ID.RA-09 states: "The authenticity and integrity of hardware and software are assessed prior to acquisition and use". For software you consume, evidence is a record that you checked where a package came from and that it was not altered, such as signature or checksum verification, source checks and an approval step.
What the outcome asks
In NIST CSF 2.0, ID.RA-09 sits in the Risk Assessment category under Identify. Two words carry the weight. Authenticity asks whether the software really comes from who it claims. Integrity asks whether it arrived unchanged. The phrase "prior to acquisition and use" sets the timing: the check happens before the software is adopted or run, not after an incident.
The same category includes ID.RA-10, which says critical suppliers are assessed prior to acquisition. The supplier is covered there, and the artifact itself is covered here.
Artifacts that can show the check
| Check | Artifact to keep |
|---|---|
| Source identity | Record of the registry, publisher and repository the package came from |
| Integrity | Checksum or lockfile hash comparison in the build log |
| Signature | Output of signature verification, with the identity trusted |
| Provenance | Build attestation or provenance statement where the publisher supplies one |
| Approval | Ticket or pull request approving a new dependency or tool |
| Scan | Result of malware and vulnerability scans on first use |
Not every ecosystem offers signatures or provenance. Where it does not, say so and rely on the other checks. Writing down the limit is itself honest evidence.
Steps to build the habit
- Pin dependencies with lockfiles that include content hashes, and fail the build on mismatch.
- Pull from approved registries only, and record which ones.
- Verify signatures or provenance where the publisher provides them, and log the result.
- Require a pull request for any new direct dependency, with the reviewer checking the publisher and project health.
- Verify downloaded tools and installers by checksum against a source you trust.
- Store the evidence next to the release it applies to.
Do the same for container base images, build plugins and editor extensions. They are software you acquire and run.
Limits to be upfront about
A valid signature proves who signed it, not that the code is safe. A matching checksum proves the file is the one you expected, not that it is benign. These checks reduce specific risks. Say what each one covers, and pair them with scanning and review. That framing keeps your evidence accurate.
Try it yourself
Open the dependency inventory demo and look at where each component comes from. Knowing the source is the first step of an authenticity check.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard can produce SBOM and dependency scanning results and run asset discovery, which gives you machine generated inventory records to attach next to your own review notes. You can try the free scan at gold.safeguard.sh/scan. Whether a record satisfies a control is for you and your auditor to decide.
Quick check
Does ID.RA-09 apply to open source packages?
The text says software without limiting it to commercial products. Packages you adopt are software you acquire and use.
Is a lockfile hash a form of integrity evidence?
Yes, it shows that the content you built with matches the content that was recorded, if the build fails on mismatch.
Sources
Last reviewed: 19 October 2026.
