SA-15, Development Process, Standards, and Tools, asks the organization to require the developer to follow a documented development process. That process must explicitly address security and privacy requirements, identify the standards and tools used, document the specific tool options and configurations, and document, manage and ensure the integrity of changes to the process and tools. The organization must also review the process, standards, tools, options and configurations to decide whether they can satisfy the security and privacy requirements it names.
800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference, and a close match for the "describe your secure development practices" section of a customer questionnaire.
What it means in practice
Two layers are in play. The developer documents how they build. Then the organization reviews whether that way of building is good enough.
The guidance defines development tools broadly: programming languages and computer aided design systems. It says reviews of the process can use maturity models to judge likely effectiveness. And it makes a point that is easy to miss: maintaining the integrity of changes to tools and processes supports supply chain risk assessment. That requires configuration control across the life cycle, to track authorized changes and block unauthorized ones.
In a modern team the build system is a tool whose configuration matters. If anyone can edit the pipeline file without review, the documented process is only a suggestion.
The enhancements cover the options: SA-15.1 Quality Metrics, SA-15.2 Security and Privacy Tracking Tools, SA-15.3 Criticality Analysis, SA-15.4 Threat Modeling and Vulnerability Analysis, SA-15.5 Attack Surface Reduction, SA-15.6 Continuous Improvement, SA-15.7 Automated Vulnerability Analysis and SA-15.8 Reuse of Threat and Vulnerability Information.
Evidence to collect
- A written development process that names where security requirements enter.
- A tool inventory: languages, compilers, build systems, scanners, repositories, with versions.
- Exported configuration for each security relevant tool, such as pipeline definitions and scanner settings.
- Change history for the pipeline and tool configuration, with reviewers.
- The organization's review record that judged the process adequate.
- Any metrics you track, such as defects found per release.
Common gaps
A process document with no tool detail. Saying you run static analysis is weaker than showing which rules are on.
Pipeline configuration editable without review.
A one time review. Tools and processes change, and the review should repeat.
Security tooling in a few repositories while the rest build with no checks.
How to implement it
- Write the process as stages, and mark where security requirements and checks appear.
- Inventory the tools and export their configuration into version control.
- Protect pipeline and tool configuration with required review and branch protection.
- Hold a yearly review that asks whether the process meets the requirements you set, and record the answer.
- Use gates that stop a release when agreed checks fail. The demo shows how a production gate works.
- Track a small number of quality metrics and act on trends.
Click through it at your own pace, or open it full screen.
Try it yourself
Dependencies are part of your tool chain. The free in browser scan at gold.safeguard.sh/scan shows the known vulnerabilities in a manifest, and you can use the result as a first input to the SA-15.7 conversation.
Quick check
Why does the control care about changes to tools?
Integrity of tool and process changes supports supply chain risk assessment and requires configuration control to track authorized changes and prevent unauthorized ones.
Is a maturity model required?
No. The guidance says reviews of development processes include the use of maturity models as a way to judge effectiveness.
