PO.1.2—Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time.
PO.1
>Control Description
Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time.
>Practice: 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).
>Notional Implementation Examples
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 7.Establish and follow processes for handling requirement exception requests, including periodic reviews of all approved exceptions.
>Cross-Framework References
Mappings to related frameworks and standards from NIST SP 800-218
BSA FSS
SC.1-1
SC.2
PD.1-1
PD.1-2
PD.1-3
PD.2-2
SI
PA
+4 more
BSIMM
SM1.1
SM1.4
SM2.2
CP1.1
CP1.2
CP1.3
CP2.1
CP2.3
+9 more
EO 14028
4e(ix)
IEC 62443
SR-3
SR-4
SR-5
SD-4
ISO 27034
7.3.2
Microsoft SDL
2
5
NIST CSF
OWASP MASVS
1.12
OWASP SAMM
PC1-A
PC1-B
PC2-A
PC3-A
SR1-A
SR1-B
SR2-B
SA1-B
+1 more
PCI SSLC
2.1
2.2
2.3
3.3
SAFECode FPSSD
Establish Coding Standards and Conventions
SP 800-160
3.1.2
3.2.1
3.3.1
SP 800-161
SA-8
SA-15
SR-3
SP 800-181 (NICE)
T0414
K0003
K0039
K0044
K0157
K0168
K0177
K0211
+10 more
Ask AI
Configure your API key to use AI features.