TDA-02.3: Development Methods, Techniques & Processes
Mechanisms exist to require software developers to ensure that their software development processes employ industry-recognized secure practices for secure programming, engineering methods, quality control processes and validation techniques to minimize flawed and/or malformed software.
Control Question: Does the organization require software developers to ensure that their software development processes employ industry-recognized secure practices for secure programming, engineering methods, quality control processes and validation techniques to minimize flawed and/or malformed software?
General (27)
| Framework | Mapping Values |
|---|---|
| CIS CSC 8.1 | 16.1 |
| CIS CSC 8.1 IG2 | 16.1 |
| CIS CSC 8.1 IG3 | 16.1 |
| CSA IoT SCF 2 | SDV-07 |
| ISO 27002 2022 | 8.25 8.29 |
| ISO 27017 2015 | 14.2.9 |
| ISO 42001 2023 | A.6.1.3 A.6.2.3 |
| NIST AI 100-1 (AI RMF) 1.0 | GOVERN 4.1 GOVERN 4.2 |
| NIST Privacy Framework 1.0 | CT.DM-P9 CT.DM-P10 |
| NIST 800-53 R4 | SA-4(3) |
| NIST 800-53 R5 (source) | SA-4(3) SR-3(1) |
| NIST 800-53 R5 (NOC) (source) | SA-4(3) SR-3(1) |
| NIST 800-161 R1 | SR-3(1) |
| NIST 800-161 R1 Level 2 | SR-3(1) |
| NIST 800-161 R1 Level 3 | SR-3(1) |
| NIST 800-171 R3 (source) | 03.16.01 |
| NIST 800-171A R3 (source) | A.03.16.01.ODP[01] A.03.16.01 |
| NIST 800-218 | PO.1 PO.3 PO.3.1 PO.3.2 PO.3.3 PO.4.2 PW.2 PW.5 PW.6.1 RV.1 RV.2 |
| OWASP Top 10 2021 | A04:2021 |
| PCI DSS 4.0.1 (source) | 6.2 6.2.1 |
| PCI DSS 4.0.1 SAQ A-EP (source) | 6.2.1 |
| PCI DSS 4.0.1 SAQ C (source) | 6.2.1 |
| PCI DSS 4.0.1 SAQ D Merchant (source) | 6.2.1 |
| PCI DSS 4.0.1 SAQ D Service Provider (source) | 6.2.1 |
| SCF CORE ESP Level 2 Critical Infrastructure | TDA-02.3 |
| SCF CORE ESP Level 3 Advanced Threats | TDA-02.3 |
| SCF CORE AI Model Deployment | TDA-02.3 |
US (5)
| Framework | Mapping Values |
|---|---|
| US C2M2 2.1 | ARCHITECTURE-4.B.MIL2 ARCHITECTURE-4.E.MIL3 |
| US DHS CISA SSDAF | 2 |
| US DHS ZTCF | DEV-03 |
| US EO 14028 | 4e(iii) |
| US - CA CCPA 2025 | 7123(c)(14) |
EMEA (3)
| Framework | Mapping Values |
|---|---|
| EMEA EU AI Act | 14.1 |
| EMEA EU EBA GL/2019/04 | 3.6.2(69) 3.6.2(74) |
| EMEA Spain CCN-STIC 825 | 8.6.1 [MP.SW.1] |
APAC (2)
| Framework | Mapping Values |
|---|---|
| APAC Japan ISMAP | 14.2.9 |
| APAC Singapore MAS TRM 2021 | 6.1.4 6.1.5 6.1.6 6.1.7 |
Americas (2)
| Framework | Mapping Values |
|---|---|
| Americas Canada OSFI B-13 | 2.4.3 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 require software developers to ensure that their software development processes employ industry-recognized secure practices for secure programming, engineering methods, quality control processes and validation techniques to minimize flawed and/or malformed software.
Level 1 — Performed Informally
C|P-CMM1 is N/A, since a structured process is required to require software developers to ensure that their software development processes employ industry-recognized secure practices for secure programming, engineering methods, quality control processes and validation techniques to minimize flawed and/or malformed software.
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
See C|P-CMM3. There are no defined C|P-CMM4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to require software developers to ensure that their software development processes employ industry-recognized secure practices for secure programming, engineering methods, quality control processes and validation techniques to minimize flawed and/or malformed software.
Level 5 — Continuously Improving
See C|P-CMM4. There are no defined C|P-CMM5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to require software developers to ensure that their software development processes employ industry-recognized secure practices for secure programming, engineering methods, quality control processes and validation techniques to minimize flawed and/or malformed software.
Assessment Objectives
- TDA-02.3_A01 cybersecurity / data privacy systems engineering methods are defined.
- TDA-02.3_A02 software development methods are defined.
- TDA-02.3_A03 testing, evaluation, assessment, verification and validation methods are defined.
- TDA-02.3_A04 quality control processes are defined.
- TDA-02.3_A05 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.
- TDA-02.3_A06 systems security engineering principles to be applied to the development or modification of the system and system components are defined.
- TDA-02.3_A07 <A.03.16.01.ODP[01]: systems security engineering principles> are applied to the development or modification of the system and system components.
Evidence Requirements
- E-TDA-04 Design and Development Plan (DDP)
-
Documented evidence of an engineering method to control the design process and govern the lifecycle of the product/service.
Technology Design & Acquisition
Technology Recommendations
Micro/Small
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
- Product / project management
Small
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
- Product / project management
Medium
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
- Product / project management
Large
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
- Defined business processes
- Product / project management
- Defined technical requirements
- Defined business requirements
- System Development Lifecycle (SDLC) governance / oversight
Enterprise
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
- Defined business processes
- Product / project management
- Defined technical requirements
- Defined business requirements
- System Development Lifecycle (SDLC) governance / oversight