Recognize the unavoidable need for runtime security

No security strategy can guarantee absolute protection. Modern software complexity and dynamic threats mean some risks will evade detection (Figure 1). According to Dynatrace analysis, a significant portion of Fortune 500 companies remain vulnerable to known vulnerabilities, such as Spring4Shell.

Left-shifted tools often lack runtime context, making it hard to prioritize vulnerabilities by real-world impact. Runtime security bridges this gap by continuously monitoring production environments, detecting and mitigating threats in real time. This approach helps organizations adapt to emerging risks instead of relying on pre-deployment checks.

Dynatrace addresses this challenge by adding runtime context to left-shifted security findings, enabling environment-aware vulnerability prioritization. Dynatrace Application Security integrates seamlessly with third-party tools to ingest and enrich vulnerability data with runtime context. This context-rich prioritization reduces cognitive overload for teams across the SDLC.

The value of defense-in-depth in SDLC

A defense-in-depth approach layers multiple security controls across the SDLC to build resilient applications that can withstand sophisticated attacks. Rather than relying on a single security measure, defense-in-depth supports the strategy that if one layer misses a vulnerability, another will catch it.

This approach gains added relevance as modern development practices accelerate release cycles, often introducing new risks at every stage. By embedding security from the earliest phases of development through to production monitoring, teams can proactively identify, mitigate, and respond to threats before they escalate. Figure 2 illustrates this multi-layered approach, mapping out key capabilities across four critical SDLC phases: Development, Build, Deploy, and Observe (encompassing the commonly referred-to phases of runtime and monitoring).

Each phase contributes unique controls and processes to a strong overall security posture. This layered approach is essential for protecting sensitive data, maintaining customer trust and meeting regulatory requirements in an increasingly hostile cyber environment.

To understand how this works in practice, let’s look at an example of a cloud-native microservices application.

End-to-end scenario: How the Astronomy Shop application leverages runtime context

Consider  Astronomy Shop, an online retailer demo application built on containerized microservices such as frontend, product, cart, checkout, payment, order, and search — all deployed on Kubernetes. Astronomy Shop’s teams implement defense-in-depth across the SDLC phases to secure their application.

By leveraging runtime context, they validate and prioritize risks in production, ensuring that the most critical security issues are addressed first. Below is a walkthrough of how Astronomy Shop uses tools and Dynatrace capabilities throughout the SDLC to enhance security.

Effective security starts at the foundation: during development. This phase sets the tone for the entire security lifecycle.

Development phase: Build security from the ground up

Scenario: Developers commit code for services like product, cart, and checkout. Security scanning runs early, and threat modeling identifies sensitive paths (e.g., checkout and payment). Findings are triaged later using the runtime context to prioritize risks.

Sample tools:

• SonarQube for code quality and static application security testing (SAST), GitHub Advanced Security for dependency monitoring and software composition analysis (SCA).

The Dynatrace role:

• Ingests security findings from development tools via OpenPipeline’s security events ingest endpoint.
• Maps findings to the Semantic Dictionary in Grail™ for unified prioritization, analysis, and automation.
• Highlights critical and high alerts and deprioritizes non-executed code vulnerabilities while prioritizing medium issues exposed to sensitive data. This helps developers focus on vulnerabilities that pose real risks in production.

After development, the build phase is positioned to catch vulnerabilities before deployment.

Build phase: Strengthening security through automation and testing

Scenario: Astronomy Shop teams build and push container images to AWS ECR. Automated image scanning tools like AWS Inspector and Snyk Container assess vulnerabilities. Findings are enriched with runtime context to identify which issues truly impact production.

Sample tools:

• AWS Inspector for image scanning and Snyk for container scanning.
• Recommended approach: Artifact/container image scanning for OS and package vulnerabilities.

The Dynatrace role:

• Extends observability to the build phase for governance and security hygiene control.
• Adds runtime context to container scans, so developers know which vulnerabilities to prioritize. This simplifies decision making and reduces cognitive load.
• Automates security gates and workflows with tools like Site Reliability Guardian to ensure no critical vulnerabilities affect production.

And now, we move on to deployment, the critical moment when applications face real-world threats.

Deploy phase: Safeguard production with real-time oversight

Scenario: The Astronomy Shop team deploys services to Kubernetes using Helm or GitOps. Admission policies and baseline checks run, while cloud controls enforce guardrails and flag misconfigurations.

Sample tools:

• Kyverno for workload and cluster policies, AWS Security Hub for cloud security posture management (CSPM).

The Dynatrace role:

• Monitors deployment success and audits deployment operations by ingesting SDLC events.
• Enriches KSPM and cloud misconfiguration findings with runtime context to prioritize critical issues.
• Detects and addresses configuration issues with Dynatrace KSPM, ensuring continuous monitoring in Kubernetes and cloud environments.

Once deployed, applications should be actively monitored to detect and address emerging threats and potential signs of compromise.

Observe phase: Monitor production for threats

Scenario: The Astronomy Shop application is deployed to production and actively monitored. A new vulnerability is discovered in a library, and Dynatrace detects and locates the issue in real time. Malicious actors attempt to exploit the vulnerability, but the application remains secure due to proactive patching.

Sample tools:

• Dynatrace Runtime Application Protection (RAP), Runtime Vulnerability Analytics (RVA), Microsoft Defender for Cloud, Amazon GuardDuty, Microsoft Sentinel.

The Dynatrace role:

• Unifies third-party runtime detections and security signals into a single view for efficient processing.
• Provides deep runtime observability through OneAgent, extending visibility to process health, cloud, and infrastructure.
• Enables runtime security capabilities like RVA (Runtime Vulnerability Analytics), Security Posture Management (SPM), and Runtime Application Protection (RAP), serving as the final defense layer against threats.

Figure 3 highlights how Dynatrace integrates seamlessly across the SDLC, enhancing security with runtime context and enabling teams to prioritize and address the vulnerabilities that matter most.

Let’s examine practical scenarios where Dynatrace enhances left-shifted security findings with runtime context, enabling environment-aware prioritization.

Practical scenarios: Elevate security with runtime context

1. Prioritize SAST findings in code
   Static scanners often detect thousands of vulnerabilities, many of which are irrelevant in production. Runtime context enables teams to prioritize vulnerabilities based on actual risk. For instance, critical severity vulnerabilities in non-executed code could be deprioritized, while medium-severity vulnerabilities exposed to the internet and near sensitive data become high priorities.
2. Prioritize container scanner findings
   Container scans often flag numerous vulnerabilities. Runtime context helps determine whether these issues truly impact production. For example, a critical vulnerability in a library that is never executed in production can be deprioritized, while containers not deployed in production can be addressed later.
3. Prioritize KSPM findings on clusters
   Post-deployment, runtime context helps identify which security issues in workload cluster components or configurations impact production services. Critical vulnerabilities with no direct impact on production can be deprioritized, letting teams focus on what matters most.
4. Prioritize cloud alerts and compliance findings
   Continuous assessment of cloud environments and prioritization of misconfigurations with the application insights reduces the noise from cloud alerts and help to remediate the most important issues first.

Ready to strengthen your security in production?

Explore how Dynatrace can integrate seamlessly into your DevSecOps processes providing application-level insights to security findings across the SDLC for smarter prioritization.

The post Strengthen production security: Bridge SDLC best practices with runtime validation appeared first on Dynatrace news.

On the product security team here at Dynatrace, we use Snyk and our own platform as our go-to tools to gain visibility into the security state of our software. Snyk detects vulnerabilities while code is being developed, while Dynatrace runtime vulnerability analysis (RVA) provides operational visibility at runtime. RVA covers all the running software that makes up our production deployment to ensure the confidentiality, integrity, and availability of the Dynatrace platform. So, how do we use the two most effectively to keep our environments secure?

In this blog, we’ll discuss the steps we’ve taken to use the newly published Snyk Integration for Dynatrace to create actionable Jira tickets for our engineers. We’ll also share how we are matching the results of Snyk’s Source Composition Analysis (SCA) to Dynatrace’s Runtime Vulnerability Analytics (RVA) results, and outline what lies ahead.

Why do so many vulnerabilities land in prod?

Generally, new vulnerabilities in both open and closed-source software are continuously discovered and disclosed by a broad community of security researchers. As a result, the number of reported vulnerabilities continues to grow year over year. Nearly 40,000 new CVEs were issued in the past 12 months, making this a key focus area for our internal security practices.

According to internal data for the software our team builds and runs, we have matched approximately 1,600 of these newly disclosed vulnerabilities to the open-source components used in our organization. Multiplied by the number of affected projects, this resulted in over a hundred thousand findings. Put simply, newly disclosed vulnerabilities amounted to over 97% of new findings.

No matter how much release-gating and pre-deployment scanning we do, the main parts of our software will eventually “become vulnerable” on production.

Because our team is responsible for detecting and distributing security findings, we need to address the large overlap between the findings that Open Source scanning by Snyk and Runtime Vulnerability Analysis by Dynatrace will detect for a service that is being monitored by Snyk at build time and by Dynatrace in our production environment.

Static scanning vs. dynamic scanning

Snyk’s static scanner re-scans dependencies every 24 hours and provides detailed insights into how and where vulnerable components are included in the build process of a project. Dynatrace RVA’s dynamic scanner, on the other hand, reports newly disclosed findings in a matter of minutes and is able to include the context of a running application to calculate the Davis Security Score, which represents a more accurate depiction of risk including the environment that a service is deployed in. Dynatrace also shows us if a vulnerable function is executed in our running deployments which heavily influences the required urgency. This makes it a very valuable data source for us in comparison with the more static CVSS scoring that findings in Snyk are typically rated with.

While both scan results have their strengths, bombarding engineers with duplicate notifications for essentially the same findings consumes unnecessary resources, interrupts focus time, and creates frustration.

This is why we needed to investigate matching results of Dynatrace RVA and Snyk, combining the results while fixing some of our long-known issues with the noisiness of native Snyk alerting. Here’s how we did it and how you can set it up for your team.

Reducing security alert fatigue

Last year, we conducted an internal survey to understand how and where our engineers are using Snyk, and what improvements they wish to see. A major concern highlighted was the notification system for issues detected by Snyk. Our engineers complained about notifications being hard to configure and being sent on an abstraction level that was either too high or too low to be usable for them. Also, our teams prefer acting on notifications in Jira since it’s already an integral part of their daily workflows.

Challenges

With these insights, our goal was clear: we wanted to implement automatic Jira ticket creation for security issues found by Snyk. But there were some major roadblocks.

• Notifications & duplicate findings. Snyk’s native notifications are tightly coupled to the way it interprets a project and therefore an issue. Snyk creates a separate project for every single configuration file scanned with Snyk Infrastructure as Code (IaC) and every Gradle sub-project for Snyk Open Source (OS). This leads to a lot of duplication for findings that often require a single remediation action in the source code.
  • In some cases, a single vulnerable component included in a repository resulted in over 40 new issues (and therefore 40 Slack notifications or action items as reported by Snyk’s native integration with Jira).
• Overlap with Dynatrace detections. We needed to find a way to match Snyk findings to Dynatrace RVA findings and prevent teams from being spammed with two tickets for every finding. Especially in the case of vulnerable components, this can become frustrating, with a project being flagged at build time by Snyk and at runtime by Dynatrace RVA.

The foundation of the Dynatrace and Snyk integration

We wanted more flexibility and to redefine what an “issue” is in our alerting context. Instead of reporting a vulnerable component finding (such as how Snyk defines it per file or Gradle sub-project), we just wanted to see the finding once on a source code repository. To make that happen, we needed a less rigid way of working with the data.

This is where the Dynatrace – Snyk extension comes in handy. This extension allows us to synchronize all our Snyk findings to our Dynatrace environment without a single line of code.

The Snyk findings persist as Security Events in Grail, which gives us all the power of DQL to transform into the views that we need. To reduce our example of 40 different issues (as detected by Snyk) into a single issue for a source-code repository, we can do a quick “summarize” call with DQL while grouping on the Snyk target.

fetch events

| filter dt.system.bucket == "default_security_custom_events"

    AND event.kind == "SECURITY_EVENT"

    AND event.provider=="Snyk"

    AND event.type=="VULNERABILITY_FINDING"
 

// take the most recent findings

| dedup snyk.issue.id, sort:{timestamp desc}

// group by target name and vulnerability id

| summarize {references = collectArray(record(project=snyk.project.name, branch=snyk.target.reference))},

    by:{snyk.target.name, vulnerability.id}

Putting this simple query in a Notebook already shows us a reduction of alerts by 80% compared to the issues we see in our Snyk environment!

Automated Jira ticket creation

We did not want to stop at Notebooks. Instead, we wanted to go the extra mile and create actionable Jira tickets for engineers without any manual intervention slowing down the distribution process and tying down resources.

This is where Dynatrace Workflows enter the picture. They allow us to easily put together simple automations that (either periodically or event-based) can trigger actions such as querying Jira for existing tickets and creating tickets based on certain criteria.

Our setup uses two workflows. The first periodically queries Security Events on Grail using a similar DQL query as depicted above to group the Snyk issues into the representation we want to have. After this query, we loop over a second workflow that receives each record as an input, resolves the owning team, and creates a Jira ticket.

To ensure we are not creating tickets for already-reported findings, we depend on the help of the Jira labels. We search if there is an existing ticket with the labels: CVE, Snyk Issue ID, and Snyk Target (usually the source code repository).

If we do not find an existing Jira issue for a new Snyk finding with the same combination of labels, we create a new ticket.

To derive the correct Jira project and assignee, we use the Dynatrace Ownership feature and the get_owners action. We can supply it with an owner identifier and Dynatrace resolves it against the stored ownership metadata. This fully automates the distribution of the created tickets directly to the responsible teams.

This simple combination of querying and grouping with DQL and then feeding into a workflow allowed us to get rid of about 80% of our alerts and create a single automatic Jira ticket for a vulnerability in a source code repository.

But there came the next challenge. If the vulnerability was already reported by Dynatrace for the same project, we did not want to create a new Snyk ticket at all. That is where we needed a solution to match findings between Snyk and Dynatrace RVA.

Connecting development and runtime

Many might remember that the Dynatrace app security product team already explored this connection of pre-deployment and runtime observability two years ago with the DevSecOps-Lifecycle (DSOL) app. While this was a great step in the right direction, it fell short on some parts that are important to us.

The DSOL app builds upon matching container scan results of Snyk to hashes of container monitored with Dynatrace. Unfortunately for us, our Snyk scanning strategy mainly focuses on Snyk OpenSource scans instead of Container scans. This meant that we could not use container hashes to match the scan results.

This brought us to the following question: How can we consistently correlate a scan that operates on repository level to scan results of Dynatrace that operate on a running system without relying on container hash matching?

Correlation of Snyk and Dynatrace RVA tickets based on Source-Location

Snyk already provides the source repository for each project in the terminology of a target which we propagate already as labels on the Jira tickets we create. However, Dynatrace also needed to be made aware of how to connect a finding on a running process to the source location that houses its source-code.

To solve this, we added a Kubernetes annotation to our main deployment templates:

dynatrace.com/source-location: <SCM-URL>

This change was rolled out across many systems through automated template updates. Dynatrace picks up these annotations and makes them queryable via DQL, allowing us to attach the source location to every Dynatrace RVA ticket we generate.

With this setup we have a common identifier between tools which allows our workflows to detect if a vulnerability has already been reported by another scanner at a different stage of the project’s lifecycle. Instead of creating duplicate tickets, we simply comment on the existing one, adding metadata about the new occurrence.

By correlating a static scan performed at build time with a runtime scan during process execution, we can leverage the strengths of both approaches without being overwhelmed by the noise of overlapping findings.

Snyk provides repository-level analysis, offering teams precise insights into how a vulnerable component is introduced into their project and where fixes need to be applied. Dynatrace RVA, on the other hand, contextualizes these findings by identifying whether a vulnerable function is invoked at runtime and whether the deployment environment influences the real-world risk.

Together, these insights play a crucial role in effective prioritization, equipping our engineers with the tools they need to assess and remediate vulnerabilities as efficiently as possible.

The outcome: Minimal alerts with maximal impact

This initiative highlighted two key strengths of the Dynatrace platform for us.

1. Dynatrace is a powerful general-purpose analysis and automation platform. It helped us significantly reduce noise and prevent alert fatigue among engineers. While our focus was on integrating with Snyk, the underlying approach is broadly applicable to other external systems that are hard to align with organizational requirements.
2. Dynatrace excels at providing precise runtime insights. In the realm of open-source vulnerability management, different scanners offer unique strengths, where Snyk prevails with scanning close to the developer with features such as IDE integrations, Dynatrace shines through tracking executed functions and the actual environmental context.

However, overlaps between scanners are common and can lead to frustrating experiences for engineers. To bridge this gap, we enrich Dynatrace runtime data with additional context using custom metadata, Kubernetes annotations, or OCI annotations on container images. This metadata also supports broader use cases like ownership tracking or cost management.

By embedding this context into our runtime monitoring, we can map complex production environments back to organizational structures and connect events across diverse systems.

What silos can we break next?

While we have built our solution a bit ad hoc, there are very interesting possibilities emerging in the Dynatrace platform of referring to source code and integrating it with running processes.

One of those was released recently with the Dynatrace Live Debugger and its ability to load source code from a configured repository and debugging applications in production in a non-breaking manner.

Similarly, some of our Dynatrace power users shared how repository information and commit hashes allow them to trace certain increments across environments, automate health gates, and alert on potential service degradations.

All these developments show how the Dynatrace platform is in the best position to enable true end-to-end observability from when code is committed to when it is processing millions of requests in production. And this breaking up of silos is what is needed in truly modern environments.

The post Snyk integration for Dynatrace: Bridging development and runtime with actionable security notifications appeared first on Dynatrace news.

At financial services company Soldo, efficiency and security by design are paramount goals.

Safeguarding against vulnerabilities, data breaches, and emerging threats while meeting regulatory compliance and customer expectations borders on the impossible without a holistic approach. This is especially true as organizations rely more on diverse and nimble cloud-native and open source technologies.

Since 2015, the Soldo business spend management platform has provided companies with a simple and efficient way to better spend and control company money. The platform helps companies manage corporate spending using automations, card (physical and virtual), and integrations with expense management systems and enterprise resource planning (ERP) systems, such as Netsuite, Concur, Zucchetti, and so on.

“We believe at Soldo that efficiency is the key value to be very successful in the business we run,” said Luca Domenella, head of cloud operations and DevOps at Soldo. This efficiency is why he and his teams use Dynatrace for everything in their development, security, and operations (DevSecOps) practices. These practices include observability, application security, Kubernetes monitoring, and microservices migration.

Domenella’s team adopted security by design from the beginning because Soldo operates in a highly regulated industry. In a recent conversation at Dynatrace Innovate in Barcelona, Spain, with Liisa Tallinn, product manager of application security at Dynatrace, Domenella explained how it works.

What is security by design?

Security by design is an approach to developing systems that integrate security principles into the entire software development lifecycle. The goal of security by design is to minimize vulnerabilities and security risks from the outset before teams release software. By integrating security practices more tightly into software development, teams can create more secure and resilient software and systems.

Cloud native from the start

To be nimble and competitive, Soldo set out to be cloud-native at its inception. “We’re born in the cloud, we’re a cloud-native company. . . to be efficient and fast at what we do,” Domenella said. “Since the beginning, we created centralized monitoring and leveraged open source products, like Nagios, to create custom controls, and Prometheus and Grafana for monitoring.”

But as the company matured, it needed to elevate its observability game. “We needed to adopt an end-to-end visibility tool that could give us broader visibility of what was happening in our ecosystem and within the applications,” he said. “The most efficient one we found was Dynatrace.”

End-to-end observability enables security by design

“The value Dynatrace gives us is broader visibility over the full infrastructure and the key metrics that show how fast we authorize the transactions,” Domenella said.

As a Mastercard issuer, having visibility into card authorization response times is crucial for Soldo. “Only Dynatrace enables us to check if the application is running as expected and that our response times to Mastercard aren’t lagging.”

The visibility extends through smartphone applications, load balancers, web application firewalls (WAFs), and databases. With end-to-end observability, the DevOps teams at Soldo can create rules and manage workflows. These rules and workflows ensure that users can use the Soldo platform to spend money seamlessly.

Adopting security by design is fundamental in a highly regulated industry such as the payment card industry. As a result, Domenella and his colleagues have shifted security controls “left” into the development cycle. “Dynatrace gives us a lot of value because we are not perfect,” Domenella said. “There is always something that can escape the controls, especially zero-day vulnerabilities.” Data supports this. Of 1,300 organizations, 61% say it’s impossible to respond to zero-day vulnerabilities quickly enough to eliminate risk entirely.

Benefits of a security-by-design approach

This security-by-design approach has enabled Soldo to reduce mean time to recovery (MTTR) to fix new vulnerabilities. “Dynatrace App Security gives us security visibility into what’s happening in runtime,” Domenella says. “This enables us to see and fix security weaknesses in the applications and improve the product.” As a result, Domenella and his team have adopted DevSecOps practices that enable them to focus on what’s most important.

With this awareness, the security team at Soldo can prioritize which vulnerabilities to address first. “This is very important because [the team] can focus on the risk score of every vulnerability,” he said. “Because you can’t recover everything in a moment.” For Domenella and his team, security is no longer a silo. “It’s the glue between the DevOps teams because we have several development teams,” he continued. “Typically, a security team delays development until they resolve all the vulnerabilities.” At Soldo, however, the teams are integrated and invested in each other’s success.

Every week, the Soldo security teams use Dynatrace APIs to generate a report they discuss with the development teams. “This report gets all the important vulnerabilities directly from Dynatrace so developers can discuss the risk score of each.” He further noted that all of this is automatic, requiring no manual processes.

Security by design helps Soldo on its Log4j adventure

Like many organizations, Soldo was affected by Log4Shell, the zero-day vulnerability in the Apache Log4j library that emerged in 2021. Using Dynatrace, Soldo completely eradicated its Log4Shell issues in a very short time.

“Using the full suite and end-to-end visibility provided by Dynatrace, we’ve been able to find a workaround to immediately secure our systems against the Log4j exploits,” Domenella said. With end-to-end visibility and the Dynatrace real-user monitoring (RUM) interface, his team analyzed what was going on and took defensive measures through the organization’s AWS WAF. With the system protected against immediate attacks, the team developed and deployed a patch, which they rolled out to all production systems within 14 days.

“I think it’s a very good result,” Domenella added.

A security-by-design approach helps with microservices migration and Kubernetes implementation

Next on the agenda for Soldo is using the security-by-design approach Domenella and his teams have implemented with Dynatrace to migrate its legacy services to microservices architecture. “We also use Dynatrace to create the priorities for this migration because of the time it takes to fix the vulnerabilities in the old architecture.”

Another priority for the teams at Soldo is using Dynatrace end-to-end observability to shift applications to Kubernetes. “Dynatrace is the basic brick that we built in our system to provide visibility, especially inside Kubernetes,” Domenella said. “You can use several tools to have visibility inside Kubernetes, but (they) don’t have the same visibility that Dynatrace can give you, because it’s not just monitoring.”

With Dynatrace, Soldo teams can see what’s happening in a cluster and also correlate among all the applications and workloads. This includes the Kubernetes cluster itself and all the other elements running in their IT environment.

The post Security by design enhanced by unified observability and security appeared first on Dynatrace news.