NIST 800-53 SR-4 Provenance: What to Show an Auditor

SR-4 asks you to document, monitor and maintain valid provenance of the systems, system components and associated data you define. NIST 800-53 binds US federal systems and, by contract, some others. For other companies it is the reference behind a common customer request: show me where your software came from and prove it was not altered.

What it asks

The statement is short. You choose the systems, components and data in scope, and then you must document provenance, monitor it and keep it valid. All three verbs matter. A provenance record written once and never checked does not satisfy the control.

What it means in practice

NIST defines provenance as the chronology of the origin, development, ownership, location and changes to a system or component and associated data. It can also include the people and processes that interacted with or changed the item.

The guidance suggests procedures for allocating responsibility for creating, maintaining and monitoring provenance, for transferring provenance documentation and responsibility between organizations, and for preventing and monitoring unauthorized changes to the provenance records. It calls for valid provenance baselines, and says the records should support non-repudiation. Provenance should be addressed throughout the development life cycle and in contracts where appropriate.

For software, the question has concrete answers. Which source commit produced this artifact. Which build system and which identity ran the build. Which dependencies, at which versions and from which registries, went in. Who approved the release. A software bill of materials captures the component list, and signed build attestations capture the how.

The four enhancements fit this reading: identity (SR-4.1), track and trace (SR-4.2), validate as genuine and not altered (SR-4.3) and supply chain integrity pedigree (SR-4.4).

Evidence to collect

• The list of systems, components and data in scope.
• SBOMs per release, stored with the artifact.
• Build records linking artifact digest, commit, builder and time.
• Signatures or attestations, and the verification step in deploy.
• Registry and source records for each dependency.
• Access logs and review records for the provenance store itself.
• The procedure assigning responsibility and describing transfer to customers or partners.

Common gaps

• SBOMs generated once for a customer request and never again.
• Builds run from developer laptops, with no record of the environment.
• Provenance data that anyone with CI access can edit.
• Dependencies pulled from mirrors or proxies with no origin record.
• No verification at deploy, so signatures exist but nothing checks them.
• Provenance covering code but not container base images or build tools.

How to implement it

Generate an SBOM automatically on every build and store it next to the artifact. A manual export is a snapshot, not a baseline.

Build in a controlled pipeline, record the commit, builder identity and artifact digest, and sign the result. Make the deploy step verify the signature.

Protect the records. Restrict write access, log changes and keep them as long as you keep the software. This is the part that gives you the non-repudiation the guidance describes.

When you hand software to a customer, include the SBOM and the verification instructions. That covers the transfer language in the guidance.

Click through it at your own pace, or open it full screen.

Try it yourself

The free in-browser dependency scan at gold.safeguard.sh/scan lets you check a manifest for known vulnerabilities without a signup. It does not replace provenance records, but it is a quick way to see what your dependency list actually contains before you start writing the baseline.

Quick check

Sources

• NIST SP 800-53 Rev 5, SR-4 Provenance
• NIST OSCAL catalog for SP 800-53 Rev 5