From fa524dd941927c6132bd6b0fff5ddbf5e5c65c8c Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 31 Oct 2024 14:28:56 -0400 Subject: [PATCH] More linting fixes Signed-off-by: Marina Moore --- .../suply-chain-security-paper-v2/SSCBPv2.md | 272 ++++++++---------- 1 file changed, 124 insertions(+), 148 deletions(-) diff --git a/community/working-groups/supply-chain-security/suply-chain-security-paper-v2/SSCBPv2.md b/community/working-groups/supply-chain-security/suply-chain-security-paper-v2/SSCBPv2.md index ed4266cb3..ed2dd04a0 100644 --- a/community/working-groups/supply-chain-security/suply-chain-security-paper-v2/SSCBPv2.md +++ b/community/working-groups/supply-chain-security/suply-chain-security-paper-v2/SSCBPv2.md @@ -3,7 +3,7 @@ Authors: Original White Paper authors, Marina Moore, Michael Lieberman, John Kjell, James Carnegie, Ben Cotton Reviewers: -# Scope: {#scope:} +## Scope: This new publication modernizes the original Supply Chain Best Practices whitepaper by highlighting changes and improvements to supply chain security tools and practices since the time of its writing. It also adds discussion of personas, and how different groups of people should approach this whitepaper to get relevant guidance. @@ -20,7 +20,7 @@ Ensures third parties are securing data, limiting access, monitoring for data se * Discussion of providing cryptographic verification that correct actions were performed (e.g., ensuring tests were actually run). * Updates to examples of attacks and tools to reflect recent changes. -## Out of Scope {#out-of-scope} +### Out of Scope The software supply chain security space is vast, so not all topics could be included in this document. The following is a non-comprehensive list of topics that did not fit in this paper, but could be explored in future work. @@ -36,7 +36,7 @@ The following is a non-comprehensive list of topics that did not fit in this pap * Incident response and mitigation * [Compliance](https://github.com/cncf/tag-security/blob/main/community/working-groups/compliance/README.md) -# Introduction {#introduction} +## Introduction Software supply chain attacks cost over $45 billion in 2023, with projections exceeding more than $80 billion by 2026[^1]. According to the Verizon DBIR 2024[^2], supply chain attacks grew 68% year-over-year. @@ -49,14 +49,14 @@ The CNCF Technical Advisory Group (TAG) for Security maintains a detailed catalo This paper presents a holistic view of the software supply chain, providing information for both newcomers and experienced professionals in the field. -## Non-goals {#non-goals} +### Non-goals This paper does not detail tool-specific configurations, but it refers to existing documentation where it is reasonable and appropriate to ensure the reader has the most recent information. This paper does not provide instructions on assessing existing supply chains for security risk. This paper is not an end-all solution for resolving or preventing supply chain attacks. The components of this paper should be evaluated by the reader for usability and applicability in relation to their organization’s risk tolerance and environmental requirements. -## Projects and Products {#projects-and-products} +### Projects and Products Where possible the authors strive to provide the readers with CNCF open source projects as examples. However, it is recognized that some of these projects may not yet be productized or available “off-the-shelf”. @@ -64,7 +64,7 @@ As a result, this paper may also refer to other projects, including both open so All such references, including references to existing documentation, are given as examples to the reader in an effort to provide real-world relatability. Readers should understand that these references are not an endorsement of any project or product by the CNCF or the paper’s authors and reviewers. -# Table of Contents {#table-of-contents} +## Table of Contents [Scope:](#scope:) @@ -98,7 +98,7 @@ Readers should understand that these references are not an endorsement of any pr [Deployments and Distribution](#deployments-and-distribution) -# Detailed Table of Contents {#detailed-table-of-contents} +## Detailed Table of Contents [Scope:](#scope:) @@ -107,7 +107,6 @@ Readers should understand that these references are not an endorsement of any pr [Introduction](#introduction) >[Non-goals](#non-goals) - >[Projects and Products](#projects-and-products) [Table of Contents](#table-of-contents) @@ -119,17 +118,11 @@ Readers should understand that these references are not an endorsement of any pr [Audience/persona](#audience/persona) >[Developer](#developer) - >[Producer’s Security Team](#producer’s-security-team) - >[Compliance-focus, big-picture (CISO)](#compliance-focused,-big-picture-\(ciso\)) - >[Ops/platform folks setting up supply chain infrastructure](#ops-and-platform-teams-building-supply-chain-infrastructure) - >[Security team of consumer (verifier)](#security-team-of-consumer-\(verifier\)) - >[Expert looking to discover more best practices](#heading=h.dm77ln9auip4) - >[End User Concerns & Use Cases](#end-user-concerns-and-use-cases) [Part 2](#part-2:-overview) @@ -139,15 +132,10 @@ Readers should understand that these references are not an endorsement of any pr [Concepts](#concepts) >[Metadata](#metadata) - >[Vulnerability scanning](#vulnerability-scanning) - >[Policy](#policy) - >[Testing](#testing) - >[Zero trust](#zero-trust) - >[Root of trust](#root-of-trust) [Part 3: Software supply chain best practices reference](#part-3:-best-practices-reference) @@ -157,49 +145,38 @@ Readers should understand that these references are not an endorsement of any pr [Source Code](#source-code) >[Verification](#verification) - >[Automation](#automation) - >[Controlled Environments](#controlled-environments) - >[Secure Authentication](#secure-authentication) [Materials](#materials) >[Verification](#verification-1) - >[Automation](#automation-1) [Build Pipelines](#build-pipelines) >[Verification:](#verification-2) - >[Automation:](#automation-2) - >[Controlled Environments:](#controlled-environments-1) - >[Secure Authentication/Access:](#secure-authentication-and-access:) [Artifacts](#artifacts) >[Verification](#verification-3) - >[Automation](#automation-3) - >[Controlled Environments](#controlled-environments-2) [Deployments and Distribution](#deployments-and-distribution) >[Verification](#verification-4) - >[Automation](#automation-4) [An Example Secure Supply Chain](#an-example-secure-supply-chain) +## Part 1: How to read this paper -# Part 1: How to read this paper {#part-1:-how-to-read-this-paper} - -# Audience/persona {#audience/persona} +## Audience/persona At a high level, software supply chain security has two main perspectives: software producers and software consumers. Software producers are looking to secure the software they produce and distribute. @@ -229,7 +206,7 @@ Below is a list of other personas that fall into one or more of the categories b For each persona there is discussion as to where to start with software supply chain security. More details about the suggested best practices can be found in part 3 of this document. -## Developer {#developer} +### Developer Developers are not only responsible for adding new features and fixing bugs, but also managing application dependencies, version control system configuration (VCS), and often also Continuous Integration and Delivery (CI/CD) configurations. Moreover, much of their work happens locally[^3], so managing the security of workstations has never been more important. @@ -238,19 +215,19 @@ Fortunately, more and more developer work happens in source control. This is great news for security, consistency, recoverability, auditability, and collaboration, but it also means at the forefront of supply chain security. The changes developers make (or fail to make) have a direct impact on an organization’s supply chain security, and in many cases, also the supply chain security of downstream consumers, their consumers, and so on. -### Where do I start? +#### Where do I start? One of the most impactful actions developers can take to improve and maintain the security of their supply chain is to ensure that all dependencies are kept up to date. This means accepting those automated PRs, running `npm audit` (or equivalent) regularly, updating container base images and keeping workstations up to date with the latest patches. Even this isn’t an easy task, especially when it comes to keeping dependencies up to date on projects that are not currently being actively developed. -### Then what? +#### Then what? The supply chain is only as secure as its weakest link, so even if all dependencies are kept up to date, a simple misconfiguration, leaked access token or unauthorized change to an upstream project can cause the whole chain to fall apart. As with all security, the best strategy for the supply chain is defense in depth (often referred to as “layers on the onion”). For developers, this means also paying attention to the other areas: -#### Choosing New Libraries and Base Images +##### Choosing New Libraries and Base Images * **Minimize Dependencies:** Where possible, minimize the number of dependencies so that each can be more easily audited. Use dependencies from the same organization or vendor to minimize sources of trust. @@ -264,14 +241,14 @@ Minimize the number of publishers to simplify the work of investigating publishe * **Recursive dependencies**:Ensure that all recursive dependencies are audited by either you or the vendor. If possible, minimize recursive dependencies and perform more scrutiny on each one. -#### Protecting Source Code (see [Producer](#producer’s-security-team)) +##### Protecting Source Code (see [Producer](#producer’s-security-team)) * **Signing Commits/Pushes**: Use cryptographic signing of commits and pushes to verify author identity and prevent unauthorized changes. * **Git Security**: Implement strong access controls, use two-factor authentication for repository access, and regularly review access logs. * **Workstation Security**: Ensure your workstation is protected with the latest antivirus software, firewalls, and is regularly updated to prevent vulnerabilities. * **Secure Coding Practices**: Adopt and promote secure coding practices within your team to minimize vulnerabilities in the codebase. -#### Protecting the Build +##### Protecting the Build * **Audit**: Regularly review and audit your build processes and automation tools to ensure they are free from vulnerabilities. * **Scanning**: Integrate vulnerability scanning in your CI/CD pipeline to detect and address security issues before build and deployment. @@ -282,7 +259,7 @@ If possible, minimize recursive dependencies and perform more scrutiny on each o * **Supply chain Levels for Software Artifacts (SLSA)**: Aim to achieve higher levels of SLSA to ensure your build processes are comprehensively secure. * **Reproducible builds:** Ensure that binaries are consistently generated from their source code to make tampering evident. -#### Supporting Downstream +##### Supporting Downstream * **VEX (Vulnerability Exploitability eXchange)**: Provide clear and actionable information about the exploitability of vulnerabilities in components you produce. * **Scoring System**: Provide a data-driven estimation, such as Exploit Prediction Scoring System (EPSS), for the likelihood a vulnerability in one or more components will be exploited in the wild. @@ -290,7 +267,7 @@ If possible, minimize recursive dependencies and perform more scrutiny on each o * **Software Bill of Materials (SBOM)**: Generate and distribute [SBOMs](#sbom) to provide transparency about the versions and components in your software. * **Provenance**: Ensure that all software artifacts include information about their origin and the process used to build them. -## Producer’s Security Team {#producer’s-security-team} +### Producer’s Security Team In the quest to secure the Software Supply Chain, the synergy between developers, Chief Information Security Officers (CISOs), and operations teams emerges as a cornerstone. This collaboration is vital to preemptively identify vulnerabilities and swiftly respond to incidents. @@ -305,7 +282,7 @@ In particular, the producer should: * Use a vulnerability risk assessment solution to scan the code, packages, and third party dependencies. This assessment should cross-reference the CVSS database with databases such as Nessus to identify vulnerabilities and to discover the latest packages or implement fixes. -## Compliance-focused, big-picture (CISO) {#compliance-focused,-big-picture-(ciso)} +### Compliance-focused, big-picture (CISO) The Chief Information Security Officer (CISO) plays a pivotal role in managing organizational risk. Their duties include achieving and upholding compliance with regulatory standards, as well as providing evidence to auditors and the board. @@ -315,24 +292,24 @@ This includes determining the organization's risk tolerance, necessitating an as The ultimate objective is to safeguard the organization against large-scale data breaches and incidents that could severely impact the business and damage its reputation. Ignoring these risks is not an option, and failure to comply or inadequately handling threats may result in legal action. -## Ops and Platform Teams Building Supply Chain Infrastructure {#ops-and-platform-teams-building-supply-chain-infrastructure} +### Ops and Platform Teams Building Supply Chain Infrastructure Ops/platform teams are responsible for selecting and configuring the tools that manage the supply chain. To tackle this critical step, a focus on simplicity and observability is essential. -### Achieving Observability +#### Achieving Observability Having a complete view and understanding the current state of the supply chain is crucial. Employing observability tools that aggregate data across various points of the supply chain enables real-time visibility into potential vulnerabilities. This awareness enables teams to proactively address security concerns, adapt to threats while continuously refining and improving security strategies. -### Policy enforcement +#### Policy enforcement The creation of explicit security [policies](#policy) sets the stage for secure supply chain practices; however, the real challenge lies in consistently enforcing these policies. Leveraging policy-as-code solutions allows for the automation of these enforcements, ensuring that every step and element of the supply chain adheres to established security standards. To strengthen policy enforcement, continuous validation ensures that security policies are not only adhered to at the outset, but also continuously improved as the supply chain evolves. -## Security Team of Consumer (Verifier) {#security-team-of-consumer-(verifier)} +### Security Team of Consumer (Verifier) End-users of software must establish trust in the software they consume. In order to safely consume software, verifying the security, integrity, and authenticity of the product is essential to safeguard against supply chain vulnerabilities. @@ -344,7 +321,7 @@ Ideally, the consumer will audit all consumed software, creating an allowlist of Even if an organization does not have the resources to audit every package, they can ensure that the same packages are requested on every download by creating a lock file with dependency digests or similar, reducing the opportunities for typos. Once packages have been selected, the next step is to verify their authenticity. -### Verifying Software Integrity and Authenticity +#### Verifying Software Integrity and Authenticity Consumers should verify the source and integrity of software prior to utilization. Signature and checksum validation were once standard methods of doing so, but are no longer enough to ensure provenance and integrity. @@ -364,13 +341,13 @@ When this happens, consumers can: * Engage with upstream producers to help improve their supply chain practices * Perform [Software Composition Analysis (SCA)](#run-software-composition-analysis-on-ingested-software) on consumed packages. -## End User Concerns and Use Cases {#end-user-concerns-and-use-cases} +### End User Concerns and Use Cases End users come in various forms: from enterprises that use open-source software without releasing their software externally, to non-technical users downloading open-source software for personal use. This document focuses on the safe consumption of software without consideration of its intended use. For use cases where software is being used to develop more software look, refer to the [**Developer**](#developer) persona. -### Where do I start? +#### Where do I start? For the end user consumer it might seem like security is not something you should have to deal with. It’s the problem of those providing me with software. @@ -387,7 +364,7 @@ If you are using open source software to do something that deals with sensitive Once you have an understanding of what are the important things to focus time and money on in protecting you need to threat model. -### Then what? +#### Then what? As an end user, once you have an understanding of what you’re looking to protect and how much time and effort you’re willing to spend on it, you need to get started on actually protecting yourself from potential security issues. Most end users are not security experts and most businesses’ core competencies are not related to cybersecurity. @@ -397,7 +374,7 @@ Download software from trustworthy places, update your software regularly, and f This won’t protect you from a lot of sophisticated software supply chain attacks, but it helps prevent the most common ones. Having more end users companies fund and contribute to the projects they use also helps here. -#### Protecting Ingestion (see [consumer](#security-team-of-consumer-\(verifier\))) +##### Protecting Ingestion (see [consumer](#security-team-of-consumer-\(verifier\))) * **Publisher Trust**: Use software trusted sources. * **Verify Security**: Ingest security metadata like [SBOMs](#sbom), in-toto [attestations](#attestations) like SLSA, etc. @@ -405,23 +382,23 @@ and verify that it fits your security needs. * **Secure Supply Chain Consumption Framework ([S2C2F](https://github.com/ossf/s2c2f)):** Follow best practices around consuming open source software. The more technical your team is the more you can do on this front. -#### Protecting Runtime +##### Protecting Runtime * **Store Software Security Metadata**: Store SBOMs, in-toto attestations, etc. from your SDLC processes and your dependencies. * **Have Supply Chain Observability:** Analyze supply chain metadata like SBOMs and in-toto attestations and correlate it with runtime behavior to better respond to supply chain incidents like vulnerabilities or attacks. * **Have software update processes**: Understand what to do when there’s a new version of software released or vulnerability discovered. -#### Protecting the Ecosystem +##### Protecting the Ecosystem * **Fund Open Source**: Well-funded open source has a strong correlation with better security posture. Help fund security initiatives and critical open source projects. * **Contribute to Open Source:** Contributing back to the open source projects you use is also a good way to help with supply chain security. This includes more than just code contributions, when you discover issues, report them. -# Part 2: Overview {#part-2:-overview} +## Part 2: Overview -# Securing the Software Supply Chain {#securing-the-software-supply-chain} +## Securing the Software Supply Chain A supply chain is “a process of getting a product to the customer.” This sentence hides a lot of complexity. As we learned during the COVID-19 pandemic, the supply chains for manufactured goods are complex and can be disrupted by events anywhere along the way. @@ -454,12 +431,12 @@ All of these best practices are designed so that readers can start small, and bu Not all supply chains look alike, so much of this guidance leaves specific policy choices to the implementer to decide based on their threat model and risk assessment. A software supply chain is made up of many people and machines, and only by working together to secure each link in the chain can we make it more secure. -# Concepts {#concepts} +## Concepts Before providing detailed security best practices for each of the steps in the software supply chain, some tools and concepts that are relevant throughout the software supply chain are discussed. These concepts come up in many of the stages of the supply chain, so they are described here for brevity. -## Metadata {#metadata} +### Metadata There are several types of metadata that can be associated with artifacts in order to improve software supply chain security. Discussed here are SBOMs, VEX, and attestations. @@ -467,7 +444,7 @@ All of the metadata produced during the software supply chain needs to be stored Storage mechanisms include OCI and [Github](https://github.blog/changelog/2024-06-25-artifact-attestations-is-generally-available/). These storage mechanisms allow software consumers to find and verify metadata associated with the artifacts they consume. -### SBOM {#sbom} +#### SBOM A Software Bill of Materials (SBOM) is a detailed inventory of all components, libraries, and dependencies used in a software application and the environment in which it was built. SBOMs can help software consumers determine their transitive dependencies, and to determine whether they are impacted by a vulnerability. @@ -488,7 +465,7 @@ This makes build tools the ideal producer of accurate and attested SBOMs. SBOMs are generated by the software producer or vendor, and represent the state of the released software as understood by the producer. As such, SBOMs may not contain information about all dependencies, and do not include vulnerability information about the package itself. -### VEX +#### VEX The generation of Vulnerability Exploitability eXchange (VEX) documents for software artifacts is a proactive measure to communicate the exploitability of vulnerabilities within specific environments. During this process, it is possible to include a parameter describing the state of given vulnerabilities present in the report (AFFECTED, NOT AFFECTED, UNDER INVESTIGATION, FIXED). @@ -503,7 +480,7 @@ Python tools like "vexy" can analyze a CycloneDX SBOM and generate a correspondi This VEX file would then detail the exploitability of the identified vulnerabilities within the context of the specific product that uses those components. VEX is not yet widely adopted, however it is a useful tool to consider when producing SBOMs and consuming artifacts. -### Attestations {#attestations} +#### Attestations Attestations are signed records of actions that occurred in the software supply chain. They enable policy evaluation by providing verifiable information about what occurred in the software supply chain. @@ -523,21 +500,21 @@ Such verification ensures that the supply chain policy is adhered to. If a vulnerability is discovered later, attestations can be used as an audit trail to determine where in the supply chain the vulnerability was introduced. Storage mechanisms include Archivista, OCI, and [GitHub](https://github.blog/changelog/2024-05-02-artifact-attestations-public-beta/). -## Policy {#policy} +### Policy Software supply chain policy describes requirements for the software supply chain, defined in software, including authorized actors and expected actions. This policy can then be evaluated against attestations as part of the verification process. Policy will evolve with an organization’s supply chain security posture, first capturing the current process, then stricter security requirements as the organization’s threat model and risk assessment evolve. More detail about software supply chain policy, including its evaluation and enforcement, is described in a [blog post](https://www.cncf.io/blog/2024/02/14/policy-as-code-in-the-software-supply-chain/#:~:text=%E2%80%9CPolicy%2Das%2DCode%E2%80%9D,of%20operational%20and%20security%20guidelines.) by TAG Security. -## Testing {#testing} +### Testing Properly testing and verifying software is a crucial aspect of ensuring not only its functionality, but also its security. Testing should be considered and attested to at each step of the delivery lifecycle. Test results should be captured as signed, verifiable attestations and which are stored so in a metadata store that it can be evaluated against supply chain policy. Software supply chain policy should list any expected tests to ensure they are run before deployment. -## Zero Trust {#zero-trust} +### Zero Trust Software supply chain security heavily relies on an understanding of which actors are performing which actions in the software delivery lifecycle. Metadata like SBOMs and attestations help shed light on what is happening in the software supply chain, but the data are only as trustworthy as the identities that created them. @@ -547,7 +524,7 @@ The verified identities may be a public identity like the Linux Foundation or a A pseudonymous identity can be associated with a cryptographic key or other consistent identifier that indicates that the same actor is performing an action over time. Such consistency can be used to establish trust even without verifying a human identity. -## Root of Trust {#root-of-trust} +### Root of Trust A root of trust is an entity that provides the initial trust anchor for a system. This trust anchor can then have a chain of trust that can be used to determine other trusted parties, such as developer signing keys. @@ -559,9 +536,9 @@ The level of hardening of a root of trust is dependent on the organization’s t For example, a hobby project may use online keys to improve automation of the root of trust, while a certificate authority may require a threshold of offline keys for improved compromise resilience. Each organization should perform a risk assessment to determine the scope and severity of a root of trust breach, and harden it accordingly. -# Part 3: Best Practices Reference {#part-3:-best-practices-reference} +## Part 3: Best Practices Reference -# Software supply chain overview {#software-supply-chain-overview} +## Software supply chain overview The software supply chain consists of all of the steps taken to move code from source to production. While every supply chain is unique, there are some general steps that are used by most software supply chains. @@ -602,7 +579,7 @@ Each software supply chain has dependencies on other software, which has its own In this way the software supply chain is recursive, with each piece of software building on the software supply chain of its dependencies. While software consumers can and should validate the software supply chain of their immediate dependencies, this will not encompass the entire supply chain unless they also validate the dependencies of those dependencies, and so on. -# Source Code {#source-code} +## Source Code The foundational construct of any software supply chain is the source code. The initial step in securing a supply chain is establishing and ensuring the integrity of the source code. @@ -622,9 +599,9 @@ While the recommendations here assume that source code is tracked in a Git repos The assumption is that there is a centrally managed canonical copy of the repository (for example, on github.com) that all developers contribute their changes to and pull new changes from. If the VCS is not Git, it’s also necessary to confirm what integrity guarantees the VCS provides for its tracking of files and changes, such as the hashing algorithm. -## Verification {#verification} +### Verification -**Declare protected repository namespaces** +#### Declare protected repository namespaces The repository responsible for storing source code and tracking changes must also include policy that indicates which parts of the repository are protected and who can make changes to them. For example, repositories typically have a primary branch such as `main`. @@ -637,7 +614,7 @@ Open source tools like Peribolos (part of Prow) can be used to declare access co This tool is used by Kubernetes. Another option that also enables *verification* of policy enforcement is gittuf, an OpenSSF sandbox project. -**Authenticate and monitor repository activity** +#### Authenticate and monitor repository activity The primary copy of the repository which serves as a synchronization point for all developers should limit who can push to it. This baseline access control protection is offered by all popular source control platforms. @@ -652,22 +629,22 @@ Finally, all repository activity should be recorded in an audit log, and this au As before, source control platforms include audit logs on a repository and organization basis. These logs should be inspected to detect unauthorized changes to a repository or the policies themselves due to the compromise of a privileged developer account. -**Enforce independent 2-party review** +#### Enforce independent 2-party review The author(s) of a request may not also be the approver of the request. At least two individuals, of which one should have write access to the branch, that are independent of the request should review and approve the request. Some organizations may find an engineering manager or a lead engineer, who is an informed security practitioner to be sufficient for this role. Reviewers should have a similar level of knowledge as the author(s), implying equal or greater expertise to provide informed review. -**Require verification attestations / confirmation** +#### Require verification attestations / confirmation Verification of source code policies should be captured as attestations. This allows other systems such as a CI pipeline to verify that source code policies were enforced and met for a specific revision prior to performing a build. Ongoing work such as the SLSA source track is defining guidelines about how to generate attestations at different levels. -## Automation {#automation} +### Automation -**Prevent committing secrets to source code repository** +#### Prevent committing secrets to source code repository Secrets such as credential files, SSH keys, access tokens, and API keys should not be committed to the source code repository unless encrypted prior to placement. Tooling exists to detect secret key leaks, such as git-secrets or trufflehog, which can be integrated using either a client-side hook (pre-commit), server-side hook (pre-receive or update), or as a step in the CI process. @@ -675,7 +652,7 @@ Tooling exists to detect secret key leaks, such as git-secrets or trufflehog, wh Some DevOps platforms and integrations provide a default list of files which cannot be pushed to the repository. These lists can be extended to include more domain specific files which may contain sensitive materials. -#### **Automate software security scanning and testing** +##### Automate software security scanning and testing Software best practices include the use of unit, functional, and end-to-end testing to identify bugs and errors in the code before release. In addition, security specific scans should be performed, including Static Application Security Tests (SAST) and Dynamic Application Security Tests (DAST). @@ -685,9 +662,9 @@ For more details on application security best practices refer to the [OWASP](htt During the build process the metadata from security tooling such as SAST tooling should be recorded and linked to a hash of the build artifact to provide provenance. Both the coverage and results of these tests should be published as part of the repository information to help downstream consumers of software better assess the stability, reliability, and/or suitability of a product or library, possibly as an in-toto attestation. -## Controlled Environments {#controlled-environments} +### Controlled Environments -#### **Establish and adhere to contribution policies** +#### Establish and adhere to contribution policies Modern VCS platforms allow repository administrators to define configuration options or rules to enforce security, hygiene and operational policies. These rules can help enforce policies during different stages of software development allowing standardization across different team members. @@ -695,20 +672,20 @@ For example, automated deletion of branches, policies for code reviews, role bas It is recommended that repository administrators define a baseline of these rules. General contribution policies should also define what is and is not considered an acceptable contribution so that potential contributors are made aware in advance. -#### **Define roles aligned to functional responsibilities** +#### Define roles aligned to functional responsibilities Define roles corresponding to the different actors interacting with source code repositories, and assign access controls based on their responsibilities while enforcing the principle of least privilege. Examples of roles include Developer, Maintainer, Owner, Reviewer, Approver, and Guest. Grant each role fine-grained permissions for repository access control. -## Secure Authentication {#secure-authentication} +### Secure Authentication -#### **Enforce MFA for accessing source code repositories** +#### Enforce MFA for accessing source code repositories Multi-factor authentication (MFA) should be required at the VCS level for all software projects. MFA provides an additional layer of security, normally by requiring a soft or physical token in addition to traditional credentials, thus requiring two compromises in order for an attack to be successful. -#### **Use SSH keys to provide developers access to upstream source code repositories** +#### Use SSH keys to provide developers access to upstream source code repositories Developers contributing source code require a non-interactive way to access source code hosted repositories from their development tools. Instead of using passwords which are prone to common hacking techniques like brute force, password guessing and password spraying, SSH keys[27](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md#user-content-fn-27-4616ccb4d6ae4a3472a432b18926f014) or SSH certificates[28](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md#user-content-fn-28-4616ccb4d6ae4a3472a432b18926f014) should be used. @@ -720,7 +697,7 @@ One possible approach to authentication is frequently rotating Access Tokens, sc It is important to note that the problem with tokens is their distribution, exposing credentials to Man in the Middle (MITM) and other classes of attack. Tokens, in this context, should only be used if they are short lived and issued with an out-of-band identity management system such as [SPIRE](https://github.com/spiffe/spire). -**Use short-lived/ephemeral credentials for machine/service access** +#### Use short-lived/ephemeral credentials for machine/service access Modern VCS platforms allow the use of randomly generated short lived tokens for the access management of machines and services such as CI/CD pipeline agents. Short-life credential issuance encourages the use of fine grained permissions and automation in provisioning access tokens. @@ -730,7 +707,7 @@ These permissions further restrict the type of operation that can be performed a Short-lived access tokens should be considered instead of password-based credentials so that tokens are continuously authenticated. These tokens shouldn't be confused with the long-lived and non-refreshable personal access tokens (PAT) such as those [available on GitHub](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token), as these PATs will have similar security properties as a shared secret or password type of credential. -# Materials {#materials} +## Materials The overall quality and consistency of any “manufacturing” process largely depends on the quality and consistency of the goods used as inputs. Producers must take care to verify the quality of these materials. @@ -738,7 +715,7 @@ For software supply chains, the quality of the dependencies, direct or transitiv Ensuring dependencies are retrieved from trusted sources and have not been tampered with is a key part of the software supply chain. Depending upon the required risk profile, it may be appropriate to identify trusted repositories and rely directly upon them, in addition to disabling access to all other repositories. -##### Second and Third-Party Risk Management +###### Second and Third-Party Risk Management When making determinations on accepting, limiting, or denying the use of second- and third-party software, organizations should use risk management processes to understand the risk presented by these materials. Not all software an organization may intend to use has the same level of support behind it, which may reflect significant differences in the overall level of quality, security, or responsiveness to issues across dependencies. @@ -765,29 +742,29 @@ Software and service vendors should list any changes to their Service Level Agre It is incumbent on the consumer to review and understand these changes and to analyze how they will impact their supply chain. -## Verification {#verification-1} +### Verification -###### *Verify third party artifacts and open source libraries* +####### *Verify third party artifacts and open source libraries* Third party artifacts need to be verified using a range of approaches. All third party artifacts, open source libraries, and any other dependencies should be verified as part of continuous integration.Verification involves verifying their checksums against a known good source and checking any cryptographic signatures. Any software ingested should be scanned using Software Composition Analysis (SCA) tools to detect whether any vulnerable software is present in the final product. For even higher confidence, perform penetration and fuzz testing to ensure any third party artifacts are resistant to common attacks and no basic security flaws are present. -###### *Require SBOMs and VEX statements from third-party suppliers* {#require-sboms-and-vex-statements-from-third-party-suppliers} +####### *Require SBOMs and VEX statements from third-party suppliers* Where possible, software vendors should be required to provide [Software Bills of Materials](https://www.ntia.gov/SBOM) (SBOMs) containing the explicit details of the software and versions used within the supplied product and Vulnerability Exploitability eXchange (VEX) statements that indicate whether specific vulnerabilities affect the software. This provides a clear and direct link to the dependencies, removing doubt on the version of dependencies that are used and thus removing the requirement of using heuristics via SCA tools. Ideally, signed metadata from the build process should accompany the SBOM. -###### *Track dependencies between open source components* +####### *Track dependencies between open source components* A register of a project’s open source components, dependencies, and vulnerabilities should always be maintained to help identify any deployed artifacts with new vulnerabilities. One of the most popular open source inventory implementations is OWASP Dependency-Track. Generating, receiving, or maintaining a supply chain inventory will help identify the software vendors, suppliers, and sources used in an organization, as well as the associated software and versions. Cataloging this inventory into a human and machine readable format allows organizations to correlate vulnerabilities as they are published against in-use or prospective software and to establish any impact. -###### *Build libraries from source code* +####### *Build libraries from source code* Software dependencies are often distributed in binary form such as tarballs, or stored in a package management repository. However, there is often no explicit connection between the binary in a repository and the source code itself. @@ -799,7 +776,7 @@ Consequently, when possible, it is safer and more reliable to build the binaries This provides a clear link between the library source code and the compiled binary. However, because this process is time consuming and resource intensive, it may only be feasible within highly regulated environments. -###### *Define trusted package managers, repositories, and libraries* +####### *Define trusted package managers, repositories, and libraries* If building from source is not a viable option for every component, components from a trusted supplier which regularly maintains and updates those binary components in a backwards compatible way should be used. They should be vetted by using [metrics](#vulnerability-scanning) and other [testing methods](#testing). @@ -811,7 +788,7 @@ If organizations choose to host their own package managers and artifact reposito These hosted package managers must be properly configured to ensure that they do not have malicious packages and are using best practices for software distribution. When organizations choose to instead utilize external repositories, they should ensure that packages are signed by the correct authors and limit the pages ingested from untrusted repositories (such as through the use of an allowlist or other validation). -###### *Generate an immutable SBOM of the code* +####### *Generate an immutable SBOM of the code* While rebuilding a software artifact, it is best practice to also generate its SBOM. An SBOM provides a machine readable inventory of the contents of the artifact. @@ -823,9 +800,9 @@ For third party software, an SBOM can be generated using software composition an SBOM data generated by using the build-time data will be more accurate because the build process has visibility into the dependencies used to generate the software. An SBOM generated through scanning isn’t likely to capture issues such as the toolchain vulnerabilities or manually installed software. -## Automation {#automation-1} +### Automation -###### *Scan software for vulnerabilities* +####### *Scan software for vulnerabilities* Before software dependencies are brought into a system and periodically thereafter, they should be analyzed to ensure the vulnerabilities they include pose an acceptable risk to the organization. If the dependency poses an unacceptable risk, perform triage using a vulnerability management process to decide whether other mitigations may be applied to reduce risk, or whether the software or update should be blocked. @@ -833,13 +810,13 @@ If the dependency poses an unacceptable risk, perform triage using a vulnerabili Note that instances may exist where the specific usage of the software does not expose or use the specific code containing the vulnerability. For these occurrences, analysis mechanisms such VEX or CVSS may be provided to mitigate the vulnerability. -###### *Managing software licenses* +####### *Managing software licenses* While not directly a security concern, licensing obligations are an important consideration when adding new dependencies. The Linux Foundation maintains the [Open Compliance Program](https://compliance.linuxfoundation.org/references/tools/) which provides several tools to ensure released software meets legal and regulatory requirements. Licensing metadata should be recorded during the build process and distributed within the artifact’s SBOM. -###### *Run software composition analysis on ingested software* {#run-software-composition-analysis-on-ingested-software} +####### *Run software composition analysis on ingested software* At a minimum, a Software Composition Analysis (SCA) tool should be run against any dependencies used within the software being built. The SCA tool will use heuristics to identify the direct and transitive dependencies, and can also verify the contents of the SBOM. @@ -849,7 +826,7 @@ Errors may occur when libraries are mapped against vulnerability feeds due to th namespace or version strings). Validation of the security of the open source components should occur before the build process and can complement a range of checks appropriate to organizations risk tolerance. -# Build Pipelines {#build-pipelines} +## Build Pipelines The build pipeline "assembles" the software artifacts that will be made available to downstream consumers. @@ -887,9 +864,9 @@ This division of responsibility should support least privilege authorization. For more detail about build pipelines, see the TAG Security [Secure Software Factory Whitepaper](https://github.com/cncf/tag-security/blob/main/supply-chain-security/secure-software-factory/secure-software-factory.md). -## Verification {#verification-2} +### Verification -### Enforcing policy +#### Enforcing policy Project and organizational release policy should be maintained as software supply chain policy. Metadata produced during the build process should be analyzed to ensure that the products, materials, and processes used during the build pipeline fall within requirements defined in the policy. @@ -902,21 +879,21 @@ The [SLSA framework](https://slsa.dev/) uses in-toto attestations, combined with Build metadata should be evaluated against the policy by using tools such as [Open Policy Agent](https://www.openpolicyagent.org/) (OPA). Open Policy Agent provides a language to enforce policy on JSON data derived from any source, such as Terraform or [SPDX](https://spdx.dev/). -### Validate environments and dependencies before usage +#### Validate environments and dependencies before usage The build environment's sources and dependencies must come from a secure, trusted source of truth. Checksums and any signatures should be validated both in the downloading or ingestion process, and again by the build worker. This should include validating package manager signatures, checking out specific Git commit hashes, and verifying digests of input sources and binaries. After completing this validation, the downloading process could sign all binaries or libraries to generate an attestation or include them in an internal repository that allows future steps to ingest them directly. -### Validate runtime security of build workers +#### Validate runtime security of build workers Out-of-band verification of runtime environment security, as defined by execution of policies using tools such as seccomp, AppArmor, and SELinux, provides defense in depth against attacks on build infrastructure. Policy rule sets should be created and applied to build infrastructure. High privilege kernel capabilities such as debugger, device, and network attachments should be restricted and monitored. Findings should be forwarded to organizational Security Information and Event Management (SIEM) systems for remediation. -### Validate build artifacts through verifiably reproducible builds +#### Validate build artifacts through verifiably reproducible builds A deterministic build produces equivalent outputs when given the same inputs and enables the detection of unintended changes (whether malicious, such as malware and backdoors, or accidental). Verifiably reproducible builds improve on this by enabling cryptographic attestation that the given inputs produce the same output. @@ -928,9 +905,9 @@ The ability to build software in a verifiably reproducible manner is of growing Building software in a reproducible way is not a trivial task however, and care needs to be taken to capture the required build environment and remove non-determinism from all aspects of the process. In what follows, several recommendations specific to the production of reproducible builds are given.[40](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md#user-content-fn-40-dbfbf2c033ed60aef07c6cbd23c5b467) -### Recommendations For Reproducible Builds +#### Recommendations For Reproducible Builds -#### Lock and Verify External Requirements From The Build Process +##### Lock and Verify External Requirements From The Build Process External resources introduce a source of risk into systems. Verification by reproducibility gives security administrators more confidence that external software has not been compromised. @@ -943,7 +920,7 @@ However, if pinned versions are not regularly updated, vital bug fixes and secur Therefore, it is important to use tools like dependabot or renovatebot to track and update dependency versions regularly. If an external dependency cannot be verified in some way, replacement or complete removal of the dependency should be considered. -#### Find and Eliminate Sources Of Non-Determinism +##### Find and Eliminate Sources Of Non-Determinism Timestamps, locale differences, and embedded version information are just a few of the things that may affect determinism in the build process. A compiler may produce different output if source files are passed in differing orders. @@ -952,20 +929,20 @@ The things that may affect determinism in a particular build depends on which to [Reproducible Builds](https://reproducible-builds.org/) documents and offers solutions for many of these. Diffoscope[41](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md#user-content-fn-41-dbfbf2c033ed60aef07c6cbd23c5b467) can be used to identify the sources of build non-determinism. -#### Record The Build Environment +##### Record The Build Environment In order to reproduce a build environment, the versions and hashes of all tools and required configurations should be recorded and distributed with the software's source. Compilers, system libraries, build paths, and operating systems are some of the items that are required to be recorded to properly reproduce a build environment. Debian has created a .buildinfo[42](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md#user-content-fn-42-dbfbf2c033ed60aef07c6cbd23c5b467) file format that they use for this purpose. Storing snapshots of historical build environments allows some forensic analysis and may be more achievable for some teams. -#### Automate Creation Of Build Environments +##### Automate Creation Of Build Environments Other developers or verifiers who wish to build your software need to be able to recreate the build environment with minimum effort. A project may use scripts to quickly retrieve and set up the required tools in a virtual environment. For example, tools like Vagrant[43](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md#user-content-fn-43-dbfbf2c033ed60aef07c6cbd23c5b467) can be used to declaratively create a virtual machine, or Dockerfiles and container images. -#### Distribute Builds Across Different Infrastructure +##### Distribute Builds Across Different Infrastructure To detect potential attacks on the build infrastructure an architecture can be deployed to distribute the builds to multiple hosts. Each host independently and deterministically builds the same component. @@ -974,16 +951,16 @@ To successfully attack such an architecture, the attacker must compromise multip Rebuilderd[44](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md#user-content-fn-44-dbfbf2c033ed60aef07c6cbd23c5b467) is an example of a tool that can be used to set up independent *rebuilder* environments on different infrastructure. It currently supports rebuilding Arch Linux packages, with support for Debian packages planned for the future. -## Automation {#automation-2} +### Automation -### Build and related continuous integration/continuous delivery steps should all be automated through a pipeline defined as code +#### Build and related continuous integration/continuous delivery steps should all be automated through a pipeline defined as code Steps such as build, linting, scanning, and validation should be clearly defined in code that describes a pipeline. This means that all steps from code checkout, to checksum and signature validation, to building and compilation, to publishing, and eventually to deployment should be automated. By putting all steps in a pipeline as code, the likelihood of human error is reduced, and the same steps are taken on each build. The only manual steps during this process should be any code reviews or sign offs. -### Standardize pipelines across projects +#### Standardize pipelines across projects CI/CD processes should be standardized across the enterprise for ease of maintenance and to ensure secure configurations. This process should be enforced by templating CI/CD pipelines or using shared workflows and verifying that pipelines and shared workflows meet organizational standards. @@ -994,7 +971,7 @@ Verification of pipelines should occur before release or distribution. This can ensure that pipelines are following best practices. in-toto provides a layout specification enabling out-of-band verification of CI/CD pipelines. -### Provision a secured orchestration platform to host the build pipeline +#### Provision a secured orchestration platform to host the build pipeline During the initialization phase of the platform trust should be bootstrapped in the system. Methods to bootstrap trust vary by installation type. @@ -1005,7 +982,7 @@ The provisioning process should be described as IaC and happen through an automa Cluster administrative credentials should be secured with hardware tokens. The use of GitOps as a deployment methodology ensures all changes to the system are tracked and can be integrated with organizational identity management systems. -### Build Workers Should be Single Use +#### Build Workers Should be Single Use Build Workers, the workloads that perform the Build Steps, should only be used once before being thrown away. This lowers the blast radius of a compromised build worker, and limits the attack surface by keeping the lifespan of a build worker to a single build operation. @@ -1013,22 +990,22 @@ Long lived build workers are prone to configuration drift and can lead to increa Shorter build worker uptime makes it easier to reason about the operations performed during its lifecycle. For use cases where future forensics might need to be performed, it is prudent to either snapshot the build worker or to keep it running and quarantine it after its build. -## Controlled Environments {#controlled-environments-1} +### Controlled Environments -### Ensure Build Pipeline has minimal network connectivity. +#### Ensure Build Pipeline has minimal network connectivity. The build pipeline should have no network connectivity other than to connect to the trusted sources of source code, the dependency repository and code signing infrastructure.The build workers will require a secure shared storage capability to pass data between each worker. This prevents the workers from repeatedly retrieving remote data for the build and thus improves performance. This shared storage must be encrypted and secured to prevent tampering. -### Segregate the Duties of Each Build Worker +#### Segregate the Duties of Each Build Worker When planning what each build worker will be responsible for, consider segregation of duties within the domain of a particular build. It is generally better to have specific build workers handle specific parts of a build as opposed to having a single worker handle all steps, e.g. lint, compile, submit for remote scanning, push artifact etc. Splitting the build between workers reduces the attack surface for any compromised worker. -### Pass in Build Worker Environment and Commands +#### Pass in Build Worker Environment and Commands A build worker should have a hermetic (e.g. isolated and sealed) environment given to it from the broader pipeline, and no ability to define its own environment. @@ -1039,21 +1016,21 @@ One method of doing this might be to use Kubernetes pod or job objects to deploy The object definitions can be used to specify the environmental variables, commands, and volumes relevant to that particular step, while the base image itself remains minimal[46](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md#user-content-fn-46-dbfbf2c033ed60aef07c6cbd23c5b467). For environments which do not use Kubernetes as an orchestrator, other methods exist for externally declaring the environment and commands that a container should execute. -### Write Output to a Separate Secured Storage Repository +#### Write Output to a Separate Secured Storage Repository The output artifacts of builds require similar security considerations as the inputs and the environment definition. The output artifacts should be written to separate storage from the inputs. A process separate from the worker should then upload the artifacts to the appropriate repository for downstream consumption. -## Secure Authentication and Access: {#secure-authentication-and-access:} +### Secure Authentication and Access: -### Only allow pipeline modifications through "pipeline as code" +#### Only allow pipeline modifications through "pipeline as code" The pipeline configuration should be deployed through the pipeline as code and should be immutable. It should not be possible for an administrator to modify an instantiated pipeline to ensure an attacker posing as an administrator cannot interfere with it directly. This model requires appropriate authentication and authorization to be in place for the configuration of the pipeline. -### Define user roles +#### Define user roles Organizations must define user roles in a build pipeline which should be used to define permission boundaries. In high security environments, no single user should be able to attest to the validity of a software release. @@ -1063,11 +1040,11 @@ Inevitably there will be shared responsibilities across these roles. Teams should carefully define the boundaries and delineate expectations around those shared responsibilities, especially when it comes to security concerns. For example: how much responsibility do application developers have for security within the pipeline? What are they not responsible for? -### Follow best practices for establishing a root of trust from an offline source +#### Follow best practices for establishing a root of trust from an offline source [Root of trust](https://csrc.nist.gov/glossary/term/roots_of_trust) for a build pipeline should follow standard methods for their establishment a from an offline source. -### Use short-lived Workload Certificates +#### Use short-lived Workload Certificates Workloads should be issued short lived credentials with automated rotation. The CNCF maintained SPIFFE/SPIRE project provides a robust identity and certificate orchestration system. @@ -1075,12 +1052,12 @@ The publication "[Solving The Bottom Turtle](https://spiffe.io/book/)"[47](https Certificate rotation policy is a decision based on the trade-off of system availability and the security impact of a lost key. In situations where the use of long-lived certificates is required, a robust certificate revocation system should be implemented. -### Deploy monitoring tools to detect malicious behavior +#### Deploy monitoring tools to detect malicious behavior Additional security techniques should be integrated into the build pipeline itself to monitor for suspicious or unexpected activity, such as attempts to connect to unexpected endpoints during the build process. It is especially valuable to provide enhanced monitoring of stages within the pipeline that affect the resulting artifacts (as opposed to stages performing testing on them) as any deviations from their normal process may be a sign of compromise. -### Sign Every Step in the Build Process +#### Sign Every Step in the Build Process Individual steps in the build process should be attested to for process integrity. Build step inputs, outputs, and process traces should be collected and evaluated as part of the software release and distribution process. @@ -1088,7 +1065,7 @@ The final artifact bundle should include these collective signatures and itself These signatures may use keyless signing methods, like Sigstore, to tie signatures to a developer identity rather than long-lived keys. The CNCF sponsors in-toto, The Update Framework (TUF), and the SPIFFE/SPIRE projects, each of which support the framework for such an attestation/control system. -# Artifacts {#artifacts} +## Artifacts An artifact is the output of the build pipeline once the software has been built and packaged for distribution. Software artifacts, along with corresponding build metadata, should be hashed and signed by authorized entities. @@ -1101,28 +1078,29 @@ For example, consider a scenario where the artifact is signed at build time and The signing of artifacts and creation of signed attestations should be performed at each stage of an artifact’s life cycle, along with the verification of signatures and attestations from prior stages, to ensure end-to-end trust. For added protection, encryption can be used to protect the confidentiality of the artifact, and to ensure only authorized parties are able to use the artifact. -## Verification {#verification-3} +### Verification -#### **Validate the Signatures Generated at Each Step** +#### Validate the Signatures Generated at Each Step The integrity and provenance of images, deployment configuration, and application packages included in artifacts should all be validated using the signatures generated by each step in its build process to ensure compliance with the organization's requirements. This includes signatures on attestations. The contents of attestations should additionally be verified against the software supply chain policy. Additionally, software metadata, such as SBOMs, should have verified signatures to ensure objects in an artifact's manifest or dependency metadata store have not been tampered with between build and runtime. -**Perform additional checks on the artifact** +#### Perform additional checks on the artifact Perform additional testing or validation on the built artifact to ensure it meets security expectations. Once these checks are performed, add a signature to the artifact indicating that it is ready for release. This signing key for this validation service should be delegated to as the trusted key for this artifact. -**Policy** +##### Policy + In addition to validating the signatures on attestations, the verifier should also check that these attestations adhere to the [software supply chain policy](#policy)y. For example, this policy could ensure that the output of the source code is the same as the input to the build system, or that the correct entity signed each attestation. -## Automation {#automation-3} +### Automation -#### **Use TUF to manage signing of artifacts** +#### Use TUF to manage signing of artifacts The CNCF maintains The Update Framework (TUF), to enable the secure distribution of artifacts. Signatures and metadata about artifacts are stored, often adjacent to an OCI registry. @@ -1131,29 +1109,29 @@ This should be used to delegate to the expected signing entity for each artifact It uses additional metadata to allow clients to verify the freshness of content in a repository and protect against common attacks on update systems[48](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md#user-content-fn-48-b48f8aeca0379d5092f46210756d7d22). Clients can make use of public keys to verify the contents of the repository. -#### **Use a store to manage metadata from in-toto** +#### Use a store to manage metadata from in-toto Organizations that generate in-toto metadata need a way to track and store this metadata. This may be a database or a dedicated solution such as Archivista or Grafeas. Archivista is a CNCF project that provides a graph and storage mechanism for in-toto attestations. Grafeas is an open source artifact metadata API supporting in-toto link attestations as a type, and has a supporting Kubernetes admission controller called Kritis[49](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md#user-content-fn-49-b48f8aeca0379d5092f46210756d7d22). -**Distribute in-toto metadata with TUF** +#### Distribute in-toto metadata with TUF The in-toto metadata, along with the supply chain policy for an artifact needs to be securely distributed to users to prevent tampering and rollback attacks. Delegations in TUF can be used to associate each image with its policy and in-toto metadata, while preventing attacks on their distribution. This TUF metadata can be stored alongside the artifact or in a metadata store, such as those discussed in the [Metadata](#metadata) section to allow for secure discovery and verification. -## Controlled Environments {#controlled-environments-2} +### Controlled Environments -#### **Limit which artifacts any given party is authorized to certify** +#### Limit which artifacts any given party is authorized to certify It is important that a software delivery and update system must not grant trust universally or indefinitely. The system must make it clear which artifacts or metadata a given party is trusted to certify using selective trust delegations, such as those in TUF. Trust must expire at predefined intervals, unless renewed. Finally, the idea of trust must be compartmentalized \-- a party must only be trusted to perform the tasks assigned to it. -#### **Build in a system for rotating and revoking private keys** +#### Build in a system for rotating and revoking private keys It is insufficient to cryptographically sign components being distributed and assume they're protected. Instead, the system must be prepared for *when, not if,* its private keys are compromised. @@ -1163,21 +1141,21 @@ This requires a notion of timeliness, similar to the one used by TUF. Additionally, multiple keys must be used, especially for different tasks or roles, and a threshold of keys must be required for important roles. Finally, minimal trust must be placed in high-risk keys like those that are stored online or used in automated roles. -#### **Use a container registry that supports OCI image-spec images** +#### Use a container registry that supports OCI image-spec images An internal image registry should be deployed and configured to support internal artifact distribution with the security properties described in this section. This might be accomplished by distributing metadata using the recently standardized OCI artifact manifest[50](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md#user-content-fn-50-b48f8aeca0379d5092f46210756d7d22). -# Deployments and Distribution {#deployments-and-distribution} +## Deployments and Distribution Software delivery systems have been historically prone to several types of attacks. The Update Framework (TUF) has been designed to be resistant to these attacks. Therefore, any system designed to distribute software artifacts and their corresponding metadata must have several properties that enable them to counter the attacks defined in the TUF spec: Trust, Compromise Resilience, Integrity, and Freshness. In addition the system must contain preventive and detective capabilities to monitor its security posture and report if attempts to compromise are discovered. -## Verification {#verification-4} +### Verification -**Ensure clients can perform Verification of Artifacts and associated metadata** +#### Ensure clients can perform Verification of Artifacts and associated metadata Clients receiving software artifacts and policy from the distribution mechanism must be able to verify the integrity of the downloaded files using the policy. It’s also vital that the view a client has of the repository is consistent and up to date so the client sees the latest version of all the files it has access to. @@ -1188,7 +1166,7 @@ In addition to authenticating the metadata, such as by verifying its signature(s For example, if SLSA provenance is captured for a build process as an in-toto attestation, the signature on the attestation as well as the provenance metadata must be verified against the policy. Adopters can use different tooling depending on the type of metadata that must be verified, with tools like Witness shipping with policy features to verify different types of in-toto attestations. -**Ensure clients can verify the “freshness” of files** +#### Ensure clients can verify the “freshness” of files Since software updates are used to deliver bug fixes and security patches, it is important for clients to have access to the latest available versions. @@ -1197,7 +1175,7 @@ when they are being provided files that are out of date. Clients must also recognize if they are unable to obtain updates that exist on the repository. -**Air-gapped deployment** +##### Air-gapped deployment In air-gapped environments, verifiers will not have live access to artifacts and attestations. While these artifacts and attestations can be copied into the air-gapped deployment, there may be a lag leading to expired signatures or a failure of freshness checks. @@ -1205,16 +1183,16 @@ To address this, air-gapped deployments may use a time in the past (such as when Further, all verification should be done before artifacts are copied into the air-gapped environment, with an attestation that such verification occurred. With this attestation, the verifier can ensure that the artifacts were valid at the time of ingestion. -**Admission controller/deployment gate** +##### Admission controller/deployment gate All software supply chain metadata should be verified at the deployment gate, for example by a Kubernetes admission controller. By performing verification at this stage, any mistakes or vulnerabilities in the software supply chain can be caught and addressed early in the process. Verification at the deployment gate can supplement, but not replace verification at the end of the pipeline. Further metadata may be generated or tampered with between the deployment gate and the end user, so verification must also be done by the end user. The deployment gate verification allows for early detection. -## Automation {#automation-4} +### Automation -**Use The Update Framework** +#### Use The Update Framework TUF is a specification for securely delivering software artifacts by combining trust, compromise resilience, integrity, and freshness. It is a graduated CNCF project and has been deployed in various contexts — PyPI, Datadog, Amazon Web Services for Bottlerocket, Notary, Google Fuchsia, and IBM cloud. @@ -1226,13 +1204,12 @@ end-to-end guarantees to the consumer. This model has been documented in a blog post and two in-toto Enhancements (ITEs), ITE-2 and ITE-3. -**Continuous vulnerability scanning** +#### Continuous vulnerability scanning The state of an application’s dependencies is not static because vulnerabilities could be discovered after deployment. SBOMs and VEX documents can help track which new vulnerabilities might affect the software. - -## An Example Secure Supply Chain {#an-example-secure-supply-chain} +### An Example Secure Supply Chain Some Assumptions: @@ -1254,7 +1231,6 @@ Some Assumptions: 14. Once the package is downloaded the consumer verifies that what they received is what is in the attestations. 15. The consumer performs any other security related scans for their risk appetite for that artifact. - [^1]: [Juniper Research Study Reveals Staggering Cost of Vulnerable Software Supply Chains](https://www.juniperresearch.com/press/study-reveals-staggering-cost-of-software-supply/), May 2023 [^2]: [Verizon Data Breach Information Report](https://www.verizon.com/business/en-gb/resources/reports/dbir/), May 2024