Software Supply Chain Security

Introduction to Software Supply Chain Security

For a Professional Cloud Architect, security doesn't end with a firewall. In modern cloud-native environments, the code itself—and the tools used to build and deploy it—are primary targets for attackers. Software Supply Chain Security is the practice of ensuring that only trusted, verified code reaches your production environment.

Google Cloud implements this using a "Shift Left" approach, integrating security into the very first stages of the development lifecycle.

Plain-Language Explanation: Software Supply Chain Security

Supply chain security is like the rigorous safety checks in a high-end food manufacturing plant.

Analogy 1 — The Certified Organic Seal (Attestations)

Imagine you're buying organic milk. How do you know it's actually organic? You look for a Certified Seal. In GCP, an Attestation is that digital seal. When a build system (Cloud Build) successfully tests and scans a container, it "signs" the container with a digital seal saying, "This container passed the safety test."

Analogy 2 — The Security Guard at the Loading Dock (Binary Authorization)

Binary Authorization is the Security Guard at the loading dock of your grocery store (Production Environment). When a truck (Container) arrives, the guard doesn't just look at the driver. They check the paperwork for the Certified Seal. If the seal is missing or forged, the truck is blocked from unloading. It doesn't matter how important the delivery is; no seal means no entry.

Analogy 3 — The Ingredient List (SBOM)

An SBOM (Software Bill of Materials) is like the Ingredient List on a box of cereal. It tells you exactly what's inside—every library, every package, and every dependency. If a health inspector (Security Scanner) discovers that a specific ingredient (a library like Log4j) is poisonous (vulnerable), you can instantly check your ingredient lists to see which boxes need to be recalled.

The SLSA Framework — Levels 1 to 4 in Detail

SLSA (Supply-chain Levels for Software Artifacts), pronounced "salsa", is the framework Google open-sourced and donated to OpenSSF. It defines progressively stricter requirements across four levels, each adding new tamper-resistance guarantees over the previous one.

Level 1 — Documented Build Process

The build must be fully scripted and automated, and it must produce provenance — a metadata record describing how the artifact was built (source, build steps, dependencies). Cloud Build satisfies this by emitting a Build resource with steps, images, and logsBucket. Level 1 alone doesn't prevent tampering; it just makes the process auditable.

Level 2 — Tamper-resistant Build Service with Signed Provenance

The build runs on a hosted service (not a developer laptop), and the provenance is signed by the build service. Cloud Build with Artifact Analysis automatically generates SLSA Level 2 provenance for container images stored in Artifact Registry. The signature is verifiable via the public key endpoint https://cloudbuild.googleapis.com/.well-known/jwks.json.

Level 3 — Hardened Builds with Non-falsifiable Provenance

Build platform runs in an ephemeral, isolated environment. Each build gets a fresh VM, no persistent state, and the build service prevents users from injecting their own provenance. Cloud Build private pools with --peered-network and disabled SSH meet this bar. The provenance is signed inside the trusted build platform — the build user cannot forge it.

Level 4 — Two-party Review + Hermetic Builds

The highest level adds two-person review of all source changes and hermetic, reproducible builds (no network access during build; same inputs always produce identical bit-for-bit outputs). Achievable on GCP only with significant effort — typically using Bazel with --config=remote plus enforced branch protection requiring two approvers.

Key GCP Security Services

1. Artifact Registry

A secure, central location to store your container images and language packages (Maven, npm, Python). It integrates directly with security scanning.

2. Artifact Analysis

Automatically scans your images in Artifact Registry for vulnerabilities (CVEs).

• On-push Scanning: Scan whenever a new image is uploaded.
• Continuous Analysis: Automatically re-scans images when new vulnerabilities are discovered in the global CVE database.

3. Binary Authorization

A deploy-time security control for GKE and Cloud Run.

• Policy Enforcement: You define a policy that says "Only images signed by the QA team can be deployed."
• Attestors: The entities (e.g., Cloud Build, a security tool, or a human manager) that provide the digital signatures.

Building a Secure Pipeline

A professional architect designs a "Locked-down" pipeline:

1. Source: Code is stored in a secure repo with protected branches.
2. Build (Cloud Build): The build runs in an isolated environment. Artifact Analysis scans for vulnerabilities.
3. Attest: If the scan is clean and tests pass, a digital signature (Attestation) is created.
4. Deploy (GKE/Cloud Run): Binary Authorization checks for the signature. If valid, the deployment proceeds. If not, it is blocked and an alert is sent.

Vulnerability Management Strategy

• Prioritization: Focus on "Critical" and "High" vulnerabilities that have a known "Fix available."
• Automatic Patching: Use tools to automatically create Pull Requests when a dependency needs updating.
• Vulnerability Exceptions: Occasionally, a vulnerability is found that doesn't apply to your specific use case. Artifact Analysis allows you to document and "acknowledge" these exceptions.

Artifact Registry Container Scanning Deep Dive

Artifact Registry is GCP's unified package repository, replacing the older Container Registry (gcr.io). For supply chain security, two scanning behaviors matter most.

On-push Scanning

Whenever an image is pushed via docker push <region>-docker.pkg.dev/<project>/<repo>/<image>:<tag> or gcloud artifacts docker images upload, Artifact Analysis automatically extracts the image manifest, identifies installed OS packages (Debian, Ubuntu, RHEL, Alpine, etc.) and language packages (Maven, Go, npm, Python, Nuget), then matches them against the NVD / OSV / vendor advisories. Results typically appear within 60 seconds for small images, up to several minutes for large ones.

Continuous Analysis

Once an image is scanned, it stays in a watch list. When a new CVE is disclosed and matches a package version already in your image, the Occurrence is updated automatically — you don't have to re-push the image. This is the only realistic way to detect zero-day vulnerabilities like Log4Shell in already-deployed images.

Enabling and Querying

# Enable scanning at the project level
gcloud services enable containerscanning.googleapis.com

# Query CVEs for a specific image
gcloud artifacts docker images list-vulnerabilities \
  us-central1-docker.pkg.dev/my-proj/repo/myapp:v1 \
  --format="table(vulnerability.effectiveSeverity,vulnerability.shortDescription)"

Scanning Coverage Tiers

• Standard tier (free up to N scans/month): OS packages only — Debian, Ubuntu, Alpine, RHEL, CentOS.
• Premium tier (Security Command Center Premium): OS + language packages (Go, Java, JavaScript, Python, .NET) + continuous analysis.

Limits and Pitfalls

• Scanning supports Docker v2 and OCI manifests — distroless and FROM scratch images may have limited package metadata.
• Multi-arch manifest lists are scanned per-architecture; results aggregate but you must query each digest.
• Vulnerabilities discovered after image deletion are lost — keep important production tags retained via Artifact Registry's cleanup policies with a KEEP rule.

Artifact Analysis API — Vulnerabilities and Provenance Occurrences

The Artifact Analysis API (containeranalysis.googleapis.com) is the metadata layer that stores scan results, attestations, SBOMs, and build provenance as a graph of Notes and Occurrences.

Notes vs Occurrences

• A Note is a class of finding — e.g., "CVE-2021-44228 in log4j-core 2.14.1".
• An Occurrence is an instance of that Note linked to a specific resource — e.g., "CVE-2021-44228 found in image sha256:abc123 layer 4".

This separation lets a single CVE Note reference thousands of affected image Occurrences without duplication.

Provenance Occurrences

When Cloud Build produces an image with SLSA Level 2+ provenance, Artifact Analysis stores a BUILD kind Occurrence containing:

• The git commit SHA of the source.
• The build steps, their container images, and arguments.
• The builder identity (Cloud Build service account email).
• A signed JWT payload that anyone can verify against Google's public keys.

Querying Provenance via gcloud

gcloud artifacts docker images describe \
  us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123 \
  --show-provenance

Filtering with Resource Manager

You can list all critical CVE Occurrences across an entire org:

gcloud container analysis occurrences list \
  --project=my-proj \
  --filter='kind="VULNERABILITY" AND vulnerability.severity="CRITICAL"'

Binary Authorization Attestations and Policy Modes

Binary Authorization is the runtime gatekeeper. It evaluates a deployment policy at admission time and either allows, blocks, or audit-logs the action.

Attestor Anatomy

An Attestor has three parts:

1. A Note in Artifact Analysis (the public name of the seal).
2. A PKIX public key (or KMS-backed key) used to verify signatures.
3. An IAM binding controlling who can create attestations against this attestor.

Creating and Signing

# Create the attestor
gcloud container binauthz attestors create prod-attestor \
  --attestation-authority-note=prod-attestor-note \
  --attestation-authority-note-project=my-proj

# Sign an image (Cloud Build typically does this automatically)
gcloud beta container binauthz attestations sign-and-create \
  --artifact-url="us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123" \
  --attestor=prod-attestor \
  --keyversion=projects/my-proj/locations/global/keyRings/binauthz/cryptoKeys/prod/cryptoKeyVersions/1

Policy Evaluation Modes

• ALWAYS_ALLOW: Bypass — used in dev clusters.
• ALWAYS_DENY: Hard block — rare, used only for isolated clusters.
• REQUIRE_ATTESTATION: The most common — image must have a valid attestation from every listed attestor.
• ALWAYS_ALLOW with dryRunOnly: true: Audit mode — policy violations are logged to Cloud Audit Logs but deployments proceed. Use this when rolling out a new policy.

Cluster-specific Rules

Default policy applies cluster-wide, but you can override per cluster with clusterAdmissionRules. A typical setup:

• projects/my-proj/zones/us-central1-a/clusters/dev → ALWAYS_ALLOW
• projects/my-proj/zones/us-central1-a/clusters/prod → REQUIRE_ATTESTATION with prod-attestor

Continuous Validation (CV)

Even after admission, Continuous Validation re-checks running pods every 24 hours and emits Cloud Logging entries if a pod is no longer compliant (e.g., the attestation was revoked). This catches the case where a policy tightens after deployment.

SBOM Generation — SPDX and CycloneDX on GCP

A Software Bill of Materials is no longer optional — US Executive Order 14028 requires SBOMs for software sold to federal agencies, and the EU Cyber Resilience Act expects similar disclosure.

Two Industry Standards

• SPDX (Software Package Data Exchange): Linux Foundation standard, ISO/IEC 5962:2021. Tag-value, JSON, YAML, or RDF formats. Strong on licensing metadata.
• CycloneDX: OWASP-maintained, JSON/XML, optimized for security use cases. Includes VEX (Vulnerability Exploitability eXchange) and dependency relationships.

GCP Artifact Analysis can export SBOMs in both formats from any scanned image:

# Export SPDX
gcloud artifacts sbom export \
  --uri=us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123 \
  --format=SPDX

# Export CycloneDX
gcloud artifacts sbom export \
  --uri=us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123 \
  --format=CYCLONEDX

SBOM Storage Pattern

Best practice is to store SBOMs in a dedicated Cloud Storage bucket with object versioning and a Bucket Lock retention policy (e.g., 7 years) so they're tamper-proof for compliance audits.

Open-source SBOM Tools that Integrate

• Syft (Anchore) — generates SBOMs from filesystems, container images, or registries.
• Trivy (Aqua) — SBOM + vuln scanner.
• Tern — specialized for container images.

SBOM-driven Vulnerability Response

When CVE-2024-XXXX drops, you don't need to re-scan every image. Query the SBOM corpus with jq or load into BigQuery and run:

SELECT image_uri FROM `proj.security.sboms`
WHERE 'pkg:maven/org.apache.logging.log4j/[email protected]' IN UNNEST(components);

This converts a multi-day fire drill into a one-minute query.

Assured Open Source Software (Assured OSS)

Assured OSS is Google's curated repository of common open-source packages that Google itself uses, builds, and security-tests inside Google's infrastructure.

What You Get

• Packages built with Cloud Build on SLSA Level 3 infrastructure.
• Signed provenance for every artifact.
• Continuous vulnerability scanning by Google's security team.
• VEX statements indicating which CVEs are actually exploitable.
• Faster patches — Google often patches before upstream releases.

Supported Ecosystems (growing list)

• Java (Maven) — ~1,000+ packages including Guava, Apache Commons, Jackson, Log4j.
• Python (pip) — Django, Flask, requests, NumPy, etc.

How to Consume

Point your pom.xml or requirements.txt at the Assured OSS Artifact Registry remote repository:

<repository>
  <id>assured-oss</id>
  <url>https://us-maven.pkg.dev/cloud-aoss/maven</url>
</repository>

For Python:

pip install --index-url https://us-python.pkg.dev/cloud-aoss/python/simple/ django

When to Use vs. Public Mirrors

• High compliance (FedRAMP, HIPAA, FSI) → Assured OSS.
• General development → public mirrors with Artifact Registry remote caching is usually sufficient.
• Mixed approach → Pin critical libraries (crypto, auth, logging frameworks) to Assured OSS; let everything else use Maven Central via remote repo.

Dependency Review and Container Signing with Cosign

Dependency Review (Source-side)

Before code even hits Cloud Build, you should scan dependency PRs. Options:

• GitHub's Dependency Review Action — fails the PR if a new dep has a known CVE.
• OSV-Scanner (open-source by Google) — runs against go.sum, package-lock.json, Pipfile.lock, etc. Integrates with Cloud Build via a custom step.
• Renovate / Dependabot — automated PRs that bump deps when CVEs are disclosed.

Cosign Container Signing

cosign (from the Sigstore project) is the de facto open-source standard for signing OCI artifacts. It complements Binary Authorization — you can use cosign signatures as input to Binary Authorization attestations.

# Sign with a KMS-backed key (recommended for production)
cosign sign --key gcpkms://projects/my-proj/locations/global/keyRings/cosign/cryptoKeys/prod \
  us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123

# Verify
cosign verify --key gcpkms://projects/my-proj/locations/global/keyRings/cosign/cryptoKeys/prod \
  us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123

Keyless Signing with Sigstore

cosign also supports keyless signing using OIDC identity — the signature is bound to a workload identity (GitHub Actions, Cloud Build SA), and the public key is logged in Rekor (a transparency log). This eliminates long-lived signing keys but requires trusting Sigstore's Fulcio CA.

GitHub Actions OIDC and Build Provenance Verification

Many teams build in GitHub Actions and deploy to GCP. The secure pattern uses Workload Identity Federation so GitHub can authenticate to GCP without service account keys.

OIDC Trust Configuration

gcloud iam workload-identity-pools create github-pool --location=global

gcloud iam workload-identity-pools providers create-oidc github-provider \
  --workload-identity-pool=github-pool --location=global \
  --issuer-uri=https://token.actions.githubusercontent.com \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository"

Then bind a service account to a specific repo and branch:

gcloud iam service-accounts add-iam-policy-binding \
  [email protected] \
  --role=roles/iam.workloadIdentityUser \
  --member="principalSet://iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/github-pool/attribute.repository/myorg/myrepo"

GitHub Build Attestations

Since 2024, GitHub natively produces SLSA v1.0 provenance for any artifact built in Actions. The actions/attest-build-provenance action signs the attestation with a Sigstore-backed ephemeral certificate tied to the workflow's OIDC token.

- uses: actions/attest-build-provenance@v1
  with:
    subject-name: us-central1-docker.pkg.dev/my-proj/repo/myapp
    subject-digest: sha256:abc123
    push-to-registry: true

Verifying GitHub-built Images in GKE

On the deploy side, your Binary Authorization policy can require an attestation signed by GitHub's Sigstore identity. Alternatively, use gh attestation verify in a Cloud Build pre-deploy step.

Pitfalls

• pull_request workflows run with read-only tokens and can't generate trustworthy attestations. Only sign on push to protected branches or release events.
• Reusable workflows must be referenced by SHA, not by tag — tags are mutable and can be hijacked.
• GITHUB_TOKEN leakage — never echo it; treat it as a write-capable credential to your repo.

FAQ — Software Supply Chain Security

Q1. What is an SBOM?

A Software Bill of Materials is a comprehensive list of all components, libraries, and dependencies used in a piece of software. It is essential for tracking where a vulnerable library might be used in your organization.

Q2. Does Binary Authorization work with non-Google containers?

Yes. As long as the container is stored in Artifact Registry and you have a process to sign it, Binary Authorization can enforce policies on any image.

Q3. What happens if Binary Authorization blocks a critical production fix?

Binary Authorization has a "Break-glass" mode. This allows an emergency deployment to bypass the policy. However, every "break-glass" event is logged and should be audited immediately.

Q4. Is Artifact Analysis free?

Basic vulnerability scanning has a cost per image scanned. Continuous analysis also carries a small monthly fee per image.

Q5. Why is "Shift Left" important?

Shifting Left means moving security checks earlier in the development process. It is much cheaper and faster to fix a vulnerability during the build phase than it is to respond to a security breach in production.

Final Architect Tip

For the PCA exam, focus on the Artifact Analysis + Binary Authorization duo. This is the primary architectural pattern for supply chain security. If a scenario mentions "ensuring only approved images are deployed," the answer is Binary Authorization. If it mentions "tracking vulnerabilities in container images," the answer is Artifact Analysis. Also, be familiar with the SLSA framework as the industry standard for build integrity.