NIST SP 800-218
Produce Well Secured Software

NIST SP 800-218 SP800-218-PW.1.1: Design Software to Meet Security Requirements

Design software so that it meets security requirements and mitigates known risks from the start. Use threat modelling to identify how an attacker could abuse the system and feed mitigations back into the design.

Maintained by Gerard BlokdykVerified against the published standard Control text last updated

What else in your programme already covers this

This control maps to 49 controls across 22 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.

NIST SP 800-161 Rev 1 · 5 controls

BSIMM · 4 controls

  • AA1.4 Use a risk-ranking methodology for applications
  • AA2.1 Perform architecture analysis using STRIDE or equivalent
  • AM1.3 Identify potential attackers
  • SFD1.2 Engage architecture teams with security

NIST SP 800-53 Rev 5 · 4 controls

C5 (Germany) · 3 controls

  • C5-DEV-01 Policies for the development/procurement of information systems
  • C5-DEV-05 Risk assessment, categorisation and prioritisation of changes
  • C5-OIS-07 Application of the Risk Management Policy

FedRAMP High · 3 controls

  • RA-3 Risk Assessment
  • SA-11(2) Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses (SA-11(2))
  • SA-8 Security and Privacy Engineering Principles

FedRAMP Moderate · 3 controls

  • RA-3 Risk Assessment
  • SA-11(2) Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses (SA-11(2))
  • SA-8 Security and Privacy Engineering Principles

SOC 2 · 3 controls

  • SOC2-CC3.2 CC3.2 Identifying and analysing risks to objectives (COSO principle 7)
  • SOC2-CC8.1 CC8.1 Managing changes to procedures, software, data and infrastructure
  • SOC2-PI1.3 PI1.3 Controls over system processing

CIS Controls v8 · 2 controls

  • CIS-16.10 Apply Secure Design Principles in Application Architectures
  • CIS-16.14 Conduct Threat Modeling
  • CCM-AIS-04 Secure Application Design and Development
  • CCM-DSP-07 Data Protection by Design and Default

ISO 27001:2022 · 2 controls

  • 8.26 Application security requirements
  • 8.27 Secure system architecture and engineering principles

ISO 27002:2022 · 2 controls

  • 8.26 Application security requirements
  • 8.27 Secure system architecture and engineering principles

ISO/IEC 42001:2023 · 2 controls

  • NIST-CSF-ID.RA-03 Internal and external threats to the organization are identified and recorded
  • NIST-CSF-PR.PS-06 Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle

NIST SP 800-171 Rev 3 · 2 controls

NIST SP 800-172 · 2 controls

  • 3.11.1e Threat-Aware Risk Assessment
  • 3.13.2e Introduce Unpredictability into System Operations
  • OSPS-SA-03.01 OSPS-SA-03.01 Maintain a Project Security Assessment
  • OSPS-SA-03.02 OSPS-SA-03.02 Maintain a Project Security Assessment
  • SEC01-BP07 Identify threats and prioritize mitigations using a threat model

CMMC 2.0 · 1 control

PCI DSS 4.0 · 1 control

  • 6.2.1 6.2.1 Secure development of bespoke and custom software

Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.

Other controls in Produce Well Secured Software

You are reading one control. How much of NIST SP 800-218 have you already done?

NIST SP 800-218 SP800-218-PW.1.1 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of NIST SP 800-218 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 30 of 42 NIST SP 800-218 controls already carry evidence.

Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 0 were rejected on the NIST SP 800-53 Rev 5 pair alone.

Query this from an agent

The graph holds this control, the 49 it maps to, and the evidence behind each claim, over MCP and REST.