Professional Cloud DevOps Engineer

Software Supply Chain Security

Understanding Software Supply Chain Security

A software supply chain includes all the code, people, systems, and processes that work together to develop and deliver software to users. Because attackers can target any part of this chain, organizations need ways to verify that their software has not been tampered with and comes from trusted sources. Google Cloud provides tools that help DevOps teams track what goes into their applications, verify build integrity, and block untrusted code from running in production. This approach protects against threats like malicious code injection, compromised dependencies, and unauthorized changes to deployed applications.

Applying the SLSA Framework

The Supply-chain Levels for Software Artifacts (SLSA) framework provides a systematic way to secure build processes and prove that software has not been altered. SLSA defines different maturity levels, where higher levels require more rigorous security controls. Achieving SLSA Level 2 means using immutable version control and keeping documented change histories. Moving to Level 3 requires verified source history and strict retention policies, while Level 4 mandates that two people review every code change before it is accepted.

Cloud Build on Google Cloud natively supports SLSA Level 3 for container builds and automatically generates authenticated build provenance, which is a verifiable record that shows what source code was used, which build tools ran, and what the final image looks like. Teams store this provenance alongside their artifacts to prove the build's integrity later. The framework also encourages generating a Software Bill of Materials (SBOM), which lists all dependencies so teams know exactly what their software contains.

Implementing Binary Authorization

Binary Authorization is a security service that ensures only trusted container images can deploy to environments like GKE or Cloud Run. The system works by checking for valid attestations before allowing any deployment. An attestation is a digital signature created by a trusted party after an image passes security checks, such as vulnerability scanning. When you try to deploy an image, Binary Authorization verifies that attestations from your defined attestors exist; if they do not, the deployment is blocked.

To use Binary Authorization effectively, you integrate it with your CI/CD pipeline and container registry. After your build process completes and security scans pass, your pipeline creates attestations that certify the image meets your organization's standards. These attestations are stored in the container registry alongside the image. When a deployment triggers, Binary Authorization automatically checks for the required attestations before allowing the image to run. This creates a chain of trust from your build system through to production.

Policies define how Binary Authorization behaves. A default rule specifies whether to allow or deny images without attestations, while specific rules can require attestations from particular parties for certain deployments. You can make policies more permissive during development while enforcing strict controls in production. Policies can also reference external signing parties for cross-organization verification, which is useful when multiple teams or companies need to validate software.

Integrating Vulnerability Scanning

Scanning for vulnerabilities is essential for knowing what risks exist in your software before deployment. Artifact Analysis automatically scans container images stored in Artifact Registry when they are uploaded and continuously monitors for new vulnerabilities as threat intelligence evolves. For earlier feedback during development, On-Demand Scanning can run directly within Cloud Build steps right after images are built.

Scan results include details like the CVE identifier, severity score (CVSS), affected package, and version. Teams configure policy gates that parse these results and take action—for example, blocking deployment if any critical vulnerabilities exist. This automation enforces security standards without requiring manual review, supporting the shift-left security principle by catching problems early.

Scanning also extends to application dependencies through software composition analysis, which identifies vulnerabilities in language-specific packages like those used in Java, Go, or Python. This produces an SBOM that gives full visibility into all components. Binary Authorization can require attestations confirming that vulnerability scans passed before allowing deployment, linking scanning results to deployment decisions.

Continuous Monitoring and Runtime Security

Security does not end at deployment. Binary Authorization can continuously validate that running workloads meet current policy, even if the policy changes after deployment. Runtime environments provide additional security insights: the GKE Security Posture Dashboard and Cloud Run security panel display vulnerability information for deployed workloads, including SLSA build level compliance and build provenance details. This creates a feedback loop where teams can monitor for newly discovered vulnerabilities in production and respond with patches or rollbacks as needed.