If you ship containers through Google Cloud, you already have most of the plumbing needed for GCP SBOM generation — you just need to switch it on and wire it into your pipeline. Teams that push images to Artifact Registry without generating a software bill of materials GCP-wide are flying blind: a new CVE drops, and nobody can say in minutes which services actually pull in the affected package. Artifact Analysis (formerly Container Analysis) can automatically scan images, produce SPDX or CycloneDX SBOMs, and — paired with Cloud Build — attach SLSA provenance so you can prove not just what's in an artifact, but how it was built.
This guide walks through enabling Artifact Analysis, generating and exporting SBOMs for a real image, producing SLSA provenance, and verifying both before deployment. By the end, you'll have a repeatable, scriptable workflow you can drop into CI/CD.
Step 1: Enable Artifact Analysis and Prerequisite APIs
GCP SBOM generation depends on a handful of APIs working together: Artifact Registry to host images, Artifact Analysis (the modern name for the Container Analysis API) to scan them, and Cloud Build if you want provenance attached automatically at build time.
gcloud services enable \
artifactregistry.googleapis.com \
containeranalysis.googleapis.com \
containerscanning.googleapis.com \
cloudbuild.googleapis.com \
--project=YOUR_PROJECT_ID
Confirm your project has On-Demand Scanning or automatic vulnerability scanning enabled — Artifact Analysis SBOM generation is bundled with the same scanning pipeline that powers vulnerability occurrences, so if scanning works, SBOM export will too.
gcloud artifacts docker images list \
--repository=YOUR_REPO \
--location=us-central1 \
--project=YOUR_PROJECT_ID
Step 2: Push an Image to Artifact Registry
SBOM generation triggers on images that land in Artifact Registry (Container Registry is deprecated and does not support the newer Artifact Analysis SBOM workflow). Tag and push a sample image to confirm the pipeline end to end.
docker tag my-app:latest \
us-central1-docker.pkg.dev/YOUR_PROJECT_ID/my-repo/my-app:latest
docker push \
us-central1-docker.pkg.dev/YOUR_PROJECT_ID/my-repo/my-app:latest
Within a few minutes of the push, Artifact Analysis automatically kicks off a scan and, if SBOM generation is enabled for the project, produces a discovery occurrence tied to that image digest.
Step 3: Run GCP SBOM Generation On Demand
For images already sitting in a registry, or for one-off audits, use the On-Demand Scanning CLI to generate a software bill of materials GCP tooling can hand you directly, without waiting for an automatic scan cycle:
gcloud artifacts sbom export \
--uri=us-central1-docker.pkg.dev/YOUR_PROJECT_ID/my-repo/my-app@sha256:DIGEST \
--output-file=my-app-sbom.spdx.json
If you need CycloneDX instead of SPDX for downstream tooling compatibility, most SBOM diff and enrichment tools (including Syft) can convert between the two formats after export:
syft convert my-app-sbom.spdx.json -o cyclonedx-json=my-app-sbom.cdx.json
Store both digest-pinned SBOMs (not tag-pinned) — tags move, digests don't, and your audit trail needs to reference the exact artifact that was deployed. If you manage multiple repositories across several GCP projects, script this export step to run against every repository nightly, and archive the resulting files in a versioned bucket so you can diff SBOMs between releases and spot when a new dependency was introduced.
Step 4: Retrieve SBOM Occurrences via the API
For automation, query occurrences directly rather than re-running exports. This is the pattern to build a compliance dashboard or feed an inventory system:
curl -X GET \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://containeranalysis.googleapis.com/v1/projects/YOUR_PROJECT_ID/occurrences?filter=resourceUrl%3D%22https://us-central1-docker.pkg.dev/YOUR_PROJECT_ID/my-repo/my-app@sha256:DIGEST%22+AND+kind%3D%22SBOM_REFERENCE%22"
The response includes a pointer to the generated SBOM document plus its content hash, which you should verify against your stored copy before trusting it in a downstream policy check. This is the same query pattern a compliance tool would run to prove, on demand, that every production image has an associated software bill of materials GCP auditors or customers can review — useful when you're answering a vendor security questionnaire or preparing for a SOC 2 audit.
Step 5: Generate SLSA Provenance with Cloud Build
SBOM generation tells you what's in an artifact; SLSA provenance GCP builds can attach tells you how it got there — which source commit, which builder, which build steps ran. Cloud Build generates provenance automatically at SLSA Build Level 3 when you use a supported build configuration:
steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$SHORT_SHA', '.']
images:
- 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$SHORT_SHA'
options:
requestedVerifyOption: VERIFIED
Run the build and Cloud Build will emit an in-toto attestation as a build provenance occurrence:
gcloud builds submit --config=cloudbuild.yaml .
Step 6: Verify Provenance and SBOM Integrity Before Deploy
Never treat SBOM or provenance generation as fire-and-forget — verify both at deploy time so a tampered artifact or a scan gap can't slip through.
gcloud artifacts docker images describe \
us-central1-docker.pkg.dev/YOUR_PROJECT_ID/my-repo/my-app@sha256:DIGEST \
--show-provenance \
--show-sbom-refs
If you're enforcing supply chain policy with Binary Authorization, add an attestor that checks for both a valid SBOM reference and SLSA provenance before allowing deployment to GKE or Cloud Run:
gcloud container binauthz attestations sign-and-create \
--artifact-url=us-central1-docker.pkg.dev/YOUR_PROJECT_ID/my-repo/my-app@sha256:DIGEST \
--attestor=sbom-verified \
--attestor-project=YOUR_PROJECT_ID \
--keyversion=YOUR_KMS_KEY_VERSION
Step 7: Automate the Whole Flow in CI/CD
Wire steps 2 through 6 into your existing pipeline so every merge to main produces a scanned image, an exported SBOM, and attached provenance without a human remembering to run a command. A minimal Cloud Build trigger config chains the build, push, SBOM export, and Binary Authorization gate as sequential steps, failing the pipeline if any occurrence is missing or the vulnerability scan turns up a critical unpatched CVE above your policy threshold.
Add a final step that publishes the exported SBOM to an internal artifact store or notifies a security channel when a build introduces a new license or a package with a known-bad reputation. Treating GCP SBOM generation as a pipeline gate rather than an optional report is what actually stops risky dependencies from reaching production, instead of just documenting that they got there.
Troubleshooting and Verification
SBOM export returns "not found" for a fresh push. Scanning is asynchronous and can take a few minutes on first push, longer for large multi-layer images. Poll the occurrences API instead of assuming failure after one attempt.
No SBOM occurrence appears at all. Confirm the image lives in Artifact Registry, not the deprecated Container Registry (gcr.io legacy hosts are not covered by newer Artifact Analysis SBOM features), and confirm containerscanning.googleapis.com is enabled at the project level, not just containeranalysis.googleapis.com.
Provenance is missing from a Cloud Build run. Provenance requires requestedVerifyOption: VERIFIED in your build config and a supported builder image; custom or third-party build steps that bypass Cloud Build's native build/push steps won't get attested automatically.
SBOM contents look stale after a rebuild. Always key lookups off the image digest, never the tag. A tag can be reused across builds, but the SBOM and provenance are permanently bound to the digest that existed at scan time.
Binary Authorization blocks a deploy unexpectedly. Check that the attestor's public key matches the KMS key version used to sign, and that the SBOM/provenance occurrences actually exist for that exact digest before assuming the attestor logic is broken.
How Safeguard Helps
Artifact Analysis gives you the raw material — SBOMs and provenance per image — but most organizations run dozens of repositories across multiple GCP projects, plus workloads on other clouds and on-prem build systems. Chasing down occurrences per digest through the API isn't a substitute for a single place that answers "where does this vulnerable package live across everything we ship."
Safeguard ingests SBOMs generated by Artifact Analysis alongside SBOMs from other build systems and registries, normalizes them into one searchable inventory, and continuously cross-references components against new CVE disclosures the moment they're published — not on your next scheduled scan. It validates SLSA provenance GCP builds emit, flags artifacts missing attestations before they reach production, and enforces policy gates so a container without a verified SBOM or provenance record simply can't ship. For teams already using Binary Authorization, Safeguard adds the fleet-wide visibility and audit trail that turns individual attestations into a defensible, continuously monitored supply chain security program.