Prepare and test your skills
Prepare and test your skills
Integrating security scanning into CI/CD pipelines means using Artifact Analysis (opens in a new tab) to scan container images, store findings as structured metadata, and trigger automated remediation. Artifact Registry (opens in a new tab) and Google Kubernetes Engine (GKE) have built-in detection points for Artifact Analysis, and all scanning services match files against known vulnerabilities using a common vulnerability store that can include third-party sources.
Automatic scanning in Artifact Registry scans a new image when the image is pushed to a Docker repository and then keeps the findings current through continuous analysis. The on-push scan extracts operating system and language packages, identifies dependencies and licenses, checks for malicious packages from the OpenSSF Malicious Packages Repository, and produces a vulnerability result that collects all vulnerability occurrences for that image. Malicious packages are reported as CRITICAL severity vulnerabilities, and automatic scans can also detect exposed secrets such as API keys and service account keys in public preview.
Automatic scanning is keyed to the image digest, so an image is scanned only once and adding or changing tags does not trigger a new scan. Continuous analysis ingests new and updated vulnerability data multiple times each day and then updates existing occurrences, creates new occurrences, or deletes occurrences that are no longer valid. Findings stay updated only while the image has been pulled within the last 30 days; after 30 days without a pull the metadata becomes stale and is no longer updated, and after more than 90 days stale it becomes archived and can be evaluated only by API. Pulling a stale or archived image refreshes its metadata within up to 24 hours, and scanning applies only to Linux-based images, prefers the Linux amd64 image in a manifest list, and does not support Windows Server containers.
Exam tip: Automatic scanning triggers once per image digest, not per tag, and enabling the Artifact Analysis API does not enable repository scanning by itself — scanning must still be enabled for each Artifact Registry repository.
On-demand scanning (opens in a new tab) is a manual scan started with the gcloud command-line interface (CLI) against a local image or a registry image without first pushing to Artifact Registry. On-demand scanning gives a Cloud Build step control over timing, so the pipeline can build an image, scan it immediately, and block the upload to Artifact Registry or fail the build when findings exceed a severity threshold. Results from on-demand scanning are available for up to 48 hours after completion and are never updated afterward.
The two scanning modes differ in trigger, freshness, and pipeline role, so teams commonly combine them:
| Scanning mode | Trigger and location | Freshness and retention |
|---|---|---|
| Automatic scanning with Artifact Registry | Triggered automatically on push of a new digest to Artifact Registry; covers operating system plus language packages | Continuously updated while image was pulled within 30 days; stale after 30 days, archived after 90 days stale |
| On-demand scanning | Manually initiated by command for a local or registry image; usable before push | Point-in-time result available for 48 hours with no continuous updates; ideal as a build gate |
Because on-demand scanning is point-in-time and automatic scanning is continuous, on-demand scanning blocks risky images early in Cloud Build while automatic scanning catches newly disclosed vulnerabilities in images already stored in Artifact Registry.
Artifact Analysis metadata management stores structured metadata that describes what happened to an artifact across source, build, storage, deployment, and runtime environments. People or automated systems attach metadata such as passed integration tests or passed vulnerability scans, and Binary Authorization reads that metadata to allow or deny deployment. A Binary Authorization policy can require only compliant images from trusted registries, require signed attestations of compliance with a vulnerability scan policy, or use a vulnerability allowlist built from Artifact Analysis findings.
Artifact Analysis links metadata to images through notes and occurrences, where a note defines a type of metadata and an occurrence records an instance of that note on a specific image. The Artifact Analysis API supports gRPC and REST/JSON, client libraries, and authenticated OAuth2 access for creating custom notes and occurrences and for querying vulnerability occurrences. The Google Cloud console surfaces the same findings in Artifact Registry, and the gcloud CLI can list vulnerabilities and image metadata for automation and auditing.
Centralized visibility aggregates Artifact Analysis findings so new scan completions and newly discovered vulnerabilities become actionable events. Security Command Center aggregates Artifact Registry scan findings across projects, shows container image vulnerabilities in running workloads alongside other risks, and supports export to BigQuery for long-term analysis. Cloud Deploy (opens in a new tab) security insights expose SLSA level, vulnerabilities by severity with fixes and VEX status, Software Bill of Materials (SBOM) inventories generated for Cloud Build images pushed to Artifact Registry, and build details including logs, builder name, timestamp, and JSON build provenance.
When continuous analysis creates or updates an occurrence, that change signals downstream automation to rebuild the image, revoke an attestation, block promotion, or notify owners. To investigate an unfamiliar package such as a transitive dependency introduced by a package manager, trace the finding to its file path with this container scanning (opens in a new tab) workflow:
This flow connects detection to ownership because the scan identifies the vulnerable file, the SBOM and provenance identify how it entered the build, and Binary Authorization and Security Command Center determine whether the image can continue to run.
Deployment gates using Binary Authorization are admission checks that block container deploys to Google Kubernetes Engine (GKE) unless the image carries required cryptographically signed attestations backed by Artifact Analysis scan metadata. In this model, Artifact Analysis (opens in a new tab) produces vulnerability findings and stores verification metadata, an authorized attester signs that a policy was met, and Binary Authorization verifies the signatures at deploy time. The gate therefore depends on fresh scan data flowing from Artifact Registry (opens in a new tab) to Artifact Analysis to the attester to the GKE admission controller.
Artifact Analysis metadata is the evidence foundation that Binary Authorization gates read before allowing a deployment. Artifact Analysis is a family of services for software composition analysis and structured metadata storage and retrieval, with detection points built into Artifact Registry and GKE and support for first-party and third-party sources. All scanning services match files against a common vulnerability store, and people or automated systems add metadata at phases of the release process to describe results such as passing an integration test suite or a vulnerability scan.
Artifact Analysis associates metadata with a specific image through notes and occurrences, where a note defines the metadata type and an occurrence records an instance on that image. A vulnerability result is the collection of vulnerability occurrences for an image after a scan completes, plus dependency and license data for software composition. Because the metadata travels with the image digest across source, build, storage, deployment, and runtime environments, Binary Authorization can later require proof that the expected checks created the expected occurrences before admission is granted.
Automatic scanning in Artifact Registry provides the continuously refreshed signal that production gates should trust. The scan triggers automatically on every push of a new image to Artifact Registry, extracts operating system and application language package inventory, and scans once per image digest so adding or retagging does not trigger a new scan. Findings cover publicly monitored packages from upstream sources and malicious packages from the OpenSSF Malicious Packages Repository, reported as CRITICAL severity vulnerabilities, plus secret detection for API keys and service account keys in public preview.
Continuous analysis keeps that signal current by ingesting new vulnerability data multiple times each day and updating existing occurrences, creating new occurrences, and deleting occurrences that are no longer valid. The lifecycle depends on image use: metadata stays updated while the image has been pulled within the last 30 days, then becomes stale and is no longer updated, then after more than 90 days stale it becomes archived and can be evaluated only by API. An image with stale or archived metadata can be refreshed by pulling the image, with refresh taking up to 24 hours, which means a gate that requires current scan metadata depends on recent pulls and cannot rely on old tags alone.
On-demand scanning (opens in a new tab) is a manual scan initiated by gcloud CLI command against a local image or registry image without first pushing to Artifact Registry or GKE runtimes. The scan result is available for up to 48 hours after completion and is not updated afterward, so the finding reflects only the vulnerability store at scan time. This behavior makes on-demand scanning suitable for early pipeline decisions rather than long-lived deploy-time truth.
A common early gate runs on-demand scanning in Cloud Build immediately after build and blocks upload to Artifact Registry if vulnerabilities exceed a severity level. If automatic scanning is also enabled, images that pass the early gate are scanned again on upload and then continuously monitored. The two modes complement each other across the pipeline:
| Scanning mode | Trigger and location | Updates and retention | Gate use |
|---|---|---|---|
| Automatic scanning with Artifact Registry | Automatic on push to Artifact Registry, scanned once per digest | Continuously updated multiple times daily; stale after 30 days without pull, archived after 90 days stale | Deploy-time signal for Binary Authorization attestations |
| On-demand scanning | Manual gcloud CLI command on local or registry image | Static result for 48 hours, never updated | Build-time shift-left check to block upload on severity threshold |
Binary Authorization verifies container integrity so only trusted images deploy by enforcing a policy when a deploy to GKE is attempted. The policy allows or denies deployment based on the presence or absence of required attestations, and policies apply at cluster level so development, staging, and production clusters can require different attesters. A typical vulnerability gate configures the policy to allow deployment only if the image digest is signed for compliance with a vulnerability scan policy.
The ordered gate workflow preserves the chain from evidence to admission:
Enforcing by digest (sha256:...) rather than mutable tag prevents tag-mutation bypass, and a vulnerability allowlist based on Artifact Analysis data can alert when violations exceed policy. Supporting hygiene includes cleanup policies that delete unversioned, untagged, or stale release-candidate images and virtual repository priorities that prefer internal artifacts, which reduce the chance that a legacy or confused-dependency image reaches the gate.
Exam tip: Binary Authorization does not evaluate CVE severity at admission; it verifies that the required attestations exist for the exact image digest, so retagging an image never creates new scan evidence.
Progressive attestation hardens gates as images move toward production through increasing signature requirements enforced by automated attestation generation in Cloud Build or GitHub Actions pipelines. An image first collects build and scan attestations, then QA or security-review attestations, and the production cluster policy requires the full set while earlier clusters require fewer. Because each attestation binds to the same immutable digest, promotion cannot substitute a different binary without invalidating the signatures.
Continuous Validation extends the gate past admission by watching already-running Pods when new vulnerabilities are disclosed, which matters because automatic scan metadata can change after deployment. If a new CRITICAL finding or malicious package maps to a running image, the control plane flags the workload in Logging even though admission previously succeeded. For high-severity incidents that require immediate deployment of an unsigned or non-compliant image, breakglass emergency deployment bypasses admission, but Monitoring alerting policies on breakglass audit log events must notify the security operations team so every bypass is tracked and remediated.
Google Cloud Artifact Analysis (opens in a new tab) is a family of services for software composition analysis and metadata storage and retrieval. Detection points are built into Artifact Registry (opens in a new tab) and Google Kubernetes Engine (GKE) for quick enablement, and the service also stores information from third-party sources. All scanning services match files against known vulnerabilities using a common vulnerability store, and they identify dependencies and licenses in container images.
Automatic scanning in Artifact Registry scans a new container image when the image is pushed to a Docker repository. The scan extracts information about operating system (OS) packages and application language packages and produces a scan result, which is the collection of vulnerability and malicious-package occurrences for that image. Images are scanned only once based on the image digest, so adding or modifying tags does not trigger a new scan and only changing image contents triggers a new scan.
Enabling the Artifact Analysis API starts automatic scanning of new pushes in the project, but scanning remains disabled by default for Artifact Registry repositories until scanning is enabled for the individual repository. Automatic scanning runs on any Linux-based architecture and does not support Windows Server containers. For a manifest list, which is a list of pointers to manifests for several platforms, Artifact Analysis scans the Linux amd64 image when present and otherwise selects a different image from the list.
Continuous analysis is the second task of automatic scanning in Artifact Registry, and continuous analysis keeps scan metadata current after the initial on-push scan. Artifact Analysis receives new and updated vulnerability and malicious-package information from upstream providers multiple times each day, then updates existing occurrences, creates new occurrences for new notes, and deletes occurrences that are no longer valid. This flow moves vulnerability data from the vulnerability sources to the stored occurrences attached to each scanned image digest.
Freshness depends on image use. Artifact Analysis continues to update metadata as long as the image has been pulled within the last 30 days, and after 30 days without a pull the results become stale and are no longer updated. Metadata that has been stale for more than 90 days becomes archived and can be evaluated only by using the API. An image with stale or archived metadata can be refreshed by pulling the image, with refresh taking up to 24 hours, while packages with stale or archived metadata cannot be rescanned.
Exam tip: Tag changes never trigger a new automatic scan because scanning is keyed to image digest; only a content change with a new digest triggers a new scan.
On-demand scanning (opens in a new tab) is a manual scan initiated with the gcloud command-line interface (CLI) against a local image or an image in a registry. The image does not need to be pushed to Artifact Registry or GKE runtimes first, so the scan can run earlier in a build or on a workstation. This placement gives control over when vulnerability results are accessed in a continuous integration and continuous delivery (CI/CD) pipeline, including blocking and failing builds based on severity.
On-demand scanning is not continual. Scan results are available for up to 48 hours after the scan completes, and vulnerability information is not updated after the scan finishes. Choose on-demand scanning when a point-in-time check or pre-push gate is needed, and choose automatic scanning with continuous analysis when stored images need ongoing monitoring for newly disclosed vulnerabilities.
| Mode | Trigger | Continuous updates | Image location | Result lifetime |
|---|---|---|---|---|
| Automatic scanning with Artifact Registry | Push of a new image digest to Artifact Registry | Yes, multiple times daily while image was pulled in last 30 days | Image must be stored in Artifact Registry | Persistent occurrences until stale after 30 days without pull, then archived after 90 days stale |
| On-demand scanning | Manual gcloud CLI command | No updates after scan finishes | Local computer or registry without required push | Available up to 48 hours after scan completes |
Container scanning (opens in a new tab) covers both OS packages and application language packages, plus malicious packages and exposed secrets. Vulnerability data comes from upstream OS and language providers, while malicious-package data comes from the OpenSSF Malicious Packages Repository and is reported as CRITICAL severity vulnerabilities. Automatic scans also detect secrets such as API keys and service account keys in public preview to prevent sensitive data exposure.
Automatic language-package scanning is only available for Artifact Registry, while on-demand and automatic scanning both address OS and language packages for Java and Go and related ecosystems. Supported application language packages include:
Supported OS package families include AlmaLinux OS, Alpine, CentOS, Chainguard, Debian, Google Distroless, MinimOS, Red Hat Enterprise Linux (RHEL), Red Hat Universal Base Image (UBI), Rocky Linux, SUSE Linux Enterprise Server (SLES), Ubuntu, and Wolfi. Only publicly monitored packages are detected, so findings are limited to vulnerabilities with upstream coverage.
Artifact Analysis metadata links scan findings to images through notes and occurrences, where occurrences record a specific finding against an image. People or automated systems can add metadata at phases of the release process, such as recording that an image passed an integration test suite or vulnerability scan. Access to vulnerabilities and metadata flows through three interfaces: the Google Cloud console view for Artifact Registry, the gcloud CLI, and the Artifact Analysis REST API and gRPC API with OAuth2 authentication, client libraries, or cURL.
Scan metadata can enforce deployment decisions downstream. Binary Authorization consumes Artifact Analysis vulnerability information to create attestations and deployment policies that allow only compliant images from trusted registries, including a vulnerability allowlist that alerts when violations occur. Security Command Center aggregates Artifact Registry scan findings across projects to show container vulnerabilities in running workloads alongside other risks, with export to BigQuery for analysis and long-term storage.
To trace a transitive dependency that is not a direct dependency, investigate the file location for a finding in Artifact Registry:
Automatic scanning in Artifact Registry triggers automatically when a new image digest is pushed and keeps findings current through continuous analysis while the image was pulled within the last 30 days. On-demand scanning is manually initiated with the gcloud command-line interface (CLI) against a local or registry image without pushing to Artifact Registry and produces a point-in-time result available for up to 48 hours with no updates afterward. Teams commonly use on-demand scanning as a build gate to block risky images early and automatic scanning to catch newly disclosed vulnerabilities in stored images.
Artifact Analysis metadata stays updated while the image has been pulled within the last 30 days, becomes stale after 30 days without a pull and is no longer updated, and becomes archived after more than 90 days stale where it can be evaluated only by API. Pulling a stale or archived image refreshes its metadata within up to 24 hours. Automatic scanning is also keyed to the image digest, so adding or changing tags does not trigger a new scan.
Binary Authorization enforces deployment to Google Kubernetes Engine (GKE) by verifying required cryptographically signed attestations for the exact image digest before Pod creation and denying images without them. Artifact Analysis provides the evidence foundation by storing vulnerability occurrences linked to the digest through notes and occurrences, an authorized attester signs compliance with a vulnerability scan policy, and the admission controller checks those signatures. Binary Authorization does not evaluate CVE severity at admission, so retagging an image never creates new scan evidence.
Your team is establishing a vulnerability scanning and compliance pipeline for containerized microservices stored in Artifact Registry. The solution must meet the following requirements:
Which combination of configuration steps and IAM permissions should you implement?
Last updated