Automatic vulnerability scanning

Container Analysis provides automatic vulnerability scanning and metadata storage for containers. This page describes vulnerability scanning.

This document explains concepts about automatic vulnerability scanning of container images on Artifact Registry and Container Registry. If you want to learn about manual vulnerability scanning see the On-Demand Scanning documentation.

Vulnerability scanning

Software vulnerabilities are weaknesses that can either cause an accidental system failure or result in malicious activity.

Container Analysis performs vulnerability scans on container images in Artifact Registry and Container Registry, it monitors the vulnerability information to keep it up to date. This process comprises two main tasks: scanning and continuous analysis.

When the scan of an image is completed, the produced vulnerability result is the collection of vulnerability occurrences for that image.

Scanning

Container Analysis scans new images when they're uploaded to Artifact Registry or Container Registry. This scan extracts information about the system packages in the container.

Container Analysis scans images only once, based on the image's digest. This means that adding or modifying tags won't trigger new scans, only changing the contents of the image will.

Container Analysis only detects packages publicly monitored for security vulnerabilities.

Manifest lists

You can also use vulnerability scanning with manifest lists. A manifest list is a list of pointers to manifests for several platforms. They allow a single image to work with multiple architectures or variations of an operating system.

Container Analysis vulnerability scanning only supports Linux amd64 images. If your manifest list points to more than one Linux amd64 image, only the first one will be scanned; if there are no pointers to Linux amd64 images, you won't get any scanning results.

Continuous analysis

Container Analysis creates occurrences for vulnerabilities found when you upload the image. After the initial scan, it continuously monitors the metadata for scanned images in Artifact Registry and Container Registry for new vulnerabilities.

As Container Analysis receives new and updated vulnerability information from vulnerability sources, it updates the metadata of the scanned images to keep it up-to-date, creating new vulnerability occurrences for new notes and deleting vulnerability occurrences that are no longer valid.

Vulnerability sources

Container Analysis supports package vulnerability scanning for Linux distributions and obtains CVE data from the following sources:

Supported versions

Container Analysis supports vulnerability scanning for the following OS versions:

  • Debian GNU/Linux - Versions: 9, 10, 11, 12, 13
  • Ubuntu - Versions: 12.04, 12.10, 13.04, 14.04, 14.10, 15.04, 15.10, 16.04, 16.10, 17.04, 17.10, 18.04, 18.10, 20.04
  • Alpine Linux - Versions: 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.11, 3.12, 3.13
  • CentOS - Versions: 6, 7, 8 and minor versions
  • Redhat - Versions: 6, 7, 8 and minor versions

Severity levels for vulnerabilities

Container Analysis uses the following severity levels:

  • Critical
  • High
  • Medium
  • Low
  • Minimal

The severity levels are qualitative labels that reflect factors such as exploitability, scope, impact, and maturity of the vulnerability. For example, if a vulnerability enables a remote user to easily access a system and run arbitrary code without authentication or user interaction, that vulnerability would be classified as Critical.

Two types of severity are associated with each vulnerability:

  • Effective severity - The severity level assigned by the Linux distribution. If distribution-specific severity levels are unavailable, Container Analysis uses the severity level assigned by the note provider.

  • CVSS score - The Common Vulnerability Scoring System score and associated severity level. Refer to the CVSS 2.0 documentation for details on how CVSS scores are calculated.

For a given vulnerability, the severity derived from a calculated CVSS score might not match the effective severity. Linux distributions that assign severity levels use their own criteria to assess the specific impacts of a vulnerability on their distributions.

Default Container Analysis service account

Container Analysis analyzes your container images using a service account, a special Google account that collects information about your images on your behalf. The email for the Container Analysis service account is service-[PROJECT_NUMBER]@container-analysis.iam.gserviceaccount.com. This account uses the Container Analysis Service Agent role.

If you enable vulnerability scanning, the Container Scanning API used by this feature also uses a special Google account. The email for that service account is service-[PROJECT_NUMBER]@gcp-sa-containerscanning.iam.gserviceaccount.com. The account uses the Container Scanner Service Agent role.

You can view your project's service accounts via the IAM menu of the Cloud Console.

Container Analysis interfaces

In the Cloud Console, you can view image vulnerabilities and image metadata for containers in Container Registry.

You can use the gcloud tool to view vulnerabilities and image metadata.

You can also use the Container Analysis REST API to perform any of these actions. As with other Cloud Platform APIs, you must authenticate access using OAuth2. After you have authenticated, you can use the API to create new notes and occurrences, view vulnerability occurrences, etc.

The Container Analysis API supports both gRPC and REST/JSON. You can make calls to the API either using the client libraries or using cURL for REST/JSON.

Controlling deployment of vulnerable images

Based on the vulnerability information provided by Container Analysis, you can use Binary Authorization to create a vulnerability allowlist as part of you Cloud Build pipeline. If the vulnerabilities violate the policy in the allowlist, the build fails.

You can also integrate Container Analysis with Binary Authorization to create attestations, which can prevent container images with known security issues from running in your deployment environment.

What's next