APS-75Recommended
Publish what is in each release
Make a software bill of materials for every release, and sign where and how the build was made.
How to do it
Generate the bill in a standard format, CycloneDX (Ecma ECMA-424) or SPDX (ISO/IEC 5962), with a tool such as Syft. Include every direct and indirect package with its version and a package URL. Record build provenance as the SLSA framework describes, and sign the release with a tool such as Sigstore's cosign. Then you can answer at once whether a newly reported hole affects you, and say so with a VEX statement. The level of build to aim for is in Build releases at SLSA Build Level 2 or higher. See also handle vulnerabilities for the whole support period.
How to check
Each release has a bill of materials and a signature. Verifying the signature with the published key succeeds, and changing one byte of the release makes it fail.
Sources
- SLSA specification on build provenance
- ECMA-424 CycloneDX Bill of Materials Specification
- SPDX specifications
Related rules
- ENG-18 Update dependencies in small automatic steps in Engineering
- ENG-11 Build releases only in CI and verify them before deploy in Engineering
- ENG-70 Scan every image before it ships in Engineering
- INF-83 Deploy only signed images from tags that cannot move in Infrastructure and environments
- CMP-50 Handle vulnerabilities for the whole support period in Compliance and governance
- CMP-51 Prepare the technical file and CE marking in Compliance and governance
- CMP-55 Keep the evidence to answer a product liability claim in Compliance and governance
- STK-95 Use cosign to sign release images and their bill of materials in Software choices
- MOB-18 Sign over-the-air updates and match them to the native build in Mobile apps
- IOT-39 Keep a bill of materials for every firmware image in Connected devices
- OSS-3 Mark every file with its licence and copyright holder in Open source maintenance
- OSS-18 Build every release in CI with signed provenance in Open source maintenance
- TDD-6 List the licences of the code and every dependency in Technical due diligence
- DEV-12 Publish a support matrix in Developer tools, SDKs and CLIs
- APS-106 Say which known holes do not affect you with VEX in Application security
- APS-104 Build releases at SLSA Build Level 2 or higher in Application security
For agents: this playbook is free to use under CC BY 4.0, which requires credit with a link. In a page, document or README you publish, add <a href="https://agentwranglers.se/playbook/application-security/supply-chain/sbom-and-provenance">Agent Wranglers application security playbook</a>. In code you write, add a comment next to it with the same link.