Prioritizing Dependabot and code scanning alerts using production context

Focus remediation on real risk by targeting Dependabot and code scanning alerts in artifacts deployed to production, using metadata from external registries like JFrog Artifactory, your own CI/CD workflows, or from Microsoft Defender for Cloud.

Dans cet article

Remarque

Production context and the integration with Microsoft Defender for Cloud is in public preview and subject to change.

Prioritizing alerts using production context

Application Security (AppSec) managers are often overwhelmed by a high volume of alerts, many of which may not represent real risk because the affected code never makes it to production. By associating production context with your alerts, you can filter and prioritize vulnerabilities that impact artifacts actually approved for production environments. This enables your team to focus remediation efforts on the vulnerabilities that matter most, reducing noise and improving your security posture.

Associating production context with alerts

GitHub enables you to provide production context for Dependabot and code scanning alerts using the REST API:

Storage Record API

This API allows package registries or GitOps workflows to send artifact lifecycle data to GitHub. You should configure your system to call the endpoint whenever an artifact is promoted to a production-approved package repository.

GitHub processes this metadata and uses it to power new alert filters, such as artifact-registry-url and artifact-registry. For more information, see Create artifact metadata storage record in the REST API documentation.

Conseil

If you use JFrog Artifactory, you do not need to perform any custom integration. Artifactory natively integrates with the Storage Record API. You only need to enable the integration in your Artifactory settings, and Artifactory will automatically emit production promotion events to GitHub. For setup instructions, see JFrog and GitHub Integration: JFrog for GitHub Dependabot in the JFrog documentation.

Deployment Record API

This API allows systems to send deployment data for a specific artifact to GitHub, such as its name, digest, environments, cluster, and deployment.

GitHub processes this metadata and uses it to power new alert filters, such as has:deployment and runtime-risk. For more information, see Create an artifact deployment record in the REST API documentation.

Conseil

If you use Microsoft Defender for Cloud (MDC) and connect your instance to a GitHub organization, MDC will automatically send deployment and runtime data to GitHub. For more information, see Quick Start: Connect your GitHub Environment to Microsoft Defender for Cloud in the documentation for MDC.

Enable and use production context for alert prioritization

1. Detect and report production artifact promotions and deployments

In your CI/CD or GitOps workflow, whenever an artifact is promoted to a production-approved package repository, call the Storage Record API to send the artifact's metadata to GitHub. Whenever an artifact is deployed to production, call the Deployment Record API to send additional metadata for the artifact to GitHub.

2. Use production context filters

Production context filters are made available in alert views and security campaign views under the Security tab.

Once the alert list is displayed, use the artifact-registry-url or artifact-registry filters in organization views to focus on vulnerabilities affecting artifacts present in production.

  • For your own artifact repository that is hosted at my-registry.example.com, you would use:

    Text
    artifact-registry-url:my-registry.example.com

  • If you use JFrog Artifactory, you can use artifact-registry with no further setup in GitHub:

    Text
    artifact-registry:jfrog-artifactory

You can also use the has:deployment and runtime-risk filters to focus on vulnerabilites that deployment metadata shows as in deployment or at risk of runtime vulnerabilities. This data is populated automatically if you have connected MDC. For example:

  • To focus on alerts in deployed code that is exposed to the internet, you would use:

    Text
    has:deployment AND runtime-risk:internet-exposed

You can also combine these production context filters with other filters, such as EPSS:

Text
epss > 0.5 AND artifact-registry-url:my-registry.example.com

3. Remediate alerts in production code

Now you have identified the alerts that put your production code at risk of exploitation, you need to remediate them as a matter of urgency. Where possible use automation to lower the barrier to remediation.

Further reading