Security Resilience

← ISO 27001 Annex A

A.8.28 Technological

Secure coding

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 (17)

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).

CM-3→P SA-10→P SA-11←M →M SA-15←F →M SA-17←M SI-7←P SA-3gov SA-8gov

Why these map — AI rationale (under review)

SA-11mostlyaligns with — Both controls require systematic security testing and evaluation of software during development to identify and mitigate vulnerabilities before deployment.
SA-15mostlyaligns with — Both controls mandate the use of secure development processes, standards, and tools to produce software with fewer exploitable weaknesses.
SA-8mostlyaligns with — Both controls embed security and privacy engineering principles such as least privilege, threat modeling, and secure design into the software development lifecycle.
CM-2partialaligns with — Both controls establish approved, secure baselines for development tools and environments to ensure consistent, hardened configurations.
CM-3partialaligns with — Both controls apply configuration change control and version management to source code to prevent unauthorized modification and maintain integrity.
SA-10partialaligns with — Both controls require configuration management practices for developer-created artifacts to track changes and protect against tampering.
SI-2partialaligns with — Both controls require ongoing identification and remediation of software flaws and vulnerabilities after code is placed into operation.
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-8implements — Assessed as NOT holding by the authoring instrument at v1.19-2026-08-23. 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.
SI-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.

Aligned NIST CSF 2.0 outcomes (23)

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 DE.AE-07gov GV.SC-05gov ID.AM-02gov ID.RA-01gov ID.RA-09gov PR.AT-02gov PR.PS-01gov PR.PS-02gov

Why these map — AI rationale (under review)

PR.PS-06fullcovers — The ISO control establishes organization-wide secure coding governance, standards, tool configuration, developer qualification, threat-informed continual improvement, and third-party component vetting—directly fulfilling the CSF outcome of integrating and monitoring secure software development practices.
ID.RA-01mostlyaligns with — By requiring static analysis, review of common programming errors, and mitigation before release, the control systematically identifies and records vulnerabilities in software assets.
ID.RA-09mostlyaligns with — The control mandates vetting, inventorying, and ongoing updates of external libraries and components for authenticity, integrity, and security before and after acquisition.
GV.SC-05partialaligns with — Extending secure-coding governance and component-vetting requirements to third-party and open-source software integrates cybersecurity expectations into supplier contracts and processes.
PR.PS-01partialaligns with — Secure coding standards, IDE/tool configuration, and configuration-management controls for source code constitute configuration-management practices applied to the development environment.
PR.PS-02partialaligns with — The control requires secure packaging, deployment, and regular updates of software, aligning with the outcome of maintaining or replacing software commensurate with risk.
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.RA-01implements — 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.PS-01implements — 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.PS-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 (15)

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).

V1.3.2←P V11.1.2←P V13.4.1→P V15.1.2←M →M V15.1.4→P V15.1.5←M V15.2.1←M →M V15.2.4→P V15.2.5←P →P V15.3.3←P V15.3.5←P V16.3.4→P

Why these map — AI rationale (under review)

V15.1.2mostlycovers — The ISO control's requirement to maintain an inventory of third-party and open-source libraries with version tracking directly implements the ASVS mandate for an SBOM-style catalog of all third-party components.
V15.2.1mostlycovers — Requiring that components stay within documented remediation timeframes for vulnerabilities is the direct operational outcome of the ISO control's continual monitoring of threats and vulnerabilities.
V13.4.1partialaligns with — The ISO control's requirement to protect source code against unauthorized access and tampering using configuration-management tools aligns with the ASVS requirement to prevent exposure of source-control metadata in production.
V15.1.4partialaligns with — The ISO control's call to qualify developers and apply secure coding standards supports the ASVS expectation that documentation identifies risky third-party libraries.
V15.2.4partialaligns with — The ISO control's emphasis on selecting and authorizing well-vetted external components from reputable sources aligns with the ASVS requirement that third-party components and transitive dependencies come from expected repositories.
V15.2.5partialaligns with — The ISO control's prohibition of insecure design techniques and emphasis on least privilege during review aligns with the ASVS requirement for additional protections around documented dangerous functionality.
V16.3.4partialaligns with — The ISO control's directive to log errors and suspected attacks and regularly review logs aligns with the ASVS requirement to log unexpected errors and security-control failures.

Related weaknesses / CWE (1732)

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-1004←P CWE-1007←P CWE-102←P CWE-1021←P CWE-1022←P CWE-1023←P →P CWE-1024←P CWE-1025←P CWE-1037←P CWE-1038←P →P CWE-1039←P →P CWE-1049←P CWE-1050→P CWE-1055←P CWE-1056←P CWE-1058←P CWE-1066←P →P CWE-1067←P CWE-1076←P →P CWE-1077←P CWE-1078←P →P CWE-1083←P CWE-1088←P CWE-1091←P CWE-1100←P →P CWE-1102←P →P CWE-1106←P CWE-1107←P →P CWE-1108←P CWE-111←P CWE-1116←P CWE-1118←P →P CWE-1119←P CWE-112←P CWE-1124←P CWE-113←P CWE-114←P →P CWE-115←P CWE-116←P →P CWE-1164←P →P CWE-117←P CWE-1173←P CWE-1174←P CWE-1176←P CWE-118←P →P CWE-119←P →P CWE-1190→P CWE-120←M CWE-1204←P CWE-121←P CWE-122←P CWE-1221←P →P CWE-1223←P →P CWE-1224←P CWE-123←P CWE-1231←P →P CWE-1236←P CWE-124←P CWE-1240←P CWE-1242←P →P CWE-1245→P CWE-1246←P CWE-125←P CWE-1254←P CWE-1255←P CWE-1256←P CWE-1258←P CWE-1259→P CWE-126←P CWE-1260←P CWE-1265←P CWE-127←P CWE-1270←P CWE-1272→P CWE-1275←P CWE-1279←P CWE-128←P CWE-1281←P CWE-1284←P CWE-1285←P CWE-1286←P CWE-1287←P CWE-1288←P CWE-1289←P CWE-129←P CWE-1291←P CWE-1295←P CWE-130←P CWE-131←M CWE-1316←P CWE-1320←P CWE-1321←P CWE-1322←P CWE-1327→P CWE-1332←P CWE-1333←P CWE-1335←P CWE-1336←P CWE-134←P CWE-1341←P CWE-135←P CWE-138←P →P CWE-1385←P →P CWE-1386←P CWE-1389←P CWE-1391←P →P CWE-14←P CWE-140←P CWE-141←P CWE-142←M CWE-143←P CWE-144←P CWE-145←P CWE-146←P CWE-147←P CWE-148←P CWE-149←P CWE-150←P CWE-153←P CWE-154←P CWE-155←P CWE-156←P CWE-157←P CWE-158←P CWE-159←P →P CWE-160←P CWE-162←P CWE-164←P CWE-166←P CWE-167←P CWE-168←P CWE-170←P CWE-172←M →P CWE-173←P CWE-176←P CWE-177←P CWE-178←P CWE-179←P CWE-180←P CWE-182←P CWE-183←P CWE-184←P CWE-185←P →P CWE-186←P CWE-187←P CWE-188←P CWE-190←P CWE-191←P CWE-192←P CWE-193←P CWE-194←P CWE-195←P CWE-196←P CWE-197←P CWE-198←P CWE-20→P CWE-200→P CWE-201←P CWE-202←P →P CWE-204←P →P CWE-205←P →P CWE-209→P CWE-210←P →P CWE-212←P CWE-214←P CWE-219←P CWE-22←P CWE-228←P →P CWE-229←P CWE-23←P CWE-230←P CWE-231←P CWE-232←P CWE-233←P CWE-234←P CWE-235←P CWE-236←P CWE-237←P CWE-239←P CWE-24←P CWE-240←P →P CWE-241←P CWE-242←P CWE-244←P CWE-248←P CWE-25←P CWE-252←P CWE-253←P CWE-257←P CWE-26←P CWE-27←P CWE-270←P CWE-271→P CWE-277←P CWE-278←P →P CWE-28←P CWE-288→P CWE-29←P CWE-290←P CWE-296→P CWE-297←P CWE-298→P CWE-299→P CWE-30←P CWE-302←P CWE-303←P CWE-305→P CWE-31←P CWE-313←P CWE-314←P CWE-315←P CWE-316←P CWE-318←P CWE-32←P CWE-325←P CWE-328←P CWE-329←P CWE-330←P →P CWE-331→P CWE-333→P CWE-335←P CWE-336→P CWE-339←P CWE-34←P CWE-340→P CWE-341←P →P CWE-345→P CWE-346←P →P CWE-349←P CWE-35←P CWE-350←P CWE-351←P CWE-353←P →P CWE-354←P →P CWE-357←P CWE-358←P CWE-36←P CWE-362←P →P CWE-363←P CWE-364←P CWE-366←P CWE-368←P CWE-369←P CWE-37←P CWE-370→P CWE-372←P CWE-374←P CWE-377←P →P CWE-378←P CWE-379←P CWE-38←P CWE-385→P CWE-386←P →P CWE-39←P CWE-390←P CWE-391←P CWE-392←P →P CWE-393←P CWE-394←P CWE-395←P CWE-396←P CWE-40←P CWE-401←P CWE-403←P CWE-407←P →P CWE-41←P CWE-412→P CWE-413←P CWE-414←P CWE-416←P CWE-42←P CWE-421←P →P CWE-422←P CWE-424←P →P CWE-426←P CWE-427←P CWE-428←P CWE-43←P CWE-430←P →P CWE-431←P →P CWE-433←P CWE-436←P →P CWE-44←P CWE-440←P CWE-441←P →P CWE-444←P →P CWE-446→P CWE-448←P CWE-449←P CWE-450←P CWE-451←P →P CWE-453←P CWE-454←P CWE-455←P CWE-456←P CWE-457←P CWE-459←P CWE-46←P CWE-460←P CWE-462←P CWE-463←P CWE-466←P CWE-467←P CWE-468←P CWE-469←P CWE-470←P CWE-472←P CWE-473←P CWE-474←P CWE-475←P CWE-476←P CWE-477←P →P CWE-478←P CWE-479←P CWE-480←P CWE-482←P CWE-484←P CWE-488←P CWE-489←P CWE-491←P CWE-495←P CWE-499←P CWE-50←P CWE-501←P CWE-507←P CWE-511←P CWE-515←P CWE-523→P CWE-524←P CWE-525←P →P CWE-526←P CWE-528←P CWE-531←P →P CWE-535←P CWE-539←P →P CWE-540←P CWE-541←P →P CWE-544←M CWE-547←P CWE-548←P →P CWE-550←P →P CWE-551←P CWE-553←P CWE-561←P CWE-562←P CWE-564←P CWE-565←P CWE-567←P CWE-57←P CWE-570←P CWE-571←P CWE-573←P →P CWE-587←P CWE-588←P CWE-59←P CWE-590←P CWE-591←P CWE-597←P CWE-598←P CWE-599←P →P CWE-600←P CWE-602←P →P CWE-603←P CWE-605←P CWE-606←P CWE-61←P CWE-610←P →P CWE-611←P CWE-614→P CWE-615←P CWE-616←P CWE-617←P CWE-618←P CWE-62←P CWE-621←P CWE-622←P CWE-623←P CWE-624←P CWE-625←P CWE-626←P CWE-627←P CWE-628←P CWE-637→P CWE-64→P CWE-641←P CWE-642→P CWE-643←P CWE-644←P CWE-646←P →P CWE-647←P CWE-648←P CWE-649←P →P CWE-65←P CWE-650←P CWE-652←P CWE-656→P CWE-657←P CWE-66←P CWE-662←P →P CWE-663←P CWE-665←P →P CWE-667←P →P CWE-669←P CWE-670←P →P CWE-672←P →P CWE-674→P CWE-675←P →P CWE-676←P CWE-680←P CWE-681←P CWE-682←P CWE-683←P CWE-686←P CWE-687←P CWE-688←P CWE-689←P CWE-69←P →P CWE-690←P CWE-691←P CWE-692←P CWE-694→P CWE-695←P CWE-696←P →P CWE-697←P CWE-698←P CWE-704←P →P CWE-705←P →P CWE-706←P →P CWE-707←P CWE-710←P CWE-73←P CWE-733←P →P CWE-74←P →P CWE-749←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 CWE-761←P CWE-762←P CWE-763←P CWE-764←P CWE-765←P CWE-767←P CWE-768←P CWE-77←P →P CWE-771←P CWE-772←P CWE-774←P CWE-776←P CWE-777←P CWE-780←P →P CWE-783←P CWE-784←P CWE-786←P CWE-787←P CWE-788←P CWE-789←P CWE-79→P CWE-790←P →P CWE-791←P CWE-792←P CWE-794←P CWE-799→P CWE-80←P CWE-804←P →P CWE-805←P CWE-807←P CWE-81←P CWE-82←P CWE-820←P →P CWE-821←P CWE-822←P CWE-823←P CWE-824←P CWE-825←P CWE-826←P CWE-827←P CWE-828←P CWE-83←P CWE-830←P →P CWE-832←P →P CWE-833←P CWE-834←P →P CWE-836→P CWE-837←P CWE-838←M CWE-839←P CWE-84←P CWE-841→P CWE-843←P CWE-85←P CWE-86←P CWE-87←P CWE-88←P CWE-89→P CWE-90←P CWE-908←P CWE-909→P CWE-91←P CWE-910←P CWE-911←P CWE-912→P CWE-913←P →P CWE-914←P CWE-915←P CWE-917←P CWE-923→P CWE-925←P CWE-926←P CWE-927←P CWE-939←P CWE-940→P CWE-941→P CWE-942←P CWE-943←P →P CWE-95←P CWE-96←P CWE-97←P CWE-98←P CWE-99←P →P

Why these map — AI rationale (under review)

CWE-1264noneprevents — Secure coding guidelines can address hardware description language issues that lead to premature data forwarding.
CWE-1298noneprevents — Secure coding guidance can extend to hardware description languages but is primarily software-oriented.
CWE-514noneprevents — Secure-coding standards can forbid constructs known to create covert channels, but the control does not explicitly require covert-channel analysis.
CWE-553noneprevents — Secure coding standards prohibit placing command shells in publicly accessible paths.
CWE-669noneprevents — Secure-coding standards help prevent implementation of improper transfers.
CWE-1004prevents — Secure coding standards explicitly require the HttpOnly flag for sensitive cookies.
CWE-102prevents — Secure coding rules directly prevent duplicate Struts validation forms.
CWE-1021prevents — Secure coding practices directly require implementation of frame-busting headers or CSP frame-ancestors directives.
CWE-1022prevents — Secure coding standards directly require the use of rel="noopener noreferrer" on external links, eliminating the weakness.
CWE-1023prevents — Secure coding standards can forbid incomplete comparisons, but the control covers a wide range of coding issues.
CWE-1024prevents — Secure coding standards directly require type-safe comparisons and compiler warnings for incompatible types.
CWE-1025prevents — Secure coding standards directly address proper comparison logic and factor selection.
CWE-103removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, SAST, and mitigation of common/historical errors (including incomplete validation methods like this Struts-specific validate() flaw), so well-implemented it removes the defect from first-party code; remainder is inconsistent application or third-party components where the clause falls back to inventory/update rather than direct removal.
CWE-1037prevents — Secure coding standards must explicitly forbid optimizations that eliminate security-critical operations.
CWE-1038prevents — Secure coding standards must address risks from compiler or build-tool optimizations that alter intended security behavior.
CWE-1039prevents — Secure coding practices can incorporate input sanitization and adversarial robustness checks for ML models.
CWE-104removes — A.8.28's secure coding process (principles, standards, defect removal, prohibiting insecure techniques, SAST, peer review, threat modeling) directly removes this first-party code defect before release; remainder is reuse of third-party/open-source Struts components where the clause's own guidance falls back to inventory/update rather than in-house removal.
CWE-1042removes — A.8.28's secure coding process, principles, standards, defect removal, prohibition of insecure techniques, SAST, and peer review directly remove this first-party static-member design defect from the product before it ships; the bounded remainder is imperfect application of the process to every line in every language and reuse scenario.
CWE-1045removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes the described first-party code defect (inconsistent virtual destructor declarations) from the product before it ships, with only a bounded remainder for cases where the mandated process is not fully applied to every development activity.
CWE-1049prevents — Secure coding rules directly prohibit or limit complex joins and sub-queries on large tables.
CWE-105removes — A.8.28 mandates secure coding practices, standards, defect removal, SAST, and prohibiting insecure techniques that directly eliminate form-field-without-validator defects before and during development; the bounded remainder is inconsistent application across all languages, frameworks, and third-party code reuse scenarios.
CWE-1050prevents — Secure coding standards explicitly forbid resource-consuming loops.
CWE-1051prevents — Secure coding standards typically ban hard-coded network resources, yet the control covers many other practices.
CWE-1051removes — A.8.28 mandates secure coding practices, standards, and techniques that explicitly prohibit hard-coded credentials/passwords and require removal of programming defects; this removes most instances of CWE-1051 (a first-party code defect) from the product before it ships, with a bounded remainder in cases of incomplete adoption or third-party component reuse.
CWE-1052removes — A.8.28 explicitly prohibits hard-coded passwords and insecure design techniques during coding, mandates secure coding standards and principles that address this exact class of literal misuse in initialization, and requires removing programming defects; this removes the flaw from first-party code for most cases, with a bounded remainder around complex non-password literals or third-party components that fall under separate inventory rules.
CWE-1053removes — A.8.28 mandates secure coding practices, principles, documentation of code, and removal of defects during development but does not mandate or produce design-level documentation; the absence of design documentation (CWE-1053) therefore remains after the control is applied.
CWE-1054removes — A.8.28's secure coding principles, standards, design/architecture review, threat modelling, prohibition of insecure techniques, documentation/removal of defects, and SAST directly target and eliminate unnecessary deep-layer invocations during development and review; the bounded remainder is post-operational maintenance or third-party component layers reached only indirectly via 8.8/8.29.
CWE-1055prevents — Secure coding standards can explicitly prohibit or limit multiple inheritance from concrete classes.
CWE-1055removes — A.8.28 mandates secure coding principles, standards, peer review, removal of defects, prohibition of insecure techniques, SAST, and analysis of common programming errors (including this one) before release, so well-implemented secure coding removes most instances of multiple-inheritance-from-concrete-classes from first-party code; the bounded remainder is inconsistent application across all languages, libraries, and outsourced components where the clause's governance does not reach every implementation detail.
CWE-1056prevents — Secure coding standards explicitly forbid variadic parameter lists that bypass static analysis and type safety.
CWE-1056removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, prohibition of insecure techniques, and use of SAST that directly target and eliminate first-party code defects including variadic signatures before the software ships; the bounded remainder is variadic usage introduced via inadequately vetted third-party components whose removal lives in the separate library-management slice of the clause.
CWE-1057prevents — Secure coding standards prohibit direct data access outside the approved data-manager abstraction.
CWE-1057removes — A.8.28 mandates secure coding practices, standards, defect removal, secure design, and prohibiting insecure techniques (including during review/maintenance), which removes most first-party code that performs data access outside the dedicated manager component; the bounded remainder is incomplete uptake of those practices across all languages, third-party components, or subtle architectural violations that survive peer review and SAST.
CWE-1058prevents — Secure coding standards directly prohibit non-final static fields accessed by multiple threads without synchronization.
CWE-106removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, SAST, and prohibiting insecure techniques; this directly removes the specific first-party code defect of not using an input validation framework like Struts Validator before the product ships.
CWE-1062removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes first-party code defects like parent-child circular references when the secure-coding baseline addresses them, with a bounded remainder for cases where the specific pattern is not yet codified in the org's principles or historical-defect list.
CWE-1063removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes first-party code defects like static-block instantiation during development; remainder is third-party/open-source components where the clause only governs selection/update rather than mandating removal of the pattern.
CWE-1064removes — A.8.28's secure coding principles, standards, defect removal, prohibition of insecure techniques, and peer review/refactoring directly eliminate excessive-parameter signatures during development and maintenance; the bounded remainder is that the clause's governance/monitoring aspects do not reach every possible legacy or third-party invocation site.
CWE-1065removes — A.8.28's secure coding principles, standards, prohibition of insecure techniques, documentation/removal of defects, and secure design directly remove the low-level resource management that bypasses the app-server API, with a bounded remainder in third-party component selection and post-deployment maintenance.
CWE-1066prevents — Secure coding standards directly address implementing required serialization methods for data elements.
CWE-1067prevents — Secure coding standards explicitly require use of indexes and avoidance of full-table scans.
CWE-1069removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes empty exception blocks from first-party code; the bounded remainder is third-party/open-source components where the clause only requires inventory/update rather than mandating removal of the defect.
CWE-107removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, SAST, and mitigation of common/historical errors (including validation logic), which removes most instances of outdated/unused validation forms from first-party code; the bounded remainder is incomplete uptake of the mandated practices across all languages, third-party components, or edge-case defects.
CWE-1070removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, and prohibiting insecure techniques (including design flaws that could produce non-serializable members in a serializable element); this removes a minority slice of CWE-1070 instances that arise from prohibited or detectable coding defects, but most instances are architectural/data-model choices outside its direct mandate and the clause is silent on serialization contracts.
CWE-1071removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes empty code blocks from first-party source during development; the bounded remainder is third-party/open-source components where the clause only requires inventory/update rather than mandating removal of the empty-block pattern.
CWE-1072prevents — Secure coding standards can discourage direct connection creation but do not explicitly require connection pooling.
CWE-1072removes — A.8.28's secure coding process (principles, standards, prohibiting insecure techniques, removing defects, SAST, peer review, threat modeling) directly produces code that uses connection pooling instead of the anti-pattern, so the first-party flaw stops being present; remainder is third-party library defects reached only via the separate A.8.8-managed update path.
CWE-1075removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes unconditional gotos outside switch blocks when they are recognized as historical/common defects during development; the bounded remainder is latent instances already shipped in operational code (handled only indirectly via 8.8/8.29, not by this clause).
CWE-1076prevents — Secure coding standards directly address adherence to coding conventions.
CWE-1077prevents — Secure coding rules can mandate safe floating-point comparison practices.
CWE-1078prevents — Secure coding explicitly requires adherence to style and formatting standards that directly address CWE-1078.
CWE-1079removes — A.8.28 mandates secure coding practices, principles, standards, defect removal, prohibition of insecure techniques, and SAST during development that directly eliminate parent-class-without-virtual-destructor defects from first-party code before it ships; the bounded remainder is third-party or open-source components whose flaws are addressed only by inventory/update steps rather than by the secure-coding process itself.
CWE-108removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, SAST, and prohibiting insecure techniques; this directly removes the unvalidated Struts Action Form (a named historical defect) from first-party code, with a bounded remainder for third-party/open-source components governed only by inventory/update rules rather than direct code remediation.
CWE-1080removes — A.8.28 mandates secure coding practices, principles, standards, reviews and defect removal during development to reduce potential vulnerabilities, but does not mandate or perform any action that shortens or refactors an already-written source file that exceeds a line-count threshold; the flaw remains present after the control runs.
CWE-1083prevents — Secure coding standards explicitly forbid direct data access outside the approved data manager, addressing the root cause of CWE-1083.
CWE-1083removes — A.8.28's secure coding principles, standards, defect removal, prohibition of insecure techniques, and SAST directly remove first-party code that bypasses the intended data manager component; the bounded remainder is third-party or open-source components whose flaws are addressed only by inventory/update rules rather than by the coding practices themselves.
CWE-1084removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST, threat modeling) directly removes excessive file/data access operations from first-party code during development; remainder is third-party/open-source components governed only by inventory/update rules rather than code-level removal.
CWE-1086removes — A.8.28 mandates secure coding practices, principles, standards, reviews and SAST that can surface excessive-inheritance smells before or during development, but does not itself rewrite or refactor the class hierarchy; the flaw therefore remains present in the delivered code (see explicit anchor: secure coding removes, testing does not; also A.8.29 removes CWE-89 = none).
CWE-1087removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes first-party code defects like missing virtual destructors (a common C++ pitfall taught in secure coding), though some third-party component cases or incomplete adoption leave a bounded remainder.
CWE-1088prevents — Secure coding standards directly require proper timeout configuration for synchronous remote calls.
CWE-1089removes — A.8.28 mandates secure coding practices, principles, standards, and reviews that reduce potential vulnerabilities during development, but does not mandate or perform any removal of an already-written excessive-indexes table design (a first-party code/architecture defect); per the verb definition and anchors, this is not removal.
CWE-109removes — A.8.28 mandates secure coding practices, principles, standards, defect removal, SAST, threat modeling, and prohibiting insecure techniques (including during Struts development), which removes the specific configuration flaw of turning off the Validator from first-party code; the bounded remainder is insecure reuse of already-compromised third-party Struts libraries where the control's own guidance falls back to inventory/update rather than mandating removal of the disabled-validator pattern.
CWE-1090removes — A.8.28 mandates secure coding practices, principles, standards, peer review, defect removal, prohibition of insecure techniques, and SAST during development, which directly removes this first-party code defect from the product before it ships; the bounded remainder is that the clause's governance processes and 'should' language leave room for incomplete or inconsistently applied enforcement on every instance.
CWE-1091prevents — Secure coding standards directly address proper destructor/finalizer invocation to avoid resource leaks.
CWE-1092removes — A.8.28 mandates secure coding principles, secure design/architecture (incl. threat modelling), prohibiting insecure techniques, removing defects, and evaluating attack surface/least privilege before release; this directly removes same-invokable-control-element duplication across layers when well-implemented, but leaves a bounded remainder for post-release maintenance and third-party component reuse scenarios where the flaw can still be introduced.
CWE-1095removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes loop-condition-update defects from first-party code (and reused/third-party components via inventory/vetting), but leaves a bounded remainder for defects that slip through imperfect implementation of those practices.
CWE-1096removes — A.8.28 mandates secure coding practices, principles, standards, design, peer review, defect removal, and prohibiting insecure techniques (including during new development and reuse); this directly removes singleton-without-synchronization defects from first-party code, with bounded remainder only in third-party components managed under the same clause.
CWE-1097removes — A.8.28's secure coding process (principles, standards, defect removal during coding/review, prohibiting insecure techniques, SAST, and analysis of common errors) removes this first-party code defect in most cases by ensuring the missing comparison method is implemented; remainder is incomplete application of the process to all storable elements or third-party components.
CWE-1098removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes first-party code defects like missing copy-control elements on pointer data (a historical defect per the clause), with a bounded remainder in incomplete adoption or third-party components.
CWE-1099removes — A.8.28 mandates secure coding practices, principles, standards, and defect removal during development to reduce potential vulnerabilities, but does not address or remove inconsistent naming conventions (a maintainability/readability issue, not a security vulnerability per the clause's stated purpose and guidance).
CWE-11prevents — Secure coding practices discourage leaving debug binaries in production but do not explicitly govern configuration settings.
CWE-1100prevents — Secure coding standards mandate separating platform-specific code into distinct modules to reduce coupling.
CWE-1102prevents — Secure coding standards explicitly prohibit or flag use of machine-dependent data representations, directly mitigating this weakness.
CWE-1103removes — A.8.28 is a first-party secure-coding practice that governs how the organization's own developers write and review code; CWE-1103 is a design-time reliance on an inherently non-portable third-party component, which secure coding neither removes from an already-written product nor prevents from being introduced under the CVE-mediating rule for first-party defect classes
CWE-1105removes — A.8.28's secure coding principles, standards, practices, defect removal, prohibition of insecure techniques, and secure design directly eliminate machine-dependent functionality that is insufficiently encapsulated from first-party code; the bounded remainder is third-party/open-source components (explicitly in scope but handled via inventory/update/selection rather than pure in-house coding).
CWE-1106prevents — Secure coding standards explicitly require use of symbolic constants instead of magic literals.
CWE-1106removes — A.8.28 mandates secure coding practices, standards, principles, and defect removal that directly target and eliminate literal/hard-coded constants in first-party source (via design, peer review, static analysis, and refactoring), removing the weakness; the bounded remainder is inconsistent application across all code, third-party components, or post-deployment evolution.
CWE-1107prevents — Secure coding standards explicitly call for centralized constant definitions to avoid duplication and errors.
CWE-1108prevents — Secure coding standards explicitly ban or restrict global variables to reduce coupling and side-effects.
CWE-1109removes — A.8.28 mandates secure coding practices, standards, peer review, removing defects, prohibiting insecure techniques, and SAST during development; this directly removes multi-purpose variable usage (a named historical defect) from first-party code before it ships, with a bounded remainder in third-party components and post-deployment maintenance.
CWE-111prevents — Secure coding standards explicitly ban or tightly control unsafe JNI calls, directly mitigating the weakness.
CWE-1110removes — A.8.28 mandates secure coding practices, principles, standards, reviews and defect removal during development but does not mandate or produce design documentation; the absence of adequate design documentation (CWE-1110) therefore remains after the control is applied
CWE-1113prevents — Secure coding policy can mandate consistent comment style as part of coding standards.
CWE-1113removes — A.8.28 mandates secure coding practices, principles, standards, and defect removal during development but does not reach or remove an already-written inconsistent comment style that is not itself a security vulnerability or exploitable defect
CWE-1114removes — A.8.28 mandates secure coding practices, principles, standards, defect removal and SAST during development; it does not reach or remove an already-written whitespace-style inconsistency that is the definition of CWE-1114
CWE-1116prevents — Secure coding practices typically mandate accurate, up-to-date comments as part of coding standards.
CWE-1118prevents — Secure coding standards mandate documented error-handling practices.
CWE-1119prevents — Secure coding standards explicitly prohibit excessive unconditional branching and mandate structured control flow.
CWE-1119removes — A.8.28's secure coding process (principles, standards, peer review, refactoring, removing defects, prohibiting insecure techniques, SAST) directly removes unconditional-branching bloat from first-party code; the bounded remainder is that it cannot reach already-shipped binaries or unmaintained third-party libraries whose source is unavailable.
CWE-112prevents — Secure coding standards directly require validation of untrusted XML against a proper schema.
CWE-1122removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and use of vetted/maintained components; this directly removes excessive Halstead complexity (a first-party code defect) from the product in most cases, with bounded remainder for complex legacy/reuse scenarios or where principles are applied inconsistently.
CWE-1123removes — A.8.28's secure coding principles, standards, prohibiting insecure techniques, removing defects, and secure design directly remove excessive self-modifying code from first-party software; the bounded remainder is third-party/open-source components where the clause only requires vetting and updating rather than mandating removal.
CWE-1124prevents — Secure coding standards explicitly forbid or limit excessive nesting to improve readability and reduce defects.
CWE-1124removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes excessive nesting (a named historical defect and structural complexity issue) from first-party code before it ships, with a bounded remainder in third-party components and incomplete enforcement across all developers/tools.
CWE-1126removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes unnecessarily-wide variable declarations from first-party code (a named historical defect), with a bounded remainder in third-party components and incomplete enforcement across all developers/tools.
CWE-113prevents — Secure coding standards require neutralization of CRLF sequences before inclusion in HTTP headers.
CWE-114prevents — Secure coding standards explicitly forbid executing or loading code from untrusted sources.
CWE-115prevents — Secure coding standards require strict input validation and canonical forms to eliminate misinterpretation vulnerabilities.
CWE-116prevents — Secure coding standards explicitly require correct output encoding and escaping to preserve message structure.
CWE-1164prevents — Secure coding standards explicitly require removal of unused or dead code.
CWE-117prevents — Secure coding practices mandate input validation and output encoding, directly preventing log injection.
CWE-1173prevents — Secure coding directly requires correct use of language-provided or approved validation libraries.
CWE-1174prevents — Secure coding practices directly require proper use of ASP.NET model validation attributes.
CWE-1174removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST, and analysis of common errors) directly removes this first-party ASP.NET model-validation flaw from the product before and during development; the bounded remainder is post-operational discovered instances handled only by cross-referenced A.8.8.
CWE-118prevents — Secure coding standards directly require bounds checking and safe array access to prevent range errors.
CWE-119prevents — Secure coding standards explicitly forbid unsafe buffer operations, directly eliminating CWE-119.
CWE-1190prevents — Secure coding practices can prevent early DMA initialization in firmware code.
CWE-1192removes — A.8.28 mandates secure coding practices, principles, standards, and reviews that reduce potential vulnerabilities during development, but does not mandate or remove the specific hardware/SoC design flaw of lacking unique immutable component identifiers (a first-party architectural defect outside its software-coding locus).
CWE-1193removes — A.8.28 is a first-party secure-coding and secure-design process that prevents certain classes of implementation defects; CWE-1193 is a specific hardware/firmware initialization sequencing flaw in an untrusted execution core, which this clause neither writes nor removes from an existing product.
CWE-12prevents — Secure coding practices include avoiding default error messages that leak implementation details.
CWE-120prevents — Secure coding directly requires bounds-checked memory operations, addressing the root cause of CWE-120.
CWE-1204prevents — Requires secure coding practices that include proper cryptographic API usage and IV handling.
CWE-121prevents — Secure coding standards explicitly forbid unsafe buffer handling that causes CWE-121.
CWE-122prevents — Secure coding standards directly prescribe techniques (safe functions, bounds checks) that prevent heap-based buffer overflows.
CWE-1221prevents — Secure coding practices for HDL reduce the likelihood of defining insecure register defaults or IP parameters.
CWE-1223prevents — Secure coding guidelines for hardware description languages can enforce proper write-once attribute protection and initialization order.
CWE-1224removes — A.8.28 is a first-party secure-coding process control that removes classes of defects introduced in the organization's own code; CWE-1224 is a hardware design flaw in sticky-bit implementation, outside the software-coding locus and never removed by secure-coding practices (per the explicit first-party-code-defect rule).
CWE-123prevents — Secure coding standards explicitly forbid unsafe buffer operations that enable arbitrary memory writes.
CWE-123removes — A.8.28 mandates secure coding practices, principles, standards, defect removal, prohibition of insecure techniques, and SAST that directly target and eliminate first-party code defects like arbitrary-write conditions before they reach production; the bounded remainder is incomplete application of those practices across all languages, third-party components, or edge cases not caught in review.
CWE-1231prevents — Secure coding can avoid software paths that modify lock bits, yet cannot guarantee the underlying hardware prevents such writes.
CWE-1236prevents — Secure coding standards explicitly require neutralization of special characters when writing CSV files.
CWE-124prevents — Secure coding standards explicitly forbid unsafe pointer arithmetic and mandate bounds checks.
CWE-1240prevents — Secure coding standards prohibit non-standard or disallowed cryptographic algorithms.
CWE-1241prevents — Secure coding standards prohibit use of weak or predictable RNG functions.
CWE-1242prevents — Secure coding standards and peer review detect and prohibit undocumented or debug features.
CWE-1243removes — A.8.28 is a first-party secure-coding governance and practice control that removes code defects during development; CWE-1243 is a hardware/fuse protection weakness in a manufactured chip that is never written as software and is outside the locus of secure coding
CWE-1245prevents — Secure coding guidelines can extend to hardware description languages to prevent FSM coding errors.
CWE-1246prevents — Secure coding practices must implement or correctly invoke wear-leveling algorithms for limited-write non-volatile memories.
CWE-125prevents — Secure coding standards explicitly forbid unsafe pointer arithmetic and mandate bounds-checked reads, eliminating CWE-125.
CWE-1252removes — A.8.28 is a first-party secure-coding process that removes code defects written by the organization; CWE-1252 is a CPU hardware configuration weakness outside the software development locus, so the control performs the verb against none of this class (per the explicit first-party vs. hardware/component boundary in the verb definition).
CWE-1254prevents — Secure coding standards can require constant-time comparison functions to avoid stepwise string comparison vulnerabilities.
CWE-1255prevents — Secure coding standards can mandate constant-time comparison routines and power-analysis-resistant implementations.
CWE-1256prevents — Secure coding practices can enforce input validation and capability checks on hardware-control APIs, reducing the likelihood of unintended register or memory changes.
CWE-1257prevents — Secure coding practices can catch alias-permission mismatches during implementation.
CWE-1259prevents — Secure coding practices reduce the likelihood of token-assignment bugs but do not define the policy.
CWE-126prevents — Secure coding standards directly require bounds-checked buffer access, mitigating over-reads.
CWE-1260prevents — Secure coding standards mandate checks for address-range overlap and proper memory-protection configuration, mitigating the weakness at implementation time.
CWE-1261removes — A.8.28 is a first-party secure-coding and secure-design process that addresses software defects in in-house and outsourced code; CWE-1261 is a hardware-logic design flaw about single-event upsets that lives outside the software-coding locus this control reaches.
CWE-1262prevents — Secure coding practices prevent unauthorized register access in firmware and drivers.
CWE-1265prevents — Secure coding standards and reviews directly target reentrancy issues and non-reentrant code patterns.
CWE-1265removes — A.8.28's secure coding principles, standards, defect removal, prohibition of insecure techniques, SAST, and peer review directly remove first-party reentrancy defects during development; remainder is third-party components (explicitly in scope but handled via inventory/update rather than code rewrite) and post-release discoveries addressed only by reference to A.8.8.
CWE-1266removes — A.8.28 is a secure-coding governance and practice clause that prevents first-party defects during development; it does not act on already-written sensitive-data scrubbing logic that is missing/incorrect in a decommissioned device (a post-development, often hardware-adjacent flaw outside its locus).
CWE-1268removes — A.8.28 is a first-party secure-coding governance and practice control that removes many code defects (per its own guidance on standards, peer review, removing defects, SAST); CWE-1268 is a hardware design flaw in inconsistent privilege policy between control and data agents, outside the software-coding locus this clause reaches and explicitly scoped by the removes verb to exclude first-party code-defect classes reached only via CVE-mediated third-party patching.
CWE-127prevents — Secure coding standards directly require bounds checking and safe pointer arithmetic.
CWE-1270prevents — Secure coding standards reduce the likelihood of implementation errors that produce incorrect tokens.
CWE-1272prevents — Secure-coding practices can prevent the weakness if applied, but the control itself is broader than this specific flaw.
CWE-1275prevents — Secure coding standards directly require proper SameSite settings to prevent CSRF.
CWE-1276removes — A.8.28 is a first-party secure-coding and secure-design process that removes defects written into the organization's own code; CWE-1276 is a hardware design flaw in how an IP block is wired into a parent system, which is outside the software-coding locus and is explicitly excluded by the CVE-mediated / first-party-code-defect rule
CWE-1277removes — A.8.28 mandates secure coding practices, principles, standards, and defect removal during development to reduce vulnerabilities in first-party code; it has no mechanism that removes or patches already-shipped non-updateable firmware (a post-deployment product property), and CVE-mediated patching rules explicitly bar removal claims on first-party code-defect classes like this.
CWE-1278removes — A.8.28 is a first-party secure-coding and secure-design process that removes code-level defects and insecure design choices; CWE-1278 is a hardware-level physical reverse-engineering weakness that cannot be coded away and is explicitly excluded by the CVE-mediate rule for first-party code-defect classes
CWE-1279prevents — Secure coding practices can prevent cryptographic operations before supporting units are ready.
CWE-128prevents — Secure coding standards directly require avoidance of integer overflow and wrap-around conditions.
CWE-1281prevents — Secure coding guidelines can require avoidance of known problematic instruction sequences and use of validated libraries.
CWE-1282prevents — Secure coding practices can avoid storing immutable data in writable memory but do not address hardware-level protection.
CWE-1284prevents — Secure coding standards require explicit checks on numeric quantity inputs, fully addressing CWE-1284.
CWE-1285prevents — Secure coding standards directly require validation of indices, positions, and offsets before use.
CWE-1285removes — A.8.28 mandates secure coding practices, standards, defect removal, SAST, and analysis of common errors (including index/offset validation) during development, so well-implemented secure coding removes most CWE-1285 instances from first-party code; the bounded remainder is inconsistent application across all entry points, languages, or third-party components where the clause's governance does not reach.
CWE-1286prevents — Secure coding standards directly require proper syntactic validation of all inputs.
CWE-1287prevents — Secure coding standards directly require proper type validation of all external inputs.
CWE-1288prevents — Secure coding standards explicitly require validation of interrelated input fields to prevent CWE-1288.
CWE-1289prevents — Secure coding standards directly require correct validation of resource identifiers and equivalence checks.
CWE-129prevents — Secure coding standards explicitly require bounds checking and validation of array indices derived from untrusted data.
CWE-1290removes — A.8.28 mandates secure coding practices, principles, standards, threat modeling, defect removal, and prohibiting insecure techniques (including during design/architecture for new and reused code), which directly removes this first-party decoding flaw from the product before it ships; the bounded remainder is post-operational reported vulnerabilities (explicitly handed to A.8.8) and third-party component defects (explicitly scoped out of this clause's own first-party focus).
CWE-1291prevents — Secure-coding standards can mandate distinct signing keys and prohibit reuse between debug and production builds.
CWE-1291removes — A.8.28's secure coding principles, prohibiting insecure techniques like hard-coded elements, secure design/threat modeling, peer review, SAST, and vetting of components can remove re-used signing keys from first-party code before release, but this is only a minority slice as the weakness is often introduced via third-party libraries, build processes, or post-coding maintenance not fully dictated by the clause.
CWE-1292removes — A.8.28 mandates secure coding principles, standards, secure design/threat modeling, prohibiting insecure techniques, removing defects, and using vetted components during in-house and third-party development, which removes this first-party conversion flaw from the product before it ships; the bounded remainder is post-operational code changes or vendor-modified packages where the clause's own guidance on risk and consent may not reach full removal.
CWE-1295prevents — Secure coding practices mandate removal or protection of debug output containing sensitive information before release.
CWE-1296removes — A.8.28's secure coding principles, standards, defect removal, prohibition of insecure techniques, SAST, and peer review during development directly remove first-party debug-component chaining/granularity defects before the product ships; the bounded remainder is post-operational or third-party component cases where 8.28 defers to 8.8/8.29.
CWE-1297removes — A.8.28 is a first-party secure-coding and secure-design process that prevents or removes code defects in software written by the organization; CWE-1297 is a hardware-level manufacturing weakness about unprotected confidential information accessible to OSAT vendors during semiconductor assembly/test, not a first-party code defect
CWE-13removes — A.8.28's secure coding process (principles, standards, prohibiting hard-coded passwords, removing defects, secure design, vetting components) directly removes plaintext password storage from first-party and third-party code/config during development; remainder is post-operational misconfigurations or unmodified vendor packages outside the coding baseline.
CWE-130prevents — Secure coding standards directly prohibit improper length handling and enforce defensive parsing practices.
CWE-131prevents — Secure coding standards directly require correct buffer-size calculations.
CWE-1311removes — A.8.28 is a first-party secure-coding governance and practice clause that prevents certain code defects from being written; CWE-1311 is a specific hardware-fabric translation flaw (not a first-party code defect prevented by secure coding), and per the supplied doctrine a CVE-mediated or third-party/component class is graded none on removes for this control
CWE-1312prevents — Secure coding practices can avoid mirror-region oversights, yet the weakness is primarily a hardware-design flaw.
CWE-1312removes — A.8.28 is a first-party secure-coding practice that removes certain code defects by mandating their avoidance; CWE-1312 is a hardware on-chip fabric design flaw (missing firewall coverage of mirrored regions) outside the software-coding locus, so the control removes nothing of it per the first-party code-defect rule
CWE-1314prevents — Secure coding practices can prevent software from writing to protected parameter areas but do not address the underlying hardware protection gap.
CWE-1314removes — A.8.28 mandates secure coding practices, principles, standards, and reviews that can keep this parametric-data flaw out of first-party code (Q2), but does not remove an already-written instance of CWE-1314; that is a code defect, not a third-party/component class, so the CVE-mediated removal doctrine does not apply and the verb is not performed
CWE-1318removes — A.8.28 is a first-party secure-coding and secure-design process that removes classes of coding defects from in-house software; CWE-1318 is a hardware design flaw in on-chip fabrics/buses (a third-party or silicon-level class outside the software-development locus), so the control performs the verb against none of this weakness per the owner ruling on first-party code-defect classes.
CWE-1320prevents — Secure coding practices reduce the risk of improper outbound error handling.
CWE-1321prevents — Secure coding standards directly prohibit unsafe prototype attribute assignment and require defensive checks.
CWE-1322prevents — Secure coding standards directly prohibit blocking operations inside single-threaded event loops.
CWE-1325prevents — Secure coding standards can require explicit limits on memory per object, yet fixing the weakness alone does not satisfy the full control.
CWE-1327prevents — Secure coding guidance can catch hard-coded 0.0.0.0 bindings during development but is not the primary mitigation.
CWE-1333prevents — Secure coding standards explicitly prohibit or limit the use of inefficient regular expressions.
CWE-1335prevents — Secure coding directly addresses the use of safe bitwise-shift operations and bounds checking.
CWE-1336prevents — Secure coding standards require proper escaping or sandboxing of template directives, directly mitigating CWE-1336.
CWE-1338removes — A.8.28 is a first-party secure-coding and secure-design process that removes classes of software defects introduced during development; CWE-1338 is a hardware design weakness about missing physical/thermal-protection circuitry, which this control never authors or removes.
CWE-1339removes — A.8.28 mandates secure coding practices, principles, defect removal during coding/review, and use of vetted components, which removes some classes of numeric-precision defects (e.g. via standards that forbid error-prone floating-point idioms), but leaves a large remainder (algorithmic/rounding choices, library precision limits, and implementation-specific decisions not covered by generic secure-coding baselines).
CWE-134prevents — Secure coding standards directly forbid the use of untrusted format strings and prescribe safe alternatives.
CWE-1341prevents — Secure-coding standards directly address proper resource-release discipline, preventing multiple-close errors.
CWE-135prevents — Secure coding directly addresses proper calculation of multi-byte string lengths through coding standards and reviews.
CWE-1351removes — A.8.28 is a first-party secure-coding governance and practice control that removes classes of software defects introduced during in-house development; CWE-1351 is a hardware/firmware design flaw concerning physical temperature effects on security primitives, which this clause never touches or removes.
CWE-138prevents — Secure coding standards require proper escaping and neutralization of special elements, directly eliminating CWE-138.
CWE-1385prevents — Secure coding standards can explicitly require origin validation for WebSocket connections.
CWE-1386prevents — Secure coding standards directly address safe file/directory handling to prevent insecure junction operations.
CWE-1389prevents — Secure coding standards directly mandate safe numeric parsing and validation of input bases.
CWE-1391prevents — Secure-coding rules can prohibit hard-coded passwords, yet coverage depends on specific coding standards adopted.
CWE-14prevents — Secure coding rules can mandate explicit volatile or memory-clearing patterns that survive compiler optimization.
CWE-140prevents — Secure coding explicitly requires proper neutralization of delimiters to prevent injection and parsing flaws.
CWE-141prevents — Secure coding standards require proper escaping or neutralization of parameter delimiters in all downstream calls.
CWE-142prevents — Secure coding explicitly calls for proper escaping or encoding of value delimiters in downstream contexts.
CWE-1420removes — A.8.28 is a first-party secure-coding process control that removes code defects by mandating secure practices, standards, reviews and SAST during development; CWE-1420 is a transient-execution side-channel class (Spectre-class) whose root cause is in processor microarchitecture, not in any software coding choice the developer controls.
CWE-1421removes — A.8.28 is a first-party secure-coding process control that removes code defects introduced during in-house development; CWE-1421 is a hardware transient-execution side-channel class (Spectre-class) residing in the processor's microarchitectural structures, not a software coding flaw the organization's developers write or remove.
CWE-1422removes — A.8.28 is a first-party secure-coding governance and practice control that reduces defects during in-house development; CWE-1422 is a transient-execution microarchitectural data-exposure class (Spectre-like) that lives in processor hardware behavior, not in software coding errors the organization writes or can remove from its own code.
CWE-1423removes — A.8.28 is a first-party secure-coding process control that removes code defects written by the organization; CWE-1423 is a hardware microarchitectural design flaw in the CPU, not a software coding defect that secure coding can remove from the product.
CWE-1427removes — A.8.28 mandates secure coding practices, principles, standards, threat modeling, defect removal, prohibition of insecure techniques, SAST, and peer review that directly target and eliminate prompt-construction flaws (including LLM injection) from first-party code before it ships; the bounded remainder is incomplete uptake of LLM-specific guidance in the 'continual improvement' clause or third-party components.
CWE-1429removes — A.8.28 is a first-party secure-coding and secure-design process that prevents or removes code defects introduced by the organization; CWE-1429 is a hardware-interface design omission whose removal would require changing a chip's RTL or silicon, not software coding practices.
CWE-143prevents — Secure coding standards require proper escaping or neutralization of record delimiters in all downstream interfaces.
CWE-144prevents — Secure coding standards directly require proper neutralization of line delimiters in input handling.
CWE-145prevents — Secure coding standards require correct neutralization of section delimiters in all downstream outputs.
CWE-146prevents — Secure coding standards require proper neutralization of special elements, directly eliminating this weakness.
CWE-147prevents — Secure coding standards require explicit neutralization of input terminators, directly eliminating this weakness.
CWE-148prevents — Secure coding standards directly require proper neutralization of input leaders, covering most of this weakness.
CWE-149prevents — Secure coding standards require proper escaping or parameterization, directly eliminating CWE-149.
CWE-150prevents — Secure coding standards require proper escaping and neutralization of control characters before downstream processing.
CWE-151removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes comment-delimiter neutralization defects from first-party code before it ships, with a bounded remainder around incomplete enforcement or third-party components that the clause itself addresses only by inventory/update.
CWE-152removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes macro-symbol neutralization defects from first-party code (and managed third-party components) before they ship, with bounded remainder in incomplete adoption or post-shipment changes.
CWE-153prevents — Secure coding standards require proper neutralization of substitution characters in all input handling.
CWE-154prevents — Secure coding standards require proper escaping or parameterization of all variable-name delimiters, directly eliminating CWE-154.
CWE-155prevents — Secure coding standards explicitly require proper escaping or neutralization of wildcard and matching symbols.
CWE-156prevents — Secure coding standards directly require proper input sanitization and neutralization of special elements like whitespace.
CWE-157prevents — Secure coding standards directly mandate sanitizing paired delimiters to prevent injection or parsing errors.
CWE-158prevents — Secure coding standards explicitly require proper neutralization of null bytes and other metacharacters.
CWE-159prevents — Secure coding standards require proper escaping, quoting and validation of special characters in user input.
CWE-160prevents — Secure coding standards require proper neutralization of leading special elements in all input paths.
CWE-161removes — A.8.28 mandates secure coding practices, principles, standards, defect removal, prohibition of insecure techniques, SAST, and peer review that directly eliminate multiple-leading-special-element neutralization defects from first-party code before it ships; the bounded remainder is incomplete uptake of those practices on every code path or third-party component that the clause treats as governance rather than direct removal.
CWE-162prevents — Secure coding standards directly require correct neutralization of trailing special elements in input handling.
CWE-163removes — A.8.28 mandates secure coding practices, standards, defect removal, prohibition of insecure techniques, SAST, and peer review that directly eliminate multiple-trailing-special-element flaws from first-party code before it ships; the bounded remainder is third-party/open-source components whose handling lives in the same clause but is not guaranteed to reach every instance.
CWE-164prevents — Secure coding standards require proper escaping and neutralization of special elements, directly mitigating CWE-164.
CWE-165removes — A.8.28 mandates secure coding practices, standards, defect removal, SAST, and prohibiting insecure techniques that directly target and eliminate multiple-internal-special-element neutralization defects from first-party code before it ships; the bounded remainder is incomplete application of those practices across all languages, third-party components, or post-deployment maintenance changes.
CWE-166prevents — Secure coding standards directly require validation for missing special elements, covering most of this weakness.
CWE-167prevents — Secure coding standards directly require correct handling of all input elements, eliminating this weakness.
CWE-168prevents — Secure coding standards explicitly require proper handling of special characters and reserved words.
CWE-170prevents — Secure coding standards directly require correct null termination of strings and arrays.
CWE-172prevents — Secure coding explicitly requires correct character encoding and output escaping to avoid CWE-172.
CWE-173prevents — Secure coding standards explicitly require proper handling of alternate encodings and canonical forms to avoid injection or bypass flaws.
CWE-175removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques; this removes most mixed-encoding handling defects from first-party code before release, with a bounded remainder in incomplete application to all languages, third-party components, or edge cases missed by the baseline.
CWE-176prevents — Secure coding standards directly address proper Unicode and character-encoding validation.
CWE-177prevents — Secure coding standards mandate proper handling and decoding of encoded inputs, eliminating CWE-177.
CWE-178prevents — Secure coding guidelines must mandate explicit case handling to prevent inconsistent lookups.
CWE-179prevents — Secure coding standards explicitly require canonicalization before validation to avoid CWE-179.
CWE-180prevents — Secure coding standards explicitly require canonicalize-then-validate to eliminate CWE-180.
CWE-181removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, and prohibiting insecure techniques that directly produce validate-before-filter order; this removes the first-party code defect in most cases, with a bounded remainder in incomplete adoption or complex third-party reuse scenarios.
CWE-182prevents — Secure coding standards explicitly forbid unsafe filtering or collapsing of security-critical values.
CWE-183prevents — Secure coding standards enforce rigorous input validation and reject unsafe values, mitigating permissive allow-list weaknesses.
CWE-183removes — A.8.28 mandates secure coding practices, standards, principles, defect removal, prohibition of insecure techniques, and SAST that directly target and eliminate permissive allow-lists during development (preventing the flaw from existing in the product), but leaves a bounded remainder for complex/undocumented historical defects or third-party component reuse not caught by the baseline.
CWE-184prevents — Secure coding standards directly require exhaustive allow-lists or complete deny-lists for inputs, addressing the root cause of incomplete disallowed-input lists.
CWE-185prevents — Secure coding standards directly address proper construction and review of regular expressions.
CWE-186prevents — Secure coding standards directly mandate proper regex design and testing, largely preventing this weakness.
CWE-187prevents — Secure coding standards can explicitly prohibit substring-based comparisons for security decisions.
CWE-188prevents — Secure coding standards and reviews target unsafe reliance on implicit data layout.
CWE-190prevents — Secure coding standards explicitly forbid unsafe integer operations and mandate overflow-safe constructs.
CWE-191prevents — Secure coding standards directly prescribe safe integer handling and overflow/underflow prevention.
CWE-192prevents — Secure coding standards directly address integer coercion through language-specific rules and static analysis.
CWE-193prevents — Secure coding directly addresses off-by-one errors through coding standards and peer review.
CWE-194prevents — Secure coding standards directly address integer handling and sign-extension pitfalls in source code.
CWE-195prevents — Secure coding standards directly prohibit unsafe signed-to-unsigned casts and require defensive checks.
CWE-196prevents — Secure coding standards directly address avoiding unsafe casts from unsigned to signed integers.
CWE-197prevents — Secure coding standards directly prohibit unsafe narrowing conversions and truncation.
CWE-198prevents — Secure coding standards directly require correct byte-order handling when processing external input.
CWE-20prevents — Requiring language-specific secure coding standards, peer review, SAST and documented mitigation of common programming errors forces validation of all inputs before they are trusted.
CWE-200prevents — Source-code protection via configuration-management tools and access-control rules reduces the chance that sensitive implementation details or credentials will be exposed to unauthorized readers.
CWE-201prevents — Secure-coding standards explicitly forbid hard-coded or unfiltered sensitive data in outbound messages.
CWE-202prevents — Secure coding practices can implement query restrictions or result-set limits to reduce inference risk.
CWE-204prevents — Secure coding standards explicitly require uniform error handling to prevent information leakage.
CWE-205prevents — Secure coding standards can require consistent, non-informative error messages and timing behavior.
CWE-207prevents — Secure coding practices can prevent implementation differences that leak product identity.
CWE-209prevents — Secure coding standards explicitly forbid exposing sensitive data in errors.
CWE-210prevents — Secure coding standards directly prohibit embedding sensitive information in generated error messages.
CWE-212prevents — Secure-coding standards can mandate removal of secrets and PII from code and logs.
CWE-214prevents — Secure coding practices can prevent passing sensitive data via command-line arguments or environment variables.
CWE-215prevents — Secure coding standards explicitly prohibit embedding secrets or debug statements.
CWE-22prevents — Secure coding standards explicitly forbid unsafe path construction and mandate safe APIs.
CWE-226prevents — Secure coding practices can prevent leaving sensitive data in memory or files before reuse.
CWE-228prevents — Secure coding explicitly requires validation of all input syntax and structure, directly eliminating CWE-228.
CWE-229prevents — Secure coding standards mandate proper handling of missing or undefined parameters, directly addressing this weakness.
CWE-23prevents — Secure coding standards require neutralizing path traversal sequences, directly addressing CWE-23.
CWE-230prevents — Secure coding standards can require validation that every supplied parameter has a non-null value.
CWE-231prevents — Secure coding standards directly require validation of the exact number and type of input parameters.
CWE-232prevents — Secure coding standards directly require defensive checks for undefined or unsupported parameter values.
CWE-233prevents — Secure coding standards directly address proper handling of function parameters and input validation.
CWE-234prevents — Secure coding standards directly address proper argument validation and handling of missing or unexpected parameters.
CWE-234removes — A.8.28's secure coding process (principles, standards, defect removal during coding/review, prohibiting insecure techniques, SAST, and analysis of common errors) removes most instances of this first-party code defect before release; the bounded remainder is ad-hoc/variable-argument cases or post-release code not reached by the process.
CWE-235prevents — Secure coding standards directly require proper handling of input parameters and arrays to avoid CWE-235.
CWE-236prevents — Secure coding standards directly address proper handling of undefined or unsupported parameters during implementation.
CWE-237prevents — Secure coding standards directly address proper handling and validation of structured data elements.
CWE-239prevents — Secure coding standards typically include rules for validating element completeness, directly addressing CWE-239.
CWE-24prevents — Secure coding standards require neutralizing ../ sequences and canonicalizing paths before file operations.
CWE-240prevents — Secure coding standards address consistent parsing and validation of structural elements.
CWE-241prevents — Secure coding standards explicitly require type checking and input sanitization, directly addressing improper handling of unexpected data types.
CWE-242prevents — Secure coding standards explicitly ban or restrict inherently dangerous functions.
CWE-243removes — A.8.28's secure coding principles, standards, defect removal, prohibition of insecure techniques, and SAST directly remove chroot-without-chdir defects from first-party code during development; the bounded remainder is third-party/open-source components whose insecure use is governed only by inventory/update rules rather than by the coding practices themselves.
CWE-244prevents — Mandates secure coding practices that include proper memory sanitization before release.
CWE-245removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes this first-party J2EE connection-management flaw from the codebase before it ships; the bounded remainder is that the clause's governance/continual-improvement language leaves room for incomplete uptake of the specific practice on a given project.
CWE-246removes — A.8.28's secure coding process (principles, standards, prohibiting insecure techniques, removing defects, peer review, SAST) directly removes the first-party code defect of using raw sockets instead of framework calls; the bounded remainder is that it depends on the rigour of the implementer and does not reach every possible insecure socket use that might slip through.
CWE-248prevents — Secure coding standards directly require catching and handling exceptions to prevent crashes or leaks.
CWE-25prevents — Secure coding standards require canonicalization and neutralization of '../' sequences in path construction.
CWE-252prevents — Secure coding explicitly requires checking return values to avoid CWE-252.
CWE-253prevents — Secure coding explicitly demands checking return values, covering most of CWE-253.
CWE-256prevents — Secure coding practices would prevent developers from writing code that stores passwords in plaintext.
CWE-257prevents — Secure coding practices can prevent developers from implementing recoverable password storage.
CWE-258prevents — Secure coding standards explicitly forbid hard-coded or empty credentials.
CWE-26prevents — Secure coding standards require neutralizing '../' sequences and canonicalizing paths before file operations.
CWE-260prevents — Secure coding standards discourage hard-coded credentials, reducing the likelihood of passwords in configuration files.
CWE-261prevents — Enforces secure coding practices that would reject trivial password encoding.
CWE-267prevents — Secure coding practices can avoid unsafe privilege implementations but do not address privileges already defined.
CWE-27prevents — Secure coding standards require neutralizing '../' sequences and using safe file APIs, eliminating this exact weakness.
CWE-270prevents — Secure-coding guidelines can prevent common privilege-switch bugs yet are not exhaustive.
CWE-271prevents — Secure coding standards can mandate privilege-dropping calls, yet the control is broader than this single weakness.
CWE-272prevents — Secure coding practices can prevent least-privilege violations but do not constitute the control itself.
CWE-273prevents — Secure coding practices can prevent missing privilege-drop checks, but the control itself does not mandate verification of privilege changes.
CWE-274prevents — Secure-coding standards may require proper privilege-error handling, but the control does not guarantee it.
CWE-274removes — A.8.28 mandates secure coding practices, secure design (incl. least privilege and attack surface), removal of defects, and prohibiting insecure techniques such as hard-coded credentials; this removes most instances of improper privilege handling from first-party code, with a bounded remainder in third-party components and incomplete application of the principles.
CWE-277prevents — Secure coding standards can explicitly require setting restrictive permissions at object creation, directly mitigating insecure inheritance.
CWE-277removes — A.8.28's secure coding principles, standards, defect removal, prohibition of insecure techniques, and secure design (including least privilege and attack surface) directly remove the insecure inherited permissions flaw from first-party code; the bounded remainder is third-party/open-source components where the clause only requires inventory/selection rather than mandating removal.
CWE-278prevents — Secure coding standards can mandate explicit permission setting instead of relying on inherited defaults.
CWE-279prevents — Secure coding practices can prevent the coding error that leads to incorrect permission assignment.
CWE-28prevents — Secure coding standards explicitly forbid unsafe path construction and mandate neutralization of .. sequences.
CWE-280prevents — Secure-coding standards require proper permission checks before resource access.
CWE-288prevents — Secure coding practices help avoid bypass vulnerabilities but do not address deployed instances.
CWE-29prevents — Secure coding standards directly require neutralizing path traversal sequences such as '\..\filename'.
CWE-29removes — A.8.28's secure coding process (principles, standards, defect removal, prohibiting insecure techniques, SAST, peer review) directly removes this first-party code defect from the product before release; the bounded remainder is incomplete uptake of its own listed practices (e.g. historical defects, language-specific rules) or post-release code changes.
CWE-290prevents — Secure coding practices reduce implementation errors that enable spoofing.
CWE-293prevents — Secure coding standards would forbid using Referer for authentication, mitigating the weakness at the source.
CWE-296prevents — Secure coding standards address correct certificate chain validation.
CWE-297prevents — Secure coding practices include implementing proper certificate and hostname validation in code.
CWE-298prevents — Secure coding practices can include certificate validation checks but do not address the control's broader scope.
CWE-299prevents — Secure coding practices should include proper certificate revocation verification.
CWE-30prevents — Secure coding standards require neutralizing directory traversal sequences such as '\..\' in path construction.
CWE-301prevents — Secure coding practices can implement proper challenge-response logic, but the control is broader than this single weakness.
CWE-302prevents — Secure-coding standards prohibit trusting client-controlled data for authentication decisions.
CWE-303prevents — Secure coding practices reduce the likelihood of incorrect authentication algorithm implementation.
CWE-304prevents — Secure coding practices can prevent missing auth steps, yet the control is not specific to authentication.
CWE-305prevents — Secure coding practices help prevent the primary weakness that enables authentication bypass.
CWE-31prevents — Secure coding standards require canonicalization and whitelist validation that eliminate CWE-31.
CWE-313prevents — Secure coding standards can require encryption of sensitive data before storage.
CWE-314prevents — Secure coding standards require encryption or protected storage instead of cleartext registry values.
CWE-315prevents — Requires secure coding practices that would eliminate storing sensitive data in cleartext cookies.
CWE-316prevents — Secure-coding standards explicitly require avoiding plaintext storage of secrets in RAM.
CWE-317prevents — Secure coding practices can prevent the weakness but do not address the control's broader scope.
CWE-318prevents — Secure coding standards explicitly forbid embedding secrets or sensitive data in binaries.
CWE-32prevents — Secure coding standards require canonicalization and filtering of '...' sequences, directly eliminating CWE-32.
CWE-322prevents — Secure coding standards can enforce authenticated key exchange in cryptographic implementations.
CWE-323prevents — Secure-coding rules can require unique nonces, but the control is broader than this single weakness.
CWE-325prevents — Requires secure coding practices that would catch missing cryptographic steps during development.
CWE-328prevents — Requires secure coding standards that forbid weak hash functions in source code.
CWE-329prevents — Requires secure coding practices that eliminate predictable IV usage in CBC implementations.
CWE-33removes — A.8.28's secure coding process (principles, standards, defect removal during coding/review, prohibiting insecure techniques, SAST) directly removes '....' path-traversal defects from first-party and in-house code before release; the bounded remainder is third-party/open-source components whose handling lives in the separate library-management slice of the clause.
CWE-330prevents — Secure coding standards explicitly prohibit use of weak or predictable random number generators.
CWE-331prevents — Secure-coding rules can explicitly forbid weak random-number generation.
CWE-332prevents — Secure coding standards prohibit weak PRNG usage and require cryptographically secure random functions.
CWE-333prevents — Secure-coding rules can require fallback or health checks for TRNG entropy sources.
CWE-334prevents — Secure-coding standards explicitly call for cryptographically strong random number generation.
CWE-335prevents — Secure-coding standards mandate correct PRNG seeding to avoid predictable random values.
CWE-336prevents — Secure-coding standards can forbid static seeds, yet the control is broader than this single weakness.
CWE-337prevents — Secure coding standards explicitly forbid predictable PRNG seeds.
CWE-338prevents — Secure coding standards prohibit use of weak PRNGs in security contexts.
CWE-339prevents — Requires secure coding practices that include proper PRNG seeding and entropy sources.
CWE-34prevents — Secure coding standards require canonicalization and neutralization of '....//' sequences, directly eliminating this weakness.
CWE-340prevents — Secure-coding standards explicitly forbid predictable random functions and mandate cryptographically secure RNGs, preventing the weakness at the source.
CWE-341prevents — Secure coding practices explicitly forbid use of predictable state (time, PID, counters) for secrets or tokens.
CWE-342prevents — Secure coding standards prohibit predictable random-value generation.
CWE-343prevents — Secure coding standards prohibit predictable RNG implementations.
CWE-344prevents — Secure coding standards can prohibit invariant literals, but coverage depends on specific rule sets.
CWE-345prevents — Secure coding practices include implementing proper data authenticity checks.
CWE-346prevents — Secure coding practices include implementing proper origin validation to prevent spoofing.
CWE-348prevents — Secure coding practices can enforce checks that prefer or validate the more trusted data source.
CWE-349prevents — Secure coding standards mandate input sanitization and provenance checks that prevent acceptance of extraneous untrusted data.
CWE-35prevents — Secure coding standards explicitly forbid unsafe path concatenation and mandate canonicalization routines.
CWE-350prevents — Secure coding practices can replace reverse-DNS checks with cryptographically verified identities.
CWE-351prevents — Secure coding standards directly address proper type distinction and validation to prevent type-related flaws.
CWE-353prevents — Secure coding standards can require integrity verification mechanisms in protocols.
CWE-354prevents — Secure coding standards require proper implementation and validation of checksums or MACs.
CWE-356prevents — Secure coding practices can embed user warnings before unsafe operations.
CWE-357prevents — Secure coding practices include implementing noticeable, effective UI warnings for risky actions.
CWE-358prevents — Secure coding practices directly address correct implementation of security-relevant checks in standardized algorithms.
CWE-36prevents — Secure coding standards directly require neutralization of absolute path sequences in pathname construction.
CWE-362prevents — Secure coding standards explicitly forbid unsafe concurrent access patterns and mandate atomic operations or locks.
CWE-363prevents — Secure coding standards directly address TOCTOU and link-following vulnerabilities, covering most of the weakness while the control also covers many other issues.
CWE-364prevents — Secure coding standards directly prohibit race-prone signal handlers.
CWE-366prevents — Secure coding standards directly require proper synchronization primitives to prevent race conditions.
CWE-368prevents — Secure coding standards can mandate atomic operations and synchronization primitives for context switches.
CWE-369prevents — Secure coding standards directly require validation to prevent divide-by-zero and similar runtime faults.
CWE-37prevents — Secure coding standards directly require validation of file-path inputs to stop absolute-path traversal.
CWE-370prevents — Secure coding practices can prevent missing revocation checks, but eliminating this weakness does not address broader secure-coding objectives.
CWE-372prevents — Secure coding standards can require defensive checks against invalid or ambiguous internal states.
CWE-372removes — A.8.28's secure coding process (principles, standards, defect removal during coding/review, prohibiting insecure techniques, SAST, threat modeling, and post-operational adjustments) removes most instances of incomplete internal state distinction from first-party code; the bounded remainder is inconsistent application across all developers, languages, or complex state machines where defects still slip through.
CWE-374prevents — Secure coding standards directly address CWE-374 by requiring defensive copies or immutable interfaces when calling untrusted methods.
CWE-375removes — A.8.28's secure coding principles, standards, defect removal, prohibition of insecure techniques, and SAST directly remove this first-party code defect from the product; the bounded remainder is that some mutable-return patterns may still slip through incomplete peer review or language-specific guidance.
CWE-377prevents — Secure coding standards explicitly require safe temporary-file APIs and permissions.
CWE-378prevents — Secure coding standards directly prohibit insecure temporary file creation and permissions.
CWE-378removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, prohibition of insecure techniques, and secure design that directly eliminate the insecure temporary-file permission flaw from first-party code before it ships; the bounded remainder is third-party/open-source components whose handling lives in the same clause but is not guaranteed by the organization's own coding process.
CWE-379prevents — Secure coding standards directly require safe temporary-file creation with restrictive permissions.
CWE-379removes — A.8.28 mandates secure coding practices, standards, principles, and defect removal that directly target insecure file permission issues during development (including temp-file handling), so well-implemented secure coding removes most instances of this first-party code defect from the product; the bounded remainder is insecure defaults or third-party library behavior addressed only by later maintenance clauses.
CWE-38prevents — Secure-coding standards require canonicalization and whitelist validation of file paths, eliminating this weakness.
CWE-382removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes the System.exit() call from first-party J2EE code during development; remainder is third-party/open-source components where the clause only requires inventory/update rather than guaranteed excision.
CWE-383removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST, threat modeling) directly keeps the error-prone direct thread use out of first-party code, removing the weakness; remainder is third-party/open-source components where the clause only requires inventory/update rather than mandating removal.
CWE-384prevents — Secure-coding standards can forbid session fixation, but removing the flaw does not achieve the entire coding standard.
CWE-385prevents — Secure coding guidelines may recommend constant-time algorithms but coverage is not guaranteed.
CWE-386prevents — Secure coding standards can mandate direct object handles or validated lookups rather than symbolic names that drift.
CWE-39prevents — Secure coding standards directly require rejecting or normalizing absolute drive-letter paths in file operations.
CWE-390prevents — Secure coding standards typically require explicit error handling, reducing the likelihood of silent failures.
CWE-391prevents — Secure coding standards directly prohibit ignoring exceptions and unchecked errors.
CWE-391removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques that directly produce unchecked error conditions in first-party code, so well-implemented it removes most instances of the flaw from the product (per Q2); the bounded remainder is inconsistent application across all developers, languages, or third-party components where the clause's governance does not guarantee total eradication.
CWE-392prevents — Secure coding standards require functions to return appropriate error codes or status values.
CWE-393prevents — Secure coding standards directly address proper return-value handling and error indication.
CWE-394prevents — Secure coding standards directly mandate checking all legitimate return values and status codes.
CWE-395prevents — Secure coding rules explicitly forbid catching NullPointerException to detect null dereferences.
CWE-396prevents — Secure coding standards explicitly prohibit overly broad exception handlers that mask errors and create exploitable paths.
CWE-397removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes the first-party code defect of declaring overly-broad exceptions (a named common/historical defect per its own guidance), with only a bounded remainder (e.g. third-party library code not authored by the organization).
CWE-40prevents — Secure coding standards directly require validation and sanitization of file paths including UNC shares.
CWE-401prevents — Secure coding standards directly require proper allocation/deallocation, covering most of this weakness.
CWE-403prevents — Secure coding rules require closing inherited file descriptors before spawning child processes.
CWE-407prevents — Secure coding practices can include guidelines to avoid or mitigate inefficient algorithms.
CWE-409prevents — Secure coding practices directly require bounds checking and safe handling of compressed data.
CWE-41prevents — Secure coding standards directly require canonical path resolution and input sanitization to prevent equivalence attacks.
CWE-412prevents — Secure coding guidelines can enforce internal-only lock control during implementation.
CWE-413prevents — Secure coding standards directly prohibit missing or incorrect resource locks.
CWE-414prevents — Secure coding standards require explicit lock acquisition checks before operating on shared resources.
CWE-415prevents — Secure coding standards directly address proper use of free() and similar functions.
CWE-416prevents — Secure coding standards directly prescribe avoidance of use-after-free patterns.
CWE-42prevents — Secure coding standards directly require validation of path inputs to prevent traversal via trailing dots.
CWE-421prevents — Secure coding guidelines help developers avoid race conditions on alternate communication paths.
CWE-422prevents — Secure coding practices include validating message sources and avoiding elevated processes that accept unauthenticated Windows messages.
CWE-424prevents — Secure coding practices reduce the likelihood of unprotected alternate paths in source code.
CWE-425prevents — Secure coding practices reduce the likelihood of missing authorization checks, yet do not guarantee coverage.
CWE-426prevents — Secure coding standards require absolute paths or integrity-checked search paths, directly mitigating CWE-426.
CWE-427prevents — Secure coding practices directly address the use of fixed or controlled search paths that can be influenced by unintended actors.
CWE-428prevents — Secure coding standards directly mandate quoting search paths and avoiding unsafe path construction.
CWE-43prevents — Secure coding standards directly require sanitizing and rejecting malformed filenames like multiple trailing dots.
CWE-430prevents — Secure coding standards can enforce correct handler registration and prevent mis-wiring.
CWE-431prevents — Secure coding standards explicitly call for implementing handlers for all foreseeable inputs and exceptions.
CWE-433prevents — Secure coding practices require explicit server configuration and file-extension handling to avoid raw content delivery.
CWE-436prevents — Secure coding standards can enforce canonical input handling and strict protocol compliance to avoid misinterpretation between products.
CWE-439removes — A.8.28 mandates secure coding practices, principles, standards, threat modeling, SAST, and defect removal during development to reduce potential vulnerabilities, but does not address or remove behavioral changes that only manifest after deployment in a new version or environment (a post-release compatibility issue outside the development-time secure coding locus).
CWE-44prevents — Secure coding standards directly require rejecting or normalizing malformed paths such as internal dots.
CWE-440prevents — Secure coding practices enforce adherence to functional specifications during implementation.
CWE-441prevents — Secure-coding standards can require explicit checks that preserve and verify the original requester identity before acting.
CWE-444prevents — Secure coding standards can require strict HTTP header and request validation to prevent smuggling.
CWE-446prevents — Secure coding practices help avoid implementation bugs that cause UI discrepancies, though the control is not focused on UI correctness.
CWE-447prevents — Secure coding practices reduce the chance of leaving security features unimplemented.
CWE-448prevents — Secure coding standards discourage leaving obsolete UI code without user notification.
CWE-449prevents — Secure coding practices enforce correct control-flow and input-to-action mapping in the UI layer.
CWE-45removes — A.8.28's secure coding process (principles, standards, defect removal, prohibiting insecure techniques, SAST, peer review, threat modeling) directly removes this first-party code defect from the product before it ships; the bounded remainder is inconsistent application across all languages, third-party components, or post-deployment maintenance where the flaw can still be introduced.
CWE-450prevents — Secure coding practices directly address unambiguous input parsing and user confirmation for less-secure interpretations.
CWE-451prevents — Secure coding practices can prevent UI flaws that obscure or spoof critical information.
CWE-453prevents — Secure coding standards mandate explicit, safe variable initialization.
CWE-454prevents — Secure coding standards directly prohibit initializing trusted data from untrusted sources.
CWE-455prevents — Secure coding practices mandate proper error handling during initialization to prevent insecure fallback states.
CWE-456prevents — Secure coding standards directly require explicit initialization of all variables before use.
CWE-457prevents — Secure coding explicitly requires variable initialization and static-analysis checks.
CWE-459prevents — Secure-coding rules can mandate explicit cleanup of temporary resources, but do not guarantee it.
CWE-46prevents — Secure coding standards directly require stripping or rejecting trailing spaces in file paths, addressing the root cause.
CWE-460prevents — Secure coding standards directly require proper resource release and state restoration after exceptions.
CWE-462prevents — Secure coding standards directly address associative-list key uniqueness and collision handling.
CWE-463prevents — Secure coding standards directly address sentinel misuse and deletion errors.
CWE-464removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes sentinel-addition defects from first-party code before release, with a bounded remainder in third-party components and post-deployment maintenance.
CWE-466prevents — Secure coding standards directly address pointer validation and bounds checking, mitigating this specific weakness.
CWE-467prevents — Secure coding rules directly forbid sizeof(pointer) mistakes that produce incorrect buffer sizes.
CWE-468prevents — Secure-coding standards and training directly target pointer arithmetic mistakes, covering most of this weakness while the control also addresses many other issues.
CWE-469prevents — Secure coding standards directly forbid pointer subtraction for size calculations and prescribe safer alternatives.
CWE-47removes — A.8.28 mandates secure coding practices, standards, defect removal, prohibition of insecure techniques, SAST, and analysis of common errors (including path-related ones) during development; this removes most first-party instances of CWE-47 before the product ships, with a bounded remainder in third-party components, reuse scenarios, or incomplete enforcement of the baseline.
CWE-470prevents — Secure coding standards directly forbid unsafe reflection and require whitelisting or static alternatives.
CWE-471prevents — Secure coding standards discourage mutable storage for values that must remain constant.
CWE-472prevents — Secure coding standards require server-side verification of client-supplied data, eliminating the root cause of external control of immutable parameters.
CWE-473prevents — Secure coding standards require disabling register_globals and sanitizing all external inputs, eliminating the root cause of CWE-473.
CWE-474prevents — Secure coding standards explicitly prohibit or wrap functions known to behave differently across OSes and versions.
CWE-475prevents — Secure coding directly addresses avoiding undefined behavior by enforcing defined inputs and error handling in APIs.
CWE-476prevents — Secure coding standards directly require NULL-pointer checks and safe dereference patterns.
CWE-477prevents — Secure coding standards explicitly prohibit use of deprecated/obsolete functions.
CWE-478prevents — Secure coding standards explicitly require exhaustive switch/case handling to prevent unhandled paths.
CWE-479prevents — Secure coding standards explicitly forbid non-reentrant functions inside signal handlers.
CWE-48removes — A.8.28 mandates secure coding practices, standards, defect removal, prohibition of insecure techniques, SAST, and peer review that directly eliminate internal-whitespace path-equivalence defects from first-party code before it ships; the bounded remainder is third-party/open-source components whose handling is governed by later subclauses rather than by the coding act itself.
CWE-480prevents — Secure coding standards and peer review directly prevent accidental use of incorrect operators.
CWE-481removes — A.8.28 mandates secure coding practices, standards, peer review, removing defects, prohibiting insecure techniques, and SAST during development; this directly removes assignment-vs-comparison defects (a named historical coding error) from first-party code before it reaches production, with a bounded remainder in third-party/open-source components that the clause only manages rather than rewrites.
CWE-482prevents — Secure coding standards and reviews directly prevent use of comparison operators where assignment was intended.
CWE-483removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes incorrect block delimitation (a named historical defect) from first-party code, though some third-party/open-source slices and post-deployment maintenance remain as bounded remainder.
CWE-484prevents — Secure coding rules explicitly require break statements in switch constructs, directly preventing this omission.
CWE-486removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes first-party code defects like class-name comparisons (a historical defect per its own guidance), with only a bounded remainder in implementation variance or third-party components not fully governed by in-house standards.
CWE-487removes — A.8.28 mandates secure coding practices, standards, peer review, removal of defects, prohibition of insecure techniques, and secure design that directly eliminate package-scope reliance flaws from first-party code before it ships; the bounded remainder is third-party/open-source components where the clause only requires vetting and inventory rather than mandating their internal redesign.
CWE-488prevents — Secure coding standards mandate correct session handling to prevent exposure of data elements to the wrong session.
CWE-489prevents — Secure coding standards explicitly prohibit leaving debug code active in production.
CWE-49removes — A.8.28 mandates secure coding practices, standards, principles, defect removal during coding/review, and prohibiting insecure techniques that directly address path-equivalence defects in first-party code, so the weakness stops being present; the bounded remainder is inconsistent application across all developers, languages, and third-party components despite the governance baseline.
CWE-491prevents — Secure coding standards directly require final clone or defensive-copy patterns to block object hijacking.
CWE-492removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques (including those that would embed sensitive data in inner classes); this removes most instances of the CWE-492 flaw from first-party code, with a bounded remainder in third-party/open-source components that the clause only manages rather than rewrites.
CWE-493removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes first-party code defects like a non-final critical public variable during development; remainder is third-party/open-source components where the clause only governs selection/update rather than mandating removal of the flaw.
CWE-495prevents — Secure coding standards can forbid public methods that return references to private mutable structures, largely eliminating this weakness.
CWE-496removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, prohibition of insecure techniques, and secure design that directly eliminate this first-party code defect before the product ships; the bounded remainder is inconsistent or incomplete application of those practices across all codebases and languages.
CWE-498removes — A.8.28 mandates secure coding practices, principles, standards, defect removal, prohibition of insecure techniques (including hard-coded secrets), secure design, peer review, and SAST that together remove most instances of this first-party code defect; the bounded remainder is inconsistent application across languages, libraries, or outsourced components where the cloneable-sensitive pattern is not caught.
CWE-499prevents — Secure coding standards directly require marking sensitive classes as non-serializable or implementing custom serialization controls.
CWE-50prevents — Secure coding standards directly address path traversal and equivalence vulnerabilities.
CWE-500removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, prohibition of insecure techniques, and secure design that directly eliminate the mutable public static field flaw from first-party code before it reaches production; the bounded remainder is third-party/open-source components where the clause only requires inventory/update rather than guaranteed removal of the defect.
CWE-501prevents — Secure coding standards can enforce input validation and data tagging, but do not guarantee architectural separation.
CWE-502prevents — Requiring vetted libraries, regular updates and SAST before release reduces the likelihood that deserialization logic will accept and act on attacker-controlled serialized objects.
CWE-507prevents — Secure coding practices help detect and eliminate hidden Trojan Horse functionality.
CWE-51removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, prohibition of insecure techniques, and SAST that directly target and eliminate path-equivalence defects from first-party code before release; the bounded remainder is incomplete uptake of its non-mandatory items (e.g. threat modeling depth or third-party component vetting rigor).
CWE-510removes — A.8.28 mandates secure coding practices, principles, standards, prohibition of insecure techniques (including hard-coded passwords), peer review, removal of defects, and SAST that directly target and eliminate trapdoor/backdoor code during development, leaving only a bounded remainder of sophisticated or post-deployment inserted trapdoors outside its first-party development scope.
CWE-511prevents — Secure coding standards and peer review directly prevent insertion of malicious time- or logic-triggered code.
CWE-512removes — A.8.28 is a first-party secure-coding governance and practice control that reduces vulnerabilities written into the organization's own software; CWE-512 is a design-level behavioral flaw in how a product stealthily collects and exfiltrates PII without consent, which is not removed by mandating secure coding practices, threat modeling, or SAST (per the locus rule that first-party code-defect classes are not removed by CVE-mediated or third-party patching controls, and this pair is the symmetric case).
CWE-515prevents — Secure coding practices can avoid some covert storage patterns but cannot cover all implementation flaws.
CWE-52removes — A.8.28 mandates secure coding practices, standards, principles, defect removal, SAST, and prohibiting insecure techniques that directly target and eliminate path-equivalence defects (including trailing-slash variants) from first-party code before it reaches production; the bounded remainder is inconsistent application across all developers, languages, or third-party components where the clause's governance does not guarantee total eradication.
CWE-523prevents — Requires secure coding practices that can prevent unprotected credential transmission.
CWE-524prevents — Secure coding practices prevent caching of sensitive data outside intended boundaries.
CWE-525prevents — Secure coding standards can mandate proper cache-control headers and form-field handling to prevent sensitive data retention.
CWE-526prevents — Secure coding standards typically prohibit storing sensitive information in cleartext environment variables.
CWE-53removes — A.8.28 mandates secure coding practices, standards, principles, defect removal, prohibition of insecure techniques, SAST, and peer review that directly eliminate path-equivalence defects from first-party code before it ships; the bounded remainder is inconsistent application across all developers, languages, or third-party code reuse scenarios where the clause's governance does not guarantee total eradication.
CWE-531prevents — Secure coding standards can require scrubbing or exclusion of secrets from test modules.
CWE-535prevents — Secure coding standards directly require handling exceptions without exposing internal details.
CWE-536removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes the code-level defect of unhandled exceptions that leak sensitive info in servlet error messages; remainder is post-operational handling and third-party library cases reached only by other clauses.
CWE-537removes — A.8.28's secure coding process (principles, standards, defect removal during coding/review, prohibiting insecure techniques, SAST, and analysis of common errors) directly removes the code defect that produces sensitive data in Java runtime error messages; the bounded remainder is that it cannot reach every possible unhandled exception path or third-party library behavior without perfect implementation.
CWE-539prevents — Secure coding standards directly forbid embedding sensitive information in persistent cookies.
CWE-54removes — A.8.28 mandates secure coding practices, standards, principles, defect removal during coding/review, and prohibiting insecure techniques (including path handling that leads to equivalence issues); well-implemented it removes most first-party instances of CWE-54 from the product before release, with a bounded remainder in incomplete enforcement, third-party components, or post-release changes.
CWE-540prevents — Secure coding standards explicitly prohibit hard-coding credentials or sensitive data.
CWE-541prevents — Secure coding standards directly prohibit embedding credentials in include files.
CWE-543removes — A.8.28 mandates secure coding practices, principles, standards, design, peer review, defect removal, and prohibiting insecure techniques (including during new development and reuse); this directly removes the unsynchronized singleton flaw from first-party code before it ships, with a bounded remainder in third-party/open-source components that the clause separately requires be vetted/updated but does not rewrite.
CWE-544prevents — Secure coding explicitly calls for uniform, standardized error handling to avoid introducing weaknesses.
CWE-546removes — A.8.28's during-coding and review/maintenance sections explicitly require documenting code while removing programming defects, prohibiting insecure techniques, and handling reported vulnerabilities with code adjustments, which directly removes suspicious comments suggesting bugs or weaknesses from first-party code.
CWE-547prevents — Secure coding standards explicitly prohibit hard-coded security constants.
CWE-548prevents — Secure coding practices ensure developers do not leave directory listing enabled on production web servers.
CWE-549prevents — Secure coding practices would include implementing password masking, but the control is broader than this single weakness.
CWE-55removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, prohibition of insecure techniques, and SAST that directly target and eliminate path-equivalence defects from first-party code before release, leaving only a bounded remainder in third-party components or post-deployment maintenance.
CWE-550prevents — Secure coding standards prohibit embedding sensitive data in server error messages.
CWE-551prevents — Secure coding practices directly address canonicalization and authorization sequencing flaws.
CWE-554removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, SAST, and prohibiting insecure techniques; this directly removes the specific misconfiguration of not using ASP.NET's input validation framework from first-party code, with bounded remainder around third-party components and incomplete enforcement.
CWE-558removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes the getlogin() call from first-party multithreaded code; remainder is third-party components and post-deployment discovered instances handled by other clauses (8.8/8.29).
CWE-56removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, prohibition of insecure techniques, and secure design that directly eliminate path-equivalence wildcard flaws from first-party code before it reaches production; the bounded remainder is incomplete uptake of those practices on every historical defect pattern or third-party component.
CWE-560removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques (including hard-coded values and unapproved samples that overlap this class); well-implemented it removes most instances of this first-party code defect from the product before release, with a bounded remainder in third-party components or incomplete enforcement.
CWE-561prevents — Secure coding standards require removal of dead code to improve maintainability and reduce attack surface.
CWE-562prevents — Secure coding standards directly prohibit returning addresses of stack variables.
CWE-564prevents — Secure coding explicitly requires parameterized queries and safe Hibernate usage to prevent injection.
CWE-565prevents — Secure coding practices directly eliminate reliance on unvalidated cookies by requiring proper integrity checks and server-side verification.
CWE-566prevents — Secure-coding standards mandate parameterized queries and server-side authorization, eliminating the root cause of CWE-566.
CWE-567prevents — Secure coding standards directly require synchronization of shared variables across threads.
CWE-568removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes this first-party finalize() omission during development; remainder is non-mandated edge cases like incomplete peer review or overlooked legacy code.
CWE-57prevents — Mandates secure coding techniques such as proper pathname canonicalization and input sanitization.
CWE-570prevents — Secure coding standards and practices directly prevent constant-false expressions through disciplined coding and peer review.
CWE-571prevents — Secure coding standards and practices directly target logic errors such as tautological expressions.
CWE-572removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes this first-party threading defect from the product before it ships; the bounded remainder is that the clause's governance/continual-improvement framing leaves enforcement rigour to the implementer, so some instances may survive if the baseline or reviews are incomplete.
CWE-573prevents — Secure coding standards enforce correct use of APIs, protocols and language features, mitigating caller specification violations.
CWE-574removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes EJB synchronization violations (a named historical defect) from first-party code before it reaches production, though some third-party EJB components or post-deployment maintenance gaps remain.
CWE-576removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes EJB I/O violations from first-party code during development; the bounded remainder is third-party/open-source components where the clause only requires inventory/update rather than guaranteed removal.
CWE-577removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes first-party EJB socket usage during development and maintenance; remainder is third-party/open-source components where the clause only requires inventory/vetting rather than mandating removal.
CWE-578removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes the EJB class-loader misuse from first-party code before it ships; remainder is third-party/open-source components where the clause only requires inventory/update rather than guaranteed removal.
CWE-579removes — A.8.28 mandates secure coding practices, standards, defect removal, prohibition of insecure techniques, SAST, and peer review that directly eliminate non-serializable session objects from first-party code; the bounded remainder is inconsistent application across all developers, languages, or third-party components where the clause's governance does not guarantee total eradication.
CWE-58removes — A.8.28's secure coding principles, standards, defect removal, prohibition of insecure techniques, SAST, and peer review during development directly remove the first-party code defect of failing to canonicalize or block 8.3 path equivalents before the product ships; the bounded remainder is post-shipment discovered instances (handled in 8.8/8.29) and third-party library cases (handled in the clause's own library-management text).
CWE-580removes — A.8.28 mandates secure coding practices, standards, defect removal, prohibition of insecure techniques, and SAST/testing that together remove first-party clone() defects missing super.clone(); the bounded remainder is inconsistent application across all languages, developers, and third-party code reuse scenarios.
CWE-581removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques; this removes most (but not all) instances of the CWE-581 defect class when well implemented, as some equal/hashCode violations can still arise from incomplete application of the practices or in third-party components.
CWE-582removes — A.8.28's secure coding process (principles, standards, prohibiting insecure techniques like hard-coded values, peer review, removing defects, SAST, threat modeling) directly removes this first-party code defect when well implemented; the bounded remainder is inconsistent application across all developers, languages, and third-party code reuse scenarios.
CWE-583removes — A.8.28 mandates secure coding principles, practices, standards, defect removal, prohibition of insecure techniques, and SAST during development; this directly removes the public finalize() anti-pattern from first-party code (and from managed third-party components via inventory/update rules), but leaves a bounded remainder in unmodified external libraries where the organization only selects/vets rather than rewrites.
CWE-584removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes the specific first-party code defect of a return inside a finally block (a historical defect per the clause) from the product before it ships, with only bounded remainder for unrigorous implementations or post-operational changes.
CWE-585removes — A.8.28's secure coding principles, standards, defect removal, SAST, peer review, and prohibition of insecure techniques (including during-code and before-operational checks) directly remove empty synchronized blocks from first-party code; the bounded remainder is third-party/open-source components where the clause only requires inventory/update rather than guaranteed removal.
CWE-586removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes explicit finalize() calls from first-party code during development; remainder is third-party library code where the control only manages selection/updates rather than rewriting.
CWE-587prevents — Secure coding standards directly forbid assigning fixed addresses to pointers.
CWE-588prevents — Secure coding standards directly forbid casting non-structures to structures and accessing fields.
CWE-589removes — A.8.28 mandates secure coding practices, standards, defect removal, prohibition of insecure techniques, SAST, and analysis of common programming errors (including non-portable API use) before release, so well-implemented secure coding removes this first-party code defect from the product; the bounded remainder is defects that slip through imperfect human or tool application of those practices.
CWE-59prevents — Secure coding standards directly address canonicalization and symlink attacks during implementation.
CWE-590prevents — Secure coding standards explicitly forbid freeing pointers not obtained from heap allocators, directly mitigating CWE-590.
CWE-591prevents — Secure-coding standards can mandate use of locked-memory APIs, directly preventing the weakness.
CWE-593removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding, prohibition of insecure techniques, and evaluation of common errors before deployment, which removes this specific first-party code defect (modifying the SSL context post-creation) from the product when well-implemented; the bounded remainder is inconsistent application across all developers, languages, or third-party code reuse scenarios.
CWE-595removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes first-party code defects like CWE-595 by ensuring object content comparison is used instead, with only bounded remainder from incomplete implementation rigor or third-party components.
CWE-597prevents — Secure coding rules directly prohibit use of the wrong string-comparison operator.
CWE-598prevents — Secure coding standards directly prohibit placing secrets in query parameters.
CWE-599prevents — Requires secure coding practices that would include proper certificate validation in OpenSSL usage.
CWE-600prevents — Secure coding standards directly prescribe catching and sanitizing exceptions in servlets to avoid leaking debug data.
CWE-602prevents — Secure coding standards require server-side checks and reject client-only enforcement.
CWE-603prevents — Secure coding standards discourage reliance on client-side authentication logic.
CWE-605prevents — Secure coding practices can include checks to ensure sockets request exclusive port binding.
CWE-606prevents — Secure coding standards directly mandate validation of loop-control inputs to prevent unbounded iteration.
CWE-607removes — A.8.28 mandates secure coding practices, principles, standards, peer review, removal of defects, prohibition of insecure techniques (including hard-coded values), and secure design that directly eliminate this first-party code defect before release; the bounded remainder is that the clause's governance processes and 'should' language leave room for incomplete enforcement on every instance.
CWE-608removes — A.8.28's secure coding process, principles, standards, defect removal, prohibition of insecure techniques, SAST, and peer review during development directly remove this first-party code defect before the product ships; the bounded remainder is post-operational discovered instances or third-party library code where the clause's own later items defer to A.8.8.
CWE-609removes — A.8.28 mandates secure coding practices, principles, standards, defect removal, prohibition of insecure techniques, and SAST during development that directly eliminate double-checked locking defects from first-party code before it reaches production.
CWE-61prevents — Secure-coding standards mandate explicit symlink checks and safe open patterns, fully mitigating CWE-61.
CWE-610prevents — Secure coding standards require input validation and canonicalization to block externally controlled resource references.
CWE-611prevents — Secure coding standards require disabling DTDs and external entities in XML processing.
CWE-614prevents — Secure coding practices directly prevent missing the Secure attribute on sensitive cookies, though the control covers many other coding issues.
CWE-615prevents — Secure-coding standards and training directly discourage embedding secrets or sensitive data in comments.
CWE-616prevents — Secure coding explicitly prohibits use of deprecated upload variables and requires validated, server-side file handling.
CWE-617prevents — Secure coding standards explicitly ban the use of assert() or equivalent statements that can be triggered by external input.
CWE-618prevents — Secure coding standards directly prohibit unsafe ActiveX method exposure and require least-privilege interfaces.
CWE-619removes — A.8.28's secure coding process (principles, standards, defect removal during coding/review, prohibiting insecure techniques, SAST, and analysis of common errors) directly removes dangling-cursor defects from first-party and in-house code before release; the bounded remainder is third-party/open-source components whose cursor-handling flaws are addressed only by inventory/update steps that live in other clauses.
CWE-62prevents — Secure-coding practices can mandate safe file-open APIs and link validation, directly addressing the weakness.
CWE-621prevents — Secure coding standards directly prohibit unvalidated variable extraction from external input.
CWE-622prevents — Secure coding standards directly require argument validation for any exposed or hooked functions.
CWE-623prevents — Secure coding standards explicitly forbid marking ActiveX controls as safe-for-scripting unless truly safe.
CWE-624prevents — Secure coding standards directly address safe regex construction and ban user-supplied pattern modifiers.
CWE-625prevents — Secure coding standards directly prohibit permissive regex and enforce strict pattern validation.
CWE-626prevents — Secure coding standards directly address null-byte handling and input sanitization.
CWE-627prevents — Secure coding standards directly prohibit or constrain dynamic variable evaluation to prevent arbitrary access.
CWE-628prevents — Secure coding standards directly address proper function-call syntax and argument validation.
CWE-637prevents — Secure coding guidelines may discourage complex constructs but do not specifically address protection-mechanism design.
CWE-639prevents — Secure coding practices reduce the likelihood of missing authorization checks but do not guarantee their presence at runtime.
CWE-64prevents — Secure coding practices can implement proper validation of .LNK targets to prevent unauthorized file operations.
CWE-640prevents — Secure-coding standards can prevent weak recovery implementations, yet the control is wider in scope.
CWE-641prevents — Secure coding standards explicitly require validation and sanitization of filenames derived from external input.
CWE-642prevents — Secure coding guidelines can prevent the practice of storing critical state in externally accessible locations.
CWE-643prevents — Secure coding standards require proper neutralization of untrusted input in XPath expressions.
CWE-644prevents — Secure coding standards require proper escaping or rejection of scripting syntax in HTTP headers.
CWE-644removes — A.8.28's secure coding process, principles, standards, defect removal, prohibition of insecure techniques, SAST, and peer review during development directly remove this first-party code defect before the product ships; the bounded remainder is post-operational reported vulnerabilities (handled in 8.8) and third-party library cases where the clause only manages rather than rewrites.
CWE-646prevents — Secure coding standards explicitly require validating file content rather than trusting names or extensions.
CWE-647prevents — Secure-coding standards that require URL canonicalization and safe path handling eliminate the root cause of the weakness.
CWE-648prevents — Secure coding standards can enforce correct usage of privileged APIs.
CWE-649prevents — Secure coding practices include validating integrity of encrypted/obfuscated inputs before use.
CWE-65prevents — Secure-coding practices can require canonicalization and path validation to prevent following unintended hard links.
CWE-650prevents — Secure coding practices directly address improper HTTP method usage and ensure state-changing operations use POST/PUT/DELETE.
CWE-652prevents — Secure coding standards require proper neutralization of untrusted input in query expressions.
CWE-656prevents — Secure-coding rules prohibit hidden or undocumented security mechanisms.
CWE-66prevents — Secure coding standards directly address safe file-name handling and canonicalization, substantially mitigating this weakness.
CWE-662prevents — Secure coding standards explicitly mandate proper use of locks, semaphores, and atomic operations to eliminate race conditions.
CWE-663prevents — Secure coding standards explicitly forbid use of non-reentrant functions in multi-threaded or signal-handling code.
CWE-664prevents — Secure coding practices help avoid lifetime control bugs but do not address the full scope.
CWE-664removes — A.8.28 mandates secure coding practices, principles, standards, defect removal, prohibition of insecure techniques, and secure design that directly eliminate many lifetime-control flaws before they reach production; the bounded remainder is complex or emergent resource-lifetime errors that secure-coding baselines do not systematically catch.
CWE-665prevents — Secure coding standards explicitly forbid uninitialized variables and mandate proper resource initialization before use.
CWE-667prevents — Secure coding standards directly prohibit missing or incorrect lock usage.
CWE-67prevents — Secure coding standards directly address proper handling of Windows reserved device names in pathnames.
CWE-670prevents — Secure coding standards and reviews directly target flawed control-flow implementations.
CWE-672prevents — Secure-coding rules require checks that prevent operations on freed or expired objects.
CWE-674prevents — Secure coding standards directly prohibit or constrain recursive constructs that could exhaust stack or memory.
CWE-675prevents — Secure coding standards directly address avoiding multiple operations on a resource in a single-operation context.
CWE-676prevents — Secure coding standards explicitly ban or restrict dangerous functions such as strcpy, gets, or system.
CWE-680prevents — Secure coding standards directly require prevention of integer overflows that lead to buffer overflows.
CWE-680removes — A.8.28 mandates secure coding practices, principles, standards, defect removal, threat modeling, and SAST that directly target and eliminate integer overflow calculations leading to buffer overflows in first-party code; the bounded remainder is inconsistent or incomplete application across all developers, languages, and third-party components despite the governance baseline.
CWE-681prevents — Secure coding standards directly address correct numeric type conversions and overflow checks.
CWE-682prevents — Secure coding standards directly prohibit unsafe arithmetic and require defensive checks against incorrect results.
CWE-682removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques that directly produce incorrect calculations, so well-implemented secure coding removes most instances of this first-party code defect from the product before it ships; the bounded remainder is defects that slip through imperfect human processes or arise in third-party components managed under the same clause.
CWE-683prevents — Secure coding standards can mandate argument-order checks and static analysis, but do not guarantee elimination of all ordering mistakes.
CWE-686prevents — Secure coding directly addresses type safety, static analysis, and compiler warnings for argument mismatches.
CWE-687prevents — Secure coding directly addresses correct function-call argument usage.
CWE-688prevents — Secure coding standards directly address proper function-call argument usage and validation.
CWE-689prevents — Mandates secure coding techniques to set permissions atomically during copy.
CWE-69prevents — Secure-coding standards and reviews can require explicit handling or disabling of alternate data streams, directly addressing the root cause in application code.
CWE-690prevents — Secure coding standards explicitly forbid unchecked return values leading to NULL dereference.
CWE-690removes — A.8.28 mandates secure coding practices, principles, standards, defect removal, prohibition of insecure techniques, SAST, and analysis of common errors (including unchecked returns/NULLs) during development, which removes this first-party code defect from the product; the bounded remainder is inconsistent or incomplete application across all code, languages, and third-party components despite the governance baseline.
CWE-691prevents — Secure coding standards explicitly forbid constructs that allow unintended control-flow changes such as missing breaks or unsafe jumps.
CWE-691removes — A.8.28 mandates secure coding practices, principles, standards, defect removal, prohibition of insecure techniques, and SAST during development that directly eliminate insufficient control flow constructs from first-party code before it ships; the bounded remainder is post-operational discovered issues handled via 8.8/8.29 rather than this clause's own coding-time mandate.
CWE-692prevents — Secure-coding rules directly require allow-list or context-aware escaping instead of incomplete denylists for XSS.
CWE-692removes — A.8.28's secure coding process (principles, standards, defect removal, prohibiting insecure techniques, SAST, peer review) directly removes incomplete denylists from first-party code; remainder is third-party library defects reached only via inventory/update steps rather than coding itself.
CWE-693removes — A.8.28 mandates secure coding practices, principles, standards, design, peer review, defect removal, prohibition of insecure techniques (e.g. hard-coded passwords), and evaluation of common errors before deployment, which directly removes many instances of missing or incorrectly used protection mechanisms from first-party code; the bounded remainder is third-party components and post-deployment issues handled by other clauses (8.8, 8.29).
CWE-694prevents — Secure coding standards can mandate unique identifier generation and validation.
CWE-695prevents — Secure coding standards directly prohibit disallowed low-level functionality.
CWE-696prevents — Secure coding standards enforce correct execution order of security-critical operations.
CWE-697prevents — Secure coding standards directly address avoiding incorrect comparison operators and logic.
CWE-697removes — A.8.28 mandates secure coding practices, standards, defect removal, prohibition of insecure techniques, and analysis of common programming errors (including incorrect comparisons in security contexts) before deployment, so the flaw stops being present in first-party code; remainder is inconsistent implementation across all developers, third-party components, and post-deployment maintenance changes.
CWE-698prevents — Secure coding standards directly address proper redirect handling and flow termination.
CWE-7removes — A.8.28's secure coding process (principles, standards, defect removal during coding/review, prohibiting insecure techniques, SAST, and analysis of common errors) removes most instances of missing custom error pages from first-party code; the bounded remainder is third-party/open-source components whose misconfigurations are only managed (not removed) per the clause.
CWE-703removes — A.8.28 mandates secure coding practices, principles, defect removal during coding/review, and prohibiting insecure techniques that directly produce improper exception handling; this removes most instances of the first-party code defect, with a bounded remainder in incomplete adoption or edge-case defects not captured by the baseline.
CWE-704prevents — Secure coding standards directly forbid or detect incorrect type casts.
CWE-705prevents — Secure coding standards directly address correct return and exception handling to prevent control-flow errors.
CWE-706prevents — Secure-coding standards directly address canonicalization, input validation and safe name resolution, mitigating CWE-706.
CWE-707prevents — Secure coding standards directly require proper neutralization of inputs and outputs, eliminating CWE-707.
CWE-707removes — A.8.28 mandates secure coding practices, standards, defect removal, prohibition of insecure techniques, SAST, and peer review that directly eliminate improper neutralization defects from first-party code before release; the bounded remainder is incomplete uptake of its non-mandatory items (e.g. threat modeling depth or third-party component vetting rigor).
CWE-710prevents — Directly requires secure coding practices and standards.
CWE-710removes — A.8.28 mandates secure coding standards, their use, removal of defects, and related practices that directly eliminate improper adherence to coding standards from the product; the bounded remainder is that imperfect enforcement or incomplete standards may leave some violations.
CWE-72removes — A.8.28's secure coding principles, standards, defect removal, prohibition of insecure techniques, and SAST directly remove first-party code defects like improper HFS+ path handling during development; the bounded remainder is third-party/open-source components (explicitly in scope but handled via inventory/update rather than code rewrite).
CWE-73prevents — Secure coding standards require canonicalization, allow-listing, and bounds checks on file paths, directly eliminating CWE-73.
CWE-733prevents — Secure coding standards explicitly address compiler flags and volatile/optimization barriers for security-critical code.
CWE-74prevents — Secure coding standards require proper neutralization of special elements, directly addressing CWE-74.
CWE-749prevents — Secure coding standards explicitly prohibit inclusion of dangerous methods or functions in production APIs.
CWE-75prevents — Secure coding standards require rigorous input sanitization, directly eliminating CWE-75.
CWE-754prevents — Secure coding standards directly mandate proper checks for exceptional and unusual conditions.
CWE-755prevents — Secure coding standards mandate proper exception handling to avoid CWE-755.
CWE-756prevents — Secure coding practices directly address proper error handling and custom error pages.
CWE-757prevents — Secure coding standards can mandate checks to reject weaker negotiated algorithms.
CWE-758prevents — Secure coding explicitly prohibits constructs whose behavior is undefined, unspecified or implementation-defined.
CWE-759prevents — Secure coding standards explicitly forbid unsalted password hashes and require salting.
CWE-76prevents — Secure coding standards directly address proper neutralization of all equivalent special elements.
CWE-760prevents — Secure coding explicitly prohibits predictable salts and mandates cryptographically secure random salts.
CWE-761prevents — Secure coding rules directly forbid freeing a pointer that is not at the start of an allocated buffer.
CWE-762prevents — Secure coding standards directly prohibit mismatched memory-management calls and enforce safe patterns.
CWE-763prevents — Secure coding standards directly prohibit mismatched or incorrect pointer-release calls.
CWE-764prevents — Secure coding standards and reviews can catch and prevent erroneous multiple-lock sequences in source code.
CWE-765prevents — Secure coding standards and reviews can catch or prevent erroneous unlock sequences in critical sections.
CWE-766removes — A.8.28 mandates secure coding practices, principles, standards, peer review, removal of defects, prohibition of insecure techniques (including hard-coded values), and evaluation of common errors before deployment, which removes most instances of publicly-declared critical data by ensuring it is instead declared with appropriate access modifiers during development.
CWE-767prevents — Secure coding standards explicitly forbid exposing private variables through public methods.
CWE-768prevents — Secure-coding standards directly forbid short-circuit side effects and require explicit evaluation order.
CWE-77prevents — Secure coding standards require proper escaping and parameterization of commands, directly eliminating CWE-77.
CWE-771prevents — Secure coding standards can require proper reference maintenance for allocated resources.
CWE-772prevents — Secure-coding rules can mandate explicit resource-release patterns, but the control is broader than this single weakness.
CWE-773removes — A.8.28's secure coding process (principles, standards, defect removal during coding/review, prohibiting insecure techniques, SAST, and post-operational adjustments) directly removes first-party code defects like missing file descriptor references; the bounded remainder is third-party/open-source components where the clause only requires inventory/update rather than mandating removal of the defect.
CWE-774prevents — Secure coding standards explicitly require limits on file-handle allocation.
CWE-775prevents — Secure-coding standards can mandate explicit close/release of handles, directly mitigating CWE-775.
CWE-776prevents — Secure coding standards directly require disabling or restricting recursive entity references in XML parsers.
CWE-777prevents — Secure coding explicitly requires anchored regex to prevent bypass of input validation.
CWE-780prevents — Requires secure coding practices that would prevent missing OAEP padding.
CWE-781removes — A.8.28 mandates secure coding practices, principles, standards, defect removal, prohibition of insecure techniques, SAST, and peer review that directly target and eliminate improper validation defects like CWE-781 during development; the bounded remainder is inconsistent or incomplete application across all code paths and third-party components.
CWE-782prevents — Secure coding practices prevent omission of access-control checks on IOCTL handlers.
CWE-783prevents — Secure coding standards and guidelines directly address operator precedence mistakes.
CWE-784prevents — Secure coding practices require integrity checks on security-critical cookies used for decisions.
CWE-785removes — A.8.28 mandates secure coding practices, standards, principles, defect removal during coding/review, and prohibiting insecure techniques; this directly removes the buffer-size error in path-manipulation calls from first-party code (Q2), with a bounded remainder in third-party/open-source components that the clause treats via inventory and vetting rather than in-house coding.
CWE-786prevents — Secure coding standards directly require bounds checking and pointer validation that prevent this weakness.
CWE-786removes — A.8.28 mandates secure coding practices, standards, defect removal, SAST, and prohibiting insecure techniques that directly eliminate out-of-bounds buffer accesses during development; the bounded remainder is custom/undocumented edge cases or third-party code not reached by in-house processes.
CWE-787prevents — Secure coding directly addresses out-of-bounds writes through language choice and coding standards.
CWE-788prevents — Secure coding standards directly forbid writing or reading past buffer ends.
CWE-788removes — A.8.28 mandates secure coding practices, standards, principles, defect removal, SAST, and prohibiting insecure techniques that directly eliminate out-of-bounds buffer accesses during development and maintenance; the bounded remainder is insecure third-party components or post-deployment code changes that fall to other clauses.
CWE-789prevents — Secure coding standards directly prohibit allocating memory from untrusted size values without validation.
CWE-79prevents — Secure-coding standards, SAST scans and removal of insecure code samples together eliminate the failure to neutralize script content that produces cross-site scripting flaws.
CWE-790prevents — Secure coding standards require proper filtering and encoding of special elements before downstream processing.
CWE-791prevents — Secure coding standards mandate complete filtering and escaping of special elements, directly eliminating CWE-791.
CWE-792prevents — Secure coding standards require complete sanitization of special elements before downstream processing.
CWE-793removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques that directly produce this exact filtering defect in first-party code, so well-implemented it removes most instances; the bounded remainder is inconsistent application across all entry points, languages, or third-party code reuse where the clause's governance does not reach every developer or component.
CWE-794prevents — Secure coding standards require complete sanitization of all instances of special elements before downstream processing.
CWE-795removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes first-party code defects like location-specific filtering (a form of improper neutralization), with bounded remainder in incomplete implementation or third-party components.
CWE-796removes — A.8.28 mandates secure coding practices, standards, defect removal, prohibition of insecure techniques, SAST, and peer review that directly eliminate marker-relative filtering defects from first-party code before it reaches production; the bounded remainder is incomplete uptake of those practices on every code path or third-party component.
CWE-797removes — A.8.28 mandates secure coding practices, standards, defect removal during coding/review, and prohibiting insecure techniques; this directly removes absolute-position-only filtering defects from first-party code before it ships, with a bounded remainder for third-party components or post-deployment reported issues handled under separate clauses (8.8/8.29).
CWE-798prevents — Explicit prohibition of hard-coded passwords and unauthenticated external services stops credentials from being embedded directly in source code.
CWE-799prevents — Secure coding practices can embed input-frequency and throttling checks in code.
CWE-8removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes first-party code defects like declaring an entity bean remote; the bounded remainder is third-party/open-source components where the clause only governs selection and updating rather than mandating removal of the misconfiguration.
CWE-80prevents — Secure coding standards require proper escaping of <, >, & to block XSS.
CWE-804prevents — Secure coding practices ensure CAPTCHA logic is resistant to automated recognition or guessing attacks.
CWE-805prevents — Secure coding explicitly requires correct buffer-length handling, eliminating CWE-805 when followed.
CWE-806removes — A.8.28 mandates secure coding practices, principles, standards, defect removal during coding/review, and prohibiting insecure techniques that directly produce this exact class of buffer-size error in first-party code; well-implemented it removes most instances, with a bounded remainder in third-party components, reuse scenarios, and incomplete enforcement across all developers/tools.
CWE-807prevents — Secure coding standards directly prohibit using untrusted inputs for security-critical decisions.
CWE-81prevents — Secure coding standards require output encoding and error-message sanitization, directly eliminating CWE-81.
CWE-82prevents — Secure coding standards directly require proper neutralization of script in HTML attributes, addressing the root cause of CWE-82.
CWE-820prevents — Secure coding standards directly require synchronization primitives to prevent race conditions.
CWE-821prevents — Secure coding standards directly require correct synchronization primitives and thread-safety.
CWE-822prevents — Secure coding standards explicitly forbid dereferencing pointers derived from untrusted input.
CWE-823prevents — Secure coding standards directly forbid unsafe pointer arithmetic and require bounds checks.
CWE-824prevents — Secure coding standards directly prohibit use of uninitialized pointers.
CWE-825prevents — Secure coding standards directly address pointer lifetime and deallocation discipline, substantially mitigating expired-pointer dereference.
CWE-825removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST, threat modeling) directly removes expired-pointer defects from first-party code before release; the bounded remainder is third-party/open-source components whose defects are only managed (inventory, updates) rather than removed by this clause.
CWE-826prevents — Secure coding standards directly prohibit premature resource release, covering most of the weakness.
CWE-827prevents — Secure coding standards explicitly forbid unsafe XML parsers and mandate disabling external entities.
CWE-828prevents — Secure coding standards directly address asynchronous-safety and reentrancy requirements in signal handlers.
CWE-83prevents — Secure coding standards require proper escaping of untrusted data in HTML attributes, directly eliminating CWE-83.
CWE-830prevents — Secure coding practices can avoid unsafe inclusion of external scripts, but coverage depends on developer adherence.
CWE-831removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes the multi-signal handler flaw from first-party code during development; remainder is third-party/open-source components where the clause only requires inventory/update rather than mandating removal of the defect.
CWE-832prevents — Secure coding standards can explicitly forbid unlocking resources that were never locked.
CWE-833prevents — Secure coding standards mandate safe lock ordering, timeouts, and deadlock detection patterns.
CWE-834prevents — Secure coding standards explicitly forbid unbounded loops and require explicit iteration limits.
CWE-835prevents — Secure coding standards directly address loop termination and prevent infinite loops.
CWE-836prevents — Secure coding guidance can prevent this implementation error but does not address the control's broader intent.
CWE-837prevents — Secure-coding standards can mandate checks that prevent repeated actions, but the control covers many coding issues.
CWE-838prevents — Secure coding directly addresses proper output encoding for context, covering most of the weakness and the control's intent.
CWE-839prevents — Secure coding standards explicitly forbid numeric comparisons that omit the lower bound, directly mitigating CWE-839.
CWE-84prevents — Secure coding standards mandate proper neutralization of encoded URI schemes, eliminating the root cause of CWE-84.
CWE-841prevents — Secure coding practices can prevent missing workflow checks but do not define the control itself.
CWE-843prevents — Secure coding standards directly forbid unsafe type casts and require static-analysis checks for type confusion.
CWE-85prevents — Secure coding practices directly require proper sanitization of user input, covering most of this XSS variant.
CWE-86prevents — Secure coding standards require proper neutralization of invalid characters in tag names, URIs and identifiers, directly addressing CWE-86.
CWE-87prevents — Secure coding standards require proper neutralization of alternate script syntax, directly eliminating CWE-87.
CWE-87removes — A.8.28 mandates secure coding practices, standards, defect removal, prohibition of insecure techniques, SAST, and peer review that directly eliminate alternate XSS syntax flaws from first-party code during development; the bounded remainder is incomplete uptake of its non-mandatory items (e.g. threat modeling depth or third-party library vetting rigor).
CWE-88prevents — Secure coding standards explicitly require proper neutralization of command arguments, directly eliminating CWE-88.
CWE-89prevents — Language-specific secure coding rules, peer review and SAST together prevent the construction of SQL statements from untrusted data without proper parameterization or escaping.
CWE-9removes — A.8.28's secure coding process (principles, standards, peer review, removing defects, prohibiting insecure techniques, SAST) directly removes weak EJB access permissions from first-party code before it reaches production; the bounded remainder is third-party/open-source components whose misconfigurations are only managed (not coded).
CWE-90prevents — Secure coding standards require proper neutralization of LDAP special characters, directly eliminating this weakness.
CWE-908prevents — Secure coding standards directly require explicit initialization of all variables and resources, substantially mitigating CWE-908.
CWE-909prevents — Secure coding standards explicitly require initialization of variables and resources.
CWE-91prevents — Secure coding standards require proper neutralization of XML metacharacters, directly eliminating CWE-91.
CWE-910prevents — Secure-coding standards can explicitly forbid use of expired file descriptors.
CWE-911prevents — Secure coding standards directly prescribe correct increment/decrement patterns, covering most instances of this weakness.
CWE-912prevents — Secure coding standards reduce the likelihood of introducing hidden code but do not address its detection or removal.
CWE-913prevents — Secure coding standards directly prohibit unsafe dynamic code resource handling and injection patterns.
CWE-914prevents — Secure coding standards directly prohibit uncontrolled dynamic variable access.
CWE-915prevents — Secure coding standards explicitly forbid unsafe dynamic attribute assignment and require property allow-lists.
CWE-916prevents — Secure coding practices include implementing password storage with adequate computational effort.
CWE-917prevents — Secure coding standards require proper escaping and parameterization of expression-language statements.
CWE-923prevents — Secure coding practices can implement endpoint checks but the control itself is process-oriented.
CWE-925prevents — Secure coding practices directly address proper intent verification in broadcast receivers.
CWE-926prevents — Secure-coding standards require explicit permission declarations and intent-filter restrictions to avoid improper exports.
CWE-927prevents — Secure coding standards explicitly forbid implicit intents when handling sensitive information.
CWE-93prevents — Secure coding standards explicitly require neutralization of CRLF sequences, fully addressing this weakness.
CWE-939prevents — Mandates secure coding practices that include proper authorization checks before executing actions triggered by custom URL schemes.
CWE-94prevents — Banning unapproved code samples and unauthenticated web services, combined with secure-coding standards and SAST, prevents the dynamic generation or inclusion of attacker-supplied code.
CWE-940prevents — Secure coding practices can prevent improper source verification if explicitly required.
CWE-941prevents — Secure coding guidelines can require destination checks, but enforcement is not guaranteed.
CWE-942prevents — Secure coding practices require proper configuration of CSP and cross-domain policies to avoid untrusted domains.
CWE-943prevents — Secure coding standards require proper neutralization of special elements in all data queries.
CWE-95prevents — Secure coding explicitly requires neutralization of input before dynamic evaluation, directly mitigating eval injection.
CWE-96prevents — Secure coding explicitly requires proper neutralization of directives in templates, libraries and configuration files.
CWE-97prevents — Secure coding standards explicitly require escaping or disabling SSI constructs in dynamic web content.
CWE-98prevents — Secure coding standards directly require whitelisting and sanitization of filenames used in include/require statements.
CWE-99prevents — Secure coding standards require strict validation and whitelisting of all resource identifiers before use.

Mitigated MITRE ATT&CK techniques (590)

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←M T1001.001←M T1001.002←M T1001.003←M T1003→P T1003.001→P T1003.005→P T1003.008→P T1006←M T1014←M T1027→P T1027.001←M T1027.002←M T1027.003→P T1027.004←M →P T1027.005←M T1027.006←M →P T1027.007←M →P T1027.008←M →P T1027.009←M →P T1027.010←M →P T1027.011←M T1027.013←M T1027.014←M →P T1027.016←M →P T1027.017←M →P T1027.018←M →P T1036←M →P T1036.001→P T1036.002→P T1036.003←M T1036.004→P T1036.005←M →P T1036.008←M →P T1036.009←M T1036.012←M T1037→P T1037.001→P T1037.003→P T1037.004→P T1055←M →P T1055.001←M →P T1055.002←M →P T1055.003←M →P T1055.004←M →P T1055.005←M →P T1055.008←M →P T1055.009←M →P T1055.011←M →P T1055.012←M →P T1055.013←M →P T1055.014←M →P T1055.015←M →P T1056.001→P T1056.003←M →P T1056.004→P T1059→P T1059.001→P T1059.002→P T1059.003→P T1059.004→P T1059.005→P T1059.006→P T1059.007→P T1059.008→P T1059.009→P T1059.010→P T1059.011→P T1059.012→P T1059.013→P T1068←M →M T1071←M T1071.001←M T1071.004←M T1078←P T1078.001←P →P T1078.002→P T1080→P T1095←M T1098→P T1098.004→P T1098.005←M T1098.006→P T1102←M T1102.001←M T1102.002←M T1106→P T1110→P T1110.001→P T1110.002→P T1110.003→P T1110.004→P T1111←M →P T1127←M →P T1127.001←M →P T1127.002←M →P T1127.003←M →P T1129→P T1132←P T1132.001←M T1132.002←M →P T1133←M T1134←M T1134.001→P T1134.004←M →P T1136→P T1137→P T1137.001→P T1137.002→P T1137.003→P T1137.004→P T1137.005→P T1137.006→P T1140→P T1176←M →P T1176.001→P T1176.002←P →P T1185←M →P T1189←P →P T1190←M →M T1195←P →P T1195.001←M →P T1195.002←P →P T1202←M →P T1203←M →P T1204.002→P T1204.003→P T1204.004←M T1204.005←M →P T1205.002→P T1207←M T1210←M →P T1211←M →P T1212←P →P T1213.001→P T1216←M →P T1216.001←M →P T1216.002←M →P T1218←M →P T1218.001←M →P T1218.002←M →P T1218.003←M →P T1218.004←M →P T1218.005←M →P T1218.007←M →P T1218.008←M →P T1218.009←M →P T1218.010←M →P T1218.011←M →P T1218.012←M →P T1218.013←M →P T1218.014→P T1218.015←M →P T1219.001←P →P T1219.003←M T1220←M →P T1221←M →P T1222←M →P T1222.001←P →P T1222.002←M →P T1480.001←M T1484←M T1484.002←M T1496.001→P T1497←M →P T1497.001←P T1497.002←M T1499←P →P T1499.002→P T1499.003→P T1499.004←P →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 →P T1542←M T1542.002←M T1542.003←M T1543→P T1543.001→P T1543.002→P T1543.003→P T1543.004→P T1543.005→P T1546→P T1546.001→P T1546.003→P T1546.004→P T1546.005→P T1546.006←P →P T1546.007→P T1546.008→P T1546.009→P T1546.010→P T1546.011←M →P T1546.012←P →P T1546.013→P T1546.014→P T1546.015→P T1546.016→P T1546.017→P T1546.018→P T1547.001→P T1547.002→P T1547.003→P T1547.004→P T1547.005→P T1547.006→P T1547.007→P T1547.008→P T1547.010→P T1547.012→P T1547.013→P T1547.015→P T1548←M →P T1548.001←P →P T1548.002←P →P T1548.003→P T1548.004→P T1548.005→P T1548.006←M →P T1550←M →P T1550.001←F →P T1550.002←F T1550.003←F T1550.004←F T1552→P T1552.001→P T1552.003→P T1552.004→P T1552.005←M →P T1552.006→P T1552.007→P T1553←P →P T1553.001←M →P T1553.002←M T1553.003←M →P T1553.004←M T1553.005←M T1553.006←M →P T1554←P →P T1555→P T1555.003→P T1555.005→P T1556←M →P T1556.001→P T1556.002→P T1556.003←M →P T1556.004←M →P T1556.005→P T1556.006→P T1556.007←P →P T1556.008→P T1556.009←M T1557.001→P T1558.004→P T1559→P T1559.002→P T1559.003←P →P T1560.002→P T1560.003→P T1563.001→P T1564.007→P T1564.009→P T1564.010→P T1565→P T1565.001→P T1565.002→P T1565.003→P T1566.002→P T1569→P T1569.002→P T1571←M T1572←M T1573.001→P T1574←M →P T1574.001←M →P T1574.004←M →P T1574.005←P →P T1574.006←M →P T1574.007→P T1574.008←P →P T1574.009←P →P T1574.010→P T1574.011→P T1574.012←P →P T1574.013←M →P T1574.014→P T1578←M T1578.001←M T1578.002←M T1578.003←M T1578.004←M T1578.005←M T1587→P T1587.001→P T1587.004→P T1588.005→P T1599←M T1599.001←P T1600←P →P T1600.001←P →P T1600.002←P T1601←P →P T1601.001←P T1601.002←M T1606←M →P T1606.001←M →P T1608.004→P T1610←P →P T1611←M →P T1612←M →P T1620←M →P T1621←P →P T1622←M →P T1647←P T1648→P T1649→P T1666←M T1677←M →P T1678←M T1685←M T1685.001→P T1685.002←M T1685.003←M T1685.004←M T1685.005←M T1686←F T1686.001←M T1686.003←M T1687←M →P T1688←M T1689←P →P T1690←M

Why these map — AI rationale (under review)

T1003prevents — A.8.28's secure coding principles, threat modelling, least-privilege design, secure configuration of tools/environments, and prohibition of insecure techniques (e.g. hard-coded credentials) can stop certain credential-storing or exposure patterns from being introduced into custom software, but the technique is overwhelmingly an OS/runtime post-exploitation action against structures the OS itself maintains, outside the reach of application-level secure coding.
T1003.001prevents — A.8.28's secure coding principles, threat modelling, least-privilege evaluation, secure design, prohibition of insecure techniques, SAST, and vetted-component rules can stop many LSASS-dumping patterns (e.g. custom SSP injection, unsafe debug hooks, or unsafe third-party code) from being introduced, but cannot prevent the built-in Windows LSASS credential-storage and dump mechanisms that ship with the OS.
T1003.005prevents — A.8.28's secure coding governance, principles, threat monitoring, secure design/threat modelling, least-privilege evaluation, and secure packaging/deployment can prevent some classes of credential-caching flaws (e.g. insecure storage or overly permissive defaults introduced in custom code or components), but the technique's dominant vectors rely on post-deployment extraction of legitimately cached OS/domain credentials (Mimikatz, SSSD caches, SYSTEM/sudo access) that secure coding does not stop.
T1003.008prevents — A.8.28 mandates secure coding practices, principles, threat modelling, least-privilege design, removal of hard-coded credentials, and secure handling of authentication components; these reach the design and implementation slice of credential-storage weaknesses that enable T1003.008 but do not stop a privileged process or misconfigured file from dumping the files at runtime.
T1027prevents — A.8.28 mandates secure coding practices, principles, standards, threat modelling, SAST, and vetting of components that can stop many classes of obfuscation (e.g. insecure encoding, command obfuscation via poor language use, or weak third-party components) from being introduced in developed software, but leaves open adversary-controlled payloads, runtime packing, or external files that are never touched by the organization's coding process.
T1027.003prevents — A.8.28 mandates secure coding practices, principles, threat modeling, secure design, prohibition of insecure techniques, SAST, and vetting of components/libraries; these directly reduce the likelihood that developers will introduce steganography (e.g. custom embedding routines or use of vulnerable/obfuscation libraries) into first-party or supplied software, but do not stop adversaries from applying the technique to already-compromised systems or third-party binaries post-deployment.
T1027.004detects — A.8.28 requires logging of errors/suspected attacks plus regular review (and SAST during dev), which can surface compile-after-delivery artifacts or anomalous compilation; this is a minority slice of the technique's post-delivery execution on victim systems rather than a bounded remainder.
T1027.004prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, SAST testing, and vetting of development tools/compilers; this can stop delivery of uncompiled source-code payloads (or their later compilation) in environments built under the control, but the clause is a governance-and-practice requirement whose coverage depends on what the implementer actually prohibits and scans for, leaving a large slice of adversary-chosen delivery vectors and third-party supply-chain code untouched.
T1027.006prevents — A.8.28 mandates secure coding practices, principles, threat modelling, secure design, and prohibition of insecure techniques during development; this can stop an adversary's HTML smuggling implementation from being introduced into first-party or managed code, but leaves the dominant delivery vector (malicious third-party HTML/JS reaching the victim) untouched.
T1027.007detects — A.8.28 requires logging of errors/suspected attacks, regular log review, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface dynamic API resolution in reviewed code or deployed software but does not mandate runtime behavioral detection of the technique itself.
T1027.007prevents — A.8.28 mandates secure coding practices, principles, standards, threat modelling, SAST, removal of defects, and vetting of components/libraries, which can stop many (but not all) forms of dynamic API resolution from being introduced in first-party or third-party code developed under the control.
T1027.008prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, use of vetted components, and SAST testing that can catch or avoid stripping symbols/strings during development, but this is a slice of developer practice rather than a mechanism that stops adversaries from applying stripping to already-compiled or third-party payloads.
T1027.009prevents — A.8.28 mandates secure coding practices, principles, standards, threat modeling, SAST, removal of defects, prohibition of insecure techniques, and vetting of libraries/components, which can stop many (but not all) classes of embedding/obfuscation payloads during development of first-party and third-party code.
T1027.010prevents — A.8.28 mandates secure coding practices, principles, standards, threat modeling, SAST, and removal of defects that lead to vulnerabilities; this reaches the subset of command obfuscation introduced via insecure custom code or poor practices during development, but leaves the bulk (adversary use of built-in language features, tools like Invoke-Obfuscation, or runtime tricks in delivered payloads) untouched.
T1027.014prevents — A.8.28 mandates secure coding practices, threat modeling, SAST, removal of defects, and vetting of components/libraries that can stop many classes of polymorphic/mutating code from being introduced in first-party or approved third-party software; it does not stop an adversary from bringing in or executing already-polymorphic malware.
T1027.016prevents — A.8.28 mandates secure coding principles, standards, threat modelling, SAST, removal of defects, and avoidance of insecure techniques during development; this can stop junk/dead-code insertion from being introduced into first-party or managed third-party software, but does not stop adversaries from adding it to already-compiled malware binaries they control.
T1027.017detects — A.8.28 explicitly requires SAST during/after development plus logging of errors/suspected attacks with regular review to adjust code; this surfaces SVG smuggling (malicious script in XML) when it appears in first-party or reviewed code, but the clause does not mandate runtime or content-filter detection of delivered SVG payloads on user systems.
T1027.017prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, SAST, removal of defects, prohibition of insecure techniques, and vetting of libraries/components; these directly address the construction and use of malicious SVG content (script tags, smuggling payloads, interactive elements) in code that generates or processes SVGs, but only for software developed or maintained under the organization's processes — they do not stop adversaries from crafting or delivering SVGs independently of that code.
T1027.018detects — A.8.28 explicitly requires SAST during/after development plus logging of errors/suspected attacks with regular review, both of which can surface invisible-Unicode concealment in code or scripts; this is limited to what the chosen tools and review scope actually flag rather than universal detection of the technique.
T1027.018prevents — A.8.28 mandates secure coding principles, standards, threat modelling, SAST, removal of defects, and secure practices that can catch or block insertion of invisible Unicode for obfuscation in code/scripts (especially via reviews, static analysis, and prohibiting insecure techniques), but this is only a slice of the technique's attack surface across files, documents, emails, and non-development contexts.
T1036prevents — A.8.28 mandates secure coding practices, standards, threat modelling, SAST, removal of defects, and vetting of components/libraries that can stop many (but not all) masquerading implementations from being introduced into first-party or third-party code.
T1036.001prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, SAST, removal of defects, and vetting of components/libraries, which can stop many (but not all) ways an adversary could introduce or reuse invalid-signature binaries during development or supply-chain steps; it does not address runtime deception, user/analyst perception, or post-build tampering on deployed systems.
T1036.002detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface RTLO-based disguises in code, filenames, or components post-deployment or in review; this is only a slice because the control is primarily a development-time secure-coding process that does not mandate runtime detection tooling or universal coverage of all possible RTLO uses (e.g. in Registry or non-code artifacts).
T1036.002prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and analysis of common programming errors; these can catch or block RTLO-based filename spoofing when treated as a presentation-layer or input-handling defect, but the control is silent on display canonicalization, UI rendering, or non-code artifacts such as registry entries or third-party tools, leaving a large remainder.
T1036.004prevents — A.8.28 mandates secure coding practices, standards, threat modelling, secure design, peer review, SAST and prohibition of insecure techniques that reach the naming/description fields of tasks/services during development, preventing many (but not all) masquerading implementations at source; it does not constrain post-deployment adversary actions or every possible delivery vector.
T1036.005prevents — A.8.28's secure coding principles, standards, threat modelling, secure design, prohibition of insecure techniques, and SAST directly prevent many naming/location masquerading defects (especially in custom/container code) but do not reach all adversary-placed resources or non-development vectors such as post-compromise Registry or ESXi changes.
T1036.008prevents — A.8.28 mandates secure coding practices, standards, threat modelling, SAST, removal of defects, and secure handling of external libraries/components that can stop many (but not all) ways an adversary could introduce or reuse masquerading file-type payloads during development, transfer, or deployment.
T1037prevents — A.8.28's secure coding governance, principles, standards, SAST, threat modeling, and prohibition of insecure techniques (including unauthenticated services) can stop developers from introducing vulnerable boot/logon initialization scripts that enable the technique, but this is limited to in-house and third-party code written under the control and does not address pre-existing OS defaults, vendor-supplied scripts, or runtime configuration outside development.
T1037.001detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface anomalous logon-script persistence artifacts after the fact; this is a minority slice of the class because the clause is overwhelmingly about secure development practices rather than runtime detection of post-compromise adversary behavior.
T1037.001prevents — A.8.28 mandates secure coding principles, standards, threat modelling, prohibition of insecure techniques, SAST, and secure baselines that reach the class of persistence-via-logon-script when that script is introduced as custom/organization code; this is a genuine but minority slice of the technique (most real-world use is configuration of existing scripts or third-party tools rather than new vulnerable code).
T1037.003prevents — A.8.28 mandates secure coding principles, standards, threat modelling, secure design, removal of defects, prohibition of insecure techniques, SAST, and vetting of components/libraries; these can stop an adversary-chosen or custom network logon script containing malicious persistence logic from being introduced during in-house or third-party development, but do not constrain legitimate use or modification of built-in Windows/AD/Group Policy logon script mechanisms by an already-privileged user or admin.
T1037.004detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface RC-script tampering after the fact on covered systems; this is a minority slice of the technique's post-deployment, root-level, cross-reboot execution surface rather than a bounded remainder.
T1037.004prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, removal of insecure techniques, and SAST that can stop an RC-script backdoor from being introduced in first-party or managed third-party code; this is a genuine but minority slice of the technique (most real-world abuse targets unmodified OS/distribution scripts, config, or third-party components outside the org's development governance).
T1055detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface some process-injection artifacts or anomalies, but the clause's focus is secure-development governance and its detection slice is narrow and indirect.
T1055prevents — A.8.28 mandates secure coding practices, principles, threat modelling, SAST, peer review, removal of defects, and secure baselines that can stop many (but not all) classes of injection flaws from being introduced into first-party code; it does not address platform-native legitimate mechanisms, third-party components, or runtime injection into already-running processes.
T1055.001detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface some DLL injection artifacts post-facto; this is a minority slice because the clause is a secure-development practice that does not mandate runtime host/process monitoring or anomaly detection for live injection.
T1055.001prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, least privilege, SAST, and vetted components that can stop many (but not all) classes of DLL-injection vectors at development time; the control is a governance-and-practice mandate whose coverage therefore depends on what the implementer actually enforces, leaving a genuine slice of injection techniques (especially runtime or post-deployment) unreached.
T1055.002prevents — A.8.28 mandates secure coding practices, principles, threat modelling, SAST, and secure design that can stop injection-vulnerable code patterns from being introduced in first-party software; it does not reach adversary PE-injection techniques executed at runtime against already-compromised or third-party processes.
T1055.003detects — A.8.28 requires logging of errors/suspected attacks plus post-operational review and adjustment, plus SAST during development; this surfaces some in-process injection attempts (especially those that trigger detectable errors or are caught in code review), but the clause's scope is development-time secure coding rather than runtime detection of live thread-hijacking, leaving most runtime realizations outside its view.
T1055.003prevents — A.8.28 mandates secure coding practices, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and secure baselines that can stop many classes of injection leading to thread hijacking when followed in development; however it is a process/governance control whose effect depends on implementation rigour and does not reach runtime process-injection vectors in already-deployed code or third-party binaries.
T1055.004detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface APC injection indicators in development, testing or post-deployment review; this is only a slice because the clause is scoped to secure development practices and does not mandate runtime detection mechanisms for live process injection.
T1055.004prevents — A.8.28 mandates secure coding practices, principles, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and secure baselines that can stop APC injection patterns (e.g. unsafe API use, unvetted libraries, missing least-privilege design) from being introduced in first-party or managed third-party code; this is genuine but only a slice because the technique is commonly used in post-compromise adversary tooling or unvetted external binaries outside the organization's development governance.
T1055.005prevents — A.8.28 mandates secure coding practices, principles, threat modelling, SAST, removal of defects, and secure baselines that can stop developers from introducing the PE/TLS callback manipulation patterns that enable this technique; it does not reach runtime process-injection vectors or already-compromised binaries.
T1055.008detects — A.8.28 requires logging of errors/suspected attacks plus regular review (and SAST during dev), which can surface ptrace-based injection when it triggers observable anomalies or leaves detectable code defects, but this is scoped only to what the org chooses to log/review and does not mandate runtime behavioral detection of the live technique.
T1055.008prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, least privilege, SAST, and vetted components that can stop ptrace-based injection patterns (e.g. via hardened memory handling, restricted debug APIs, or removal of unsafe patterns) when applied during development, but leaves a large remainder for runtime process-injection vectors, non-child/higher-privilege targets, and post-deployment behaviors the clause does not reach.
T1055.009detects — A.8.28 requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface proc memory injection indicators in Linux software; however, the control is scoped to development-time practices and post-operational code adjustments rather than runtime detection of the live technique.
T1055.009prevents — A.8.28 mandates secure coding practices, principles, threat modelling, secure design, SAST, removal of defects, and vetted components that can stop many classes of memory-corruption or gadget-supplying flaws used in proc-memory injection, but does not reach the live-process /proc filesystem manipulation or ROP payload construction itself and leaves platform-specific injection vectors as a remainder
T1055.011detects — A.8.28 explicitly requires SAST during/after development plus logging of errors/suspected attacks with regular review to adjust code, which can surface EWM injection patterns or anomalies in Windows-specific code; this is a genuine but minority slice because the control is scoped to development-time and post-operational code review rather than runtime detection of live process injection.
T1055.011prevents — A.8.28 mandates secure coding practices, principles, threat modelling, SAST, removal of defects, and avoidance of insecure techniques that can reduce the likelihood of introducing EWM injection flaws during development of Windows graphical code, but does not guarantee their absence and leaves many implementation/operational factors untouched.
T1055.012detects — A.8.28 requires logging of errors/suspected attacks, regular log review, SAST during development, and monitoring of real-world threats/vulnerabilities, which can surface process hollowing when it leaves detectable artifacts or matches known patterns, but the control's scope is primarily secure-development governance rather than runtime detection of in-process injection.
T1055.012prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, least-privilege evaluation, removal of insecure techniques, SAST, and vetted components; these can stop hollowing patterns (e.g. via safe process-creation wrappers, memory-safety rules, or prohibiting risky APIs) in developed software, but only for code written under the control and with no guarantee against all implementation gaps or third-party binaries.
T1055.013detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface process doppelgänging when it leaves observable artifacts or is known; this is limited to a slice because the technique is fileless, avoids monitored APIs, and runs at runtime in live processes outside the development/testing scope of secure coding.
T1055.013prevents — A.8.28 mandates secure coding practices, principles, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and secure baselines that can stop many classes of injection and memory-corruption flaws before they ship; however, process doppelgänging is an advanced, OS-specific abuse of an obscure, still-enabled API (TxF) that is not among the common/historical defects or language-specific practices the control explicitly targets, leaving a genuine slice of the technique unprevented.
T1055.014detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface VDSO hijacking indicators post-exploitation or in development artifacts, but this is limited to what the organization's chosen scope and tooling actually observe rather than a dedicated detection mechanism.
T1055.014prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, SAST, removal of defects, vetted components, and least-privilege evaluation that can stop VDSO hijacking patterns from being introduced in in-house or third-party code; this is a genuine but minority slice of the Linux-specific technique that also relies on runtime memory protections, process isolation, and post-deployment defenses outside the coding baseline.
T1055.015detects — A.8.28 requires logging of errors/suspected attacks, log review, SAST during development, and monitoring of real-world threats/vulnerabilities; this surfaces ListPlanting-like injection in first-party code or known patterns but does not instrument runtime detection of the live technique in third-party processes or arbitrary post-deployment use.
T1055.015prevents — A.8.28 mandates secure coding practices, principles, threat modelling, SAST, removal of defects, and secure use of libraries/components that can stop many classes of injection including ListPlanting when followed in development; it does not guarantee prevention for all code (especially third-party, legacy, or non-compliant implementations) and the technique can still be introduced at runtime via other T1055 vectors.
T1056.001prevents — A.8.28's secure coding principles, SAST, threat modelling, least-privilege design, removal of insecure techniques, and vetted-component rules can stop many (but not all) implementation paths for keylogging, especially those relying on custom drivers, API hooks, or unsafe third-party libraries in first-party or supplied software; they do not reach OS-level or hardware-buffer methods outside the development scope.
T1056.003prevents — A.8.28's secure coding practices, threat modeling, SAST, secure design, and prohibition of insecure techniques (e.g. unauthenticated services) can stop the insertion of credential-capturing code into web portals during development or maintenance, but this is only a slice: the technique is frequently introduced post-compromise via admin access or web exploits on already-operational systems, which the clause does not address.
T1056.004detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface some hooking-based credential theft after the fact, but this is a minority slice of the technique's runtime behaviors across Windows/Linux/macOS.
T1056.004prevents — A.8.28 mandates secure coding practices, principles, threat modelling, SAST, removal of defects, and vetting of libraries/components that can stop many (but not all) classes of credential-hooking bugs from being introduced in first-party or third-party code.
T1059prevents — A.8.28 mandates secure coding processes, principles, standards, tool configuration, prohibition of insecure techniques, and removal of defects that can enable interpreter abuse, which stops many (but not all) ways the technique can be introduced into first-party or managed third-party code.
T1059.001prevents — A.8.28 mandates secure coding principles, baselines, tool configuration, prohibition of insecure techniques, and SAST that can stop many classes of PowerShell-abusing scripts from being introduced in first-party or managed third-party code; it does not constrain built-in OS interpreters or adversary use of them post-compromise.
T1059.002prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetted components; these can stop many AppleScript abuses (e.g. via code review, banning unauthenticated scripts, or threat-modelling dialog/automation flows) but leave a large remainder (runtime execution of legitimate AppleScript, osascript from non-custom code, or third-party/legacy macOS features) untouched.
T1059.003prevents — A.8.28 mandates secure coding practices, principles, standards, tool configuration, threat modeling, and prohibition of insecure techniques that can reduce the likelihood of introducing code allowing cmd.exe abuse (e.g. via injection, weak remote execution paths, or unvetted scripts), but does not eliminate the built-in Windows shell itself or block all possible abuse vectors.
T1059.004prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, SAST, and vetting of third-party components; these can stop certain classes of shell-script abuse (e.g. unsafe command construction or inclusion of vulnerable Busybox-derived shells) from being introduced during development, but do not prevent an already-present or externally supplied interpreter from being abused at runtime.
T1059.005detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface VB/VBA/VBScript abuse in custom or third-party code but does not broadly instrument runtime execution or document macros across the enterprise
T1059.005prevents — A.8.28 mandates secure coding principles, standards, tool configuration, prohibition of insecure techniques (e.g. hard-coded credentials), SAST, and vetting of components/libraries, which can stop many unsafe uses of VB/VBA/VBScript from being introduced in first-party or third-party code; it does not reach adversary abuse of built-in VB interpreters or macros in Office/documents that ship with the platform.
T1059.006prevents — A.8.28 mandates secure coding principles, secure design, threat modelling, prohibiting insecure techniques, SAST, and vetting of libraries/components; this can stop many (but not all) ways an adversary could introduce/abuse Python for malicious execution in developed software.
T1059.007detects — A.8.28 requires logging of errors/suspected attacks, regular log review for code adjustments, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface JS-based execution anomalies or malicious scripts in reviewed code or deployed software, but this is limited to development/testing and post-operational review rather than runtime detection across all platforms and execution contexts.
T1059.007prevents — A.8.28 mandates secure coding principles, standards, threat modeling, SAST, prohibition of insecure techniques, and vetted components that can stop many classes of JavaScript-based execution abuse (e.g. unsafe eval, untrusted script loading, or inclusion of vulnerable JS libraries) before the code ships; it does not reach every vector (e.g. adversary-supplied JS in drive-by, post-compromise interpreters, or runtime JXA/osascript abuse outside the organization's development pipeline).
T1059.008detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and secure coding that can include SAST), which surfaces anomalous CLI use on managed devices but only where the organization controls the network device code/config and includes it in its review scope; most network device CLI abuse occurs on infrastructure the organization does not develop.
T1059.008prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, prohibition of insecure techniques, and secure baselines that reach network-device firmware/OS code; this stops many classes of CLI-abusing payloads from being introduced, but leaves a genuine slice (adversary use of legitimate CLI features after compromise, or flaws in already-deployed vendor images) untouched.
T1059.009prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, prohibition of insecure techniques, and secure baselines that reach the slice of cloud-API abuse introduced via custom/inhouse/outsourced code or SDK usage; this constrains some instances of the technique but leaves the dominant remainder (abuse of legitimate tenant APIs via stolen credentials, approved CLIs, or cloud shells in already-permissioned environments) untouched.
T1059.010prevents — A.8.28 mandates secure coding principles, secure design, threat modelling, prohibiting insecure techniques, SAST, and vetting of third-party components; these can stop AHK/AutoIT scripts or compiled payloads from being introduced as malicious automation during development, but only for first-party or approved third-party code under the org's SDLC — not for arbitrary adversary-introduced .ahk/.au3/.exe on victim systems.
T1059.011prevents — A.8.28 mandates secure coding processes, principles, standards, tool configuration, threat modeling, SAST, and prohibition of insecure techniques that can reduce the chance an application will ship with an embedded/abusable Lua interpreter or accept/execute untrusted Lua scripts; this is a genuine but minority slice of the technique (most real-world abuse vectors use interpreters already present on the target or supplied by the adversary).
T1059.012prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, removal of insecure techniques, and vetting of components; these can stop hypervisor CLI abuse patterns from being introduced into in-house or third-party code that runs on or manages ESXi, but the control is silent on runtime hardening of the hypervisor CLI surface itself and on already-deployed systems.
T1059.013prevents — A.8.28's secure coding governance, principles, threat monitoring, secure design/threat modelling, least-privilege evaluation, and prohibition of insecure techniques (including unauthenticated services) constrain how container images, CLIs, and orchestration configs are built and deployed, so the technique cannot run in environments developed under it; this is only a slice because the clause is a process that depends on implementation rigour and does not reach runtime container management or already-deployed environments.
T1068prevents — Threat modelling and secure design practices limit the introduction of privilege-escalation bugs that adversaries would otherwise chain after an initial foothold.
T1078.001prevents — A.8.28 mandates secure coding principles, secure defaults, removal of hard-coded credentials, least-privilege design, threat modelling, and vetting of third-party components (including those that ship default accounts), which stops many default-account weaknesses from being introduced in in-house, outsourced, or integrated software; it does not reach factory defaults on appliances, pre-existing OS accounts, or post-deployment credential hygiene that the technique also exploits.
T1078.002prevents — A.8.28's secure coding principles, standards, threat modelling, SAST, removal of defects, and vetting of components can stop certain coding errors that enable credential compromise (e.g. hard-coded creds, insecure defaults, or unvetted libs exposing domain accounts), but this is only a minority slice of the technique's dominant vectors such as OS credential dumping and password reuse.
T1080prevents — A.8.28's secure coding governance, principles, standards, threat monitoring, SAST, peer review, and vetting of third-party components reduce the chance that an adversary can introduce or exploit tainted content in code repositories and shared development artifacts, but do not stop post-deployment network-share binary infections or directory-share pivots that require no code change.
T1098prevents — A.8.28's secure coding practices, threat modeling, least-privilege design, secure defaults, and prohibition of insecure techniques (e.g. hard-coded credentials) can stop certain account-manipulation vectors from being introduced into custom code or components, but this is only a slice of the technique's surface across all listed platforms and does not constrain post-compromise manipulation of existing accounts.
T1098.004prevents — A.8.28's secure coding governance, principles, standards, SAST, peer review, and prohibition of insecure practices (e.g. hard-coded credentials) can stop developers from introducing SSH key management flaws that enable this technique, but the control is silent on runtime configuration, cloud API hardening, network device CLI, and post-deployment file integrity so only a minority slice of the technique is reached.
T1098.006prevents — A.8.28 mandates secure coding practices, secure design/threat modelling, least-privilege evaluation, and secure configuration of development tools that can stop insecure RBAC/ABAC bindings or overly permissive roles from being introduced into container orchestration code or IaC; this is a genuine but minority slice of the technique (most real-world executions rely on post-compromise runtime abuse of already-valid accounts rather than new insecure code).
T1106prevents — A.8.28's secure coding principles, standards, SAST, threat modeling, and prohibition of insecure techniques (including unsafe API use) reduce the chance that first-party or managed third-party code will contain or introduce calls that enable T1106, but cannot stop adversaries from using native APIs already present in the OS, runtime libraries, or unmanaged components.
T1110prevents — A.8.28 mandates secure coding practices, principles, standards, threat modeling, and removal of defects that can produce weak authentication or credential-handling code, which stops many (but not all) brute-forceable secrets from being introduced; the technique can still succeed against non-code factors such as weak user-chosen passwords, policy gaps, or post-compromise credential material.
T1110.001prevents — A.8.28 mandates secure coding principles, standards, threat modelling, least-privilege design, removal of hard-coded credentials, vetted authentication components, and secure configuration of development tools; these directly stop many password-guessing vectors (weak defaults, exposed management services, poor auth libraries, hard-coded secrets) from being present in developed or acquired software, though they do not reach every possible deployment or legacy service.
T1110.002prevents — A.8.28 mandates secure coding practices, principles, standards, threat modelling, removal of defects, and vetting of components (including cryptographic ones); this can stop weak password storage or hashing algorithms that make cracking trivial, but does not reach the dominant case of strong hashes cracked offline with sufficient compute or rainbow tables.
T1110.003prevents — A.8.28 mandates secure coding principles, developer qualification, secure design/threat modelling, prohibiting insecure techniques (e.g. hard-coded passwords), and use of vetted authentication components; these reduce the likelihood that weak/default credentials or flawed auth implementations enabling spraying are introduced, but do not stop an already-deployed service from being sprayed nor reach all platform vectors (e.g. misconfigured cloud identity providers).
T1110.004prevents — A.8.28 mandates secure coding practices, principles, standards, threat modeling, SAST, and secure authentication/cryptographic component selection that can stop credential stuffing vectors in code (e.g. weak password storage, missing rate limiting, improper SSO/federation handling); this is a genuine but minority slice of the technique, which primarily exploits user password reuse and external breach data rather than a coding defect.
T1111prevents — A.8.28's secure coding practices, principles, threat modelling, SAST, prohibition of insecure techniques (e.g. hard-coded secrets), and vetting of components can prevent certain MFA-interception vectors introduced via flawed code (e.g. weak token handling or out-of-band code transmission), but this is only a slice of the technique which also relies on runtime compromise (keyloggers), service provider attacks, and non-code factors.
T1127detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface T1127 abuse of dev utilities in development or operational phases, but this is limited to code review/testing and post-incident logging rather than runtime detection of the technique on production endpoints.
T1127prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, vetting of development tools/libraries, and removal of defects before deployment, which stops many (but not all) classes of trusted-developer-utility abuse from ever being introduced into production code or build pipelines.
T1127.001detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface anomalous or malicious use of MSBuild inline tasks in monitored environments, but the control's scope is development-time secure coding rather than runtime detection of this living-off-the-land technique.
T1127.001prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, SAST, and vetting of development tools/components; this can stop many unsafe MSBuild inline-task patterns from being introduced in first-party or supplied code, but leaves open third-party build chains, legacy code, and attacker-controlled project files that do not go through the organization's secure-coding pipeline.
T1127.002prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetting of components/libraries; these can stop some ClickOnce abuse vectors (e.g. unsafe .NET deployment patterns or unvetted third-party components) but leave many others (user execution, startup folder persistence, rundll32 proxying of already-built malicious ClickOnce packages) untouched.
T1127.003detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface abuse of JamPlus as a build tool for malicious .jam execution (especially post-operational or in reviewed third-party components).
T1127.003prevents — A.8.28 mandates secure coding principles, tool configuration, prohibition of insecure techniques, SAST, and vetted component selection; these can stop adversaries from introducing or reusing JamPlus-based build abuse in developed software, but the control is a governance-and-practice framework whose coverage depends on implementation rigor and does not block all possible abuse of an already-installed reputable build utility.
T1129detects — A.8.28 requires logging of errors/suspected attacks plus regular review (and SAST during dev), which can surface anomalous module-loading behavior after the fact, but this is only a slice of the technique's runtime execution paths and does not mandate runtime detection mechanisms.
T1129prevents — A.8.28's secure coding principles, standards, SAST, threat modelling, prohibition of insecure techniques, and vetting of libraries can stop developers from introducing unsafe dynamic loading patterns (e.g. dlopen/LoadLibrary of untrusted paths or unauthenticated modules) that enable T1129, but this is only a slice of the technique's surface because the control does not reach runtime loader behaviour, OS defaults, or already-compromised binaries.
T1132.002prevents — A.8.28 mandates secure coding practices, principles, standards, threat modeling, SAST, and removal of defects that lead to vulnerabilities; non-standard encoding in C2 is a deliberate obfuscation technique often implemented via custom code that can be caught/prevented by those practices when the encoding logic is authored or reviewed under the control.
T1134.001prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, least-privilege evaluation, removal of programming defects, and prohibition of insecure techniques; these can stop the insecure coding patterns that enable token duplication/impersonation before the vulnerable code is written or deployed, but only for first-party and managed third-party components under the organization's development governance, leaving a large remainder of already-compiled OS binaries, unvetted libraries, and runtime technique abuse that the clause does not reach.
T1134.004prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, prohibiting insecure techniques, SAST, and removal of defects that could enable spoofing via Native API or CreateProcess abuse in developed code, but this is a slice of developer practice that does not stop adversaries using the built-in Windows mechanisms from existing binaries or non-custom code.
T1136prevents — A.8.28 mandates secure coding principles, threat modelling, least-privilege design, secure defaults, and removal of insecure techniques (including unauthenticated services or hard-coded credentials) that would otherwise allow an adversary to create and use a backdoor account; this stops the technique at the development stage for in-house and third-party code, but leaves a large remainder for post-deployment account creation, cloud tenant accounts, and runtime abuse outside the development lifecycle.
T1137prevents — A.8.28's secure coding principles, standards, threat modelling, SAST, prohibition of insecure techniques, and secure baselines for in-house/outsourced/third-party code reduce the likelihood of introducing the Office add-in/macro/template mechanisms abused for T1137 persistence, but do not guarantee their absence (e.g., in COTS Office itself, legacy configurations, or incomplete enforcement).
T1137.001detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface this macro-based persistence technique post-deployment or in code review; however, the clause is scoped to development-time secure coding and does not mandate runtime detection across all Office instances or user environments.
T1137.001prevents — A.8.28 mandates secure coding principles, standards, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and secure baselines that reach macro-enabled templates and Office VBA when applied to in-house or third-party code; this stops the technique at development time for software the org ships or modifies, but leaves the attack surface on unmodified COTS Office installs and on already-deployed templates untouched.
T1137.002prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, SAST, and vetting of components/libraries; these address the class of persistence-via-registry-abuse in custom or in-house Office add-ins but do not reach adversary abuse of an already-installed Office application on an end-user system.
T1137.003detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface this technique post-deployment or in custom code; partial because the clause is scoped to development-time practices and secure-coding governance rather than mandating runtime detection of form-loading or crafted-email execution in end-user Outlook instances.
T1137.003prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, removal of defects, prohibition of insecure techniques, SAST, and vetting of components/libraries; these address the custom-code and third-party aspects of implanting malicious Outlook forms but leave a remainder (e.g. post-compromise registry/mailbox manipulation of existing Outlook, non-development supply-chain insertion, or forms added via other vectors) that the clause does not reach.
T1137.004detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface the anomalous HTML/URL or execution behavior after the fact, but this is only a minority slice of the technique's post-compromise execution and does not mandate detection of the persistence itself.
T1137.004prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, removal of defects, prohibition of insecure techniques, SAST, and vetting of components/libraries; these address the custom malicious HTML/URL and code-execution aspects of the T1137.004 technique in in-house or third-party Outlook customizations, but leave a remainder for configuration abuse of the legacy feature itself in deployed Outlook instances.
T1137.005detects — A.8.28 requires logging of errors and suspected attacks plus regular log review (and SAST during dev), which can surface anomalous Outlook rules or the crafted trigger email as a realized attack, but this is a minority slice of the technique's full attack surface and does not mandate detection of rule creation or loading itself.
T1137.005prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and secure baselines that can stop developers from introducing the code enabling malicious Outlook rules (e.g. unsafe script execution or auto-run logic), but this is only a slice of the attack surface since the technique can also be realized via post-compromise configuration changes or user-added rules without new code.
T1137.006detects — A.8.28 requires logging of errors/suspected attacks, regular log review, and SAST during development plus monitoring of real-world threats/vulnerabilities; this can surface add-in based persistence after the fact or in code review, but the clause is scoped to secure development processes rather than runtime detection of deployed add-ins and does not mandate host/Office telemetry for the technique.
T1137.006prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, SAST, and vetting of components/libraries; this can stop development or reuse of malicious/persistent add-ins (especially custom/VBA/VSTO), but does not block all Office add-in persistence vectors (e.g. pre-installed COM/Outlook add-ins or runtime abuse) and the control is a governance/practice rather than a universal mechanism.
T1140prevents — A.8.28's secure coding principles, standards, threat modelling, SAST, prohibition of insecure techniques, and secure design directly stop many classes of obfuscation from being introduced into first-party or managed third-party code, but have no reach on adversary-controlled malware/utilities or on runtime deobfuscation steps that do not originate in the organization's own development process.
T1176detects — A.8.28 explicitly requires SAST during development plus post-operational logging of errors/suspected attacks with regular review to adjust code; this surfaces malicious or abused extensions in first-party or vetted third-party code but does not address marketplace trust, social engineering delivery, or runtime blending in third-party host apps, leaving a large named remainder.
T1176prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, SAST, least-privilege evaluation, prohibition of insecure techniques, and vetting of third-party components (including those used in IDEs), all of which can stop malicious or vulnerable extensions from being introduced during in-house or supplied development; this is only a slice of T1176 because the technique also covers post-compromise abuse of already-installed benign extensions, marketplace compromises, and user-installed extensions outside the organization's development lifecycle.
T1176.001prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, prohibition of insecure techniques, SAST, and vetted-component selection; these can stop malicious or vulnerable extension code from being written or deployed in first-party or approved third-party software, but the technique is predominantly about post-compromise abuse of the browser's own extension-loading mechanisms or social-engineering installation of extensions the organization never wrote.
T1176.002detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities; this surfaces malicious or anomalous IDE extensions in the development environment but only for the development slice, not for runtime abuse on arbitrary victim systems.
T1176.002prevents — A.8.28 mandates secure coding governance, principles, tool configuration, vetting of components/libraries, and prohibiting insecure practices; this reaches the IDE-extension abuse vector in development-time scenarios (e.g. configuring IDEs, vetting extensions, avoiding side-loading or unvetted marketplace installs) but leaves the post-deployment victim-side execution of already-installed malicious/benign extensions untouched.
T1185detects — A.8.28 requires logging of errors/suspected attacks, regular log review, SAST during development, and monitoring of real-world threats/vulnerabilities, which can surface some browser hijacking indicators or related code defects post-deployment or in development, but this is a minority slice (mostly governance and dev-time) rather than broad runtime detection of the in-browser technique.
T1185prevents — A.8.28 mandates secure coding practices, principles, threat modeling, SAST, and removal of common defects that directly target the injection of malicious code or exploitation of browser software vulnerabilities named in T1185; this stops many (but not all) instances at development time, leaving a slice for runtime injection vectors, inherent browser functionality, and post-deployment pivoting that the clause does not reach.
T1189prevents — A.8.28's secure coding principles, standards, threat modelling, SAST, removal of defects, and secure practices for in-house/third-party code reduce the chance that exploitable client-side flaws (XSS, vulnerable plugins, insecure JS) are introduced into the websites or components an adversary would abuse for drive-by delivery.
T1190prevents — Secure coding standards, threat modelling, and static analysis directly reduce the number of exploitable flaws in public-facing applications that adversaries rely on for initial compromise.
T1195prevents — A.8.28 mandates secure coding governance, principles, tool configuration, vetting of third-party/open-source components, threat monitoring, and secure baselines that directly constrain manipulation of development tools/environments, source code, and open-source dependencies — preventing the technique from succeeding in those named slices — but leaves shipment interdiction, counterfeit sales, and update-channel compromises outside its development-focused scope.
T1195.001detects — A.8.28 explicitly requires monitoring real-world threats/vulnerabilities, SAST during testing, logging/review of errors/suspected attacks, and inventorying/updating external libraries and components, which surfaces some supply-chain compromises in dependencies, tools, and CI/CD after they are present but before or during operational use; this is only a slice because the control is primarily a secure-development governance process, does not mandate broad or continuous detection tooling for pre-receipt manipulation, and leaves many upstream or typosquatting cases outside its scope.
T1195.001prevents — A.8.28 mandates secure coding governance, principles, vetting/reuse of external components, threat monitoring to update practices, and secure baselines that directly constrain many supply-chain manipulation vectors (e.g. prohibiting insecure techniques, mandating vetted libraries, inventory+updates, avoiding typosquatting via selection processes); however, it is a process/practice control whose coverage depends on implementation rigor and leaves residual gaps such as zero-days in third-party components or upstream compromises before vetting occurs.
T1195.002prevents — A.8.28 mandates secure coding governance, principles, threat-informed baselines, SAST, vetting of third-party components, and secure update packaging that directly stop many forms of source-code or build manipulation before release, but leaves open-ended supply-chain vectors such as upstream vendor compromise, distribution-channel hijacking after packaging, and unvetted open-source dependencies chosen by implementers.
T1202prevents — A.8.28 mandates secure coding practices, principles, standards, threat modelling, SAST, removal of defects, and secure baselines that can stop many indirect execution vectors from being introduced in custom or third-party code; it does not reach adversary abuse of already-shipped Windows utilities or system binaries (Forfiles, pcalua.exe, ssh.exe, WSL components) that ship with the OS.
T1203prevents — By enforcing vetted libraries, least-privilege design, and removal of insecure constructs such as hard-coded credentials, the control shrinks the attack surface that client-side exploits target.
T1204.002prevents — A.8.28's secure coding practices, secure design, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and vetting of third-party components reduce the likelihood that delivered software contains exploitable flaws (e.g. in document parsers or script handlers) that an adversary could leverage to turn a user-opened file into arbitrary code execution; this is a genuine but minority slice of the technique, which is primarily driven by social engineering, user action, and post-delivery placement rather than by a coding defect the control can reach.
T1204.003prevents — A.8.28's secure coding governance, principles, threat monitoring, secure design/threat modelling, vetting of external components/libraries, and prohibition of insecure techniques (including unauthenticated services) reduce the chance that an organization produces or deploys a backdoored image or container, but this is only a slice of the technique which also covers adversary-uploaded images to public repos and user error in selecting them.
T1204.005detects — A.8.28 requires monitoring of real-world threats/vulnerabilities, logging of errors/suspected attacks with regular review, and SAST during testing, which can surface malicious libraries in the development pipeline or post-deployment; this is only a slice because the control is scoped to secure coding governance and does not mandate runtime or supply-chain detection of installed malicious libraries in production.
T1204.005prevents — A.8.28 mandates secure coding governance, vetting/reuse of well-vetted external libraries, inventorying and updating them, and avoiding insecure practices; this constrains the supply of malicious or backdoored libraries into the environment but does not stop users from installing unvetted third-party packages via typosquatting or public repos, nor does it block all compromise of popular dependencies.
T1205.002prevents — A.8.28 mandates secure coding practices, principles, standards, threat modeling, secure design, and prohibition of insecure techniques during development (including for in-house, outsourced, and third-party components), which can stop socket filter backdoor mechanisms from being introduced into custom software; however, it does not address pre-existing platform libraries like libpcap/WinPcap, OS-level raw sockets, or adversary use on already-deployed systems.
T1210detects — A.8.28 requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface some T1210 indicators (e.g. in custom code or known vulnerable components) but does not mandate runtime detection of exploitation attempts against remote services.
T1210prevents — A.8.28 mandates secure coding practices, principles, standards, threat modeling, SAST, and removal of common defects that directly stop many programming errors from becoming exploitable remote-service vulnerabilities; it does not reach configuration, patching, or runtime protections for already-shipped services, leaving a bounded but substantial remainder.
T1211prevents — A.8.28 mandates secure coding principles, standards, threat modelling, SAST, removal of defects and vetting of third-party components, which stops many exploitable programming flaws (including those that could be leveraged for stealth/evasion) from reaching production; it does not guarantee absence of all such flaws or cover post-deployment exploitation paths, leaving a genuine minority slice.
T1212prevents — A.8.28's secure coding principles, standards, SAST, threat modelling, removal of defects, and secure design directly stop many (but not all) classes of exploitable programming errors that T1212 relies on, especially in first-party and third-party code developed or integrated under the control.
T1213.001prevents — A.8.28's secure coding governance, principles, threat modeling, least-privilege evaluation, and secure design requirements (especially in planning/before-coding and before-operational phases) directly reduce the chance that Confluence will be configured to host or expose the listed sensitive items (e.g. credentials, architecture diagrams, source snippets) in a development environment.
T1216detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface proxy script abuse when it produces observable anomalies, but this is limited to what the org chooses to log/review and does not mandate runtime detection of the technique itself.
T1216prevents — A.8.28 mandates secure coding principles, standards, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and vetting of third-party components; these reduce the chance that a developer will introduce or retain a signed/trusted proxy script (or custom wrapper) that can be abused for T1216, but the control does not reach pre-existing Microsoft-signed LOLBAS scripts that ship with Windows or are supplied by the vendor.
T1216.001prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetting of components/libraries; these directly address the insecure design and implementation of the signed-but-abusable PubPrn.vbs (and similar living-off-the-land binaries) when the organization develops or modifies code, but leave a bounded remainder for pre-existing Microsoft-signed system scripts the organization cannot alter.
T1216.002detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface anomalous use of SyncAppvPublishingServer.vbs as a LOLBin proxy; this is a minority slice of the technique's post-deployment runtime abuse rather than broad detection coverage.
T1216.002prevents — A.8.28 mandates secure coding practices, principles, standards, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and vetting of components/libraries; these directly reduce the likelihood that an application will ship with an exposed or abusable SyncAppvPublishingServer.vbs call that adversaries can leverage for proxy execution.
T1218prevents — A.8.28's secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetting of components can stop developers from introducing or retaining proxy binaries and unsafe execution paths in custom or third-party code, but this is only a slice of the technique's surface (which primarily abuses pre-existing, signed OS-native binaries that need not be written or chosen by the developer).
T1218.001prevents — A.8.28's secure coding principles, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and vetting of components can stop developers from introducing or retaining CHM-abuse vectors (e.g. unsafe embedding of active content or unpatched help viewers) in in-house or third-party software, but this is only a slice of the technique's attack surface which also includes pre-existing OS components, user execution of delivered CHMs, and legacy/unpatched systems outside the developer's control.
T1218.002prevents — A.8.28 mandates secure coding practices, standards, threat modelling, SAST, and vetting of components/libraries that can stop many classes of malicious code (including some proxy-execution techniques) from being introduced in the first place; it does not address already-compromised control.exe, renamed CPLs, or runtime abuse of a legitimate Windows binary.
T1218.003prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, prohibition of insecure techniques, SAST, and vetted components that can stop many classes of malicious INF/scriptlet/DLL abuse vectors during development of in-house or third-party software, but leaves open the use of already-vulnerable signed binaries like CMSTP.exe itself as well as runtime bypasses of application control.
T1218.004detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface InstallUtil abuse as anomalous/suspicious activity, but this is only a slice of possible detection surfaces rather than a bounded remainder.
T1218.004prevents — A.8.28 mandates secure coding practices, principles, standards, threat modeling, SAST, removal of defects, and vetting of components/libraries that can stop developers from introducing or retaining the .NET attributes and installer patterns InstallUtil abuses for proxy execution.
T1218.005detects — A.8.28 requires logging of errors/suspected attacks plus regular review (and SAST during dev), which can surface mshta.exe abuse when it produces observable anomalies or is caught in code review, but the clause's scope is development-time secure coding and post-op code adjustments rather than runtime detection of this living-off-the-land technique across the enterprise.
T1218.005prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, least privilege, removal of insecure techniques, and SAST that can stop mshta abuse patterns (e.g. hard-coded scripts, unvetted external components, or unsafe execution) from being introduced into in-house or third-party code, but does not constrain adversary abuse of the pre-existing trusted Windows binary itself.
T1218.007prevents — A.8.28's secure coding governance, principles, standards, tool configuration, threat monitoring, and prohibition of insecure techniques (including unapproved samples) reduce the chance that in-house or third-party code will embed or rely on msiexec.exe abuse patterns, but the control does not reach the Windows platform defaults, signed binary behavior, or AlwaysInstallElevated policy that enable the technique.
T1218.008detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface anomalous use of a signed binary such as odbcconf.exe; this is a genuine but minority slice of the technique's post-compromise execution surface rather than broad runtime detection.
T1218.008prevents — A.8.28's secure coding governance, principles, standards, SAST, threat modeling, and secure design requirements can stop developers from introducing or retaining living-off-the-land abuse of signed binaries such as odbcconf.exe in custom software, but this is only a slice of the technique's attack surface (most usage is in already-deployed third-party or legacy code that the organization's own coding process never touches).
T1218.009detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface anomalous use of Regsvcs/Regasm or the malicious registration attributes, but the clause is scoped to secure-development governance and does not mandate runtime detection of this living-off-the-land technique on production Windows systems.
T1218.009prevents — A.8.28's secure coding principles, standards, threat modelling, SAST, prohibition of insecure techniques, and vetting of components reduce the chance that a .NET assembly containing malicious [ComRegisterFunction] or [ComUnregisterFunction] attributes is written, built or introduced, but cannot stop an adversary from supplying or dropping such an assembly post-compromise.
T1218.010prevents — A.8.28 mandates secure coding practices, standards, threat modeling, secure design, prohibition of insecure techniques, SAST, and vetted components that can stop many classes of flaws enabling Regsvr32 abuse (e.g. unsafe COM/DLL loading, weak allowlisting, or unvetted third-party code), but leaves a large remainder of runtime/execution-environment bypasses, signed-binary living-off-the-land behaviors, and post-development operational controls that the clause does not reach.
T1218.011prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, prohibition of insecure techniques, SAST, and vetted-component selection that can stop many classes of malicious DLLs, scripts, or masquerading payloads from ever being introduced, but does not address runtime proxy/abuse of a legitimate signed system binary (rundll32.exe) itself.
T1218.012detects — A.8.28 requires logging of errors/suspected attacks plus regular review (and SAST during dev), which can surface anomalous use of verclsid.exe or related COM abuse in reviewed logs or scans, but this is limited to what the org chooses to instrument and review rather than a dedicated detection mechanism.
T1218.012prevents — A.8.28's secure coding governance, principles, threat monitoring, prohibition of insecure techniques, SAST, and vetted-component rules can stop developers from introducing or retaining COM/CLSID abuse patterns (including verclsid.exe proxying) in custom or third-party code they control, but this is only a slice of the technique's surface because the binary is native/signed Windows OS functionality that adversaries can invoke directly without any organizational code change.
T1218.013prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, least privilege, SAST, and vetting of components/libraries, which can stop many (but not all) ways a developer introduces or permits mavinject.exe abuse for DLL/import injection in custom or third-party code.
T1218.014prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, least-privilege evaluation, removal of insecure techniques, and SAST that can stop the insecure design/implementation steps (e.g. malicious CLSID registration, custom .msc creation, or abuse of signed binaries) from being introduced into in-house or third-party code an organization develops or reuses.
T1218.015detects — A.8.28 requires logging of errors/suspected attacks, regular log review, and SAST during development plus monitoring of real-world threats/vulnerabilities, which can surface Electron-specific abuse (e.g. anomalous child processes or planted JS) when it aligns with the org's chosen scope and tooling, but the clause does not mandate runtime behavioral detection or Electron-specific coverage.
T1218.015prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetting of components/libraries; these directly address planting malicious JS, using insecure Electron configs, or pulling in vulnerable Electron-based components, but the technique can still be realised via runtime abuse of legitimate Electron apps or supply-chain compromise of closed-source third-party Electron apps outside the developer's control.
T1219.001detects — A.8.28 requires logging of errors/suspected attacks during review/maintenance plus monitoring of real-world threats/vulnerabilities to guide secure coding, which can surface anomalous IDE tunneling in dev workflows, but this is limited to post-operational logging/review and does not mandate runtime detection or broad coverage of the technique.
T1219.001prevents — A.8.28 mandates secure coding principles, tool configuration (e.g. IDEs), prohibiting insecure techniques, and vetting of components/extensions; this constrains adversary abuse of IDE tunneling features when those features are introduced or enabled during development, but leaves a large remainder where the IDE is already present, the technique is configured post-deployment, or the development environment itself is compromised.
T1220detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface XSL-scripting abuse when it triggers observable anomalies, but the clause's scope is development-time secure coding and post-op code adjustments rather than runtime detection of this living-off-the-land technique.
T1220prevents — A.8.28 mandates secure coding principles, standards, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and vetting of components; these can stop developers from introducing XSL-scripting patterns or msxsl/wmic abuse in custom code, but the technique is a post-build living-off-the-land abuse of a built-in Windows feature that secure-coding governance reaches only indirectly and incompletely.
T1221detects — A.8.28 explicitly requires SAST during/after development plus logging of errors/suspected attacks with regular review to adjust code; this surfaces template-injection flaws (and their indicators) in first-party or reviewed code but does not instrument runtime document loading or third-party RTF/OOXML consumption outside the development pipeline.
T1221prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetting of components/libraries, which can stop developers from introducing template references that enable T1221; however this is a slice (governed by how rigorously the mandated practices are applied to document formats, RTF/OOXML handling, and third-party components) rather than the bulk of the technique.
T1222prevents — A.8.28 mandates secure coding principles, standards, threat modelling, least-privilege design, removal of insecure techniques, and SAST that can stop developers from introducing the permission-modification logic (or the elevated-privilege paths that enable it) in the first place; this is a genuine but minority slice of the technique, which is overwhelmingly performed at runtime by already-compromised adversary-controlled processes rather than by developer-introduced code defects.
T1222.001prevents — A.8.28 mandates secure coding principles, standards, threat modelling, least-privilege design, removal of insecure practices, and SAST that can stop many permission-modifying patterns (e.g. hard-coded credentials, unsafe defaults, or vulnerable library use) from being introduced into first-party or managed third-party code; it does not stop an already-compromised process or adversary from later running icacls/takeown/attrib against production files.
T1222.002prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, removal of insecure design patterns, and secure baselines that reach many (but not all) permission-related coding or configuration mistakes an adversary could later exploit with chmod/chown.
T1496.001prevents — A.8.28's secure coding, secure design, threat modelling, SAST, least-privilege evaluation, prohibition of insecure techniques, and vetting of third-party components can stop many implementation paths that allow initial compromise and subsequent deployment of compute-hijacking malware, but cannot block all delivery vectors, misconfigurations, or already-compromised environments.
T1497prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, and removal of programming defects that enable exploitation, which can stop many VME/sandbox detection artifacts (e.g. hardcoded checks, insecure environment queries) from being introduced into malware during development; this is only a slice because the technique can still be implemented via advanced, non-obvious methods or in third-party components despite the governance and baseline.
T1499prevents — A.8.28's secure-coding governance, principles, standards, threat modeling, defect removal, SAST, and vetted-component rules can stop many endpoint DoS vectors that arise from application-layer resource-exhaustion or crash bugs introduced in code; they do not address network-flood, botnet, spoofing, or OS-level resource-saturation techniques that require no faulty code.
T1499.002prevents — A.8.28's secure coding principles, secure design/threat modelling, least-privilege evaluation, removal of insecure techniques, and vetted-component selection can stop certain implementation flaws (e.g. missing rate limits, unsafe SSL renegotiation config) that enable service-exhaustion floods, but this is only a slice of the technique whose dominant vectors are volumetric traffic, network-layer exhaustion, or runtime resource limits outside the coded software itself.
T1499.003prevents — A.8.28's secure coding principles, secure design/threat modelling, least-privilege evaluation, removal of programming defects, and secure configuration of development tools can stop many resource-exhaustion flaws from being introduced into application code, but this is only a slice: the technique can also be realised through configuration, third-party components, or runtime behaviour outside the developer's control, and the clause itself is a governance-and-practice mandate rather than a universal mechanism.
T1499.004prevents — A.8.28's secure coding processes, principles, standards, threat modeling, SAST, removal of defects, and vetting of third-party components reduce the introduction or persistence of exploitable vulnerabilities that adversaries could trigger for crashes/DoS, but this is a slice (governance and development-time practices) rather than a universal barrier, with residuals in zero-days, incomplete implementation, and post-deployment re-exploitation.
T1505detects — A.8.28 requires logging of errors/suspected attacks, log review for code adjustments, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface some T1505 abuse (e.g. via anomalous logs or post-install scans), but this is limited to what the organization chooses to instrument and review rather than a broad detection mandate.
T1505prevents — A.8.28 mandates secure coding governance, principles, threat-informed baselines, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetted component selection; these directly stop developers from introducing the malicious or vulnerable extensible server components that T1505 requires, but only for code written or selected under the organization's processes (third-party/legacy/outsourced components and post-deployment installs remain reachable).
T1505.001detects — A.8.28 requires logging of errors/suspected attacks, regular log review, SAST during development, and monitoring of real-world threats/vulnerabilities, which can surface malicious stored procedures or related anomalies in code or runtime, but only for covered development pipelines and monitored components rather than broadly across deployed database instances.
T1505.001prevents — A.8.28 mandates secure coding principles, standards, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and secure handling of third-party components; these directly stop an adversary from being able to introduce a malicious stored procedure or CLR assembly during development or maintenance, but only for code written or modified under the organization's processes (a minority slice of the technique's attack surface, which also includes runtime abuse of existing legitimate stored procedures, post-deployment changes, and third-party database packages outside the development pipeline).
T1505.002detects — A.8.28 mandates logging of errors/suspected attacks, log review, SAST during development, and monitoring of real-world threats/vulnerabilities, which can surface a malicious transport agent as anomalous code or behavior; this is only a slice because the clause is scoped to secure-development practices and does not mandate runtime detection of registered agents in production Exchange pipelines.
T1505.002prevents — A.8.28's secure coding governance, principles, standards, threat modeling, SAST, peer review, and vetting of components directly reduce the likelihood that a developer (in-house or third-party) will write/register a malicious transport agent, but the control is a process that depends on implementation rigor and does not block all possible abuse vectors or already-installed agents.
T1505.003prevents — Secure coding governance and source-code protection controls make it harder for attackers to plant or maintain web shells in production code.
T1505.003detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, all of which can surface a deployed web shell; this is a genuine but minority slice of the technique (post-deployment detection only, not the dominant pre- or during-placement vectors).
T1505.004detects — A.8.28 requires logging of errors/suspected attacks, regular log review, SAST during development, and handling of reported vulnerabilities (via 8.8), which can surface malicious IIS components post-installation; this is a genuine but minority slice of the full technique (installation + runtime use of ISAPI/modules) rather than broad detection.
T1505.004prevents — A.8.28 mandates secure coding principles, secure design/threat modeling, prohibition of insecure techniques, SAST, and vetting of components/libraries; these directly stop an adversary from writing and deploying a malicious IIS extension/filter/module during development, but only for code written under the control — they do not stop post-compromise installation of a pre-built malicious DLL on a running IIS server.
T1525prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, vetting of components/libraries, and secure packaging/deployment; these directly stop an adversary (or insider) from successfully implanting a malicious backdoor during image/container build or modification processes under organizational control.
T1528prevents — A.8.28 mandates secure coding principles, threat modeling, secure design, least privilege evaluation, removal of insecure techniques (e.g. hard-coded secrets), and secure handling of external components/tokens in development and CI/CD pipelines, which stops many (but not all) ways the technique can be introduced or enabled in custom or third-party code.
T1539prevents — A.8.28 mandates secure coding practices, principles, threat modelling, SAST, and secure handling of external components that can stop many session-cookie stealing vectors at development time (e.g. XSS/JS injection, insecure defaults, unvetted libraries, missing HttpOnly/Secure flags, poor session management), but leaves open vectors such as malware scraping memory/disk, phishing/AiTM proxies, and post-compromise theft that do not originate in the application's own code.
T1543prevents — A.8.28's secure coding principles, threat modelling, least-privilege design, prohibition of insecure techniques, SAST, and vetted-component rules can stop developers from introducing the insecure service/daemon creation or modification patterns that adversaries later abuse for T1543, but this is only a slice of the technique (most real-world abuse is post-compromise reconfiguration of already-shipped system components, not a coding defect introduced by the defender).
T1543.001detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface anomalous launch-agent activity after the fact; this is genuine but only a minority slice of the technique's full surface (creation/modification of .plist files, disguise, user-level execution).
T1543.001prevents — A.8.28's secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetting of components can stop developers from introducing or reusing launch-agent persistence code in custom or third-party software, but this is only a slice of the technique (which also covers post-compromise adversary actions on existing agents, non-development vectors, and runtime OS behaviors).
T1543.002prevents — A.8.28 mandates secure coding principles, standards, threat modelling, secure design, SAST, peer review and prohibition of insecure techniques across in-house and third-party code; this reaches the custom-code slice of T1543.002 (e.g. malicious generators or service-file templates written by developers) but leaves the dominant runtime/admin slice (adversary placing .service files, symlinks or drop-ins via shell, package install or existing tools) untouched.
T1543.003prevents — A.8.28 mandates secure coding principles, standards, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and vetting of third-party components; these stop many classes of service-creation/persistence bugs (e.g. unsafe driver loading, hard-coded credentials, unvetted libraries) from being introduced in first- or third-party code, but do not block an already-compromised process from calling CreateService/Registry APIs at runtime.
T1543.004prevents — A.8.28's secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetting of third-party components can stop developers from introducing or reusing Launch Daemon plist/executable patterns that enable persistence, but this is a narrow slice of one macOS-specific technique rather than the bulk of the class.
T1543.005prevents — A.8.28's secure coding principles, secure design/threat modelling, least-privilege evaluation, prohibition of insecure techniques, and secure baselines for in-house/outsourced/third-party code reduce the likelihood that container-management services (Docker/Podman/kubelet/DaemonSets) will be written or configured with the modifiable, persistently-restarting, or privilege-escalating flaws the technique exploits.
T1546prevents — A.8.28's secure coding principles, threat modelling, secure design, least-privilege evaluation, removal of programming defects, and prohibition of insecure techniques (e.g. hard-coded credentials) can stop developers from introducing many classes of event-trigger mechanisms that adversaries later abuse for persistence or privilege escalation, but this is only a slice: the control does not reach already-deployed triggers, runtime configuration of OS/cloud event subscriptions, or non-coding abuse of legitimate ones.
T1546.001prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST testing, and least-privilege evaluation that can stop developers from introducing the registry-modifying code or default-handler logic this technique relies on; it does not stop post-deployment registry edits by admins or already-shipped vulnerable software.
T1546.003detects — A.8.28 requires logging of errors/suspected attacks, regular log review, and SAST during development plus monitoring of real-world threats/vulnerabilities; this can surface some WMI event subscription abuse (especially if it triggers detectable errors or is caught in code review), but the control's scope is primarily secure-development governance rather than runtime detection of post-deployment persistence techniques.
T1546.003prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, least privilege, removal of programming defects, and vetting of components/libraries, which can stop insecure WMI event subscriptions from being introduced in in-house or third-party code; it does not reach adversary abuse of legitimate WMI in already-deployed systems or non-coding vectors.
T1546.004prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and secure baselines that reach configuration-file handling and startup scripts; this stops many (but not all) malicious insertions into shell config files at development time.
T1546.005prevents — A.8.28 mandates secure coding principles, standards, threat modelling, secure design, removal of defects, prohibition of insecure techniques, SAST, and vetting of components/libraries, which can stop trap-based persistence from being introduced in first-party or third-party code developed under the process; it does not reach adversary abuse of legitimate trap handlers already present in the OS or unmodified vendor software.
T1546.006prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, SAST, and vetting of libraries/components; this reaches the binary-modification slice of T1546.006 when the tainted binary is first-party code developed under the control, but does not reach adversary post-compromise binary patching of third-party or already-deployed binaries on macOS.
T1546.007detects — A.8.28 requires logging of errors/suspected attacks, regular log review, and monitoring of real-world threats/vulnerabilities (plus SAST during dev), which can surface anomalous netsh helper DLL registrations or related suspicious activity, but this is limited to what the org chooses to log/review and does not mandate specific detection of the persistence technique itself.
T1546.007prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, SAST, removal of defects, and vetting of components/libraries during development; this can stop malicious or vulnerable Netsh Helper DLL registration code from being introduced in in-house, outsourced, or third-party software, but does not address already-deployed systems, runtime configuration, or adversary abuse of legitimate netsh.exe on existing Windows installations.
T1546.008detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface some post-exploitation anomalous behavior or code patterns associated with this technique, but the clause is scoped to secure-development practices and does not mandate runtime detection of the live accessibility-feature abuse.
T1546.008prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, least-privilege evaluation, and secure configuration of development tools, all of which can stop the insecure design pattern (e.g. binary replacement or IFEO registry abuse) from being introduced in custom or in-house code; it does not stop the technique when the vulnerable accessibility binaries or registry entries already ship with the OS or third-party components.
T1546.009prevents — A.8.28's secure coding principles, threat modelling, secure design, prohibition of insecure techniques, SAST, and vetting of components can stop developers from introducing or retaining the insecure registry configuration and loading logic that enables this technique, but only for first-party or in-house code and does not reach pre-existing OS defaults, third-party apps, or runtime abuse of the mechanism.
T1546.010detects — A.8.28 requires logging of errors/suspected attacks, regular log review, and SAST during development plus monitoring of real-world threats/vulnerabilities, which can surface AppInit DLL abuse in logs or code but only where the organization has chosen to instrument those logs or scan for this specific pattern; the clause sets scope rather than mandating universal detection of the technique.
T1546.010prevents — A.8.28's secure coding governance, principles, threat monitoring, secure design/threat modelling, prohibition of insecure techniques, SAST testing, and vetting of external components can stop developers from introducing or retaining the registry-based AppInit_DLLs configuration that enables this technique, but only for first-party or in-house code under the org's SDLC; it does not reach pre-existing OS defaults, third-party apps, or runtime abuse of the mechanism.
T1546.011prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, prohibition of insecure techniques, SAST, and vetting of components/libraries; these directly reduce the likelihood that custom or third-party code will introduce or retain shim-based persistence/elevation mechanisms (e.g. via unsafe hooking, unvetted compat shims, or poor architecture), but the control is silent on runtime OS-level shim management, admin-privileged shim installation, and non-code configuration of the Windows compatibility framework itself.
T1546.012detects — A.8.28 requires logging of errors/suspected attacks, regular log review, and monitoring of real-world threats/vulnerabilities (plus SAST during dev), which can surface IFEO-based persistence or defense-impairment after the fact; this is limited to what the org chooses to log/monitor and does not mandate runtime detection of the technique itself.
T1546.012prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, prohibiting insecure techniques, SAST, and vetting of components; these address the developer-introduced IFEO registry abuse in custom or third-party code but leave the built-in Windows mechanism itself, its legitimate use by admins, and post-deployment configuration changes untouched.
T1546.013detects — A.8.28 requires logging of errors/suspected attacks, regular log review, and monitoring of real-world threats/vulnerabilities (plus SAST), which can surface malicious profile modifications or anomalous PowerShell behavior post-execution, but this is limited to chosen scopes, code review, and after-the-fact discovery rather than broad runtime detection of the technique.
T1546.013prevents — A.8.28 mandates secure coding principles, standards, threat modelling, prohibition of insecure techniques (including unauthenticated services and hard-coded credentials), SAST, peer review, and secure baselines that reach custom/profile.ps1 scripts written or modified inside the organisation, but does not constrain adversary modification of existing profiles on deployed endpoints nor third-party PowerShell host behaviours.
T1546.014prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, SAST, and vetting of components/libraries; these can stop an adversary-written emond rule or plist from being introduced during development of in-house or third-party code, but the technique can still be realised post-deployment by an attacker with write access to /etc/emond.d/rules/ or the LaunchDaemon plist on a running macOS system.
T1546.015detects — A.8.28 requires logging of errors/suspected attacks, regular log review, SAST during development, and monitoring of real-world threats/vulnerabilities, which can surface COM hijacking indicators in custom code or known patterns but does not mandate runtime detection of the live technique on deployed Windows systems.
T1546.015prevents — A.8.28 mandates secure coding principles, threat modelling, secure design/architecture, prohibition of insecure techniques, SAST testing, and vetting of third-party components; these address many root causes that could allow COM hijacking via registry tampering or malicious code insertion in custom or supplied software, but do not cover all vectors (e.g., already-compromised systems, OS-level registry changes outside dev processes, or non-code persistence in third-party binaries).
T1546.016detects — A.8.28 requires logging of errors/suspected attacks, regular log review, SAST during development, and monitoring of real-world threats/vulnerabilities, which can surface malicious installer-script patterns or anomalies post-deployment; this is only a slice because the clause is primarily about secure development practices rather than runtime detection of adversary installer abuse.
T1546.016prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, peer review and vetting of third-party components (including installers), which can stop malicious or vulnerable installer scripts from being introduced in both first-party and supplied software; it does not reach unmodified legitimate third-party installers an end-user might run or all deployment-time abuse vectors.
T1546.017detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface anomalous udev rule changes or malicious RUN+= actions after the fact, but this is only a slice of possible detection surfaces and does not mandate runtime or file-integrity monitoring of the udev rules directories themselves
T1546.018detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface abuse of Python startup hooks in reviewed code or running environments, but this is limited to what the organization's chosen scope, tools, and review processes actually cover rather than a broad guarantee of detection.
T1546.018prevents — A.8.28 mandates secure coding principles, standards, threat modelling, SAST, prohibition of insecure techniques, and secure configuration of the development toolchain; these reach the slice of the technique that would be introduced by custom first-party or in-house code (e.g. by forbidding or detecting the creation of malicious .pth / sitecustomize.py files during development), but do not constrain adversary placement of such files post-deployment, third-party package installation, or abuse of already-present Python interpreters in production environments.
T1547.001prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, removal of programming defects, prohibition of insecure techniques, SAST, and least-privilege evaluation that can stop developers from intentionally or accidentally adding registry-run-key or startup-folder entries for persistence; this is a genuine but minority slice of the technique (most real-world abuse is post-compromise configuration abuse by already-running malware, not a coding defect introduced at development time).
T1547.002prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, least-privilege evaluation, removal of insecure techniques, and SAST that can catch many (but not all) ways an authentication package reference could be introduced into LSA autostart registry values or related boot-time code.
T1547.003detects — A.8.28 requires logging of errors/suspected attacks, regular log review, and monitoring of real-world threats/vulnerabilities (plus SAST during dev), which can surface anomalous time-provider registrations or malicious DLL loads; this is a minority slice of the technique's full surface (admin-only registry changes at boot, Local Service execution) rather than a bounded remainder.
T1547.003prevents — A.8.28 mandates secure coding practices, threat modelling, secure design, prohibiting insecure techniques, SAST, and vetting of components/libraries, which can stop developers from introducing a malicious time-provider DLL registration during in-house or third-party code development; this is only a slice because the technique can also be introduced post-deployment via admin-privileged configuration changes outside any coding process.
T1547.004prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, least-privilege evaluation, prohibition of insecure techniques, SAST, and vetted components; these reach the design/implementation slice that would stop malicious Winlogon helper registration but leave the post-deployment configuration abuse vector (and non-development controls) untouched.
T1547.005prevents — A.8.28's secure coding governance, principles, threat monitoring, secure design/threat modelling, least-privilege evaluation, and prohibition of insecure techniques (including unauthenticated services) can prevent development or reuse of SSPs that enable this boot-time abuse, but this is only a slice of the weakness since the technique also relies on post-development registry modification and runtime loading that the control does not directly address.
T1547.006prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, SAST, removal of defects, and vetting of third-party components/libraries; these can stop malicious or vulnerable kernel-module code from being introduced during in-house or outsourced development, but the technique is most often realised via runtime loading of already-compiled LKMs/kexts or supply-chain binaries rather than by defects in code the organisation itself writes, leaving a large remainder outside the clause's direct effect.
T1547.007prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, least privilege, removal of defects, and vetting of components/libraries, which can stop a developer from introducing plist-modifying persistence code; this reaches only a slice of the technique (implementation-time defects) rather than the full class, which also includes post-deployment modification of existing plists by adversaries.
T1547.008prevents — A.8.28's secure coding governance, principles, threat monitoring, secure design/threat modelling, SAST, least-privilege evaluation, and vetted-component rules can stop developers from introducing the insecure driver modifications or additions that enable this persistence technique, but only for first-party or in-house code; the technique can still be introduced via third-party drivers, unvetted libraries, or post-deployment runtime hijacks that the clause does not reach.
T1547.010detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface anomalous port-monitor DLL loads or registry changes after the fact; this is a minority slice of the technique's full surface (boot-time SYSTEM-level execution, arbitrary subkeys, no mandated runtime monitoring).
T1547.010prevents — A.8.28's secure coding governance, principles, threat monitoring, secure design/threat modelling, least-privilege evaluation, SAST, and prohibition of insecure techniques (including unauthenticated services) can stop developers from introducing the insecure registry/monitor configurations or custom port-monitor DLLs that enable this technique, but this is only a slice of the attack surface given its reliance on runtime OS configuration, permissions, and third-party components rather than pure code defects.
T1547.012detects — A.8.28 requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities; these can surface the anomalous print-processor registration or malicious DLL load as a suspected attack or discovered vulnerability, but only for code under the organization's development, review or scanning scope — not for post-deployment abuse of the OS print spooler by an already-installed adversary payload.
T1547.012prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, SAST, removal of defects, and vetting of components/libraries during development, which can stop insecure print-processor registration or loading code from being introduced in custom or in-house software but does not address abuse of the existing OS print-spooler mechanism by an already-compromised process or third-party driver.
T1547.013prevents — A.8.28's secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST testing, and vetting of components can stop developers from introducing autostart abuse (or accepting it in third-party code), but this is only a slice of the technique's surface (adversary post-compromise modification of .desktop files or directories is untouched).
T1547.015prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, least-privilege evaluation, removal of programming defects, prohibition of insecure techniques, and SAST testing that can stop malicious login-item registration code from being written or deployed; this reaches only the slice of the technique that lives in custom/inhouse software under the org's SDLC, leaving the dominant remainder (abuse of legitimate APIs by third-party or already-compromised binaries, post-deployment persistence, and non-code vectors) untouched.
T1548prevents — A.8.28 mandates secure coding practices, principles, standards, threat modeling, least privilege, and removal of defects that can produce elevation-control bypasses (e.g. hard-coded credentials, insecure design, common privilege-related errors), so it prevents many instances of the weakness from arising in developed software; it is only partial because the control is a governance-and-practice requirement whose coverage depends on implementation rigor, does not reach adversary abuse of already-correctly-implemented OS mechanisms, and leaves a nameable remainder of third-party or legacy components outside the organization's development processes.
T1548.001prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, removal of insecure techniques, and SAST that can stop setuid/setgid bits from being introduced on attacker-controlled or vulnerable binaries, but the control is a process/governance requirement whose actual coverage depends on implementation rigour and does not reach every possible setuid abuse vector (e.g. already-present system binaries or post-deployment chmod by an adversary).
T1548.002prevents — A.8.28 mandates secure coding practices, principles, threat modeling, least-privilege design, removal of insecure techniques, and SAST that can stop many (but not all) classes of UAC-bypass code defects from being introduced.
T1548.003prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, removal of programming defects, prohibition of insecure techniques, and secure configuration of development tools; these directly stop many poor sudoers or sudo-cache configurations from being introduced in custom code or scripts, but the technique also arises from admin misconfiguration of existing system files, third-party components, and runtime changes that the control reaches only indirectly or not at all.
T1548.004prevents — A.8.28's secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetting of components can stop developers from introducing or retaining AuthorizationExecuteWithPrivileges calls (or the world-writable file patterns that enable it), but the control is a process/governance set whose coverage depends on implementation rigour and does not reach every macOS binary an adversary might modify or supply.
T1548.005prevents — A.8.28's secure coding governance, principles, threat modelling, least-privilege evaluation, secure design and prohibition of insecure techniques (including hard-coded credentials) directly constrain the misconfigurations that create temporary-elevation paths, but the control is scoped to software development and does not reach runtime cloud permission configurations or administrative account management outside the development lifecycle.
T1548.006prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, least privilege evaluation, removal of insecure techniques, and SAST that can stop many classes of permission-abuse or injection flaws that enable TCC manipulation, but leaves a bounded remainder (platform-specific TCC database tampering, SIP bypass, and post-deployment abuse of already-granted native apps) that the control does not reach.
T1550prevents — A.8.28's secure coding principles, threat modelling, least-privilege evaluation, secure design, and prohibition of insecure techniques (e.g. hard-coded credentials) can stop certain classes of alternate-auth-material exposure (e.g. tokens or tickets baked into custom code or containers) from arising, but this is only a minority slice of the technique which primarily lives in credential theft, caching, and runtime bypass outside the developer's code.
T1550.001prevents — A.8.28 mandates secure coding practices, principles, threat modelling, secure design, SAST, and vetting of libraries/components that can stop many classes of token-compromise bugs (hard-coded secrets, insecure OAuth flows, weak token handling, unvetted auth libraries) from being introduced into first-party or reused code; it does not stop runtime theft of already-issued tokens, misconfigured cloud IAM that allows token requests, or adversary phishing of valid tokens.
T1552prevents — A.8.28 mandates secure coding practices, principles, standards, threat modelling, removal of defects like hard-coded credentials, and vetting of libraries/components that directly stop many classes of unsecured credential storage from being introduced into first-party and third-party code; it does not reach all storage locations or post-deployment misconfigurations on the broad set of platforms where the technique can be realised.
T1552.001detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface insecure credential storage in files or code; this is only a slice of the post-compromise search technique across all platforms and credential locations.
T1552.001prevents — A.8.28 mandates secure coding principles, standards, prohibition of hard-coded credentials, secure design/threat modelling, SAST, and vetting of libraries/components, which stops many (but not all) insecure credential storage cases from being introduced into first-party code and approved third-party components.
T1552.003prevents — A.8.28 mandates secure coding principles, prohibiting insecure practices like hard-coded credentials or unauthenticated services, and requires secure design/threat modeling plus removal of defects, which can stop developers from typing credentials into command lines that persist in shell history; this is only a slice because the technique also arises from runtime user behavior on already-deployed systems, not solely from code defects.
T1552.004prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, prohibition of insecure techniques (e.g. hard-coded secrets), and vetted-component selection; these stop many classes of insecure private-key storage from being introduced into first-party or approved third-party code, but do not reach already-deployed keys, OS defaults, or post-compromise search/export steps on the target platforms.
T1552.005prevents — A.8.28 mandates secure coding practices, threat modeling, least-privilege evaluation, SAST, and prohibition of insecure techniques that can stop SSRF flaws enabling metadata API access from arising in custom code or web proxies; this does not address adversary presence on the instance itself or non-code vectors.
T1552.006prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, removal of hard-coded credentials, least-privilege evaluation, and secure configuration of development tools; these directly stop developers from embedding credentials in GPP XMLs or equivalent policy artifacts during creation or reuse, but the technique also covers discovery of legacy GPP files already present on SYSVOL, which the control does not address.
T1552.007prevents — A.8.28's secure coding principles, secure design/threat modelling, least-privilege evaluation, prohibition of insecure techniques, and secure configuration of development tools and environments directly reduce the likelihood that container APIs will be left exposed or that credentials/secrets will be placed where the Docker/Kubernetes APIs can be abused to harvest them; this is a genuine but minority slice of the technique (most real-world realizations stem from runtime misconfiguration and overly permissive service accounts rather than from code defects).
T1553prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, prohibition of insecure techniques (e.g. hard-coded credentials), SAST, and vetting of third-party components, which directly prevents many sub-techniques of T1553 (e.g. creation of maliciously-signed code, use of untrusted libraries, or insecure defaults that undermine trust controls) when followed in development; however, it is a process/governance control whose effect depends on implementation rigor and does not reach all adversary methods (e.g. post-compromise registry or permission changes on existing binaries).
T1553.001prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, removal of programming defects, prohibition of insecure techniques, SAST, and vetting of external libraries/components; these directly address the logic errors, unchecked file types, external-library issues, and bundle-manipulation defects that enable T1553.001, but only for in-house or supplier-controlled code and only where the practices are rigorously followed, leaving a large remainder for adversary-controlled or already-deployed binaries, non-code vectors (USB, curl, drive-by), and post-compromise attribute modification.
T1553.003detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface hijacking attempts that leave detectable artifacts (e.g. registry changes, anomalous signing behavior, or known vulnerable components), but this is scoped only to development-time and post-operational review rather than runtime detection of the technique itself.
T1553.003prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, SAST, and vetting of components/libraries; these address the development-time introduction of the weak SIP/trust-provider registration or DLL-loading logic that adversaries later hijack, but do not stop post-deployment registry or search-order tampering of already-shipped components.
T1553.006prevents — A.8.28 mandates secure coding principles, threat modeling, secure design, least-privilege evaluation, and prohibition of insecure techniques (including hard-coded credentials or unauthenticated services) that directly address the developer practice of weakening or disabling code-signing enforcement during development/testing; this stops the technique at its source for in-house and supplied software, but leaves a bounded remainder for post-deployment OS policy changes, kernel-memory attacks, and third-party components outside the development pipeline.
T1554detects — A.8.28 requires logging of errors/suspected attacks, regular log review, SAST during development, and monitoring of real-world threats/vulnerabilities, which can surface some binary modifications or related indicators (especially in dev or post-incident review), but this is limited to what the org chooses to instrument and does not broadly detect in-production binary patching or replacement across the attack surface.
T1554prevents — A.8.28 mandates secure coding practices, principles, standards, threat modeling, SAST, vetting of components/libraries, and removal of defects that can introduce exploitable vulnerabilities, which directly lowers the chance an adversary can introduce or patch malicious functionality into binaries during development or maintenance.
T1555prevents — A.8.28 mandates secure coding practices, principles, threat modeling, least-privilege design, removal of hard-coded secrets, vetted components, and SAST that can stop many insecure credential-storage patterns from being introduced into custom software; this prevents the technique on developer-controlled code but leaves platform defaults, third-party password managers, OS credential stores, and non-coded storage locations untouched.
T1555.003prevents — A.8.28 mandates secure coding practices, principles, threat modelling, least privilege, removal of defects, and secure handling of components/libraries that can reduce the likelihood of introducing browser credential storage flaws or insecure defaults that enable T1555.003, but does not guarantee prevention of all such weaknesses (e.g., in third-party browser code or memory-search vectors).
T1555.005prevents — A.8.28 mandates secure coding practices, principles, threat modeling, secure design, least privilege, removal of defects, and secure handling of components/libraries that can reduce the likelihood of implementation flaws enabling memory scraping, insecure storage, or weak master-password handling in password-manager code (or in the apps that integrate with them), but does not stop post-compromise extraction techniques, brute-force against the master password, or already-shipped vulnerable password-manager binaries.
T1556prevents — A.8.28's secure coding principles, standards, threat modelling, SAST, prohibition of insecure techniques (e.g. hard-coded passwords), and vetting of components directly stop many classes of authentication-process modification defects from being introduced in first-party or third-party code, but the control is silent on runtime protection, configuration of already-deployed auth mechanisms (e.g. PAM/LSASS/SAM), and post-deployment adversarial modification of binaries or plugins.
T1556.001detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review, SAST during development, and monitoring of real-world threats/vulnerabilities, which can surface indicators of LSASS patching or anomalous domain-controller authentication behavior, but only where those signals fall inside the chosen monitoring scope and tooling.
T1556.001prevents — A.8.28's secure coding baseline, threat monitoring, secure design/threat modelling, SAST, prohibition of insecure techniques, and vetting of components can stop the introduction of the specific LSASS patching backdoor during development of in-house or third-party code that ships on domain controllers, but this is only a slice of the attack surface (adversary-supplied malware, post-deployment patches, runtime injection into already-deployed LSASS).
T1556.002prevents — A.8.28's secure coding governance, principles, threat monitoring, secure design/threat modelling, prohibition of insecure techniques, SAST testing, and vetting of third-party components can stop developers from introducing or retaining a malicious password filter DLL, but this is only a slice of the technique's attack surface (e.g. does not address runtime registration, existing compromised filters, or non-development vectors).
T1556.003detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface malicious PAM modifications or anomalous auth behavior after the fact, but this is only a minority slice of the technique's post-deployment execution on Linux/macOS systems.
T1556.003prevents — A.8.28 mandates secure coding practices, principles, threat modeling, SAST, peer review, and secure baselines that reach custom/in-house code and (via inventory/vetting) third-party components; this stops many classes of PAM modification/backdoor but leaves a genuine slice (e.g., supply-chain compromise of vetted libs, runtime patching of deployed binaries, or config-file tampering outside the development lifecycle) unreached.
T1556.004prevents — A.8.28 mandates secure coding principles, prohibiting insecure design techniques like hard-coded passwords and requiring secure design/threat modeling plus vetted components, which would stop the implant of a backdoor password during OS image patching if the development or modification process falls under the organization's governance; however, the technique targets deployed network device images (often vendor-supplied or post-deployment), which sits outside the clause's primary in-house/outsourced software development scope.
T1556.005prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques (e.g. hard-coded secrets), secure baselines, and vetting of components/libraries; this reaches the configuration and development practices that would stop reversible encryption from being enabled in new/updated AD-integrated software or custom components, but leaves the bulk of the technique (adversary-driven runtime changes via GPO, FGPP, or PowerShell against existing production AD accounts) untouched.
T1556.006prevents — A.8.28's secure coding principles, standards, threat modeling, secure design, prohibition of insecure techniques, and SAST directly prevent many classes of MFA bypass code/config defects (e.g. hard-coded secrets, improper auth logic, vulnerable patching) when applied to MFA-related software and components; it does not reach all adversary methods such as abusing legitimate admin features or policy exclusions post-compromise.
T1556.007prevents — A.8.28's secure coding governance, principles, threat monitoring, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetting of components directly reduce the likelihood that the authentication processes (on-prem agents, AD FS config, DLL loading) will contain the modifiable/backdoorable defects the technique relies on; this is a genuine but minority slice of the hybrid-identity attack surface whose dominant vectors live in operational compromise and cloud-side admin rather than in the initial code defects.
T1556.008detects — A.8.28 requires logging of errors/suspected attacks, log review, and SAST during development plus monitoring of real-world threats/vulnerabilities; this surfaces some post-installation anomalous logon or registry activity tied to the technique but does not mandate runtime detection of the specific credential-capture behavior.
T1556.008prevents — A.8.28's secure coding governance, principles, standards, threat modeling, SAST, and vetting of components/libraries can stop developers from introducing the insecure Registry-based registration and credential-capture logic that enables this technique, but only for first-party or in-house code; it does not reach adversary-planted third-party DLLs or post-deployment Registry manipulation on production systems.
T1557.001prevents — A.8.28's secure coding principles, threat modelling, secure design, least-privilege evaluation, and prohibition of insecure techniques (e.g. unauthenticated services) can prevent vulnerable name-resolution or relay code from being introduced in custom Windows software, but the technique is a runtime network behavior on Windows platforms that does not require a coding defect and is outside the control's development-focused scope.
T1558.004prevents — A.8.28's secure coding principles, secure design/threat modelling, prohibition of insecure techniques, and use of vetted cryptographic components can prevent the insecure configuration (disabled pre-auth + weak RC4) from being introduced in custom or third-party code, but the technique also applies to misconfigured accounts in existing Windows/AD environments outside the development process.
T1559prevents — Mandating secure coding techniques and peer review reduces the likelihood of insecure inter-process communication paths that could be abused for execution.
T1559.002prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and secure baselines that can stop DDE-based command execution from being introduced in custom or in-house code (e.g. by banning DDE formulas in Office/CSV handling or requiring safer IPC alternatives), but this is only a slice: the technique is most commonly delivered via third-party Office documents, poisoned files from external sources, or registry-enabled legacy features that the control's governance and development-focused practices do not block.
T1559.003prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, input sanitization, least privilege, removal of insecure techniques and SAST testing that directly target the improper validation/sanitization and poor protocol-definition issues that enable T1559.003; it does not guarantee their complete or universal application across all macOS developers or third-party components.
T1560.002prevents — A.8.28's secure coding governance, principles, standards, tool configuration, prohibition of insecure techniques, and vetting of third-party libraries can stop an adversary from linking or using archival libraries in compiled custom code, but leaves the preinstalled system libraries (bzip2, zip) and their use in non-custom or interpreted code untouched.
T1560.003prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, removal of defects, and prohibition of insecure techniques (including hard-coded secrets and unapproved samples) that can stop many custom XOR/stream-cipher implementations from being introduced in the first place; it does not reach every possible custom archival method an adversary could write.
T1563.001prevents — A.8.28 mandates secure coding practices, principles, threat modelling, least-privilege evaluation, removal of insecure design patterns, and secure configuration of development tools that can stop SSH-agent or session-handling code from exposing sockets, keys, or root-level hijack vectors before the flawed software is written or deployed.
T1564.007detects — A.8.28 explicitly requires SAST during development plus post-operational logging/review of errors/suspected attacks and handling of reported vulnerabilities, which can surface VBA stomping artifacts in first-party or reviewed code; this is only a slice because the control is scoped to secure-development governance and does not mandate runtime or forensic detection of stomping in arbitrary third-party Office documents.
T1564.007prevents — A.8.28 mandates secure coding principles, standards, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and secure handling of third-party components; these directly stop an adversary from introducing or retaining malicious p-code in VBA during development or reuse, but only for code written or modified under the organization's processes — they do not stop an adversary from stomping an already-compiled malicious document obtained from elsewhere.
T1564.009detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review, SAST during development, and monitoring of real-world threats/vulnerabilities, which can surface resource-fork abuse when it leaves detectable artifacts or matches known patterns, but the control is scoped to secure-development processes and does not mandate runtime detection of this macOS-specific hiding technique.
T1564.009prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST testing, and vetting of components/libraries; these can stop developers from introducing resource-fork hiding techniques on macOS, but the control is a broad governance-and-practice clause whose coverage of this niche, platform-specific technique depends on whether the organisation's chosen principles and tooling explicitly address it.
T1564.010prevents — A.8.28 mandates secure coding practices, threat modeling, secure design, SAST, removal of defects, and vetting of components/libraries, which can stop many classes of argument-spoofing enablers (e.g., unsafe memory writes, insecure process creation patterns, or unvetted hollowing code) from being introduced; it does not reach runtime PEB manipulation techniques that rely on already-compromised processes or native API abuse after initial execution.
T1565prevents — A.8.28's secure coding principles, standards, threat modelling, SAST, defect removal, and secure design directly stop many classes of data-manipulation flaws (e.g. injection, missing validation, unsafe deserialization) from reaching production, but only for first-party and managed third-party code; it does not address runtime manipulation after deployment, adversary-in-the-middle attacks on data in transit/storage, or complex process-specific manipulation requiring specialized expertise outside the development lifecycle.
T1565.001prevents — A.8.28's secure coding principles, standards, threat modelling, SAST, defect removal, least-privilege design and vetted-component rules reduce the chance that an application will contain the logic or access paths an adversary needs to reach and alter stored data at rest; this is a genuine but minority slice of the technique (most real-world stored-data manipulation uses post-compromise access or separate tools rather than an app-level coding flaw).
T1565.002prevents — A.8.28's secure coding principles, standards, threat modelling, secure design, SAST, removal of defects, and least-privilege evaluation directly stop many classes of transmitted-data manipulation that arise from insecure code (e.g. missing integrity checks, improper deserialization, or weak network handling), but the technique can also be realized through configuration, third-party components, or runtime interception outside the developer's code, leaving a genuine minority slice prevented.
T1565.003prevents — A.8.28's secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, peer review and vetting of components reduce the chance that an application will contain the modifiable binaries or runtime data paths an adversary would alter for T1565.003, but this is only a slice: the technique can still be realised via post-compromise binary patching, configuration changes, or supply-chain insertion outside the developer's secure-coding boundary.
T1566.002prevents — A.8.28's secure coding practices, threat modeling, secure design, SAST, and vetting of components can prevent certain classes of vulnerabilities (e.g. browser exploits, malicious downloads, or OAuth consent flaws) that the malicious link is designed to trigger, but the social engineering delivery, user execution, and email-based targeting of the technique sit outside the coding layer.
T1569prevents — A.8.28's secure coding governance, principles, standards, threat modeling, SAST, and prohibition of insecure techniques (including unauthenticated services) reduce the likelihood that developers will introduce or leave abusable services/daemons, but this is a minority slice of the technique's surface (most abuse targets existing OS services rather than custom code defects).
T1569.002prevents — A.8.28's secure coding principles, secure design/threat modelling, least-privilege evaluation, prohibition of insecure techniques, SAST, and vetted-component rules can stop many service-execution vectors (especially those introduced via custom code or libraries), but the technique's dominant abuse surface is OS-provided service control manager utilities and APIs that remain available on Windows regardless of application-level secure coding.
T1573.001prevents — A.8.28 mandates secure coding practices, principles, standards, threat modelling, secure design, and vetting of cryptographic components; this reaches the subset of T1573.001 cases where weak/broken algorithms (e.g. RC4, DES) or insecure key handling are introduced via poor coding, but does not stop an adversary from deliberately choosing and correctly implementing a strong symmetric algorithm such as AES to hide C2.
T1574prevents — A.8.28's secure coding practices, secure design/threat modelling, least-privilege evaluation, prohibition of insecure techniques, SAST, and vetted-component selection stop many (but not all) hijack vectors from being introduced into first-party or third-party code the organization writes or selects.
T1574.001detects — A.8.28 requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface some DLL hijacking/sideloading indicators in developed software but does not mandate runtime detection or cover the full technique surface (especially post-deployment abuse vectors).
T1574.001prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, SAST, and vetted component selection that can stop many (but not all) classes of DLL sideloading, search-order hijacking, and phantom/substitution flaws at development time; the remainder is runtime configuration, third-party binaries, and post-deployment hijacks outside the coding baseline.
T1574.004detects — A.8.28 requires logging of errors/suspected attacks, regular log review, SAST during development, and monitoring of real-world threats/vulnerabilities, which can surface dylib hijacking indicators in code or runtime but only for a slice (e.g., in-house development or scanned components) rather than broadly across deployed macOS applications.
T1574.004prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, SAST testing, and vetting of external libraries/components; these address the developer-side misconfigurations (search path ordering, weak linking, unvetted dylibs) that enable T1574.004 but do not reach all runtime loader behaviours or every vulnerable third-party binary an app may load.
T1574.005detects — A.8.28 requires logging of errors/suspected attacks, regular log review, SAST during development, and monitoring of real-world vulnerabilities/threats, which can surface some installer permission weaknesses (especially in first-party code or known patterns), but does not mandate runtime detection, installer-specific analysis, or coverage of third-party installers post-deployment.
T1574.005prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, removal of insecure design techniques, and secure baselines that reach installer permission and packaging issues in developed or in-house software, but does not reach third-party installers or the runtime permission weaknesses exploited after deployment.
T1574.006prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibition of insecure techniques, SAST, and vetted-component selection that can stop many (but not all) dynamic-linker hijacking vectors when applied during development of in-house or third-party software.
T1574.007prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, removal of insecure practices, and vetted components; these can stop many (but not all) coding patterns that produce PATH-interception flaws, especially in custom software and scripts that rely on the variable.
T1574.008detects — A.8.28 requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface search-order hijacking patterns or vulnerable non-full-path calls in reviewed code or running software, but this is only a slice of possible detections rather than a broad or guaranteed mechanism.
T1574.008prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, use of vetted components, and SAST testing that can stop developers from writing or retaining code vulnerable to search-order hijacking (e.g. calls without full paths).
T1574.009detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface path-interception attempts or related anomalies after the fact, but this is only a minority slice of the technique's surface (mostly runtime hijack on unmonitored paths) and the clause's primary focus is secure coding to stop defects rather than runtime detection.
T1574.009prevents — A.8.28 mandates secure coding principles, standards, threat modelling, secure design, removal of common defects, and use of vetted components; these directly address the class of unquoted-path defects when applied to code that sets paths (including in-house, outsourced, or third-party components), but the control is a process/governance requirement whose actual coverage depends on implementation rigour and does not reach every possible path-setting site or legacy binary.
T1574.010detects — A.8.28 requires logging of errors/suspected attacks plus regular log review (and SAST during dev), which can surface anomalous service-binary behavior or related permission anomalies after the fact, but this is a minority slice of the technique's execution surface rather than a broad detection mechanism.
T1574.010prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, removal of insecure design techniques, and secure baselines that reach the permission and binary-handling slice of this Windows-specific hijacking technique, but the control is a broad governance-and-practice mandate whose coverage of this post-deployment service-binary permission flaw is a minority slice rather than the bulk.
T1574.011prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, removal of programming defects, and secure baselines that reach the class of permission/configuration weaknesses introduced during development of in-house or third-party code; this stops many instances of the technique at authoring time, but leaves a genuine remainder (misconfigurations of OS-default services, runtime Registry changes outside the development lifecycle, and components not governed by the org's secure-coding process).
T1574.012detects — A.8.28 requires logging of errors/suspected attacks, regular log review, and monitoring of real-world threats/vulnerabilities (plus SAST during dev), which can surface anomalous .NET profiler loading or related suspicious behavior in operational .NET processes, but this is only a slice of possible detection surfaces for the technique.
T1574.012prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, prohibition of insecure techniques, SAST, and vetted components during development, which can stop COR_PROFILER abuse patterns from being introduced in in-house or third-party .NET code; this is only a slice because the technique can still be enabled at runtime via environment variables or registry changes outside the development process.
T1574.013prevents — A.8.28 mandates secure coding practices, principles, threat modelling, secure design, SAST, removal of defects, and prohibition of insecure techniques during development; this can stop the introduction of the specific coding patterns (e.g. unsafe PEB/KernelCallbackTable manipulation, missing integrity checks on callbacks) that enable the technique, but only for first-party or in-house code written under the process — it does not reach adversary-controlled binaries, already-compromised third-party components, or runtime abuse after deployment.
T1574.014detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface AppDomainManager injection indicators in .NET code or runtime behavior, but only for covered development pipelines and not universally across deployed processes.
T1574.014prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, prohibiting insecure techniques, SAST, and vetting of libraries/components; these address the class of insecure loading/assembly hijacking in .NET development (including config/env tampering vectors) for in-house and third-party code, but only as a practice whose coverage depends on implementation rigour and does not guarantee elimination of all such defects.
T1587prevents — A.8.28 mandates secure coding processes, principles, standards, threat modeling, SAST, and vetting of components that an adversary (or its contractors) would follow when developing in-house capabilities such as malware or exploits, thereby reducing the likelihood those capabilities contain exploitable flaws that enable later ATT&CK techniques.
T1587.001prevents — A.8.28 mandates secure-coding processes, principles, standards, threat modeling, SAST, defect removal, and vetted-component selection that directly lower the chance an adversary's in-house or contracted malware development will succeed in producing functional, evadable payloads or C2; this is a genuine but minority slice of the technique because the control only governs code written under the organization's own practices and cannot stop external actors, skill acquisition, or infrastructure choices outside its boundary.
T1587.004prevents — A.8.28 mandates secure coding processes, principles, standards, threat modeling, SAST, defect removal, and vetted components that reduce the introduction of exploitable bugs, directly lowering the supply of vulnerabilities an adversary can discover/fuzz/patch-analyze to build custom exploits.
T1588.005prevents — A.8.28's secure coding governance, principles, standards, SAST, threat modeling, and vetting of third-party components reduce the introduction and persistence of exploitable bugs, thereby preventing many (but not all) vulnerabilities that adversaries could buy/steal/download and weaponize in later phases.
T1600prevents — A.8.28's secure coding governance, principles, standards, threat modeling, SAST, and vetted crypto-component selection directly stop many classes of implementation defects that enable T1600 sub-techniques (e.g. weak ciphers, reduced key space, disabled hardware via bad config), but cannot stop post-deployment device compromise such as Modify System Image (T1601) that bypasses the original secure code.
T1600.001prevents — A.8.28's secure coding principles, standards, threat modelling, SAST, prohibition of insecure techniques, and vetting of cryptographic components directly reduce the chance that weak key sizes or cipher strength are introduced during development or component selection, but this is only a slice of the technique (which also covers post-compromise modification of deployed device images via T1601).
T1601prevents — A.8.28's secure coding governance, principles, threat modeling, SAST, vetting of components, and prohibition of insecure techniques (including during maintenance/modification of packages) reduce the chance that developers will introduce the specific code changes that realize T1601, but only for first-party or in-house code; the technique's core scenario is post-deployment modification of monolithic firmware images on deployed network devices, which the control's development-time focus reaches only as a minority slice.
T1606prevents — A.8.28's secure coding principles, secure design/threat modelling, prohibition of insecure techniques (e.g. hard-coded secrets), vetted crypto components, and removal of defects directly stop many classes of credential-forging bugs in web apps and auth code; it does not stop all adversary-side forging vectors (e.g. abusing legitimate AssumeRole APIs with already-compromised accounts) or non-code issues.
T1606.001prevents — A.8.28 mandates secure coding practices, standards, threat modelling, SAST, and secure handling of secrets/cryptography/auth components that can stop many (but not all) cookie-forging vectors at development time; the control is a practice rather than a universal mechanism, so coverage is an implementer-chosen slice rather than the bulk with a bounded remainder.
T1608.004prevents — A.8.28 mandates secure coding practices, principles, standards, threat modeling, SAST, and secure handling of external components/libraries that directly reduce the likelihood an adversary can successfully stage malicious web content (e.g. injected JavaScript) on an adversary-controlled or compromised site as part of T1608.004 preparation.
T1610prevents — A.8.28 mandates secure coding practices, secure design/threat modelling, least-privilege evaluation, prohibition of insecure techniques, and vetted-component selection that can stop an adversary from building or introducing a malicious/vulnerable/privileged container image in the first place; this is a genuine but minority slice of the technique (most real-world deployments use existing images or runtime misconfigurations outside the development pipeline).
T1611prevents — A.8.28 mandates secure coding principles, threat modelling, secure design/architecture, least-privilege evaluation, prohibition of insecure techniques, and SAST that can stop many container-escape flaws (e.g. bind mounts, privileged containers, unsafe syscalls, hard-coded secrets) at development time; it does not reach runtime configuration, hypervisor vulnerabilities, or all post-deployment escape vectors.
T1612detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, and monitoring of real-world threats/vulnerabilities, which can surface anomalous build activity or malicious artifacts in images on the host; this is a genuine but minority slice of the technique (e.g., post-build detection via review or SAST on the resulting image) rather than a bounded remainder.
T1612prevents — A.8.28's secure coding governance, principles, threat monitoring, secure design/threat modelling, SAST, and vetting of components/libraries can stop insecure build practices or malicious inclusions that enable on-host image builds, but this is a minority slice of the technique (which is primarily an operational API abuse, not a code defect).
T1620detects — A.8.28 requires logging of errors/suspected attacks plus post-operational review and adjustment, plus SAST during development; this can surface reflective loading when it produces observable anomalies or is present in reviewed code, but the clause's scope is development-time secure coding rather than runtime detection of in-memory loading, leaving most live instances outside its view.
T1620prevents — A.8.28 mandates secure coding practices, principles, threat modelling, SAST, removal of defects, prohibition of insecure techniques, and vetted components; these can stop many (but not all) patterns that enable reflective code loading, especially in custom first-party or third-party code developed under the control.
T1621prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, least privilege, and prohibiting insecure techniques (including unauthenticated services), which can prevent classes of MFA bypasses introduced via flawed code in custom apps or auth flows; it does not address the dominant abuse of legitimate MFA request generation against configured services.
T1622prevents — A.8.28 mandates secure coding principles, threat modelling, secure design, removal of programming defects, prohibition of insecure techniques, SAST testing, and secure handling of third-party components, all of which can stop many debugger-evasion checks (e.g. PEB walks, SEH abuse, OutputDebugString loops, or use of known-evasion libraries) from being introduced; it does not reach every possible evasion (especially novel or environment-specific ones written after deployment) so the coverage is a genuine but incomplete slice.
T1648prevents — A.8.28 mandates secure coding principles, secure design/threat modelling, least-privilege evaluation, prohibition of insecure techniques, SAST, and vetted-component selection; these can stop insecure serverless functions or workflows from being introduced in the first place, but the clause is silent on runtime configuration, IAM permissions, event-trigger rules, and already-deployed cloud services that live outside the organization's development lifecycle.
T1649prevents — A.8.28 mandates secure coding principles, threat modeling, secure design/architecture, least-privilege evaluation, removal of insecure techniques (e.g. hard-coded credentials), and vetting of cryptographic components, which directly blocks many certificate forging, misconfiguration, and insecure-storage defects that enable T1649; it does not address runtime theft of existing valid certificates, post-deployment CA key compromise, or all enrollment-rights issues.
T1677detects — A.8.28 explicitly requires logging of errors/suspected attacks, regular log review to adjust code, SAST during testing, monitoring of real-world threats/vulnerabilities, and handling of reported vulnerabilities, all of which surface poisoned-pipeline indicators after they are introduced but before or after operational impact; this is a genuine but minority slice because the clause is overwhelmingly a preventer via secure-coding governance and the detection elements do not systematically cover all three poisoning scenarios (especially public/fork-based ones).
T1677prevents — A.8.28 mandates secure coding governance, principles, threat-informed baselines, secure design/threat modelling, peer review, SAST, prohibition of insecure practices, and controlled environments that directly stop many Direct/Indirect/Public pipeline poisoning vectors (e.g. malicious config changes, unvetted scripts, unsafe triggers, or pull-request inputs) when applied to CI/CD code; it is only partial because the clause is a process requirement whose coverage depends on implementation rigour and does not universally eliminate every self-hosted-runner or public-fork scenario.
T1685.001prevents — A.8.28's secure coding governance, principles, threat monitoring, secure design/threat modelling, SAST, and prohibition of insecure techniques (including unauthenticated services or hard-coded elements) can stop certain implementation flaws that enable T1685.001 (e.g. weak service hardening or audit config in custom code), but this is only a slice of the technique's attack surface which is mostly OS-level admin actions on stock components rather than code defects.
T1687prevents — A.8.28's secure coding processes, principles, standards, SAST, defect removal, threat monitoring, and secure design directly reduce the introduction of exploitable programming errors in defensive components (including in-house, third-party and open-source security tools), preventing many T1687 opportunities at the source; partial because it is a governance-and-practice mandate whose coverage depends on implementation rigor and cannot reach every possible defensive component or zero-day.
T1689prevents — A.8.28's secure coding governance, principles, updated tools, vetted components, and prohibition of insecure techniques (including hard-coded or unapproved elements) can stop developers from introducing or retaining backward-compatibility paths and outdated feature versions that enable downgrade attacks, but this is only a slice of the technique's surface (e.g., runtime forcing, network protocol negotiation, or boot-manager tampering lie outside the coding baseline).

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

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 A04→P A06→P A07→P A09←P

Why these map — AI rationale (under review)

A01blocks — A.8.28 mandates secure coding practices, principles, standards, threat modelling, peer review, SAST and removal of defects that produce authorization failures, which directly prevents the code-level members of A01 (missing checks, IDOR, path traversal, insecure direct references); it does not prevent runtime bypasses such as CSRF or forced browsing that succeed despite correct code.
A04blocks — A.8.28 mandates secure coding practices, principles, standards, threat modelling, SAST and vetting of cryptographic components, which prevents many (but not all) absent/weak/misused cryptography defects from being introduced.
A06blocks — A.8.28 mandates secure design, threat modelling, secure architecture principles, least privilege evaluation and prohibition of insecure design techniques before and during coding, which directly blocks many design-level weaknesses from being baked in; it is only partial because the control is a broad governance-and-practice mandate whose actual coverage still depends on the rigour with which those principles are chosen and enforced, leaving a genuine slice of design flaws unaddressed.
A07blocks — A.8.28 mandates secure coding practices, principles, standards, threat modelling, SAST, and removal of defects that explicitly include weak authentication mechanisms, credential handling, session logic and related errors, which prevents many (but not all) members of the A07 class such as weak password storage, predictable tokens or missing MFA.

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.