Scanning and Cleanup Policies

Introduction: Why Scanning and Cleanup Matter

Welcome to the fifth and final lesson in our course on working with container registries . You've built a solid foundation in Google Artifact Registry fundamentals, created secure repositories, mastered the push-pull workflow, and successfully deployed container images. Now it's time to learn how to manage those images responsibly over time through vulnerability scanning and cleanup policies . Vulnerability scanning automatically analyzes your images against databases of known vulnerabilities through the Container Analysis API, providing detailed security reports as new threats are discovered in container components. Cleanup policies provide automated rules that remove old, unused, or untagged images, preventing repositories from accumulating hundreds of versions that lead to unnecessary storage costs and operational complexity. You'll achieve two key outcomes: viewing vulnerability scan findings using the gcloud artifacts docker images describe command for security analysis and creating automated cleanup rules using the gcloud artifacts repositories set-cleanup-policies command with configuration files.

Prerequisites and Context

Before diving into vulnerability scanning and cleanup policies, you need to ensure you have the proper foundation from previous lessons and understand the permissions required for these advanced Artifact Registry operations. You should have an existing Artifact Registry repository with at least one container image — specifically, the my-web-app repository with a Docker image tagged as latest from lessons two and three. Additionally, you should have enabled the Container Analysis API at the project level in an earlier lesson, which automatically enables vulnerability scanning for all images pushed to any repository in your project. You can verify your repository exists by running the familiar command from previous lessons. Shellgcloud artifacts repositories describe my-web-app \ --location=us-central1 This command should return details about your repository, including the repository format, creation time, and configuration settings. You can also check which images exist in your repository using the list command. Shellgcloud artifacts docker images list \ us-central1-docker.pkg.dev/PROJECT_ID/my-web-app For the advanced operations covered in this lesson, your Google Cloud credentials need appropriate IAM permissions beyond the basic push and pull permissions you used previously. The essential roles are: Vulnerability Scanning: roles/artifactregistry.reader: Allows you to view repository contents and image metadata. roles/containeranalysis.occurrences.viewer: Lets you retrieve and view vulnerability scan results from the Container Analysis API. Cleanup Policy Management: roles/artifactregistry.repoAdmin: Required for setting or updating cleanup policies on repositories. The writer role is insufficient for policy management. roles/artifactregistry.reader: Allows viewing existing cleanup policies and repository configurations (read-only access). Permission Summary for Common Operations: Create repositories: Requires roles/artifactregistry.repoAdmin Push images: Requires roles/artifactregistry.writer or higher Pull images: Requires roles/artifactregistry.reader or higher View vulnerability scans: Requires roles/containeranalysis.occurrences.viewer Set cleanup policies: Requires roles/artifactregistry.repoAdmin These permissions are required in addition to the standard push and pull permissions for Artifact Registry. Most Google Cloud environments that provide Artifact Registry access include these permissions in standard roles, but if you encounter permission denied errors during this lesson, verify these specific roles in your IAM policies. The permissions can be granted at the project level or for specific repositories, allowing you to control access granularly based on your security requirements. As with all Artifact Registry operations, consistency in location and repository naming remains critical. Your gcloud commands must use the same location where your repository exists, and repository names must exactly match those used during creation. Double-check these details if you encounter "repository not found" errors during vulnerability scanning or cleanup policy operations.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Viewing Vulnerability Scan Findings

Google Artifact Registry provides automatic vulnerability scanning through the Container Analysis API, which you enabled at the project level in an earlier lesson. Vulnerability scanning is a project-wide setting — once enabled, the Container Analysis API automatically scans all images pushed to any repository in your project, analyzing each layer for known vulnerabilities and continuously updating results as new vulnerability databases become available. You do not configure scanning per-repository; it applies to all repositories in your project.

When you pushed your Docker image in lesson three, the Container Analysis API automatically began scanning it in the background. You can retrieve vulnerability count summaries for any image using the gcloud artifacts docker images describe command with the --show-package-vulnerability flag, which provides high-level vulnerability statistics.

Shell

gcloud artifacts docker images describe \
  us-central1-docker.pkg.dev/PROJECT_ID/my-web-app/my-web-app:latest \
  --show-package-vulnerability

gcloud artifacts docker images describe \
  us-central1-docker.pkg.dev/PROJECT_ID/my-web-app/my-web-app:latest \
  --show-package-vulnerability

The scan findings output provides vulnerability counts by severity level.

text

Listing items under project PROJECT_ID.

IMAGE: us-central1-docker.pkg.dev/PROJECT_ID/my-web-app/my-web-app:latest
CREATE_TIME: 2024-01-15T10:30:45
UPDATE_TIME: 2024-01-15T10:35:22
DIGEST: sha256:8f2a1b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a
VULNERABILITIES:
  CRITICAL: 2
  HIGH: 5
  MEDIUM: 12
  LOW: 8
  TOTAL: 27

Listing items under project PROJECT_ID.

IMAGE: us-central1-docker.pkg.dev/PROJECT_ID/my-web-app/my-web-app:latest
CREATE_TIME: 2024-01-15T10:30:45
UPDATE_TIME: 2024-01-15T10:35:22
DIGEST: sha256:8f2a1b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a
VULNERABILITIES:
  CRITICAL: 2
  HIGH: 5
  MEDIUM: 12
  LOW: 8
  TOTAL: 27

This summary view is ideal for quickly assessing the overall security posture of an image. Critical and High severity vulnerabilities represent the most serious security risks that should be addressed immediately. Medium findings represent moderate risks for regular maintenance cycles, while Low findings often indicate minor improvements that can be addressed as time permits.

For detailed information about each vulnerability — including CVE identifiers, affected packages, and specific remediation steps — use the separate gcloud artifacts docker images list-vulnerabilities command.

Shell

gcloud artifacts docker images list-vulnerabilities \
  us-central1-docker.pkg.dev/PROJECT_ID/my-web-app/my-web-app:latest

gcloud artifacts docker images list-vulnerabilities \
  us-central1-docker.pkg.dev/PROJECT_ID/my-web-app/my-web-app:latest

This command provides comprehensive details for each vulnerability found in the image. Each detailed finding includes the CVE identifier, affected package name and version, vulnerability description, severity rating, and which container layer contains the vulnerable component. When working with images that have many findings, add the optional --limit=N flag to control pagination (e.g., --limit=10 shows only the first 10 vulnerabilities).

When triaging scan findings, focus first on Critical and High severity vulnerabilities affecting packages exposed to network traffic or user input. Research each CVE to understand specific attack vectors and determine whether your deployment context exposes you to the vulnerability.

The most effective approach to addressing scan findings involves updating base images, upgrading vulnerable packages, and rebuilding container images with the latest security patches integrated into your regular development workflows.

Applying and Verifying Cleanup Policies

Apply your cleanup policy to a repository using the gcloud artifacts repositories set-cleanup-policies command.

Shell

gcloud artifacts repositories set-cleanup-policies my-web-app \
  --location=us-central1 \
  --policy=cleanup-policy.json

gcloud artifacts repositories set-cleanup-policies my-web-app \
  --location=us-central1 \
  --policy=cleanup-policy.json

The --policy flag reads policy content from your local file. On success, gcloud returns a confirmation message.

Updated cleanup policies for repository [my-web-app].

Updated cleanup policies for repository [my-web-app].

Verify the policy configuration by retrieving the repository details.

Shell

gcloud artifacts repositories describe my-web-app \
  --location=us-central1

gcloud artifacts repositories describe my-web-app \
  --location=us-central1

This command returns the complete repository configuration, including active cleanup policies.

Encryption: Google-managed key
Repository Size: 245.3MB
Create Time: 2024-01-10T08:15:30
Update Time: 2024-01-15T11:20:45
Cleanup Policies:
  rules:
  - action: DELETE
    condition:
      tagState: UNTAGGED
      olderThan: 604800s

Encryption: Google-managed key
Repository Size: 245.3MB
Create Time: 2024-01-10T08:15:30
Update Time: 2024-01-15T11:20:45
Cleanup Policies:
  rules:
  - action: DELETE
    condition:
      tagState: UNTAGGED
      olderThan: 604800s

Artifact Registry evaluates cleanup policies on a regular schedule (typically daily). Policy effects are not immediate — new policies take effect during the next scheduled evaluation cycle, providing a safety buffer against accidental deletion due to configuration errors.

Monitor policy effects by checking your repository's image list periodically.

Shell

gcloud artifacts docker images list \
  us-central1-docker.pkg.dev/PROJECT_ID/my-web-app

gcloud artifacts docker images list \
  us-central1-docker.pkg.dev/PROJECT_ID/my-web-app

Over time, you should see that images matching your policy criteria are automatically removed while protected images remain available.

Introduction: Why Scanning and Cleanup Matter

Prerequisites and Context

Join the 1M+ learners on CodeSignal

Viewing Vulnerability Scan Findings

Cleanup Policy Model

Applying and Verifying Cleanup Policies

Pitfalls & Best Practices

Lesson Wrap-Up