Inspection of Systems or Components SR-10

Source: NIST SP 800-53 Rev.5, Supply Chain Risk Management family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

SR-10 (Inspection of Systems or Components) is about physically and logically checking the parts you receive and run — hardware, firmware, and software — to catch tampering before you trust them. It belongs to the Supply Chain Risk Management (SR) family and sits in the Low baseline. Even a small lab server should have a way to confirm that a delivered or updated component is genuine and unaltered.

What good looks like

• Decide what to inspect (for example new hardware, firmware updates, and downloaded packages) and when — at random, on a set schedule, or whenever something looks off.
• Check that software is genuine and unaltered by verifying digital signatures and checksums against the vendor’s published values — not just that a file finished downloading.
• Look for signs of physical tampering on delivered hardware — broken seals, opened packaging, or parts that do not match the order.
• Keep a baseline of known-good files so you can compare against it later and spot unexpected changes.
• Write down what you inspected and what you found — an inspection nobody recorded cannot be shown as evidence.

Framework mapping

• NIST CSF 2.0 — ID.RA-09 — The authenticity and integrity of hardware and software are assessed prior to acquisition and use

How to move it toward Implemented

• Verify software authenticity before you trust it: APT (Advanced Package Tool) checks repository signatures automatically, so treat any NO_PUBKEY or ‘not signed’ warning as a stop-and-investigate signal — and on Red Hat-style systems run rpm --checksig <file>.rpm to confirm the vendor’s GPG (GNU Privacy Guard) signature.
• Confirm a downloaded file matches the vendor’s published hash with sha256sum <file>, then compare the output to the value on the vendor’s site — a mismatch means do not install.
• Set up a file-integrity baseline with AIDE (Advanced Intrusion Detection Environment): run aideinit once, then aide --check on a schedule to catch files that changed without an approved reason.
• Spot-check installed packages against their manifests — debsums -c on Debian/Ubuntu or rpm -Va on Red Hat-style systems — and investigate any file that fails.
• Run and log a dated inspection (signature checks, sha256sum results, and an aide --check report), saved as a dated file.
• Attach that inspection log as hardening evidence on the asset, naming SR-10 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.