Prioritize GitHub Advanced Security alerts with runtime context from Dynatrace

Dynatrace extends its integration with GitHub Advanced Security to share the runtime context of your monitored Kubernetes environment with developers and security teams, enabling improved prioritization, automation, and remediation of security alerts across your code and third-party dependencies.

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.

GitHub security findings dashboard in Dynatrace

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.

High-level architecture diagram of the Dynatrace GitHub Advanced Security integration

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).

A sample filter of Dependabot alerts on the organizational level, focusing only on the vulnerabilities of deployed images with internet exposure: has:deployment AND runtime-risk:internet-exposed

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.

Using the integration, Dynatrace shares the runtime context of a running container with GitHub. (video)

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.