Artifact Analysis, Binary Authorization, SLSA and Pipeline IAM

What it is

The pipeline is a target. If an attacker can push an image, change a build step or deploy directly, every control on the running service is bypassed. Software supply chain security makes sure only code that went through the trusted pipeline, and passed its checks, can run.

The pieces are scanning artifacts, proving how they were built, enforcing that proof at deploy time, and limiting who can act in each environment.

How it works

Artifact Analysis and vulnerability scanning

Artifact Analysis scans container images for known vulnerabilities in their operating system and language packages, and stores the results as metadata on the artifact.

- name: gcr.io/google.com/cloudsdktool/cloud-sdk
  entrypoint: bash
  args:
  - -c
  - |
    gcloud artifacts docker images scan "$_IMAGE:$SHORT_SHA" \
      --format='value(response.scan)' > /workspace/scan_id.txt
    gcloud artifacts docker images list-vulnerabilities "$(cat /workspace/scan_id.txt)" \
      --format='value(vulnerability.effectiveSeverity)' | grep -q CRITICAL && exit 1 || exit 0

Scanning reports problems; it does not block anything unless a pipeline step or a policy acts on the result.

SLSA and build provenance

Supply-chain Levels for Software Artifacts (SLSA) is a framework of increasing levels of assurance about how an artifact was produced. Its core idea is provenance: signed metadata saying which source, which builder and which steps produced an artifact.

images:
- '$_IMAGE:$SHORT_SHA'

Higher SLSA levels also need reviewed source changes and hardened build configuration that users cannot tamper with.

Binary Authorization

Binary Authorization is a deploy-time gate for GKE and Cloud Run. A policy says which images may run; images need attestations from trusted attestors, usually signed with Cloud KMS keys.

A pipeline usually creates an attestation only after tests and the vulnerability check pass. Cloud Build can also attest images it builds with the built-by-cloud-build attestor, so a policy can require that an image came from Cloud Build. This works only for images pushed through the images field (not a docker push step), with Binary Authorization in the same project; private pool builds also need requestedVerifyOption: VERIFIED.

gcloud run deploy web --image="$IMAGE" --region=europe-west1 \
  --binary-authorization=default

Roll out policies in dry run first, read the audit log entries, add exemptions, then enforce.

IAM policies based on environment

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: prod
requireApproval: true
gke:
  cluster: projects/shop-prod/locations/europe-west1/clusters/prod
executionConfigs:
- usages: [RENDER, DEPLOY]
  serviceAccount: deploy-prod@shop-prod.iam.gserviceaccount.com

A worked example

A company must prove that every production image came from its pipeline and has no critical vulnerabilities. The build runs On-Demand Scanning and fails on critical findings; images are listed under images so Cloud Build records provenance.

After tests, a step signs an attestation with a Cloud KMS key. The production GKE cluster rule requires that attestation, first in dry run for two weeks, then enforced, and only the production execution service account can deploy there.

How the exam asks about this

• "Only images built by the company's pipeline may run on the production GKE cluster." Require an attestation with Binary Authorization on that cluster.
• "Stop images with critical vulnerabilities before they are pushed." Use On-Demand Scanning in the build and fail the step.
• "A developer with staging access must not be able to deploy to production." Use separate projects and execution service accounts per target, and grant production promote and approve rights only to release managers.