Skip to main content

TDA-15: Developer Threat Analysis & Flaw Remediation

TDA 9 — Critical Protect

Mechanisms exist to require system developers and integrators to develop and implement an ongoing Security Testing and Evaluation (ST&E) plan, or similar process, to objectively identify and remediate vulnerabilities prior to release to production.

Control Question: Does the organization require system developers and integrators to create a Security Testing and Evaluation (ST&E) plan and implement the plan under the witness of an independent party?

General (23)
Framework Mapping Values
AICPA TSC 2017:2022 (used for SOC 2) (source) CC4.2
CIS CSC 8.1 16.2
CIS CSC 8.1 IG2 16.2
CIS CSC 8.1 IG3 16.2
COBIT 2019 DSS06.04 MEA01.05
COSO 2017 Principle 17
CSA IoT SCF 2 SET-04 SET-05 SET-06
GovRAMP Moderate SA-11(02)
GovRAMP High SA-11(02)
ISO/SAE 21434 2021 PM-06-08 RQ-15-17.a RQ-15-17.b RQ-15-17.c RQ-15-17.d
ISO 42001 2023 10.2 10.2(a) 10.2(a)(1) 10.2(a)(2) 10.2(b) 10.2(b)(1) 10.2(b)(2) 10.2(b)(3) 10.2(c) 10.2(d) 10.2(e)
NIST 800-37 R2 A-5
NIST 800-53 R4 SA-11(2)
NIST 800-53 R5 (source) SA-11(2)
NIST 800-53 R5 (NOC) (source) SA-11(2)
PCI DSS 4.0.1 (source) 6.2.1 6.2.2 6.2.3 6.2.3.1 6.2.4 6.3.1 6.4.1 6.4.2 11.4.1 11.4.4 12.4.2.1 A1.2.3
PCI DSS 4.0.1 SAQ A (source) 6.3.1
PCI DSS 4.0.1 SAQ A-EP (source) 6.2.1 6.2.2 6.2.4 6.3.1 6.4.1 6.4.2 11.4.1 11.4.4
PCI DSS 4.0.1 SAQ B-IP (source) 6.3.1
PCI DSS 4.0.1 SAQ C (source) 6.2.1 6.2.2 6.2.3.1 6.2.4 6.3.1
PCI DSS 4.0.1 SAQ C-VT (source) 6.3.1
PCI DSS 4.0.1 SAQ D Merchant (source) 6.2.1 6.2.2 6.2.3 6.2.3.1 6.2.4 6.3.1 6.4.1 6.4.2 11.4.1 11.4.4
PCI DSS 4.0.1 SAQ D Service Provider (source) 6.2.1 6.2.2 6.2.3 6.2.3.1 6.2.4 6.3.1 6.4.1 6.4.2 11.4.1 11.4.4 12.4.2.1 A1.2.3
US (12)
Framework Mapping Values
US DHS CISA SSDAF 2 4.a
US DHS ZTCF DEV-04
US EO 14028 4e(iii) 4e(iv)
US FedRAMP R4 SA-11(2)
US FedRAMP R4 (moderate) SA-11(2)
US FedRAMP R4 (high) SA-11(2)
US FedRAMP R5 (source) SA-11(2)
US FedRAMP R5 (moderate) (source) SA-11(2)
US FedRAMP R5 (high) (source) SA-11(2)
US NSTC NSPM-33 6.11
US - CA CCPA 2025 7123(c)(14)
US - TX TX-RAMP Level 2 SA-11(2)
EMEA (6)
Framework Mapping Values
EMEA EU EBA GL/2019/04 3.6.2(68) 3.6.2(69) 3.6.2(70)
EMEA EU NIS2 21.4
EMEA Germany C5 2020 DEV-02
EMEA Israel CDMO 1.0 17.13
EMEA Saudi Arabia CSCC-1 2019 1-3-2-1
EMEA Saudi Arabia ECC-1 2018 1-5-3-2 1-5-3-4
APAC (2)
Framework Mapping Values
APAC Japan ISMAP 4.7.1
APAC Singapore MAS TRM 2021 6.1.6
Americas (1)
Framework Mapping Values
Americas Canada CSAG 2.7

Capability Maturity Model

Level 0 — Not Performed

There is no evidence of a capability to require system developers and integrators to create a Security Testing and Evaluation (ST&E) plan and implement the plan under the witness of an independent party.

Level 1 — Performed Informally

C|P-CMM1 is N/A, since a structured process is required to require system developers and integrators to create a Security Testing and Evaluation (ST&E) plan and implement the plan under the witness of an independent party.

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

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 system developers and integrators to create a Security Testing and Evaluation (ST&E) plan and implement the plan under the witness of an independent party.

Assessment Objectives

  1. TDA-15_A01 information concerning impact, environment of operations, known or assumed threats and acceptable risk levels to be used as contextual information for threat modeling and vulnerability analyses is defined.
  2. TDA-15_A02 the tools and methods to be employed for threat modeling and vulnerability analyses are defined.
  3. TDA-15_A03 the breadth and depth of threat modeling to be conducted is defined.
  4. TDA-15_A04 the breadth and depth of vulnerability analyses to be conducted is defined.
  5. TDA-15_A05 acceptance criteria to be met by produced evidence for threat modeling are defined.
  6. TDA-15_A06 acceptance criteria to be met by produced evidence for vulnerability analyses are defined.
  7. TDA-15_A07 the developer of the system, system component, or system service is required to perform threat modeling during development of the system, component, or service that uses organization-defined information.
  8. TDA-15_A08 the developer of the system, system component, or system service is required to perform vulnerability analyses during development of the system, component, or service that uses organization-defined information.
  9. TDA-15_A09 the developer of the system, system component, or system service is required to perform threat modeling during the subsequent testing and evaluation of the system, component, or service that uses organization-defined information.
  10. TDA-15_A10 the developer of the system, system component, or system service is required to perform vulnerability analyses during the subsequent testing and evaluation of the system, component, or service that uses organization-defined information.
  11. TDA-15_A11 the developer of the system, system component, or system service is required to perform threat modeling during development of the system, component, or service that employs organization-defined tools and methods.
  12. TDA-15_A12 the developer of the system, system component, or system service is required to perform threat modeling during the subsequent testing and evaluation of the system, component, or service that employs organization-defined tools and methods.
  13. TDA-15_A13 the developer of the system, system component, or system service is required to perform vulnerability analyses during development of the system, component, or service that employs organization-defined tools and methods.
  14. TDA-15_A14 the developer of the system, system component, or system service is required to perform vulnerability analyses during the subsequent testing and evaluation of the system, component, or service that employs organization-defined tools and methods.
  15. TDA-15_A15 the developer of the system, system component, or system service is required to perform threat modeling per an organization-defined breadth and depth during development of the system, component or service.
  16. TDA-15_A16 the developer of the system, system component, or system service is required to perform vulnerability analyses during the subsequent testing and evaluation of the system, component, or service that conducts modeling and analyses per an organization-defined breadth and depth.
  17. TDA-15_A17 the developer of the system, system component, or system service is required to perform threat modeling during development of the system, component, or service that produces evidence that meets organization-defined acceptance criteria.
  18. TDA-15_A18 the developer of the system, system component, or system service is required to perform threat modeling during the subsequent testing and evaluation of the system, component, or service that produces evidence that meets organization-defined acceptance criteria.
  19. TDA-15_A19 the developer of the system, system component, or system service is required to perform vulnerability analyses during development of the system, component, or service that produces evidence that meets organization-defined acceptance criteria.
  20. TDA-15_A20 the developer of the system, system component, or system service is required to perform vulnerability analyses during the subsequent testing and evaluation of the system, component, or service that produces evidence that meets organization-defined acceptance criteria.

Technology Recommendations

Micro/Small

  • Security Testing and Evaluation (ST&E)

Small

  • Security Testing and Evaluation (ST&E)

Medium

  • Security Testing and Evaluation (ST&E)

Large

  • Security Testing and Evaluation (ST&E)

Enterprise

  • Security Testing and Evaluation (ST&E)

The Secure Controls Framework (SCF) is maintained by SCF Council. Use of SCF content is subject to the SCF Terms & Conditions.

Manage this control in SCF Connect

Track implementation status, collect evidence, and map controls to your compliance frameworks automatically.