| title |
|---|
The official CHAINS software supply chain recommendations |
Based on our readings and research, we came to the following conclusions.
-- The Chains team
CHAINS recommendations are meant to be directly applicable, with state of the art solutions.
- CHAINS recommends designing, implementing and enforcing reproducible builds
- CHAINS recommends the usage of dependency pinning, via hashes.
- In NPM, this means using lockfiles.
- In Maven, this means strict versions in the pom + Maven lockfile.
- CHAINS recommends the usage of automated dependency bots such as Renovate and Dependabot. Chains recommends activating auto-merge of dependency updates, together with a strong test suite.
- CHAINS recommends the usage of static vulnerability scanners on all commits of the main branch. This contributes to protecting against insider attacks (eg xz).
- CHAINS recommends disabling dynamic evaluation of code (aka eval) in production
- In NodeJS, this is
--disallow-code-generation-from-stringsdoc
- In NodeJS, this is
- CHAINS recommends taking care of Github organization permissions:
- Do not use default "Allow all actions and reusable workflows"
- Do not use "Require approval for all external contributor" for CI workflows
- Do no use default "Read and write permissions" for token permissions
- Tokens should all have expiration dates
These items are harder to achieve than the recommendations above, because of lack of maturity.
- CHAINS encourages transparency logs over releases/packages
- CHAINS encourages pushing build attestations on high-integrity ledgers such Sigstore/Rekor
- CHAINS encourages using functional package managers in CI (Guix, NIX)
- CHAINS encourages automated publication of SBOMs as part of the release process (tutorial for Github release)
- CHAINS encourages source-based package registries, such as Go. This increases transparency and auditability, and reduces the attack surface of malicious tampering.
- DOn't use caching in your builds, strictly forbidden in your release builds (caching attack)