ID.RA-09 says the authenticity and integrity of hardware and software are assessed prior to acquisition and use. Before you buy or install something, check that it is what it claims to be and that it has not been tampered with. For software, that mostly means verifying where packages come from and confirming they match published checksums or signatures.
What good looks like
Critical technology products and services get a documented look before they enter the environment. NIST's example is to assess the authenticity and cybersecurity of critical technology products and services prior to acquisition and use. For a small team, that means a short checklist for laptops, network gear, SaaS tools, and every new open source package or container image that reaches production.
How to implement it
- For hardware, buy from authorized resellers and check serial numbers and tamper seals on arrival.
- For installers and updates, verify signatures or published hashes before running them.
- For open source dependencies, pull from official registries, pin versions with lockfiles, and review new or lightly maintained packages before adding them. Typosquatted names are a real route in.
- Generate a software bill of materials for what you ship so you know exactly which components came in. This also helps answer customer questions later.
- Prefer vendors that publish signed releases, provenance data, or an SBOM, and note it in your review.
- Record the check: what was verified, how, by whom, and when.
Try it yourself
This walkthrough generates an SBOM from a project so you can see every component that came in.
Click through it at your own pace, or open it full screen.
For a quick look at your own dependencies, the free in browser dependency scan is at https://gold.safeguard.sh/scan.
Evidence to collect
- An acquisition checklist and completed examples
- Records of signature or hash verification for key installers
- Lockfiles and a dependency review rule
- SBOMs for shipped software, with dates
Common gaps
- Checks happen for hardware but never for software packages
- Developers add dependencies with no review
- Hash verification is possible but skipped under time pressure
- Nothing is recorded, so the check cannot be shown later
Quick check
Does a lockfile prove integrity?
It pins versions and usually hashes, which helps detect changes between installs. It does not prove the original package was trustworthy. Pair it with source checks and review.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (February 2024), Appendix A, CSF Core: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST CSF 2.0 landing page: https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
The CSF is voluntary guidance. There is no CSF certification, so nothing here makes a company "CSF certified". You describe your own practices against the outcomes.
