A software bill of materials is produced and made available to consumers of software.
Archive all files and supporting data necessary for each software release in secure repositories with controlled access. Include integrity verification information and provenance data, ensuring these are protected from unauthorized changes. If needed, store integrity and provenance data separately from release files to enhance security. This secure archiving process enables reliable traceability for each release, supporting the creation and maintenance of a comprehensive software bill of materials (SBOM).
Develop a standardized and centrally documented build process to ensure consistent execution, whether performed manually or through automated tools. The build process must detail all steps end-to-end, enabling reproducibility and ensuring that all outputs align with expected results. Store the process definition centrally, ensuring accessibility while avoiding multiple, unaligned copies. Exclude sensitive secrets (e.g., passwords, tokens) from the build process definition and secure these through separate mechanisms. Regularly review and update all build tools, ensuring they align with vendor recommendations and best practices. Harden configurations and apply security patches to prevent vulnerabilities in the build environment. For each artifact generated, calculate and securely store integrity verification values such as hashes or signatures. If signing artifacts, protect private certificates rigorously. Maintain archives in controlled-access repositories and incorporate provenance data to facilitate traceability and the generation of an SBOM. Routine patching and hardening of build tools further ensure the integrity of the entire process.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-03-01-01-01-01 | Define and document the build process | Create a detailed, step-by-step definition of the build process, covering all stages from source code to artifact generation. Ensure the definition is stored centrally and updated consistently. | Preparation | Build engineers, Development leads |
| SSS-03-01-01-01-02 | Eliminate secrets from build definitions | Avoid including secrets like API keys or credentials in the build process definition. Use secure secret management solutions for sensitive information. | Preparation | Security team, DevOps team |
| SSS-03-01-01-01-03 | Harden and maintain build tools | Ensure that build tools are up-to-date with the latest security patches and are configured securely according to vendor and industry best practices. | Development | DevOps team, Security team |
| SSS-03-01-01-01-04 | Implement artifact integrity checks | Generate and protect a unique value (e.g., signature or hash) for each build artifact to verify its integrity and authenticity later. | Deployment | DevOps team, Security team |
| SSS-03-01-01-01-05 | Regularly audit and patch build tools | Schedule routine audits and patching for build tools to ensure they remain secure and compliant with organizational policies. | Post-deployment | Security team, IT operations |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1730) NIST Secure Software Development Framework (PS.3.1) OWASP SAMM: Software Assurance Maturity Model (I-SB-1-A) |
Collect and safeguard detailed provenance data for each component within a software release, maintaining it in a software bill of materials (SBOM) that can be shared with software acquirers and operations teams. Protect the SBOM’s integrity to ensure accurate traceability and update it as components change over time. This enables consumers to understand the origins and dependencies of each software component, supporting secure and transparent software usage.
Establish processes to generate comprehensive SBOMs for all open-source software (OSS) components that are rebuilt as part of your software supply chain. Each SBOM should capture detailed provenance data, including the origins, dependencies, and versions of each package, ensuring alignment with auditability requirements. Maintain the integrity of the SBOMs to provide accurate traceability for software users and stakeholders, facilitating dependency management and transparency. Update SBOMs as components evolve or dependencies change, enabling organizations to assess the blast radius of potential vulnerabilities or issues. Share SBOMs securely with authorized acquirers or operators to enhance the overall security and reliability of the software supply chain.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-03-01-02-01-01 | Identify and document rebuilt OSS components | Catalog all open-source software (OSS) components you rebuild, including their versions, dependencies, and sources. | Preparation | Development teams, Security team |
| SSS-03-01-02-01-02 | Use tools to generate SBOMs | Leverage Software Bill of Materials (SBOM) generation tools to capture detailed supply chain metadata for each rebuilt package. | Development | DevOps team, Security team |
| SSS-03-01-02-01-03 | Incorporate SBOM generation into CI/CD pipelines | Automate the generation of SBOMs during the build process to ensure that every rebuilt OSS component is accompanied by its SBOM. | Development | DevOps team, Build engineers |
| SSS-03-01-02-01-04 | Store SBOMs in a central repository | Maintain a centralized repository for storing and managing SBOMs, ensuring easy access for audits, compliance, and vulnerability tracking. | Deployment | Security team, Compliance team |
| SSS-03-01-02-01-05 | Leverage SBOMs for risk assessment and audit | Use SBOMs to assess the blast radius of vulnerabilities and ensure traceability and compliance for regulatory or audit requirements. | Post-deployment | Security team, Risk management team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1730) NIST Secure Software Development Framework (PS.3.2) S2C2F: Secure Supply Chain Consumption Framework (REB-3) |