Developer Configuration Management

LOW ✓ MODERATE ✓ HIGH
7 Enhancements 1 Overlay 14 Related Controls
Graph
Export ▾

Requirements NIST SOURCE

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

Discussion (NIST Supplemental Guidance)

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.

Enhancements NIST SOURCE

SA-10(1) Software and Firmware Integrity Verification LOW MODERATE HIGH

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

Discussion

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.

Open full page for SA-10(1) →
SA-10(2) Alternative Configuration Management Processes LOW MODERATE HIGH

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

Discussion

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.

Open full page for SA-10(2) →
SA-10(3) Hardware Integrity Verification LOW MODERATE HIGH

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

Discussion

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.

Open full page for SA-10(3) →
SA-10(4) Trusted Generation LOW MODERATE HIGH

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

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.

Open full page for SA-10(4) →
SA-10(5) Mapping Integrity for Version Control LOW MODERATE HIGH

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

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.

Open full page for SA-10(5) →
SA-10(6) Trusted Distribution LOW MODERATE HIGH

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

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.

Open full page for SA-10(6) →
SA-10(7) Security and Privacy Representatives LOW MODERATE HIGH

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

Discussion

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.

Open full page for SA-10(7) →

Implementation Guidance

Engineering Interpretation

Original engineering commentary written for this explorer — not NIST source text and not authoritative guidance.

No engineering interpretation has been authored for SA-10 yet. This section is architected to receive it — see the Requirements and Assessment sections above for the authoritative NIST source content in the meantime.

Assessment

NIST SP 800-53A REV 5.2.0

Assessment Objectives

  1. one or more of the following PARAMETER VALUES is/are selected: {design; development; implementation; operation; disposal};
  2. configuration items under configuration management are defined;
  3. personnel to whom security flaws and flaw resolutions within the system, component, or service are reported is/are defined;
  4. the developer of the system, system component, or system service is required to perform configuration management during system, component, or service <SA-10_ODP[01] SELECTED PARAMETER VALUES>;
  5. the developer of the system, system component, or system service is required to document the integrity of changes to <SA-10_ODP[02] configuration items>;
  6. the developer of the system, system component, or system service is required to manage the integrity of changes to <SA-10_ODP[02] configuration items>;
  7. the developer of the system, system component, or system service is required to control the integrity of changes to <SA-10_ODP[02] configuration items>;
  8. the developer of the system, system component, or system service is required to implement only organization-approved changes to the system, component, or service;
  9. the developer of the system, system component, or system service is required to document approved changes to the system, component, or service;
  10. the developer of the system, system component, or system service is required to document the potential security impacts of approved changes;
  11. the developer of the system, system component, or system service is required to document the potential privacy impacts of approved changes;
  12. the developer of the system, system component, or system service is required to track security flaws within the system, component, or service;
  13. the developer of the system, system component, or system service is required to track security flaw resolutions within the system, component, or service;
  14. the developer of the system, system component, or system service is required to report findings to <SA-10_ODP[03] personnel>.

Examine

[SELECT FROM: 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

[SELECT FROM: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; organizational personnel with configuration management responsibilities; system developers].

Test

[SELECT FROM: Organizational processes for monitoring developer configuration management; mechanisms supporting and/or implementing the monitoring of developer configuration management].

Overlays

OT/ICS Overlay SP 800-82r3

NIST SP 800-82r3 Appendix F, Table 22. Blank baseline means the control/control enhancement is not selected in that initial OT baseline.

LOW

Not applicable at this tier.

MODERATE

  • Base control: Included (matches standard baseline)

HIGH

  • Base control: Included (matches standard baseline)

STIGs & CCIs

No STIG checks or CCI mappings are currently loaded for SA-10. This section is architected to display, per product: STIG ID, Finding ID, Severity, Title, Description, Check, Fix, CCI, and NIST control mapping — but nothing is populated here until a real DISA STIG/CCI dataset is ingested.

Learn more about STIG/CCI integration →

Evidence

Potential Evidence — Derived

Categorized from the SP 800-53A "Examine"/"Test" artifact list above by keyword — not an authoritative NIST evidence list.

Policy

  • System and services acquisition policy
  • system security plan

Configuration

  • procedures addressing system developer configuration management
  • system developer configuration management plan
  • configuration management records

Testing

  • Organizational processes for monitoring developer configuration management
  • mechanisms supporting and/or implementing the monitoring of developer configuration management

Other Records

  • solicitation documentation
  • acquisition documentation
  • service level agreements
  • acquisition contracts for the system, system component, or system service
  • security flaw and flaw resolution tracking records
  • system change authorization records
  • change control records
  • other relevant documents or records