Securing your software delivery pipeline

Software production and delivery can be viewed as a supply chain in which the same developer can be both a software producer (by developing software) and a consumer (by using existing software as a dependency for the app being developed).

This section is a high-level overview of some of the security threats against a software delivery pipeline, as well as some best practices that help protect against those threats. In later chapters, we describe how to implement some of the best practices, using Google Cloud-managed services.

First, let’s look at the security of your source code.

Source code management threats and remediations

Threats to source code management systems affect the security of the source code. These threats can come from the code itself (for example, submitting source code that is unintentionally or intentionally vulnerable) or can be threats to the source control platform, which can be compromised in different ways. The next section lists some practices to help ensure your source code is safe.

Source code management security best practices

The following is a list of security best practices to protect the integrity of your source code:

• Repository configuration: Configure repositories using a secure, automated method that offers preconfigured templates based on the application’s security level.

  Enforce centralized identity management with multi-factor authentication (MFA) for users, ensuring updated access privileges. Limit repository ownership to a few trusted employees, integrate identity management systems, and require dual approval for merges to enhance security.

• Code reviews: Code reviews are one of the most important practices to ensure software quality and security and should always be part of a secure software supply chain.

  Reviewers should be assigned to a repository application or a specific commit based on expertise in the programming language and relevant security risks. Perform code reviews on feature-branch pull requests as soon as developers are ready.

  In addition to human code reviews, implement static code analysis tools.

• Merge approvals: Establish a select group of trusted individuals to authorize merges into production branches. For applications with stricter security requirements, implement a process that requires more than one approver.

Now, let’s look at security for your build process.

Build threats and remediations

The following are some examples of security threats to the artifact build process and tools:

• Builds that use modified source code (not from a trusted source control system)
• Compromise of the build system
• Artifacts built outside of the official build system and process
• Compromise of the artifact storage system

The following section lists some practices to help ensure the security of your build process.

Build security best practices

The Supply-chain Levels for Software Artifacts (SLSA) specification defines a set of build-security best practices. These are established by multiple software-industry organizations under the Open Source Security Foundation (OpenSSF) (https://openssf.org/).

SLSA (http://slsa.dev) is a specification meant to help you describe and improve your software supply chain security. It’s structured as a series of tracks, each one covering an aspect of supply chain security, and levels, with each level offering progressively stronger security guidelines and requirements for each track.

At the time of this writing, the SLSA specification is at version 1.0, the first stable release of SLSA. SLSA v1.0 consists of only one track: Build. Future versions of SLSA will add tracks that cover other parts of the software supply chain.

Each level includes a set of requirements for the build process: lower-level requirements are easier to implement but provide lower security guarantees. Higher-level requirements are harder and usually more expensive to adopt but demonstrate that tougher security guidelines have been adopted for software build practices.

The level-based structure also allows you to incrementally adopt the guidelines, progressively improving the security posture of your software supply chain.

The primary goal of the SLSA Build track is to attest and verify that an artifact was built as expected. This is done mainly by generating build provenance, which software consumers can verify. The SLSA v1.0 Build track includes three levels: L1 to L3. There is also an L0 level, which refers to software that doesn’t meet any SLSA requirements. The following table summarizes the build levels:

Table 1.1 – SLSA v1 Build tracks

These security levels, and descriptions thereof, are from the SLSA specification, version 1.0, courtesy of the SLSA Working Group. You can find more details on the requirements for each level at http://slsa.dev.

In the next section, we’ll talk about threats in your code’s dependencies and some practices for remediating those threats.

Dependency threats and remediations

Dependency threats are vulnerabilities or intentionally malicious code in any software that your application depends on.

Dependency management best practices

The following is a list of security best practices for managing dependencies:

• Scan dependencies for vulnerabilities: Integrate a scanning tool into the development and build workflow that identifies vulnerabilities, using databases such as the National Institute of Standards of Technology National Vulnerability Database (NIST NVD).
• Store dependencies in a private registry: A private registry offers the convenience of a public repository, with enhanced control over dependencies. It can provide capabilities such as access control, vulnerability scanning, and repository management.
• Remove unused dependencies: Regularly cleaning up unneeded dependencies keeps your application lean and nimble, improving its performance and reducing its attack surface. This proactive approach helps minimize potential security risks associated with outdated or irrelevant dependencies.
• Use open source tools to track dependency insights: Various tools can help you to get information on dependencies. Here are two examples:
  • Open Source Insights (https://deps.dev/): A website that provides information about software packages vulnerabilities and licenses.
  • Open Source Vulnerability (OSV) Database (https://osv.dev/): A searchable vulnerability database.

This section described how to secure your software delivery pipeline, including a look at how your code and its dependencies can face vulnerabilities.