What SA-10 developer configuration management asks for
SA-10 binds the developer of a system, component or service to configuration management, change control and security flaw tracking. A moderate or high baseline system, or a vendor-built component running inside one, needs SA-10 evidence before an assessor will accept the way its code and firmware reach production. The control is an assurance requirement: it asks the developer to control which changes are made, prove they were approved, and show how known flaws were tracked to resolution. The risk it addresses is simple to state and hard to test. Changes that nobody approved, or that cannot be traced to a reviewed baseline, can reach production unnoticed, and the organization running the system may have no reliable way to tell what it is actually operating.
The difficulty grows when the developer is an external party. An organization can enforce change control on its own engineers through its own tools, but a vendor or outsourced development team controls its own repositories, build pipelines and release process. The organization therefore has to define, in the acquisition contract and in the service arrangement, which configuration items fall under SA-10, what evidence the developer must produce, how often, and what happens when a change is made without approval. Ask the developer to show change authorization records, configuration management records and flaw tracking records for a recent release, and confirm that those records cover the components you will actually run, not only the core product.
For self-hosted open-source platforms, much of the developer side can be held in your own infrastructure. Protected branches in GitLab Community Edition can restrict who may push or merge to a branch, block direct pushes, and keep force pushes disabled unless explicitly allowed, which gives a repeatable trail of approved changes. GLPI's Assistance module can hold change and problem records under ITIL practice, and Zammad can hold ticket history for flaw reports. Confirm with your own assessor which records they will sample and whether a self-hosted tool's audit trail meets their expectations before you build your process around it.
Which developers, systems and changes fall under SA-10
SA-10 applies to whoever builds or changes a system, component or service, whether that is an internal team, a contractor or a vendor. The scope decisions below determine which developers, components and change records the control reaches, and how much of the work sits with your contracts rather than your own engineers.
Internal development teams
Your own engineers are the developer when they write, configure or modify the system. SA-10 expects them to run configuration management: track changes to defined configuration items, implement only approved changes, and record approvals and impacts. Check that your internal teams work from a documented change process and that repository, pipeline and ticket records show who approved each change. Assessors typically start with these internal records because they are the easiest to sample.
External developers and vendors
When a vendor or integrator builds or changes a component for you, the vendor usually carries the developer role. Your contract should require the vendor to keep configuration management records, report flaws, and document approved changes, because SA-10 evidence has to come from the developer. Identify each third party that touches code, firmware or configuration, and confirm in writing how it will supply records to your assessor.
Systems, components and firmware in scope
SA-10 covers the system, its components and services, not only application code. Firmware, appliance images, container base images, infrastructure-as-code and vendor-supplied libraries can all be configuration items. Build an inventory of the items you have defined as configuration items, and state which ones the developer controls and which ones your team controls. Gaps in this inventory are the most common reason change records fail to cover what actually runs.
Moderate or high baseline selection
SP 800-53B assigns SA-10 to the moderate and high security control baselines, so a system categorized as low does not have it as a baseline control. Confirm your impact categorization before scoping, because moving a system from low to moderate adds this control and its evidence. Tailoring can change the selection, but record every tailoring decision and its rationale in the security plan.
FedRAMP Class C and D requirements
If the system is assessed under FedRAMP, the Rev5 baselines require SA-10 at Classes C and D. Ask whether your authorization path maps to those classes and whether any FedRAMP-specific parameters or related indicators change what you must produce. Treat this as a scoping input: a cloud service with FedRAMP obligations usually needs vendor developer records that a standard enterprise system does not.
Contract allocation of the developer role
SA-10 is written against the developer, so the contract decides who holds the obligation when work is outsourced. Specify which party performs configuration management, who approves changes, where records are kept, and how flaw tracking hands off to your security team. Ambiguous allocation is the usual reason an assessor finds a gap after go-live. Ask any implementation partner to confirm which controls it prepares and which records your organization must keep itself.
How an assessor tests SA-10 in SP 800-53A
The examine method is where most of SA-10's assessment work happens. SP 800-53A pairs the examine method with a set of suggested assessment objects, which are the records an assessor expects to see. For SA-10, these include security flaw and flaw resolution tracking records, system change authorization records, change control records and configuration management records. An assessor reads these records to confirm that the developer tracks flaws, approves changes before they are implemented and keeps configuration items under control.
- Flaw tracking records: Entries showing each security flaw, its status, its owner and the date and method of resolution.
- System change authorization records: Approvals showing who authorized each change to a configuration item before it went into the system.
- Change control records: Requests, reviews and decisions for changes, including the documented impact of each approved change.
- Configuration management records: Current and historical records of defined configuration items and their versions.
- Sampling: Assessors typically select a sample of changes and flaws and trace each one through the records, so gaps in any single record matter.
Confirm that your records link each change to its approval, its documented impact and any related flaw, so an assessor can follow one item across all four object types.
The interview method asks people to explain how the process works in practice. For SA-10, an assessor interviews the people who approve changes, those who maintain configuration items and those who handle flaw resolution. The purpose is to check that the written process matches daily practice and that staff can describe what they do without reading from a document. Interviews often reveal whether approvals happen in the tool of record or in side channels such as chat.
- Change approvers: Who approves changes, what they check and how they document the impacts they considered.
- Configuration managers: How configuration items are defined, how versions are recorded and how unapproved changes are detected.
- Flaw handlers: How security flaws are reported, prioritized, assigned and closed, and who verifies the fix.
- Process owners: How the developer decides which changes need review and how exceptions are handled.
- Consistency: Assessors compare answers across roles, so staff should describe the same process in the same terms.
Confirm that the people named in your procedures can describe the change and flaw process accurately and point to the records that prove it.
The test method checks that a mechanism works as described. For SA-10, an assessor may test whether the change control workflow blocks an unapproved change, whether protected branches prevent direct pushes to controlled code and whether flaw tracking records update when a fix is merged. Test results are only as useful as the reproducibility of the test, so assessors look for defined test steps, expected results and recorded outcomes. Testing is usually performed in a non-production copy or a controlled test case so that the live environment is not disturbed.
- Approval enforcement: Attempting a change without the required approval and confirming the system rejects it.
- Branch protection: Attempting a direct push to a protected branch and confirming that the platform blocks it.
- Traceability: Following a sample flaw from report to fix to closure and checking that each step is recorded.
- Configuration integrity: Comparing a configuration item against its recorded baseline to confirm that changes were logged.
- Repeatable evidence: Retaining test scripts, inputs, outputs and dates so the result can be re-run.
Confirm that each mechanism your organization relies on can be tested on demand and that the test results are retained with the other SA-10 evidence.
Implementing SA-10 in the developer's workflow
This sequence turns SA-10 from a policy statement into working records: a defined set of configuration items, enforced branch and approval rules, documented change authorizations, and tracked security flaws. Each step leaves an artifact an assessor can examine.
Define the configuration items
The engineering lead, with the system owner, lists every item that SA-10 should keep under change control: source repositories, infrastructure-as-code, build pipeline definitions, container base images, deployment manifests, and any firmware or signed artifacts the developer produces. Each entry names an owner, the repository or location, and the environment it feeds. The output is a configuration item list approved by the system owner. Done means every production artifact traces back to a listed item, and the list is stored in the configuration management plan so reviewers can compare it against actual repositories.
Set branch protection and approval rules
The platform team configures protected branches on each configuration item so that only defined roles can push or merge, direct pushes to release branches are blocked, and force pushes stay disabled unless a named exception applies. In a self-hosted GitLab Community Edition instance, these are set per branch in the project settings. The output is an approval policy that states who may approve which change types. Confirm the settings in the live instance, export them, and keep the export with the policy so the configuration can be shown as it actually runs.
Record change authorizations before merge
Each proposed change gets a ticket that describes the change, its security impact, the reviewer, and the approval decision before code reaches a protected branch. A self-hosted helpdesk such as GLPI, using its Assistance module for tickets and changes, or Zammad, can hold these records with links to the merge request. The output is a change authorization record for each change. Done means a sample of merged changes can each be traced to an approved record, and any change without one is flagged for review.
Document approved changes and their impacts
The developer writes a short impact note for each approved change covering affected components, configuration items, and any effect on security functions or documentation. The note is attached to the change record and updated when the change is deployed. The output is a change log that links every release to its approved changes. The check is whether a reviewer can reconstruct, for any release, what changed, who approved it, and what it affected, without asking the developer.
Route security flaws into a tracked register
Static analysis findings, dependency alerts, and reports from testing or external parties are logged as flaws with severity, owner, and target resolution state. Semgrep Community Edition can run in CI/CD to scan repositories continuously across the languages in your codebase, and its findings feed the register. The output is a flaw register that records each flaw from identification through resolution. Confirm which languages your pipeline covers, because the scanner's supported language list determines what it can see.
Link flaw fixes to change records
Every flaw resolution is delivered as an approved change, so the fix goes through the same branch rules and authorization as any other change. The register entry is updated with the change identifier and the verification result. The output is a closed flaw record that points to the change that fixed it. Done means no flaw is marked resolved without a linked change, and the register can show open, in-progress, and closed items with dates recorded by the tools rather than by memory.
Verify build integrity and retain evidence
The platform team confirms that the build pipeline produces artifacts only from approved commits on protected branches, and that the artifact identifiers can be matched to the change log. Checks include reviewing pipeline logs, comparing hashes where the build produces them, and sampling releases against records. The output is a periodic verification record, signed off by someone outside the development team. Confirm with your assessor which integrity checks they expect for your system, since SA-10 does not prescribe specific tooling.
Evidence that passes an SA-10 assessment
SP 800-53A assessors test SA-10 by examining records, so the evidence has to show who approved each change, what it affected and how flaws were closed. The cards below map to the examine objects in the assessment procedures, and each one needs to be kept current between assessments rather than assembled at audit time.
Protected branch settings
Export the branch protection configuration for every repository that builds the system or its components. Assessors look for restrictions on which roles can push or merge to the main branches, direct pushes blocked by setting push access to no one, and force pushes disabled unless explicitly approved. Re-export after every change to the settings and store the export with the change records, so you can show the configuration that was in force on any given date.
Merge and approval records
Keep the merge request history that links each code change to a reviewer, an approval and a timestamp. The approval record must come from the platform, not from a spreadsheet filled in afterward. Check that approvers are not the authors of the change, and that any exceptions to the normal review path are recorded with a named authorizer and a reason. Assessors use this trail to test whether only approved changes reach the baseline.
Change tickets with impact analysis
Each approved change should have a ticket that describes the change, the configuration items it touches, its security impact and the test results used to decide it. Tickets built on ITIL-style change processes, such as those in GLPI's Assistance module, can hold this record and link it to commits. Confirm that the impact analysis is written before implementation, because a ticket completed after deployment shows that the change control did not operate as described.
Configuration baselines
Maintain a versioned record of the configuration items the developer controls, such as build definitions, container base images, infrastructure code and firmware versions, with the approved state of each. Review the baseline at a set interval and after significant changes, and keep prior versions so you can show what the configuration was when a flaw was introduced. Assessors compare this baseline against deployed systems to test whether the approved configuration is the one in use.
Flaw tracking and resolution dates
Track each reported security flaw from discovery to resolution in a single register, with the affected component, the severity, the fix version and the date it was closed. SA-10 specifically asks for flaw tracking and the resolution of those flaws, so gaps in the register are findings. Helpdesk tools such as Zammad can route vulnerability reports from customers or researchers into tickets, which helps keep intake and resolution in one auditable trail.
Release integrity records
Record the checksums, signatures and build provenance for each release that leaves the developer, and retain them with the change and flaw records for that version. This supports the integrity verification enhancements of SA-10, which concern whether software and firmware delivered to the customer match what was approved. Confirm the signing keys are controlled, and test a verification step in a clean environment before you rely on it in an assessment.
What meeting SA-10 costs in money and effort
This table breaks SA-10 costs into components, showing who is paid, whether each item is one-time or recurring, and what drives it up or down. Use it to shape a quote request, since no price is published for this control and the real figure depends on your developer population and release pattern.
| Cost component | Who is paid or who carries the effort | One-time or recurring | What drives it |
|---|---|---|---|
| Tooling and licenses | Software vendors or none if self-hosted open source is chosen | Recurring for commercial tools, usually none for community editions | Number of developer seats, hosting model and whether premium features such as advanced reporting are needed |
| Configuring change control workflows | Internal platform team or implementation partner | One-time, with periodic rework after process changes | Number of repositories, branch protection rules, approval roles and ticket workflow design |
| Engineering time for flaw tracking | Internal developers and security staff | Recurring with every release cycle | Release frequency, volume of flaws raised and how many systems share one tracker |
| Evidence upkeep | Internal compliance or engineering staff | Recurring, usually tied to each assessment period | How often change records are exported, reviewed and retained, and whether evidence is generated automatically |
| External developer oversight | Internal reviewers, plus costs of enforcing terms in external contracts | Recurring for each external supplier, plus one-time contract drafting | Number of external developers, contract terms on configuration records and access to supplier repositories |
| External testing or review | Independent assessors or security testing providers | Periodic, scoped per assessment | Size of the codebase, number of components and whether firmware is in scope |
| Assessor sampling | Independent assessor, billed according to its own engagement terms | Recurring at each assessment | How many changes and flaws the assessor samples, and how complete the records are on first request |
| Ongoing governance and review | Internal change advisory or configuration owners | Recurring | Frequency of configuration item changes and the number of approvers in the change process |
Who owns SA-10 and what can be outsourced
SA-10 is a requirement on the developer of a system, component or service, so the organization that builds or directly commissions the system carries accountability for it even when others write the code. Outsourcing does not transfer that accountability. The organization decides which configuration items are under control, who may approve changes, what counts as a security flaw requiring tracking, and how approved changes are documented against their impacts. These decisions are policy and governance choices that must be made by people who answer for the risk.
- Configuration item scope: Decide which artifacts (source repositories, build scripts, infrastructure definitions, firmware images) are controlled configuration items.
- Change approval authority: Name the roles that may approve changes to production-bound code and record how approval is granted.
- Flaw tracking rules: Define what is logged as a security flaw, who triages it and what resolution evidence closes it.
- Developer obligations in contracts: Write the SA-10 expectations into statements of work or internal engineering standards, including for external developers.
- Risk acceptance: Sign off on exceptions, such as emergency changes that bypass normal approval, and track them to closure.
Before engaging any partner, confirm internally who holds each of these decisions and where the approvals will be recorded.
An implementation partner can configure the tools that enforce SA-10 and prepare the records an assessor will examine. This work is largely technical and fits a fixed-scope engagement with written deliverables. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so the configuration lives under the client's control after handover.
- Repository controls: Set up protected branches, restricted push and merge roles and disabled force pushes in a self-hosted GitLab instance, as an illustrative example, so that unapproved changes cannot reach protected branches.
- Automated checks in pipelines: Wire static analysis such as Semgrep Community Edition into CI/CD so that flaws surface as tracked findings.
- Change and flaw tickets: Configure a ticketing system such as GLPI's Assistance module to hold change and problem records with approvals and impacts.
- Evidence exports: Prepare reports from these systems that show approvals, change history and flaw resolution for examination.
- Runbooks and handover: Document how the controls operate and train the client's staff to run them.
Ask the partner to list every system that produces evidence and who will own each one after the engagement ends.
An independent assessor examines the configuration management records, interviews staff and tests whether the controls work as described. SP 800-53A Release 5.2.0 gives the assessment procedure for SA-10, using examine, interview and test methods. The assessor needs direct access to the actual records and personnel, not a summary written by the partner. Who issues the final assessment depends on the program, such as a federal authorizing official, an agency inspector or an accredited third-party assessor under FedRAMP.
- Examine objects: Expect requests for change control records, system change authorization records, configuration management records and flaw tracking and resolution records.
- Interview questions: Staff who approve changes and triage flaws should be able to explain the process without referring to a consultant.
- Test samples: The assessor may select recent changes and trace each one from request to approval to deployment.
- Gaps as findings: Missing approvals or unresolved flaws appear in the assessment report and go into the plan of action and milestones.
Confirm with your authorizing body which assessor type applies before preparing evidence, because the requirements differ.
Independence means the assessor did not design, configure or operate the controls being assessed. If the same firm builds the pipeline, writes the change policy and then certifies that the policy works, the assessment loses credibility. An implementation partner may help a client prepare for assessment, but it cannot issue the assessment, a report or a certificate. DeployOpen prepares systems, controls and evidence and does not issue audit reports, attestations or certifications.
- Partner limits: Remediation work and evidence preparation are allowed; signing off the final conclusion is not.
- Assessor limits: An assessor who helped design the controls should disclose it and consider whether the engagement still meets the authorizing body's independence rules.
- Client role: The organization accepts the assessment result, decides on risk and funds remediation.
- Documentation of roles: Record who did which work in the system security plan or equivalent so the boundary is visible to reviewers.
- Contract wording: State in the engagement letter that the partner does not issue assessment results.
Check your authorizing body's independence requirements in writing before selecting either a partner or an assessor.
Where SA-10 programs usually fall short
SA-10 programs tend to fail at the points where change control meets daily engineering practice: who can push code, what gets reviewed before approval, how flaws are closed, and who counts as the developer. Each card below names one gap an assessor commonly probes, with a closing action the organization can take before the assessment.
Direct pushes to protected branches
Protected branches exist, but many teams leave push access open to developers or allow force pushes, so changes reach production history without an approved merge request. An assessor testing SA-10 will look for the change authorization trail and find commits that have none. Check that push access on release branches is set to no one, that force pushes stay disabled, and that every merge traces to a recorded approval. GitLab's protected branch settings are the place to confirm this.
Approvals without impact analysis
Change boards often approve requests on a ticket title and a reviewer's initials, with no written statement of what the change affects. SA-10 expects approved changes and their security impacts to be documented, so a bare approval does not show that the impact was considered. Require each change record to name the affected configuration items, the security functions touched and the test evidence that supports the impact statement before approval is recorded.
Flaw tickets closed without resolution evidence
Security flaws are often marked resolved when a fix is merged, not when the fix is verified in the deployed component. An assessor examining flaw tracking records will ask for the link between the finding, the change, and a retest or scan result. Make the closure rule explicit: a flaw ticket closes only when it references the merged change, the release that carried it and the verification result. A ticketing tool such as GLPI can enforce these fields on a change or problem record.
Unmanaged external developers
Contractors, offshore teams and vendor engineers frequently commit to repositories through shared accounts or personal tokens that are never reviewed. SA-10 applies to the developer whether it is internal or external, so the contract and the access model must place these people under the same change control. Confirm that each external developer has a named identity, that their access is tied to the change process, and that the acquisition contract requires them to follow it.
Configuration items never defined
Many programs cannot answer which items are under configuration management, so change control has no defined scope to enforce. Without a list of configuration items, an assessor cannot test whether changes to them were authorized. Start with a written inventory covering source repositories, build pipelines, infrastructure definitions, firmware and signing keys, and record an owner for each. Review the list whenever a system boundary changes.
Scanning that does not gate merges
Static analysis is sometimes run on a schedule, so findings appear after code has already merged. That weakens the link between development and flaw tracking that SA-10 asks for. Semgrep Community Edition can run in CI/CD pipelines against many languages, so findings can be attached to merge requests. Confirm which findings block a merge, who may accept a risk, and how accepted risks are recorded and reviewed.
Questions buyers ask about SA-10
How much does meeting SA-10 cost?
No price can be stated from the facts available, and DeployOpen does not publish a price list. Cost is driven by who builds the change control and flaw tracking, how many developers and suppliers the requirement reaches, how many systems and components are in scope, and whether the tools already in place can produce the records. The organization pays for its own staff time and any tooling licenses, and an implementation partner is paid under a fixed-scope written agreement. Ask any partner for a quote that separates one-time setup (process design, tool configuration, integration with the pipeline) from recurring work (reviewing change records, running flaw reviews, retaining evidence each cycle). Ask also which items assume the organization already has ticketing, source control and an approved change process.
How long does SA-10 preparation take?
The duration depends on how mature the development process is and how many teams and external developers fall under the requirement. No timeline is supplied for this control, so treat any number you hear as unverified until it is tied to a written scope. Preparation usually needs a named owner for configuration management, access to source control and the change ticketing system, time from developers to adopt approved-change workflows, and a sample of past change and flaw records to show the process works. An assessor will expect several cycles of real records, so the work is not finished when the policy is written.
Can we meet SA-10 without an outside partner?
Yes, an organization can meet SA-10 with its own staff, provided it owns the control and can produce the evidence. The control is about the developer, so an in-house engineering team can run it directly. The hard parts are consistent enforcement across every repository, keeping change records complete, and tracking flaws through resolution. Teams that lack staff with configuration management experience, or that have many external developers, often bring in help for setup and testing. Whatever the choice, the organization remains accountable, and only an independent assessor issues the assessment result.
What should a written scope for SA-10 include?
A written scope should name the systems, repositories, pipelines and developers covered, and say whether internal teams, external developers or both are included. It should list the configuration items under control, the approved change workflow and who authorizes changes, and the flaw tracking process from report to resolution. Ask the partner to state which deliverables they produce, such as configured branch protections, change record templates, flaw tracking integration and a mapping of evidence to the SA-10 assessment objects. The scope should also state what the organization must provide, including access, named owners and sign-off, and what the partner will not do, since only an independent assessor can issue a report.
How does SA-10 relate to FedRAMP KSI-SCR-MIT?
FedRAMP 20x lists SA-10 among the related SP 800-53 controls for Key Security Indicator KSI-SCR-MIT, which concerns mitigating supply chain risk. The link is that SA-10 requires the developer to control changes and track flaws, which supports a supplier's ability to show what it changed and how it fixed weaknesses. Confirm the exact indicator wording and its requirements in the current FedRAMP rules before relying on it, because the indicator and its mapping are defined by FedRAMP, not by this page. A KSI-related record does not replace the SA-10 evidence itself, so keep change and flaw records in a form an assessor can sample.
Which open-source tools produce SA-10 evidence?
Several self-hosted tools can produce evidence for parts of SA-10. GitLab Community Edition protected branches can restrict who pushes or merges, block direct pushes, and keep force pushes disabled unless explicitly allowed, which supports controlled approved changes. GLPI's Assistance module supports tickets, problems and changes following ITIL practices, which can hold change authorization and impact records. Semgrep Community Edition can run in CI/CD pipelines to scan repositories, which helps show flaws are detected. Confirm each tool's fit with your repository layout and retention needs before adopting it, since a tool produces records but does not by itself satisfy the control.
Is SA-10 required in every NIST baseline?
SA-10 is assigned to the moderate and high security control baselines in SP 800-53B, not to the low baseline. Its enhancements are not assigned to any SP 800-53B baseline, so the base control carries the baseline requirement. FedRAMP's Rev5 baselines require SA-10 at Classes C and D. Check the baseline your system is categorized under, and any agency or contract overlay, before you scope the control, because tailoring can change what applies.
How DeployOpen prepares SA-10 evidence
DeployOpen prepares the systems and records that support SA-10 evidence, but the organization remains responsible for its own developer configuration management controls, and only an independent assessor can test them and report on them. The work starts with a written scope that names the systems, repositories, change workflows and developer roles in question, along with the deliverables and timelines agreed before any work begins. Engagements are fixed-scope, so the organization knows in advance which configuration items, approval paths and flaw-tracking records will be set up and handed over. DeployOpen does not issue audit reports, attestations or certifications.
Within the client's own cloud accounts, data centers or air-gapped networks, DeployOpen configures self-hosted open-source platforms so that the records an assessor would examine exist and can be retrieved. In practice this can mean protected branches in GitLab Community Edition with direct pushes blocked and force pushes disabled, a change workflow in GLPI's Assistance module that records approved changes and their impacts, and Semgrep Community Edition running in CI/CD to scan repositories and surface security flaws for tracking. Before scoping, ask the partner to confirm which of these capabilities fit your environment and which external developers, if any, must work through the same workflow. Confirm the exact configuration against the current vendor documentation during the design phase.
