Anchore Enterprise Integration with DefectDojo

Anchore Enterprise Integration with DefectDojo

Anchore Enterprise is a commercial software supply chain security platform from Anchore, Inc. It generates SBOMs for container images, matches their packages against vulnerability feeds, and evaluates images against policy gates such as banned packages, exposed secrets, Dockerfile rules, and vulnerability thresholds. It is driven through a web UI, an API, and the anchorectl CLI. Anchore also maintains the open source scanner Grype. DefectDojo has parsers for Anchore Enterprise vulnerability reports, AnchoreCTL vulnerability and policy reports, legacy anchore-cli policy checks, and Grype JSON, and DefectDojo Pro adds an Anchore Enterprise connector.

Anchore Enterprise Integration with DefectDojo

We use Anchore to decide whether an image is fit to ship, and DefectDojo to make sure what it finds actually gets fixed. Anchore knows every package in every layer and whether a policy gate fails. What it doesn't do is sit next to our SAST, DAST, and pentest results with one set of SLAs and one owner per service. Importing Anchore reports into DefectDojo turns image CVEs and policy violations into Findings on the right Asset, deduplicated across rebuilds, so the next image scan closes what was patched instead of starting the list over.

Why Anchore Enterprise Matters

Container images ship an operating system's worth of packages plus language dependencies, and most of their vulnerabilities come from components the application team never chose directly.

• Anchore scans OS packages and language ecosystems (Go binaries, Java archives, npm, Python, and others) in each image layer.
• Its policy engine adds a second axis beyond CVEs: whether an image breaks rules your organization set, with stop and warn actions.
• Grype gives developers the same vulnerability matching locally and in CI without a server.
• An Anchore report is a snapshot of one image digest. Without a tracking platform, nobody can say which CVEs persisted across five releases.

Advantages of This Integration

What we gained by sending Anchore results through DefectDojo:

• Deduplication tuned per report type. Vulnerability reports deduplicate on title, severity, component name, component version, and file path; policy reports on title, severity, component name, and file path; Grype on title, severity, component name, and component version.
• Lifecycle across rebuilds. Reimporting each new scan into the same Test mitigates CVEs fixed by a base image update and reactivates any that return.
• Fix information ready for triage. Mitigation text names the fixed version where one exists, and DefectDojo records whether a fix is available.
• Exploit context from Grype. Grype imports carry EPSS score and percentile and CISA KEV dates when the report includes them, which helps separate urgent CVEs from background noise.
• Policy violations as tracked work. Stop and warn results from Anchore policies become Findings with SLAs, not just a failed pipeline step.

How This Integration Works

Pick the scan type that matches the file you have. Each name below is exactly as DefectDojo lists it.

Anchore Engine Scan (Anchore Enterprise vulnerability report). The docs title this parser "Anchore Enterprise Vulnerability". It reads both the legacy anchore-cli vulnerability JSON and the newer format with metadata and securityEvaluation keys, produced by:

anchorectl image vulnerabilities registry.example.com/payments:2.3.1 -o json > anchore-vulns.json

You can also download the same JSON from an image's Vulnerabilities tab in the Anchore Enterprise UI.

AnchoreCTL Vuln Report. Reads a JSON array of vulnerabilities with camelCase fields such as packageName, packagePath, and feedGroup, the format earlier AnchoreCTL releases produced.

AnchoreCTL Policies Report. Reads AnchoreCTL policy evaluation JSON in both the legacy list format and the newer object format with an evaluations array. Only evaluations that report findings are imported. Before automating, confirm that the output of the anchorectl version you run matches one of these layouts.

Anchore Enterprise Policy Check. Reads the legacy anchore-cli JSON policy check format, where each row of the evaluation result is one gate trigger.

Anchore Grype and Anchore Grype detailed. Both read Grype JSON. The default type aggregates matches for the same vulnerability, component name, and version into one Finding. The detailed type creates one Finding per file path and deduplicates on a unique ID built from vulnerability ID, component, version, and path.

grype registry.example.com/payments:2.3.1 -o json > grype.json

Import the file. In the UI, open the Engagement, choose Import Scan Results, and select the scan type. For automation, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Anchore Engine Scan" \
  -F "file=@anchore-vulns.json" \
  -F "product_name=payments" \
  -F "engagement_name=Image Scans" \
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Anchore Grype" \
  --report-path "./grype.json" \
  --product-name "payments" \
  --engagement-name "Image Scans" \
  --auto-create-context

Or connect Anchore Enterprise directly (DefectDojo Pro). The connector pulls data from Anchore Enterprise with an API key. Enter the URL where you reach Anchore in the Location field and the API key in the Secret field. Assets are discovered and mapped from Anchore "Applications", which group multiple images.

Data Granularity: What Gets Imported

The main table covers the Anchore Engine Scan vulnerability report.

How the other scan types differ:

Policy findings set component name and version from the image repository and tag, pull a file path from the description when one appears, and add the CVE when the trigger ID starts with one. Grype findings also set fix version, EPSS, KEV date, and a tag named for the matcher (for example dpkg).

Use Cases

In CI for every image build: Developers run Grype in the pipeline and reimport into a Test per image, so pull requests show only new CVEs.

For release gating with Anchore Enterprise: The platform team imports the AnchoreCTL policy evaluation for each release candidate. Stop actions arrive as Critical Findings with an owner and SLA, which makes the gate decision auditable.

Across a large registry: DefectDojo Pro teams use the connector so each Anchore Application maps to an Asset, giving security leads image risk by service without exporting files.

During base image upgrades: After a base image bump, reimporting each service's report shows which CVEs the upgrade closed fleet-wide and which come from application-installed packages.

Operational Tips

• Choose Anchore Grype or Anchore Grype detailed per pipeline and stick with it. Switching changes how findings are grouped and deduplicated.
• Use --by-cve with Grype consistently or not at all. Mixing the two across reimports produces mismatched hash codes.
• In AnchoreCTL policy reports, a go status imports as inactive Info, so passing checks don't count against SLAs.
• In the newer Anchore Engine Scan format, finding descriptions can accumulate package lines from earlier entries in the same report. Rely on the title, component, and file path fields when triaging.
• Set minimum_severity=Low if Negligible OS package CVEs, imported as Info, would bury the team.
• Tag imports with image name and tag (for example tags=payments,2.3.1) to filter findings by release.