GitHub ties alerts to runtime context

# GitHub ties alerts to runtime context Most security teams do not have a shortage of alerts. They have a shortage of useful ranking. A modern software stack can generate warnings from dependency scanners, code scanners, secret detectors, cloud tools, and runtime monitors all at once. The hard part is not finding another issue. The hard part is deciding which issue deserves attention first. That is the problem GitHub is trying to narrow with a new integration announced on April 7, 2026. GitHub said teams can now use runtime context from Dynatrace to prioritize GitHub Advanced Security alerts based on deployed artifacts and runtime risk in Kubernetes environments. (github.blog) To understand why that matters, it helps to separate two different kinds of security information. The first kind is static information. A scanner looks at source code, dependencies, container images, or configuration files and reports what might be vulnerable. That produces a long list of possible problems, but it does not always say whether the affected component is actually running in production. The second kind is runtime information. That is the live context around software after it has been deployed: which container image is active, which workload is exposed, which service is handling traffic, and what risk signals are attached to that running system. Dynatrace describes its role here as observing the runtime entities associated with development artifacts and enriching GitHub Advanced Security findings with that context. (docs.dynatrace.com) (dynatrace.com) That distinction changes how a team triages work. A vulnerability in a package that exists only in a test branch is usually a different priority from the same vulnerability in a container image that is deployed to a production cluster and exposed to real traffic. GitHub has already been building toward this model. Its documentation describes “production context” as metadata that lets teams filter and prioritize Dependabot and code scanning alerts tied to artifacts approved for production environments. GitHub says this metadata powers filters such as whether an alert has a deployment and what runtime risk is associated with it. (docs.github.com 1) (docs.github.com 2) The Dynatrace announcement turns that framework into a more direct workflow. When Dynatrace is connected to GitHub, GitHub says users will see deployment context for container images that Dynatrace maps to repositories, along with runtime risk signals. In plain terms, the alert list starts to reflect not just what is theoretically vulnerable, but what is actually deployed and risky right now. (github.blog) That is a meaningful shift away from the old habit of sorting mostly by raw alert count or by Common Vulnerability Scoring System severity alone. Common Vulnerability Scoring System scores estimate technical severity, but they do not tell a team whether the vulnerable code is sitting unused in a dormant image or running in a critical production service. The new GitHub-Dynatrace link adds that missing operational layer. (github.blog) (docs.github.com) GitHub’s own wording is careful. The company is not claiming that runtime context replaces code scanning or dependency analysis. It is saying that runtime context helps prioritize the resulting alerts. That means the basic security pipeline still matters: scanners still find issues, but ranking becomes more grounded in real deployment data. (github.blog) Dynatrace has been pushing this code-to-runtime connection for months. In earlier material, the company said its GitHub Advanced Security integration could ingest, visualize, prioritize, and automate vulnerability findings by enriching them with runtime context. The new GitHub-side announcement suggests that this approach is moving from partner workflow into GitHub’s own alert-prioritization surface. (dynatrace.com) (github.blog) The immediate use case is Kubernetes. GitHub’s announcement specifically mentions deployed artifacts and runtime risk in Kubernetes environments. That focus makes sense because Kubernetes systems often run many short-lived containers across many services, which makes it easy for security findings to pile up faster than humans can sort them. (github.blog) There is also a broader industry pattern here. Microsoft has been making a similar argument in its GitHub Advanced Security integration with Microsoft Defender for Cloud, saying code repositories can be linked to cloud workloads so alerts can be prioritized using real runtime context. Different vendors are using different plumbing, but the shared idea is the same: security tools are trying to connect code findings to live systems instead of leaving them in separate dashboards. (learn.microsoft.com) For developers, the practical effect is less abstract than it sounds. If two alerts have the same severity score, but only one is tied to a container image that is deployed in production and carrying runtime risk signals, that one can move to the top of the queue. If a third alert is attached to code that is not deployed anywhere, it can wait. For security leaders, this is really a workflow story. Teams have spent years improving detection, yet many still struggle with remediation speed because the alert stream is too noisy. Runtime-aware prioritization is an attempt to cut that noise by attaching each finding to the question engineers actually care about: where is this running, and how exposed is it? (techcommunity.microsoft.com) (docs.dynatrace.com) GitHub’s announcement is small in size, but it points to a larger redesign of vulnerability management. The center of gravity is moving away from “how bad does the scanner say this is?” toward “is this artifact deployed, and what does the running environment say about the risk?” (github.blog) (docs.github.com) That does not eliminate backlog. It changes which backlog gets worked first.