Dynatrace Security Enrichment gives security teams one place to connect commercial, open source, and proprietary threat intelligence (TI) sources and use them to enrich IP addresses across Dynatrace Investigations, Threats & Exploits, and Workflows. Instead of building and maintaining a separate connector for each TI provider, you configure an HTTP-based connection, normalize the response, and reuse that context across the platform. This can support faster triage and more consistent decisions, and reduce integration overhead, for teams that rely on both third-party feeds and internal intelligence.

Why security teams need flexible threat intelligence enrichment

How can you distinguish between yet another false positive and a real threat when the context your team needs resides in a different tool for each investigation?

Threat intelligence sources rarely live in one place. Your team might rely on commercial feeds for reputation data, open sources for additional signal, and internal services for the context that matters most to your business. An internal IP reputation database or customer-IP registry can be just as important as any external feed.

That fragmentation slows down every investigation. Analysts move between browser tabs, scripts, and disconnected tools just to answer basic questions about an IP address. Each source returns a different response pattern, which makes it harder to apply consistent triage logic across teams and workflows. The more enrichment sources you depend on, the more operational overhead you create.

At the same time, security teams are under pressure to automate triage without losing control. That means you need flexible enrichment that can keep up with new providers, internal intelligence, and changing workflows without forcing you to build a new connector every time.

One unified experience to operationalize intelligence sources

Dynatrace Security Enrichment gives you a flexible, native way to connect to any HTTP-based threat intelligence API and use its results directly in the Dynatrace Platform. This includes commercial services, open source feeds, and proprietary internal APIs.

Start in minutes with vendor blueprints.

Pre-configured templates for popular providers like AbuseIPDB and VirusTotal handle the setup for you. Add your API key, and the enrichment configuration is set.

Connect any other source just as easily.

Whether it’s a niche commercial provider, an OSINT platform like MISP, or your team’s own internal reputation service — if it has an HTTP API that returns JSON, you can connect it. No coding, no custom integration development. Just point, configure, and go.

See consistent results across every source.

Each security intelligence source vendor returns different field names, different scoring models, and different response structures. Dynatrace Security Enrichment normalizes all of this — using the same query language your team already knows from Dynatrace — into a unified view with consistent reputation levels, geolocation data, recency indicators, and source references. Triage logic and automation that works for one source works for every source you add afterward.

From manual lookups to automated responses

This is where Security Enrichment changes the operational model — not just the tooling.

Consider a team that maintains its own internal IP reputation database, built from years of telemetry and asset context that no external vendor can provide. Today, when an analyst encounters a suspicious IP during an investigation, they open a separate tool, query that database manually, and paste the result back into their case notes. Multiply that by every investigation, every analyst, and every day.

With Security Enrichment, that internal system becomes a native enrichment source. The analyst selects an IP in their investigation and sees the internal reputation score right alongside commercial intelligence and geolocation — in one consistent view that persists as case evidence. No context switching, no manual lookups, no data siloed in a browser tab.

The same connection also powers automated workflows. Teams use the enrichment action in Dynatrace Workflows to build automated triage patterns like:

• Multi-source consensus. Enrich against several sources in parallel and only escalate when multiple providers agree an indicator is malicious — dramatically reducing false positives from any single feed.
• Automatic suppression of known-good traffic. Auto-resolve findings involving IPs your internal systems have classified as benign, with a full audit trail — so analysts focus on the alerts that actually need attention.
• Pre-enriched cases from the start. Automatically enrich every new investigation case the moment it opens, and page the on-call responder when a recently flagged malicious IP appears — so no one opens a case cold.

Because enrichment, detections, investigations, and automation all live on one platform, your team can run these patterns without sending alerts to a separate orchestrator, without maintaining duplicate configurations, and without the drift that comes from stitching together tools that weren’t designed to work together.

What’s next

We’re evolving Security Enrichment to cover a broader set of observables relevant to investigations. We’re also exploring ways to make integrations more adaptable based on user needs. Over time, we aim to further incorporate threat intelligence to inform investigations and support more proactive detection.

Get started

You can get started with Security Enrichment directly from the Dynatrace Hub and create your first connections in just a few clicks.

If you’re already using the standalone AbuseIPDB or VirusTotal apps, matching blueprints are available to help streamline the transition. With those standalone apps removed in June 2026, now is a good time to see what other threat intelligence you can incorporate.

The post Dynatrace Security Enrichment: Every threat intelligence source in one unified experience appeared first on Dynatrace news.

Kubernetes Security Posture Management (KSPM) is a specialized subset of Security Posture Management (SPM) that focuses on container orchestration platforms. Its main purpose is to identify misconfigurations and compliance gaps across clusters. Here are the latest enhancements:

• KSPM is turned on by default during Kubernetes cluster onboarding
• Security findings are surfaced directly in the Kubernetes app
• Node Configuration Collector (NCC) occurs automatically via the Dynatrace Operator. These improvements reduce operational overhead for platform and SRE teams while embedding security insights directly into runtime context, so teams can quickly understand, prioritize, and act without switching tools.

Dynatrace now unifies:

• Vulnerability findings (runtime-relevant CVEs)
• Detection findings (active threats)
• Misconfiguration findings (insecure configurations or compliance gaps)

The result is a single, contextual view of risk across your Kubernetes workloads.

The problem: Security findings without context slow teams down

Today, security and development teams operate with fragmented visibility:

• Developers receive CVEs or misconfiguration alerts without runtime context
• Security teams know what’s wrong but lack clarity on where the issues are and who owns them
• Findings and workloads exist in separate tools, owned by different teams

The impact

This fragmented visibility ultimately introduces friction and delay with each hand-off. The result is lower remediation, unclear ownership, and increased exposure risk for business-critical applications.

Security in context, without the context switch

Dynatrace closes this gap by embedding security findings directly into the Kubernetes app. A new Security tab is now available at the workload, namespace, and cluster levels, giving teams a unified view without leaving the platform they already work in.

Three types of findings unified into a single view

The Security tab surfaces three categories of findings.

1. Vulnerability findings focus on CVE libraries loaded at runtime, so findings reflect what is actually running, not everything that’s installed.
2. Detection findings flag signals of active malicious behavior, tied directly to specific Kubernetes resources.
3. Misconfiguration findings highlight deviations from benchmarks starting with CIS, visible in near real time.

Why this matters

Developers can now identify security issues while investigating performance or availability, see findings in the exact context of the affected workload, and act immediately, without waiting for an external ticket to make its way through the queue.

Consider a practical example: a developer investigating a workload discovers that Kubernetes secrets are exposed as environment variables instead of mounted as files. Without this integration, that issue might surface days later, stripped of actionable context and requiring cross-team coordination to resolve. With Dynatrace, it appears in real time, in the same workflow, with clear remediation guidance attached.

From insight to fix, without leaving the platform

Starting from the Security tab, developers can jump straight into the Security Posture Management app, pre-filtered to the exact finding they’re investigating, no manual searching required. From there, Smartscape® topology provides full runtime context at a glance: the affected workload, namespace, cluster, and its dependencies, all mapped out instantly. (This same type of user journey is also supported for the Vulnerabilities app and Threats & Exploits.)

Guidance that tells you what to do, not just what’s wrong

Rather than leaving teams to interpret raw findings, Dynatrace Intelligence delivers plain-language recommendations tailored to the specific benchmark and workload. In the secrets exposure example, the guidance is concrete: update your YAML configs to mount sensitive data as files rather than environment variables. No guesswork, no interpretation overhead.

The result is that teams can move from detection to remediation within a single session, without switching tools or waiting on another team to connect the dots.

Onboard Kubernetes clusters to Dynatrace for monitoring with automatic rollout and enablement of KSPM scans

Dynatrace removes friction from Kubernetes security adoption by making it automatic from the start. KSPM is now turned in during Kubernetes onboarding, with the Dynatrace Operator automatically deploying NCC without any manual configuration.

How it works

1. Start cluster onboarding in the Kubernetes app.
2. Select your monitoring mode (KSPM is turned on by default).
3. Install the Dynatrace Operator (Helm or GitOps).
4. NCC is deployed automatically for compliance data collection.
5. KSPM scans begin.
6. Misconfigurations appear in context within Kubernetes resources.

What’s next

Dynatrace will soon expand coverage across diverse Kubernetes environments with the introduction of Kubernetes Security Essentials, a new KSPM profile that provides baseline best-practice security checks across Kubernetes distributions and versions, without requiring node-level configuration data.

Broader coverage, wherever you run Kubernetes

This matters because not every environment supports full benchmark profiles. Kubernetes Security Essentials extends consistent security posture evaluation to platforms like GKE, OpenShift, K3s, and MicroK8, meaning even the most lightweight or managed distributions can now benefit from the same foundational security checks as any other environment.

Get started

Onboard your Kubernetes clusters with Dynatrace to:

• Gain visibility into your security posture
• Identify and prioritize critical misconfigurations
• Move from finding to fixing faster

The post Your business applications are at risk: Introducing in-context security findings for Kubernetes appeared first on Dynatrace news.

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.

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.

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.

In this blog, we’ll demonstrate how attackers exploiting CVE-2025-3248 can use traditional attack techniques to manipulate AI agent behavior and plant a malicious backdoor in AI-generated source code.

To help mitigate the risks posed by vulnerabilities in agentic AI frameworks, we show how Dynatrace Cloud Application Detection and Response (CADR) detects malicious activity to protect both the agents and the environment they run in.

The attacker’s perspective: What is CVE-2025-3248 and how to exploit it?

The critical vulnerability CVE-2025-3248 in the Langflow framework leads to remote code execution (RCE) due to the ability to perform code injection (CWE-94) by unauthenticated users (CWE-306). Dynatrace security researchers discovered that in addition to affecting the Python package langflow v1.3.0 and below, the package langflow-base v0.3.0 and below are also vulnerable.

In our scenario, an attacker exploits this vulnerability to get remote access to the container running Langflow. The attacker manipulates the instructions to the LLM in the AI agent to inject a backdoor into generated code functions as shown in the figure above.

Let’s step back and take a look at the process from the beginning. The figure below shows the user interface of Langflow. To configure the agent, a benign system prompt saying “You are a programming assistant. Respond to technical queries with clarity, accuracy, and efficiency” is used in the setup. The user can interact with the agent through a chat input and receives answers through a chat output window. The agent can also be exposed and integrated into an external application using an API.

In our setup, the Langflow framework is deployed on a Kubernetes cluster and is accessible to users to work on specific tasks, such as using the agent to generate source code. The attacker in our scenario uses one of the public exploits for CVE-2025-3248 to inject and execute attacker-controlled code into the container, like reading the /etc/passwd file as shown below.

The attacker then opens a reverse shell to execute more commands on the application host and further compromise the system. Specifically, the attacker establishes a connection using port 7777 to facilitate command execution on the container. Opening a reverse shell enables the attacker to be much quieter when executing certain commands, since the initial exploit script causes an exception which is visible in the log files.

To further penetrate the system, the attacker searches for the SQLite database used by Langflow and then proceeds to enumerate user accounts, credentials, and flows. They could exfiltrate the data or alter it in the database, further compromising the integrity and security of the system.

In the default deployment configuration of Langflow, which uses a local SQLite database, the attacker can access this data without needing any credentials. If Langflow is configured to use a different database backend (e.g., PostgreSQL), the attacker may still be able to retrieve the necessary credentials by inspecting environment variables.

The attacker then changes the system prompt of the AI agent to a malicious one in the database to make the AI agent inject a backdoor into generated code and obfuscate it.

Now, when a user requests the agent to generate a code snippet, it would include an obfuscated malicious portion with a code comment telling the user that the code is there to ensure backwards compatibility and not to remove it, as seen below.

While this might appear to be obviously suspicious code, the risk increases significantly when the agent is tasked with producing larger or more complex codebases. In such cases, users may be inclined to run the code without thoroughly reviewing or verifying its contents. The potential impact becomes even more serious if the Agentic AI is integrated into development environments where it can test and execute code directly on a developer’s machine.

The defender’s perspective: How the Dynatrace CADR approach helps

Dynatrace enables the detection and prevention of the type of attacks described above on multiple layers: By detecting the vulnerability as the entry door for the attacker, identifying misconfigurations that enable an attack to penetrate the system, and investigating suspicious traces caused by the exploit.

Let’s walk through an example scenario that explores all three layers. The journey begins when Dynatrace workflows notifies a Site Reliability Engineer (SRE) on Slack about a Python exception through Dynatrace workflows.

This encourages the SRE to have a closer look at the affected container, which has a critical vulnerability that is detected and visible in the Vulnerabilities App. Investigating the affected container also shows several misconfigurations in the Security Posture Management App which leads the SRE to align with internal security analysts and start a deeper investigation using the Security Investigator App.

First layer of defense: Detecting CVE-2025-3248 with Runtime Vulnerability Analytics

The version of the Langflow framework we installed contains the recent critical vulnerability CVE-2025-3248 which is detected right away by Dynatrace’s Runtime Vulnerability Analytics as shown below.

Agentic AI frameworks are often based on Python and the recently introduced ability in Dynatrace to detect Python vulnerabilities at runtime provides immediate information about potential doors for attackers. Applying the recommended fix outlined in the vulnerabilities app would prevent an attacker from exploiting the system.

Second layer of defense: Identifying misconfigurations with Security Posture Management (SPM)

Specific configurations in complex systems enable attackers to perform certain actions to penetrate through a system and achieve their goal.

In our scenario, the attacker employs a reverse shell, which is a common tactic used to enable remote command execution. In the current configuration of our Kubernetes cluster a network policy is missing which is shown in the SPM app.

To address the tactic of deploying a reverse shell, implementing a network policy that restricts all outbound connections, except for HTTP/S ports, serves as an effective countermeasure, while allowing essential web access for the AI Agent.

Applying network policies across a Kubernetes cluster is a security best practice, as outlined in benchmarks like those from the Center for Internet Security (CIS). The Dynatrace Security Posture Management application can identify and prevent such misconfigurations. In our scenario, as shown below, we apply a network policy to the langflow namespace which prevents attackers from using random ports for a reverse shell.

Although the network policy in our scenario does not entirely protect against advanced attack techniques, as attackers may circumvent restrictions, they increase the complexity and difficulty of executing successful attacks. By adopting these SPM rules, best practices can be enforced to effectively reduce the attack surface. Adjusting deployment configurations and aligning them with compliance benchmarks, organizations can significantly reduce the risk of successful compromises. Good compliance practice will further reduce the blast radius in case of a successful attack, for example by preventing attackers from escaping a compromised container.

As we can see in the screenshot below, when the network policy is configured, the attacker is unable to establish a reverse shell connection. See the figure below with the message “Exploit failed with status 200”. This makes the traces of the attack more noisy and visible in the log files and allows analysts to draw conclusions more easily.

Third layer of defense: Tracing the exploit with the Security Investigator

After being notified by a workflow automation our analyst runs a query in the Security Investigator to check for exceptions on any of the monitored Kubernetes clusters and receives a number of outputs as shown below.

Tracing the cause of the exception in the log entries, the analyst discovers the following suspicious log lines showing the command and its output executed by the attacker.

Based on this, the analyst decides to further investigate this activity and discovers multiple attacker activities as shown below.

Filtering out the relevant content from the log entries of the affected container reveals the different steps performed by the attacker, such as executing shell commands and deploying a reverse shell to further penetrate the system and manipulate the AI agent.

Conclusion

The exploitation of CVE-2025-3248 demonstrates how traditional attack techniques—like remote code execution and reverse shells—can be repurposed to compromise agentic AI systems. As these frameworks become more deeply embedded in enterprise workflows, the attack surface will continue to expand, and the stakes will grow higher.

Securing agentic AI isn’t just about patching vulnerabilities. It’s about anticipating how attackers will adapt and evolve. The Dynatrace multi-layered approach, combining runtime vulnerability analytics, security posture management, and deep log investigation, provides a robust foundation for defending these dynamic environments.

The post Remediating CVE-2025-3248: How Dynatrace Application Security protects Agentic AI applications 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.

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.

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.

Log data alone, however, is often not enough to give you a complete overview. In the case of security incidents, the origin of a failed request or a login attempt is often the most valuable information you have in triaging a potential incident and determining its severity.

To speed up your threat hunting and incident response activities, Security Investigator now allows you to enrich IP addresses with additional context from third-party threat detection databases.

Fast insights into IP addresses

Dynatrace Security Investigator is one of the built-in apps shipped 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 solving a security incident and need to understand more about the origin of an attack. You want to check the IP address reputation analysis provided by AbuseIPDB or VirusTotal, but manually looking up and pasting these addresses takes too much time. Not to mention, you want to keep this external reputation information tied to your investigation for future access.

By right-clicking an IP address in Security Investigator and selecting Enrich IP, you can choose your configured enrichment source to enrich the address. For this first release, Dynatrace offers IP enrichment insights from AbuseIPDB and VirusTotal.

Suppose you find something suspicious in your log data related to a certain IP address. You can now add the IP address and additional reputation analysis to your Suspicious IP evidence list in Security Investigator.

The IP address and corresponding enrichment data are now kept in the context of your investigation; you can revisit this enrichment data at any time.

Automatic IP evidence enrichment

You can now automatically enrich all the IP addresses you collect with evidence. In the evidence list enrichment menu, choose if enrichment should be enabled for all added elements by default, and which connection should be used to enrich the IP addresses that are added to your evidence list.

When you add new IP addresses to the evidence list, they’re automatically enriched on your behalf using your selected enrichment connection.

Select the details icon to quickly access the persisted IP enrichment data that’s fetched from each third-party source.

The post Security Investigator offers reputation analysis and context for IP addresses appeared first on Dynatrace news.

Dynatrace® now integrates with VirusTotal to provide threat intelligence context for observables, helping your organization combat online threats such as cyberattacks, spamming, and other malicious activities.

In today’s continuously evolving threat landscape, enterprises face hundreds of suspicious activities coming from potentially malicious actors. Various security tools are capable of identifying suspicious activity and reporting it. However, Security Operations (SOC) and Incident Detection and Response (IDR) teams are often overwhelmed by the number of alerts and detections generated by these tools.

How can you distinguish between yet another false positive and a real threat? And how can you know that your organization’s response will be as fast as possible?

Threat intelligence information provides a strong indication of the maliciousness of detected activities based on industry reports. Whether it’s a random malicious act that affects some organizations or a comprehensive threat-actor activity that jeopardizes the whole industry, threat intelligence provides the additional context your teams need to decide how much attention to give to a certain alert.

Uplevel your security investigations with Dynatrace

The Dynatrace® platform integrates with various security detection tools and offers runtime context to better filter incoming alerts and focus only on those that impact your sensitive services and applications, which draws your organization’s internal prioritization considerations towards important alerts.

An additional element for reducing alert noise and achieving better prioritization of security alerts is threat intelligence context. Such context represents the external factors that must be taken into consideration during triaging.

Dynatrace integrates with VirusTotal and offers threat intelligence enrichment for observables, such as IP addresses. With provided threat context, such as IP reputation, your security  teams can perform:

• Threat-informed security investigations: Enhance your security investigations by leveraging IP reputation data to detect anomalous and malicious activity in Security Investigator.
• Automated threat-alert triaging: Classify and prioritize alerts using enriched threat intelligence in Workflows.

Easy VirusTotal integration via Dynatrace Apps

The VirusTotal integration is delivered as a Dynatrace app that can be installed in-product using the Dynatrace Hub.

As soon as the integration is installed, you can start using the threat intelligence enrichment capabilities in Workflows using the dedicated workflow action. It’s possible to configure multiple connections to VirusTotal and use your preferred connection for each workflow action.

Dynatrace also provides you with a sample workflow, which demonstrates an end-to-end automated threat-alert triaging use case. This sample workflow processes new critical detection findings and, based on the reputation of the involved IP addresses, decides whether to notify relevant stakeholders.

What’s next

The VirusTotal threat intelligence enrichment capabilities are not limited to workflow use cases. We’re working on enabling other Dynatrace® Apps, such as Security Investigator and Threat and Exploits, to natively support the VirusTotal integration and provide the additional context as part of each user journey.

Get started

For full details of the prerequisites and steps for setting up the VirusTotal integration, please visit our documentation, Enrich threat observables with VirusTotal.

The post Enrich observables with VirusTotal threat intelligence appeared first on Dynatrace news.

Dynatrace® now integrates with AbuseIPDB to provide threat intelligence context for observables, helping your organization combat online threats, such as cyberattacks, spamming, and other malicious activities.

In today’s continuously evolving threat landscape, enterprises face hundreds of suspicious activities coming from potentially malicious actors. Various security tools are capable of identifying suspicious activity and reporting it. However, Security Operations (SOC) and Incident Detection and Response (IDR) teams are often overwhelmed by the number of alerts and detections generated by these tools.

How can you distinguish between yet another false positive and a real threat? And how can you know that your organization’s response will be as fast as possible?

Threat intelligence context provides a strong indication of the maliciousness of detected activities based on industry reports. Whether it’s a random malicious act that affects some organizations or a comprehensive threat-actor activity that jeopardizes the whole industry, threat intelligence provides the additional context your teams need to decide how much attention to give to a certain alert.

Uplevel your security investigations with Dynatrace

The Dynatrace® platform integrates with various security detection tools and offers runtime context to better filter incoming alerts and focus only on those that impact your sensitive services and applications, which draws your organization’s internal prioritization considerations towards important alerts.

An additional element for reducing alert noise and achieving better prioritization of security alerts is threat intelligence context. Such context represents the external factors that must be taken into consideration during triaging.

Dynatrace integrates with AbuseIPDB and offers threat intelligence enrichment for observables, such as IP addresses. With the provided threat context, such as IP reputation, your security teams can perform:

• Threat-informed security investigations: Enhance your security investigations by leveraging IP reputation data to detect anomalous and malicious activity in Security Investigator.
• Automated threat-alert triaging: Classify and prioritize alerts using enriched threat intelligence in Workflows.

Easy AbuseIPDB integration via Dynatrace Apps

The AbuseIPDB integration is delivered as a Dynatrace app that can be installed in-product using the Dynatrace Hub.

As soon as the integration is installed, you can start using the threat intelligence enrichment capabilities in Workflows using the dedicated workflow action. It’s possible to configure multiple connections to AbuseIPDB and use your preferred connection for each workflow action.

Dynatrace also provides you with a sample workflow, which demonstrates an end-to-end
automated threat-alert triaging use case. This sample workflow processes new critical detection findings and, based on the reputation of the involved IP addresses, decides whether to notify relevant stakeholders.

What’s next

The AbuseIPDB threat intelligence enrichment capabilities are not limited to workflow use cases. We’re working on enabling other Dynatrace® Apps, such as Security Investigator and Threat and Exploits, to natively support the AbuseIPDB integration and provide the additional context as part of each user journey.

Get started

For full details of the prerequisites and steps for setting up the AbuseIPDB integration, please visit our documentation, Enrich threat observables with AbuseIPDB.

The post Enrich observables with AbuseIPDB threat intelligence appeared first on Dynatrace news.

Dynatrace introduces a new advanced way to enhance your DQL queries in Security Investigator cases. The pivoting queries concept allows engineers to quickly change the investigation context by switching the scope of a query using available pivoting dimensions.

Time is critical

Imagine you’re investigating latency issues in your cloud applications by analyzing your Istio proxy logs with Security Investigator. You have hundreds of pods, each of which has application containers and Istio containers running side-by-side. You analyze all the Istio logs at once to get a comprehensive overview of the whole infrastructure, fetching logs for all long-running requests, and you want to investigate some of the requests to identify the issues behind the high latency.

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

Security Investigator allows you to:

• Keep your whole investigation flow in context.
• Perform complex security investigations on the data stored in Grail.
• Build DQL queries based on your findings in a fast and easy way.
• Save and use the found evidence to build your DQL queries and find answers to your questions.
• Navigate with ease to any point in your investigation history and review queries and results.
• Fetch detailed results in the original format to quickly understand the information.

Quickly shift your investigative perspective

Thanks to pivoting queries, it‘s now possible to quickly shift your investigation from one perspective to another. You can choose Pivot query by right-clicking any record in the results table in Security Investigator and selecting the dimension you want to pivot your query by, for example, Kubernetes pod. As a result, a new query node is created, containing all the logs from the same Kubernetes pod from which the Istio record originated, giving you the full context and all application logs from that pod.

Pivoting queries also work at scale: if you select multiple records and use pivoting queries with multiple values, multiple nodes will be created based on the distinct selected values. So, if you choose five result records and pivot query by trace_id, then five new query nodes will be created, which will contain results for each respective trace ID. This allows you to continue investigating each trace in your query branch, keeping the context and tracking your individual query history.

The pivoting dimensions are chosen from the metadata fields of your log records and can be further customized in Security Investigator. You can switch dimensions from, for example, a high-level Kubernetes cluster or host to the corresponding process group instance or cloud application, depending on your investigation’s purpose and the context you need.

The pivoting queries feature allows you to speed up your investigations and apply them in different contexts using the power of the query tree and other investigative features of Security Investigator.

Get started

The post Pivot the perspective of your investigative queries with Security Investigator appeared first on Dynatrace news.

Expand security posture management across cloud and VMware

Building on this success, Dynatrace continues to evolve its platform to support broader Cloud Security Posture Management (CSPM) and VMware Security Posture Management (VSPM) use cases. While platform-native Security Posture Management capabilities are on the horizon, you don’t have to wait to benefit from these insights. Thanks to the tight integration with Runecast Analyzer, Dynatrace users can already access robust CSPM and VSPM functionality today, allowing them to:

Continuously assess their cloud and VMware environments for misconfiguration

Organizations operating in regulated industries, such as finance, healthcare, and government, must demonstrate ongoing compliance with standards like CIS, PCI-DSS, NIST, DORA, and DISA STIG. With Runecast Analyzer integrated into Dynatrace:

• Compliance checks are automated and performed on a daily basis, rather than annually, with cumbersome manual effort.
• Findings are mapped to specific controls, and affected resources can be easily identified.
• Audit readiness becomes a proactive, not reactive, process.

Proactively reduce risks

Misconfigurations are one of the leading causes of cloud breaches. CSPM and VSPM help teams:

• Detect insecure configurations in cloud services.
• Identify vulnerabilities in VMware environments before they’re exploited.
• Prioritize remediation based on real-time impact and exposure.

Bridge security and operations

Security teams often struggle to communicate risk in a way that’s actionable for DevOps and platform teams. This integration allows shared visibility through Dashboards, Notebooks, and Workflows.

Gain hybrid and multicloud visibility

Modern enterprises operate across AWS, Azure, GCP, and on-premises VMware. Runecast Analyzer supports all these environments, and Dynatrace delivers insights into them together on a single platform, ensuring consistent posture management across the entire stack.

Get Started with Runecast Analyzer and Dynatrace

Dynatrace makes it easy to ingest and analyze compliance findings from Runecast Analyzer. Here’s a quick overview of the setup process:

1. Deploy Runecast Analyzer

• Deploy the Runecast Analyzer Virtual Appliance in your environment (on-premises or cloud).
• Connect the virtual appliance to your cloud accounts (AWS, Azure, GCP) and VMware infrastructure.

2. Enable compliance scanning

• Choose from a wide range of compliance profiles.
• Schedule regular assessments or run them on demand.

3. Ingest findings into Dynatrace

• Use the Dynatrace Security Events API to ingest findings from Runecast.
• Findings are enriched with Dynatrace context and stored in Grail™ data lakehouse for unified analysis.

4. Visualize and act

• Explore findings using Dashboards, Notebooks, and Security Investigator.
• Automate responses with Dynatrace Workflows—trigger alerts, create tickets, or initiate remediation.

Looking ahead

As Dynatrace continues to enhance its platform, you can look forward to even more seamless and native capabilities for CSPM and VSPM. In the meantime, the current integration with Runecast Analyzer ensures that your organization can start strengthening its security posture and compliance coverage within the Dynatrace platform today.

___

© 2025 Dynatrace LLC

Dynatrace and the Dynatrace logo, are trademarks of the Dynatrace, Inc. group of companies. All other trademarks are the property of their respective owners.

The post Extend the Dynatrace platform with CSPM and VSPM appeared first on Dynatrace news.

Protecting applications running in cloud-native environments is top of mind for many security practitioners. To keep up with the increasing number of threats targeting workloads in the cloud, delivering multi-layer protection by seamlessly integrating visibility, analytics, and response in one platform is key. Cloud Application Detection and Response (CADR) is thus emerging as a stronger approach to application security. CADR ensures a more holistic application security strategy, continuously monitoring for suspicious or unauthorized activities at any layer of an application, from code to container.

In this blog, we’ll use the example of the high-profile Spring4Shell vulnerability to demonstrate how Dynatrace can detect and prevent exploitation on multiple layers. This blog will illustrate a simplified view of the steps an attacker can take, from initial access through remote code execution to sending commands to a web shell and further exfiltrating cloud resources. For each step, we will demonstrate how different features in Dynatrace Application Security can be used to detect and prevent critical threats.

What is Spring4Shell?

Spring4Shell (CVE-2022-22965) is a critical remote code execution vulnerability in the Spring Framework, a popular Java platform for building web applications. The exploit specifically targets applications running on Java 9 or newer, often deployed with Apache Tomcat using specific packaging (such as WAR deployment). While Spring4Shell is not the most recent vulnerability, its high criticality, easiness of exploitation, and wide distribution make it still relevant today. According to Dynatrace analysis, 50% of Fortune 500 companies are still vulnerable to Spring4Shell.

When exploited, Spring4Shell allows an attacker to send specially crafted HTTP requests that manipulate class properties via Spring’s data-binding mechanism. In a vulnerable environment, the attacker can overwrite internal configuration fields, such as those belonging to ClassLoader or Tomcat’s file upload paths.

The exploit can be used to write a web shell or other malicious Java code (commonly as a .jsp file) into a directory served by the webserver (for example, Tomcat’s webapps/ROOT). Once the attacker writes a JSP web shell to the filesystem, they can send commands to it and gain remote control to execute commands, read or modify files, and escalate privileges.

One of the first public exploit PoCs of the Spring4Shell vulnerability was shown by the Github user Reznok in the repository Spring4Shell-POC. The repo provides a simple Java application based on a vulnerable version of the spring framework in a container.

To demonstrate how Dynatrace detects an exploit of Spring4Shell, we set up a small Kubernetes cluster and deployed the container with the vulnerable application.

CADR first layer of defense: Runtime Vulnerability Analytics

In the Kubernetes app, we can see the deployed container “spring4s-ti-app-no-sc” running the test application vulnerable to Spring4Shell.

Accessing the running application shows the expected output:

Looking in the Vulnerabilities App, we can see the container with the Spring4Shell vulnerability. The app shows the affected process groups in the container as well as the vulnerable functions related to Spring4Shell, which are currently in use.

Presenting the first layer of defense, the Vulnerabilities App shows exactly where a specific vulnerability is located and if it is currently in use by a specific process group, which is the case in our scenario. Upgrading the vulnerable packages to a non-vulnerable version would remediate this threat by closing the entry door for an attacker to further propagate through the system.

CADR second layer of defense: Security posture management

On the deployed container, we now run the exploit script provided in the repo and see the expected output:

~$ python3 exploit.py --url http://10.200.2.57:8080/helloworld/greeting

[*] Resetting Log Variables.

[*] Response code: 200

[*] Modifying Log Configurations

[*] Response code: 200

[*] Response Code: 200

[*] Resetting Log Variables.

[*] Response code: 200

[+] Exploit completed

[+] Check your target for a shell

[+] File: shell.jsp

[+] Shell should be at: http://10.200.2.57:8080/shell.jsp?cmd=id

As shown in the terminal output above and explained in detail in our earlier blog post about Spring4Shell, the exploit changes the log configuration and then writes a file containing malicious code to the vulnerable environment.

Now, we have a web-shell deployed that we can leverage to execute commands in the container:

A closer look at the deployed container “spring4s-ti-app-no-sc” in the Security Posture Management App shows that the deployed container fails certain checks defined in Kubernetes security benchmarks, such as the one from the Center of Internet Security (CIS). One specific check, as shown below, verifies the presence of a security context in the Kubernetes deployment .yaml file of our container, which is missing in our case.

We add the “SecurityContext” to the deployment .yaml file to ensure that the main process in the container is running as a non-root user (such as uid 1000). With this adjusted .yaml file we deploy the container again under the name “spring4s-ti-app-sc” on our Kubernetes cluster. As shown below, this deployment passes the security context check.

Executing the Spring4Shell exploit on the deployed “spring4s-ti-app-sc” container fails because the main container process is not running as root. We can verify this by checking the logs of the container, which state that creating the /usr/local/tomcat/webapps/ROOT directory failed and the shell.jsp file cannot be found, as shown below:

Attempts to access the web-shell do not work on the container with the enabled security context.

Security posture management is thus critical. In this scenario, simply changing specific configurations of a deployment—without touching the application or upgrading a vulnerable package—can prevent an exploit from being successful. Mapping checks of a compliance benchmark to attack techniques used during an exploit can significantly reduce the risk of a successful compromise.

CADR third layer of defense: Threats & Exploits

Identifying vulnerabilities such as Spring4Shell and adjusting configurations to prevent exploitation requires detailed knowledge about the vulnerability and exploit techniques against it. For cases where a vulnerability is not known yet (i.e. “zero-day” vulnerabilities), Dynatrace’s Threats & Exploits App provides the ability to automatically detect, monitor and block attacks that are based on specific techniques such as command or SQL injection.

The screenshot below shows the detection of command injection which are coming through the deployed web-shell on the “spring4s-ti-app-no-sc” container. The app shows the exploit in detail, such as the file name of the deployed web-shell, “shell.jsp”, and the submitted command, “cat /etc/passwd”.

The Threats & Exploits App not only enables the detection of a command injection attack but also can actively block it.

Sending a web-shell command to the vulnerable application does not work anymore, and the server returns an error code.

Dynatrace’s security offering enables protection against known, but also against unknown vulnerabilities and threats. 

CADR fourth layer of defense: Security Investigator

Investigating if a system was compromised and an exploit was successful is a top priority after a critical vulnerability is discovered. A first go to point is to find indicators of compromise in log files, which Dynatrace ingests and makes searchable through DQL (Dynatrace Query Language).

When it comes to detecting exploits of Spring4Shell, log files of the application or the tomcat server are not reliable sources, since the exploit is based on changing and overwriting the log configuration. Therefore, we leverage distributed trace records and investigate network requests to our deployed test applications. From the Vulnerabilities App, we know exactly which Kubernetes workloads are affected by the Spring4Shell vulnerability, namely “spring4s-ti-app-sc” and “spring4s-ti-app-no-sc” as shown in the screenshot from the Vulnerabilities App below.

Now, we use this information to run a query in the Security Investigator App as shown below to take a closer look at which successful (status code 200) requests were sent to our affected containers. The “spring4s-ti-app-no-sc” container where the exploit was successful had two web-shell files deployed (shell.jsp and tomcatwar.jsp) and received multiple shell commands which are shown in the url.query fields. Some of them, such as cmd=cat%20/etc/passwd, could be of malicious intent.

With the ability to combine the exact location of a vulnerability through the Vulnerabilities App and observing successful requests in the Security Investigator App, we can determine successful exploits of vulnerabilities such as Spring4Shell, independent of indicators that can easily be adjusted by attackers.

We couldn’t identify any successful web-shell requests in the “spring4s-ti-app-sc” container, which was expected since the exploit didn’t work there due to the applied security context as explained above.
In a real-world scenario, we might face a situation where thousands of requests are sent to a container. In such cases, it can be more difficult to identify attacker traffic going to a web-shell. Querying for a summary of files of recently received requests can help to narrow down the detection of suspicious files on a container. This strategy revealed another suspicious file, which could be an indicator of a web-shell.

Also summarizing new url.path endpoints (which have not been seen before) will help to identify suspicious endpoints. We can further leverage information in our queries from the Threats & Exploits App which provides information about blocked or monitored attack requests as we show in the previous section.

This shows only a scratch on the surface of Dynatrace’s abilities to detect and investigate critical exploits in detail. One of our recent blog post about threat detection in cloud native environments demonstrates such an investigation in greater detail.

Conclusion

Dynatrace offers multi-layer detection and defense approach against cloud-native applications. By combining Runtime Vulnerability Analytics, Security Posture Management, Threats & Exploit detection, and the Security Investigator, the Dynatrace platform approach to Cloud Application Detection and Response (CADR) helps detect and mitigate critical vulnerabilities such as Spring4Shell on multiple layers to keep your organization secure.

The post Revisiting Spring4Shell: How Cloud Application Detection and Response (CADR) offers multi-layer protection appeared first on Dynatrace news.

Dynatrace introduces a new way to think about timestamps in your Security Investigator cases. The reference time concept uses relative timestamps to speed up incident response time.

Time is critical

Imagine an engineer performing root cause analysis by analyzing your application logs using Security Investigator. They discover the event in the logs that caused an incident, and as the next step, they want to analyze network flow logs from your Cloud Service Provider (CSP). Since network flow logs don’t contain any meaningful data about the request content or its response, it’s relatively difficult to understand which events in the network flow logs occurred before the incident and which ones followed it.

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

Security Investigator allows you to:

• Keep your whole investigation flow in context.
• Perform complex security investigations on the data stored in Grail.
• Build DQL queries based on your findings in a fast and usable way.
• Save and use found evidence to build your DQL queries and find answers to your questions.
• Navigate with ease to any point in your investigation history and review queries and results.
• Fetch detailed results in the original format to quickly understand the information.

Thanks to reference time, it‘s now possible to add the time perspective to keep track of the relative time between events you’re analyzing and the time that incidents occurred.

You can choose Set as reference time by right-clicking any Security Investigator timestamp field related to an event that caused an incident.

A new virtual column called timestamp_diff is then added to all the query nodes of the query tree. The virtual node contains the time difference between the set reference time and the timestamp of the event in the results table. So, even if you open another query node, you’ll still see the reference time offset field in the results menu displaying the time distance between the event and the set reference time.

The virtual offset column is created automatically for the first timestamp field in the results table (usually called timestamp), but it can be turned on for any timestamp field. You can do this from the column header menu or from the reference time menu.

This small, yet powerful feature allows engineers to speed up investigations and lock down event timestamps for easier navigation across their query results.

With reference time, you can efficiently navigate logs while maintaining an incident’s time context. It helps you track the time offset between events you’re analyzing and when the incident occurred. This allows you to uncover relevant threads and evidence, even from logs and events that might initially seem unrelated.

Reference time integrates diverse information, ensuring a consistent incident context across all data points.

For a more detailed example of how reference time speeds up threat hunting, please see the reference time use case in Dynatrace Documentation.

© 2025 Dynatrace LLC

Dynatrace and the Dynatrace logo, are trademarks of the Dynatrace, Inc. group of companies. All other trademarks are the property of their respective owners.

The post Create context in Security Investigator with reference times appeared first on Dynatrace news.

With the current threat landscape, attackers are often targeting cloud-native environments. The inherent nature of these environments means they are often spun up very quickly and are distributed, leading to monitoring and security challenges. Attackers leverage this fact, which is clearly demonstrated by the increasingly short time to exploit. On top of that, while the increasing use of AI in security can certainly benefit organizations, AI can also lead to an explosion of security findings that can overwhelm security teams. With these considerations, threat detection and runtime visibility are critical to maintaining secure environments.

In this blog, we will look at how teams can use Dynatrace’s capabilities to detect and respond to threats quickly and automatically, improving mean time to respond (MTTR) and efficacy.

Dynatrace Query Language (DQL) enables you to develop detections that uncover active threats in your cloud-native environment. By combining different data sources like logs and runtime context, Dynatrace helps improve threat detection accuracy and create actionable findings.

What would an adversary do?

Before creating a detection, there has to be a threat to protect against. Valuable inputs can be threat intelligence, penetration testing reports, or an insightful blog post, just to name a few.

Let’s take the recent ingress-nginx vulnerability (CVE-2025-1974). By creating a malicious ingress object, an adversary can execute arbitrary code in the context of the ingress-nginx service account. Because the service account has permissions to access all secrets within the entire cluster this was categorized as a critical vulnerability. If a threat actor would successfully exploit such a vulnerability, what would they do next and what would be a good method to detect such suspicious behavior?

Threat detection engineering

A common thing attackers do after establishing a foothold is use their newly gained permissions and look for sensitive data (such as credentials) to further escalate their privileges. In the case of Kubernetes, this can be done by asking the kube-api to return all available secrets and configmaps. This uses the permissions of the compromised pod’s service account.

Since the service account may be allowed to access some of those resources but not all of them, this will inevitably result in responses from the kube-api server signaling the requester (the attacker sitting in one of our pods) access has been denied, including an HTTP status code of 403: “Forbidden”. This should rarely happen in a cluster under normal circumstances and is thus a good starting point for building a detection.

Before we start working on our query, let’s talk about the right tool for the job: Security Investigator. Developing detections is an iterative process. You may have to jump back and forth, search other data sources for relevant information, drill down, zoom out again, etc. When using other tools, you may end up with either a huge list of queries in some form (and needing to copy/paste them all the time) or dozens of browser tabs open with all the different snippets and versions of your query. By using Security Investigator’s query tree, your queries are automatically saved. You can start another branch or go back to a previous version of your query.

Now, back to the adversary and our compromised pod: how can we detect this behavior? By using the ability to search through all the data Dynatrace has about the environment, we can make this indicator visible.

Note: For readability, the query snippets mentioned have been shortened. To get the full query and others, check out the appendix.

fetch logs, 
  from: -15m,
  scanLimitGBytes: -1

| parse content, "JSON{JSON{STRING+:log}(flat=true):properties}(flat=true)",
  parsingPrerequisite: (
    azure.resource.type == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS" and 
    log.source == "kube-audit"
  )
| fieldsAdd content=coalesce(properties, content)
| parse content, "JSON{
  STRING+:kind,
  STRING+:apiVersion,
  STRING+:level,
  STRING+:auditID,
  STRING+:stage,
  STRING+:requestURI,
  STRING:verb,
  JSON:user,
  JSON_ARRAY{ipaddr}(typed=true):sourceIPs,
  STRING+:userAgent,
  JSON:objectRef,
  JSON:responseStatus,
  TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):requestReceivedTimestamp,
  TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):stageTimestamp,
  JSON:annotations
  }(flat=true)"

| filter 
  apiVersion == "audit.k8s.io/v1" and
  startsWith(user[username], "system:serviceaccount:") and
  in(verb, {"list", "get"}) and
  in(objectRef[resource], {"configmaps", "secrets"}) and
  responseStatus[reason] == "Forbidden"

This query fetches all the logs and parses the fields of the Kubernetes audit log. It then filters only on those records, including failed requests by service accounts trying to access configmaps or secrets. I’ve executed the suspicious behavior in my environment and ran this query. Let’s see what we get:

So far, our query is working perfectly. A few things can be observed by looking at the result:

👍 We see the name of the service account acting suspiciously. In our case, we see “unguard-proxy” in a namespace called “unguard”.

👍 We gain additional information about the pod this request originated from, including its name and uid.

👍 We also get the user agent used to execute the requests. In this case, it’s “kubectl”, which is also a bit telling, since it’s a CLI tool mostly used by humans and rarely by service accounts.

👍 Additionally, we get the source IP of the requester, which seems to be a private IP.

👍 Because Dynatrace is enriching the logs automatically with some metadata, we have fields like cloud.account.id, cloud.provider and cloud.region included, as well.

When we encounter such a suspicious event, we may want to know a few additional things to be able to better assess the situation:

🤔 If there are any vulnerabilities affecting this pod. This may lead us to a possible exploitation of one of those vulnerabilities.

🤔 If there are any critical compliance findings affecting this pod. This may tell us, for example, if a pod is running with elevated privileges.

🤔 Pod labels might tell us more about ownership or other relevant metadata.

If this query finds something malicious down the road, we will definitely want to know more about the security-related context of the originating pod (more on that in a future post of this series). In the end, this could lead us directly to a compromised pod, and we want to avoid requesting access to the cluster or cloud environment in the heat of a possible security incident.

Enriching logs with runtime information

By using what we already know about our cloud-native environment (including all the clusters, namespaces, and pods) with Dynatrace, we can enrich the bare Kubernetes audit log with runtime context based on the entity model. To get the pod name and its namespace from the IP address, we could add the following snippet to our query:

// enrich with smartscape data
| join [
    fetch dt.entity.cloud_application_instance, from:-24h
    | fieldsAdd resourceUid
    | fieldsAdd clustered_by
    | fieldsAdd dt.entity.cloud_application = instance_of[dt.entity.cloud_application]
    | fieldsAdd dt.entity.kubernetes_cluster = clustered_by[dt.entity.kubernetes_cluster]
    | fieldsAdd clusterName = entityName(dt.entity.kubernetes_cluster)
    | fieldsAdd cloudApplicationLabels
  ],
  kind: leftOuter,
  on: { left[k8s.pod.uid] == right[resourceUid] },
  fields: {
    k8s.cluster.name = clusterName,
    k8s.namespace.name = namespaceName,
    dt.entity.cloud_application,
    k8s.pod.labels = cloudApplicationLabels
  }

This gives us not only the cluster name of where this activity is happening but also the unique identifier of the pod in the entity model, along with all of its labels. Immediately, we know which team owns the workload and who to contact in the event of a confirmed true positive.

Using the unique entity ID, we can now enrich the event even further with vulnerability data. If the pod we’re looking at is known to be vulnerable, we want to know if it may be affected by a vulnerability that could explain the suspicious behavior of its service account.

// enrich with vulnerability data 
| join [ 
fetch events 
| filter  
  event.kind == "SECURITY_EVENT" and 
  event.category == "VULNERABILITY_MANAGEMENT" and 
  event.type == "VULNERABILITY_STATE_REPORT_EVENT" and 
  event.status == "OPEN"  
| expand related_entities.kubernetes_workloads.id = related_entities.kubernetes_workloads.ids
| summarize {
  vulnerability.risk.level = takeLast(vulnerability.risk.level),
  vulnerability.davis_assessment.exploit_status = takeLast(vulnerability.davis_assessment.exploit_status)
  },
  by: { 
    vulnerability.id,
    related_entities.kubernetes_workloads.id
    }
| summarize { 
  vulnerability.risk.level.high_count = countIf(vulnerability.risk.level == "HIGH"), 
  vulnerability.risk.level.medium_count = countIf(vulnerability.risk.level == "MEDIUM"), 
  vulnerability.risk.level.low_count = countIf(vulnerability.risk.level == "LOW"), 
  vulnerability.davis_assessment.exploit_status = countIf(vulnerability.davis_assessment.exploit_status == "AVAILABLE") 
  }, 
  by: { related_entities.kubernetes_workloads.id }
  ], 
on: {left[dt.entity.cloud_application]==right[related_entities.kubernetes_workloads.id]}, 
fields: { 
  vulnerability.risk.level.high_count, 
  vulnerability.risk.level.medium_count, 
  vulnerability.risk.level.low_count, 
  vulnerability.davis_assessment.exploit_status 
}, 
kind:leftOuter

This gives us additional fields that indicate if there are vulnerabilities affecting the pod based on their severity, as well as the exposure of the vulnerability and if an exploit is available.

Lastly, we may even want to enrich the event with information from Kubernetes security posture management (KSPM) findings:

// enrich with compliance data
| join [
  fetch events, from:-2h
  | filter event.kind == "SECURITY_EVENT"
  | filter event.type == "COMPLIANCE_FINDING"
  | filter compliance.result.object.type == "k8spod"
  | filter compliance.result.status.level == "FAILED"
  | summarize {
      compliance.rule.severity.level = takeLast(compliance.rule.severity.level)
    },
    by: {
      k8s.cluster.name,
      object.name,
      compliance.rule.id
    }

  | summarize {
      compliance.rule.severity.level.high_count = countIf(compliance.rule.severity.level == "HIGH"),
      compliance.rule.severity.level.medium_count = countIf(compliance.rule.severity.level == "MEDIUM"),
      compliance.rule.severity.level.low_count = countIf(compliance.rule.severity.level == "LOW")
  }, 
  by: {
    k8s.cluster.name,
    object.name
  }
], 
on: {
  k8s.cluster.name,
  left[k8s.pod.name]==right[object.name]
}, 
kind:leftOuter,
fields: {
  compliance.rule.severity.level.high_count,
  compliance.rule.severity.level.medium_count,
  compliance.rule.severity.level.low_count
}

Whatever runtime context you like your finding to include, the chances are high that Dynatrace already knows about it. With DQL, Grail, and Smartscape, you’re able to create meaningful high-fidelity alerts to protect your cloud-native environment.

Lastly, we can add some metadata based on MITRE ATT&CK. This will allow us to track some metrics and maybe even create some meta-detections later.

| fieldsAdd mitre.attack.enterprise.tactic.ids = array("TA0006")
| fieldsAdd mitre.attack.enterprise.technique.ids = array("T1552.007")

Adding those two fields tells us in case this event fires, the tactic and the corresponding technique. This results in the following rich event, that allows to establish situational awareness quickly and confidently:

Sample queries

In the appendix, you will find this query and others addressing the following techniques:

• Kubernetes API Permission Enumeration
• Kubernetes Admission Controller Modification
• Kubernetes Events Deletion

Feel free to execute them in your environment and adjust them to your needs as the best queries are the ones that are tightly tuned to the environment they’re running in.

Threat detection with Dynatrace: What’s next

Creating a detection query is one of the first steps to successfully handling a threat, but not the last one. By combining multiple capabilities of the Dynatrace platform, teams can continuously check for signs of an ongoing attack, create a detection finding in case we uncover an active adversary, and provide investigative guidance on how to deal with such a finding after it has been created. Future articles will go into detail about these topics to be able to not only successfully detect malicious activity, but also adequately respond to it.

Appendix

Access Denied for Service Account Accessing Secret(s) or Configmap(s)

fetch logs, 
  from: -15m, 
  to: -5m, 
  scanLimitGBytes: -1

// MS AKS
| parse content, "JSON{JSON{STRING+:log}(flat=true):properties}(flat=true)",
  parsingPrerequisite: (
    azure.resource.type == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS" and 
    log.source == "kube-audit"
  )
| fieldsAdd content=coalesce(properties, content)

| parse content, "JSON{
  STRING+:kind,
  STRING+:apiVersion,
  STRING+:level,
  STRING+:auditID,
  STRING+:stage,
  STRING+:requestURI,
  STRING:verb,
  JSON:user,
  JSON_ARRAY{ipaddr}(typed=true):sourceIPs,
  STRING+:userAgent,
  JSON:objectRef,
  JSON:responseStatus,
  TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):requestReceivedTimestamp,
  TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):stageTimestamp,
  JSON:annotations
  }(flat=true)"

// filter on denied requests of service accounts trying to access configmaps and/or secrets 
| filter 
  apiVersion == "audit.k8s.io/v1" and
  startsWith(user[username], "system:serviceaccount:") and
  in(verb, {"list", "get"}) and
  in(objectRef[resource], {"configmaps", "secrets"}) and
  responseStatus[reason] == "Forbidden"

| fieldsAdd 
  k8s.pod.uid = user[extra][`authentication.kubernetes.io/pod-uid`],
  k8s.pod.name = user[extra][`authentication.kubernetes.io/pod-name`],
  user.name = user[username]

| expand k8s.pod.uid
| expand k8s.pod.name
| expand sourceIP = sourceIPs

// enrich with smartscape data
| join [
    fetch dt.entity.cloud_application_instance, from:-24h
    | fieldsAdd resourceUid
    | fieldsAdd clustered_by
    | fieldsAdd dt.entity.cloud_application = instance_of[dt.entity.cloud_application]
    | fieldsAdd dt.entity.kubernetes_cluster = clustered_by[dt.entity.kubernetes_cluster]
    | fieldsAdd clusterName = entityName(dt.entity.kubernetes_cluster)
  ],
  kind: leftOuter,
  on: { left[k8s.pod.uid] == right[resourceUid] },
  fields: {
    k8s.cluster.name = clusterName,
    k8s.namespace.name = namespaceName,
    dt.entity.cloud_application
  }

// enrich with vulnerability data 
| join [ 
fetch events 
| filter  
  event.kind == "SECURITY_EVENT" and 
  event.category == "VULNERABILITY_MANAGEMENT" and 
  event.type == "VULNERABILITY_STATE_REPORT_EVENT" and 
  event.status == "OPEN"  
| expand related_entities.kubernetes_workloads.id = related_entities.kubernetes_workloads.ids
| summarize {
  vulnerability.risk.level = takeLast(vulnerability.risk.level),
  vulnerability.davis_assessment.exploit_status = takeLast(vulnerability.davis_assessment.exploit_status)
  },
  by: { 
    vulnerability.id,
    related_entities.kubernetes_workloads.id
    }
| summarize { 
  vulnerability.risk.level.high_count = countIf(vulnerability.risk.level == "HIGH"), 
  vulnerability.risk.level.medium_count = countIf(vulnerability.risk.level == "MEDIUM"), 
  vulnerability.risk.level.low_count = countIf(vulnerability.risk.level == "LOW"), 
  vulnerability.davis_assessment.exploit_status = countIf(vulnerability.davis_assessment.exploit_status == "AVAILABLE") 
  }, 
  by: { related_entities.kubernetes_workloads.id }
  ], 
on: {left[dt.entity.cloud_application]==right[related_entities.kubernetes_workloads.id]}, 
fields: { 
  vulnerability.risk.level.high_count, 
  vulnerability.risk.level.medium_count, 
  vulnerability.risk.level.low_count, 
  vulnerability.davis_assessment.exploit_status 
}, 
kind:leftOuter

// enrich with compliance data
| join [
  fetch events, from:-1h
  | filter event.kind == "SECURITY_EVENT"
  | filter event.type == "COMPLIANCE_FINDING"
  | filter compliance.result.object.type == "k8spod"
  | filter compliance.result.status.level == "FAILED"
  | summarize {
      compliance.rule.severity.level = takeLast(compliance.rule.severity.level)
    },
    by: {
      k8s.cluster.name,
      object.name,
      compliance.rule.id
    }
  
  | summarize {
      compliance.rule.severity.level.high_count = countIf(compliance.rule.severity.level == "HIGH"),
      compliance.rule.severity.level.medium_count = countIf(compliance.rule.severity.level == "MEDIUM"),
      compliance.rule.severity.level.low_count = countIf(compliance.rule.severity.level == "LOW")
  }, 
  by: {
    k8s.cluster.name,
    object.name
  }
], 
on: {
  k8s.cluster.name,
  left[k8s.pod.name]==right[object.name]
}, 
kind:leftOuter,
fields: {
  compliance.rule.severity.level.high_count,
  compliance.rule.severity.level.medium_count,
  compliance.rule.severity.level.low_count
}

| fieldsAdd mitre.attack.enterprise.tactic.id = array("TA0006")
| fieldsAdd mitre.attack.enterprise.technique.id = array("T1552.007")

Kubernetes API Permission Enumeration

fetch logs, 
  from: -15m, 
  to: -5m, 
  scanLimitGBytes: -1

// MS AKS
| parse content, "JSON{JSON{STRING+:log}(flat=true):properties}(flat=true)",
  parsingPrerequisite: (
    azure.resource.type == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS" and 
    log.source == "kube-audit")
| fieldsAdd content=coalesce(properties, content)

| parse content, "JSON{
    STRING+:kind,
    STRING+:apiVersion,
    STRING+:level,
    STRING+:auditID,
    STRING+:stage,
    STRING+:requestURI,
    STRING:verb,
    JSON:user,
    JSON_ARRAY{ipaddr}(typed=true):sourceIPs,
    STRING+:userAgent,
    JSON:objectRef,
    JSON:responseStatus,
    TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):requestReceivedTimestamp,
    TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):stageTimestamp,
    JSON:annotations
  }(flat=true)"
| filter 
  apiVersion == "audit.k8s.io/v1" and 
  verb == "create" and
  in (objectRef[resource], {"selfsubjectrulesreviews", "selfsubjectaccessreviews"}) and
  objectRef[apiGroup] == "authorization.k8s.io" and
  startsWith(user[username], "system:serviceaccount:")
  
| fieldsAdd 
  k8s.pod.uid = user[extra][`authentication.kubernetes.io/pod-uid`],
  k8s.pod.name = user[extra][`authentication.kubernetes.io/pod-name`],
  user.name = user[username]

| expand k8s.pod.uid
| expand k8s.pod.name
| expand sourceIP = sourceIPs

// enrich with smartscape data
| join [
    fetch dt.entity.cloud_application_instance, from:-24h
    | fieldsAdd resourceUid
    | fieldsAdd clustered_by
    | fieldsAdd dt.entity.cloud_application = instance_of[dt.entity.cloud_application]
    | fieldsAdd dt.entity.kubernetes_cluster = clustered_by[dt.entity.kubernetes_cluster]
    | fieldsAdd clusterName = entityName(dt.entity.kubernetes_cluster)
  ],
  kind: leftOuter,
  on: { left[k8s.pod.uid] == right[resourceUid] },
  fields: {
    k8s.cluster.name = clusterName,
    k8s.namespace.name = namespaceName,
    dt.entity.cloud_application
  }

// enrich with vulnerability data 
| join [ 
fetch events 
| filter  
  event.kind == "SECURITY_EVENT" and 
  event.category == "VULNERABILITY_MANAGEMENT" and 
  event.type == "VULNERABILITY_STATE_REPORT_EVENT" and 
  event.status == "OPEN"  
| expand related_entities.kubernetes_workloads.id = related_entities.kubernetes_workloads.ids
| summarize {
  vulnerability.risk.level = takeLast(vulnerability.risk.level),
  vulnerability.davis_assessment.exploit_status = takeLast(vulnerability.davis_assessment.exploit_status)
  },
  by: { 
    vulnerability.id,
    related_entities.kubernetes_workloads.id
    }
| summarize { 
  vulnerability.risk.level.high_count = countIf(vulnerability.risk.level == "HIGH"), 
  vulnerability.risk.level.medium_count = countIf(vulnerability.risk.level == "MEDIUM"), 
  vulnerability.risk.level.low_count = countIf(vulnerability.risk.level == "LOW"), 
  vulnerability.davis_assessment.exploit_status = countIf(vulnerability.davis_assessment.exploit_status == "AVAILABLE") 
  }, 
  by: { related_entities.kubernetes_workloads.id }
  ], 
on: {left[dt.entity.cloud_application]==right[related_entities.kubernetes_workloads.id]}, 
fields: { 
  vulnerability.risk.level.high_count, 
  vulnerability.risk.level.medium_count, 
  vulnerability.risk.level.low_count, 
  vulnerability.davis_assessment.exploit_status 
}, 
kind:leftOuter

// enrich with compliance data
| join [
  fetch events, from:-20m
  | filter event.kind == "SECURITY_EVENT"
  | filter event.type == "COMPLIANCE_FINDING"
  | filter compliance.result.object.type == "k8spod"
  | filter compliance.result.status.level == "FAILED"
  | sort timestamp desc
  | summarize {
      compliance.rule.severity.level = takeFirst(compliance.rule.severity.level)
    },
    by: {
      k8s.cluster.name,
      object.name,
      compliance.rule.id
    }
  
  | summarize {
      compliance.rule.severity.level.high_count = countIf(compliance.rule.severity.level == "HIGH"),
      compliance.rule.severity.level.medium_count = countIf(compliance.rule.severity.level == "MEDIUM"),
      compliance.rule.severity.level.low_count = countIf(compliance.rule.severity.level == "LOW")
  }, 
  by: {
    k8s.cluster.name,
    object.name
  }
], 
on: {
  k8s.cluster.name,
  left[k8s.pod.name]==right[object.name]
}, 
kind:leftOuter,
fields: {
  compliance.rule.severity.level.high_count,
  compliance.rule.severity.level.medium_count,
  compliance.rule.severity.level.low_count
}

| fieldsAdd mitre.attack.enterprise.tactic.id = "TA0007"
| fieldsAdd mitre.attack.enterprise.technique.id = "T1069"

Kubernetes Admission Controller Modification

fetch logs, 
  from: -15m, 
  to: -5m, 
  scanLimitGBytes: -1

// MS AKS
| parse content, "JSON{JSON{STRING+:log}(flat=true):properties}(flat=true)",
  parsingPrerequisite: (
    azure.resource.type == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS" and 
    log.source == "kube-audit")
| fieldsAdd content=coalesce(properties, content)

| parse content, "JSON{
    STRING+:kind,
    STRING+:apiVersion,
    STRING+:level,
    STRING+:auditID,
    STRING+:stage,
    STRING+:requestURI,
    STRING:verb,
    JSON:user,
    JSON_ARRAY{ipaddr}(typed=true):sourceIPs,
    STRING+:userAgent,
    JSON:objectRef,
    JSON:responseStatus,
    TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):requestReceivedTimestamp,
    TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):stageTimestamp,
    JSON:annotations
  }(flat=true)"

| filter
    apiVersion == "audit.k8s.io/v1" and
    objectRef[apiGroup] == "admissionregistration.k8s.io" and
    in(objectRef[resource], { "mutatingwebhookconfigurations", "validatingwebhookconfigurations" }) and
    in(verb, { "create", "patch", "replace", "update" })

| fieldsAdd mitre.attack.enterprise.tactic.ids = array("TA0003", "TA0004")
| fieldsAdd mitre.attack.enterprise.technique.ids = array("T1078", "T1552", "T1552.007")

Kubernetes Events Deleted

fetch logs, 
  from: -15m, 
  to: -5m, 
  scanLimitGBytes: -1

// MS AKS
| parse content, "JSON{JSON{STRING+:log}(flat=true):properties}(flat=true)",
  parsingPrerequisite: (
    azure.resource.type == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS" and 
    log.source == "kube-audit")
| fieldsAdd content=coalesce(properties, content)

| parse content, "JSON{
    STRING+:kind,
    STRING+:apiVersion,
    STRING+:level,
    STRING+:auditID,
    STRING+:stage,
    STRING+:requestURI,
    STRING:verb,
    JSON:user,
    JSON_ARRAY{ipaddr}(typed=true):sourceIPs,
    STRING+:userAgent,
    JSON:objectRef,
    JSON:responseStatus,
    TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):requestReceivedTimestamp,
    TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):stageTimestamp,
    JSON:annotations
  }(flat=true)"

// filter for deleted events
| filter
    apiVersion == "audit.k8s.io/v1" and
    objectRef[resource] == "events" and
    verb == "delete"

| fieldsAdd mitre.attack.enterprise.tactic.id = "TA0005"
| fieldsAdd mitre.attack.enterprise.technique.id = "T1070"

The post Threat detection in cloud native environments: Detecting suspicious Kubernetes service account behavior appeared first on Dynatrace news.

“The best defense is a good offense.” With the threat surfaces of modern IT environments always expanding, taking the initiative can be the most effective way to protect your business rather than passively waiting to react to a threat or attack.

Technical leaders bear the ultimate responsibility for the security outcomes of increasingly complex tech stacks. Breaches risk financial loss and reputational damage. But it’s IT teams who face the daily challenge of securing these dynamic environments and meeting compliance and performance requirements. Teams also need room to innovate and adopt new tools that address evolving organizational needs.

Balancing these competing demands is no small task. Decision-makers must accommodate flexibility and creativity while maintaining a foundation of security and stability. They must also consider business imperatives, including cost management and sustainability goals, all without compromising the quality of technology services.

As a leader, how can you get ahead of these challenges, and what capabilities do you need to strike the right balance? Unifying observability signals and context with security capabilities is a crucial advantage for teams that must simultaneously deliver security, performance, compliance, and business objectives.

Key takeaways:

• Organizations must balance IT security, performance, and business needs. Understand the challenges of balancing security outcomes with performance and business needs.
• Teams need flexible and secure environments and methods. IT environments and operating methods must simultaneously provide flexibility, stability, and security.
• Converging observability with security enables flexibility and operational stability. Adopting a unified observability approach with application-layer context can operationalize security within platform engineering, SRE frameworks, and CI/CD pipelines so vulnerabilities aren’t passed to production environments.
• Observability for security detection and remediation delivers real-world results. Recent critical security vulnerabilities demonstrate how this observability approach to security helps teams mitigate risk.

Why balancing security and performance with business goals is challenging

Modern tech stacks consist of a myriad services that address specific needs at every stage. But these services, which span hybrid and multi-cloud environments, also introduce ever-expanding attack surfaces. While microservices, container orchestration, and broader DevSecOps practices have transformed software delivery, they also present some very real challenges.

• Security complexity. More services from increasing vendors and open-source projects also expand the attack surface through vulnerabilities and attack vectors. And it’s not just external attackers; misconfigurations, siloed tools and teams, and outdated processes amplify the risk.
• Performance expectations. Organizations must deliver fast, reliable, and scalable systems to meet user needs. Securing these systems without undermining speed and responsiveness requires an integrated approach.
• Regulatory compliance demands. Businesses must also keep up with stringent regulations involving data storage, processing, and access. These requirements are constantly evolving, making compliance an ongoing challenge.
• Cost and sustainability pressures. As organizations expand their cloud computing and generative AI tools, they must also mind expanding costs and carbon footprints.

Balancing these priorities demands a leadership mindset that simultaneously helps teams innovate while assisting the organization in meeting its performance, compliance, and cost obligations. Striking this balance also requires some key capabilities.

Key capabilities for building a flexible, secure, and stable environment

The challenge for technical leaders comes down to this question: How do you offer your teams the tools and freedoms they need to be creative while maintaining the guardrails that protect applications and stabilize operations?

The answer lies in creating an operating environment that integrates security, performance, and compliance capabilities at every layer.

Full-stack observability

Comprehensive observability of every layer—from infrastructure to user experience—is vital for identifying IT and security risks, optimizing performance, and providing context to link IT with business goals.

Application security

Observability facilitates runtime vulnerability analytics and application protection so teams can monitor vulnerabilities in real time, catch anomalies early, and safeguard against threats. Teams must operationalize those security findings so developers who need to fix them know exactly what to do and which security finding to focus on. Prioritizing context-based risk by combining observability and security is the best way to close the door to exploits, which represent the number one entry point (38%) for successful intrusions.

Security posture management for Kubernetes and cloud environments

Effective security management of cloud and Kubernetes environments includes assessing misconfigurations and practices that don’t meet regulatory compliance standards and security guidelines. As with vulnerabilities, SREs need awareness of these configuration issues and ideally have a system that can automatically generate the code fix for the configuration-as-code files they work with daily. Automating remediation decreases uncertainty about what to do and drastically reduces time spent on determining the fix.

Observability for developers

Developers need tools that help them understand how code behaves in production, enabling them to integrate security into the development lifecycle.

Platform engineering and site reliability engineering (SRE)

Strong platform engineering and SRE practices can standardize workflows, simplify toolsets, and meet reliability targets while giving teams the autonomy to build innovative solutions.

Carbon footprint monitoring

Sustainability has become a top concern for many organizations. Teams need tools that provide visibility into the environmental impact of workloads to help reduce emissions.

Compliance automation

Regulatory compliance is increasingly important for organizations in just about every region of the world. Automated compliance solutions help teams meet fast-changing regulatory requirements and reporting timelines while minimizing manual overhead.

These capabilities, delivered through an integrated AI-based platform, create an operating environment that fosters both innovation and security.

How unified observability delivers security advantages

End-to-end observability in context with performance metrics, user experience, and business metrics, offers a unique benefit to an organization’s security posture management. By integrating data from all channels on a single platform using automatic and customizable instrumentation, teams have access to the data they need to act quickly and confidently.

With comprehensive observability in context, developers and SREs can quickly identify exposed vulnerabilities. Likewise, security teams can immediately pinpoint threats so they can focus on what matters most.

• Exploitation awareness. Evaluate vulnerabilities based on whether they expose critical assets or are subject to active exploits.
• Real-world context. Implement a system that can continuously collect data and automatically prioritize risk based on context, which vastly reduces the need for time-consuming manual risk assessments and priority evaluations.
• Streamlined prioritization. Reduce noise and false positives by assessing threats based on their real impact on your environment, not just abstract risk scores.

Integrated security and performance in practice: Learning from recent critical vulnerabilities

Vulnerabilities—and the exploits that follow them—are a fact of life. A few recent examples demonstrate how an observability platform approach to security can mean the difference between real harm with a long recovery or nipping a zero-day vulnerability in the bud with little or no downtime.

VMware VMSA-2025-0004

The VMSA-2025-0004 advisory consists of three Common Vulnerabilities and Exposures (CVEs) that represent unique risks to virtualized and containerized environments. With specialized virtualization security posture management (VSPM) capabilities, teams can quickly detect the VMSA-2025-0004 vulnerabilities and automate remediation.

NGINX IngressNightmare

The IngressNightmare cluster of vulnerabilities affect the mechanisms that allow external traffic to access services within a Kubernetes cluster. By exploiting a chain of multiple flaws, an attacker can use remote code execution (RCE) to upload and execute a file and inject arbitrary code to take over the whole cluster. With access to full Kubernetes logs, metrics, and trace data in a causal data lakehouse, teams can detect vulnerable instances and surface signs of compromise for quick remediation.

Apache Struts 2 CVE-2024-53677

The Apache Struts 2 vulnerability affected the widely used Java framework for web applications, Apache Struts 2. Also an RCE vulnerability, CVE-2024-53677 allowed attackers to manipulate file upload parameters, leading to unauthorized file placement. Understanding the mechanics of the file upload systems helped teams find the signatures of these exploits using data lakehouse queries and Runtime Vulnerability Analytics to detect the active use of the vulnerable method within their applications.

CrowdStrike update crisis

Sometimes risk to systems comes in the form of a faulty software update, such as the CrowdStrike “blue screen of death” incident from 2024 that affected Windows servers. With full-stack monitoring and topology mapping, out-of-the-box dashboards, synthetic monitoring, data lakehouse querying, collaborative notebooks, real-user monitoring, and service-level objectives to help prioritize remediation, teams were able to recover in hours.

Log4Shell

In 2021, the Log4Shell vulnerability exposed applications to RCE exploits through its error logging functions. In this scenario, an attacker could direct the logging function to request an infected resource, then download and execute it, causing system damage or data compromise. To quickly find affected systems and mitigate exposure, teams needed to automatically identify all vulnerable applications and the data systems they depend on and prioritize those that are exposed to the internet.

With observability to reveal details of affected systems, a data lakehouse for preserving all data in context, and analysis tools to discover details and threat signatures, organizations were able to quickly prioritize remediation, often avoiding downtime altogether.

Balancing security and performance with the business

In today’s business environment, leaders need to give their teams every advantage to anticipate rapid change and emerging threats. Unifying observability and security with a single AI-driven platform delivers those advantages so organizations can balance performance and security with the compliance, cost, and sustainability goals of the business.

The post Balancing security and performance with business goals through observability appeared first on Dynatrace news.

Among the myriad options in today’s cloud security landscape, three key solutions stand out: Cloud-Native Application Protection Platform (CNAPP), Cloud Security Posture Management (CSPM), and Kubernetes Security Posture Management (KSPM). Each offers unique features and benefits, but how do they compare, and which IT security solution is right for your organization?

Since 2020, usage of cloud services has more than doubled, and growth is expected to accelerate. Per the 2024 Gartner® Market Guide for Cloud-Native Application Protection Platforms report, “By 2029, 35% of all enterprise applications will run in containers, an increase from less than 15% in 2023.”[1] As modern enterprises adopt cloud technologies over time, they often end up with a heterogeneous mix of fragmented security products managed by siloed teams, resulting in complexity, a broadened attack surface, and a plethora of unanswered security questions. Organizations are now looking into solutions that unify security capabilities to protect their environments efficiently.

In this article, we’ll dive deep into CSPM, KSPM, and CNAPP, exploring their core functionalities and use cases while providing guidance on which tool may be right for your organization.

Key takeaways: How do CSPM, KSPM, and CNAPP compare?

What is Cloud Security Posture Management?

CSPM solutions continuously monitor and improve the security posture of Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) environments. They detect misconfigurations, support compliance, and automate risk remediation.

Key CSPM features

• Continuous monitoring: Keeps an eye on cloud resources to detect misconfigurations and potential security issues.
• Security posture reporting: Generated to assess cloud configuration compliance with industry standards and regulations; these reports are subsequently reviewed and analyzed by personnel to evaluate the organization’s overall compliance posture and can be used as a foundation for automated remediation.
• Risk detection and assessment: Identifies and responds to security threats in real time. Also evaluates the potential impact of security risks.
• Automated remediation: Provides automated solutions or workflows to help fix identified security issues based on best practices and compliance recommendations.
• Integrations: Can work across multi-cloud and hybrid-cloud environments, such as AWS, Azure, and Google Cloud Platform, and provide unified visibility and management.

CSPM use cases

• Identifying misconfigurations: Continuously scanning cloud environments to detect misconfigurations (such as open network ports, missing security patches, and exposed storage buckets) to help maintain a secure, stable infrastructure.
• Incident response: Providing capabilities for incident response, including remediation suggestions and integration with DevOps workflows, to help resolve security incidents quickly and efficiently.
• Compliance monitoring: Support cloud configurations in their compliance with industry standards and regulations to help the organization avoid misconfigurations that could lead to compliance violations and potential security gaps.
• Threat detection: Proactively detecting security threats across multiple cloud environments to enable real-time threat response and reduce potential damage.
• Shadow IT detection: Identifying unauthorized cloud services and applications to reduce the risk of systems deployed outside of organizational policies and support cloud resource management and security.
• Risk prioritization: Prioritizing risks based on their severity to allow SREs to address critical vulnerabilities first and help support efforts to maintain a secure environment.
• Monitoring and reporting: Providing audit-ready reports and continuous cloud resources monitoring to ongoing security and compliance and keep SREs up to date on security posture.

Is CSPM right for my organization?

CSPM is valuable in hybrid or multicloud environments. Because these environments make manual maintenance and visibility into configurations difficult to maintain, security misconfigurations are more likely to arise and lead to breaches. CSPM might also be right for your organization if your industry follows standards such as CIS, NIST, PCI DSS, HIPAA, GDPR, and others, as it helps continuously support adherence to these standards.

If your organization lacks security expertise, CSPM solutions often provide risk assessment and guided remediation, which can help when dedicated experts are missing. CSPM can also help you find unused or misconfigured resources, which can help you optimize cloud costs efficiently.

However, if you only use minimal cloud services, your cloud environment is static, or you rely on on-premises infrastructure, CSPM may not be worth buying yet.

What is Kubernetes Security Posture Management?

Kubernetes Security Posture Management (KSPM) consists of solutions and processes that continuously manage the security posture of Kubernetes workloads and clusters through prevention, detection, and response to risks within the Kubernetes environment. The core of KSPM applies common frameworks, regulatory requirements (as applicable), and enterprise policies to proactively discover and assess the risk and trust levels of Kubernetes configurations and security settings. If an issue is identified, it provides automated or human-driven remediation options for fixes.

Key KSPM features

• Configuration management: Assists in maintaining secure Kubernetes clusters.
• Policy enforcement and control: Applies security policies across clusters and controls how the rules are being followed.
• Vulnerability scanning: Identifies and mitigates vulnerabilities in Kubernetes components.
• Compliance reporting: Provides audit-ready reports on compliance with security standards.

KSPM use cases

• Security and compliance automation in CI/CD pipelines: Enabling DevOps and platform engineering teams to catch Kubernetes misconfigurations before deployment.
• RBAC and identity management auditing: Helping SREs and platform engineers increase visibility into Kubernetes RBAC to prevent excessive permissions. KSPM detects overly permissive service accounts, misconfigured roles, and potential privilege escalation risks. These least-privilege principles are fundamental when meeting the requirements of standards including SOC2 or NIST.
• Kubernetes misconfiguration detection and remediation automation: Continuously scanning clusters and providing remediation steps or workflows for automated fixes.
• Kubernetes compliance and governance: Assisting organizations in highly regulated industries that must enforce compliance policies across multiple clusters and generate audit-ready reports.
• Multi-cluster visibility and security: Providing platform engineers with centralized security monitoring to provide unified security insights across EKS, AKS, GKE, and on-prem clusters.

Is KSPM right for my organization?

The main prerequisite for KSPM is running Kubernetes in production. If you’re using native Kubernetes, or K8s in AWS EKS, Azure AKS, Google GKE, or on-prem (e.g. OpenShift, Rancher), KSPM can help secure workloads, clusters, and configurations. Or, if you manage multiple clusters, namespaces, and microservices with frequent deployments, solutions like KSPM can automate misconfiguration detection and help with policy enforcement: a critical capability for organizations in highly regulated industries.

If you’re running Infrastructure as Code and deploying using Helm, Kustomize, Terraform, or AgroCD, KSPM can help assess security policy adherence before deployment. For those concerned about RBAC & identity management, KSPM can help detect overly permissive roles, improper API access, and privilege escalation risks.

If you’re looking for runtime protection alongside posture management, some KSPM tools offer integrations with CSPM for end-to-end security, including container runtime threat detection.

KSPM is not worth it if you’re not using Kubernetes, but rather traditional VMs, bare metal, or serverless without Kubernetes. If you’re only experimenting with Kubernetes, running small-scale or development-only clusters, KSPM might not yet justify the cost. Another case might be if you deploy workloads infrequently and don’t change configurations often. For static Kubernetes environments, a one-time audit may be enough.

What is a Cloud-Native Application Protection Platform?

CNAPP is a comprehensive security solution combining CSPM, KSPM, and runtime security. It provides end-to-end protections for applications across multi-cloud and containerized environments.

An effective CNAPP provides a single view into the organization’s biggest risks and helps security teams collaborate more effectively with developers and IT operations so they can tackle and optimize security and compliance throughout the application development lifecycle and minimize friction.

Key CNAPP features

A cloud-native application protection platform typically includes the following capabilities:

• Cloud security posture management (CSPM)
• Kubernetes security posture management (KSPM)
• Cloud workload protection (CWPP)
• Cloud infrastructure entitlement management (CIEM)
• CI/CD security and container scanning

A CNAPP integrates multiple cloud security capabilities into a single platform to provide the following capabilities:

• Unified security visibility: Integrates CSPM and KSPM insights in a single platform.
• Workload protection: Secures containers, VMs, and serverless functions.
• Runtime threat detection: Uses behavioral analytics to identify attacks in real time.
• Shift-left security: Embeds security into the development pipeline to prevent vulnerabilities early.

CNAPP use cases

• Reducing tool sprawl: Improving efficiency with an integrated cloud security approach.
• Protecting applications from development to runtime: Embedding security checks and automated remediation across the software development lifecycle.
• Enhancing security for multi-cloud and hybrid environments: Closing visibility gaps to help proactively identify and address issues.

SREs and platform engineers can use CNAPP to support reliability and compliance. Security teams can use it for threat detection and governance. DevOps teams can use it to embed security practices efficiently into development workflows. But most importantly, CNAPP provides a single source of truth across all these teams. This helps promote alignment and acting on security risks quickly.

Is a CNAPP right for my organization?

CNAPP is highly valuable for organizations with dynamic, cloud-native environments that leverage Kubernetes, serverless computing, and containerized workloads. It provides insights and security protections by combining CSPM, CWPP, CIEM, and runtime protection, ensuring comprehensive visibility and threat detection across multi-cloud infrastructures. CNAPP can integrate with DevSecOps workflows and CI/CD pipelines to prevent misconfigurations and vulnerabilities before deployment.

Additionally, its runtime security and anomaly detection enhance real-time threat response, making it ideal for businesses that require advanced cloud security and have significant compliance obligations (e.g. PCI DSS, HIPAA, NIST, or SOC2).

However, CNAPP may be overkill for organizations with static workloads running on traditional VMs or basic cloud resources, that don’t require Kubernetes security or advanced runtime monitoring. If an organization has minimal DevSecOps integration and no CI/CD automation, standalone tools can serve basic security needs.

Ultimately, CNAPP is worth it for enterprises with large-scale, multi-cloud architectures, strict compliance needs, and dynamic, ephemeral workloads that require proactive risk mitigation. But for smaller teams with simpler infrastructure, limited security requirements, or cost constraints, a mix of CSPM, SIEM, and lightweight DevSecOps tools may be a more practical alternative.

Choosing the right solution

Use this flow chart to help determine whether CSPM, KSPM, or CNAPP is the best fit for your organization’s security needs.

[1] Gartner, Market Guide for Cloud-Native Application Protection Platforms, Dale Koeppen, Charlie Winckless, et al., 22 July 2024. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

The post Which IT security solution is right for your organization? CSPM vs. KSPM vs. CNAPP appeared first on Dynatrace news.

A critical security threat for cloud-native architectures

SSRF is a web security vulnerability that allows an attacker to make a server-side application send requests to unintended locations. This can include internal services within an organization’s infrastructure or external systems. SSRF can lead to unauthorized access to sensitive data, such as cloud metadata, internal databases, and other protected resources. Attackers can exploit SSRF to bypass firewalls, steal credentials, and execute arbitrary commands.

SSRF attacks remain a critical security threat, with real-world breaches exposing sensitive internal resources and cloud metadata services. As more organizations adopt cloud-native architectures, the risk of SSRF grows. Due to its dynamic nature, static analysis (SAST) tools are often less accurate in correctly detecting SSRF, and Web Application Firewalls (WAFs) struggle to block sophisticated attacks that exploit legitimate application behavior. Notable breaches, such as the Capital One data breach, have demonstrated the severe impact of SSRF, where attackers exploited an SSRF vulnerability to access AWS metadata and gain privileged access.

Security teams need a runtime-aware, contextual solution that detects SSRF in real time and provides actionable remediation without introducing false positives or developer friction.

Real-time, runtime-aware security for Java applications

Dynatrace Java SSRF protection brings real-time, runtime-aware security to Java applications, preventing unauthorized outbound requests before they reach internal systems or third-party services. Unlike traditional solutions, the Dynatrace approach leverages deep application insight, identifies tainted data flows leading to SSRF risks, and stops them before they can be exploited. This runtime-aware, contextual solution understands the application’s behavior and data flows in real time, allowing for precise detection and immediate response to SSRF attempts. This reduces the risk of false positives and ensures that legitimate application functionality is not disrupted.

Java remains one of the most popular programming languages globally, and it is used by major companies worldwide for everything from web and Android apps to server-side programming and large-scale enterprise systems. A strong ecosystem and community support the ongoing popularity of Java. Protecting Java applications is crucial due to their widespread use and the significant impact SSRF vulnerabilities can have on these systems.

The new Dynatrace capability integrates seamlessly into existing Java applications, providing continuous monitoring, detection, and protection—without requiring custom rules, code modifications, or additional network filtering.

Start protecting your critical applications

If you’re already a Dynatrace Application Security customer using Dynatrace Runtime Vulnerability Analytics (RVA) or Runtime Application Protection (RAP), visit Dynatrace Documentation to get started detecting SSRF vulnerabilities in your applications and protecting them against exploitation.

If you’re not a Dynatrace Application Security customer, contact us for a demo or check it out at Dynatrace Playground.

_{Dynatrace and the Dynatrace logo are trademarks of the Dynatrace, Inc. group of companies. All other trademarks are the property of their respective owners.}

The post Announcing Java SSRF protection in Dynatrace Application Security appeared first on Dynatrace news.