Two NIST 800-53 controls cover trust in what you install. CM-14, Signed Components, prevents installing defined components unless they carry a signature from an approved certificate. SI-7 uses integrity verification tools to detect unauthorized change and defines actions when it is found. Together they map to signed artifacts and verified deploys.
CM-14 in plain terms
The Rev. 5 text says to prevent installation of defined components without verification that the component has been digitally signed using a certificate recognized and approved by the organization. The discussion lists software and firmware version updates, patches, service packs, device drivers and BIOS updates as examples. It describes signatures and their verification as a method of code authentication.
CM-14 is not selected by the low, moderate or high baseline profiles checked, so it appears when a program adds it. Check whether yours does.
SI-7 in plain terms
SI-7 asks to employ integrity verification tools to detect unauthorized changes to defined software, firmware and information, and to take defined actions when changes are detected. The discussion says unauthorized change can come from errors or malicious activity and lists mechanisms: parity checks, cyclical redundancy checks, cryptographic hashes and associated tools. SI-7 is in the moderate and high baselines.
Mapping to a pipeline
- Receive. Control idea: CM-14; Practical step: Verify vendor and registry signatures before use
- Build. Control idea: SI-7; Practical step: Record hashes of inputs and outputs
- Release. Control idea: CM-14; Practical step: Sign your own artifacts with a managed key
- Deploy. Control idea: CM-14, SI-7; Practical step: Refuse unsigned or mismatched artifacts
- Run. Control idea: SI-7; Practical step: Detect changes to deployed files and images
Key handling matters
A signature is only as good as the key. If the signing key sits on a build server any job can read, the signature proves little. Restrict who and what can sign, rotate on a schedule and log signing events.
Also decide who approves certificates. The control says "recognized and approved by the organization," so there must be an approved list and an owner for it.
What to record for an assessor
- The list of component types covered, and the approved certificates.
- Pipeline or admission policy that refuses unsigned items.
- A sample of blocked attempts or test results.
- The integrity tooling configuration and its alert history.
- The response actions taken for any real detection.
Limits
Signing proves who published a component. It does not prove the component is free of flaws. A signed package can still contain a vulnerable library or a malicious change from a compromised publisher. Pair it with scanning and review. Our post on this point: A valid signature does not mean the software is safe.
Try it yourself
Open the demo and watch a change get checked before merge. Look for where a failing check blocks it.
Click through it at your own pace, or open it full screen.
Quick check
Is CM-14 in the moderate baseline?
Not in the Rev. 5 profile checked. A program can add it.
Does a valid signature mean the component is safe?
No. It shows who signed it, not that the content is free of flaws or malicious change.
Safeguard's policies and gates and its SBOM scanning help enforce checks before release. A free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-53 Rev. 5 catalog and baseline profiles, CM-14 and SI-7 (OSCAL content)
- NIST SP 800-53 Rev. 5 page
Last reviewed: 19 October 2026.
