Skip to content

PO.1: Define Security Requirements for Software Development

Ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of effort can be minimized because the requirements information can be collected once and shared. This includes requirements from internal sources (e.g., the organization’s policies, business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations).

PO.1.1

Identify and document all security requirements for the organization’s software development infrastructures and processes, and maintain the requirements over time.

Implementation Examples
  • Example 1: Define policies for securing software development infrastructures and their components, including development endpoints, throughout the SDLC and maintaining that security.
  • Example 2: Define policies for securing software development processes throughout the SDLC and maintaining that security, including for open-source and other third-party software components utilized by software being developed.
  • Example 3: Review and update security requirements at least annually, or sooner if there are new requirements from internal or external sources, or a major security incident targeting software development infrastructure has occurred.
  • Example 4: Educate affected individuals on impending changes to requirements.
References
  • BSAFSS: SM.3, DE.1, IA.1, IA.2
  • BSIMM: CP1.1, CP1.3, SR1.1, SR2.2, SE1.2, SE2.6
  • EO14028: 4e(ix)
  • IEC62443: SM-7, SM-9
  • NISTCSF: ID.GV-3
  • OWASPASVS: 1.1.1
  • OWASPMASVS: 1.10
  • OWASPSAMM: PC1-A, PC1-B, PC2-A
  • PCISSLC: 2.1, 2.2
  • SCFPSSD: Planning the Implementation and Deployment of Secure Development Practices
  • SP80053: SA-1, SA-8, SA-15, SR-3
  • SP800160: 3.1.2, 3.2.1, 3.2.2, 3.3.1, 3.4.2, 3.4.3
  • SP800161: SA-1, SA-8, SA-15, SR-3
  • SP800181: T0414; K0003, K0039, K0044, K0157, K0168, K0177, K0211, K0260, K0261, K0262, K0524; S0010, S0357, S0368; A0033, A0123, A0151

PO.1.2

Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time.

Implementation Examples
  • Example 1: Define policies that specify risk-based software architecture and design requirements, such as making code modular to facilitate code reuse and updates; isolating security components from other components during execution; avoiding undocumented commands and settings; and providing features that will aid software acquirers with the secure deployment, operation, and maintenance of the software.
  • Example 2: Define policies that specify the security requirements for the organization’s software, and verify compliance at key points in the SDLC (e.g., classes of software flaws verified by gates, responses to vulnerabilities discovered in released software).
  • Example 3: Analyze the risk of applicable technology stacks (e.g., languages, environments, deployment models), and recommend or require the use of stacks that will reduce risk compared to others.
  • Example 4: Define policies that specify what needs to be archived for each software release (e.g., code, package files, third-party libraries, documentation, data inventory) and how long it needs to be retained based on the SDLC model, software end-of-life, and other factors.
  • Example 5: Ensure that policies cover the entire software life cycle, including notifying users of the impending end of software support and the date of software end-of-life.
  • Example 6: Review all security requirements at least annually, or sooner if there are new requirements from internal or external sources, a major vulnerability is discovered in released software, or a major security incident targeting organization-developed software has occurred.
  • Example 7: Establish and follow processes for handling requirement exception requests, including periodic reviews of all approved exceptions.
References
  • BSAFSS: SC.1-1, SC.2, PD.1-1, PD.1-2, PD.1-3, PD.2-2, SI, PA, CS, AA, LO, EE
  • BSIMM: SM1.1, SM1.4, SM2.2, CP1.1, CP1.2, CP1.3, CP2.1, CP2.3, AM1.2, SFD1.1, SFD2.1, SFD3.2, SR1.1, SR1.3, SR2.2, SR3.3, SR3.4
  • EO14028: 4e(ix)
  • IEC62443: SR-3, SR-4, SR-5, SD-4
  • ISO27034: 7.3.2
  • MSSDL: 2, 5
  • NISTCSF: ID.GV-3
  • OWASPMASVS: 1.12
  • OWASPSAMM: PC1-A, PC1-B, PC2-A, PC3-A, SR1-A, SR1-B, SR2-B, SA1-B, IR1-A
  • PCISSLC: 2.1, 2.2, 2.3, 3.3
  • SCFPSSD: Establish Coding Standards and Conventions
  • SP80053: SA-8, SA-8(3), SA-15, SR-3
  • SP800160: 3.1.2, 3.2.1, 3.3.1
  • SP800161: SA-8, SA-15, SR-3
  • SP800181: T0414; K0003, K0039, K0044, K0157, K0168, K0177, K0211, K0260, K0261, K0262, K0524; S0010, S0357, S0368; A0033, A0123, A0151

PO.1.3

Communicate requirements to all third parties who will provide commercial software components to the organization for reuse by the organization’s own software. [Formerly PW.3.1]

Implementation Examples
  • Example 1: Define a core set of security requirements for software components, and include it in acquisition documents, software contracts, and other agreements with third parties.
  • Example 2: Define security-related criteria for selecting software; the criteria can include the third party’s vulnerability disclosure program and product security incident response capabilities or the third party’s adherence to organization-defined practices.
  • Example 3: Require third parties to attest that their software complies with the organization’s security requirements.
  • Example 4: Require third parties to provide provenance data and integrity verification mechanisms for all components of their software.
  • Example 5: Establish and follow processes to address risk when there are security requirements that third-party software components to be acquired do not meet; this should include periodic reviews of all approved exceptions to requirements.
References
  • BSAFSS: SM.1, SM.2, SM.2-1, SM.2-4
  • BSIMM: CP2.4, CP3.2, SR2.5, SR3.2
  • EO14028: 4e(vi), 4e(ix)
  • IDASOAR: 19, 21
  • IEC62443: SM-9, SM-10
  • MSSDL: 7
  • NISTCSF: ID.SC-3
  • OWASPSAMM: SR3-A
  • SCAGILE: Tasks Requiring the Help of Security Experts 8
  • SCFPSSD: Manage Security Risk Inherent in the Use of Third-Party Components
  • SCSIC: Vendor Sourcing Integrity Controls
  • SP80053: SA-4, SA-9, SA-10, SA-10(1), SA-15, SR-3, SR-4, SR-5
  • SP800160: 3.1.1, 3.1.2
  • SP800161: SA-4, SA-9, SA-9(1), SA-9(3), SA-10, SA-10(1), SA-15, SR-3, SR-4, SR-5
  • SP800181: T0203, T0415; K0039; S0374; A0056, A0161