Cyber Resilience

← ISO 27001 Annex A

A.8.25 Technological

Secure development life cycle

AttributesPreventive C·I·A Protect Application security System and network security Protection

Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?

The implementation guidance for this control is published in ISO/IEC 27002:2022 and is not reproduced here. The structured attributes and the cross-walk rationales below are derived facts and our own AI-authored analysis.

Mapped NIST 800-53 r5 controls (25)

Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

AT-3←P →P CA-8←P CM-9←P SA-10←P SA-11←M →P SA-15gov SA-17gov SA-3gov SA-4gov SA-8gov

Why these map — AI rationale (under review)

SA-11mostlyaligns with — Both mandate security testing activities such as code review, vulnerability scanning, and penetration testing during development.
SA-15mostlyaligns with — Both require the use of secure development processes, standards, and tools to produce secure software and systems.
AT-3partialaligns with — Both require role-based security training for developers to ensure they can identify and remediate vulnerabilities.
CM-2partialaligns with — Both address the need for secure baseline configurations and controlled repositories for source code and system components.
SA-11partialcovers — A.8.25 requires security to be designed and implemented within the SDLC (including testing/evaluation activities), which addresses a slice of SA-11's post-design testing, assessment-plan, and evidence requirements, but leaves the bulk of SA-11's specific developer obligations, parameters, and ongoing assessment details uncovered.
SA-17partialaligns with — Both require security architecture and design considerations to be addressed during the development life cycle.
SA-8partialaligns with — Both embed security and privacy engineering principles into the development process to reduce vulnerabilities.
SA-3noneimplements — Both controls establish a secure development life cycle that integrates security requirements, testing, and controls across all phases of system creation.
CM-2covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
SA-15implements — A.8.25 directly requires a secure SDLC that incorporates security into development processes, which SA-15 operationalizes by mandating a documented development process that explicitly addresses security/privacy requirements, standards, tools, and configuration management.
SA-17implements — A.8.25 requires secure development practices including design-phase security architecture; SA-17 directly operationalizes that by mandating developer-produced security architecture consistent with the enterprise architecture.
SA-8implements — A.8.25's mandate to embed information security throughout the SDLC directly operationalizes the application of security engineering principles across the identical set of lifecycle phases that SA-8 names; the link is by shared subject domain rather than explicit citation of the principles themselves.

Aligned NIST CSF 2.0 outcomes (20)

NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

PR.PS-06←F →F GV.SC-05gov ID.IM-02gov ID.RA-09gov PR.AT-02gov PR.IR-01gov PR.PS-01gov

Why these map — AI rationale (under review)

PR.PS-06fullcovers — The ISO control mandates embedding security requirements, testing, and developer training throughout the software development lifecycle, which directly fulfills the CSF outcome of integrating and monitoring secure development practices.
ID.RA-09mostlyaligns with — Requiring security checkpoints, code scanning, and penetration testing before release ensures the authenticity and integrity of software are assessed prior to acquisition and use.
PR.AT-02mostlyaligns with — The control explicitly calls for application-security knowledge, training, and developer capability to prevent, find, and fix vulnerabilities, matching the CSF requirement for specialized-role awareness and training.
GV.SC-05partialaligns with — When development is outsourced, the control requires the organization to obtain assurance that the supplier follows its secure-development rules, which corresponds to establishing and integrating cybersecurity requirements into supplier contracts.
ID.IM-02partialaligns with — Security testing, regression testing, and penetration testing performed during development generate findings that the organization can use to identify improvements, aligning with the CSF outcome of sourcing improvements from security tests and exercises.
GV.SC-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
ID.IM-02implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
ID.RA-09implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
PR.AT-02implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.

Related OWASP ASVS 5.0 requirements (14)

Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

V15.1.1←M →P V15.1.2←M →P V15.1.5←P V15.2.1←M →P V15.2.4→P V15.2.5←P →P V15.3.2→P V15.3.3→P V15.3.5→P V2.1.1←P

Why these map — AI rationale (under review)

V15.1.1partialaligns with — The ISO control's emphasis on security checkpoints, testing, and remediation timelines in the development lifecycle directly supports the ASVS requirement for documented risk-based remediation time frames for vulnerable third-party components.
V15.1.2partialaligns with — Requiring secure repositories and version control under the ISO control aligns with the ASVS mandate to maintain an inventory of third-party libraries and their versions as part of secure development governance.
V15.2.1partialaligns with — The ISO control's requirement for developers to prevent, find, and fix vulnerabilities supports the ASVS expectation that no components remain in production beyond their documented remediation time frames.
V15.2.4partialaligns with — Secure source-code repositories and version-control practices in the ISO control align with the ASVS requirement that third-party components and transitive dependencies come only from expected, approved repositories.
V15.2.5partialaligns with — The ISO control's call for secure coding guidelines and developer training corresponds to the ASVS requirement for additional protections around documented dangerous functionality.
V15.3.2partialaligns with — Secure development practices and testing checkpoints in the ISO control align with the ASVS requirement that backend calls to external URLs do not follow redirects unless explicitly intended.
V15.3.3partialaligns with — The ISO control's secure-coding guidelines and developer capability expectations support the ASVS requirement to implement countermeasures against mass-assignment attacks by limiting allowed fields.
V15.3.5partialaligns with — Requiring secure coding guidelines and developer training under the ISO control aligns with the ASVS expectation that the application enforces correct variable types and strict equality/comparator operations.

Related weaknesses / CWE (909)

Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

CWE-1007←P CWE-102←P →P CWE-1022←P →P CWE-1024←P →P CWE-1025←P →P CWE-1037←P →P CWE-1038←P →P CWE-1039←P →P CWE-1049←P →P CWE-1050→P CWE-1051←P →P CWE-1055←P →P CWE-1057←P →P CWE-1058←P →P CWE-1059←P →P CWE-1066←P →P CWE-1067←P →P CWE-1068←P →P CWE-1072→P CWE-1076←P →P CWE-1078→P CWE-1083←P →P CWE-1088←P →P CWE-1091→P CWE-11←P →P CWE-1100→P CWE-1102←P →P CWE-1103←P CWE-1106→P CWE-1107←P →P CWE-1108←P →P CWE-111←P →P CWE-1112←P CWE-1113→P CWE-1116←P →P CWE-1118←P →P CWE-1119→P CWE-112←P →P CWE-1124←P →P CWE-1125←P →P CWE-113←P →P CWE-114←P →P CWE-115←P →P CWE-116←P →P CWE-1164←P →P CWE-117→P CWE-1173←P →P CWE-1174←P →P CWE-1176←P CWE-118←P →P CWE-119←P →P CWE-1191→P CWE-12←P →P CWE-120←P →P CWE-1204→P CWE-121←P →P CWE-122←P →P CWE-1221←P →P CWE-1223←P →P CWE-1224←P →P CWE-123←P →P CWE-1231←P →P CWE-1236←P →P CWE-124←P →P CWE-1240←P →P CWE-1241→P CWE-1242←P →P CWE-1244←P →P CWE-1245←P →P CWE-1246←P →P CWE-125←P →P CWE-1250←P →P CWE-1254←P →P CWE-126←P →P CWE-1264←P →P CWE-1265←P →P CWE-1269←P →P CWE-127←P →P CWE-1270←P →P CWE-1272→P CWE-128←P →P CWE-1281←P →P CWE-1282←P →P CWE-1284←P →P CWE-1285←P →P CWE-1286←P →P CWE-1287←P →P CWE-1288←P →P CWE-129←P →P CWE-1291←P →P CWE-1298←P →P CWE-130←P →P CWE-131←P →P CWE-1310→P CWE-1320←P →P CWE-1321←P →P CWE-1322←P →P CWE-1325←P →P CWE-1328→P CWE-1329←P →P CWE-1333←P →P CWE-1335←P →P CWE-1336←P →P CWE-134←P →P CWE-1341←P →P CWE-135←P →P CWE-1357→P CWE-138←P →P CWE-1386←P →P CWE-1389←P →P CWE-1391←P →P CWE-14→P CWE-140→P CWE-141←P →P CWE-142←P →P CWE-143←P →P CWE-144←P →P CWE-145←P →P CWE-146←P →P CWE-147←P →P CWE-148←P →P CWE-149←P →P CWE-150←P →P CWE-153←P →P CWE-154←P →P CWE-155←P →P CWE-156←P →P CWE-157←P →P CWE-158←P →P CWE-159←P →P CWE-160←P →P CWE-162←P →P CWE-164←P →P CWE-166←P →P CWE-167←P →P CWE-168←P →P CWE-170←P →P CWE-172←P →P CWE-176←P →P CWE-177→P CWE-178←P →P CWE-179←P →P CWE-180←P →P CWE-182←P →P CWE-185←P →P CWE-186←P →P CWE-187←P →P CWE-188←P →P CWE-190←P →P CWE-191←P →P CWE-192←P →P CWE-193←P →P CWE-194←P →P CWE-195←P →P CWE-196←P →P CWE-197←P →P CWE-198←P →P CWE-20→P CWE-200→P CWE-201←P →P CWE-204←P →P CWE-205←P →P CWE-207→P CWE-209←P →P CWE-210←P CWE-212←P →P CWE-215←P →P CWE-219←P →P CWE-22←P →P CWE-226→P CWE-228←P →P CWE-229←P →P CWE-23←P →P CWE-231←P →P CWE-232←P →P CWE-233←P →P CWE-234←P →P CWE-235←P →P CWE-236←P →P CWE-237←P →P CWE-239←P →P CWE-24←P →P CWE-240←P →P CWE-241←P →P CWE-242←P →P CWE-244→P CWE-248←P →P CWE-25←P →P CWE-252←P →P CWE-253←P →P CWE-257←P →P CWE-258→P CWE-26←P →P CWE-267→P CWE-27←P →P CWE-270←P →P CWE-271→P CWE-274→P CWE-277←P →P CWE-278←P →P CWE-28←P →P CWE-280→P CWE-284→P CWE-287→P CWE-288→P CWE-290←P →P CWE-30→P CWE-302←P →P CWE-303←P →P CWE-304→P CWE-305→P CWE-31←P →P CWE-316→P CWE-318→P CWE-32←P →P CWE-325→P CWE-329→P CWE-330→P CWE-331→P CWE-332→P CWE-336←P →P CWE-337←P →P CWE-338→P CWE-34←P →P CWE-340→P CWE-341→P CWE-342→P CWE-343→P CWE-344←P →P CWE-345→P CWE-349←P →P CWE-35←P →P CWE-351←P →P CWE-356←P →P CWE-357←P →P CWE-358←P →P CWE-36←P →P CWE-362←P →P CWE-363←P →P CWE-364←P →P CWE-366←P →P CWE-368←P →P CWE-369←P →P CWE-372←P →P CWE-374←P →P CWE-377←P →P CWE-378←P →P CWE-38←P →P CWE-384→P CWE-386←P →P CWE-390←P →P CWE-391←P →P CWE-392←P →P CWE-393←P →P CWE-394←P →P CWE-396→P CWE-401←P →P CWE-403←P →P CWE-407←P →P CWE-409→P CWE-41←P →P CWE-412→P CWE-413←P →P CWE-414←P →P CWE-415←P →P CWE-416←P →P CWE-421←P →P CWE-422←P →P CWE-424←P →P CWE-425→P CWE-428←P →P CWE-43←P →P CWE-430←P →P CWE-431←P →P CWE-433←P →P CWE-434→P CWE-435←P →P CWE-436←P →P CWE-437←P →P CWE-440←P →P CWE-441←P →P CWE-444←P →P CWE-446←P →P CWE-447←P →P CWE-448←P →P CWE-449←P →P CWE-450←P →P CWE-451←P →P CWE-453←P →P CWE-454←P →P CWE-455←P →P CWE-456←P →P CWE-457←P →P CWE-459←P →P CWE-460←P →P CWE-462←P →P CWE-463←P →P CWE-466←P →P CWE-467→P CWE-468←P →P CWE-469←P →P CWE-470←P →P CWE-471→P CWE-472←P →P CWE-473←P →P CWE-474←P →P CWE-475←P →P CWE-476←P →P CWE-477←P →P CWE-478→P CWE-479←P →P CWE-482→P CWE-484→P CWE-488←P →P CWE-489←P →P CWE-491←P →P CWE-495←P →P CWE-499←P →P CWE-50←P →P CWE-501←P →P CWE-507←P →P CWE-511←P →P CWE-520→P CWE-526←P →P CWE-531←P →P CWE-535←P →P CWE-539←P →P CWE-540←P →P CWE-541←P →P CWE-544←P →P CWE-547←P →P CWE-548←P →P CWE-550←P →P CWE-551←P →P CWE-553←P →P CWE-561←P →P CWE-562←P →P CWE-564←P →P CWE-567←P →P CWE-57←P →P CWE-570←P →P CWE-571←P →P CWE-573←P →P CWE-587←P →P CWE-588←P →P CWE-59←P →P CWE-590←P →P CWE-597←P →P CWE-6→P CWE-600←P →P CWE-602←P →P CWE-606←P →P CWE-610←P →P CWE-611←P →P CWE-615←P →P CWE-616←P →P CWE-617←P →P CWE-618←P →P CWE-621←P →P CWE-622←P →P CWE-623←P →P CWE-624←P →P CWE-625←P →P CWE-626←P →P CWE-627←P →P CWE-628←P →P CWE-637←P →P CWE-639→P CWE-640→P CWE-641←P →P CWE-642→P CWE-643←P →P CWE-644←P →P CWE-646←P →P CWE-648←P →P CWE-652←P →P CWE-657←M →P CWE-66←P →P CWE-662←P →P CWE-663←P →P CWE-664←P →P CWE-665←P →P CWE-667←P →P CWE-669←P →P CWE-67→P CWE-670←P →P CWE-674←P →P CWE-675←P →P CWE-676←P →P CWE-680←P →P CWE-681←P →P CWE-682←P →P CWE-683→P CWE-684←P →P CWE-686←P →P CWE-687←P →P CWE-688←P →P CWE-689←P →P CWE-690←P →P CWE-691←P →P CWE-692→P CWE-694→P CWE-695←P →P CWE-696←P →P CWE-697←P →P CWE-698←P →P CWE-704←P →P CWE-705←P →P CWE-706←P →P CWE-707←P →P CWE-710←P →P CWE-73←P →P CWE-733←P →P CWE-74←P →P CWE-749←P →P CWE-75←P →P CWE-754←P →P CWE-755←P →P CWE-756←P →P CWE-757→P CWE-758←P →P CWE-759→P CWE-76←P →P CWE-760→P CWE-761→P CWE-762←P →P CWE-763←P →P CWE-764←P →P CWE-765←P →P CWE-767←P →P CWE-768←P →P CWE-77←P →P CWE-771←P →P CWE-772←P →P CWE-774←P →P CWE-775←P →P CWE-776←P →P CWE-782→P CWE-783←P →P CWE-786←P →P CWE-787←P →P CWE-788←P →P CWE-789←P →P CWE-79→P CWE-790←P →P CWE-791→P CWE-792←P →P CWE-794←P →P CWE-80←P →P CWE-805←P →P CWE-81←P →P CWE-820←P →P CWE-821←P →P CWE-822←P →P CWE-823←P →P CWE-824←P →P CWE-825←P →P CWE-826←P →P CWE-827←P →P CWE-828←P →P CWE-83←P →P CWE-832←P →P CWE-833←P →P CWE-834←P →P CWE-835←P →P CWE-837←P →P CWE-838←P →P CWE-839←P →P CWE-84→P CWE-841←P →P CWE-843←P →P CWE-86←P →P CWE-862→P CWE-87←P →P CWE-88←P →P CWE-89→P CWE-90←P →P CWE-908←P →P CWE-909←P →P CWE-91←P →P CWE-910←P →P CWE-911←P →P CWE-912←P →P CWE-913←P →P CWE-914←P →P CWE-915←P →P CWE-917←P →P CWE-93←P →P CWE-941→P CWE-943←P →P CWE-95←P →P CWE-96←P →P CWE-97←P →P CWE-98←P →P CWE-99←P →P

Why these map — AI rationale (under review)

CWE-1103nonemitigates — Secure SDLC practices can include portability and cross-platform testing requirements for third-party components.
CWE-1342nonemitigates — Secure SDLC can incorporate hardware-specific threat modelling and mitigation for transient-execution issues.
CWE-210nonemitigates — Secure SDLC mandates error-handling rules that prevent leakage of sensitive information.
CWE-102prevents — Secure SDLC practices reduce duplicate-form validation errors through design and code review.
CWE-1022prevents — Secure development lifecycle processes require design and code reviews that should identify missing rel="noopener" or target="_blank" mitigations.
CWE-1024prevents — Secure development life cycle mandates type-safe coding practices that reduce incompatible-type comparisons.
CWE-1025prevents — Secure development lifecycle includes requirements and reviews that can catch incorrect comparison logic.
CWE-1037prevents — Secure development lifecycle requires compiler/optimization settings that preserve security-critical code.
CWE-1038prevents — Secure development lifecycle mandates review of automated build/optimization steps that could introduce security side-effects.
CWE-1039prevents — Secure development lifecycle requires adversarial testing and robustness validation for ML-based recognition components.
CWE-1049prevents — Secure development lifecycle requires design and code reviews that can catch excessive joins before deployment.
CWE-1050prevents — Secure SDLC processes can catch the weakness during reviews but do not inherently prevent it.
CWE-1051prevents — Secure development life cycle requires avoiding hard-coded secrets and network identifiers during design and coding.
CWE-1055prevents — Secure development life cycle requires design reviews that can catch problematic inheritance patterns.
CWE-1057prevents — Secure SDLC mandates use of approved data-access components and prevents ad-hoc direct access.
CWE-1058prevents — Secure development lifecycle mandates thread-safety reviews that can catch non-final static fields in multi-threaded code.
CWE-1059prevents — Secure SDLC mandates artefacts such as architecture and interface documentation.
CWE-1066prevents — Secure development lifecycle requires proper serialization handling to avoid missing control elements.
CWE-1067prevents — Secure development lifecycle requires performance and query-efficiency reviews that can catch missing indexes.
CWE-1068prevents — Secure SDLC mandates that implementation matches documented design artifacts, catching the inconsistency early.
CWE-1072prevents — Secure development life cycle can include architectural guidance on connection pooling but does not specifically enforce it.
CWE-1076prevents — Secure SDLC processes typically enforce coding and design conventions.
CWE-1078prevents — Secure development life cycle includes coding standards, but style enforcement is only one small part of the control.
CWE-1083prevents — A secure development life cycle mandates that all data access paths be routed through the approved data manager component.
CWE-1088prevents — Secure SDLC practices require timeout handling for external calls, directly addressing the missing timeout.
CWE-1091prevents — Secure SDLC practices can mandate proper resource-cleanup patterns that prevent missing destructor calls.
CWE-11prevents — Secure development life cycle mandates removal of debug symbols and verbose error handling before deployment.
CWE-1100prevents — Secure development life cycle processes encourage modular design but do not specifically address isolation of system-dependent functions.
CWE-1102prevents — Secure development life cycle mandates portable, architecture-independent coding practices that reduce reliance on machine-specific data representations.
CWE-1106prevents — Secure SDLC processes encourage consistent coding practices that reduce literal constants.
CWE-1107prevents — Secure development life cycle requires centralized, well-managed definitions that reduce scattered symbolic constants.
CWE-1108prevents — Secure SDLC practices discourage global state by enforcing modular design and encapsulation.
CWE-111prevents — Secure SDLC mandates review of native/JNI interfaces, reducing exposure to unsafe foreign code.
CWE-1113prevents — Secure SDLC includes coding standards enforcement that may indirectly address comment style.
CWE-1116prevents — Secure development life cycle includes code review and documentation standards that reduce inaccurate comments.
CWE-1118prevents — Secure development life cycle requires documentation of error-handling techniques.
CWE-1119prevents — Secure SDLC processes include code-quality gates that can catch excessive branching, but the control itself does not prescribe coding style.
CWE-112prevents — Secure development lifecycle mandates input validation and schema enforcement for untrusted XML.
CWE-1124prevents — Secure development life cycle mandates code reviews and design rules that can catch or prevent excessive nesting.
CWE-1125prevents — Secure SDLC practices include attack-surface reduction reviews during design and release.
CWE-113prevents — Secure development lifecycle mandates input validation and output encoding that directly prevents CRLF injection into HTTP headers.
CWE-114mitigates — Secure development lifecycle practices include controls on external code and command execution paths.
CWE-115prevents — Secure development lifecycle mandates input validation and canonicalization that directly prevent misinterpretation of inputs.
CWE-116prevents — Secure development life cycle mandates output encoding/escaping practices that directly prevent improper encoding.
CWE-1164prevents — Secure SDLC mandates code reviews and clean-up that remove dead/irrelevant code.
CWE-117prevents — Secure SDLC includes coding standards that reduce log-related weaknesses but does not specifically address logging.
CWE-1173prevents — Secure development life cycle mandates use of approved validation frameworks and libraries.
CWE-1174prevents — Secure development life cycle mandates validation of input models to prevent improper handling.
CWE-118prevents — Secure development lifecycle includes input validation and bounds checking that can prevent range errors.
CWE-119prevents — Secure development lifecycle mandates memory-safety practices that directly prevent buffer-boundary violations.
CWE-1191prevents — Secure SDLC encourages hardware security requirements but does not mandate debug-port controls.
CWE-12prevents — Secure development life cycle includes configuration hardening and error-handling requirements.
CWE-120prevents — Secure development life cycle mandates processes that can include input validation and bounds checking to prevent buffer overflows.
CWE-1204prevents — Secure SDLC processes can embed cryptographic standards and reviews that catch weak IV generation.
CWE-121prevents — Secure SDLC mandates buffer-safety practices that directly prevent stack overflows.
CWE-122prevents — Secure development lifecycle mandates practices that reduce the likelihood of introducing heap overflows.
CWE-1221prevents — Secure development life cycle requires review and validation of hardware design parameters to prevent insecure defaults.
CWE-1223prevents — Secure development lifecycle practices can include hardware design reviews that detect write-once register race conditions.
CWE-1224prevents — Secure development lifecycle includes hardware design reviews that can catch improper sticky-bit implementation.
CWE-123prevents — Secure development lifecycle practices directly reduce the likelihood of write-what-where flaws such as buffer overflows.
CWE-1231prevents — Secure development life cycle can require lock-bit immutability in design, yet does not ensure the implemented hardware prevents later changes.
CWE-1236prevents — Secure SDLC mandates input validation and output encoding that directly prevents formula injection in CSV exports.
CWE-124prevents — Secure SDLC mandates input validation and bounds checking that directly prevent buffer underflow.
CWE-1240prevents — Secure SDLC requires vetted crypto libraries and standards, reducing risky custom implementations.
CWE-1241prevents — Secure SDLC requires vetted RNG components, reducing likelihood of predictable algorithms.
CWE-1242prevents — Secure development life cycle requires documented design and review, reducing hidden or undocumented features.
CWE-1244prevents — Secure development lifecycle can include debug interface design reviews but does not guarantee correct access-level assignment.
CWE-1245prevents — Secure development lifecycle includes hardware design reviews that can catch FSM flaws.
CWE-1246prevents — Secure development life cycle requires design-time consideration of hardware constraints such as wear-leveling in limited-write NVM.
CWE-125prevents — Secure development life cycle mandates input validation and bounds checking that directly prevent out-of-bounds reads.
CWE-1250prevents — Secure SDLC practices can include consistency requirements yet do not specifically mandate distributed-state synchronization.
CWE-1254prevents — Secure development lifecycle processes can require constant-time comparison functions to prevent timing side-channels.
CWE-126prevents — Secure SDLC mandates input validation and bounds checking that can prevent buffer over-reads.
CWE-1264prevents — Secure development lifecycle practices can catch insecure hardware control/data channel synchronization during design and verification.
CWE-1265prevents — Secure SDLC practices can include reentrancy analysis and design rules that reduce the likelihood of nested non-reentrant calls.
CWE-1269prevents — Secure development life-cycle practices include release-gate checks that catch non-release configurations.
CWE-127prevents — Secure SDLC mandates input validation and bounds checking that can prevent buffer under-reads.
CWE-1270prevents — Secure development lifecycle practices include requirements and reviews that prevent flawed token-generation logic.
CWE-1272prevents — Secure SDLC can include state-transition checks, yet the control does not specifically require data clearing.
CWE-128prevents — Secure development lifecycle includes input validation and bounds checking that can prevent wrap-around errors.
CWE-1281prevents — Secure development lifecycle can include processor-specific validation to avoid instruction sequences that cause lock-ups.
CWE-1282prevents — Secure development life cycle mandates hardware-enforced immutability or protected storage for bootloaders and device identifiers.
CWE-1284prevents — Secure development lifecycle mandates input validation for quantity fields, directly preventing CWE-1284.
CWE-1285prevents — Secure development lifecycle includes input validation requirements that can prevent improper index handling.
CWE-1286prevents — Secure development life cycle mandates input validation to ensure syntactic correctness.
CWE-1287prevents — Secure development lifecycle mandates input validation and type checking to prevent improper type handling.
CWE-1288prevents — Secure development lifecycle requires input validation and consistency checks that directly address CWE-1288.
CWE-129prevents — Secure development lifecycle mandates input validation and bounds checking that directly prevents improper array indexing.
CWE-1291prevents — Secure SDLC practices include key-separation and signing-process controls that prevent reuse of the same key across environments.
CWE-1298prevents — Secure development lifecycle includes hardware design reviews that can catch race conditions.
CWE-130prevents — Secure development lifecycle mandates input validation and length checks that directly address inconsistent length fields.
CWE-131prevents — Secure development lifecycle mandates size-checking practices that reduce buffer-size miscalculations.
CWE-1310prevents — Secure development lifecycle practices encourage updatable firmware design but do not enforce post-deployment ROM patching.
CWE-1320prevents — Secure development lifecycle includes requirements for proper error and alert handling.
CWE-1321prevents — Secure development lifecycle mandates input validation and object-handling controls that directly prevent prototype pollution.
CWE-1322prevents — Secure development lifecycle requires architectural and coding practices that avoid blocking calls in non-blocking contexts.
CWE-1325prevents — Secure development life cycle includes resource-management requirements that can prevent uncontrolled per-object allocations.
CWE-1328prevents — Secure SDLC practices can embed anti-rollback mechanisms during hardware/firmware design.
CWE-1329mitigates — Secure-SDLC practices encourage selection of maintainable components, but the weakness may still arise from third-party or legacy choices.
CWE-1333prevents — Secure development lifecycle mandates review of algorithmic efficiency, directly addressing ReDoS-prone regex.
CWE-1335prevents — Secure development life cycle includes practices that can catch or prevent undefined bitwise-shift behavior.
CWE-1336prevents — Secure development life cycle mandates input validation and sanitization that directly prevents template-injection weaknesses.
CWE-134prevents — Secure SDLC mandates input validation and safe API usage that can prevent externally-controlled format strings.
CWE-1341prevents — Secure development lifecycle practices can include resource-management rules that reduce double-release bugs.
CWE-135prevents — Secure development life cycle includes requirements that can catch incorrect multi-byte string length calculations during design and coding.
CWE-1357mitigates — Secure SDLC practices include component selection and trust evaluation steps.
CWE-138prevents — Secure development life cycle mandates input validation and sanitization that directly prevents improper neutralization of special elements.
CWE-1386prevents — Secure development lifecycle can mandate junction/mount-point validation during design and coding.
CWE-1389prevents — Secure development lifecycle requires input validation and parsing rules that would catch radix assumptions.
CWE-1391prevents — Requires security activities throughout the SDLC that can catch weak credentials, but does not mandate their elimination.
CWE-14prevents — A secure SDLC can include compiler-flag and code-review requirements that mitigate dead-store removal, yet the control is broader.
CWE-140prevents — Secure development life cycle incorporates practices that reduce the likelihood of delimiter-neutralization defects.
CWE-141prevents — Secure development life cycle mandates input validation and sanitization that directly prevents delimiter injection.
CWE-142prevents — Secure development life cycle mandates input validation and sanitization that directly addresses delimiter neutralization.
CWE-143prevents — Secure development lifecycle mandates input validation and sanitization that directly prevents improper record-delimiter handling.
CWE-144prevents — Secure SDLC mandates input validation and sanitization that can prevent line-delimiter injection.
CWE-145prevents — Secure development life cycle mandates input validation and output encoding that directly neutralizes section delimiters.
CWE-146prevents — Secure development life cycle mandates input validation and output encoding that directly neutralizes expression/command delimiters.
CWE-147prevents — Secure development lifecycle mandates input validation and sanitization that directly prevents improper neutralization of terminators.
CWE-148prevents — Secure development lifecycle includes input-handling requirements that can prevent malformed leader sequences.
CWE-149prevents — Secure development life cycle mandates input validation and output encoding that directly prevent quote-injection flaws.
CWE-150prevents — Secure development lifecycle mandates input validation and output encoding that directly neutralizes escape/meta sequences.
CWE-153prevents — Secure development lifecycle mandates input validation and sanitization that directly prevents substitution-character injection.
CWE-154prevents — Secure SDLC mandates input validation and output encoding that directly neutralizes variable-name delimiter characters.
CWE-155prevents — Secure development lifecycle mandates input validation and sanitization that directly prevents wildcard injection.
CWE-156prevents — Secure development lifecycle includes input validation and sanitization practices that can prevent improper whitespace handling.
CWE-157prevents — Secure development life cycle requires input validation and sanitization practices that mitigate delimiter-handling flaws.
CWE-158prevents — Secure development lifecycle mandates input validation and sanitization that directly prevents null-byte injection.
CWE-159prevents — Secure development lifecycle mandates input validation and sanitization that directly prevents improper handling of special elements.
CWE-160prevents — Secure development life cycle mandates input validation and sanitization that directly prevents leading special-element injection.
CWE-162prevents — Secure development lifecycle includes input-handling requirements that can prevent trailing-special-element issues.
CWE-164prevents — Secure development life cycle mandates input validation and sanitization that directly prevents improper neutralization of internal special elements.
CWE-166prevents — Secure SDLC practices can include input validation rules that detect missing special elements.
CWE-167prevents — Secure development lifecycle mandates input validation and handling of unexpected data elements.
CWE-168prevents — Secure development lifecycle includes input-handling requirements that can prevent inconsistent special-element issues.
CWE-170prevents — Secure SDLC mandates input validation and string handling rules that prevent missing null terminators.
CWE-172prevents — Secure development lifecycle includes input/output validation and encoding practices that reduce encoding errors.
CWE-176prevents — Secure development lifecycle mandates input validation and encoding handling that can prevent Unicode mishandling.
CWE-177prevents — Secure SDLC processes include validation steps that reduce CWE-177, yet the control is broader than this single weakness.
CWE-178prevents — Secure SDLC practices should include case-sensitivity requirements in design and coding standards.
CWE-179prevents — Secure development life cycle mandates validation after canonicalization or sanitization, directly preventing early-validation bypasses.
CWE-180prevents — Secure SDLC mandates input validation and canonicalization order, directly addressing CWE-180.
CWE-182prevents — Secure development lifecycle mandates input validation and sanitization that directly prevents unsafe data collapse.
CWE-185prevents — Secure development lifecycle includes validation of input-handling constructs such as regex.
CWE-186prevents — Secure development lifecycle includes input-validation and regex-review practices that can catch overly restrictive patterns.
CWE-187prevents — Secure development lifecycle practices can include requirements to avoid partial string comparisons in authentication or validation logic.
CWE-188prevents — Secure development lifecycle includes architecture and design reviews that can catch invalid memory-layout assumptions.
CWE-190prevents — Secure SDLC mandates input validation and arithmetic checks that prevent integer overflows.
CWE-191prevents — Secure development lifecycle mandates input validation and arithmetic checks that prevent integer underflow.
CWE-192prevents — Secure development life cycle includes input validation and type-safety checks that reduce integer coercion errors.
CWE-193prevents — Secure development life cycle includes requirements and reviews that can catch off-by-one errors.
CWE-194prevents — Secure development lifecycle includes practices that can catch sign-extension issues during design and review.
CWE-195prevents — Secure development life cycle mandates practices that can catch signed-to-unsigned conversion errors during design and coding.
CWE-196prevents — Secure development lifecycle mandates practices that can catch or prevent unsafe type conversions.
CWE-197prevents — Secure development lifecycle mandates practices that can catch numeric truncation during design and code review.
CWE-198prevents — Secure development lifecycle requires handling of data formats and endianness in design and coding.
CWE-20prevents — Secure-coding guidelines and mandatory security testing (including code scans) compel developers to validate and sanitize inputs at design and implementation time, lowering the incidence of malformed or malicious data reaching downstream components.
CWE-200prevents — Penetration testing and code-scanning activities within the SDLC surface unintended exposure paths, allowing sensitive information leaks to be identified and corrected before release.
CWE-201prevents — Secure-SDLC practices include data-flow reviews that catch unintended transmission of secrets.
CWE-204prevents — Secure SDLC practices include error-handling and response standardization to avoid information disclosure.
CWE-205prevents — Secure development lifecycle practices can include design reviews that eliminate observable behavioral discrepancies.
CWE-207prevents — Secure development lifecycle practices can eliminate observable behavioral discrepancies.
CWE-209prevents — Secure SDLC mandates error-handling rules that avoid leaking sensitive information.
CWE-212prevents — Secure SDLC practices include requirements to strip sensitive data from artifacts before release.
CWE-215prevents — Secure SDLC mandates removal of debug code and sensitive data before release.
CWE-219mitigates — Secure SDLC practices include placing sensitive data outside the document root.
CWE-22prevents — Secure SDLC mandates input validation and path sanitization that directly prevent path traversal.
CWE-226prevents — Secure SDLC includes requirements for clearing sensitive data during resource lifecycle transitions.
CWE-228prevents — Secure development life cycle mandates input validation and error handling that directly prevents improper handling of syntactically invalid structures.
CWE-229prevents — Secure development lifecycle includes input validation and parameter handling requirements that reduce missing-value errors.
CWE-23prevents — Secure development lifecycle mandates input validation and path-handling controls that directly prevent relative path traversal.
CWE-231prevents — Secure development lifecycle includes input validation and parameter handling that can prevent extra-value processing flaws.
CWE-232prevents — Secure development life cycle requires handling of invalid/undefined inputs during design and coding.
CWE-233prevents — Secure development lifecycle includes input validation and parameter handling requirements that reduce improper parameter handling.
CWE-234prevents — Secure development lifecycle mandates input validation and parameter checking that can prevent missing-parameter failures.
CWE-235prevents — Secure development lifecycle includes input validation and parameter handling requirements that can prevent extra-parameter issues.
CWE-236prevents — Secure development lifecycle requires explicit definition and validation of all parameters, reducing undefined-parameter handling issues.
CWE-237prevents — Secure development lifecycle requires structured input validation and error handling that can mitigate improper handling of complex structures.
CWE-239prevents — Secure development lifecycle requires input validation and completeness checks that reduce incomplete-element handling failures.
CWE-24prevents — Secure SDLC mandates input validation and path canonicalization that directly block ../ traversal.
CWE-240prevents — Secure development lifecycle requires consistent handling of structural elements across design, coding and testing phases.
CWE-241prevents — Secure development lifecycle includes input validation and type checking that directly mitigates improper handling of unexpected data types.
CWE-242prevents — Secure SDLC processes include code review and static analysis that can detect dangerous function usage.
CWE-244prevents — Secure SDLC processes can incorporate memory-safety requirements but do not specifically mandate heap clearing.
CWE-248prevents — Secure development lifecycle includes exception-handling standards that reduce uncaught exceptions.
CWE-25prevents — Secure development lifecycle mandates input validation and path sanitization that directly prevents traversal sequences.
CWE-252prevents — Secure development life cycle mandates verification of return values to prevent undetected failures.
CWE-253prevents — Secure SDLC mandates return-value checks and error handling, directly reducing CWE-253.
CWE-257prevents — Secure SDLC includes requirements that reduce the likelihood of introducing recoverable password storage.
CWE-258prevents — Secure development lifecycle includes controls that should prevent shipping empty passwords in configuration artifacts.
CWE-26prevents — Secure development lifecycle mandates input validation and path canonicalization that directly prevent directory traversal sequences.
CWE-267mitigates — Secure development lifecycle can catch unsafe privilege definitions during design but does not prevent them at runtime.
CWE-27prevents — Secure development lifecycle mandates input validation and path sanitization that directly prevents directory traversal.
CWE-270prevents — Secure-SDLC practices can catch privilege-handling defects early but do not guarantee runtime correctness.
CWE-271prevents — Secure development lifecycle includes privilege management reviews, providing indirect coverage of the weakness.
CWE-274prevents — Secure SDLC practices can include privilege checks, yet the control itself does not mandate handling of insufficient privileges.
CWE-277prevents — Secure development lifecycle practices can include permission model reviews but do not guarantee secure inherited permissions.
CWE-278prevents — Secure development lifecycle practices include permission handling requirements that prevent insecure inherited permissions in new code.
CWE-28prevents — Secure development lifecycle mandates input validation and path sanitization that directly blocks ..\ traversal.
CWE-280prevents — Secure-SDLC practices include privilege checks during design and coding.
CWE-284prevents — Embedding security requirements and checkpoints throughout the development lifecycle forces explicit consideration of access-control decisions before code is written, reducing the chance that missing or incorrect authorization logic is introduced.
CWE-287prevents — Security requirements specified early and verified through testing drive the consistent implementation of authentication mechanisms, decreasing the likelihood that authentication steps are omitted or incorrectly applied.
CWE-288prevents — Secure development lifecycle can prevent introduction of bypass flaws but does not mitigate existing ones.
CWE-290prevents — Secure development lifecycle reduces authentication flaws when followed but is not specific to spoofing.
CWE-30prevents — Secure SDLC mandates input validation and path canonicalization that directly blocks leading-backslash traversal sequences.
CWE-302prevents — Secure SDLC practices include threat modeling and input-validation requirements that catch assumed-immutable data flaws.
CWE-303prevents — Secure development lifecycle includes verification steps that can catch incorrect authentication implementations.
CWE-304prevents — Secure development lifecycle can catch missing auth steps during design, but does not directly enforce runtime authentication.
CWE-305prevents — Secure development lifecycle reduces likelihood of introducing bypass flaws during implementation.
CWE-31prevents — Secure development lifecycle mandates input validation and path sanitization that directly blocks directory traversal sequences.
CWE-316prevents — Secure-SDLC processes include memory-handling reviews that catch this weakness.
CWE-318prevents — Secure SDLC processes can catch the weakness during design or code review but do not prescribe the technical fix.
CWE-32prevents — Secure SDLC mandates input validation and path-handling rules that directly block triple-dot traversal.
CWE-325prevents — Secure SDLC processes reduce the likelihood of missing crypto steps but do not guarantee algorithm completeness.
CWE-329prevents — Secure SDLC processes catch cryptographic flaws like bad IVs during design and review phases.
CWE-330prevents — Secure SDLC processes include verification steps that can catch insufficient randomness but do not directly specify RNG requirements.
CWE-331prevents — Secure-SDLC activities include entropy validation during design and testing.
CWE-332prevents — Secure SDLC requires selection of approved cryptographic primitives including proper RNG sources.
CWE-336prevents — Secure SDLC practices require cryptographic randomness to be addressed during design and implementation.
CWE-337prevents — Requires secure development practices that should include proper PRNG seeding.
CWE-338prevents — Secure SDLC processes should catch weak PRNG usage during design and code review.
CWE-34prevents — Secure development life cycle mandates input validation and path-handling controls that directly prevent path traversal sequences.
CWE-340prevents — A secure SDLC incorporates threat modelling and secure-design reviews that flag predictable identifier generation early in the lifecycle.
CWE-341prevents — SDLC requirements encourage secure design but do not directly mandate removal of predictable state.
CWE-342prevents — Secure SDLC mandates secure random-number practices during design and coding.
CWE-343prevents — Secure SDLC mandates cryptographic and randomness requirements that prevent predictable RNG weaknesses.
CWE-344prevents — Secure development life cycle requires parameterization and environment-aware design, directly addressing invariant values.
CWE-345prevents — Secure SDLC incorporates authenticity verification requirements throughout development.
CWE-349prevents — Secure development lifecycle mandates input validation and trust-boundary enforcement that directly prevents acceptance of untrusted data alongside trusted data.
CWE-35prevents — Secure SDLC mandates input validation and path-handling controls that directly mitigate path traversal.
CWE-351prevents — Secure development lifecycle practices can include type-safe design and validation to reduce type confusion.
CWE-356prevents — Secure development life cycle requires UI design to warn users before unsafe actions.
CWE-357prevents — Secure development lifecycle requires usable security prompts and warnings to be designed into the UI.
CWE-358prevents — Secure development life cycle mandates verification that security checks required by standards are correctly implemented.
CWE-36prevents — Secure development lifecycle includes input validation and path-handling requirements that reduce absolute path traversal risk.
CWE-362prevents — Secure SDLC mandates concurrency controls and synchronization primitives that directly prevent race conditions.
CWE-363prevents — Secure development lifecycle practices can include TOCTOU-safe file handling, but do not guarantee elimination of link-following races.
CWE-364prevents — Secure SDLC practices can require avoidance of unsafe signal handling patterns.
CWE-366prevents — Secure development lifecycle includes concurrency and synchronization practices that reduce race conditions.
CWE-368prevents — Secure development lifecycle practices can require atomic context-switch handling and race-condition testing.
CWE-369prevents — Secure development lifecycle includes input validation and error-handling practices that can prevent divide-by-zero faults.
CWE-372prevents — Secure development lifecycle practices can include state-machine validation and invariant checks that reduce incomplete internal state errors.
CWE-374prevents — Secure development lifecycle practices can mandate defensive copying of mutable objects before passing them to untrusted code.
CWE-377prevents — Secure development life cycle mandates secure handling of temporary files during design and coding.
CWE-378prevents — Secure SDLC mandates secure handling of temporary files and permissions.
CWE-38prevents — Secure development lifecycle mandates input validation and path-handling controls that directly prevent absolute-path traversal.
CWE-384prevents — Secure-SDLC requirement can embed session-fixation checks, but eliminating the weakness does not satisfy the full SDLC control.
CWE-386prevents — Secure development lifecycle practices can require explicit object resolution instead of relying on symbolic names that may change.
CWE-390prevents — Secure development lifecycle practices encourage proper error handling, but do not mandate it for every detected condition.
CWE-391prevents — Secure development life cycle requires systematic error handling, reducing unchecked conditions.
CWE-392prevents — Secure development lifecycle practices include requirements for proper error handling and status reporting.
CWE-393prevents — Secure development lifecycle includes code review and testing that can catch incorrect status codes.
CWE-394prevents — Secure development lifecycle requires handling of all return values and status codes.
CWE-396prevents — Secure SDLC processes encourage disciplined exception handling, yet the control itself does not mandate specific coding rules.
CWE-401prevents — Secure development life cycle mandates memory-management practices that reduce missing-release defects.
CWE-403prevents — Secure SDLC practices include code reviews and static analysis that can detect leaked descriptors.
CWE-407prevents — Secure development life cycle includes design reviews that can catch inefficient algorithms before deployment.
CWE-409prevents — Secure development lifecycle includes input validation and resource-limit checks that mitigate data-amplification attacks.
CWE-41prevents — Secure development lifecycle includes path-handling requirements that reduce equivalence-based disclosure.
CWE-412prevents — Secure development lifecycle practices can prevent introducing externally controllable locks during design.
CWE-413prevents — Secure development lifecycle requires proper resource management patterns that prevent improper locking.
CWE-414prevents — Secure SDLC practices include concurrency and synchronization reviews that catch missing lock checks.
CWE-415prevents — Secure development life cycle includes memory-safety practices that can prevent double-free bugs.
CWE-416prevents — Secure SDLC mandates memory-safety practices that reduce use-after-free defects.
CWE-421prevents — Secure development practices can identify and eliminate race conditions involving alternate channels.
CWE-422prevents — Secure development life cycle mandates input validation and privilege separation that directly prevent shatter-style message injection.
CWE-424prevents — Secure development lifecycle includes design reviews that should identify and close alternate paths.
CWE-425prevents — Secure SDLC can include authorization design, yet the control itself does not guarantee runtime enforcement.
CWE-428prevents — Secure development lifecycle practices include input validation and path handling that reduce unquoted search-path weaknesses.
CWE-43prevents — Secure SDLC requires input validation and path-handling controls that can prevent malformed filenames.
CWE-430prevents — Secure development life cycle includes handler registration and dispatch validation that prevents wrong-handler assignment.
CWE-431prevents — Secure development life cycle requires defined error/exception handling, reducing missing-handler defects.
CWE-433prevents — Secure development lifecycle mandates proper file-type handling and server configuration to prevent raw content exposure.
CWE-434prevents — Secure-coding guidelines and security testing explicitly address restrictions on allowed file types and upload handling, reducing the risk that dangerous file uploads are accepted without validation.
CWE-435prevents — Secure SDLC practices include integration and interface testing that can detect interaction flaws.
CWE-436prevents — Secure development lifecycle can require consistent interface contracts and canonicalization rules that reduce interpretation conflicts between components.
CWE-437prevents — A secure SDLC can mandate complete endpoint capability modeling during design and threat modeling phases.
CWE-440prevents — Secure development life cycle mandates verification against specifications, directly reducing expected-behavior violations.
CWE-441prevents — Secure-SDLC practices include design reviews that detect and eliminate confused-deputy proxy patterns before deployment.
CWE-444prevents — Secure SDLC practices require threat modeling and testing for HTTP parsing inconsistencies in intermediaries.
CWE-446prevents — Secure development lifecycle requires UI security features to be correctly implemented and verified, directly preventing misleading security-state feedback.
CWE-447prevents — Secure development lifecycle requires that security features are actually implemented, not just presented in the UI.
CWE-448prevents — Secure development lifecycle requires removal or deprecation of obsolete UI features before release.
CWE-449prevents — Secure development lifecycle includes UI/UX requirements and testing that directly prevent the interface from executing the wrong action.
CWE-450prevents — Secure development lifecycle can require UI input handling to be unambiguous and user-prompted on ambiguous choices.
CWE-451prevents — Secure development lifecycle includes UI/UX security requirements that can prevent misrepresentation of critical information.
CWE-453prevents — Secure development life cycle requires explicit secure initialization of variables.
CWE-454prevents — Secure development lifecycle mandates validation of all inputs used to initialize trusted variables or data stores.
CWE-455prevents — Secure development lifecycle requires proper error handling and secure initialization, addressing the weakness.
CWE-456prevents — Secure development life cycle mandates initialization checks that prevent uninitialized-variable defects.
CWE-457prevents — Secure development life cycle mandates practices that reduce uninitialized-variable defects.
CWE-459prevents — SDLC practices include cleanup steps, yet the weakness can still occur if those steps are omitted.
CWE-460prevents — Secure SDLC mandates exception-handling and cleanup practices that reduce improper state after thrown exceptions.
CWE-462prevents — Secure development lifecycle includes input validation and data-structure checks that can prevent duplicate-key bugs.
CWE-463prevents — Secure SDLC practices can include sentinel handling rules that reduce accidental deletion.
CWE-466prevents — Secure SDLC practices can include pointer-range validation and bounds checking to prevent out-of-range returns.
CWE-467prevents — Secure SDLC processes include coding standards that reduce this class of defect.
CWE-468prevents — Secure SDLC processes can introduce pointer-safety reviews that reduce incorrect scaling, but the control is broader than this single coding flaw.
CWE-469prevents — Secure SDLC mandates design and code reviews that can catch unsafe pointer arithmetic.
CWE-470prevents — Secure development lifecycle mandates input validation and design reviews that reduce unsafe reflection risks.
CWE-471prevents — Secure SDLC practices include design reviews that identify and protect data assumed to be immutable.
CWE-472prevents — Secure development lifecycle mandates input validation and integrity checks that directly prevent external tampering of assumed-immutable parameters.
CWE-473prevents — Secure development lifecycle mandates input validation and variable handling rules that directly prevent external variable tampering.
CWE-474prevents — Secure SDLC requires consistent API selection and platform abstraction, reducing use of inconsistently implemented functions.
CWE-475prevents — Secure development lifecycle includes API specification and validation that can prevent undefined behavior from invalid inputs.
CWE-476prevents — Secure SDLC mandates defensive coding practices that can prevent NULL dereferences.
CWE-477prevents — Secure SDLC processes include code reviews and maintenance that catch obsolete functions.
CWE-478prevents — Secure SDLC processes encourage defensive coding but do not directly mandate default-case coverage.
CWE-479prevents — Secure SDLC mandates safe coding practices that can prevent non-reentrant calls in signal handlers.
CWE-482prevents — Secure SDLC processes include coding standards that reduce this class of error.
CWE-484prevents — Secure SDLC processes include code review and testing that can catch missing breaks, but do not specifically mandate them.
CWE-488prevents — Secure development lifecycle practices include session-management controls that prevent exposure of data to the wrong session.
CWE-489prevents — Secure development life cycle mandates removal of debug code before release.
CWE-491prevents — Secure development lifecycle includes design and code reviews that can catch non-final clone methods.
CWE-495prevents — Secure SDLC practices can mandate encapsulation and return-value design rules that prevent leaking private structures.
CWE-499prevents — Secure SDLC requires design reviews that can mandate explicit non-serializability for sensitive classes.
CWE-50prevents — Secure development lifecycle requires input validation and path-handling controls that mitigate path-equivalence issues.
CWE-501prevents — Secure development lifecycle mandates separation of trusted and untrusted data flows, directly preventing mixing in the same structure.
CWE-507prevents — Secure development lifecycle reduces the chance of hidden malicious code being introduced.
CWE-511prevents — Secure development lifecycle processes include code review and testing that detect logic/time bombs before deployment.
CWE-520prevents — Secure SDLC practices can catch impersonation misconfigurations early, but removing the weakness does not fulfill the full lifecycle control objective.
CWE-526prevents — Secure SDLC practices include requirements to avoid storing secrets in cleartext environment variables.
CWE-531prevents — Secure SDLC mandates review of test artifacts, reducing risk of sensitive data in test code.
CWE-535prevents — Secure SDLC practices include proper exception handling to avoid leaking sensitive data in error messages.
CWE-539prevents — Secure development lifecycle requires avoiding persistent storage of sensitive data in cookies.
CWE-540prevents — Secure SDLC practices include removing secrets from code before commit or deployment.
CWE-541prevents — Secure SDLC practices ensure sensitive data is not hard-coded in include files.
CWE-544prevents — Secure development life cycle requires consistent, standardized error-handling practices across the codebase.
CWE-547prevents — Secure SDLC processes can catch hard-coded constants during reviews and testing.
CWE-548prevents — Secure development life cycle includes configuration hardening that disables directory listing in production web servers.
CWE-550prevents — Secure SDLC mandates handling of error messages to avoid information disclosure.
CWE-551prevents — Secure development lifecycle requires proper URL parsing and canonicalization before authorization checks.
CWE-553prevents — Secure development lifecycle practices include review and removal of dangerous files before deployment.
CWE-561prevents — Secure SDLC mandates code reviews and static analysis that detect and remove unreachable code.
CWE-562prevents — Secure SDLC practices can catch stack-variable misuse during design and code review.
CWE-564prevents — Secure SDLC mandates input validation and ORM usage that reduce dynamic SQL injection risk.
CWE-567prevents — Secure development lifecycle includes thread-safety and concurrency requirements that reduce unsynchronized access.
CWE-57prevents — Requires secure development practices that include canonicalization and input validation to prevent path-equivalence flaws.
CWE-570prevents — Secure development life cycle includes static analysis and code review that can detect always-false expressions.
CWE-571prevents — Secure development life cycle includes static analysis and code review that can detect always-true expressions.
CWE-573prevents — Secure development life cycle mandates adherence to language, framework and protocol specifications, directly reducing improper caller behavior.
CWE-587prevents — Secure development life cycle mandates practices that can prevent hard-coded pointer assignments.
CWE-588prevents — Secure SDLC mandates design and code reviews that can catch unsafe pointer casts.
CWE-59prevents — Secure SDLC practices can mandate link-resolution checks and canonicalization before file access.
CWE-590prevents — Secure development lifecycle mandates memory-safety practices that reduce use-after-free and invalid-free bugs.
CWE-597prevents — Secure SDLC practices include code reviews and static analysis that catch incorrect string comparisons.
CWE-6prevents — Secure development life cycle includes configuration hardening that would catch weak session settings.
CWE-600prevents — Secure development lifecycle mandates exception-handling and error-handling standards that prevent uncaught servlet exceptions.
CWE-602prevents — Secure development lifecycle mandates server-side validation and prevents reliance on client enforcement.
CWE-606prevents — Secure development lifecycle requires input validation and bounds checking that can prevent unchecked loop conditions.
CWE-610prevents — Secure development lifecycle mandates validation of all external references to prevent uncontrolled resource access.
CWE-611prevents — Secure development life cycle mandates input validation and entity handling that directly prevents XXE.
CWE-615prevents — Secure SDLC practices can include code-review gates that catch sensitive comments before release.
CWE-616prevents — Secure development lifecycle mandates proper input handling and file-upload validation, directly addressing the outdated global-variable approach.
CWE-617prevents — Secure development lifecycle mandates defensive coding and input validation that prevent reachable assertions from being triggered by untrusted data.
CWE-618prevents — Secure development lifecycle mandates review of exposed interfaces and dangerous methods before release.
CWE-621prevents — Secure development lifecycle mandates input validation and variable handling rules that reduce extraction errors.
CWE-622prevents — Secure development lifecycle requires input validation and API design reviews that would catch missing hook-argument checks.
CWE-623prevents — Secure development lifecycle processes include security reviews that would catch and reject unsafe-for-scripting markings.
CWE-624prevents — Secure development lifecycle includes input validation and regex review that can prevent executable regex patterns.
CWE-625prevents — Secure development lifecycle requires validation of input mechanisms, including regex, reducing permissive patterns.
CWE-626prevents — Secure SDLC practices can include input validation and boundary checks that prevent null-byte mishandling.
CWE-627prevents — Secure development lifecycle mandates input validation and variable handling rules that reduce dynamic evaluation risks.
CWE-628prevents — Secure development lifecycle includes code review and testing that can catch incorrect function arguments.
CWE-637prevents — Secure development life cycle includes design reviews that can catch overly complex protection mechanisms.
CWE-639prevents — Secure development lifecycle includes authorization design but does not itself implement runtime access checks.
CWE-640prevents — Secure-SDLC practices can embed strong recovery design, yet the control is broader than this single weakness.
CWE-641prevents — Secure development life cycle mandates input validation and safe resource naming practices that directly prevent CWE-641.
CWE-642prevents — Secure development practices can avoid placing critical state in externally writable locations.
CWE-643prevents — Secure SDLC mandates input validation and query parameterization that directly prevent XPath injection.
CWE-644prevents — Secure development lifecycle mandates input validation and output encoding that directly prevents header-injection flaws.
CWE-646prevents — Secure SDLC requires proper file-type validation, directly mitigating reliance on untrusted names or extensions.
CWE-648prevents — Secure development lifecycle includes API usage standards that can prevent incorrect privileged calls.
CWE-652prevents — Secure SDLC mandates input validation and query parameterization that directly prevent XQuery injection.
CWE-657prevents — A secure development life cycle directly requires adherence to established secure design principles.
CWE-66prevents — Secure development lifecycle practices can include input validation and path-handling rules that reduce the risk of mishandling virtual file names.
CWE-662prevents — Secure development lifecycle requires concurrency controls and synchronization primitives to prevent race conditions.
CWE-663prevents — Secure SDLC requires thread-safety and re-entrancy analysis that can prevent non-reentrant calls in concurrent contexts.
CWE-664prevents — Secure SDLC embeds resource lifecycle controls from design through decommissioning.
CWE-665prevents — Secure development life cycle mandates initialization checks and secure defaults that directly prevent improper resource initialization.
CWE-667prevents — Secure development lifecycle includes concurrency and locking requirements that reduce improper locking defects.
CWE-669mitigates — Secure SDLC practices can catch incorrect resource-transfer flaws early.
CWE-67prevents — Secure development lifecycle requires input validation and path handling rules that would prevent device-name misuse.
CWE-670prevents — Secure development lifecycle processes can catch incorrect control-flow logic during design and code review.
CWE-674prevents — Secure development life cycle requires controls that prevent uncontrolled recursion through design and code review.
CWE-675prevents — Secure development lifecycle practices can catch duplicate resource operations during design and code review.
CWE-676prevents — Secure SDLC processes include code review and static analysis that can detect use of risky functions.
CWE-680prevents — Secure development life cycle mandates practices that can catch integer overflows before deployment.
CWE-681prevents — Secure development lifecycle includes type-safety and conversion checks that reduce numeric truncation risks.
CWE-682prevents — Secure development lifecycle mandates verification steps that catch incorrect calculations before they reach production.
CWE-683prevents — A secure SDLC process encourages practices that reduce such weaknesses but does not directly address argument ordering.
CWE-684prevents — Secure development life cycle includes requirements and verification activities that directly reduce the risk of delivering functionality that deviates from published specifications.
CWE-686prevents — Secure development life cycle includes coding standards and reviews that can catch type-mismatch errors.
CWE-687prevents — Secure development lifecycle includes code review and testing that can catch incorrect argument values.
CWE-688prevents — Secure development lifecycle includes code review and testing that can catch incorrect argument usage.
CWE-689prevents — Requires secure development practices that include proper permission handling in copy routines.
CWE-690prevents — Secure SDLC mandates error-handling and input-validation practices that reduce unchecked return values.
CWE-691prevents — Secure development life cycle mandates structured control-flow design and review that directly reduces unexpected flow manipulation.
CWE-692prevents — Secure-SDLC processes encourage proper input/output handling, but do not specifically address denylist shortcomings.
CWE-694prevents — Secure development lifecycle practices can catch duplicate-ID issues during design and code review.
CWE-695prevents — Secure development life cycle mandates avoidance of prohibited low-level APIs.
CWE-696prevents — Secure development life cycle mandates correct sequencing of security activities, directly preventing incorrect behavior order.
CWE-697prevents — Secure development lifecycle includes code review and testing that can catch incorrect comparison logic.
CWE-698prevents — Secure development lifecycle requires proper handling of redirects and exit logic, reducing EAR risk.
CWE-704prevents — Secure development lifecycle includes type-safety reviews that reduce incorrect casts.
CWE-705prevents — Secure development lifecycle practices can catch improper control-flow scoping during design and code review.
CWE-706prevents — Secure SDLC practices include design reviews that can catch incorrect name or reference handling before deployment.
CWE-707prevents — Secure development life cycle mandates input validation and output encoding that directly prevent improper neutralization.
CWE-710prevents — Secure SDLC mandates coding standards and rules.
CWE-73prevents — Secure development lifecycle mandates input validation and path-handling controls that directly prevent external file/path manipulation.
CWE-733prevents — Secure SDLC requires compiler and build-process controls that can prevent optimization removal of security code.
CWE-74prevents — Secure development life cycle mandates input validation and output encoding that directly prevent injection flaws.
CWE-749prevents — Secure development life cycle requires removal or protection of dangerous APIs during design and coding.
CWE-75prevents — Secure development life cycle mandates input validation and sanitization practices that directly prevent special-element injection.
CWE-754prevents — Secure development life cycle mandates exception handling and input validation that directly prevent missing checks for unusual conditions.
CWE-755prevents — Secure SDLC mandates exception-handling requirements and testing that directly prevent improper handling of exceptional conditions.
CWE-756prevents — Secure development lifecycle includes error-handling standards that reduce exposure of sensitive data via default error pages.
CWE-757prevents — Secure SDLC practices include selecting strong crypto algorithms during design and implementation.
CWE-758prevents — Secure development life cycle requires defined, portable coding practices that reduce reliance on undefined behavior.
CWE-759prevents — Secure SDLC processes can include password-handling rules but do not guarantee salted hashes.
CWE-76prevents — Secure development life cycle mandates input validation and neutralization of all equivalent special elements.
CWE-760prevents — Secure development life cycle includes secure coding practices that would catch predictable-salt usage during design and implementation.
CWE-761prevents — Secure SDLC processes reduce the likelihood of such memory-management errors but do not specifically address them.
CWE-762prevents — Secure development lifecycle mandates consistent allocation/deallocation patterns that prevent mismatched memory routines.
CWE-763prevents — Secure SDLC practices can mandate proper memory-management APIs and reviews that catch incorrect deallocation.
CWE-764prevents — Secure development lifecycle practices can include concurrency and locking guidelines that reduce the risk of multiple-lock defects.
CWE-765prevents — Secure development lifecycle practices can include resource-locking discipline and review to prevent multiple-unlock defects.
CWE-767prevents — Secure development life cycle mandates encapsulation and access-control design practices.
CWE-768prevents — Secure SDLC practices can include code-review rules that catch short-circuit side-effect bugs.
CWE-77prevents — Secure development life cycle mandates input validation and command construction practices that directly prevent command injection.
CWE-771prevents — Secure development lifecycle practices can include resource-management rules that prevent missing references.
CWE-772prevents — Secure-SDLC practices include resource-management reviews, yet the control covers the entire lifecycle, not just this weakness.
CWE-774prevents — Secure development lifecycle requires resource-limit checks during design and coding.
CWE-775prevents — Secure SDLC practices can require resource-release reviews, yet the control is broader than this single weakness.
CWE-776prevents — Secure SDLC mandates input validation and parser hardening that can prevent unbounded entity expansion.
CWE-782prevents — Secure development lifecycle includes design-time access-control requirements for device interfaces.
CWE-783prevents — Secure development lifecycle includes code review and testing that can catch precedence errors.
CWE-786prevents — Secure development lifecycle includes buffer-boundary checks that reduce out-of-bounds reads before buffer start.
CWE-787prevents — Secure development life cycle mandates practices that prevent out-of-bounds writes.
CWE-788prevents — Secure development life cycle includes buffer-handling practices that reduce out-of-bounds accesses.
CWE-789prevents — Secure development lifecycle includes input validation and size checks that prevent unbounded allocations.
CWE-79prevents — Requiring language-specific secure-coding standards and automated scanning during the SDLC catches missing output encoding or improper neutralization of untrusted data before the software reaches production.
CWE-790prevents — Secure development life cycle mandates input validation and sanitization that directly prevents improper filtering of special elements.
CWE-791prevents — Secure development life cycle processes include validation activities that reduce the likelihood of CWE-791 but do not specify the control itself.
CWE-792prevents — Secure development lifecycle mandates input validation and sanitization that directly prevents incomplete filtering of special elements.
CWE-794prevents — Secure development lifecycle mandates input validation and sanitization that directly addresses incomplete filtering of special elements.
CWE-80prevents — Secure SDLC mandates input validation and output encoding that directly prevent basic XSS.
CWE-805prevents — Secure development life cycle mandates buffer-safety practices that directly prevent incorrect length values.
CWE-81prevents — Secure development life cycle mandates input validation and output encoding that directly prevent unneutralized script in error pages.
CWE-820prevents — Secure SDLC practices can mandate concurrency controls and synchronization primitives.
CWE-821prevents — Secure SDLC practices include concurrency and synchronization requirements that reduce race conditions.
CWE-822prevents — Secure development lifecycle includes pointer-safety practices that reduce untrusted pointer dereference risk.
CWE-823prevents — Secure SDLC mandates input validation and bounds checking that can prevent out-of-range pointer offsets.
CWE-824prevents — Secure development life cycle mandates practices that reduce uninitialized pointer defects.
CWE-825prevents — Secure development lifecycle practices can include pointer lifetime and memory-management rules that reduce expired-pointer dereferences.
CWE-826prevents — Secure development lifecycle practices can include resource-lifetime checks that reduce premature-release defects.
CWE-827prevents — Secure development lifecycle mandates input validation and external-entity restrictions that directly prevent unsafe DTD references.
CWE-828prevents — Secure development life cycle requires safe coding practices that can prevent non-reentrant signal handlers.
CWE-83prevents — Secure SDLC mandates input validation and output encoding that directly prevents script injection in HTML attributes.
CWE-832prevents — Secure development lifecycle practices can include concurrency and locking rules that prevent unlock-without-lock errors.
CWE-833prevents — Secure development lifecycle requires deadlock analysis and avoidance techniques during design and coding.
CWE-834prevents — Secure development lifecycle requires input validation and loop bounds, directly limiting excessive iteration.
CWE-835prevents — Secure development life cycle mandates practices that can detect and prevent infinite-loop defects.
CWE-837prevents — Secure SDLC practices can require design controls for single-use actions, but the control addresses the entire lifecycle.
CWE-838prevents — Secure development life cycle requires encoding-aware output handling, but does not mandate context-specific encoding checks.
CWE-839prevents — Secure development life cycle mandates input validation and boundary checks that would catch missing minimum-range verification.
CWE-84prevents — Secure development life cycle incorporates the above controls, providing indirect but systematic coverage.
CWE-841prevents — Secure development lifecycle requires explicit workflow enforcement in multi-step processes.
CWE-843prevents — Secure SDLC mandates type-safe design and review that can catch type-confusion flaws.
CWE-86prevents — Secure development life cycle mandates input validation and sanitization that directly prevents improper neutralization of invalid characters in identifiers.
CWE-862prevents — Security checkpoints and explicit authorization requirements in the design phase ensure that every sensitive function is paired with an access-control check, reducing missing-authorization defects.
CWE-87prevents — Secure SDLC mandates input validation and output encoding that directly prevent alternate XSS syntax.
CWE-88prevents — Secure development lifecycle mandates input validation and command construction practices that directly prevent argument injection.
CWE-89prevents — Secure-coding rules and security testing phases mandate the use of parameterized queries or equivalent escaping, preventing the construction of dynamic SQL statements from untrusted input.
CWE-90prevents — Secure development lifecycle mandates input validation and query construction practices that directly prevent LDAP injection.
CWE-908prevents — Secure development life cycle mandates initialization checks and static analysis that can catch uninitialized resource use.
CWE-909prevents — Secure development life cycle mandates initialization of resources before use.
CWE-91prevents — Secure SDLC mandates input validation and output encoding that directly prevent XML injection.
CWE-910prevents — Secure development lifecycle practices can include resource-cleanup rules that reduce use-after-close errors.
CWE-911prevents — Secure development lifecycle practices can include reference-counting rules and automated checks that reduce the likelihood of improper updates.
CWE-912prevents — Secure development life cycle mandates documented requirements and design reviews that would expose undocumented hidden functionality.
CWE-913prevents — Secure development lifecycle mandates controls on dynamic code generation and resource management.
CWE-914prevents — Secure development lifecycle requires input validation and variable handling rules that reduce dynamic-variable misuse.
CWE-915prevents — Secure development lifecycle requires input validation and object-property whitelisting that directly mitigates mass-assignment risks.
CWE-917prevents — Secure SDLC mandates input validation and output encoding that directly prevent expression-language injection.
CWE-93prevents — Secure development lifecycle mandates input validation and output encoding that directly prevents CRLF injection.
CWE-941prevents — Secure SDLC practices can catch destination errors during design, but coverage is indirect.
CWE-943prevents — Secure development life cycle mandates input validation and query parameterization that directly prevent injection flaws.
CWE-95prevents — Secure development life cycle mandates input validation and safe coding practices that directly prevent eval injection.
CWE-96prevents — Secure development life cycle mandates input validation and sanitization that directly prevents static code injection.
CWE-97prevents — Secure SDLC mandates input validation and output encoding that directly prevent SSI injection.
CWE-98prevents — Secure development lifecycle mandates input validation and safe include/require patterns that directly prevent remote file inclusion.
CWE-99prevents — Secure SDLC mandates input validation and resource-identifier sanitization that directly prevents resource injection.

Mitigated MITRE ATT&CK techniques (358)

Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

T1001.003←M T1006←M T1027→P T1027.001←M T1027.002←M T1027.004→P T1027.006←M →P T1027.007←M →P T1027.008←M T1027.009←M →P T1027.010←M →P T1027.011←P T1027.014←M →P T1027.016←M →P T1027.017→P T1027.018←M →P T1036.002→P T1036.003←M T1036.004→P T1036.005←M T1036.008←M →P T1036.009←P T1037→P T1037.001→P T1037.003→P T1037.004→P T1053→P T1053.007→P T1055←M →P T1055.001←M →P T1055.002←M T1055.003←M →P T1055.004←M →P T1055.005←M T1055.008←M T1055.009←M →P T1055.011←M →P T1055.012←M T1055.013←M →P T1055.014←M T1055.015←M T1056.003→P T1059→P T1059.001→P T1059.002→P T1059.004→P T1059.005→P T1059.006→P T1059.007→P T1059.008→P T1059.010→P T1059.011→P T1059.013→P T1068←M →P T1071.004←M T1072→P T1078←P T1078.001→P T1078.002→P T1078.004→P T1080→P T1098.005←P T1098.006→P T1110.001→P T1110.004→P T1127←M →P T1127.001←M →P T1127.002→P T1127.003→P T1129→P T1134←P T1134.004←P T1136→P T1137→P T1137.001→P T1137.002→P T1137.003→P T1137.004→P T1137.005→P T1137.006→P T1176→P T1176.001→P T1176.002→P T1185→P T1189→P T1190→P T1195→P T1195.001←M →P T1195.002←P →P T1202←M →P T1203←M →P T1204.002→P T1204.003→P T1204.005←P →P T1207←M T1210→P T1211←P →P T1212→P T1213.001→P T1213.003→P T1216←M →P T1216.001←M →P T1218←M →P T1218.001→P T1218.003→P T1218.004→P T1218.005←M →P T1218.007←M T1218.008←M →P T1218.009→P T1218.010←M T1218.011←M →P T1218.012→P T1218.013←M T1218.014→P T1218.015→P T1219.001→P T1219.003←M T1220←P →P T1221←M →P T1222←P T1480.001←M T1484←P T1484.002←P T1485→P T1495→P T1497←P →P T1497.002←M T1498.002→P T1499→P T1499.002→P T1499.003→P T1499.004→P T1505→P T1505.001→P T1505.002→P T1505.003→P T1505.004→P T1525→P T1528→P T1535←M T1537←M T1539←M T1542←M T1542.002←M →P T1543→P T1543.001→P T1543.002→P T1543.003→P T1543.004→P T1543.005→P T1546→P T1546.002→P T1546.003→P T1546.004→P T1546.005→P T1546.006→P T1546.008→P T1546.009→P T1546.010→P T1546.011→P T1546.012→P T1546.013→P T1546.014→P T1546.015→P T1546.016→P T1546.018→P T1547→P T1547.001→P T1547.004→P T1547.006→P T1547.007→P T1547.008→P T1547.009→P T1547.010→P T1547.012→P T1547.013→P T1548→P T1548.001←P →P T1548.003→P T1548.004→P T1548.005→P T1548.006→P T1550←M T1550.001←M T1550.002←F T1550.003←M T1550.004←F T1552→P T1552.001→P T1552.007→P T1553→P T1553.001←M T1553.002←P T1553.003←M →P T1553.004←P T1553.005←M T1553.006←P T1554→P T1556→P T1556.003→P T1556.004→P T1556.005→P T1556.007←P →P T1556.009←M T1559.002→P T1559.003→P T1564.007→P T1564.009→P T1565→P T1565.001→P T1565.002→P T1565.003→P T1569→P T1571←M T1574←M →P T1574.001←M →P T1574.004←M →P T1574.005←P →P T1574.006→P T1574.007→P T1574.008←P →P T1574.009←P →P T1574.010→P T1574.011→P T1574.012→P T1574.013←M →P T1574.014→P T1578←P T1578.001←M T1578.002←M T1578.003←P T1578.004←M T1578.005←P T1587.004→P T1588.005→P T1599←M T1600←P →P T1600.001→P T1601→P T1601.001←P →P T1601.002←P T1606.001→P T1610←P →P T1611←M →P T1612←M →P T1620←M →P T1621←P T1622←P →P T1647←P T1648→P T1649→P T1671→P T1677←M →P T1678←M T1685←P T1685.002←M →P T1685.003←M T1687←P →P T1688←M T1689←P →P

Why these map — AI rationale (under review)

T1027prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans and penetration tests, developer training on preventing/fixing vulnerabilities) that reduce the likelihood of introducing or retaining the kinds of obfuscation techniques adversaries rely on in custom code or builds; this is a genuine but minority slice of T1027, which is dominated by runtime, post-compromise, or non-custom-payload usage across platforms.
T1027.004detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface the presence of uncompiled source-code payloads or anomalous compilation activity during the SDLC, but this is limited to development/test environments and does not broadly detect the technique at runtime on victim systems across Linux/macOS/Windows.
T1027.004prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop delivery of uncompiled source-code payloads by catching or blocking insecure development/outsourcing that would produce or accept them, but this is only a slice of the technique's full scope (e.g., adversary post-compromise actions, phishing delivery, or runtime compilation on victim systems).
T1027.006prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop HTML smuggling code from being introduced in developed web-facing software, but this is only a slice of the technique's attack surface (e.g., does not address adversary-controlled HTML delivered to end-user clients or non-development vectors).
T1027.007prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, developer training on preventing/finding/fixing vulnerabilities, security testing including code scans) that can stop this obfuscation technique from being introduced in first-party or supplier-developed malware, but leaves the bulk of in-the-wild adversary malware untouched.
T1027.009prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security testing including code scans and penetration tests, developer training on preventing/fixing vulnerabilities) that can stop embedding of malicious payloads during development of first-party or supplied software, but this is only a slice of the technique which also covers adversary post-compromise abuse of benign third-party files and binaries at runtime.
T1027.010prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, developer training on preventing/fixing vulnerabilities, security testing including code scans) that reduce the chance of introducing or retaining command-obfuscation patterns in delivered payloads and scripts; this is a genuine but minority slice of the technique, which also covers interactive adversary use post-compromise and evasion of runtime detection.
T1027.014prevents — A.8.25 mandates secure-SDLC practices (secure coding guidelines, security testing including code scans and penetration tests, developer training on preventing/finding/fixing vulnerabilities) that can stop polymorphic code from being introduced in first-party or supplier-controlled software; this is only a slice of the technique, which is predominantly an adversary post-compromise runtime-evasion method applied to already-built malware on Linux/macOS/Windows.
T1027.016prevents — A.8.25 mandates secure SDLC practices including secure coding guidelines, security testing (code scans, penetration tests), and developer training on preventing/fixing vulnerabilities, which can stop junk code insertion from being introduced in first-party or contracted development; it does not address adversary use of the technique on existing third-party malware.
T1027.017detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that can surface SVG smuggling (malicious script/XML in image-like files) during development, but this is limited to the SDLC testing slice and does not address post-deployment or runtime detection of the technique.
T1027.017prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, and developer training on preventing/fixing vulnerabilities) that can catch or block SVG smuggling during development of the affected software, but does not guarantee coverage of all such defects or block the technique at runtime in already-deployed code.
T1027.018detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that can surface hidden Unicode abuse in source or scripts, but the control is a process framework whose actual detection coverage depends on which tools and rules the implementer selects.
T1027.018prevents — A.8.25 mandates secure SDLC practices including secure coding guidelines, security testing (code scans, penetration tests), and developer training on preventing/fixing vulnerabilities, which can catch or block invisible Unicode obfuscation during development; however, it is a process requirement whose effectiveness depends on implementation rigor and does not guarantee detection of all such evasion in every language, tool, or outsourced component.
T1036.002prevents — A.8.25 mandates secure SDLC practices including secure coding guidelines, security testing (code scans, penetration tests), and developer training on preventing/fixing vulnerabilities, which can stop RTLO-based filename disguises from being introduced or surviving into production; this is only a slice of the technique because it is limited to in-house/outsource development pipelines and does not constrain adversary use of RTLO on already-deployed systems, in phishing, or in non-software artifacts such as registry entries.
T1036.004prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, developer training) that reduce the chance a developer will implement a masquerading task/service, but does not stop an already-compromised or maliciously-introduced binary from renaming itself post-deployment.
T1036.008prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans and penetration tests, developer training on preventing/fixing vulnerabilities) that can stop developers from introducing or accepting masquerading file-type tricks in delivered code or systems; this is a genuine but minority slice of the technique, which is predominantly an operational/adversary post-exploitation behavior on existing binaries rather than a first-party development defect.
T1037prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing, developer training and vulnerability handling) that reduce the chance a developer will introduce or leave in place a boot/logon script that an adversary can abuse for persistence or privilege escalation; this is a genuine but minority slice of the technique, which also covers legitimate admin scripts, remote application, and post-deployment abuse of existing scripts.
T1037.001prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing, developer training) that can stop the insecure coding pattern allowing logon-script persistence from being introduced during development of in-house or custom software.
T1037.003prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing, developer training and vulnerability handling) that can stop malicious or vulnerable logon scripts from being introduced during in-house or outsourced development of the systems that consume or enforce those scripts.
T1037.004prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing, developer training and vulnerability handling) that can stop malicious or vulnerable changes to RC scripts from being introduced during development of affected Unix-like software, systems or firmware; this is only a slice of the technique because the control does not constrain post-deployment modification of RC files on running systems, nor does it reach every platform or legacy/deprecated RC usage.
T1053prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, developer training) that can stop developers from introducing scheduled-task abuse patterns during custom software or system builds; this is a genuine but minority slice of T1053 (which is mostly about post-compromise abuse of OS utilities by already-present malware or admins, not defects introduced in development).
T1053.007prevents — A.8.25 mandates secure SDLC practices (secure requirements, checkpoints, secure coding, testing including scans/pen-tests, developer training) that can catch and stop malicious container-orchestration-job logic before it reaches production, but this is only a slice of the technique (custom malicious jobs) while legitimate CronJob scheduling mechanisms and post-deployment abuse remain outside its direct scope.
T1055detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface process-injection weaknesses during development, but this is limited to pre-deployment discovery of custom code and does not address runtime detection of live injection on deployed systems
T1055prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security testing including code scans and penetration tests, developer training on preventing/fixing vulnerabilities) that reduce the likelihood of introducing the coding patterns and legitimate-functionality abuses that enable process injection techniques.
T1055.001prevents — A.8.25 mandates secure-SDLC practices (secure coding, testing, checkpoints, developer training) that can stop injection-vulnerable code from being written or deployed; this is a genuine but minority slice of the technique, which lives primarily in runtime process manipulation rather than in development defects.
T1055.003detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface process-injection defects such as thread hijacking during development; this is genuine but only a slice because the control is scoped to the SDLC and does not mandate runtime/operational detection of the live technique.
T1055.003prevents — A.8.25 mandates secure-SDLC practices (secure coding, security requirements, testing including code scans and penetration tests, developer training) that reduce the chance of introducing the memory-management and process-handling flaws an adversary exploits to perform thread hijacking; this is a genuine but minority slice of the technique's surface, so partial.
T1055.004prevents — A.8.25 mandates secure-SDLC practices (secure coding guidelines, security testing including code scans and penetration tests, developer training on preventing/fixing vulnerabilities) that can stop APC-injection code from being introduced in the first place; this is a genuine but minority slice of the technique, which lives primarily in post-development runtime behavior on Windows rather than in the developed artifact.
T1055.009prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security testing including code scans and penetration tests, developer training on preventing/fixing vulnerabilities) that can stop proc-memory-injection flaws from being introduced in custom Linux software; this is only a slice because the technique can be used against third-party binaries, via runtime configuration, or in non-development contexts.
T1055.011prevents — A.8.25 mandates secure-SDLC practices (secure coding guidelines, security requirements, testing including code scans and penetration tests, developer training on preventing/fixing vulnerabilities) that can stop EWM injection from being introduced in first-party Windows code; it does not reach third-party components, runtime configuration of existing processes, or post-deployment technique variants.
T1055.013prevents — A.8.25 mandates secure-SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, developer training) that can stop the introduction of the specific TxF-abuse and memory-replacement logic required for Process Doppelgänging; this is a genuine but minority slice of the technique's surface because the control is development-process oriented and does not constrain runtime process-injection vectors or non-custom-code paths.
T1056.003prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, and developer training) that can stop the insertion of credential-capturing code into a web portal during development or maintenance, but this is only a slice: the technique can also be introduced post-compromise via admin access or initial exploitation of a running service without touching the SDLC.
T1059prevents — Enforcing secure coding standards and code reviews limits the introduction of command or scripting interpreter vulnerabilities that adversaries could later exploit for execution.
T1059.001prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans, developer training on preventing/fixing vulnerabilities) that can stop insecure PowerShell usage or custom scripts from being introduced during development of in-house software, but this does not prevent abuse of the built-in PowerShell interpreter or its DLL interfaces in deployed Windows environments or third-party code.
T1059.002prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop AppleScript abuse from being introduced into custom macOS software or scripts during development, but this is only a slice of the technique's attack surface (e.g., does not block adversary use of built-in osascript, NSAppleScript/OSAScript APIs, or third-party/legacy components).
T1059.004prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that reduce the likelihood of introducing code enabling Unix shell abuse (e.g., unsafe script execution, weak input handling in custom tools), but this is a minority slice of the technique's attack surface which is dominated by legitimate OS-provided shells and post-compromise abuse rather than preventable development flaws.
T1059.005prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans, developer training and vulnerability prevention/fixing capability) that directly target the introduction of unsafe VB/VBA/VBScript usage, reducing the chance adversaries can rely on such abused scripting for execution; it is only partial because the control is a process that depends on implementation rigour and does not eliminate all possible VB abuse vectors (e.g. in third-party or legacy components).
T1059.006prevents — A.8.25 mandates secure-SDLC practices (secure coding guidelines, security requirements, testing including code scans, developer training on preventing/fixing vulnerabilities) that can stop malicious Python from being introduced or made executable in developed software; this reaches only the slice of the technique that lives inside first-party development and does not constrain abuse of Python already present on target systems.
T1059.007prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that directly target the introduction of JS interpreter abuse paths and weak JS handling in developed software, but this only constrains custom first-party code and does not stop adversaries from abusing built-in platform JS runtimes (Node, JXA, JScript, osascript) or downloaded/obfuscated scripts.
T1059.008prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that reduce the chance of introducing CLI-abusable flaws or weak configurations during device firmware/OS development; this is a genuine but minority slice of the technique, which also covers post-deployment abuse of intended CLI features on already-secure devices.
T1059.010prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop malicious or vulnerable AutoHotKey/AutoIT scripts from being introduced during in-house or outsourced development, but this is only a slice of the technique (adversary use of existing legitimate interpreters or pre-compiled .exe payloads on victim systems is untouched).
T1059.011prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans, developer training on preventing/fixing vulnerabilities) that can stop Lua interpreters from being embedded or exposed in a way that enables the technique, but this is only a slice of the attack surface (e.g., does not address pre-existing interpreters on platforms, runtime abuse of legitimate ones, or non-development environments).
T1059.013prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that can stop insecure container images or misconfigured orchestration from reaching production, blocking many avenues for T1059.013; it does not address runtime CLI/API abuse of already-deployed legitimate containers.
T1068detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface exploitable vulnerabilities (including those usable for privilege escalation) before or after deployment; this is genuine but only a slice of the full technique surface (e.g., zero-days, BYOVD drivers brought post-compromise, or runtime exploitation without prior scan coverage).
T1068prevents — A.8.25 mandates secure-SDLC practices (secure requirements, secure coding guidelines, checkpoints, testing including scans/pen-tests, developer training on preventing/fixing vulns) that reduce the likelihood of introducing the exploitable programming errors T1068 relies on; it does not guarantee their absence and leaves a slice of 0-days, BYOVD, and post-deployment vulns unaddressed.
T1072prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that reduce the chance insecure deployment tools or their CI/CD integrations are built or configured with the exploitable flaws adversaries abuse for T1072; this is a genuine but minority slice of the technique, which also covers post-deployment abuse of legitimate tools via stolen credentials or misconfiguration.
T1078.001prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, checkpoints, secure coding, testing including scans/pen-tests, and developer training) that can prevent many default accounts from being introduced or left unchanged during development, integration, or deployment of software, systems, and services; however, this does not reach pre-existing defaults in COTS appliances, third-party firmware, or post-setup integrations outside the organization's development lifecycle.
T1078.002prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, developer training) that can prevent the introduction of flaws enabling credential compromise such as weak password handling or insecure credential storage, but does not address runtime credential dumping, password reuse, or operational abuse of already-compromised domain accounts.
T1078.004prevents — A.8.25 mandates secure SDLC practices (requirements, secure coding, checkpoints, testing, developer training) that can prevent the introduction of misconfigurations, weak role assignments, and insecure defaults enabling T1078.004 abuse, but does not address account creation hygiene, credential issuance, brute-force/phishing vectors, or runtime privilege assumptions outside the development lifecycle.
T1080prevents — A.8.25 mandates secure SDLC practices (secure coding, secure repositories, version control, security testing, developer training) that reduce the chance of introducing tainted/malicious content into shared code repositories or builds, but does not address network shares, binary infection of arbitrary files, or directory-share pivots outside the development lifecycle.
T1098.006prevents — A.8.25 mandates secure SDLC practices (secure requirements, checkpoints, secure coding, testing including scans/pen-tests, developer training on preventing/fixing vulns) that reach the design and implementation of authorization logic and RBAC/ABAC configuration in container orchestration systems, lowering the chance the flawed permission model enabling T1098.006 is introduced; it does not address runtime account/role manipulation after deployment or in cloud IAM layers.
T1110.001prevents — A.8.25 mandates secure-SDLC practices (secure coding, security requirements, testing, developer training) that can stop password-guessing vectors from being introduced during development of the targeted services and applications; this is a genuine but minority slice of the technique, which also succeeds against already-deployed, correctly-implemented authentication surfaces via weak/default credentials, policy gaps, or network exposure.
T1110.004prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, developer training) that can prevent the introduction of authentication weaknesses enabling credential stuffing success, but does not address credential reuse, rate limiting, MFA, or post-breach password changes that are the dominant factors in this technique.
T1127detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface misuse of trusted developer utilities during the SDLC, but does not mandate runtime detection of the technique post-deployment.
T1127prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, developer training) that reduce the chance of shipping or relying on vulnerable/trusted developer utilities that can be abused for proxy execution, but does not eliminate the class of signed dev tools or block their runtime abuse on production systems.
T1127.001detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that can surface malicious or anomalous use of MSBuild inline tasks during development, but this is limited to the SDLC phase and does not broadly detect post-deployment runtime abuse of the signed binary.
T1127.001prevents — A.8.25 mandates secure SDLC practices including secure coding guidelines, security requirements, checkpoints, testing (code scans, pentests), and developer training on preventing/fixing vulnerabilities, which can stop the insecure use of MSBuild inline tasks during development of custom software; it does not address abuse of the pre-existing signed MSBuild binary on already-deployed Windows systems.
T1127.002prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that can stop ClickOnce abuse from being introduced into first-party or in-house developed .NET applications, but does not constrain third-party ClickOnce usage, user execution, or deployment of existing malicious .appref-ms/.application files.
T1127.003prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans, developer training and vulnerability prevention/fixing capability) that reach the build process and can stop malicious .jam files or abuse from being introduced or executed in development; this is only a slice of the technique because it does not constrain all possible abuse vectors of a legitimate build utility on a compromised endpoint outside the SDLC.
T1129prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop insecure module loading or untrusted shared-object use from being introduced in developed software, but this is only a slice of the technique (which also covers adversary abuse of legitimate loaders at runtime on existing systems).
T1136prevents — A.8.25 mandates security requirements, checkpoints, secure coding, testing (including scans/pen tests), and developer training that can catch or block account-creation logic during the SDLC, but this is only a slice of the technique (e.g., custom backdoor accounts) while the bulk of T1136 (abusing legitimate admin privileges, cloud IAM, or post-compromise creation) lies outside development-time controls.
T1137prevents — A.8.25 mandates secure-SDLC practices (secure coding, security requirements, checkpoints, testing, developer training) that can stop the introduction of the Office-add-in/macro/template mechanisms abused by T1137; it does not reach every implementation path or legacy Office/365 configurations, leaving a genuine minority slice unaddressed.
T1137.001detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface malicious macros or template abuses in developed/persisted Office customizations; this is a genuine but minority slice of the technique (post-development detection only, no coverage of runtime Office startup, registry hijacks, or non-development vectors).
T1137.001prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans, developer training on preventing/fixing vulnerabilities) that can stop malicious macros from being inserted into Office templates during in-house or supplier development, but this is only a slice of the technique which is primarily post-compromise abuse of existing templates on an endpoint.
T1137.002prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that reach the class of persistence-via-registry-abuse during Office application development, but this is only a slice of the technique's attack surface (e.g., does not constrain post-compromise Registry writes by an already-running adversary).
T1137.003prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, developer training) that can stop custom malicious Outlook forms from being introduced in developed/customized software, but this is only a slice of the technique which also covers post-compromise abuse of existing Outlook forms on end-user systems.
T1137.004prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, and developer training) that can catch and stop the introduction of the custom code or configuration enabling this Outlook abuse during development, but only for in-house or assured outsourced software — it does not address adversary abuse of the pre-existing legacy feature in deployed Outlook/Office itself.
T1137.005prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, developer training) that can stop the introduction of the code/config allowing malicious Outlook rules to be set or triggered, but this is only a slice of the attack surface (e.g., does not constrain post-compromise abuse of existing rules by an adversary).
T1137.006prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing, developer training and vulnerability handling) that can stop malicious/persistence-enabling add-ins from being introduced during in-house or supplier development of Office-integrated software; this is only a slice of the technique, which also covers post-compromise abuse of existing legitimate add-ins or Office configuration on already-deployed systems.
T1176prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that reduce the chance of shipping vulnerable extension-hosting software or insecure marketplaces, but does not stop post-shipment abuse of extensions, social engineering, or already-compromised systems.
T1176.001prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that can stop malicious or vulnerable browser extensions from being introduced during in-house or outsourced development of the browser or its extensions, but this covers only a minority slice of the technique (custom-developed extensions) while leaving the dominant vectors (app-store masquerading, post-compromise file manipulation, social engineering, untrusted third-party extensions) untouched.
T1176.002detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests (plus secure repositories and version control), which can surface malicious or anomalous IDE extensions during development or in the build pipeline; this is a genuine but minority slice of the technique (post-install runtime abuse of benign extensions or side-loaded ones on end-user developer workstations falls outside the SDLC scope).
T1176.002prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that reduce the chance malicious or abused IDE extensions are introduced or trusted during development, but does not stop post-development side-loading, marketplace compromise, or benign-extension abuse on end-user systems.
T1185prevents — A.8.25 mandates secure-SDLC practices (secure requirements, secure coding guidelines, code scanning, penetration testing, developer training) that can stop injection of malicious browser extensions or vulnerable browser code before release; this is a genuine but minority slice of T1185 because the technique also covers post-release exploitation of inherent browser functionality, unpatched runtime vulnerabilities, and privilege requirements that live outside the development pipeline.
T1189prevents — A.8.25 mandates secure-SDLC practices (secure coding, security requirements, checkpoints, testing including code scans and pen tests, secure repositories) that reduce the chance a legitimate site or web app contains the XSS, script-injection or vulnerable-component flaws an adversary would exploit for drive-by compromise; this is a genuine but minority slice of the technique (most drive-by vectors involve adversary-controlled sites, malvertising, watering-hole targeting or client-side browser/plugin flaws outside the developer's SDLC).
T1190prevents — A.8.25 mandates secure-SDLC practices (requirements, secure coding, checkpoints, testing including scans/pen-tests, training) that reduce the likelihood of introducing the exploitable weaknesses (bugs, misconfigs) named by T1190, but does not guarantee their absence and leaves many post-deployment or non-development factors untouched.
T1195prevents — Requiring security checkpoints, testing, and secure repositories throughout the development lifecycle reduces the likelihood that an adversary can insert malicious code or components into software before it reaches production.
T1195detects — A.8.25 explicitly requires system/security testing including code scans, penetration tests and checkpoints that surface supply-chain manipulation of dev tools/environments, source repos, dependencies and updates; this is genuine but only a slice (e.g. does not cover physical shipment interdiction, factory-infected media or second-order compromises outside tested artifacts).
T1195.001detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface malicious or anomalous components in dependencies, dev tools, and CI/CD pipelines; this is genuine detection but only a slice of the full technique surface (e.g., pre-receipt supply-chain compromise of abandoned/typosquatted packages may evade testing).
T1195.001prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing, secure repositories, version control, developer training) that directly constrain many upstream supply-chain insertion vectors in T1195.001; the bounded remainder is that it cannot stop an already-compromised external dependency or abandoned package from being pulled in.
T1195.002prevents — A.8.25 mandates secure SDLC practices (secure coding, checkpoints, testing, version control, developer training) that directly reduce the chance an organization will ship manipulated source, builds or updates, but leaves open third-party/supply-chain manipulation before the organization receives the software and does not guarantee enforcement rigor.
T1202prevents — A.8.25 mandates secure SDLC practices including secure coding guidelines, security requirements, testing (code scans, penetration tests), and developer training that can prevent introduction of the insecure configurations or code patterns enabling indirect command execution utilities, but does not guarantee their absence in all software or block runtime abuse of existing legitimate binaries.
T1203prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training and vulnerability prevention/fixing capability) that directly target the unsecure coding practices named in T1203's description as the root cause of exploitable client-application vulnerabilities; this prevents many (but not all) such vulnerabilities from arising in in-house or supplier-developed software, leaving a remainder for third-party client apps and outsourced development where assurance is only obtained rather than enforced.
T1204.002prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that reduce the chance malicious files are introduced or made executable via development flaws, but does not stop user execution of externally supplied malicious files or block the social-engineering delivery vector itself.
T1204.003prevents — A.8.25 mandates secure SDLC practices (secure coding, security testing, checkpoints, developer training) that reduce the chance a malicious or backdoored image is introduced or trusted in the development pipeline, but does not stop users from pulling and running unvetted public/third-party images at runtime.
T1204.005detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface malicious or backdoored libraries in the developed codebase or dependencies, but does not mandate ongoing detection of malicious libraries installed from external repositories by end users or in runtime environments.
T1204.005prevents — A.8.25 mandates secure SDLC practices (secure coding, dependency handling via referenced 8.28/8.30, secure repositories, version control, and developer training) that can stop malicious libraries from entering approved codebases or being introduced via outsourced development, but leaves open user-side installation of unvetted public packages (e.g. via typosquatting on PyPI/NPM) outside the organization's SDLC.
T1210prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including scans/pen-tests, developer training and vulnerability prevention/fixing) that reduce the introduction or persistence of exploitable programming errors in developed software and services, directly lowering the chance T1210 can succeed against in-house or custom components; it is only partial because the technique also targets third-party/remote services (SMB/RDP/MySQL/VMware) whose vulnerabilities lie outside the organization's own SDLC.
T1211prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including scans/pen-tests, developer training) that reduce the introduction of exploitable vulnerabilities, including those that could be leveraged for stealth/evasion; this prevents a genuine slice of T1211 but leaves a bounded remainder (0-days, logic/design flaws outside tested paths, supply-chain code not fully covered by the org's process, and post-deployment vulns).
T1212prevents — A.8.25 mandates secure SDLC practices (secure requirements, checkpoints, secure coding guidelines, testing including scans/penetration tests, developer training) that reduce the likelihood of introducing the exploitable programming errors this technique relies on; it does not guarantee their absence or address already-shipped vulnerable software.
T1213.001prevents — A.8.25 mandates secure SDLC practices including secure repositories (8.4/8.9), version control (8.32), and security in development methodology (8.28), which directly constrain what sensitive material (e.g. credentials, architecture, source snippets) reaches a Confluence wiki in dev environments, preventing the technique from having anything valuable to mine; partial because the control is scoped to in-house/outsourced development processes and does not govern already-deployed Confluence instances or non-development uses of the platform.
T1213.003prevents — A.8.25 explicitly requires secure repositories for source code and configuration plus version-control security, which directly stops adversaries from gaining the initial access needed to collect from private/internal code repositories (the core of T1213.003); it does not address already-compromised credentials or post-access collection on SaaS platforms outside the organization's SDLC.
T1216prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that reduce the likelihood of introducing or retaining the signed/trusted proxy scripts (or equivalent logic) adversaries abuse for T1216; this is a genuine but minority slice of the class, as the dominant attack surface is pre-existing/default Microsoft-signed LOLBIN scripts outside the organization's development lifecycle.
T1216.001prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that reach the class of signed-script proxy-execution flaws when applied to custom or in-house code; the named remainder is built-in Microsoft scripts like PubPrn.vbs whose abuse lives outside the development lifecycle the control governs.
T1218prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing including code scans/penetration tests, developer training) that can stop many proxy binaries from being introduced or left exploitable in developed software, but does not address abuse of pre-existing trusted OS binaries (e.g. LOLBAS) or outsourced development without full enforcement.
T1218.001prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing including code scans/penetration tests, developer training) that can stop malicious or vulnerable CHM-handling code from being introduced during in-house or supplier development, but does not constrain adversary abuse of legitimate hh.exe/CHM functionality on end-user systems or unpatched legacy deployments.
T1218.003prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that reduce the likelihood of introducing the signed-binary abuse and INF-parsing flaws enabling T1218.003, but does not guarantee their absence or block runtime abuse of a legitimate signed binary.
T1218.004prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop insecure .NET binaries containing the RunInstaller attribute from reaching production, but does not address runtime proxy execution of a signed trusted utility or post-development deployment on Windows endpoints.
T1218.005detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface malicious or anomalous use of mshta.exe as a living-off-the-land binary during development and testing phases, but does not mandate runtime detection on production systems where the technique is typically observed.
T1218.005prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing including code scans/penetration tests, developer training) that can stop mshta.exe abuse from being introduced in custom-developed Windows software, but leaves the built-in trusted utility and its bypass potential untouched in the OS itself.
T1218.008prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that reduce the chance of introducing or retaining living-off-the-land binaries whose abuse was not accounted for in application control; this is a genuine but minority slice of the technique, which lives primarily in post-build bypass of existing controls rather than in the development process itself.
T1218.009prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop the insecure .NET code containing the [ComRegisterFunction] or [ComUnregisterFunction] attributes from being written and deployed, but this is only a slice of the technique's attack surface (e.g., does not address abuse of already-compiled signed Microsoft binaries or non-development vectors).
T1218.011prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop many classes of malicious code that would be loaded via rundll32, but does not address the Windows-signed binary itself, its legitimate use for proxying, or the post-development runtime abuse vectors.
T1218.012prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop the insecure design/implementation allowing verclsid.exe abuse as a signed proxy, but this is only one slice of a Windows binary-abuse technique that also involves runtime configuration, COM registry entries, and post-development deployment choices outside the SDLC.
T1218.014prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, and developer training) that can stop the introduction of the insecure design/implementation flaws (e.g., unsafe .msc handling, COM/CLSID registration, or snap-in loading) enabling this technique, but only for in-house or assured outsourced development and leaves a large remainder for pre-existing OS components and third-party tools.
T1218.015prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop Electron-specific abuses like planting malicious JS or unsafe command execution during app development, but this is only a slice — the technique also applies to abusing existing legitimate Electron apps post-development where the control has no reach.
T1219.001detects — A.8.25 mandates security testing, code scans, penetration tests, and checkpoints that can surface anomalous IDE tunneling or related misconfigurations during development and review, but this is limited to the development process and does not broadly detect in-production or post-deployment adversary use of IDE tunneling for C2 or persistence.
T1219.001prevents — A.8.25 mandates secure SDLC practices including secure coding guidelines, security requirements, checkpoints, testing (scans/pen tests), developer training and vulnerability prevention/fixing capability; these can stop insecure IDE/remote tunneling features or extensions from being introduced or left exploitable in developed software, but the technique is an adversary abuse of legitimate developer tools post-compromise on running systems and the control reaches only the development slice, not runtime or configuration of existing IDEs.
T1220prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop XSL script abuse from being introduced in custom software; it does not constrain the built-in Windows tools or adversary use of them on existing systems.
T1221detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface template-injection flaws during development; this is genuine but only a slice (pre-release custom code), as the technique is also used in delivered Office/RTF documents and post-deployment phishing vectors outside the SDLC testing scope.
T1221prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, and developer training on preventing/fixing vulnerabilities) that can stop template-injection flaws from being introduced in custom code or document-handling features; this reaches only a slice of the technique, which also targets unmodified third-party Office/RTF parsers, user documents, and delivery vectors outside the development lifecycle.
T1485recovers — A.8.25 mandates secure SDLC practices (including backups via referenced 8.13/8.31 and secure repositories/version control) that enable recovery from data destruction in developed systems, but does not itself perform recovery and leaves gaps for non-development assets and post-compromise execution of T1485.
T1495prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, coding guidelines, testing including code scans/penetration tests, checkpoints, and developer training) that can stop insecure firmware update or boot processes from being introduced during development of affected devices or software loaders, but this is only a slice of T1495 vectors (e.g., does not address post-deployment supply-chain implants, physical attacks, or already-shipped vulnerable firmware on Linux/Windows/network devices).
T1497prevents — A.8.25 mandates secure SDLC practices including secure coding guidelines, security testing (code scans, penetration tests), developer training on preventing/fixing vulnerabilities, and secure repositories/version control, all of which can stop evasion checks and sandbox-aware logic from being introduced into malware during development.
T1498.002detects — A.8.25 mandates security testing including code scans, penetration tests and checkpoints that can surface misconfigurations or vulnerable services enabling reflection/amplification (e.g. exposed NTP/DNS/memcache), but this is only one slice of the SDLC and does not broadly instrument runtime network detection of the technique itself.
T1499prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, coding guidelines, testing including code scans/penetration tests, checkpoints) that can prevent many endpoint DoS weaknesses arising from implementation flaws in the application/OS layers, but leaves open the bulk of the technique (botnets, spoofing, resource exhaustion from external scale, or non-development issues in deployed services)
T1499.002prevents — A.8.25 mandates secure SDLC practices (secure design, coding guidelines, security testing, checkpoints) that can prevent vulnerable service implementations enabling exhaustion floods (e.g., missing rate limits, inefficient SSL renegotiation handling), but this is only a slice of the technique's surface (runtime config, resource limits, network-level volume) and does not stop all instances.
T1499.003prevents — A.8.25 mandates secure SDLC practices (requirements, secure coding, checkpoints, testing including scans/penetration tests) that can identify and eliminate resource-exhaustion flaws during development, preventing the technique from being present in the resulting application; this is only a slice because the control is process-oriented, does not guarantee complete coverage of all features or runtime behaviors, and leaves residual risk in deployed or third-party applications.
T1499.004detects — A.8.25 explicitly requires system/security testing including code scans, penetration tests and checkpoints that surface exploitable vulnerabilities (known or zero-day) before or after deployment, but this is only one slice of the control whose primary purpose is secure design and development rather than ongoing detection of in-the-wild exploitation.
T1499.004prevents — A.8.25 mandates secure-SDLC practices (secure requirements, checkpoints, secure coding, testing including scans/pen-tests, developer training) that reduce the introduction and survival of the exploitable crash vulnerabilities named by T1499.004; it does not guarantee their complete absence.
T1505prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing, developer training) that reduce the chance of shipping extensible server features whose legitimate developer interfaces can be abused for persistence; this is a genuine but minority slice of the technique, which also covers post-shipment installation of malicious components on already-deployed servers.
T1505.001prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training and vulnerability prevention/fixing) that reach the custom code and CLR assemblies an adversary would craft or modify for malicious stored procedures, but does not constrain the database engine features (xp_cmdshell, CLR integration, auto-start procedures) or configuration that enable the persistence technique itself.
T1505.002prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing, developer training) that reach the custom code an adversary would write and register as a malicious transport agent, but leaves a bounded remainder: the technique can still be introduced via misconfigured or vulnerable third-party/outsourced components, Exchange itself, or post-deployment registration that bypasses the development pipeline.
T1505.003prevents — Security testing, code scanning, and secure repositories make it more difficult for adversaries to implant web shells during the development or deployment of web applications.
T1505.003detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface web shells or the insecure code/config that enables them post-deployment or in the SDLC; this is genuine but only a slice because the clause is primarily about building secure software (prevention via process) rather than mandating ongoing runtime detection of deployed adversary web shells.
T1505.004prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, developer training) that reduce the chance a malicious or vulnerable IIS component is introduced during development of in-house or supplier software; this is a genuine but minority slice of the technique, which is overwhelmingly about post-compromise installation of already-malicious DLLs/modules on a running production IIS server rather than defects introduced in the development lifecycle.
T1525detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface malicious implants or backdoors in images built or stored in secure repositories during the SDLC, but does not address detection of already-deployed or runtime-modified images in a live registry after the development phase
T1525prevents — A.8.25 mandates secure SDLC practices (secure coding, security testing, checkpoints, developer training) that can catch and stop malicious modifications to images during build or CI/CD pipelines, but does not address post-deployment registry tampering, compromised instances with image-listing perms, or non-development image management.
T1528prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, secure repositories/version control, and developer training on preventing/fixing vulnerabilities) that reduce the likelihood of introducing the insecure token handling, storage, or OAuth flows that enable T1528, especially in CI/CD and containerized development; it does not address runtime compromise, social engineering, or post-deployment token theft vectors.
T1542.002prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that reach the firmware-development slice of T1542.002 but leave the bulk (supply-chain compromise of already-shipped components, non-software firmware flashing, and post-deployment modification) untouched.
T1543prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that reduce the chance a developer will introduce or accept a malicious/persistence-enabling service or daemon during legitimate development or maintenance; this is a genuine but minority slice of T1543, which is overwhelmingly realized post-compromise by already-present malware rather than during in-house development.
T1543.001prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing, developer training) that can stop a developer from intentionally or accidentally introducing a malicious launch agent during in-house software development, but this is only a slice of the technique which is predominantly post-compromise persistence by an already-present adversary on macOS.
T1543.002prevents — A.8.25 mandates secure SDLC practices including secure coding, security requirements, checkpoints, testing (scans/penetration), and developer training that can catch or block unsafe service modifications during development of custom software or systemd generators, but does not stop post-deployment adversarial creation or modification of .service files on production Linux systems.
T1543.003prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, developer training) that reduce the chance of introducing the vulnerable code or misconfigurations adversaries exploit to create/modify Windows services for persistence.
T1543.004prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that can prevent many implementation flaws enabling Launch Daemon abuse (e.g., poor config, insecure defaults, vulnerable code), but does not address runtime OS configuration, privilege escalation, or post-deployment persistence vectors on macOS.
T1543.005prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, checkpoints, testing, secure coding, developer training) that can stop insecure container service configurations or modifications from being introduced during development or deployment of containerized systems, but leaves a large remainder of post-deployment runtime abuse, privilege escalation via existing tools like docker/podman/kubelet, and adversary modifications outside the development lifecycle.
T1546prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, developer training) that reduce the likelihood of introducing the flawed event-trigger mechanisms or backdoors adversaries abuse for T1546, but does not guarantee their absence and leaves many post-compromise modification vectors untouched.
T1546.002detects — A.8.25 explicitly requires system and security testing including code scans and penetration tests that surface malicious or anomalous screensaver configurations and registry manipulations during development and evaluation, but does not mandate runtime detection of deployed instances
T1546.002prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, developer training) that can stop malicious screensaver code from being introduced during in-house or outsourced development, but this is only a slice of the technique which also covers post-deployment registry manipulation of existing legitimate screensavers.
T1546.003detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface malicious or anomalous WMI subscriptions during development, but does not mandate runtime detection of deployed technique use.
T1546.003prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, developer training) that can catch and stop malicious WMI subscription code from being introduced during in-house development, but this is only a slice of the technique's attack surface (e.g., does not block post-deployment abuse, compiled MOFs, or outsourced development without full assurance).
T1546.004prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing, developer training and vulnerability prevention/fixing) that can stop malicious shell-configuration modifications from being introduced during in-house or outsourced development of the affected software or systems; this is only a slice of the technique, which is predominantly an post-deployment administrative/persistence abuse that does not require new development.
T1546.005prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, and developer training on preventing/fixing vulnerabilities) that can stop trap-based persistence from being introduced in custom scripts or software during development.
T1546.006detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that can surface tainted Mach-O binaries or malicious LC_LOAD_DYLIB additions during development, but this is limited to the SDLC phase and does not address post-deployment or runtime detection of the technique.
T1546.006prevents — A.8.25 mandates secure-SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop the insecure binary modification step during development or outsourced build, but this is only a slice of the weakness class because the technique can still be applied post-build or to third-party/legacy binaries outside the organization's SDLC.
T1546.008prevents — A.8.25 mandates secure-SDLC practices (secure requirements, design checkpoints, secure coding, testing including code scans/penetration tests, and developer training) that can stop the insecure design and implementation steps needed to introduce this technique; it does not reach already-deployed systems or non-development vectors such as direct Registry/binary replacement on production hosts.
T1546.009prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, developer training) that can stop the introduction of the vulnerable registry configuration or the malicious DLL itself during in-house or contracted development; this is a genuine but minority slice of the technique, which is most often realized post-deployment via direct registry abuse rather than through flawed development.
T1546.010prevents — A.8.25 mandates secure-SDLC practices (secure coding guidelines, security requirements, testing including code scans and pen tests, developer training on preventing/fixing vulnerabilities) that can stop the insecure coding or configuration enabling AppInit_DLLs abuse during development of affected Windows software; it does not reach already-shipped products, non-development mitigations like secure boot, or runtime configuration changes.
T1546.011prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop malicious shim creation or abuse during in-house or outsourced development, but this is only a slice of the technique's attack surface (e.g., post-deployment admin-level installation, legacy OS shims, or non-development abuse vectors).
T1546.012prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop developers from introducing IFEO-based persistence or privilege-escalation mechanisms during software development, but this only reaches the subset of the technique introduced by in-house or supplier code under the SDLC and does not block adversary abuse of existing OS IFEOs or registry modifications outside development.
T1546.013prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans, developer training and vulnerability prevention/fixing) that can stop malicious profile modifications from being introduced during development of PowerShell-using software or systems; this is only a slice of the technique, which also occurs at runtime via direct profile tampering on deployed Windows systems outside any SDLC.
T1546.014prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, secure repositories/version control, and developer training) that can stop malicious emond rule files from being introduced during macOS software development or configuration, but this is only a slice of the technique's attack surface since rules can be written post-deployment by admins or via other vectors outside the SDLC.
T1546.015detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface registry-tampering or anomalous COM behavior introduced during development; this catches developer-introduced or supply-chain variants of the technique but does not address post-deployment runtime hijacks or adversary modifications outside the SDLC.
T1546.015prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop the insecure registry-modifying code patterns enabling COM hijacking from being introduced during development of in-house or supplier software; it does not reach adversary post-compromise registry changes to existing systems or third-party components.
T1546.016prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security testing including code scans and pen tests, developer training on preventing/fixing vulnerabilities, and secure repositories/version control) that reach the class of malicious or vulnerable installer scripts; this lowers the chance such content is introduced or survives to deployment, but the control is a process requirement whose effect depends on implementation rigor and does not guarantee every installer package is hardened against post-install or maintainer-script abuse.
T1546.018prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans, developer training and vulnerability prevention/fixing capability) that can stop the introduction of Python startup-hook persistence mechanisms during development; it reaches only a slice because the technique can also be introduced post-development via package installation, configuration changes or supply-chain compromise outside the organization's own SDLC.
T1547prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, coding guidelines, checkpoints, testing including code scans/penetration tests, and developer training) that can stop insecure autostart/boot mechanisms from being introduced during development of the affected software or systems, but this is only a slice of T1547 which also covers post-compromise configuration changes and kernel modifications on already-deployed systems.
T1547.001prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing, developer training and vulnerability handling) that can stop developers from introducing autostart mechanisms for malicious or vulnerable code; this reaches only the custom-development slice of the technique, not the dominant abuse of existing legitimate run keys, startup folders or registry values by already-deployed malware.
T1547.004prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, developer training) that can prevent introduction of the registry-abuse logic or vulnerable configuration during custom software or system development, but the technique itself is an OS-level persistence method in unmodified Windows components and is outside the development scope for the bulk of its real-world use.
T1547.006prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop malicious kernel module/extension code from being introduced during in-house or outsourced development; this is only a slice of the technique, which also covers post-deployment loading of existing LKMs/kexts, unsigned/legacy extensions, and adversary abuse of legitimate kernel interfaces.
T1547.007prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, and developer training) that can catch or block malicious plist modifications during development of macOS software, but this is a runtime persistence technique against end-user configuration files rather than a code defect, so only a minority slice is reached.
T1547.008prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that can stop the introduction of vulnerable or malicious LSASS driver code during development, but this is only a slice of the technique which also includes post-compromise replacement or addition of drivers on already-deployed systems.
T1547.009prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, and developer training) that can catch or stop shortcut-abuse persistence code during development, but this is only a slice of the technique (e.g. custom malware or in-house apps) and does not constrain post-deployment abuse, third-party software, or non-development vectors.
T1547.010prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop the insecure coding or configuration allowing arbitrary DLL registration in port monitors, but this is only a slice of the technique's attack surface (e.g., does not address runtime abuse of existing legitimate monitors or post-deployment changes).
T1547.012prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop the insecure coding or configuration allowing malicious print processor registration, but this is only a slice of the technique's attack surface (e.g., does not block post-deployment abuse, privilege requirements like SeLoadDriverPrivilege, or non-development vectors).
T1547.013prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, and developer training) that can catch or block malicious autostart modifications during custom software or system development, but this is only a slice of the technique which is primarily an admin/user-level persistence abuse on deployed Linux systems rather than a code defect introduced in development.
T1548prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, coding guidelines, testing including code scans/penetration tests, and developer training) that reduce the likelihood of introducing or leaving elevation-control bypasses in custom software and systems, but does not address native OS/IaaS elevation mechanisms, configuration of existing controls, or third-party components.
T1548.001prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop setuid/setgid misuse from being introduced in developed software, but does not constrain existing vulnerable binaries, third-party components, or runtime abuse of already-set bits.
T1548.003prevents — A.8.25 mandates secure-SDLC practices (secure requirements, design, checkpoints, secure coding guidelines, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that reach the configuration and coding errors enabling T1548.003; these lower the chance the vulnerable sudoers or caching setup is shipped, but do not guarantee absence of all such misconfigurations or post-deployment changes.
T1548.004prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that can prevent introduction of the insecure use or modification of AuthorizationExecuteWithPrivileges during macOS software development; this is only a slice of the technique, which also covers runtime abuse of existing/deprecated legitimate programs and world-writable file modification on victim systems.
T1548.005prevents — A.8.25 mandates secure SDLC practices (requirements, secure design, checkpoints, testing, secure coding, developer training) that reduce the chance of permission misconfigurations enabling temporary elevation paths; this reaches the root cause for IaaS/identity-provider components built under the process but does not constrain runtime abuse of already-granted JIT/impersonation/pass-role mechanisms or misconfigurations in third-party or non-development-managed cloud resources.
T1548.006prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that can prevent vulnerable macOS software from being written in ways that enable TCC manipulation (e.g., unsafe permission inheritance, weak process handling, or SIP-related flaws), but this is only a slice of the technique's attack surface which also includes post-deployment abuse of granted permissions, SIP disablement, and database tampering on running systems.
T1552prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, secure repositories, version control) that reduce the chance insecure credential storage is introduced during development of in-house or supplier software, but does not stop post-compromise search for credentials already present on running systems or in third-party components.
T1552.001prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements in design, security testing including code scans, developer training on preventing/fixing vulnerabilities) that directly target the introduction of hardcoded or insecurely stored credentials in source code, configs, and related artifacts during development, preventing the technique from being available in built systems; this is only a slice of the class because the technique also covers post-deployment user-created credential files, runtime credential stores, backups, container logs, and Group Policy Preferences outside the development lifecycle.
T1552.007prevents — A.8.25 mandates secure SDLC practices (secure requirements, checkpoints, secure coding, testing including scans/pen-tests, developer training) that can prevent insecure container API configurations or credential exposure in logs during design and build of containerized software, but leaves a large remainder for runtime misconfigurations, insufficient permissions, and post-deployment issues not addressed by development-time controls.
T1553prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing including code scans/penetration tests, developer training) that reduce the likelihood of introducing the flawed trust mechanisms (e.g. weak signing, missing checks) whose subversion enables T1553; this is a genuine but minority slice of the technique's full surface (which also includes runtime bypasses, stolen certs, and post-deployment registry/permission changes).
T1553.003prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that reach the class of trust-subversion defects introduced via flawed implementation or configuration of SIP/trust-provider components; this lowers the chance such hijackable components are written or deployed, but does not guarantee their absence because the control is a process requirement whose completeness depends on implementation rigor and does not itself enforce runtime signature validation or block the registry/DLL hijack techniques.
T1554prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, and developer training) that reduce the chance of shipping or deploying binaries containing the modifiable backdoors or patches described in T1554; this is a genuine but minority slice because the control addresses only the development pipeline and has no reach on post-deployment binaries, supply-chain delivered binaries, or runtime modification of already-installed host software.
T1556prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, developer training) that reduce the chance of introducing modifiable authentication mechanisms or weak credential-handling code, but does not stop post-deployment modification of running auth processes like LSASS, PAM, or plugins.
T1556.003prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop malicious PAM modifications from being introduced during in-house or supplier development of affected components.
T1556.004prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that can catch or block the insertion of a backdoor password during image modification in development or patching, but this is only a slice of the technique's surface (e.g., supply-chain or post-deployment patches on network devices remain outside its direct reach).
T1556.005prevents — A.8.25 mandates security requirements, checkpoints, secure coding, testing (scans/penetration), and developer training in the SDLC; these can prevent the reversible-encryption setting from being introduced or left enabled in new/updated AD configurations and code, but the control does not reach existing deployed AD instances, legacy requirements, or post-deployment policy changes that realize the technique.
T1556.007prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, secure repositories, version control, and developer training) that can stop the introduction of the backdoors, DLL injections, and config modifications described in T1556.007 during development of the affected on-prem/cloud authentication components; it does not reach post-deployment adversary modification of running processes or cloud-side registration of rogue agents.
T1559.002prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop DDE-based command execution from being introduced in custom software or Office/CSV document handlers, but leaves the bulk of the technique (adversary poisoning of third-party Office/CSV files, registry-enabled DDE in COTS Microsoft products, and post-compromise remote invocation) untouched.
T1559.003prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements in design, secure testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that directly target the root causes of improper XPC client validation and poor input sanitization named in the technique.
T1564.007detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that can surface VBA stomping artifacts in Office documents during development, but this is limited to the SDLC testing phase and does not address runtime or post-deployment detection of the technique
T1564.007prevents — A.8.25 mandates secure SDLC practices including secure coding guidelines, security testing (code scans, penetration tests), developer training on preventing/fixing vulnerabilities, and secure repositories/version control; these directly target the introduction of malicious VBA/p-code during Office document or macro development, but the technique can still be applied post-development or in outsourced/legacy documents outside the controlled SDLC.
T1564.009prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop resource-fork abuse from being introduced in developed macOS software, but this is only a slice of the technique's surface (e.g., does not constrain adversary use on existing/third-party binaries or non-development vectors).
T1565prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, coding guidelines, checkpoints, testing including scans/pen-tests, and developer training) that reduce the chance of introducing the integrity flaws adversaries later exploit to achieve data manipulation.
T1565.001prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, coding guidelines, checkpoints, testing including scans/pen-tests, and developer training) that reduce the chance of introducing the integrity weaknesses an adversary later exploits at rest; this is a genuine but minority slice of the technique (most paths are runtime/admin access or insider action, not solely dev-introduced flaws).
T1565.002prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, coding guidelines, checkpoints, testing including code scans/penetration tests, and developer training) that reduce the likelihood of introducing the insecure transmission, missing integrity checks, or interceptable data paths an adversary needs to perform T1565.002; this is a genuine but minority slice of the technique (most real-world instances arise from configuration, network exposure, or runtime interception rather than development defects).
T1565.003prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, developer training) that reduce the chance of introducing the binary-altering or runtime-data logic flaws enabling T1565.003, but does not stop post-deployment modification, specialized expertise gathering, or all supply-chain/outsourced cases.
T1569prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, coding guidelines, testing including code scans/penetration tests, developer training) that reduce the likelihood of introducing the misconfigurations or code paths adversaries later abuse to create or interact with malicious system services.
T1574prevents — A.8.25 mandates secure-SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that reduce the likelihood of introducing the insecure design or coding patterns (e.g., unsafe library loading, search-path poisoning, unvalidated configuration) that enable T1574, but does not guarantee their absence across all entry points or third-party code.
T1574.001detects — A.8.25 mandates security testing including code scans and penetration tests that surface many DLL hijacking/sideloading defects during development, but does not require runtime monitoring or detection of the live technique post-deployment
T1574.001prevents — A.8.25 mandates secure-SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop many classes of flawed loading logic or search-order handling from being introduced; this reaches only a slice of the technique because the control is a process requirement whose effect depends on implementation rigour, does not itself enforce runtime loading safeguards, and leaves platform defaults, third-party binaries, and configuration-based hijacks untouched.
T1574.004prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements in design, testing including code scans and penetration tests, developer training on preventing/fixing vulnerabilities) that can stop dylib hijacking flaws from being introduced in macOS software; this reaches only a slice because the control is a process requirement whose effectiveness depends on implementation rigor and does not guarantee elimination of all search-path or weak-linking defects.
T1574.005prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements in design, security testing including code scans and pen tests, developer training on preventing/fixing vulnerabilities) that directly target the root cause of insecure file/directory permissions during installer creation and packaging; this stops the weakness from reaching production in many cases, but remains partial because the control is a process requirement whose effectiveness depends on implementation rigor, does not reach third-party or outsourced installers without additional assurance, and leaves residual risk for legacy or untested installers.
T1574.006prevents — A.8.25 mandates secure-SDLC practices (secure coding guidelines, security requirements, testing including code scans and penetration tests, developer training on preventing/fixing vulnerabilities) that can stop the insecure use of LD_PRELOAD-style variables or the introduction of hijackable library-loading patterns during development; this reaches only a slice of the technique because the control is a process requirement whose coverage depends on implementation rigour, many hijacks target already-compiled third-party or system binaries, and the technique can still be introduced at runtime or via configuration outside the SDLC.
T1574.007prevents — A.8.25 mandates secure-SDLC practices (secure coding guidelines, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop PATH-interception flaws from being introduced in custom software and scripts; this is only a slice of the technique, which also covers OS-level or third-party binary hijacks, direct $PATH/$HOME modification at runtime, and non-development vectors such as shell config changes.
T1574.008detects — A.8.25 mandates security testing including code scans and penetration tests that can surface search-order hijacking flaws during development, but does not require runtime monitoring or anomaly detection after deployment
T1574.008prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements in design, secure repositories, developer training on preventing/fixing vulnerabilities) that can stop search-order-hijacking defects from being introduced into developed software; this is only a slice of the technique because the weakness can also be present in COTS binaries, unpatched third-party components, or non-development-time configuration choices outside the SDLC.
T1574.009detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface unquoted-path flaws during development, but does not mandate runtime detection after deployment
T1574.009prevents — A.8.25 mandates secure SDLC practices including secure coding guidelines, security requirements in design, secure repositories, version control, developer training, and testing (scans/penetration tests) that can catch and stop unquoted-path defects from reaching production code; this is a genuine but minority slice of the class because the technique also arises from misconfigured deployed services, shortcuts, and registry entries outside the development pipeline.
T1574.010prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, and developer training on preventing/fixing vulnerabilities) that reduce the likelihood of introducing the improper file/service permissions flaw during development of in-house or outsourced software and systems.
T1574.011prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, checkpoints, secure coding guidelines, testing including code scans/penetration tests, and developer training on preventing/fixing vulnerabilities) that can catch and stop insecure Registry/service permissions during custom software or system development, but this is only a slice of the technique's surface (which also covers misconfigurations on existing OS services, third-party components, or runtime hijacks outside the development lifecycle).
T1574.012prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop this technique from being introduced in custom .NET software; it does not constrain abuse of the CLR feature in third-party or already-built components.
T1574.013prevents — A.8.25 mandates secure-SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans and penetration tests, developer training on preventing/fixing vulnerabilities) that can stop this technique from being introduced into first-party or in-house-developed code; it has no effect on the many ways an adversary can introduce or trigger the same behavior via third-party binaries, process injection into running software they do not develop, or post-compromise memory corruption.
T1574.014detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that can surface this .NET-specific injection technique in developed software, but the control is scoped only to the development lifecycle and does not mandate runtime or operational detection after deployment.
T1574.014prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/pen tests, developer training on preventing/fixing vulnerabilities) that reach the class of assembly-loading hijacks when applied to .NET code, but only as a slice — the control sets process requirements rather than mandating any specific mechanism that stops AppDomainManager injection, leaving the bulk of implementation-dependent coverage unaddressed.
T1587.004prevents — A.8.25 mandates secure SDLC practices (secure coding, requirements, checkpoints, testing, developer training and vulnerability prevention/fixing) that reduce the chance an organization ships the exploitable bugs adversaries would develop custom exploits against; this constrains the technique at the source but leaves many residual cases (e.g. 0-days, outsourced code that evades the checkpoints, non-software bugs, or adversary-controlled development).
T1588.005prevents — A.8.25 mandates secure SDLC practices (secure coding, requirements, checkpoints, testing, developer training) that reduce the introduction and persistence of exploitable bugs, thereby preventing many (but not all) vulnerabilities that could be turned into purchasable/stealable exploits.
T1600prevents — A.8.25 mandates secure SDLC practices (requirements, secure coding, testing, checkpoints, developer training) that reach the design/implementation of network device firmware and its crypto components, thereby preventing many classes of weakening (e.g., weak ciphers, poor key handling, flawed image builds); it does not address post-deployment compromise vectors such as runtime manipulation of already-deployed devices.
T1600.001prevents — A.8.25 mandates secure SDLC practices (secure requirements, design, coding guidelines, checkpoints, testing including code scans/penetration tests, and developer training) that can catch or block weakening of cryptographic parameters like key size during development or updates, but this is only a slice — the technique primarily acts post-compromise on deployed network devices via image/config modification, outside the development lifecycle.
T1601prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing, checkpoints, developer training) that reach the monolithic OS image as software/firmware, lowering the chance such a modification is introduced or left exploitable; it does not guarantee prevention on every embedded device or against all live-in-memory or post-deployment changes.
T1601.001prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing, developer training) that reach the network-device firmware development process and thereby stop many classes of patchable defects or backdoors from being introduced in the first place; the remainder is post-shipment modification of already-deployed images, which the clause does not address.
T1606.001prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that reduce the chance of introducing the weak cookie-generation logic or secret-handling flaws adversaries exploit to forge cookies, but does not guarantee their absence.
T1610prevents — A.8.25 mandates secure SDLC practices (secure requirements, checkpoints, testing, secure coding, developer training) that can stop malicious or vulnerable container images from being built and deployed in the first place; this reaches the 'built malicious images' and 'vulnerable container' slices of T1610 but leaves runtime API/dashboard/privileged-deployment vectors and already-compromised environments untouched.
T1611detects — A.8.25 explicitly requires system/security testing including code scans, penetration tests and security checkpoints that surface container/virtualization escape paths (e.g. privileged containers, bind mounts, exposed sockets, vulnerable hypervisor paths) during development, but only for code built under the SDLC — not for runtime detection or already-deployed third-party images/hypervisors.
T1611prevents — A.8.25 mandates secure SDLC practices (requirements, secure design, checkpoints, testing including penetration tests, secure coding, separation of environments) that can identify and eliminate many container/virtualization escape vectors before deployment, but does not guarantee prevention of all (e.g., runtime misconfigurations, zero-days, or post-deployment changes).
T1612prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing, developer training) that can stop malicious image builds from being introduced in development pipelines, but the technique is an adversarial runtime build on a host (often outside the organization's SDLC) and the control reaches only the slice performed under its governed processes.
T1620prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security testing including code scans and penetration tests, developer training on preventing/fixing vulnerabilities) that can stop many classes of reflective loading techniques from being introduced in first-party or custom-developed code; it does not address third-party components, already-compromised environments, or runtime abuse of legitimate interpreters.
T1622prevents — A.8.25 mandates secure SDLC practices (secure coding guidelines, security testing including code scans and penetration tests, developer training on preventing/finding/fixing vulnerabilities) that can stop many debugger-evasion patterns from being introduced in first-party malware; this is a genuine but minority slice of the technique, which is overwhelmingly implemented in third-party/adversary-controlled implants outside the organization's SDLC.
T1648prevents — A.8.25 mandates secure SDLC practices (requirements, secure coding, testing, checkpoints, developer training) that can prevent insecure serverless functions or workflows from being introduced during development, but this is only a slice: the technique also covers post-deployment abuse, event-triggered persistence, and adversary-created resources outside the organization's own development lifecycle.
T1649prevents — A.8.25 mandates secure SDLC practices (secure coding, security requirements, checkpoints, testing including code scans/penetration tests, developer training on preventing/fixing vulnerabilities) that can stop certificate-related misconfigurations and insecure handling during development of systems using or issuing authentication certificates, but this does not address runtime theft, forged enrollment abuse, or compromise of existing CA keys on deployed systems.
T1671prevents — A.8.25 mandates secure SDLC practices (requirements, checkpoints, secure coding, testing, developer training) that can prevent insecure OAuth integrations or custom apps from being introduced during development of in-house or supplier-built SaaS/cloud components; this reaches only a slice of the technique, which also covers adversary creation/co-opting of integrations post-deployment or outside any organizational SDLC.
T1677detects — A.8.25 explicitly requires system/security testing including code scans and penetration tests that surface malicious code or misconfigurations in the CI/CD build process and related artifacts; this is genuine but only a slice because the clause is scoped to development-time checks rather than continuous runtime monitoring of pipeline executions.
T1677prevents — A.8.25 explicitly requires secure SDLC practices (secure coding guidelines, security in version control, security checkpoints, secure repositories, developer training on preventing/fixing vulnerabilities, and supplier assurance for outsourced development) that directly address the injection vectors named in T1677; this stops the technique in environments built under the control, but remains partial because the clause only sets process requirements whose actual enforcement and completeness are left to the implementer (see A.8.28 cross-references) and because public-pipeline/fork scenarios can still succeed against a conformant but imperfect pipeline.
T1685.002prevents — A.8.25 mandates secure SDLC practices (requirements, checkpoints, secure coding, testing, developer training) that can prevent insecure-by-design logging configurations from reaching production, but does not address runtime permission abuse, post-deployment tampering, or license downgrades by an already-privileged adversary.
T1687prevents — A.8.25 mandates secure SDLC practices (requirements, secure coding, checkpoints, testing including scans/pen-tests, developer training) that reduce the introduction of exploitable vulnerabilities in any software, including defensive components, thereby preventing many (but not all) instances of this technique from being available to run.
T1689prevents — A.8.25 mandates secure SDLC practices (secure requirements, checkpoints, testing, secure coding, version control, developer training) that can catch and block vulnerable/outdated components or downgrade-prone designs during development, but this is only a slice of the technique's surface (e.g., runtime protocol or boot-manager downgrades on deployed systems) and does not stop an adversary forcing backward compatibility post-deployment.

Prevented OWASP Web Top 10 (2025) risks (33)

OWASP Web Top 10 (2025) risk categories this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

A01→P A02→P A03←P →P A04→P A05→P A06→P A07→P A08→P A10→P

Why these map — AI rationale (under review)

A01mitigates — A.8.25 requires security requirements, checkpoints, testing (incl. pen tests), and secure SDLC practices that can surface and limit some Broken Access Control defects (e.g. missing checks, IDOR) before release, thereby reducing realized impact, but does not itself enforce or bound authorization decisions at runtime.
A01prevents — A.8.25 mandates security requirements, checkpoints, secure coding, testing (incl. pen tests) and developer training in the SDLC, which prevents many Broken Access Control defects (e.g. missing checks, IDOR) when followed; it does not address all members such as CSRF or path traversal that sit outside its direct mechanisms.
A02mitigates — A.8.25's security requirements, checkpoints, testing (scans/pen-tests), secure coding and developer training in the SDLC can catch and reduce some misconfiguration defects before release, but the control is about process and does not itself harden defaults, close cloud settings or remove the realised weakness in deployed systems.
A02prevents — A.8.25 mandates security requirements, checkpoints, secure coding, testing and developer training in the SDLC, which directly prevents many classes of misconfiguration (e.g. weak defaults, exposed cloud settings) from being introduced during design and implementation; it does not reach post-deployment runtime configuration drift or incomplete hardening of already-deployed systems.
A03mitigates — A.8.25's SDLC process (security requirements, checkpoints, testing, secure coding, developer training) can catch and reduce impact of vulnerable/outdated dependencies or pipeline issues before they reach production, but does not bound or lessen the consequence of those that are already present or introduced via outsourced supply chain without direct enforcement.
A03prevents — A.8.25 explicitly requires secure SDLC practices (secure coding, security requirements, testing, developer training, secure repositories/version control) that reduce the chance of introducing vulnerable/outdated dependencies or insecure build practices, but does not guarantee their absence and leaves build-pipeline/signing-infrastructure failures largely untouched.
A04prevents — A.8.25 mandates security requirements, checkpoints, secure coding guidelines, testing (including scans/pen tests) and developer training in the SDLC, which directly lowers the chance that absent/weak/misused cryptography is introduced; it does not itself implement or enforce cryptography so the effect is a genuine but minority slice of the class.
A05mitigates — A.8.25 requires security checkpoints, secure coding guidelines, testing (code scan, penetration tests) and developer training that can catch and limit the blast radius or occurrence of injection flaws in the SDLC, but does not itself neutralize untrusted input at runtime or bound all injection consequences.
A06mitigates — A.8.25 mandates security requirements, checkpoints, secure design guidance and testing during the SDLC, which can surface and reduce the impact or likelihood of design-level weaknesses (e.g. via threat modeling or architecture reviews), but does not itself alter or bound the realized consequence of an already-baked-in insecure design.
A06prevents — A.8.25 mandates security requirements, checkpoints, secure design guidance and testing in the SDLC which directly targets design-level weaknesses, but leaves a large remainder (flawed business logic, missing controls chosen by architects, threat modeling gaps) that the clause's listed mechanisms do not close.
A07mitigates — A.8.25 mandates security in the SDLC including secure requirements, checkpoints, testing (penetration, code scan), and developer training that can surface and reduce authentication defects before release, but does not itself bound the realized impact of those that ship.
A07prevents — A.8.25 mandates security requirements, checkpoints, secure coding, testing (including scans/pen tests) and developer training in the SDLC, which directly lowers the chance that authentication defects (weak flows, session mistakes, credential handling) are introduced; it does not guarantee their absence.
A08mitigates — A.8.25 requires security checkpoints, testing (including code scans and penetration tests), secure repositories, version control, and developer training that can surface and limit the blast radius or realization of integrity failures such as unsigned updates or CI/CD path compromises, but does not directly address or bound insecure deserialization or the core absence of integrity verification mechanisms.
A08prevents — A.8.25 mandates secure SDLC practices (secure requirements, checkpoints, testing, secure coding, version control, developer training) that directly reduce the chance of introducing code/data integrity defects such as unsigned updates or insecure deserialization during development.
A10mitigates — A.8.25 mandates security checkpoints, secure design, testing (incl. regression/pen tests) and developer training that can catch and limit the blast radius or inconsistent states of mishandled exceptions, but does not directly address error-path leakage, fail-open behavior or exception-handling logic itself.
A10prevents — A.8.25 mandates security in the SDLC including secure coding, requirements, checkpoints, testing (scans/pen tests) and developer training, which directly lowers the chance of introducing error-handling defects that leak info, fail open or create inconsistent states.

Control IDs, short titles and the structured attribute table (control type, CIA properties, cybersecurity-concept, operational capability, security domain) are facts from ISO/IEC 27001:2022 Annex A / ISO/IEC 27002:2022. The full implementation guidance prose lives in ISO/IEC 27002:2022 — not reproduced here. Cross-walks to NIST 800-53, NIST CSF 2.0, OWASP ASVS, CWE, MITRE ATT&CK and OWASP Web Top 10 are our own AI-authored analysis (authority llm_unverified, under review), not an ISO, NIST, MITRE or OWASP product — how ours compare.