SA-15 Development process: requirements and evidence

What the SA-15 development process requirement asks your engineering team to do

SA-15 asks your engineering team to write down how it builds software, follow that process, and show that both change deliberately over time. In NIST SP 800-53 Rev. 5, the requirement is that the developer follows a documented development process that addresses security and privacy requirements, identifies and controls changes to the standards and tools it uses, and is reviewed periodically against defined requirements. If an audit or baseline requirement has just landed on engineering, the work is less about buying a control and more about producing a process document, a tool inventory and a review record that match what developers actually do. SP 800-53B places SA-15 in the moderate and high baselines, so organizations in those baselines should expect an assessor to test it.

The risk behind the control is familiar: insecure build practices, unreviewed dependencies and unmanaged tooling can introduce flaws or weaken the supply chain before a product ever reaches production. The difficulty is that the process has to exist on paper, be followed by people under deadline pressure, and be visibly revised as tools change. Your team should decide which tools are in scope, such as the source host, static analysis, software composition analysis and build runners, record their versions and configuration, and name an owner who approves changes to them. A practical starting point is to confirm how protected branches, required reviews and scanner rules are configured in each repository, because an assessor will ask for the settings and the change history, not only the policy statement.

Plan for the periodic review as a recurring task with a defined scope, not a one-time sign-off. The review should compare the written process and tooling against the security and privacy requirements the organization has defined, and it should leave a dated record of findings and changes. Ask your assessor which maturity model or internal checklist they expect you to use for that review, since SP 800-53A lists documentation of development process reviews as an examine object. Confirm with your assessor and your system owner which enhancements apply to your system before scoping the work, because the baseline selection determines how much of the enhancement set you must address.

Which systems, teams and suppliers SA-15 applies to in practice

SA-15 applies to a system only when a baseline or contract selects it, and then it reaches every party that writes or changes the code. The cards below cover the decisions that settle scope: which baseline selects the control, which systems and teams sit inside it, who builds the component, which tools count as part of the controlled toolchain, and which enhancements apply.

Baseline selection

SP 800-53B assigns SA-15 to the moderate and high baselines, so a low-impact system does not need it by baseline alone. FedRAMP's Rev5 baselines also require SA-15 and SA-15(3) at Classes C and D. Confirm the impact categorization of each system in the authorization boundary, and check whether a customer contract adds SA-15 to a system that would otherwise fall in the low baseline.

Systems and development teams in scope

The control reaches the systems the organization develops or modifies, including custom applications, infrastructure code and integrations, not only the product that ships to customers. Map each development team to the systems it changes. Teams that maintain internal tooling used to build or deploy in-scope systems often fall inside the process as well, so document them explicitly in the development process rather than assuming they are covered.

Internal, contractor and external developers

SA-15 is written for the developer, and the developer may be an internal team, a contractor or an external vendor. Where a third party builds a component, the acquisition contract must require the vendor to follow a documented process and to keep its tools under configuration control. Ask each supplier to show its process and tool list, and confirm that the contract gives the organization the right to review them periodically.

The controlled toolchain

The toolchain includes every system that stores, builds, tests or releases code. In practice this means the source repository, branch protection settings, CI/CD runners, code and dependency scanners, and the systems that hold software bills of materials. Typical open-source examples are GitLab Community Edition for protected branches, Semgrep Community Edition for code scanning, and OWASP Dependency-Track for SBOM and vulnerability tracking. Record each tool, its version and its configuration owner, because SA-15 requires those tools to be identified and controlled.

Enhancements SA-15(3) and SA-15(13)

SA-15(3) is selected by both the moderate and high baselines, so it applies wherever SA-15 does. SA-15(13) Logging Syntax was added in Release 5.2.0 to set clearer logging requirements for developers, but NIST did not assign it to any SP 800-53B baseline. It applies only where the organization or a contract adopts it, so record that decision explicitly and confirm whether the assessor expects it.

How an assessor tests SA-15 development process controls

This table compares what an SP 800-53A assessor examines and interviews for SA-15, the evidence each method produces and the findings that most often appear. Read it as a checklist of what to have ready before an assessment, since the organization must show its own process and tooling in operation.

Assessment area	What the assessor does	Evidence to have ready	Common finding
Determination statements (9)	Checks each of the nine SP 800-53A determination statements for SA-15 against the organization's documentation and practice	A mapping from each statement to the document or record that answers it	Statements answered only by a policy, with no record of the process running
Examine: development process documentation	Reads the documented development process and confirms it addresses security and privacy requirements	Approved development process document with version history and named owner	Process document exists but omits security and privacy steps
Examine: critical component inventory	Reviews the inventory of critical components the developer builds or relies on	Current inventory listing components, owners and criticality	Inventory is stale or missing components added later
Examine: developer tool documentation	Checks that the documentation lists tool options and configuration guides for the tools in use	Tool list with versions, configuration guides and recorded option settings	Tool versions in use are not listed anywhere
Examine: configuration management records	Traces changes to development standards and tools through change records and approvals	Change tickets or commits showing who changed a tool or standard, when and why	Tool version changed with no change record
Examine: process review documentation	Looks for periodic reviews of the process and tooling against defined requirements	Review reports, dates, participants and any maturity model used for the review	No evidence that a periodic review took place
Interview: developers and process owners	Asks how the process is followed day to day and how tool changes are approved	Staff able to explain the process and point to records supporting their answers	Staff describe a different process from the written one
Assurance focus	Because Appendix C marks SA-15 as organization-implemented and assurance-related, the assessor relies on what the organization can show, not on vendor statements	Evidence the organization generated itself, such as pipeline logs and review minutes	Reliance on a tool vendor's claims without the organization's own records

How to implement SA-15 in a sequence your auditor can follow

This sequence turns SA-15 from a policy statement into a documented development process, controlled tooling, enforced repository protections, automated checks and a recorded periodic review that an assessor can test end to end. Your organization owns each output, and an independent assessor decides whether the evidence meets the control.

Scope the systems and developers
Name the systems, repositories, pipelines and development teams that the SA-15 process will cover, including internal developers and any external developers or contractors who write code for the system. Record which parts are owned by the organization and which are delivered by a third party, because SA-15 applies to the developer and the contract must reflect that. The output is a signed scope statement listing each system, its developers and the accountable owner. The step is done when every repository and pipeline that builds production code appears in the scope statement.
Write the secure development process
Draft or update the documented development process so that it addresses security and privacy requirements at each stage, from requirements and design through coding, review, testing and release. Map each stage to the security and privacy requirements the system must meet, so an assessor can trace a requirement to the step that verifies it. The output is an approved secure development process document with a requirement-to-stage mapping table. The step is done when the process owner has signed the document and every mapped requirement has at least one named verification step.
Inventory standards and tools
Build a register of the languages, frameworks, scanners, CI/CD pipelines, code hosting platforms and SBOM tooling the teams use to develop and release the system. For each entry, record the version, the owner, the purpose and the configuration guide or vendor documentation that governs it. Include the critical components the system depends on, since the SA-15 assessment looks for an inventory of critical component documentation. The output is a tool and standards register that the process owner has reviewed. The step is done when the register matches what the pipelines actually run.
Place tool configurations under change control
Store the configuration files for pipelines, scanners, repository settings and SBOM generators in version control, and route every change through a reviewed merge request. Define who may approve a change to a tool configuration and how the change is recorded, so the organization can show that it identifies, configures and controls changes to the standards and tools it uses. The output is a tool configuration repository with a change log and a list of approvers. The step is done when a sample change to a scanner rule can be traced to a reviewer, a date and a reason.
Configure repository protections
Apply protected branch settings so that the approved process is enforced in the platform, not only described in the document. In GitLab Community Edition, protected branches let maintainers restrict which roles can push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Confirm these settings on the main and release branches, and export the settings as evidence. The output is a settings export and a test record showing a direct push to a protected branch being rejected. The step is done when the test record is saved with the settings export. Confirm the exact settings available in your platform version before you configure them.
Add automated code and dependency checks
Add static analysis and dependency checks to the pipeline so that each merge request is scanned before it can reach a protected branch. Semgrep Community Edition can scan the languages your teams use with community or custom rules and run in CI/CD pipelines. OWASP Dependency-Track can consume CycloneDX SBOMs and VEX, flag components with known vulnerabilities, outdated or modified components and license risk. Trivy can produce an SBOM from a target and scan existing SBOMs. The output is pipeline job definitions, sample scan reports and a list of rules and their owners. The step is done when a deliberately flawed test change fails the pipeline and the failure appears in the report.
Define periodic review criteria and maturity model
Write the criteria the organization will use to review the development process and its tooling, including the requirements they are checked against and the frequency of each review. Name the maturity model or internal scale used to rate each area, and state how findings will be scored. Assessors look for documented reviews that use a maturity model, so the scale must be defined before the first review. The output is a review procedure with criteria, a rating scale and a template for findings. The step is done when the process owner and the security lead have both approved the procedure.
Run the first review and record findings
Run the first review against the criteria using the scope statement, process document, tool register, configuration history, protection settings and pipeline reports. Record each finding with its owner, its rating and the corrective action, and track each action to closure in the organization's issue tracker. Keep the completed review, the findings log and the evidence of closure as the record of the periodic review. The output is a signed review report with an action log. The step is done when every finding has an owner and a status, and the report is ready for the independent assessor to examine.

Evidence that passes an SA-15 assessment and how to keep it current

An assessor testing SA-15 looks for a documented development process, a maintained inventory of the standards and tools in use, configuration control over those tools, and records showing the process is followed and reviewed. The cards below cover each artifact and how to keep it current between assessments without waiting for audit season.

Documented development process

This is the written process the developer follows, covering the security and privacy requirements it must address at each stage. An assessor will check that it names the standards and tools in scope and that it is the document people actually use. Check that it states who approves changes to it and where the current version is kept. Review it on a schedule you set and record each review date, so the document can show it has been revisited since it was last approved.

Critical component and tool inventory

This inventory lists the development tools, languages, frameworks and critical components the process depends on, with versions and owners. It is the starting point for proving the organization knows which standards and tools it governs. Tie entries to the repositories and build pipelines where they are used, so the list matches reality. Update it when a tool is added, retired or upgraded, not only before an assessment. A software bill of materials exported from your build can help keep this list accurate.

Tool configuration guides and baselines

Configuration guides and baselines record how each tool is set up, such as branch protection rules, scanner rulesets and pipeline settings. Store them in version control so every change has an author and a date. An assessor will compare the live configuration with the documented baseline, so confirm that the two match at each review. Where a tool offers its own documentation or configuration reference, retain the version you actually run, since guidance changes between releases.

Configuration change records for tools

These records show that changes to development tools and their settings are identified, approved and tested before they take effect. Keep a change request or merge record for each tool configuration change, with the reason, the approver and the rollback path. Record changes when they happen rather than reconstructing them later, because an assessor will sample from the period under review. Gaps in this trail are one of the most common reasons configuration control is judged weak.

Development process review records

Periodic reviews test whether the process and tooling still meet the defined requirements, and SA-15 expects them to be documented. Record the review date, the scope, the findings and the actions taken. If you score the process against a maturity model, keep the scoring worksheet and the rationale for each score so the result can be traced. Set the review cadence in your own policy and show that reviews happened on that cadence.

Pipeline and repository enforcement records

Repository and pipeline records show whether the documented process runs in practice. Protected branch settings, required reviews, scanner results and build logs demonstrate that controls are enforced rather than described. Export or snapshot these settings periodically, because a setting changed without a record is hard to explain. Confirm with your tool vendor which audit logs it retains and for how long, since retention varies by product and edition.

What meeting SA-15 costs in money and effort

This table lists the cost components of meeting SA-15, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. NIST does not estimate compliance costs, so use the rows to build a scoped question list for your own environment and for any written quote.

Cost component	One-time or recurring	What drives it up	How to keep it down
Tooling and licenses	Recurring for commercial add-ons, none for the core open-source set	Number of repositories, pipelines and suppliers in scope; commercial support or hosted tiers added on top of GitLab Community Edition, Semgrep Community Edition, Dependency-Track and Trivy	Use the open-source components where they meet your needs; confirm in writing whether any commercial add-on or support tier is required before you budget for it
Engineering time to write the development process	One-time, with periodic revision	Number of development teams, languages and deployment models; how many suppliers must follow the same process	Reuse one process across teams and reference it from SA-4 and SA-10 documents instead of writing separate versions
Engineering time to configure tool controls	One-time per tool, plus change effort	Number of tools whose configuration must be baselined under SA-15; number of protected branches, rule sets and CI/CD pipelines	Standardize configurations in version control so each tool is baselined once and changes are reviewed in one place
Evidence upkeep and change tracking	Recurring	Frequency of tool updates, rule changes and new repositories; number of records kept for each configuration change	Generate evidence automatically from pipelines and repository history rather than assembling it by hand before each assessment
Periodic process and tooling review	Recurring, at the interval your organization or assessor defines	Number of tools and process areas reviewed; whether the review uses a maturity model; FedRAMP or other baseline requirements that set the review scope	Define the review criteria once, record them against the defined requirements, and review changes between cycles instead of rebuilding the review each time
Enhancement work (criticality analysis, attack surface reduction, logging syntax)	One-time build, then recurring review	Number of components rated critical; scope of attack surface reduction; whether logging syntax requirements are written into developer standards	Limit enhancement scope to the components and systems your assessor expects, and confirm which enhancements your baseline selects before you start
External testing or independent review	Recurring, usually per engagement	Size of the application and API estate; whether testing covers developer-supplied components; number of release cycles	Agree scope and deliverables in writing before work starts so testing is priced against a defined target
Auditor or assessor sampling	Recurring, per assessment cycle	Number of systems under the moderate or high baseline; number of samples the assessor selects from change and review records; FedRAMP classes C and D	Keep records indexed by system and date so sampling requests can be answered quickly; ask the assessor for the sampling approach before fieldwork

Open-source tools that produce SA-15 evidence and their license caveats

SA-15 asks for a documented development process and controlled tooling, and the evidence an assessor reviews is usually a mix of repository settings, scan output and component inventories. The four tools below each produce one part of that evidence. None of them replaces the documented process, and each license has conditions an organization should confirm before relying on it.

GitLab Community Edition protected branches

Protected branches are the repository control that shows who can change the code under review. Maintainers can restrict which roles may push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless someone explicitly allows them. The exported settings and change history give an assessor concrete evidence of tool configuration control. The license is MIT, so the feature set is permissive, but the organization should confirm which features its chosen edition includes and who approves changes to these settings.

Semgrep Community Edition static analysis

Semgrep scans source code in many languages, including Java, Go, Python, TypeScript and Terraform, using community rules or rules the organization writes itself. Running it in CI/CD pipelines produces a repeatable scan record for each change, which supports SA-15 reviews of development standards. The LGPL-2.1-only license means the organization should check how it distributes or modifies the tool, and confirm that its custom rules and the rule sources it pulls in are licensed for its use. Scan output shows that checks ran; it does not show that the rules cover the organization's standards.

OWASP Dependency-Track SBOM management

Dependency-Track consumes and produces CycloneDX SBOMs and VEX documents, and flags components with known vulnerabilities, outdated or modified components and license risk. It also tracks license use by component using SPDX license IDs. This gives a development team a maintained inventory that an assessor can compare against the tooling and standards the process names. The Apache-2.0 license is permissive, but the organization still owns the decisions about which findings are accepted, how license risk is handled and who reviews the component list.

Trivy package and SBOM scanning

Trivy identifies OS packages and software dependencies in a target, and it can both produce an SBOM and scan an existing one. Producing an SBOM at build time gives the organization a dated record of what each build contained, which supports SA-15 reviews of the tools used in development. The tool is Apache-2.0 licensed. Confirm which vulnerability databases it uses and how often they update, because scan results are only as current as the data behind them. Trivy findings feed the review process; they do not replace it.

Who does what for SA-15: your team, an implementation partner and the auditor

Your organization owns SA-15. The control asks for a documented development process that covers security and privacy requirements, for control over the standards and tools that process uses, and for periodic review of both. Those decisions belong to you, because an assessor will ask who approved the process, who approved each tool and who reviewed them. A partner can draft material, but it cannot accept the risk on your behalf.

Process ownership: Name an accountable owner for the secure development process and the engineering leaders who must follow it.
Tool change approval: Decide which tools are in scope (code hosting, scanners, SBOM generators) and approve every version change, configuration change and exception.
Periodic review: Schedule the review, define its criteria and record its outcomes, including the maturity model or checklist used.
Sign-off: Accept the control implementation statement and the residual risk, and keep the signed records.
Day-to-day operation: Enforce branch protection rules, triage scanner findings and act on them.

Before assessment, confirm that each item above has a named owner and a dated record.

Where organizations fall short on SA-15 and how to close each gap

SA-15 is easiest to fail on paper: a process document exists, tools are in use, and scan reports are generated, but nobody can show that the process is followed, that tool changes are controlled, or that findings are acted on. The cards below name the gap an assessor is likely to find and the concrete artifact or tool setting that closes it.

Process document that nobody follows

The most common SA-15 finding is a secure development process written for the audit that describes practices the engineering team does not perform. Assessors test this through interviews and by sampling recent work against the written steps. Close it by writing the process around the pipeline your developers already use, naming who approves each gate, and keeping a record of each gate passing for a sample of recent changes. Check that interview answers from developers match the document.

Tool configurations changed without a record

Linters, scanners and CI settings change over time, and SA-15 expects the developer to identify, configure and control changes to the tools it uses. A rule set quietly disabled or a scanner set to report only can remove a security check without anyone noticing. Keep tool configuration files in version control, require review for changes, and log who changed each setting and why. Assessors will ask for configuration management records for these tools.

No inventory of standards and tools

Many teams cannot list the compilers, scanners, libraries and coding standards their products depend on, so they cannot show which tools are controlled. SA-15 assessment looks for documentation of the development environment, including tool options and configuration guides. Build a single inventory that names each tool, its version, its owner, the standard it enforces and the configuration file that governs it. Review the inventory at each planned process review.

Periodic reviews without criteria

A process review that never states what it measures produces minutes that assessors cannot test. SA-15 requires periodic review of the process and tooling against defined requirements, and the assessment procedure looks for documentation of reviews, including any use of maturity models. Define the review criteria in advance, such as gate coverage and tool configuration drift, record the findings, and track each corrective action to closure. Confirm with your assessor which maturity model, if any, they expect to see.

Unprotected branches allowing direct pushes

If anyone with write access can push straight to the main branch, the reviewed development process can be bypassed without a trace. In GitLab Community Edition, protected branches let you restrict which roles can push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Apply these settings to release branches first, then confirm with a test push from a developer account that the block works.

Dependency and SBOM output nobody reviews

Teams often generate a software bill of materials or a Semgrep report on every build and then never act on the results, which leaves the process unable to show that flaws in components were handled. OWASP Dependency-Track ingests CycloneDX SBOMs and flags components with known vulnerabilities, outdated or modified components and license risk. Assign an owner to triage its findings, record the disposition of each one, and keep the triage history as SA-15 evidence. Trivy can produce the SBOM and scan existing ones, which helps keep the input consistent.

What buyers ask about SA-15 cost, effort, timing and outside help

How much effort does SA-15 take for a small team compared with a large one?

Effort scales with how many developers, repositories, pipelines and third-party tools the process must cover, not with the control's wording. A small team with one or two repositories and a single deployment pipeline usually has a short list of documents to write and tools to configure. A large team has more roles, more toolchains and more change paths to document, review and keep under configuration control. The control requires a documented development process, control of the standards and tools in use, and periodic review against defined requirements, so the work grows with each of those items. Ask any provider to break the effort down by repository, pipeline and tool before accepting a figure.

Can we implement SA-15 in-house without an implementation partner?

Yes, in principle. The organization owns its controls, and nothing in SA-15 requires an outside firm. Teams that already run a documented SDLC, protected branches and dependency tracking have a head start. The gaps usually sit in written process, periodic review records and configuration control over tools, which take people who know both the development workflow and the assessment method. An implementation partner can prepare the systems and evidence, but it does not issue assessment results. Whether to bring in help depends on your internal skills, your timeline and how many systems fall under the assessment.

What does SA-15 need from our engineers and from a named process owner?

SA-15 needs engineering time for three things: writing the development process, configuring the tools it names, and running the periodic review. Engineers must agree which standards and tools are approved, record changes to them and keep configuration records that an assessor can examine. A named process owner should hold the document, schedule the review, approve tool changes and collect the review records. Without a single owner, reviews tend to lapse and tool changes happen without records. Confirm with your assessor which review records they expect, such as maturity model results, before you assign the work.

How long does SA-15 take, and what drives the timeline?

The timeline comes from the written scope agreed before work starts, not from a generic duration. The main drivers are the number of systems and development teams in scope, how many toolchains need configuration and evidence, whether a process document already exists, how quickly reviews and approvals can happen, and how much evidence must be collected from past periods. Ask for the phases, the deliverables in each phase, the dependencies on your team and the dates each depends on. Any timeline given without a written scope should be treated as an estimate to confirm.

What should we ask for in a quote for SA-15 work?

Ask for a quote built from a written scope that lists the systems, repositories, pipelines and tools covered, the documents to be produced or revised, and the evidence to be prepared. The quote should separate one-time work, such as writing the process and configuring tools, from recurring work, such as periodic review, tool updates and evidence collection. It should name who does each task, what you must supply, what is excluded and how changes to scope are priced. Confirm that the provider prepares evidence and does not issue assessment results, and ask who your independent assessor will be.

Can a partner make the assessor's job easier without taking over the assessment?

Yes. A partner can organize the development process document, arrange tool configuration records, set up review cadence and assemble the evidence an assessor will examine, such as configuration management records and documented development process reviews. The organization still owns the control and its results. The assessor examines the evidence and interviews staff and issues the assessment conclusions. A useful partner keeps the evidence traceable to each assessment objective and does not make determinations about whether the control is met.

How DeployOpen scopes, implements and prepares SA-15 evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, including the development pipeline, tool configuration and records that SA-15 asks you to show. We prepare the systems and evidence for your assessment, while your organization owns the development process and an independent assessor reaches the conclusions.

How we scope

Engagements are fixed-scope, with the systems, repositories and pipelines covered agreed in writing before work starts.
We inventory the development tools in use and confirm which ones your documented process must govern.
The written scope names the deliverables, owners and acceptance criteria for each SA-15 evidence item.

How we build

We configure self-hosted GitLab Community Edition protected branches to restrict who can push or merge, with force pushes disabled by default.
We set up Semgrep Community Edition in CI/CD pipelines to scan repositories with community or custom rules.
We deploy OWASP Dependency-Track to ingest CycloneDX SBOMs and track vulnerable, outdated and license-risk components.

How we hand over

We deliver a written development process document that addresses security requirements and maps to the tools in use.
We provide configuration records and change logs for each development tool, ready for your periodic review.
We document the review cycle for the process and tooling, so your assessor can examine the review records directly.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover periodic tool reviews, tool version upgrades and updates to pipeline configuration.
Confirm with your assessor which review evidence they expect before the assessment window opens.