Remediating Vulnerabilities with Artifact Analysis and SCC

Vulnerability assessment and remediation in container images is the process of finding known security flaws in image contents and fixing them before deployment. In Google Cloud, Artifact Analysis (opens in a new tab) scans images stored in Artifact Registry (opens in a new tab), and remediation rebuilds the image with fixed packages and enforces the fix through the CI/CD pipeline. The image flows from the developer to Artifact Registry to the runtime, while scan findings flow back to the developer to trigger a rebuild.

1.1How Automatic Scanning Works in Artifact Registry

Automatic scanning in Artifact Registry is the service behavior that scans a container image for vulnerabilities when it is pushed and keeps monitoring it afterward. The scan extracts the inventory of system packages in the container and compares that inventory against vulnerability sources to create findings. After the push, Artifact Analysis continuously monitors the stored image metadata for new vulnerabilities for up to 30 days.

This continuous monitoring means an image that was clean at push time can become flagged later without being pushed again. The build therefore depends on scan metadata staying current, not only on the initial result. Teams integrate this check into regular linting, testing, and delivery, as described in shift-left security practices (opens in a new tab), so vulnerable dependencies are caught consistently and early.

1.2Understanding Scan Results as Notes and Occurrences

Scan results in Artifact Analysis are stored as metadata using notes and occurrences. A note describes a specific vulnerability, while an occurrence is created for each instance of that note associated with a particular image. An image can therefore have many occurrences that point to different notes for operating system (OS) packages and language packages.

Vulnerability scanners consume lock files (opens in a new tab) to determine exactly which artifacts an application depends on. The lock file provides the fully resolved dependency tree, including transitive dependencies, so the scanner can match precise versions and sometimes suggest an upgrade path. Evaluating the occurrences for an image shows which package, version, and severity are involved, which guides whether to patch a package, update a base image, or remove an unused dependency.

1.3Automatic Scanning Compared With On-Demand Scanning

Automatic scanning and On-Demand Scanning are two ways to assess the same container images at different points in the lifecycle. Automatic scanning runs in Artifact Registry after push, while On-Demand Scanning runs locally before the image is stored in Artifact Registry. Choosing between them depends on when the check is needed and which package types must be covered.

Automatic scanning covers stored images over time, while On-Demand Scanning lets developers fix a local image before it ever reaches the registry. Both results flow back to development as findings that require a rebuild and rescan.

1.4Remediation Strategies for Vulnerable Images

Remediation of a vulnerable container image means producing a new, fixed image and preventing the vulnerable image from reaching production. The fix is applied in source or the Dockerfile, then rebuilt and rescanned through the CI/CD pipeline using services such as Cloud Build and Cloud Deploy. Common remediation strategies include:

• Update the base image to a patched version from a trusted source, such as Google-provided base images or Assured Open Source Software (AOSS) for tested Java and Python images.
• Apply security patches to OS and language packages by updating version pins and lock files, then rebuilding the container image.
• Remove unused dependencies to shrink the dependency footprint, using audits in the linting pipeline and tools such as the Maven Dependency Plugin for Java.
• Mirror third-party dependencies through Artifact Registry remote repositories, which act as pull-through caches, and consolidate them with virtual repositories that prioritize private versions to reduce dependency confusion risk.
• Verify integrity with hash or signature checks in lock files and require attestations before promotion between environments.

After rebuilding, the new image flows from Cloud Build to Artifact Registry for a fresh scan, and only images that pass policy flow onward to testing or production. Binary Authorization (opens in a new tab) enforces this boundary at deployment time by checking attestations, such as proof that a trusted build system created the image or that the image meets a vulnerability policy. Running workloads in Google Kubernetes Engine (GKE) and Cloud Run then surface remaining image vulnerabilities in the GKE security posture dashboard and the Cloud Run security panel, so production findings flow back to development for the next remediation cycle.

Security finding management and prioritization is the practice of using Security Command Center (SCC) (opens in a new tab) as a central hub to collect, rank, and act on risks across Google Cloud resources. SCC scans virtual machines, containers, serverless Cloud Run workloads, and other assets without OS agents and creates findings from multiple detectors. Findings that expose the most important resources receive higher scores so teams fix high-risk issues first and export results for rapid response.

2.1Monitor Findings Across GCP Resources

Monitoring with SCC means enabling continuous scanning at the organization level and viewing all assets and findings in one place. Enabling SCC at the organization level gives near real-time visibility into misconfigurations, vulnerabilities, and threats and enables attack path simulations, security posture management, and compliance monitoring. The Assets page in the Google Cloud console shows each asset with its findings, change history, metadata, and IAM policies, and the asset data is read from Cloud Asset Inventory.

SCC creates findings from multiple built-in sources that cover different risk types:

• Security Health Analytics detects common vulnerabilities and misconfigurations across Google Cloud resources.
• Attack path exposure shows simulated paths an attacker could use to reach high-value resources.
• Event Threat Detection applies threat intelligence and machine learning to logs to identify threats in near-real time.
• Container Threat Detection detects runtime attacks such as evasive exploits, reverse shells, and unauthorized cryptomining in containers.
• Virtual Machine Threat Detection detects potentially malicious applications running on VM instances.
• Web Security Scanner scans App Engine, Compute Engine, and Google Kubernetes Engine web apps for OWASP Top Ten issues.

Activation in a project follows an ordered console workflow:

1. Go to Compute Engine Overview: Open Compute Engine Overview in the Google Cloud console.
2. Find sample findings: Look for the pane titled Sample security findings, which shows example findings.
3. Open activation: Click Turn on security scanning for free to open activation.
4. Choose tier: Optionally select a different service tier (opens in a new tab).
5. Enable scanning: Click Enable to start scanning, which usually completes within minutes or hours.

Programmatic access is available through the SCC API, client libraries, and gcloud for custom reporting and monitoring.

2.2Categorize and Prioritize Findings by Risk

Categorization and prioritization with SCC means ranking vulnerability and misconfiguration findings by how easily an attacker could reach important resources. The ranking depends on the high-value resource set, which is the list of resources the organization most needs to protect. Teams define the high-value resource set by creating resource value configurations, and until the first configuration is created SCC uses a default set that is not customized. Findings that expose resources in the high-value resource set receive higher attack exposure scores.

SCC provides several related features that explain why a finding matters. Attack path simulations visualize how threat actors could chain minor vulnerabilities from the internet to reach high-value compute resources or project billing permissions. Toxic combinations detect groups of risks that together create a path to a high-value resource, while chokepoints identify resources where multiple attack paths converge. Issues identify the most important risks found by virtual red teaming and rule-based detections on the security graph, and risk reports summarize simulation results with sample toxic combinations and attack paths. Correlated threats combine related threat findings using the security graph to help prioritize active incidents.

The available prioritization features depend on the SCC service tier:

2.3Track Remediation Progress and Enable Rapid Response

Tracking and rapid response with SCC means sending findings and resource changes to the tools that triage and fix them. After activation, findings should be exported to existing triage processes through a Pub/Sub topic, so downstream tools receive new findings automatically. Alerts can also be set up in Cloud Logging to notify teams about errors related to the SCC service agent. For resource and policy changes, teams create and subscribe to a Cloud Asset Inventory feed to receive real-time notifications.

The Google Cloud console provides formatted charts, compliance reports, and visual hierarchies for investigation, while the SCC API lets analysts manage findings and engineers build monitoring solutions. Organizations with unique needs can extend detection with custom modules for Security Health Analytics and Event Threat Detection and custom cloud controls in Compliance Manager, as part of posture assessment practices (opens in a new tab). Together, centralized findings, risk-based scores, and Pub/Sub and Logging exports let developers monitor application risks, focus on high-severity exposures, and respond quickly.

Automated response and policy enforcement means embedding security checks into the delivery pipeline so risky artifacts are found early and blocked automatically at deploy time. In Google Cloud, Cloud Build (opens in a new tab) builds and checks code, Artifact Analysis scans stored images, Cloud Deploy delivers to environments in sequence, and Binary Authorization blocks container deploys to Google Kubernetes Engine (GKE) and Cloud Run that lack required approvals.

3.1Automated Release Pipelines With Built-In Security Checks

Automated continuous integration and continuous delivery (CI/CD) pipelines remove manual errors, give standardized feedback loops, and make it possible to detect and fix security bugs early, fast, and reliably. A pipeline can scan for vulnerabilities automatically when artifacts are created, narrow the scope of security reviews, and roll back to a known and safe version when a release fails. Teams can also define different policies for development, test, and production environments so only verified artifacts move forward.

The pipeline depends on infrastructure as code and policy as code to stay consistent and auditable. Declarative infrastructure creates repeatable environments with a known good state, while tools like OPA let teams run automatic checks on infrastructure code before changes are deployed. Google Cloud supports this model with Cloud Build for builds, Cloud Deploy for staged delivery, Web Security Scanner for web checks, and Binary Authorization for deploy-time enforcement.

Cloud Build provenance flows from the build to later policy decisions. Provenance is verifiable metadata that includes digests of built images, input source locations, build toolchain, build steps, and build duration, plus the Supply-chain Levels for Software Artifacts (SLSA) build level. Cloud Build supports SLSA Level 3 builds for container images, which strengthens trust that the recorded build process actually produced the artifact.

3.2Continuous Vulnerability Scanning With Artifact Analysis

Continuous vulnerability scanning with Artifact Analysis (opens in a new tab) is the service behavior that automatically scans container artifacts stored in Artifact Registry (opens in a new tab) for known vulnerabilities. The scan starts when a new image is uploaded to Artifact Registry, extracts information about system packages in the container, and then continuously monitors the scanned image metadata for new vulnerabilities. When Artifact Analysis receives new and updated information from vulnerability sources, it updates image metadata, creates new vulnerability occurrences for new notes, and deletes occurrences that are no longer valid.

Artifact Analysis also supports earlier checks before images reach the registry. On-Demand Scanning scans container images locally for operating system, Go, and Java vulnerabilities so teams can fix issues before storing images in Artifact Registry. For stored images, Artifact Analysis can generate a software bill of materials (SBOM) and store Vulnerability Exploitability eXchange (VEX) statements that record exploitability decisions for the images in Artifact Registry.

3.3Deployment Policy Enforcement With Binary Authorization

Deployment policy enforcement with Binary Authorization is the deploy-time control that ensures only trusted code runs on GKE and Cloud Run. Binary Authorization attaches configurable signatures to container images, also called attestations, that help validate that a required process was completed. At deployment time, Binary Authorization checks those attestations against policy and blocks deployment when the required attestations are missing.

A Binary Authorization policy can require different proofs for different environments. Common policy checks include:

• Verify that a specific build system or CI pipeline created the container image.
• Validate that the image complies with a vulnerability signing policy.
• Verify that the image passes promotion criteria for the next environment, such as from development to QA.

This creates an ordered chain of trust from source to runtime:

1. Build: Cloud Build runs the build and records provenance, SLSA level, and artifact vulnerabilities.
2. Scan: Artifact Analysis scans the image in Artifact Registry and keeps findings current as vulnerability data changes.
3. Attest: A trusted authority signs the image when checks such as build identity, vulnerability review, and environment promotion are satisfied.
4. Enforce: Binary Authorization permits deployment to GKE or Cloud Run only when the required attestations are present.

3.4Monitoring Production and Blocking Vulnerable Packages

Monitoring production and blocking vulnerable packages extends pipeline enforcement into running workloads. Security Command Center provides the unified interface for continuous monitoring, findings, and posture drift across running workloads. Security Command Center can run attack path simulations that show how an attacker could chain minor vulnerabilities from the internet to high-value resources, detect toxic combinations where grouped risks create a path to those resources, and monitor active workloads with Container Threat Detection and Cloud Run Threat Detection for threats such as evasive exploits, reverse shell executions, and unauthorized cryptomining binaries.

Web and workload signals flow into the same response loop as pipeline signals. Web Security Scanner, part of Security Command Center, crawls App Engine, Compute Engine, and GKE web applications from starting URLs, follows links in scope, exercises user inputs and event handlers, and reports common issues such as cross-site scripting, code injection, mixed content, and outdated libraries. The GKE security posture dashboard adds opinionated recommendations on cluster settings, workload configuration, and container vulnerabilities, while the Cloud Run security panel shows SLSA compliance, build provenance, and vulnerabilities for running services. Artifact guard (opens in a new tab) extends blocking beyond deploy time by helping prevent deployment of vulnerable packages throughout the build process across three policy scopes: CI/CD platform, registry, and runtime, supporting broader security and compliance controls (opens in a new tab).

Key Facts

• Artifact Analysis automatically scans images pushed to Artifact Registry and continuously monitors stored image metadata for new vulnerabilities for up to 30 days.
• A note in Artifact Analysis describes a specific vulnerability, while an occurrence is created for each instance of that note associated with a particular image.
• Binary Authorization permits deployment to Google Kubernetes Engine and Cloud Run only when required attestations are present and blocks all other deploys.
• Security Command Center findings that expose resources in the high-value resource set receive higher attack exposure scores, so teams fix high-risk exposures first.
• Findings from Security Command Center should be exported through a Pub/Sub topic for automatic triage, with Cloud Asset Inventory feeds providing real-time notifications of resource changes.