SA-11(1), Static Code Analysis, is an enhancement to the SA-11 control in NIST SP 800-53 Revision 5. It asks that the developer of a system, component or service use static code analysis tools to identify common flaws and document the results. The catalog lists it as not part of any baseline.
Reading the control text carefully
The enhancement says to require the developer of the system, system component or system service to employ static code analysis tools to identify common flaws and document the results of the analysis.
Three phrases carry the meaning:
- "Require the developer" means the control is about whoever builds the software. If you buy software, you may be the one asking for it. If you build, you are the developer.
- "Common flaws" is deliberately broad. The control does not name a weakness list or a tool type.
- "Document the results" means output has to be kept, not only generated.
The baseline detail
The catalog entry states that SA-11(1) is not part of any baseline. In practice that means an organization does not get it automatically by selecting a baseline. It becomes relevant when an organization or a contract chooses to add it. Whether it applies to you is a question for the people who own your control selection.
How it relates to other guidance
NIST SP 800-218 (the Secure Software Development Framework) maps its code review and analysis practice, PW.7, to SA-11 in its references, which shows the two documents are meant to be read together. SA-11(1) gives the control language, and the SSDF gives example implementations.
What documentation can look like
A reasonable record for this enhancement has four parts:
- The tool name and version, plus the rule set or configuration used.
- The code version scanned, such as a commit hash or release tag.
- The findings, preferably in an exportable form.
- The disposition of each finding: fixed, accepted with a reason, or marked not applicable.
If you export results in a standard interchange format, you make later review easier. The OASIS SARIF standard defines a format for the output of static analysis tools, and it is a sensible thing to ask a vendor about.
What not to claim
Using a static analysis tool does not mean a system "complies with SA-11(1)" in any formal sense. Conformance is judged by an assessor against your selected controls. Describe what you do and what you keep, and leave the conclusion to the assessor.
A worked example: documenting results for one release
Imagine a team shipping version 4.2 of an internal billing service. They want the record to stand on its own six months later. Here is what the file for that release might contain.
The scan summary lists the tool name, tool version, rule set version and the date. It names the commit that was scanned, a short hash, and the repository. It lists the languages covered and the paths excluded, with a reason for each exclusion, for example a folder of generated files.
The results file is exported in a structured format and attached. A reviewer can open it without the original tool.
The triage log has one line per finding that needed a decision. Each line has the weakness type, the file and line, the decision (fixed, accepted, false positive), the person who decided, and the date. Accepted findings have a reason and a review date.
That is the whole package. It is small, and it makes the phrase "document the results of the analysis" concrete.
Common gaps in documentation
| Gap | Why it hurts | Simple fix |
|---|---|---|
| Results kept only inside the tool | Lost if you change tools | Export on every release |
| No commit reference | Cannot tell what was scanned | Store the commit hash with the export |
| Exclusions undocumented | Looks like coverage you do not have | List exclusions and reasons |
| Decisions in chat messages | Hard to find later | Record in the tracker |
| No version of the rule set | Cannot reproduce | Record versions in the summary |
What "common flaws" can mean in practice
The control does not define a list. Many teams make it concrete by pointing to a public list of weaknesses, such as the MITRE CWE Top 25, and stating that their analysis rules cover the weakness types on it that apply to their languages. That gives the phrase meaning without claiming completeness. Be careful to say "rules cover" and not "finds all", because tools have false negatives, and OWASP notes that they can miss flaws.
Who is the developer in your situation
The control is addressed to the developer of a system, component or service. For a company that builds its own software, that is you. For a company that buys or outsources software, it can be the supplier, and your role is to ask for the documentation. In a contract, you can request that the supplier provide scan summaries and triage records for each delivery. If you rely on open source components, the developer in the control sense is a community, so dependency scanning and your own review take the place of direct documentation.
How this fits with other practices
Static analysis is one part of a developer testing and evaluation family of activities. SA-11 itself covers more, including other kinds of testing. If you are documenting your approach, show the static analysis enhancement as one line item, and show the others next to it, so the picture is balanced. An assessor reading only a static analysis report may reasonably ask what else you do.
Keep the claim modest
The safest wording is factual: "We run static code analysis on these repositories, with the following scope, and retain the results and triage decisions." Leave judgments about conformance to your assessor. That wording stays true even when your coverage changes, as long as you update the scope list.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one control maps to evidence in more than one framework.
Quick check
Does SA-11(1) name a specific tool or product?
No. It asks for static code analysis tools in general and for documented results.
Is SA-11(1) part of the low, moderate or high baseline?
The catalog entry lists it as not part of any baseline, so it applies only if selected. Check with your control owner.
Is a SAST report enough documentation?
It is a start. Add the code version scanned, the configuration, and what was decided about each finding.
Safeguard offers compliance and evidence automation, plus SBOM and dependency scanning. You can try the free scan at gold.safeguard.sh/scan.
Sources
- NIST SP 800-53 Rev. 5, SA-11 and enhancements (control catalog reference)
- NIST SP 800-218, Secure Software Development Framework version 1.1
- OASIS, SARIF version 2.1.0
Last reviewed: 19 October 2026.
