Managing operations · Topic 1 of 3

CI/CD Scanning, Binary Authorization, Image Hardening and Posture

Automate CVE scanning in CI/CD, enforce Binary Authorization on GKE and Cloud Run, harden and patch images, and detect policy drift at scale.

5 min

In a nutshell

Artifact Analysis scans images in Artifact Registry; On-Demand Scanning gates the pipeline.
Binary Authorization blocks unattested images on GKE and Cloud Run; test in dry run.
Build golden images in a pipeline, publish to image families, restrict with compute.trustedImageProjects.

What it is

Security that depends on people remembering steps fails at scale. This topic is about building security into the pipeline: scanning images for known vulnerabilities (CVEs), allowing only approved images to run, producing hardened and patched images automatically, and detecting when deployed resources drift from policy.

How it works

Scanning for CVEs in CI/CD

Artifact Analysis scans container images for known vulnerabilities in the OS and language packages.

Mode	When it runs	Use
Automatic scanning	When an image is pushed to Artifact Registry, with results updated as new CVEs are published for recently used images	Continuous view of stored images
On-Demand Scanning	When the pipeline asks, before pushing	Fail a build on critical vulnerabilities

steps:
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', 'europe-docker.pkg.dev/prod-app/web/api:$SHORT_SHA', '.']
- name: gcr.io/google.com/cloudsdktool/cloud-sdk
  entrypoint: bash
  args:
  - -c
  - |
    gcloud artifacts docker images scan \
      europe-docker.pkg.dev/prod-app/web/api:$SHORT_SHA \
      --format='value(response.scan)' > scan_id.txt
    gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt) \
      --format='value(vulnerability.effectiveSeverity)' | grep -q CRITICAL && exit 1 || exit 0

Without --remote, the scan runs on the image built in the previous step, so nothing is pushed until the check passes; add the push step after it. Combine scanning with dependency review, Web Security Scanner for running web apps, and build provenance from Cloud Build.

Binary Authorization

Binary Authorization is a deploy-time control for GKE and Cloud Run. It checks each image against a policy and blocks images that lack required attestations.

Element	Meaning
Policy	Default rule plus optional rules per cluster or service
Evaluation mode	`ALWAYS_ALLOW`, `ALWAYS_DENY` or `REQUIRE_ATTESTATION`
Attestor	A signer, backed by a Cloud KMS key, that vouches for an image digest
Enforcement mode	`ENFORCED_BLOCK_AND_AUDIT_LOG`, or `DRYRUN_AUDIT_LOG_ONLY` to test
Exemptions	Image name patterns allowed without attestation, such as system images
Breakglass	An annotation for emergency deploys, always logged

name: projects/prod-app/policy
globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  requireAttestationsBy:
  - projects/prod-app/attestors/built-by-cloud-build

gcloud container binauthz policy import policy.yaml
gcloud run deploy api --image=IMAGE_URL --binary-authorization=default --region=europe-west1

A typical pipeline creates an attestation only after tests and the vulnerability check pass. Continuous validation for GKE also re-checks running pods against policy and logs violations.

Automating hardened VM and container images

Practice	How
Golden VM images	A pipeline builds custom images from a hardened base, publishes them to an image family, and deprecates old ones
Allow only trusted images	Organization policy `compute.trustedImageProjects` limits images to approved projects
Boot integrity	Shielded VM: Secure Boot, vTPM and integrity monitoring
OS patching	VM Manager patch jobs and scheduled patch deployments, with OS inventory to find unpatched VMs
Container base images	Minimal or distroless bases, rebuilt on a schedule so fixes reach every image
GKE nodes	Release channels with node auto-upgrade; Container-Optimized OS

Rebuild and redeploy rather than patch running containers. Images are immutable, so a fixed base image only helps once services run the new build.

Policy and drift detection at scale

Tool	Type	What it does
Custom organization policies	Preventive	Block non-compliant creates and updates using CEL
Security Health Analytics	Detective	Built-in detectors find misconfigurations such as public buckets or open firewalls
Security Health Analytics custom modules	Detective	Your own CEL checks on resource properties, reported as findings (Premium)
Security posture	Both	A deployed set of organization policies and detectors; drift from it is reported
Policy Controller	Preventive, GKE	Kubernetes admission policies for clusters
IaC validation	Before deploy	Check Terraform plans against posture policies in the pipeline

Cloud security posture management means defining the desired state once, preventing what you can, and detecting drift for the rest.

A worked example

A company deploys to Cloud Run and GKE from Cloud Build. The engineer adds On-Demand Scanning that fails builds with critical CVEs, and an attestation step after tests.

Binary Authorization requires that attestation in dry run for a week, then enforced. VM images come from a weekly golden image build, compute.trustedImageProjects allows only that project, and a Security Health Analytics custom module flags Cloud KMS keys without a rotation period.

How the exam asks about this

"Only container images built and approved by the CI pipeline may run on GKE." Binary Authorization requiring an attestation created by the pipeline.
"Fail the build if an image contains a critical vulnerability, before it reaches the registry." On-Demand Scanning in the Cloud Build pipeline.
"Detect resources that violate a company-specific configuration rule that no built-in detector covers." A Security Health Analytics custom module, or a custom organization policy to prevent it.

What to remember for the exam

Artifact Analysis scans images in Artifact Registry; On-Demand Scanning gates the pipeline.
Binary Authorization blocks unattested images on GKE and Cloud Run; test in dry run.
Build golden images in a pipeline, publish to image families, restrict with compute.trustedImageProjects.
VM Manager automates OS patching; containers are rebuilt and redeployed, not patched.
Custom organization policies prevent; Security Health Analytics and posture detect drift.

Watch out

Scanning finds problems but does not stop deployment by itself. Only a pipeline gate or Binary Authorization actually blocks a vulnerable image from running.

Common mistakes

Patching running containers in place. Changes are lost on restart and the image stays vulnerable. Fix the base image, rebuild and redeploy.

Enforcing Binary Authorization without exemptions. System and sidecar images can be blocked. Add allowlist patterns and start in dry run.

Relying only on detective controls. Findings arrive after the resource exists. Prevent what you can with organization policies.

Check yourself

What does Binary Authorization check before allowing a deployment?
That the image digest has the attestations required by the policy, unless an exemption or a different evaluation mode applies.
Which organization policy limits VMs to images from approved projects?
compute.trustedImageProjects.
What is the difference between a custom organization policy and a Security Health Analytics custom module?
The organization policy prevents non-compliant changes when they are made, while the custom module detects existing misconfigurations and reports findings.

Topic 1 of 3 in Managing operations

Test yourself on Managing operations

The full Google Cloud Professional Cloud Security Engineer question bank has 749 questions, with timed practice exams and an explanation for every answer.

Subscribe Try Sample Exam

This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.