SA-10: Developer Configuration Management

Quick-reference card

What this control requires

SA-10 requires organizations to enforce developer configuration management across every phase of the system development life cycle. That means your developers and vendors aren’t just writing code; they’re documenting every configuration item, controlling changes to those items, and tracking security flaws from discovery through resolution.

In practice, this control targets a gap most organizations overlook. Developers build and modify systems constantly, but without enforced configuration management, unauthorized changes slip through, security-relevant modifications go undocumented, and flaws accumulate without a clear resolution path. SA-10 closes that gap by requiring developers to implement only organization-approved changes, document the security and privacy impacts of those changes, and report flaw-tracking findings to designated personnel.

The scope is broad. Configuration items under this control include formal models, design specifications, source code, hardware schematics, running object code, and even test fixtures. Organizations that treat this control seriously use the quality and completeness of developer configuration management (CM) activities as direct evidence of whether their security controls are working. If your developers can’t demonstrate disciplined CM practices, auditors will flag it, and your NIST SP 800-53 compliance posture weakens as a result.

Why it matters

Most organizations treat developer configuration management as a checkbox requirement rather than a security function. That misalignment creates real audit exposure. When developers lack formal CM processes, there’s no reliable way to verify that the code running in production matches what was approved, tested, and documented. Auditors look for exactly this kind of traceability, and gaps here undermine confidence in your entire control environment.

The consequences extend beyond audit findings. Without disciplined CM, your organization loses the ability to reconstruct what changed, when it changed, and whether anyone authorized the change. That visibility gap makes it harder to detect tampering, respond to incidents, and demonstrate compliance to regulators or customers. For organizations operating at MODERATE or HIGH baselines, failing SA-10 introduces risk that cascades into related controls like CM-03 (Configuration Change Control) and SI-02 (Flaw Remediation).

Specifically, the risk intensifies when you rely on third-party developers. Vendors who lack mature CM practices may introduce unauthorized modifications, fail to track security flaws, or ship components built from uncontrolled development environments. Your organization inherits that risk whether or not you have visibility into the vendor’s processes.

What attackers exploit

• Unauthorized code changes that bypass approval workflows, allowing malicious or vulnerable code to reach production undetected
• Unpatched flaws in vendor-developed components that persist because no one tracks security defects from discovery through remediation
• Tampering with build artifacts when master copies of security-relevant software lack integrity protections
• Supply chain compromise through uncontrolled developer environments where source code, configuration files, or deployment scripts are modified without audit trails
• Undocumented configuration drift that creates exploitable gaps between approved baselines and actual system states

How to implement

For your vendors

The most common failure mode with SA-10 is accepting a vendor’s claim that they “follow best practices” without verifying what their configuration management process looks like. Self-attestation alone doesn’t satisfy this control. You need evidence that your vendors perform disciplined CM throughout the SDLC and can demonstrate traceability from approved changes to deployed code.

Start your assessment with targeted questionnaire questions. Ask vendors to describe their configuration management plan, including how they define and maintain configuration items. Request specifics on their change control process: who authorizes changes, how security and privacy impacts are documented before implementation, and what happens when an unauthorized change is detected. Ask how they track security flaws and flaw resolution, and who receives those reports internally.

The evidence you should request goes beyond policy documents. Ask for their developer configuration management plan, change authorization records, and security flaw tracking logs. Request examples of configuration management records that show how they control the integrity of configuration items across the SDLC. Solicitation and acquisition contracts should also reference CM requirements explicitly. If a vendor can’t produce these artifacts, that’s a red flag worth escalating.

Beyond documentation, look for specific warning signs. Vendors who can’t explain how they protect master copies of security-relevant code, firmware, or hardware schematics from unauthorized modification likely lack the controls SA-10 demands. Vendors whose change records don’t include security impact assessments for each approved change are missing a core requirement. And vendors who track flaws in ad-hoc spreadsheets rather than structured tracking systems may not meet the rigor auditors expect.

To verify beyond self-attestation, cross-reference the vendor’s CM artifacts with their actual development outputs. Compare change authorization records against release notes or deployment logs. Review their flaw-tracking records to confirm that identified security defects were resolved and reported to designated personnel. Where possible, include CM requirements in your service level agreements and acquisition contracts so you have contractual leverage during audits. For a deeper look at configuration management fundamentals, consider how your vendor’s practices align with recognized CM frameworks.

Evidence examples

Cross-framework mapping

Related controls

• CM-02 — Baseline Configuration: Establishes the approved configuration baselines that SA-10 requires developers to maintain and control throughout the SDLC.
• CM-03 — Configuration Change Control: Provides the organizational change control process that developer changes under SA-10 must flow through before implementation.
• CM-04 — Impact Analyses: Requires the security and privacy impact analysis that SA-10 mandates developers document for every approved change.
• CM-07 — Least Functionality: Restricts system functions to only those necessary, complementing SA-10’s requirement that developers implement only organization-approved changes.
• CM-09 — Configuration Management Plan: Defines the overarching CM plan that governs how developers manage configuration items under SA-10.
• SA-04 — Acquisition Process: Establishes the contractual and procurement requirements that embed SA-10 obligations into vendor agreements.
• SA-05 — System Documentation: Ensures developers produce the system documentation that supports SA-10’s requirement to document configuration items and changes.
• SA-08 — Security and Privacy Engineering Principles: Provides the security engineering foundation that informs how developers design and implement configuration-managed systems.
• SA-15 — Development Process, Standards, and Tools: Governs the development environment and tools that developers use when performing CM activities under SA-10.
• SI-02 — Flaw Remediation: Addresses the organizational flaw remediation process that SA-10’s security flaw tracking and resolution requirements feed into.

Frequently asked questions

What is NIST SP 800-53 SA-10

SA-10 requires organizations to ensure their developers perform configuration management across every phase of the system development life cycle. The control covers documenting and controlling changes to configuration items, implementing only approved modifications, recording the security and privacy impacts of those changes, and tracking security flaws through resolution. It applies to all developer-produced artifacts, including source code, design specifications, hardware schematics, and test fixtures. Organizations use the quality of developer CM activities as direct evidence that their security controls function as intended.

What happens if SA-10 is not implemented

Without SA-10, your organization loses traceability between approved changes and what’s running in production. Auditors will flag the absence of a developer configuration management plan, change authorization records, and security flaw tracking records as control deficiencies. The resulting audit findings can jeopardize your authorization to operate at MODERATE or HIGH baselines. Beyond compliance, the lack of CM discipline means unauthorized modifications, unresolved security flaws, and undocumented changes accumulate without detection.

How do you audit SA-10

Auditors verify SA-10 by examining whether developers are required to perform configuration management during design, development, implementation, operation, and disposal phases. They review the developer configuration management plan, change control records, and security flaw and flaw resolution tracking records to confirm that only organization-approved changes were implemented and that their security impacts were documented. Auditors also check that findings from flaw tracking are reported to designated personnel within the organization. Acquisition contracts and service level agreements are reviewed to confirm that CM obligations are contractually embedded.

What is the difference between SA-10 and CM-3

SA-10 focuses specifically on developer configuration management, requiring the people who build and modify systems to apply CM discipline throughout the SDLC. CM-3 (Configuration Change Control) establishes the broader organizational process for controlling and documenting changes to information systems in operation. In practice, SA-10 governs how developers manage change authorization records, security flaw tracking, and configuration item integrity during development, while CM-3 governs how the organization manages changes to production systems after deployment. Both controls work together, but SA-10 targets the development pipeline and CM-3 targets the operational environment.