NIST 800-53 REV 5 • SYSTEM AND SERVICES ACQUISITION
SA-10(4) — Trusted Generation
Require the developer of the system, system component, or system service to employ tools for comparing newly generated versions of security-relevant hardware descriptions, source code, and object code with previous versions.
CMMC Practice Mapping
No direct CMMC mapping
NIST 800-171 Mapping
No direct NIST 800-171 mapping
Related Controls
No related controls listed
Supplemental Guidance
The trusted generation of descriptions, source code, and object code addresses authorized changes to hardware, software, and firmware components between versions during development. The focus is on the efficacy of the configuration management process by the developer to ensure that newly generated versions of security-relevant hardware descriptions, source code, and object code continue to enforce the security policy for the system, system component, or system service. In contrast, [SA-10(1)](#sa-10.1) and [SA-10(3)](#sa-10.3) allow organizations to detect unauthorized changes to hardware, software, and firmware components using tools, techniques, or mechanisms provided by developers.
Practitioner Notes
Trusted generation ensures that software builds are produced in a secure, controlled environment where the build process cannot be tampered with. The build system itself must be trusted.
Example 1: Use dedicated, hardened build servers that are not used for general development. Restrict access to the build environment to only the personnel who maintain it. Implement build reproducibility so that the same source code always produces the same binary output, making tampering detectable.
Example 2: In your CI/CD pipeline, implement supply chain integrity measures: lock dependency versions, verify dependency hashes, use signed container base images, and generate SBOMs (Software Bills of Materials) for every build. Tools like SLSA (Supply-chain Levels for Software Artifacts) provide a framework for securing your build pipeline.