SA-10 Developer Configuration Management

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Moderate, High	Organization	7 (0 in a baseline)

Related controls: CM-2, CM-3, CM-4, CM-7, CM-9, SA-4, SA-5, SA-8, SA-15, SI-2, SR-3, SR-4, SR-5, SR-6

Control statement

Require the developer of the system, system component, or system service to:

• a. Perform configuration management during system, component, or service [Selection (one or more): design; development; implementation; operation; disposal];
• b. Document, manage, and control the integrity of changes to [Assignment: organization-defined configuration items];
• c. Implement only organization-approved changes to the system, component, or service;
• d. Document approved changes to the system, component, or service and the potential security and privacy impacts of such changes; and
• e. Track security flaws and flaw resolution within the system, component, or service and report findings to [Assignment: organization-defined personnel].

NIST discussion

Organizations consider the quality and completeness of configuration management activities conducted by developers as direct evidence of applying effective security controls. Controls include protecting the master copies of material used to generate security-relevant portions of the system hardware, software, and firmware from unauthorized modification or destruction. Maintaining the integrity of changes to the system, system component, or system service requires strict configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes.

The configuration items that are placed under configuration management include the formal model; the functional, high-level, and low-level design specifications; other design data; implementation documentation; source code and hardware schematics; the current running version of the object code; tools for comparing new versions of security-relevant hardware descriptions and source code with previous versions; and test fixtures and documentation. Depending on the mission and business needs of organizations and the nature of the contractual relationships in place, developers may provide configuration management support during the operations and maintenance stage of the system development life cycle.

Control enhancements

SA-10(1) Software and Firmware Integrity Verification

Baselines: Not in a baseline

Require the developer of the system, system component, or system service to enable integrity verification of software and firmware components.

Discussion and assessment objectives for SA-10(1)

Software and firmware integrity verification allows organizations to detect unauthorized changes to software and firmware components using developer-provided tools, techniques, and mechanisms. The integrity checking mechanisms can also address counterfeiting of software and firmware components. Organizations verify the integrity of software and firmware components, for example, through secure one-way hashes provided by developers. Delivered software and firmware components also include any updates to such components.

Determine if the developer of the system, system component, or system service is required to enable integrity verification of software and firmware components.

Examine: System and services acquisition policy; procedures addressing system developer configuration management; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system developer configuration management plan; software and firmware integrity verification records; system change authorization records; change control records; configuration management records; system security plan; supply chain risk management plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; organizational personnel with configuration management responsibilities; system developers; organizational personnel with supply chain risk management responsibilities.

Test: Organizational processes for monitoring developer configuration management; mechanisms supporting and/or implementing the monitoring of developer configuration management.

SA-10(2) Alternative Configuration Management Processes

Baselines: Not in a baseline

Provide an alternate configuration management process using organizational personnel in the absence of a dedicated developer configuration management team.

Discussion and assessment objectives for SA-10(2)

Alternate configuration management processes may be required when organizations use commercial off-the-shelf information technology products. Alternate configuration management processes include organizational personnel who review and approve proposed changes to systems, system components, and system services and conduct security and privacy impact analyses prior to the implementation of changes to systems, components, or services.

Determine if an alternate configuration management process has been provided using organizational personnel in the absence of a dedicated developer configuration management team.

Examine: System and services acquisition policy; system and services acquisition procedures; configuration management policy; configuration management plan; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system developer configuration management plan; security impact analyses; privacy impact analyses; privacy impact assessment; privacy risk assessment documentation; system security plan; privacy plan; other relevant documents or records.

Interview: Organizational personnel with acquisition responsibilities; organizational personnel with information security and privacy responsibilities; organizational personnel with configuration management responsibilities; system developers.

Test: Organizational processes for monitoring developer configuration management; mechanisms supporting and/or implementing the monitoring of developer configuration management.

SA-10(3) Hardware Integrity Verification

Baselines: Not in a baseline

Require the developer of the system, system component, or system service to enable integrity verification of hardware components.

Discussion and assessment objectives for SA-10(3)

Hardware integrity verification allows organizations to detect unauthorized changes to hardware components using developer-provided tools, techniques, methods, and mechanisms. Organizations may verify the integrity of hardware components with hard-to-copy labels, verifiable serial numbers provided by developers, and by requiring the use of anti-tamper technologies. Delivered hardware components also include hardware and firmware updates to such components.

Determine if the developer of the system, system component, or system service is required to enable integrity verification of hardware components.

Examine: System and services acquisition policy; procedures addressing system developer configuration management; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system developer configuration management plan; hardware integrity verification records; system security plan; supply chain risk management plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; organizational personnel with configuration management responsibilities; system developers; organizational personnel with supply chain risk management responsibilities.

Test: Organizational processes for monitoring developer configuration management; mechanisms supporting and/or implementing the monitoring of developer configuration management.

SA-10(4) Trusted Generation

Baselines: Not in a baseline

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.

Discussion and assessment objectives for SA-10(4)

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) and SA-10(3) allow organizations to detect unauthorized changes to hardware, software, and firmware components using tools, techniques, or mechanisms provided by developers.

Determine if:

• SA-10(04)[01] the developer of the system, system component, or system service is required to employ tools for comparing newly generated versions of security-relevant hardware descriptions with previous versions;
• SA-10(04)[02] the developer of the system, system component, or system service is required to employ tools for comparing newly generated versions of source code with previous versions;
• SA-10(04)[03] the developer of the system, system component, or system service is required to employ tools for comparing newly generated versions of object code with previous versions.

Examine: System and services acquisition policy; procedures addressing system developer configuration management; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system developer configuration management plan; change control records; configuration management records; configuration control audit records; system security plan; other relevant documents or records.

Test: Organizational processes for monitoring developer configuration management; mechanisms supporting and/or implementing the monitoring of developer configuration management.

SA-10(5) Mapping Integrity for Version Control

Baselines: Not in a baseline

Require the developer of the system, system component, or system service to maintain the integrity of the mapping between the master build data describing the current version of security-relevant hardware, software, and firmware and the on-site master copy of the data for the current version.

Discussion and assessment objectives for SA-10(5)

Mapping integrity for version control addresses changes to hardware, software, and firmware components during both initial development and system development life cycle updates. Maintaining the integrity between the master copies of security-relevant hardware, software, and firmware (including designs, hardware drawings, source code) and the equivalent data in master copies in operational environments is essential to ensuring the availability of organizational systems that support critical mission and business functions.

Determine if the developer of the system, system component, or system service is required to maintain the integrity of the mapping between the master build data describing the current version of security-relevant hardware, software, and firmware and the on-site master copy of the data for the current version.

Examine: System and services acquisition policy; procedures addressing system developer configuration management; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system developer configuration management plan; change control records; configuration management records; version control change/update records; integrity verification records between master copies of security-relevant hardware, software, and firmware (including designs and source code); system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; organizational personnel with configuration management responsibilities; system developers.

Test: Organizational processes for monitoring developer configuration management; mechanisms supporting and/or implementing the monitoring of developer configuration management.

SA-10(6) Trusted Distribution

Baselines: Not in a baseline

Require the developer of the system, system component, or system service to execute procedures for ensuring that security-relevant hardware, software, and firmware updates distributed to the organization are exactly as specified by the master copies.

Discussion and assessment objectives for SA-10(6)

The trusted distribution of security-relevant hardware, software, and firmware updates help to ensure that the updates are correct representations of the master copies maintained by the developer and have not been tampered with during distribution.

Determine if the developer of the system, system component, or system service is required to execute procedures for ensuring that security-relevant hardware, software, and firmware updates distributed to the organization are exactly as specified by the master copies.

Examine: System and services acquisition policy; procedures addressing system developer configuration management; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system developer configuration management plan; change control records; configuration management records; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; organizational personnel with configuration management responsibilities; system developers.

Test: Organizational processes for monitoring developer configuration management; mechanisms supporting and/or implementing the monitoring of developer configuration management.

SA-10(7) Security and Privacy Representatives

Baselines: Not in a baseline

Require [Assignment: organization-defined security and privacy representatives] to be included in the [Assignment: organization-defined configuration change management and control process].

Discussion and assessment objectives for SA-10(7)

Information security and privacy representatives can include system security officers, senior agency information security officers, senior agency officials for privacy, and system privacy officers. Representation by personnel with information security and privacy expertise is important because changes to system configurations can have unintended side effects, some of which may be security- or privacy-relevant. Detecting such changes early in the process can help avoid unintended, negative consequences that could ultimately affect the security and privacy posture of systems. The configuration change management and control process in this control enhancement refers to the change management and control process defined by organizations in SA-10b.

Determine if:

• SA-10(07)[01] [Assignment: organization-defined security representatives] are required to be included in the [Assignment: organization-defined configuration change management and control processes];
• SA-10(07)[02] [Assignment: organization-defined privacy representatives] are required to be included in the [Assignment: organization-defined configuration change management and control processes].

Examine: System and services acquisition policy; system and services acquisition procedures; configuration management policy; configuration management plan; solicitation documentation requiring representatives for security and privacy; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system developer configuration management plan; change control records; configuration management records; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security and privacy responsibilities; organizational personnel with configuration management responsibilities; system developers.

Assessment objectives (SP 800-53A)

Objectives and methods for SA-10

Determine if:

• SA-10a. the developer of the system, system component, or system service is required to perform configuration management during system, component, or service [Selection (one or more): design; development; implementation; operation; disposal];
• SA-10b.
  • SA-10b.[01] the developer of the system, system component, or system service is required to document the integrity of changes to [Assignment: organization-defined configuration items];
  • SA-10b.[02] the developer of the system, system component, or system service is required to manage the integrity of changes to [Assignment: organization-defined configuration items];
  • SA-10b.[03] the developer of the system, system component, or system service is required to control the integrity of changes to [Assignment: organization-defined configuration items];
• SA-10c. the developer of the system, system component, or system service is required to implement only organization-approved changes to the system, component, or service;
• SA-10d.
  • SA-10d.[01] the developer of the system, system component, or system service is required to document approved changes to the system, component, or service;
  • SA-10d.[02] the developer of the system, system component, or system service is required to document the potential security impacts of approved changes;
  • SA-10d.[03] the developer of the system, system component, or system service is required to document the potential privacy impacts of approved changes;
• SA-10e.
  • SA-10e.[01] the developer of the system, system component, or system service is required to track security flaws within the system, component, or service;
  • SA-10e.[02] the developer of the system, system component, or system service is required to track security flaw resolutions within the system, component, or service;
  • SA-10e.[03] the developer of the system, system component, or system service is required to report findings to [Assignment: organization-defined personnel].

Examine: System and services acquisition policy; procedures addressing system developer configuration management; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system developer configuration management plan; security flaw and flaw resolution tracking records; system change authorization records; change control records; configuration management records; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; organizational personnel with configuration management responsibilities; system developers.

Test: Organizational processes for monitoring developer configuration management; mechanisms supporting and/or implementing the monitoring of developer configuration management.

Policy statement

• The System owner shall require the developer of the system, system component or system service to perform configuration management during Select one or more: design; development; implementation; operation; disposal Typical: design, development, implementation and operation. (SA-10a)
• The System owner shall require the developer to document, manage and control the integrity of changes to Fill in: configuration items under configuration management Typical: design specifications, source code, build scripts and pipeline configuration, infrastructure and configuration as code, test scripts and results, and each released executable. (SA-10b)
• The System owner shall require the developer to implement only organization-approved changes to the system, component or service. (SA-10c)
• The System owner shall require the developer to document approved changes and their potential security and privacy impacts. (SA-10d)
• The System owner shall require the developer to track security flaws and flaw resolution within the system, component or service, and report findings to Fill in: personnel to whom security flaws and flaw resolutions within the system, component, or service are reported Typical: the system owner and the Chief Information Security Officer. (SA-10e)
• The System owner shall ensure developer changes to an operational system go through the system’s configuration change control (CM-3). (SA-10c)

From the System and Services Acquisition Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

SA-10 asks you to require configuration management from the developer, whether an outside supplier or an in-house team. The developer manages changes to the configuration items, makes only approved changes, documents their security and privacy impacts, and tracks and reports security flaws. NIST’s SA-10 discussion treats the quality of the developer’s configuration management as direct evidence that the controls work. It lists the items to place under control: design specifications, source code and hardware schematics, the running object code, comparison tools, and test fixtures and documentation.

NIST’s Secure Software Development Framework, SP 800-218 (February 2022, version 1.1; version 1.2 is a December 2025 draft; as of September 2026), cites SA-10 for practice PS.1, protecting all forms of code from unauthorized access and tampering.

Common implementations. Source control, such as Git, holding source code, build scripts, pipeline configuration and infrastructure as code. Protected main branches that need a reviewed pull request, and signed commits or tags. Each change linked to an approved ticket that notes its security and privacy impact. Build pipelines that produce released executables only from the protected branch, and keep them with their checksums. A security flaw tracker, with findings reported to the system owner and the CISO. Contracts that require the same of an outside developer (SA-4). Changes to the operational system still go through the system’s own change control, CM-3.

Organization-defined parameters. Typical values, which your organization may set differently:

Parameter	Typical value
Life cycle stages for configuration management (a)	Design, development, implementation and operation
Configuration items under configuration management (b)	Design specifications, source code, build scripts and pipeline configuration, infrastructure and configuration as code, test scripts and results, and each released executable
Who receives flaw findings (e)	The system owner and the Chief Information Security Officer

The first value selects four of the five stages; disposal falls to the organization’s own processes. In the System and Services Acquisition policy, the system owner requires each item of the developer.

Evidence assessors ask for.

• The contract or internal standard that requires developer configuration management
• The developer’s configuration management plan or documented process, naming the configuration items
• Repository settings: branch protection, required reviews, and who can change them
• A sample of changes, each traced to an approval and a recorded security and privacy impact
• The flaw tracking records, and the reports sent to the system owner and CISO

Inheritance. A shared development platform (source control, pipelines, flaw tracker) may be a common control for in-house teams. For a commercial product, the supplier performs SA-10 and the organization relies on the contract and the supplier’s evidence. The system owns requiring it and reviewing the results.

Common findings.

• Developers able to push directly to the production branch, or to change pipeline settings without review.
• Changes deployed without a matching approved change request.
• Security flaws discussed in chat but never tracked or reported.
• No SA-10 terms in the contract with an outside developer.

Enhancements in the Moderate baseline. None. SA-10(1) to SA-10(7), including software and firmware integrity verification and trusted distribution, are in no baseline.

Artifacts

• Acquisition Security Requirements
• System and Services Acquisition Decision Worksheet
• System and Services Acquisition Policy