Securing your software requires establishing, verifying, and maintaining a chain of trust. That chain establishes the provenance or origin trail of your code, via attestations, generated and checked throughout your software development and deployment process. At Google, the internal development process enables a level of security, through code review, verified code provenance, and policy enforcement that minimizes software supply chain and related risks. These concepts go hand-in-hand with improved developer productivity. What are the security risk points in your software supply chain and how can you mitigate them with Google Cloud? Let’s explore! 

Risk points for a software supply chain

The software development and deployment supply chain is quite complicated, with numerous threats along the source code, build, and publish workflow. Here are some common threats that software development supply chains face:

Also - Modifying an artifact in transit or compromising the underlying infrastructure of any of development lifecycle systems

How does Google secure the software supply chain internally?

Google employs several practices to secure its software supply chain internally:

• Zero trust (BeyondCorp)

• Incident and vulnerability response playbook

• OSS review board

• Binary Authorization on Borg 

Google Cloud is sharing these practices externally, so that the whole community can benefit. SLSA (Supply-chain Levels for Software Artifacts) is an end-to-end framework for supply chain integrity. It is an OSS-friendly version of what Google has been doing internally. In its current state, SLSA is a set of incrementally adoptable security guidelines being established by industry consensus. 

How does Google Cloud help you secure your software supply chain?

Securing your software supply chain involves defining, checking, and enforcing attestations across the software lifecycle. Here is how it works!

Binary Authorization

A key element in software supply chain security is the Binary Authorization service, which establishes, verifies, and maintains a chain of trust via attestations and policy checks. Essentially, cryptographic signatures are generated as code or other artifacts move towards production. Before deployment, the attestations are checked based on policies. 

Let’s walk through the steps of how to achieve ambient security in your developer process through policies and provenance on Google Cloud. The first step is understanding your supply or what libraries and frameworks you use to write your code.  

Code

Open source is heavily used in lots of software and it can be challenging to determine the risk of open source dependencies. To help address this challenge, we recently launched Open Source Insights, an interactive visualization site for exploring open source software packages. Open Source Insights is unique in that it provides a transitive dependency graph, with continuously updated security advisory, license, and other data across multiple languages in one place. In conjunction with open source scorecards, which provide a risk score for open source projects, Open Source Insights can be used by developers to make better choices across millions of open source packages.

Build

Once your code is checked in, it is built by Cloud Build. Here, another set of attestations are captured, adding to your chain of trust. Examples include what tests were run, what build tools and processes were used, and more. Cloud Build today helps with achieving a SLSA level 1, which denotes the level of security of your software supply chain. Cloud Build captures the source of the build configuration, which can be used to validate that the build was scripted (scripted builds are more secure than manual builds and this is a SLSA 1 requirement).  Also as required, these provenance and other attestations can be looked up using the container image digest, which is a unique signature for an image.

Cloud Build is a fully managed cloud service. This means that in addition to developer agility, this service gives you a locked-down environment for securing builds, greatly reducing the risk of compromised build integrity or a compromised build system.

You may also want to ensure you can enforce a security perimeter within your private network to keep data and access private. Cloud Build Private Pools adds support for VPC-SC and private IPs. You can take advantage of the locked down serverless build environment within your own private network.  

Test and Scan

Once the build is complete, it is stored in the Artifact Registry where it is automatically scanned for vulnerabilities. This generates additional metadata including an attestation for whether an artifact’s vulnerability results meet certain security thresholds. This information is stored by our container analysis service, which structures and organizes an artifact’s metadata, making it readily accessible to services like Binary Authorization.

Deploy and Run

Having built, stored, and scanned the images securely you are ready to deploy. At this point attestations captured along the supply chain are verified for authenticity by Binary Authorization. In enforcement mode, the image is deployed only when the attestations meet your organization's policy. In audit mode, policy violations are logged and trigger alerts. Binary Authorization is available for GKE and Cloud Run (preview)  ensuring only properly reviewed and authorized code gets deployed. Verification doesn't stop at deployment. Binary Authorization now also supports continuous validation, which ensures continued conformance to the defined policy even post-deployment. If a running application falls out of conformance with an existing or newly added policy an alert is triggered and logged. 

That was an introduction to the current supply chain capabilities of Google Cloud. To learn more, check out Binary Authorization and SLSA.  

For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev