TDA-06: Secure Software Development Practices (SSDP)
Mechanisms exist to develop applications based on Secure Software Development Practices (SSDP).
Control Question: Does the organization develop applications based on Secure Software Development Practices (SSDP)?
General (56)
| Framework | Mapping Values |
|---|---|
| AICPA TSC 2017:2022 (used for SOC 2) (source) | PI1.1 PI1.2 PI1.2-POF1 PI1.2-POF2 PI1.2-POF3 PI1.3 PI1.3-POF1 PI1.3-POF2 PI1.3-POF3 PI1.3-POF4 PI1.3-POF5 PI1.4 PI1.4-POF1 PI1.4-POF2 PI1.4-POF3 PI1.4-POF4 PI1.5 PI1.5-POF1 PI1.5-POF2 PI1.5-POF3 PI1.5-POF4 |
| CIS CSC 8.1 | 16 16.1 16.5 16.10 16.11 |
| CIS CSC 8.1 IG2 | 16.1 16.5 16.10 16.11 |
| CIS CSC 8.1 IG3 | 16.1 16.5 16.10 16.11 |
| COBIT 2019 | APO03.02 |
| CSA CCM 4 | AIS-04 |
| CSA IoT SCF 2 | SDV-05 |
| GovRAMP Low | SA-01 |
| GovRAMP Low+ | SA-01 |
| GovRAMP Moderate | SA-01 |
| GovRAMP High | SA-01 SA-15 |
| IEC 62443-4-2 2019 | CCSC 4 (4.5) |
| ISO/SAE 21434 2021 | RQ-10-01.a RQ-10-01.b RQ-10-01.c RQ-10-02 RQ-10-03 RQ-10-04.a RQ-10-04.b RQ-10-04.c RQ-10-04.d RQ-10-04.e RQ-10-04.f RQ-10-05 RQ-10-06 RQ-10-07 RQ-10-08 RQ-10-09 |
| ISO 27002 2022 | 8.25 8.26 8.27 8.28 8.30 |
| ISO 27017 2015 | 14.2.1 14.2.5 |
| ISO 42001 2023 | A.6.1.3 A.6.2.3 |
| MITRE ATT&CK 10 | T1078, T1078.001, T1078.003, T1078.004, T1213.003, T1528, T1552, T1552.001, T1552.002, T1552.004, T1552.006, T1558.004, T1574.002 |
| MPA Content Security Program 5.1 | TS-1.12 TS-1.13 |
| NAIC Insurance Data Security Model Law (MDL-668) | 4.D(2)(e) |
| NIST Privacy Framework 1.0 | CT.PO-P1 CT.DM-P7 CT.DM-P8 CT.DM-P9 CT.DM-P10 |
| NIST 800-53 R4 | SA-1 SA-15 |
| NIST 800-53 R4 (low) | SA-1 |
| NIST 800-53 R4 (moderate) | SA-1 |
| NIST 800-53 R4 (high) | SA-1 SA-15 |
| NIST 800-53 R5 (source) | SA-1 SA-4(3) SA-15 |
| NIST 800-53B R5 (privacy) (source) | SA-1 |
| NIST 800-53B R5 (low) (source) | SA-1 |
| NIST 800-53B R5 (moderate) (source) | SA-1 SA-15 |
| NIST 800-53B R5 (high) (source) | SA-1 SA-15 |
| NIST 800-53 R5 (NOC) (source) | SA-4(3) |
| NIST 800-82 R3 LOW OT Overlay | SA-1 |
| NIST 800-82 R3 MODERATE OT Overlay | SA-1 SA-15 |
| NIST 800-82 R3 HIGH OT Overlay | SA-1 SA-15 |
| NIST 800-161 R1 | SA-1 SA-15 |
| NIST 800-161 R1 C-SCRM Baseline | SA-1 |
| NIST 800-161 R1 Level 1 | SA-1 |
| NIST 800-161 R1 Level 2 | SA-1 SA-15 |
| NIST 800-161 R1 Level 3 | SA-1 SA-15 |
| NIST 800-171 R2 (source) | NFO-SA-1 |
| NIST 800-171A (source) | 3.13.2[b] 3.13.2[e] |
| NIST 800-171 R3 (source) | 03.16.01 |
| NIST 800-218 | PO.1 PW.1 PW.1.3 PW.4.2 PW.5 PW.5.1 PW.6.1 PW.6.2 RV.3.4 |
| NIST CSF 2.0 (source) | PR.PS-06 |
| OWASP Top 10 2021 | A01:2021 A02:2021 A03:2021 A04:2021 A05:2021 A06:2021 A07:2021 A08:2021 A09:2021 A10:2021 |
| PCI DSS 4.0.1 (source) | 6.2 6.2.1 6.2.4 |
| PCI DSS 4.0.1 SAQ A-EP (source) | 6.2.1 6.2.4 |
| PCI DSS 4.0.1 SAQ C (source) | 6.2.1 6.2.4 |
| PCI DSS 4.0.1 SAQ D Merchant (source) | 6.2.1 6.2.4 |
| PCI DSS 4.0.1 SAQ D Service Provider (source) | 6.2.1 6.2.4 |
| SPARTA | CM0017 CM0043 |
| SWIFT CSF 2023 | 2.10 |
| UL 2900-1 2017 | 4.1 5.1 |
| SCF CORE Mergers, Acquisitions & Divestitures (MA&D) | TDA-06 |
| SCF CORE ESP Level 1 Foundational | TDA-06 |
| SCF CORE ESP Level 2 Critical Infrastructure | TDA-06 |
| SCF CORE ESP Level 3 Advanced Threats | TDA-06 |
US (23)
| Framework | Mapping Values |
|---|---|
| US CERT RMM 1.2 | CTRL:SG2.SP1 IMC:SG1.SP1 MA:SG1.SP2 MA:SG2.SP4 RTSE:SG1.SP1 |
| US CMS MARS-E 2.0 | SA-1 |
| US DoD Zero Trust Execution Roadmap | 3.2 3.2.4 |
| US DHS CISA SSDAF | 1.e |
| US DHS ZTCF | DEV-03 |
| US EO 14028 | 4e(i)(E) |
| US FedRAMP R4 | SA-1 SA-15 |
| US FedRAMP R4 (low) | SA-1 |
| US FedRAMP R4 (moderate) | SA-1 |
| US FedRAMP R4 (high) | SA-1 SA-15 |
| US FedRAMP R4 (LI-SaaS) | SA-1 |
| US FedRAMP R5 (source) | SA-1 SA-15 |
| US FedRAMP R5 (low) (source) | SA-1 |
| US FedRAMP R5 (moderate) (source) | SA-1 SA-15 |
| US FedRAMP R5 (high) (source) | SA-1 SA-15 |
| US FedRAMP R5 (LI-SaaS) (source) | SA-1 |
| US GLBA CFR 314 2023 (source) | 314.4(c)(4) |
| US IRS 1075 | SA-1 SA-15 |
| US - CA CCPA 2025 | 7123(c)(14) |
| US - NY DFS 23 NYCRR500 2023 Amd 2 | 500.8(a) |
| US - TX DIR Control Standards 2.0 | SA-1 |
| US - TX TX-RAMP Level 1 | SA-1 |
| US - TX TX-RAMP Level 2 | SA-1 |
EMEA (10)
| Framework | Mapping Values |
|---|---|
| EMEA EU EBA GL/2019/04 | 3.6.2(69) |
| EMEA EU NIS2 | 21.3 |
| EMEA Germany Banking Supervisory Requirements for IT (BAIT) | 7.6 7.7 7.8 7.9 7.10 |
| EMEA Germany C5 2020 | DEV-02 DEV-07 DEV-08 |
| EMEA Israel CDMO 1.0 | 11.9 17.6 17.9 17.20 17.25 |
| EMEA Saudi Arabia CSCC-1 2019 | 1-3-2-3 2-13-1 2-13-2 2-13-3-1 2-13-3-2 2-13-3-3 2-13-3-4 |
| EMEA Saudi Arabia IoT CGIoT-1 2024 | 2-14-3 |
| EMEA Saudi Arabia ECC-1 2018 | 1-6-3-1 |
| EMEA Saudi Arabia SACS-002 | TPC-60 TPC-62 |
| EMEA UK CAF 4.0 | A4.b |
APAC (6)
| Framework | Mapping Values |
|---|---|
| APAC Australia ISM June 2024 | ISM-0401 ISM-1239 ISM-1419 ISM-1552 |
| APAC Japan ISMAP | 14.2.1 14.2.1.13.PB 14.2.5 |
| APAC New Zealand HISF 2022 | HHSP50 HML50 HSUP42 |
| APAC New Zealand HISF Suppliers 2023 | HSUP42 |
| APAC New Zealand NZISM 3.6 | 14.4.5.C.01 |
| APAC Singapore MAS TRM 2021 | 5.3.2 6.1.1 6.1.2 6.2.1 6.2.2 6.3.1 6.3.2 6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.4.6 6.4.7 6.4.8 6.5.1 6.5.2 6.5.3 |
Americas (4)
| Framework | Mapping Values |
|---|---|
| Americas Bermuda BMACCC | 6.20 |
| Americas Canada CSAG | 4.8 4.9 |
| Americas Canada OSFI B-13 | 2.4.5 |
| Americas Canada ITSP-10-171 | 03.16.01 |
Capability Maturity Model
Level 0 — Not Performed
There is no evidence of a capability to develop applications based on Secure Software Development Practices (SSDP).
Level 1 — Performed Informally
C|P-CMM1 is N/A, since a structured process is required to develop applications based on secure coding principles.
Level 2 — Planned & Tracked
Technology Development & Acquisition (TDA) efforts are requirements-driven and governed at a local/regional level, but are not consistent across the organization. CMM Level 2 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- Development and acquisition management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
- IT/cybersecurity personnel identify cybersecurity and data protection controls to address applicable statutory, regulatory and contractual requirements for technology development and acquisition management.
- IT/cybersecurity personnel implement secure practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets, data and network(s).
- Secure development practices mostly conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).
- Procurement practices require third-party developers of systems, system components or services to follow secure engineering practices.
- A Project Management Office (PMO), or project management function, enables the implementation of cybersecurity and data privacy-related resource planning controls across the System Development Lifecycle (SDLC) for all high-value projects.
Level 3 — Well Defined
Technology Development & Acquisition (TDA) efforts are standardized across the organization and centrally managed, where technically feasible, to ensure consistency. CMM Level 3 control maturity would reasonably expect all, or at least most, the following criteria to exist: o Provides governance oversight for the implementation of applicable statutory, regulatory and contractual cybersecurity and data protection controls to protect the confidentiality, integrity, availability and safety of the organization's applications, systems, services and data for technology development and acquisition. o Ensures the Information Assurance Program (IAP) evaluates applicable cybersecurity and data protection controls as part of “business as usual” pre-production testing. o Operates the Cybersecurity Supply Chain Risk Management (C-SCRM) program to identify and mitigate supply chain-related risks and threats.
- Secure development practices conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).
- A procurement team, or similar function, ensures that third party development and/ or acquisitions meet, or exceed, the organization's business, cybersecurity and data privacy requirements to have secure and resilient systems, applications, services and processes.
- A Software Assurance Maturity Model (SAMM) governs a secure development lifecycle for the development of systems, applications and services.
- Administrative processes exist and technologies are configured to implement secure configuration settings by default to reduce the likelihood of software being deployed with weak security settings, putting the asset at a greater risk of compromise.
- An IT Asset Management (ITAM) function, or similar function, categorizes devices according to the data the asset stores, transmits and/ or processes and applies the appropriate technology controls to protect the asset and data.
- A formal Change Management (CM) program help to ensure that no unauthorized changes are made, all changes are documented, services are not disrupted and resources are used efficiently.
- A Governance, Risk & Compliance (GRC) function, or similar function;
- A Project Management Office (PMO), or project management function, enables IAP pre-production testing of cybersecurity and data protection controls as part of the organization's established project management processes.
Level 4 — Quantitatively Controlled
Technology Development & Acquisition (TDA) efforts are metrics driven and provide sufficient management insight (based on a quantitative understanding of process capabilities) to predict optimal performance, ensure continued operations and identify areas for improvement. In addition to CMM Level 3 criteria, CMM Level 4 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
- Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
- Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
- Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
- Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
- Both business and technical stakeholders are involved in reviewing and approving proposed changes.
Level 5 — Continuously Improving
Technology Development & Acquisition (TDA) efforts are “world-class” capabilities that leverage predictive analysis (e.g., machine learning, AI, etc.). In addition to CMM Level 4 criteria, CMM Level 5 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions.
- Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.
Assessment Objectives
- TDA-06_A01 software development techniques that promote effective cybersecurity / data privacy are identified.
- TDA-06_A02 testing, evaluation, assessment, verification and validation methods are defined.
- TDA-06_A03 cybersecurity / data privacy requirements to be satisfied by the process, standards, tools, tool options and tool configurations are defined.
- TDA-06_A04 identified software development techniques that promote effective cybersecurity / data privacy are employed.
- TDA-06_A05 quality control processes are defined.
- TDA-06_A06 frequency at which to review the development process, standards, tools, tool options and tool configurations is defined.
- TDA-06_A07 the developer of the system, system component or system service is required to follow a documented development process that explicitly addresses security requirements.
- TDA-06_A08 the developer of the system, system component or system service is required to follow a documented development process that explicitly addresses privacy requirements.
- TDA-06_A09 the developer of the system, system component or system service is required to follow a documented development process that identifies the standards used in the development process.
- TDA-06_A10 the developer of the system, system component or system service is required to follow a documented development process that identifies the tools used in the development process.
- TDA-06_A11 the developer of the system, system component or system service is required to follow a documented development process that documents the specific tool used in the development process.
- TDA-06_A12 the developer of the system, system component or system service is required to follow a documented development process that documents the specific tool configurations used in the development process.
- TDA-06_A13 the developer of the system, system component or system service is required to follow a documented development process that documents, manages and ensures the integrity of changes to the process and/or tools used in development.
- TDA-06_A14 the developer of the system, system component or system service is required to follow a documented development process in which the development process, standards, tools, tool options and tool configurations are reviewed frequently to determine that the process, standards, tools, tool options and tool configurations selected and employed satisfy security requirements.
- TDA-06_A15 the developer of the system, system component or system service is required to follow a documented development process in which the development process, standards, tools, tool options and tool configurations are reviewed frequently to determine that the process, standards, tools, tool options and tool configurations selected and employed satisfy privacy requirements.
- TDA-06_A16 the developer of the system, system component or system service is required to demonstrate the use of a system development life cycle process that includes organization-defined system security engineering methods.
Evidence Requirements
- E-TDA-08 Secure Engineering Principles (SEP)
-
Documented evidence of defined secure engineering principles used to ensure Sensitivity, Integrity, Availability & Safety (CIAS) concerns are properly addressed in the design and implementation of systems, applications and services.
Technology Design & Acquisition - E-TDA-11 Software Assurance Maturity Model (SAMM)
-
Documented evidence of a Software Assurance Maturity Model (SAMM).
Technology Design & Acquisition
Technology Recommendations
Micro/Small
- Microsoft Security Development Lifecycle (SDL) practices
- OWASP's Application Security Verification Standard (ASVS)
- Mobile Application Security Verification Standard (MASVS)
Small
- Microsoft Security Development Lifecycle (SDL) practices
- OWASP's Application Security Verification Standard (ASVS)
- Mobile Application Security Verification Standard (MASVS)
Medium
- Microsoft Security Development Lifecycle (SDL) practices
- OWASP's Application Security Verification Standard (ASVS)
- Mobile Application Security Verification Standard (MASVS)
Large
- Microsoft Security Development Lifecycle (SDL) practices
- OWASP's Application Security Verification Standard (ASVS)
- Mobile Application Security Verification Standard (MASVS)
Enterprise
- Microsoft Security Development Lifecycle (SDL) practices
- OWASP's Application Security Verification Standard (ASVS)
- Mobile Application Security Verification Standard (MASVS)