Google Cloud Artifact Vulnerability Scan Integration with DefectDojo

Google Cloud Artifact Vulnerability Scan Integration with DefectDojo

Google Cloud Artifact Analysis is the vulnerability scanning service built into Google Cloud's Artifact Registry. When scanning is enabled, it analyzes container images pushed to the registry, identifies operating system and language packages, and records a vulnerability occurrence for each CVE it matches, with severity, CVSS data, the affected and fixed package versions, and advisory links. Results can be retrieved through the gcloud CLI or the Artifact Analysis API, and the gcloud output can be saved as JSON for DefectDojo to import.

Google Cloud Artifact Vulnerability Scan Integration with DefectDojo

Our images live in Artifact Registry, so turning on its scanning was the easiest way to get CVE coverage on every push. The gap was what to do with the results. Artifact Analysis lists vulnerabilities per image digest; DefectDojo turns them into Findings on the Asset that owns the service, assigns them, tracks them against SLAs, and keeps that history when the next image replaces the last. Teams that already triage SAST and dependency findings in DefectDojo now handle registry CVEs in the same queue.

Why Google Cloud Artifact Analysis Matters

Container images ship an entire userland, and most of their CVEs come from base image packages the application team never chose directly.

• Scanning happens in the registry, so every pushed image is covered without adding a scanner to each pipeline.
• It covers operating system packages and several language ecosystems in the same scan.
• Each occurrence includes Google's effective severity, a CVSS score, and whether a fix is available, which is the information needed to decide what to patch first.
• On its own, the data is organized per image. Nobody can see from the registry which team owns a CVE or how long it has been open across releases.

Advantages of This Integration

What DefectDojo adds to Artifact Analysis results:

• Ownership by Asset. Image CVEs land on the Asset that owns the service, where they can be assigned, discussed in notes, pushed to Jira, or risk-accepted.
• SLA tracking. Google's severity buckets map directly onto Critical, High, Medium, and Low, so registry CVEs fall under the same SLA rules as findings from other tools.
• Fix-first triage. The parser records whether Google reports a fix as available, so engineers can filter to CVEs they can actually resolve with an upgrade.
• A lifecycle across image versions. Reimporting the next image's results into the same Test mitigates CVEs that a base image update removed and adds new ones.
• Two ways in. File import works in Community Edition and DefectDojo Pro; DefectDojo Pro also offers a Google Artifact Analysis connector that syncs every active project the service account can see.

How This Integration Works

Option 1: File import with gcloud. Describe an image by digest with package vulnerabilities included, and write the output as JSON:

gcloud artifacts docker images describe 
  us-central1-docker.pkg.dev/my-project/my-repo/my-image@sha256:IMAGE_DIGEST 
  --show-package-vulnerability --format=json > gcloud-artifact.json

The parser reads the package_vulnerability_summary block of that output. Import it with the Google Cloud Artifact Vulnerability Scan scan type, either in the UI (open the Engagement, choose Import Scan Results, select the scan type, upload the file) or through the API:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=Google Cloud Artifact Vulnerability Scan" 
  -F "file=@gcloud-artifact.json" 
  -F "product_name=orders-service" 
  -F "engagement_name=Container Images" 
  -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 "Google Cloud Artifact Vulnerability Scan" 
  --report-path "./gcloud-artifact.json" 
  --product-name "orders-service" 
  --engagement-name "Container Images" 
  --auto-create-context

Option 2: API Connector (DefectDojo Pro). Create a Google service account with the Container Analysis Occurrences Viewer role and a JSON key. In the DefectDojo Pro UI, configure the Google Artifact Analysis connector, leave the Location field at its default unless you use a non-standard endpoint, and paste the entire contents of the key file into the Service Account Key field. Optionally set Parent to organizations/{id}, folders/{id}, or projects/{id} to narrow the sync, and set a Minimum Severity. DefectDojo creates a Record for each active GCP project the service account can list, carrying the vulnerability occurrences recorded against that project's images. No per-image or per-repository configuration is needed.

Data Granularity: What Gets Imported

This table describes the file parser.

The fixed package version appears in the description as part of the raw package issue data; the parser does not set a separate Mitigation field.

Use Cases

Registry-wide coverage without pipeline changes: A platform team enables Artifact Analysis on its registries and the DefectDojo Pro connector on the organization. Every active project becomes a Record, and image CVEs reach DefectDojo without any team editing a build file.

Release gating for one service: A service team adds the gcloud describe step after each push and reimports the JSON into a Test named for the image. A release check queries DefectDojo for new Critical findings before promoting the image.

Base image patch campaigns: After the platform team updates a shared base image, service teams rebuild and reimport. The Findings that close show which CVEs the base image update fixed, and the ones that remain point to packages installed by the application layer.

Audit evidence: Container CVEs carry discovery dates, SLA status, and remediation history in DefectDojo, so an auditor can see how long Critical image vulnerabilities stayed open.

Operational Tips

• Always describe images by digest, not by tag. The digest ties the results to the exact image that was scanned, and it is recorded in the Finding description.
• Use one Test per image repository and reimport into it, so each new digest updates the same history instead of starting over.
• Filter on Fix Available when planning patch work. CVEs with no fix yet are good candidates for time-boxed risk acceptance.
• Set minimum_severity on import if Low OS package CVEs would bury your team.
• Use the connector's Parent setting to start with one folder or project, then widen it once Record-to-Asset mapping is settled.
• If you use both the file parser and the connector, keep them pointed at different Assets. They are separate import paths, and you shouldn't count on their findings deduplicating against each other.