NIST 800-53 SA-10 Developer Configuration Management: Proof Guide

When a customer asks how you know the software you shipped is the software you reviewed, they are asking about SA-10 Developer Configuration Management. NIST 800-53 binds US federal systems, and reaches other organizations through contracts. For everyone else it is a reference, and it reads like a description of a disciplined build and release process.

What it means in practice

The control applies to the developer of the system, component or service. That can be your own team, or a supplier. The statement requires the developer to:

• Perform configuration management during a phase you define: design, development, implementation or operation.
• Document, manage and control the integrity of changes to the configuration items you define.
• Implement only organization approved changes.
• Document approved changes and their potential security and privacy impacts.
• Track security flaws and their resolution, and report findings to defined personnel.

The guidance treats the developer's configuration management as direct evidence that security controls are applied well. It includes protecting master copies of material used to build security relevant parts from unauthorized change or destruction. It lists configuration items that may fall under control: design specifications, source code, the current running object code, comparison tools and test fixtures. Developers may also support configuration management during operations, depending on the contract.

The enhancements

The record lists seven:

• SA-10.1 Software and Firmware Integrity Verification
• SA-10.2 Alternative Configuration Management Processes
• SA-10.3 Hardware Integrity Verification
• SA-10.4 Trusted Generation
• SA-10.5 Mapping Integrity for Version Control
• SA-10.6 Trusted Distribution
• SA-10.7 Security and Privacy Representatives

For software teams, the integrity verification, trusted generation and trusted distribution items line up with signed commits, reproducible builds and signed releases. You do not need all of them to answer the base control, but they show where a mature program goes.

Evidence to collect

• The configuration management plan: what is under control, who approves what.
• Version control settings: protected branches, required reviews, restricted force pushes and admin bypass.
• A sample of changes traced from ticket to review to merge to deployment.
• Security and privacy impact notes on changes, such as a field in the pull request template.
• Build pipeline definitions and access controls for who can change them.
• Release artifacts with checksums or signatures.
• The flaw tracker, with open and close dates and reports to owners.

Common gaps

• Direct pushes to the main branch by administrators.
• The pipeline definition is editable by anyone, so approved code can be built by an unapproved process.
• Emergency changes skip review and are never reviewed afterward.
• Dependencies float to the latest version with no record of what shipped.
• Suppliers are covered by contract language but nobody asks for evidence.

How to implement it

Treat the repository as the source of truth. Protect the main branch, require review, and require status checks. Log who can change pipeline configuration and review those changes too.

Record what each release contains. A software bill of materials generated at build time ties a release to its exact components, which also supports flaw tracking. Add a policy gate in the pipeline so a build with a blocking finding does not reach production. The gate demo shows that flow.

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

For suppliers, put the requirements in the contract and ask for the same evidence you would produce yourself: change control, review and flaw handling.

Quick check

Sources

• NIST SP 800-53 Rev 5, SA-10
• OSCAL catalog for SP 800-53 Rev 5