SA-11(2) Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses
Require the developer of the system, system component, or system service to perform threat modeling and vulnerability analyses during development and the subsequent testing and evaluation of the system, component, or service that: (a) Uses the following contextual information: organization-defined information concerning impact, environment of operations, known or assumed threats, and acceptable risk levels; (b) Employs the following tools and methods: organization-defined tools and methods; (c) Conducts the modeling and analyses at the following level of rigor: organization-defined breadth and depth of modeling and analyses; and (d) Produces evidence that meets the following acceptance criteria: organization-defined acceptance criteria.
Source: NIST SP 800-53 Rev 5, SA-11(2). The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open NIST SP 800-53 Rev 5 in the compliance library.
Base controls and their enhancements. Which apply follows the baseline you are assessed against (for example FedRAMP Moderate or High, or the low, moderate and high baselines of SP 800-53B). Text in square brackets is a parameter your organisation sets.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
- Vulnerability scanning results · Vulnerability scanner / patch tooling
periodic reviewEvidence produced at each review
- Records of developer security testing results for the system, system component, or system service · Document repository
- Test of Organizational processes for monitoring developer security testing and evaluation; mechanisms supporting and/or implementing the monitoring of developer security testing and evaluation · SIEM / log platform
governing documentDocuments that govern the control
- System and services acquisition policy · Policy repository / GRC workspace
- Procedures addressing system developer security testing · Policy repository / GRC workspace
- Solicitation documentation · Document repository
- Acquisition documentation · Document repository
- Service level agreements · Vendor register / contract repository
- Acquisition contracts for the system, system component, or system service · Vendor register / contract repository
- System developer security test plans · Policy repository / GRC workspace
First move
Common gaps auditors find
- The developer performs no threat modeling or vulnerability analysis during development
- Threat models lack the defined contextual information, tools and acceptance criteria
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheetSA-11(1) Developer Testing and Evaluation | Static Code Analysis · SA-11(3) Developer Testing and Evaluation | Independent Verification of Assessment Plans and Evidence