Source ↔ Container Correlation
When the same project scans both as source code (SCA) and as a container image, Vygl automatically matches dependencies by name and version. If lodash@4.17.15 appears in your package-lock.json and in /app/node_modules inside your container, Vygl links the two findings — a high-confidence signal that the CVE is actually deployed, not just theoretical.
How matches are computed
Section titled “How matches are computed”Vygl matches on three fields:
- Ecosystem (npm, pypi, go, maven, gem, composer)
- Package name
- Package version
When all three line up between an SCA finding and a container CVE, the match is recorded. Both findings remain separate (each has its own triage state, its own AI verdict) — they’re just linked.
Where to find correlations
Section titled “Where to find correlations”Image detail. The image detail page has a Source Correlations section listing every match for that image, grouped by source project.
Project view. Each project’s detail page shows correlations for any container images that include packages from that source project.
MCP / API. AI assistants connected via MCP can call get_container_correlations(image_ref) to fetch the same data.
Why correlation matters
Section titled “Why correlation matters”Container scans tend to be noisy: a base image might have 200 CVEs, of which only 5 are in packages your code actually uses. Source ↔ container correlation surfaces the subset that’s both in your code and deployed in your image — the highest-priority subset for triage.
A few practical use cases:
- “Which CVEs are reachable in production?” — start with the correlations.
- “Is this base-image CVE actually a problem for us?” — if it doesn’t correlate to a source dep, your code isn’t using that package even if it’s installed in the image.
- “Did my npm upgrade actually ship?” — re-scan the container; if the correlation now shows the upgraded version, yes.