Connecting runtime to source: Sysdig and Semgrep integration

In today’s complex cloud environments and mounting pressure, the last thing security teams need is a dead end. Yet, that’s often what a critical runtime finding becomes. We’ve all been there: you see a vulnerability actively running in production, but the trail goes cold. Where did it come from? Which team owns it? How do we implement the fix?

At Sysdig, we know that identifying an active vulnerability is only half the battle. That’s why our partnership with Semgrep is so important. We’re not just connecting two tools; we’re connecting the two most critical points in the security lifecycle: the moment a vulnerability is detected at runtime and the exact line of code where it was born.

Bridging runtime and source context

For too long, runtime security and static analysis have operated in separate universes. Sysdig’s runtime threat detection, powered by Falco, provides unparalleled runtime context: process activity, network connections, and file system interactions within live containers. Meanwhile, Semgrep provides the source context: the repositories, dependency manifests, and code ownership that represent the ground truth for your developers.

The problem has always been the manual correlation required to bridge them. A security engineer gets a finding from Sysdig about a critical in-use vulnerability in a production pod but then has to manually hunt for the source repository. A developer gets a software composition analysis (SCA) finding from Semgrep but has no data to determine if it's a theoretical risk or a five-alarm fire in production.

This integration replaces that manual hunt with a dynamic, automated data enrichment process.

Anatomy of an enriched finding: The data flow

When a Sysdig finding is generated, a precise, automated workflow is triggered to fuse runtime and source context.

1. Runtime Detection: Sysdig detects a vulnerable package being used by a running process inside a container. This generates a detailed runtime finding, for example,  including the image ID, package name (log4j-core), and version (2.14.1).
2. Metadata Extraction: As part of its standard data collection, Sysdig has already collected the container image's metadata, including the OCI labels for the source repository and commit SHA.
3. The Enrichment: Sysdig uses this extracted source information to match data to the Semgrep platform. The query essentially asks: "For the repository github.com/my-org/my-app at commit a1b2c3d, what do you know about the package log4j-core?"
4. Source Context Retrieval: Because Semgrep has already scanned this, it has the required data indexed. It instantly returns a payload containing the precise location of the vulnerable dependency (e.g., pom.xml, line 52) and the remediation advice (e.g., "Upgrade to version 2.17.1").
5. Unified Finding: Sysdig merges this Semgrep payload into its original runtime finding. The security engineer now sees a single, actionable view in the Sysdig Secure UI, containing both the "what" and the "where." Whilst within Semgrep, can see this vulnerability with the runtime context.

It’s a direct, programmatic path from a runtime event to a source code location.

How it works: Building the metadata bridge

The bridge between runtime and source isn't magic - it's built on a simple and powerful DevOps best practice that you enable in your CI/CD pipeline: embedding metadata directly into the container image. This one-time setup creates a durable link that travels with your application from source to production.

This is done using standard Open Container Initiative (OCI) labels. By adding these key-value pairs, you create the permanent breadcrumb trail that connects a running workload back to its origin. This is a robust, non-proprietary mechanism. For this integration, two labels are most important:

• org.opencontainers.image.source: The URL of the source code repository.
• org.opencontainers.image.revision: The specific commit hash (SHA) from which the image was built.

Implementing this is a straightforward modification to your image build step in any CI/CD system. 

Once an image built this way is deployed, Sysdig automatically discovers these labels. The embedded repository and commit information now serve as the exact coordinates for matching the data to Semgrep, closing the loop.

The result: A single, actionable view

This integration fundamentally changes the nature of a security finding. Instead of a simple notification, teams get a comprehensive remediation ticket in a single view.

By building a seamless technical bridge between runtime and source code, Sysdig and Semgrep are giving teams a unified signal. This allows security operations to reduce alert fatigue and focus on high-impact threats, while developers receive the precise, actionable data needed to reduce Mean Time to Remediation (MTTR). We’re empowering you to move from security bottlenecks to secure velocity, finally delivering on the promise of DevSecOps

‍