A.8.29 Technological
Security testing in development and acceptance
AttributesPreventiveC·I·AIdentifyApplication securityInformation security assuranceSystem and network securityProtection
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 (18)
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).
Why these map — AI rationale (under review)
- SA-11mostlyaligns with — Both controls require systematic security testing and evaluation of systems during development and prior to acceptance to confirm that security functions and configurations meet requirements.
- SA-11mostlycovers — A.8.29's security testing in development and acceptance to validate requirements before production deployment accounts for the bulk of SA-11's developer testing/evaluation and evidence requirements across post-design SDLC stages, but leaves a residual of SA-11's ongoing control assessment plan and privacy-specific elements uncovered.
- SA-4mostlyaligns with — Both controls embed security requirements into the acquisition and development process and mandate verification that delivered products satisfy those requirements before acceptance.
- CA-2partialaligns with — Both controls use structured testing and assessment activities to verify that security controls are implemented correctly and operating as intended.
- CM-3partialaligns with — Both controls require that changes to systems undergo planned testing and evaluation before being accepted into the operational environment.
- SI-2partialaligns with — Both controls emphasize identifying and remediating security defects discovered through testing before systems are placed into production.
- 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).
Why these map — AI rationale (under review)
- ID.RA-01mostlyaligns with — Security testing activities such as vulnerability scanning and penetration testing systematically identify and record vulnerabilities in systems under development.
- PR.PS-06mostlyaligns with — The ISO control embeds security testing and defect remediation directly into the software development lifecycle, which is the core outcome sought by PR.PS-06.
- ID.IM-02partialaligns with — Security testing performed in coordination with development teams and suppliers generates findings that drive security improvements.
- ID.RA-09partialaligns with — Pre-acquisition evaluation of supplier products and components against security requirements mirrors the authenticity and integrity assessment required before use.
- PR.AA-01partialaligns with — Testing explicitly validates authentication and access-control functions, ensuring identities and credentials behave as intended.
- PR.PS-01partialaligns with — Secure-configuration testing verifies that operating systems, firewalls, and other components are hardened before deployment.
- ID.IM-02implements — A.8.29's security testing in dev/acceptance directly operationalizes the identification of improvements from security tests (including supplier-coordinated ones) that ID.IM-02 requires; the link is within the shared testing-and-exercise domain but not by explicit citation of improvement identification.
- 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.AA-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-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-06implements — A.8.29's security testing in dev/acceptance directly operationalizes the integration and monitoring of secure SDLC practices named in PR.PS-06; testing is a core means within that domain (though not the only one).
Related OWASP ASVS 5.0 requirements (13)
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).
Why these map — AI rationale (under review)
- V15.1.1mostlyaligns with — The ISO control's requirement for documented, risk-based remediation timelines for security defects directly supports the ASVS mandate that third-party component vulnerabilities be addressed within defined time frames.
- V15.2.1mostlyaligns with — Requiring that only components meeting documented remediation schedules are present in the application mirrors the ISO expectation that security defects identified during testing are remediated before acceptance.
- V1.2.4partialaligns with — Testing secure coding practices, including the use of parameterized queries, is one of the explicit security-testing objectives listed in the ISO guidance.
- V11.2.1partialaligns with — The ISO requirement to test the correct use of cryptography aligns with the ASVS requirement that validated cryptographic implementations are employed throughout the application.
- V13.4.2partialaligns with — Verifying that debug modes are disabled in production is a concrete outcome of the ISO control's secure-configuration testing activities.
- V16.3.4partialaligns with — The ISO control's emphasis on testing for security control failures is reflected in the ASVS requirement to log unexpected errors and security-control failures such as backend TLS failures.
- V6.2.1partialaligns with — Security testing of authentication functions, such as verifying minimum password length, is explicitly called out as a required element of the ISO control's security-function testing.
Related weaknesses / CWE (535)
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→MCWE-1007→PCWE-102→MCWE-1021→MCWE-1022→MCWE-1023→MCWE-1024→MCWE-1025→MCWE-1037→MCWE-1038→MCWE-1039→MCWE-1049→MCWE-1050→MCWE-1056→MCWE-1057→MCWE-1066→MCWE-1067→PCWE-1068→MCWE-1077→MCWE-1083→MCWE-1088→MCWE-1091→MCWE-11→MCWE-1102→MCWE-1103→PCWE-111→MCWE-1119→MCWE-112→MCWE-1124→PCWE-113→MCWE-114→MCWE-115→MCWE-116→MCWE-1164→PCWE-117→MCWE-1173→MCWE-1174→MCWE-118→MCWE-1189→MCWE-119→MCWE-1190→MCWE-1191→MCWE-12→MCWE-120→MCWE-1204→MCWE-121→MCWE-122→MCWE-1221→MCWE-1223→MCWE-1224→MCWE-123→MCWE-1231→MCWE-1233→MCWE-1234→MCWE-1236→MCWE-124→MCWE-1240→MCWE-1241→MCWE-1242→MCWE-1244→MCWE-1245→MCWE-1246→MCWE-1247→PCWE-125→MCWE-1253→MCWE-1254→MCWE-1255→MCWE-1256→MCWE-1257→MCWE-1258→MCWE-1259→MCWE-126→MCWE-1260→MCWE-1262→MCWE-1264→MCWE-1265→MCWE-1269→MCWE-127→MCWE-1270→MCWE-1275→MCWE-1278→PCWE-1279→MCWE-128→MCWE-1281→MCWE-1283→MCWE-1284→MCWE-1285→MCWE-1286→MCWE-1287→MCWE-1288→MCWE-1289→MCWE-129→MCWE-1291→PCWE-1295→MCWE-1298→MCWE-1299→MCWE-130→MCWE-1300→PCWE-1303→PCWE-131→MCWE-1312→MCWE-1313→MCWE-1316→MCWE-1319→MCWE-1320→MCWE-1321→MCWE-1322→MCWE-1325→MCWE-1332→PCWE-1333→MCWE-1335→MCWE-1336→MCWE-134→MCWE-1341→MCWE-1342→PCWE-135→MCWE-138→MCWE-1385→MCWE-1386→MCWE-1389→MCWE-1391→MCWE-14→MCWE-140→MCWE-141→MCWE-142→MCWE-143→MCWE-144→MCWE-145→MCWE-146→MCWE-147→MCWE-148→MCWE-149→MCWE-150→MCWE-153→MCWE-154→MCWE-155→MCWE-156→MCWE-157→MCWE-158→MCWE-159→MCWE-160→MCWE-162→MCWE-164→MCWE-166→MCWE-167→MCWE-168→MCWE-170→MCWE-172→MCWE-173→MCWE-176→MCWE-177→MCWE-179→MCWE-180→MCWE-182→MCWE-183→MCWE-184→MCWE-185→MCWE-186→MCWE-187→MCWE-188→MCWE-190→MCWE-191→MCWE-192→MCWE-193→MCWE-194→MCWE-195→MCWE-196→MCWE-197→MCWE-198→MCWE-20→MCWE-200→MCWE-202→PCWE-204→MCWE-205→MCWE-207→MCWE-209→MCWE-210→MCWE-215→MCWE-22→MCWE-226→MCWE-228→MCWE-229→MCWE-23→MCWE-230→MCWE-231→MCWE-232→MCWE-233→MCWE-234→MCWE-235→MCWE-236→MCWE-237→MCWE-239→MCWE-24→MCWE-240→MCWE-241→MCWE-242→MCWE-248→MCWE-25→MCWE-252→MCWE-253→MCWE-26→MCWE-27→MCWE-273→MCWE-277→MCWE-28→MCWE-280→MCWE-284→MCWE-288→MCWE-29→MCWE-290→MCWE-296→MCWE-297→MCWE-298→MCWE-299→MCWE-30→MCWE-301→MCWE-302→MCWE-303→MCWE-305→MCWE-31→MCWE-316→MCWE-318→MCWE-32→MCWE-322→MCWE-323→MCWE-325→MCWE-328→MCWE-329→MCWE-330→MCWE-331→MCWE-332→MCWE-333→MCWE-334→MCWE-335→MCWE-336→MCWE-337→MCWE-338→MCWE-339→MCWE-34→MCWE-340→MCWE-341→MCWE-342→MCWE-343→MCWE-345→MCWE-348→MCWE-349→MCWE-35→MCWE-351→MCWE-354→MCWE-356→MCWE-357→MCWE-358→MCWE-36→MCWE-362→MCWE-363→MCWE-364→MCWE-366→MCWE-368→MCWE-369→MCWE-37→MCWE-372→MCWE-377→MCWE-378→MCWE-38→MCWE-384→MCWE-385→PCWE-39→MCWE-390→MCWE-391→MCWE-392→MCWE-393→MCWE-394→MCWE-395→MCWE-396→MCWE-40→MCWE-401→MCWE-403→MCWE-407→MCWE-409→MCWE-41→MCWE-410→PCWE-413→MCWE-414→MCWE-415→MCWE-416→MCWE-42→MCWE-421→MCWE-422→MCWE-424→MCWE-425→MCWE-426→MCWE-427→MCWE-428→MCWE-43→MCWE-430→MCWE-431→MCWE-433→MCWE-434→MCWE-435→MCWE-436→MCWE-437→MCWE-44→MCWE-440→MCWE-444→MCWE-446→MCWE-447→MCWE-448→PCWE-449→MCWE-450→MCWE-451→MCWE-453→MCWE-454→MCWE-455→MCWE-456→MCWE-457→MCWE-46→MCWE-460→MCWE-462→MCWE-463→MCWE-466→MCWE-467→MCWE-468→MCWE-469→MCWE-470→MCWE-471→MCWE-472→MCWE-473→MCWE-474→MCWE-475→MCWE-476→MCWE-478→MCWE-479→MCWE-480→MCWE-482→MCWE-484→MCWE-488→MCWE-489→MCWE-491→MCWE-495→MCWE-499→MCWE-50→MCWE-502→MCWE-507→MCWE-511→MCWE-514→PCWE-515→MCWE-531→MCWE-535→MCWE-539→MCWE-541→MCWE-544→MCWE-548→MCWE-550→MCWE-551→MCWE-553→MCWE-561→MCWE-562→MCWE-564→MCWE-565→MCWE-566→MCWE-567→MCWE-57→MCWE-570→MCWE-571→MCWE-573→MCWE-587→MCWE-588→MCWE-59→MCWE-590→MCWE-591→MCWE-597→MCWE-598→MCWE-599→MCWE-6→MCWE-600→MCWE-602→MCWE-603→MCWE-606→MCWE-61→MCWE-610→MCWE-611→MCWE-615→MCWE-616→MCWE-617→MCWE-618→MCWE-62→MCWE-621→MCWE-622→MCWE-623→MCWE-624→MCWE-625→MCWE-626→MCWE-627→MCWE-628→MCWE-639→MCWE-64→MCWE-641→MCWE-643→MCWE-644→MCWE-646→MCWE-647→MCWE-648→MCWE-649→MCWE-65→MCWE-650→MCWE-652→MCWE-657→MCWE-66→MCWE-662→MCWE-663→MCWE-665→MCWE-667→MCWE-67→MCWE-670→MCWE-672→MCWE-674→MCWE-675→MCWE-676→MCWE-680→MCWE-681→MCWE-682→MCWE-683→MCWE-684→MCWE-686→MCWE-687→MCWE-688→MCWE-690→MCWE-691→MCWE-692→MCWE-694→MCWE-695→MCWE-696→MCWE-697→MCWE-698→MCWE-704→MCWE-705→MCWE-706→MCWE-707→MCWE-710→MCWE-73→MCWE-733→MCWE-74→MCWE-749→MCWE-75→MCWE-754→MCWE-755→MCWE-756→MCWE-757→MCWE-758→MCWE-759→MCWE-76→MCWE-760→MCWE-761→MCWE-762→MCWE-763→MCWE-764→MCWE-765→MCWE-767→MCWE-768→MCWE-77→MCWE-771→MCWE-774→MCWE-775→MCWE-776→MCWE-777→MCWE-78→MCWE-780→MCWE-782→MCWE-783→MCWE-784→MCWE-786→MCWE-787→MCWE-788→MCWE-789→MCWE-79→MCWE-790→MCWE-791→MCWE-792→MCWE-794→MCWE-80→MCWE-804→MCWE-805→MCWE-807→MCWE-81→MCWE-82→MCWE-820→MCWE-821→MCWE-822→MCWE-823→MCWE-824→MCWE-825→MCWE-826→MCWE-827→MCWE-828→MCWE-83→MCWE-830→MCWE-832→MCWE-833→MCWE-834→MCWE-835→MCWE-838→MCWE-839→MCWE-84→MCWE-841→MCWE-843→MCWE-85→MCWE-86→MCWE-87→MCWE-88→MCWE-89→MCWE-90→MCWE-908→MCWE-909→MCWE-91→MCWE-910→MCWE-911→MCWE-912→MCWE-913→MCWE-914→MCWE-915→MCWE-917→MCWE-925→MCWE-926→MCWE-927→MCWE-93→MCWE-939→MCWE-941→MCWE-942→MCWE-943→MCWE-95→MCWE-96→MCWE-97→MCWE-98→MCWE-99→M
Why these map — AI rationale (under review)
- CWE-656nonedetects — Security testing can expose mechanisms whose only protection is obscurity.
- CWE-1004finds — Security testing can detect missing HttpOnly flags but does not prevent the weakness.
- CWE-1007finds — Security testing can detect and require fixes for insufficient visual distinction of homoglyphs.
- CWE-102finds — Security testing in development can detect duplicate validation forms before release.
- CWE-1021finds — Security testing can detect missing frame protections, but does not itself implement the control.
- CWE-1022finds — Security testing can detect missing protections on external links through automated or manual checks.
- CWE-1023finds — Security testing can detect missing comparison factors, yet testing is only one part of the control's scope.
- CWE-1024finds — Security testing in development can detect type-mismatch defects through static analysis and unit tests.
- CWE-1025finds — Security testing can detect incorrect comparison results during development and acceptance.
- CWE-1037finds — Security testing in development can detect when optimizations have removed intended protections.
- CWE-1038finds — Security testing in development and acceptance can detect unintended side-effects introduced by automated optimizations.
- CWE-1039finds — Security testing in development can explicitly cover adversarial input testing for recognition mechanisms.
- CWE-1049finds — Security testing in development can detect performance issues caused by excessive query operations.
- CWE-1050finds — Security testing can discover the defect but does not remove it from production code.
- CWE-1056finds — Security testing can detect misuse of variadic functions but does not prevent their introduction.
- CWE-1057finds — Security testing can detect unauthorized data-access paths bypassing the central manager.
- CWE-1066finds — Security testing can detect missing serialization methods before production deployment.
- CWE-1067finds — Security testing can detect slow sequential scans and missing indexes during acceptance.
- CWE-1068finds — Security testing can detect deviations, yet does not prevent the inconsistency from occurring.
- CWE-1077finds — Security testing can detect floating-point comparison defects but does not prevent them by itself.
- CWE-1083finds — Security testing can detect unauthorized direct access paths, but does not itself prevent their introduction.
- CWE-1088finds — Security testing can detect missing timeouts, providing partial coverage of both the weakness and the control.
- CWE-1091finds — Security testing can detect missing destructor calls through static analysis or resource-leak testing.
- CWE-11finds — Security testing in development and acceptance can detect debug binaries but does not prevent their creation or deployment.
- CWE-1102finds — Security testing can detect platform-specific representation issues but does not itself prevent their introduction.
- CWE-1103finds — Security testing in development can include cross-platform compatibility and functionality equivalence tests.
- CWE-111finds — Security testing can detect unsafe JNI usage through static analysis and fuzzing of native boundaries.
- CWE-1119finds — Security testing can detect overly complex or unstructured code, yet the control focuses on testing rather than coding rules.
- CWE-112finds — Security testing in development can detect missing XML validation but does not itself implement the control.
- CWE-1124finds — Security testing can detect overly complex code but does not itself prevent the weakness.
- CWE-113finds — Security testing in development and acceptance can detect CRLF injection flaws before deployment.
- CWE-114finds — Security testing can detect unsafe process or library loading but does not prevent it by itself.
- CWE-115finds — Security testing can detect input misinterpretation flaws but does not itself implement the preventive controls.
- CWE-116finds — Security testing can detect missing or incorrect encoding but does not itself implement the control.
- CWE-1164finds — Security testing can detect dead code but does not directly prevent its introduction.
- CWE-117finds — Security testing can detect log injection flaws but does not prevent them at the source.
- CWE-1173finds — Security testing can detect missing validation but does not enforce framework adoption.
- CWE-1174finds — Security testing in development and acceptance will detect missing model validation.
- CWE-118finds — Security testing can detect range errors through fuzzing and boundary-value analysis.
- CWE-1189finds — Security testing can detect SoC isolation issues but does not prevent the weakness from existing in the design.
- CWE-119finds — Security testing in development catches out-of-bounds accesses before release, covering most instances of the weakness.
- CWE-1190finds — Security testing can detect DMA enablement before security configuration is complete.
- CWE-1191finds — Security testing can discover improper debug access but does not itself implement the control.
- CWE-12finds — Security testing can detect missing custom error pages during acceptance testing.
- CWE-120finds — Security testing in development and acceptance can detect buffer overflows through fuzzing and static analysis, though it does not prevent them at the source.
- CWE-1204finds — Security testing in development can detect use of static or predictable IVs before release.
- CWE-121finds — Security testing (fuzzing, static analysis) detects stack overflows before release.
- CWE-122finds — Security testing in development and acceptance can detect heap overflows before release.
- CWE-1221finds — Security testing in development can detect incorrect register defaults before deployment.
- CWE-1223finds — Security testing in development can include hardware simulation and formal verification to catch write-once register race conditions.
- CWE-1224finds — Security testing in development can detect reprogrammable sticky bits before tape-out.
- CWE-123finds — Security testing in development and acceptance can detect write-what-where conditions before deployment.
- CWE-1231finds — Security testing can detect lock-bit modification flaws, but does not inherently prevent the weakness in production hardware.
- CWE-1233finds — Security testing can detect missing lock-bit protection during hardware/firmware validation.
- CWE-1234finds — Security testing may detect debug-mode bypasses but does not prevent the underlying hardware weakness.
- CWE-1236finds — Security testing in development can detect formula injection but does not itself implement the mitigation.
- CWE-124finds — Security testing in development catches buffer-underflow defects before release.
- CWE-1240finds — Security testing can detect use of weak or non-compliant cryptographic primitives before deployment.
- CWE-1241finds — Security testing can detect predictable RNG behavior before deployment.
- CWE-1242finds — Security testing in development and acceptance can uncover undocumented functionality before release.
- CWE-1244finds — Security testing can detect unsafe debug states, but testing alone does not prevent the design flaw.
- CWE-1245finds — Security testing in development can discover undefined FSM states before deployment.
- CWE-1246finds — Security testing can detect missing wear-leveling but does not itself implement the mitigation.
- CWE-1247finds — Security testing in development can discover and validate protections against voltage and clock glitch attacks.
- CWE-125finds — Security testing in development and acceptance includes fuzzing and static analysis that detect out-of-bounds read defects before release.
- CWE-1253finds — Security testing can detect incorrect fuse selection before release but does not prevent the weakness in production hardware.
- CWE-1254finds — Security testing can detect timing side-channels arising from stepwise comparison logic.
- CWE-1255finds — Security testing in development can include side-channel analysis to detect and remediate power-leakage vulnerabilities.
- CWE-1256finds — Security testing in development can detect and remediate improper hardware interface exposure before deployment.
- CWE-1257finds — Security testing in development can detect inconsistent access controls on aliased memory.
- CWE-1258finds — Security testing in development can detect uncleared debug information before release.
- CWE-1259finds — Security testing can detect improper token assignment but does not prevent it at design time.
- CWE-126finds — Security testing in development can detect buffer over-reads before release.
- CWE-1260finds — Security testing in development and acceptance can detect overlap issues but does not itself prevent them.
- CWE-1262finds — Security testing can discover improper register access but does not prevent it at runtime.
- CWE-1264finds — Security testing in development can detect de-synchronization flaws between control and data paths before deployment.
- CWE-1265finds — Security testing in development can detect reentrancy vulnerabilities through stress, concurrency, and fuzz testing.
- CWE-1269finds — Security testing and acceptance criteria can detect and block deployment of pre-production builds.
- CWE-127finds — Security testing can detect buffer under-reads before release.
- CWE-1270finds — Security testing in development can detect incorrect token generation before deployment.
- CWE-1275finds — Security testing can detect missing SameSite attributes but does not prevent the weakness.
- CWE-1278finds — Security testing can verify the presence of hardware protections against imaging attacks.
- CWE-1279finds — Security testing in development can detect cases where crypto runs before inputs are valid.
- CWE-128finds — Security testing can detect wrap-around errors through boundary and fuzz testing.
- CWE-1281finds — Security testing in development can detect and block instruction sequences that lead to processor lock-ups before deployment.
- CWE-1283finds — Security testing can detect weaknesses that permit mutable attestation data.
- CWE-1284finds — Security testing in development can detect missing quantity validation but does not itself implement the control.
- CWE-1285finds — Security testing can detect missing or incorrect index validation during development and acceptance.
- CWE-1286finds — Security testing in development catches missing or incorrect syntax validation.
- CWE-1287finds — Security testing can detect type-validation flaws but does not prevent them during development.
- CWE-1288finds — Security testing can detect consistency flaws but does not prevent them at design time.
- CWE-1289finds — Security testing can detect unsafe equivalence flaws but does not prevent them at design time.
- CWE-129finds — Security testing in development can detect out-of-bounds array access but does not prevent the weakness by itself.
- CWE-1291finds — Security testing and acceptance criteria can verify that production code is signed with a dedicated key not used for debug builds.
- CWE-1295finds — Security testing can detect excessive debug information, but does not guarantee its prevention in production.
- CWE-1298finds — Security testing in development can include hardware timing and race-condition verification.
- CWE-1299finds — Security testing can discover alternate-path weaknesses but does not inherently prevent them.
- CWE-130finds — Security testing in development can detect length-inconsistency vulnerabilities before deployment.
- CWE-1300finds — Security testing can include side-channel analysis to verify protections.
- CWE-1303finds — Security testing can detect side-channel leakage but does not prevent the underlying microarchitectural sharing.
- CWE-131finds — Security testing can detect buffer-size errors before release.
- CWE-1312finds — Security testing can discover mirror-region bypasses, but does not inherently prevent the design omission.
- CWE-1313finds — Security testing in development and acceptance includes verification that debug interfaces are disabled or protected before release.
- CWE-1316finds — Security testing in development can detect address-map overlaps but does not guarantee their prevention at design time.
- CWE-1319finds — Security testing in development can discover EM-FI susceptibility, but does not inherently prevent the weakness in production.
- CWE-1320finds — Security testing can verify that alerts and signals cannot be disabled by untrusted agents.
- CWE-1321finds — Security testing in development catches prototype-pollution flaws before release.
- CWE-1322finds — Security testing can detect blocking behavior but does not prevent the weakness by itself.
- CWE-1325finds — Security testing can detect unbounded allocation patterns, but removing the weakness does not fulfill testing obligations.
- CWE-1332finds — Security testing in development can discover instruction-skip faults, yet testing alone does not guarantee hardware-level mitigation.
- CWE-1333finds — Security testing can detect and reject regex patterns with exponential worst-case complexity.
- CWE-1335finds — Security testing in development can detect shift-related defects before release.
- CWE-1336finds — Security testing can detect template-injection flaws but does not itself implement neutralization controls.
- CWE-134finds — Security testing in development can detect format-string vulnerabilities before release.
- CWE-1341finds — Security testing in development can detect double-release defects before release.
- CWE-1342finds — Security testing can include side-channel and transient-execution test suites during acceptance.
- CWE-135finds — Security testing in development and acceptance can detect incorrect multi-byte string length calculations through targeted test cases.
- CWE-138finds — Security testing can detect instances of CWE-138 but does not itself implement the neutralization controls.
- CWE-1385finds — Security testing can detect missing origin validation in WebSocket implementations.
- CWE-1386finds — Security testing can detect junction/mount-point weaknesses before release.
- CWE-1389finds — Security testing can detect radix-related parsing flaws but does not prevent them by itself.
- CWE-1391finds — Security testing can discover weak credentials, but does not guarantee they are prevented by design.
- CWE-14finds — Security testing can detect residual sensitive data left by dead-store removal, but does not prevent the weakness itself.
- CWE-140finds — Security testing in development and acceptance can detect delimiter-related weaknesses before deployment.
- CWE-141finds — Security testing can detect delimiter issues but does not itself implement the neutralization.
- CWE-142finds — Security testing in development and acceptance can detect delimiter-handling defects before release.
- CWE-143finds — Security testing can detect delimiter issues but does not itself implement the fix.
- CWE-144finds — Security testing can detect the weakness but does not itself implement the neutralization.
- CWE-145finds — Security testing in development and acceptance can detect delimiter-neutralization flaws before release.
- CWE-146finds — Security testing can detect the weakness but does not prevent it by itself.
- CWE-147finds — Security testing can detect terminator issues but does not itself implement the neutralization control.
- CWE-148finds — Security testing can detect missing or malformed leaders, providing partial mitigation.
- CWE-149finds — Security testing can detect quote-injection but does not itself implement the fix.
- CWE-150finds — Security testing can detect the weakness but does not itself implement neutralization.
- CWE-153finds — Security testing can detect substitution-character flaws but does not itself implement neutralization.
- CWE-154finds — Security testing can discover delimiter-injection flaws but does not itself implement the neutralization fix.
- CWE-155finds — Security testing can detect wildcard issues but does not itself implement neutralization controls.
- CWE-156finds — Security testing can detect whitespace handling issues but does not prevent them at the source.
- CWE-157finds — Security testing in development can detect delimiter-handling weaknesses before release.
- CWE-158finds — Security testing can detect null-byte flaws but does not itself implement the neutralization.
- CWE-159finds — Security testing can discover the weakness but does not itself implement the preventive control.
- CWE-160finds — Security testing can detect the weakness but does not itself implement neutralization controls.
- CWE-162finds — Security testing can detect the weakness but does not itself implement neutralization controls.
- CWE-164finds — Security testing in development and acceptance can detect the weakness but does not prevent it at design or coding time.
- CWE-166finds — Security testing can discover missing-element flaws but does not prevent them by itself.
- CWE-167finds — Security testing in development catches improper handling of unexpected special elements before release.
- CWE-168finds — Security testing can detect inconsistent-element flaws but does not prevent them by itself.
- CWE-170finds — Security testing in development can detect missing or incorrect null terminators before release.
- CWE-172finds — Security testing in development can detect encoding flaws before deployment.
- CWE-173finds — Security testing can detect encoding-handling defects but does not itself implement the preventive coding controls.
- CWE-176finds — Security testing can detect Unicode-handling flaws before deployment.
- CWE-177finds — Security testing in development catches URL-decoding flaws before release, but does not itself define coding rules.
- CWE-179finds — Security testing can detect early-validation flaws but does not inherently prevent them in design.
- CWE-180finds — Security testing can detect validation-order defects before deployment.
- CWE-182finds — Security testing can detect collapse issues but does not prevent them by itself.
- CWE-183finds — Security testing can detect overly broad allow-lists, but does not inherently prevent their creation.
- CWE-184finds — Security testing can discover missing input checks, but does not prevent the weakness during development.
- CWE-185finds — Security testing in development can detect regex-related flaws before release.
- CWE-186finds — Security testing in development can detect overly restrictive regex through negative-test cases.
- CWE-187finds — Security testing can detect and prevent partial string comparison flaws before deployment.
- CWE-188finds — Security testing in development can detect layout-related defects before release.
- CWE-190finds — Security testing in development can detect integer overflows before release.
- CWE-191finds — Security testing in development catches integer underflow defects before release.
- CWE-192finds — Security testing in development can detect integer coercion flaws via fuzzing and static analysis.
- CWE-193finds — Security testing in development and acceptance can detect off-by-one errors before release.
- CWE-194finds — Security testing in development can detect unexpected sign-extension behavior through targeted test cases.
- CWE-195finds — Security testing in development can detect conversion-related defects before release.
- CWE-196finds — Security testing can detect integer conversion errors through static analysis and fuzzing.
- CWE-197finds — Security testing can detect truncation bugs through static analysis and fuzzing.
- CWE-198finds — Security testing can detect byte-order defects before acceptance.
- CWE-20finds — Testing against a defined set of requirements and using code review plus vulnerability scanning forces validation of inputs and handling of unanticipated conditions, reducing the chance that malformed data will be accepted.
- CWE-200finds — Penetration testing and vulnerability scanning are performed to discover unintended exposure of sensitive data resulting from misconfigurations or coding errors.
- CWE-202finds — Security testing can validate that inference attacks are mitigated in data-query functionality.
- CWE-204finds — Security testing can detect observable response discrepancies before deployment.
- CWE-205finds — Security testing can detect and require remediation of observable behavioral differences before release.
- CWE-207finds — Security testing can detect and eliminate observable behavioral discrepancies before deployment.
- CWE-209finds — Security testing can detect error messages that leak sensitive information.
- CWE-210finds — Security testing can detect the weakness but does not prevent it by itself.
- CWE-215finds — Security testing in development catches debug statements and sensitive data leaks.
- CWE-22finds — Security testing in development catches path traversal via static/dynamic analysis.
- CWE-226finds — Security testing can detect failures to sanitize resources before reuse.
- CWE-228finds — Security testing can detect malformed-input issues but does not itself implement the handling logic.
- CWE-229finds — Security testing can detect missing-value flaws but does not itself implement the handling logic.
- CWE-23finds — Security testing in development catches path traversal via static/dynamic analysis, but does not itself implement the fix.
- CWE-230finds — Security testing can detect missing-value flaws but does not itself prevent them.
- CWE-231finds — Security testing can detect extra-value handling issues but does not prevent them by itself.
- CWE-232finds — Security testing in development can detect missing handling of undefined values before release.
- CWE-233finds — Security testing can detect missing-parameter issues but does not prevent them at design time.
- CWE-234finds — Security testing in development and acceptance can detect missing-parameter conditions through negative and boundary testing.
- CWE-235finds — Security testing can detect extra-parameter handling flaws but does not itself implement the fix.
- CWE-236finds — Security testing can detect undefined-parameter handling flaws but does not prevent them at the source.
- CWE-237finds — Security testing in development can detect weaknesses related to improper handling of complex structures.
- CWE-239finds — Security testing can detect incomplete-element handling but does not itself prevent the weakness in production code.
- CWE-24finds — Security testing in development catches path-traversal flaws before release.
- CWE-240finds — Security testing in development and acceptance can detect inconsistent structural handling before release.
- CWE-241finds — Security testing can detect type-handling flaws but does not itself implement the preventive control.
- CWE-242finds — Security testing can surface calls to unsafe functions but does not prevent their introduction.
- CWE-248finds — Security testing can detect uncaught exceptions before production deployment.
- CWE-25finds — Security testing in development catches path-traversal flaws before production deployment.
- CWE-252finds — Security testing in development and acceptance can detect missing return-value checks.
- CWE-253finds — Security testing in development catches missing or incorrect return-value checks.
- CWE-26finds — Security testing in development catches path traversal via static/dynamic analysis and penetration testing.
- CWE-27finds — Security testing in development catches path-traversal flaws before release but does not itself implement the control.
- CWE-273finds — Security testing can detect failed privilege drops, yet the control does not require such checks as part of its core intent.
- CWE-277finds — Security testing may detect permission issues but does not prevent insecure inheritance by design.
- CWE-28finds — Security testing in development catches path-traversal flaws before release.
- CWE-280finds — Security testing can detect missing or incorrect privilege handling.
- CWE-284finds — Security testing explicitly validates authentication, access restriction, and cryptography functions, directly catching missing or incorrect access control checks before code reaches production.
- CWE-288finds — Security testing can detect alternate-path bypasses but does not prevent them in production.
- CWE-29finds — Security testing can discover path-traversal flaws but does not itself prevent them in production code.
- CWE-290finds — Security testing can detect spoofing vulnerabilities but does not prevent them by itself.
- CWE-296finds — Security testing can detect missing or incorrect certificate chain validation.
- CWE-297finds — Security testing can detect missing certificate validation and host-mismatch checks.
- CWE-298finds — Security testing can detect missing certificate expiration checks but does not constitute the control's full intent.
- CWE-299finds — Security testing can detect missing or incorrect certificate revocation checks.
- CWE-30finds — Security testing in development and acceptance will detect path-traversal flaws before release.
- CWE-301finds — Security testing can detect reflection vulnerabilities, providing partial coverage through verification rather than prevention.
- CWE-302finds — Security testing can discover and block authentication bypasses that rely on mutable data.
- CWE-303finds — Security testing can detect flawed authentication implementations but does not prevent them by itself.
- CWE-305finds — Security testing can detect authentication bypass conditions before deployment.
- CWE-31finds — Security testing can discover traversal flaws but does not prevent them at the source.
- CWE-316finds — Security testing can detect cleartext secrets in memory dumps or debug output.
- CWE-318finds — Security testing may detect the issue but does not prevent it at the source.
- CWE-32finds — Security testing in development catches path-traversal flaws before release, providing strong but post-coding coverage.
- CWE-322finds — Security testing can detect missing entity authentication during key exchange.
- CWE-323finds — Security testing can detect nonce reuse, yet the control addresses many other issues beyond this CWE.
- CWE-325finds — Security testing can detect incomplete crypto implementations but does not itself enforce correct algorithm steps.
- CWE-328finds — Security testing can detect weak-hash usage but does not prescribe algorithm choice.
- CWE-329finds — Security testing in development can detect predictable IV usage before deployment.
- CWE-330finds — Security testing can detect weak randomness but does not prescribe the control itself.
- CWE-331finds — Security testing can detect insufficient-entropy defects before release.
- CWE-332finds — Security testing can detect insufficient entropy in PRNG implementations before deployment.
- CWE-333finds — Security testing can detect insufficient entropy in TRNG implementations before deployment.
- CWE-334finds — Security testing can detect insufficient randomness in tokens, session IDs, or keys.
- CWE-335finds — Security testing can detect weak seeding but does not itself prevent the weakness.
- CWE-336finds — Security testing can detect predictable PRNG output, but testing alone does not prevent the flaw.
- CWE-337finds — Security testing can detect and prevent use of weak or predictable PRNG seeds.
- CWE-338finds — Security testing can detect use of weak random number generators.
- CWE-339finds — Security testing can detect weak PRNG seeding but does not prevent it by itself.
- CWE-34finds — Security testing in development and acceptance catches path traversal via dynamic and static analysis.
- CWE-340finds — Security testing in development can detect predictable identifiers through static/dynamic analysis and fuzzing, reducing residual risk.
- CWE-341finds — Security testing can detect predictability issues but does not prevent them by itself.
- CWE-342finds — Security testing can detect predictable random sequences before release.
- CWE-343finds — Security testing can detect and reject predictable random-value generators.
- CWE-345finds — Security testing can detect missing or weak data authenticity verification.
- CWE-348finds — Security testing can detect and prevent acceptance of data from less-trusted sources during development.
- CWE-349finds — Security testing can detect the weakness but does not itself implement preventive controls.
- CWE-35finds — Security testing in development can detect path-traversal flaws before release.
- CWE-351finds — Security testing can detect type confusion vulnerabilities before deployment.
- CWE-354finds — Security testing can detect missing integrity validation but does not itself implement the control.
- CWE-356finds — Security testing can verify presence of warnings for unsafe user actions.
- CWE-357finds — Security testing in development and acceptance validates that dangerous-operation warnings are sufficiently prominent.
- CWE-358finds — Security testing in development and acceptance validates that required security checks function as specified.
- CWE-36finds — Security testing in development can detect absolute path traversal via static analysis and fuzzing.
- CWE-362finds — Security testing can detect race conditions, but does not prevent them at design or coding time.
- CWE-363finds — Security testing can detect link-following races, but testing alone does not prevent the weakness.
- CWE-364finds — Security testing can detect signal-handler race conditions before release.
- CWE-366finds — Security testing can detect race conditions through concurrency and stress testing.
- CWE-368finds — Security testing can detect race conditions during context switching across privilege boundaries.
- CWE-369finds — Security testing in development can detect divide-by-zero conditions before release.
- CWE-37finds — Security testing can discover path-traversal flaws but does not prevent them at runtime.
- CWE-372finds — Security testing can detect state-machine flaws that manifest as incomplete internal state distinction.
- CWE-377finds — Security testing can detect insecure temporary files but does not prevent their creation.
- CWE-378finds — Security testing can detect insecure temporary files but does not prevent their creation.
- CWE-38finds — Security testing in development can discover path-traversal flaws before deployment.
- CWE-384finds — Security testing can detect session-fixation issues, yet the weakness absence does not replace comprehensive testing.
- CWE-385finds — Security testing can uncover timing vulnerabilities but does not prevent their introduction.
- CWE-39finds — Security testing can discover drive-letter traversal but does not prevent it at runtime.
- CWE-390finds — Security testing can uncover missing error handling, but does not ensure the weakness is eliminated in production code.
- CWE-391finds — Security testing can detect missing error handling before deployment.
- CWE-392finds — Security testing can identify missing error reporting through negative test cases and exception handling checks.
- CWE-393finds — Security testing in development can detect functions returning wrong status codes.
- CWE-394finds — Security testing can detect missing checks for unexpected but valid return values.
- CWE-395finds — Security testing can detect improper exception handling but does not prevent the coding practice itself.
- CWE-396finds — Security testing in development can detect generic catch blocks, but does not guarantee their removal.
- CWE-40finds — Security testing can discover and verify the absence of UNC-based path traversal vulnerabilities.
- CWE-401finds — Security testing in development can detect unreleased memory, providing partial coverage of the weakness.
- CWE-403finds — Security testing can uncover descriptor leaks but does not prevent them by itself.
- CWE-407finds — Security testing can uncover performance issues stemming from algorithmic complexity.
- CWE-409finds — Security testing can uncover decompression-bomb vulnerabilities before release.
- CWE-41finds — Security testing can detect path-equivalence flaws before release, partially fulfilling the control.
- CWE-410finds — Security testing can detect insufficient resource pools before deployment.
- CWE-413finds — Security testing can detect locking defects but does not itself implement locking controls.
- CWE-414finds — Security testing can detect race conditions caused by missing locks but does not prevent them by itself.
- CWE-415finds — Security testing in development can detect double-free conditions before release.
- CWE-416finds — Security testing in development can detect use-after-free bugs before release.
- CWE-42finds — Security testing can detect path-equivalence flaws before release.
- CWE-421finds — Security testing can detect alternate-channel race conditions before deployment.
- CWE-422finds — Security testing can discover shatter vulnerabilities but does not itself implement the control's broader acceptance criteria.
- CWE-424finds — Security testing can discover unprotected alternate paths before release.
- CWE-425finds — Security testing can detect forced-browsing flaws, but the control itself does not prevent them in production.
- CWE-426finds — Security testing can discover search-path issues but does not itself prevent them in production code.
- CWE-427finds — Security testing can detect uncontrolled search-path issues but does not prevent them by itself.
- CWE-428finds — Security testing in development can detect unquoted search-path issues before deployment.
- CWE-43finds — Security testing can detect path-equivalence flaws before deployment.
- CWE-430finds — Security testing can detect incorrect handler assignments before deployment.
- CWE-431finds — Security testing in development and acceptance can detect missing handlers through negative and exception test cases.
- CWE-433finds — Security testing can detect the weakness but does not itself implement the preventive control.
- CWE-434finds — Configuration and acceptance testing verify that file-upload handling enforces allowed types and does not permit dangerous content to be stored or executed.
- CWE-435finds — Security testing during integration and acceptance can reveal interaction-induced weaknesses.
- CWE-436finds — Security testing can detect and correct cases where one component misinterprets another’s state or messages.
- CWE-437finds — Security testing can validate that the intermediary correctly handles all documented and undocumented endpoint features.
- CWE-44finds — Security testing can discover path-equivalence flaws but does not itself prevent them in production.
- CWE-440finds — Security testing in development and acceptance validates that functions behave as specified.
- CWE-444finds — Security testing can detect HTTP request smuggling vulnerabilities in intermediary components.
- CWE-446finds — Security testing in development and acceptance can detect UI discrepancies before release, providing strong mitigation for this weakness.
- CWE-447finds — Security testing in development and acceptance would detect unimplemented security features before release.
- CWE-448finds — Security testing can detect and flag obsolete UI features that lack appropriate warnings.
- CWE-449finds — Security testing in development and acceptance validates that UI actions match user intent and requirements.
- CWE-450finds — Security testing can detect and require fixes for multiple-interpretation UI input flaws.
- CWE-451finds — Security testing can detect UI misrepresentation vulnerabilities before deployment.
- CWE-453finds — Security testing can detect insecure defaults but does not prevent them.
- CWE-454finds — Security testing can detect the weakness but does not prevent it at design time.
- CWE-455finds — Security testing in development can detect missing exit-on-failure behavior during initialization.
- CWE-456finds — Security testing in development and acceptance can detect uninitialized-variable conditions through static and dynamic analysis.
- CWE-457finds — Security testing can detect uninitialized-variable bugs, but the control is broader.
- CWE-46finds — Security testing in development can detect path-equivalence flaws before deployment.
- CWE-460finds — Security testing can detect missing cleanup paths, thereby mitigating the weakness before deployment.
- CWE-462finds — Security testing can detect duplicate-key conditions before release.
- CWE-463finds — Security testing can detect sentinel deletion bugs before release.
- CWE-466finds — Security testing in development can detect out-of-range pointer returns through static analysis and fuzzing.
- CWE-467finds — Security testing can detect sizeof(pointer) errors but does not prevent them at source.
- CWE-468finds — Security testing can discover pointer-scaling defects, yet eliminating the weakness itself does not satisfy the control's wider testing mandate.
- CWE-469finds — Security testing in development can detect pointer-subtraction flaws through static analysis and fuzzing.
- CWE-470finds — Security testing can detect and block unsafe reflection patterns before release.
- CWE-471finds — Security testing can detect unauthorized modification paths for assumed-immutable data.
- CWE-472finds — Security testing in development and acceptance will detect parameter tampering vulnerabilities before deployment.
- CWE-473finds — Security testing can detect variable-injection flaws but does not itself implement the preventive controls.
- CWE-474finds — Security testing can surface cross-platform inconsistencies but does not prevent their introduction in code.
- CWE-475finds — Security testing can detect undefined behavior from invalid API inputs before deployment.
- CWE-476finds — Security testing can detect NULL dereference defects before release.
- CWE-478finds — Security testing can detect missing default cases but does not guarantee their prevention.
- CWE-479finds — Security testing can detect unsafe signal-handler patterns before release.
- CWE-480finds — Security testing and code review can catch operator errors before release.
- CWE-482finds — Security testing can detect the flaw but does not prevent it at source.
- CWE-484finds — Security testing in development can detect unintended fall-through behavior, though it is not the primary control.
- CWE-488finds — Security testing can detect the weakness but does not itself implement the preventive control.
- CWE-489finds — Security testing in development and acceptance catches active debug code before deployment.
- CWE-491finds — Security testing can detect clone-related state corruption during acceptance testing.
- CWE-495finds — Security testing can detect the weakness but does not itself prevent it at design time.
- CWE-499finds — Security testing can detect serializable sensitive classes and verify they are properly protected.
- CWE-50finds — Security testing in development can detect path-equivalence flaws before deployment.
- CWE-502finds — Security testing includes validation of deserialization routines and the use of untrusted data, reducing the likelihood that unsafe object reconstruction will be deployed.
- CWE-507finds — Security testing in development and acceptance can uncover hidden malicious behavior.
- CWE-511finds — Security testing in development and acceptance can uncover hidden logic/time bombs before release.
- CWE-514finds — Security testing can discover covert channels, yet the control does not mandate such specialized testing.
- CWE-515finds — Security testing may discover covert storage channels but does not ensure they are absent.
- CWE-531finds — Security testing in development and acceptance can detect sensitive data left in test code.
- CWE-535finds — Security testing can detect exposed error messages but does not prevent them by itself.
- CWE-539finds — Security testing can detect and prevent use of persistent cookies with sensitive data.
- CWE-541finds — Security testing can detect credentials in include files before deployment.
- CWE-544finds — Security testing can detect inconsistent error handling but does not itself define the standardized mechanism.
- CWE-548finds — Security testing in development and acceptance can detect and require remediation of exposed directory listings.
- CWE-550finds — Security testing can detect and require remediation of verbose error messages.
- CWE-551finds — Security testing can detect this weakness but does not prevent it by itself.
- CWE-553finds — Security testing can discover such files but does not prevent their introduction during development.
- CWE-561finds — Security testing can surface dead code but does not directly prevent or eliminate it.
- CWE-562finds — Security testing in development can detect use-after-return bugs before release.
- CWE-564finds — Security testing can detect injection flaws but does not prevent them at design time.
- CWE-565finds — Security testing can detect cookie-validation flaws but does not itself implement the required controls.
- CWE-566finds — Security testing in development can detect missing authorization checks and unsafe SQL construction before release.
- CWE-567finds — Security testing can detect race conditions but does not itself prevent the weakness.
- CWE-57finds — Requires security testing that can detect path-traversal weaknesses before release.
- CWE-570finds — Security testing in development and acceptance can surface dead-code paths caused by always-false expressions.
- CWE-571finds — Security testing in development can surface constant-true conditions through automated checks.
- CWE-573finds — Security testing can detect specification non-compliance but does not itself prevent the weakness.
- CWE-587finds — Security testing can detect fixed-address pointer assignments but does not prevent them.
- CWE-588finds — Security testing can detect memory corruption caused by invalid pointer casts.
- CWE-59finds — Security testing can detect link-following flaws before release.
- CWE-590finds — Security testing in development can detect invalid-free defects before release.
- CWE-591finds — Security testing can discover unlocked sensitive buffers, but does not itself implement the locking mechanism.
- CWE-597finds — Security testing can detect the flaw but does not prevent its introduction.
- CWE-598finds — Security testing can detect sensitive data leakage via query strings.
- CWE-599finds — Security testing could detect missing certificate validation but does not prevent the weakness at development time.
- CWE-6finds — Security testing can detect and reject applications with insufficient session-ID length.
- CWE-600finds — Security testing in development can detect uncaught exceptions and verify proper error handling before release.
- CWE-602finds — Security testing can detect client-side enforcement but is not the primary mitigation.
- CWE-603finds — Security testing can detect missing server-side authentication checks.
- CWE-606finds — Security testing in development can detect and block unchecked loop conditions before release.
- CWE-61finds — Security testing can detect symlink-following vulnerabilities before deployment, covering most of the weakness.
- CWE-610finds — Security testing can detect instances of the weakness but does not prevent it at design or coding time.
- CWE-611finds — Security testing in development catches XXE via static analysis and dynamic XML fuzzing.
- CWE-615finds — Security testing may incidentally discover sensitive comments, but that is not the control’s primary intent.
- CWE-616finds — Security testing in development can detect the legacy upload pattern before deployment.
- CWE-617finds — Security testing in development can detect reachable assertions before release, reducing the likelihood of exploitation.
- CWE-618finds — Security testing can detect unsafe methods but does not itself prevent their introduction.
- CWE-62finds — Security testing can discover hard-link issues but does not itself prevent them in production.
- CWE-621finds — Security testing can detect variable extraction flaws before deployment.
- CWE-622finds — Security testing in development and acceptance would detect missing validation of hook arguments through fuzzing or negative testing.
- CWE-623finds — Security testing can detect unsafe ActiveX controls, but testing alone does not eliminate the root cause.
- CWE-624finds — Security testing can detect executable regex flaws before production deployment.
- CWE-625finds — Security testing can detect permissive regex through fuzzing or negative test cases.
- CWE-626finds — Security testing can detect null-byte injection flaws before release.
- CWE-627finds — Security testing can detect dynamic evaluation flaws but does not prevent them by itself.
- CWE-628finds — Security testing in development can detect argument-related defects before release.
- CWE-639finds — Security testing can detect missing authorization checks but does not prevent the weakness in production.
- CWE-64finds — Security testing can uncover shortcut-following flaws but does not itself eliminate the weakness in production code.
- CWE-641finds — Security testing can detect improper filename handling but does not itself prevent the weakness.
- CWE-643finds — Security testing in development catches XPath injection vulnerabilities before release.
- CWE-644finds — Security testing catches header-injection issues before release, covering most of the weakness.
- CWE-646finds — Security testing can detect the weakness, but the control does not guarantee its elimination.
- CWE-647finds — Security testing can discover non-canonical URL bypasses but does not itself implement the preventive control.
- CWE-648finds — Security testing can detect incorrect privileged API calls but does not prevent them at design time.
- CWE-649finds — Security testing can detect missing integrity checks on encrypted or obfuscated security inputs.
- CWE-65finds — Security testing can detect and block scenarios where applications follow malicious hard links.
- CWE-650finds — Security testing can detect and prevent vulnerabilities where GET requests cause unintended state changes.
- CWE-652finds — Security testing in development catches XQuery injection vulnerabilities before deployment.
- CWE-657finds — Security testing can detect violations of secure design principles before release.
- CWE-66finds — Security testing in development can detect path-traversal or virtual-resource handling flaws before deployment.
- CWE-662finds — Security testing can detect synchronization flaws but does not itself implement the required controls.
- CWE-663finds — Security testing can detect race conditions and re-entrancy issues but does not itself prevent the weakness.
- CWE-665finds — Security testing can detect uninitialized variables but does not itself enforce initialization practices.
- CWE-667finds — Security testing can detect race conditions and locking errors before release.
- CWE-67finds — Security testing in development can detect and prevent device-name pathname vulnerabilities.
- CWE-670finds — Security testing in development and acceptance can detect paths that deviate from intended logic.
- CWE-672finds — Security testing can detect use-after-release but does not prevent it at runtime.
- CWE-674finds — Security testing in development can detect excessive recursion via static analysis or fuzzing.
- CWE-675finds — Security testing can detect duplicate operations on resources before release.
- CWE-676finds — Security testing can surface instances of dangerous functions but does not prevent their introduction.
- CWE-680finds — Security testing can detect integer-overflow-to-buffer-overflow conditions during development.
- CWE-681finds — Security testing can detect numeric conversion defects before release.
- CWE-682finds — Security testing in development and acceptance can detect calculation flaws before deployment.
- CWE-683finds — Security testing in development can detect argument-order defects, yet testing coverage is rarely exhaustive.
- CWE-684finds — Security testing in development and acceptance validates that implemented functionality conforms to specifications before release.
- CWE-686finds — Security testing in development can detect type-related defects through unit, integration, and static-analysis testing.
- CWE-687finds — Security testing in development can detect incorrect argument values before release.
- CWE-688finds — Security testing can detect argument-related defects but does not prevent them at source.
- CWE-690finds — Security testing in development can detect missing NULL checks before release.
- CWE-691finds — Security testing in development and acceptance can detect control-flow weaknesses but does not itself implement preventive controls.
- CWE-692finds — Security testing can discover incomplete denylists, yet the control does not mandate their replacement.
- CWE-694finds — Security testing can detect duplicate identifiers before deployment.
- CWE-695finds — Security testing can detect but does not prevent use of prohibited low-level code.
- CWE-696finds — Security testing can detect ordering flaws but does not prevent them during development.
- CWE-697finds — Security testing can detect incorrect comparison flaws before deployment.
- CWE-698finds — Security testing can detect EAR flaws before deployment.
- CWE-704finds — Security testing can uncover type-conversion defects before release.
- CWE-705finds — Security testing can detect control-flow scoping defects before release.
- CWE-706finds — Security testing can detect incorrect name or reference resolution through fuzzing and negative test cases.
- CWE-707finds — Security testing can detect neutralization flaws but does not itself implement the required controls.
- CWE-710finds — Testing can detect violations but does not prevent them.
- CWE-73finds — Security testing can detect path-traversal issues but does not itself implement preventive controls.
- CWE-733finds — Security testing in development can detect optimization-induced removal of security mechanisms.
- CWE-74finds — Security testing in development catches injection vulnerabilities before release.
- CWE-749finds — Security testing can detect exposed dangerous functions, but does not prevent their initial introduction.
- CWE-75finds — Security testing catches injection vulnerabilities but does not itself implement the sanitization fix.
- CWE-754finds — Security testing in development and acceptance verifies handling of error and exceptional conditions.
- CWE-755finds — Security testing in development and acceptance verifies correct handling of exceptional conditions.
- CWE-756finds — Security testing can detect missing custom error pages and verify they do not leak sensitive information.
- CWE-757finds — Security testing can detect and block algorithm downgrade vulnerabilities before deployment.
- CWE-758finds — Security testing can detect some instances of undefined behavior but does not prevent the root weakness.
- CWE-759finds — Security testing can detect unsalted hashes but does not prevent their introduction.
- CWE-76finds — Security testing can detect incomplete neutralization but does not prevent the weakness itself.
- CWE-760finds — Security testing in development and acceptance can detect weak password hashing implementations.
- CWE-761finds — Security testing can detect the flaw but does not prevent it at the source.
- CWE-762finds — Security testing in development can detect mismatched alloc/free pairs before release.
- CWE-763finds — Security testing can detect invalid pointer releases before release.
- CWE-764finds — Security testing in development can exercise locking scenarios and detect multiple-lock conditions before release.
- CWE-765finds — Security testing in development can detect resource-state anomalies caused by multiple unlocks.
- CWE-767finds — Security testing can detect improper exposure of private variables during acceptance.
- CWE-768finds — Security testing can detect incorrect short-circuit behavior before release.
- CWE-77finds — Security testing in development catches command-injection vulnerabilities before release.
- CWE-771finds — Security testing can detect missing references to allocated resources before deployment.
- CWE-774finds — Security testing can detect unbounded descriptor allocation before release.
- CWE-775finds — Security testing can detect unreleased descriptors, providing partial coverage of the weakness.
- CWE-776finds — Security testing can detect and block XML entity-expansion vulnerabilities before deployment.
- CWE-777finds — Security testing can detect unanchored regex but does not prevent the weakness by itself.
- CWE-78finds — Security testing and code review target insecure use of operating-system command interfaces, catching command-injection flaws introduced during development.
- CWE-780finds — Security testing can detect use of RSA without OAEP during development.
- CWE-782finds — Security testing can detect missing IOCTL authorization during development.
- CWE-783finds — Security testing can detect logic errors caused by precedence issues.
- CWE-784finds — Security testing can detect missing cookie validation but does not prevent the weakness by itself.
- CWE-786finds — Security testing in development can detect and eliminate pre-buffer memory accesses before release.
- CWE-787finds — Security testing in development and acceptance can detect and prevent out-of-bounds write defects.
- CWE-788finds — Security testing in development can detect buffer-overrun defects before release.
- CWE-789finds — Security testing in development can detect and block excessive allocation flaws before deployment.
- CWE-79finds — Secure-coding testing and automated code-analysis tools are applied to detect improper neutralization of script-related content during web-page generation.
- CWE-790finds — Security testing can detect improper filtering but does not itself implement the filtering control.
- CWE-791finds — Security testing in development and acceptance can detect incomplete filtering but does not itself implement the filtering.
- CWE-792finds — Security testing in development and acceptance can detect incomplete filtering but does not itself implement the fix.
- CWE-794finds — Security testing can detect incomplete filtering but does not itself implement the filtering mechanism.
- CWE-80finds — Security testing in development catches unneutralized script tags before release.
- CWE-804finds — Security testing can detect weak CAPTCHA implementations before deployment.
- CWE-805finds — Security testing in development can detect out-of-bounds accesses, but does not guarantee prevention.
- CWE-807finds — Security testing in development catches input-validation flaws before deployment.
- CWE-81finds — Security testing in development and acceptance can detect unneutralized script in error pages but does not itself implement the fix.
- CWE-82finds — Security testing in development can detect and drive remediation of improper script handling in IMG tags.
- CWE-820finds — Security testing can detect missing synchronization through concurrency testing.
- CWE-821finds — Security testing can detect synchronization flaws before production deployment.
- CWE-822finds — Security testing can detect pointer-dereference flaws before release.
- CWE-823finds — Security testing can detect out-of-range pointer offsets before release.
- CWE-824finds — Security testing can detect uninitialized pointer usage before release.
- CWE-825finds — Security testing can detect use-after-free issues, but removing this weakness alone does not fulfill the testing control.
- CWE-826finds — Security testing can detect premature-release bugs, providing partial mitigation.
- CWE-827finds — Security testing in development can detect XXE vectors arising from uncontrolled DTD references.
- CWE-828finds — Security testing can detect unsafe signal handlers but does not prevent their introduction.
- CWE-83finds — Security testing in development catches attribute-injection flaws before release but does not itself implement the fix.
- CWE-830finds — Security testing can detect the weakness, but does not prevent its introduction during design or coding.
- CWE-832finds — Security testing may detect the flaw but does not prevent it by itself.
- CWE-833finds — Security testing in development can detect deadlock conditions through stress and concurrency testing.
- CWE-834finds — Security testing can detect excessive iteration through stress and fuzz testing.
- CWE-835finds — Security testing can uncover infinite-loop conditions before release.
- CWE-838finds — Security testing can detect encoding mismatches, but testing alone does not prevent the weakness at source.
- CWE-839finds — Security testing in development and acceptance can detect missing minimum checks through boundary-value and fuzz testing.
- CWE-84finds — Security testing in development and acceptance will detect URI-scheme injection flaws before release.
- CWE-841finds — Security testing can detect workflow bypasses but does not enforce them at runtime.
- CWE-843finds — Security testing in development can detect type-confusion vulnerabilities through fuzzing and static analysis.
- CWE-85finds — Security testing can detect doubled-character XSS, but testing alone does not prevent the weakness from being introduced.
- CWE-86finds — Security testing can detect the weakness but does not itself implement the neutralization controls.
- CWE-87finds — Security testing catches residual XSS but does not itself implement the neutralization controls.
- CWE-88finds — Security testing can detect argument injection but does not prevent it at the source.
- CWE-89finds — The same secure-coding and static-analysis activities surface missing neutralization of SQL metacharacters before the system is accepted.
- CWE-90finds — Security testing in development catches LDAP injection via dynamic analysis or fuzzing, but does not prevent it at the source.
- CWE-908finds — Security testing in development and acceptance can detect uninitialized resource usage through dynamic analysis and fuzzing.
- CWE-909finds — Security testing can detect missing initialization defects before deployment.
- CWE-91finds — Security testing catches XML injection during development but does not itself implement the fix.
- CWE-910finds — Security testing can detect use-after-close defects before release.
- CWE-911finds — Security testing in development can detect reference-count defects before release, providing partial mitigation.
- CWE-912finds — Security testing in development and acceptance can discover undocumented functionality before release.
- CWE-913finds — Security testing can detect dynamic code weaknesses but does not prevent them at design or coding time.
- CWE-914finds — Security testing can detect and prevent dynamic-variable weaknesses before release.
- CWE-915finds — Security testing can detect mass-assignment flaws but does not itself prevent them at runtime.
- CWE-917finds — Security testing in development and acceptance can detect EL injection but does not itself implement the fix.
- CWE-925finds — Security testing can detect missing intent verification but does not prevent the weakness by itself.
- CWE-926finds — Security testing can detect exported components lacking proper restrictions, providing partial coverage of the weakness.
- CWE-927finds — Security testing can detect the weakness but does not itself prevent it at runtime.
- CWE-93finds — Security testing can detect CRLF flaws but does not itself implement the neutralization.
- CWE-939finds — Security testing can discover missing authorization checks, but does not itself implement the required controls.
- CWE-941finds — Security testing can detect incorrect destinations, yet it is a detection rather than prevention control.
- CWE-942finds — Security testing can detect overly permissive cross-domain policies but does not prevent their initial introduction.
- CWE-943finds — Security testing in development catches injection vulnerabilities before release but does not itself implement the fix.
- CWE-95finds — Security testing in development can detect eval injection vulnerabilities before deployment.
- CWE-96finds — Security testing in development and acceptance will detect static code injection but does not prevent it at the source.
- CWE-97finds — Security testing can detect SSI flaws but does not itself implement the neutralization controls.
- CWE-98finds — Security testing can detect RFI but does not prevent the weakness by itself.
- CWE-99finds — Security testing can detect resource-injection flaws but does not itself implement preventive controls.
Mitigated MITRE ATT&CK techniques (952)
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 →PT1001.001←M →PT1001.002←MT1001.003←M →PT1003→PT1003.001←M →PT1003.002→PT1003.003→PT1003.004→PT1003.005→PT1003.006→PT1003.007→PT1003.008→PT1006←M →PT1008→PT1012→PT1014←M →PT1020.001→PT1021→PT1021.001→PT1021.003→PT1021.004→PT1021.005→PT1021.006→PT1021.008→PT1027←M →PT1027.001←M →PT1027.002←M →PT1027.003←M →PT1027.004→PT1027.005←M →PT1027.006←M →PT1027.007←M →PT1027.008←M →PT1027.009←M →PT1027.010←M →PT1027.011←M →PT1027.012←M →PT1027.013←M →PT1027.014←M →PT1027.015←M →PT1027.016←M →PT1027.017←M →PT1027.018←M →PT1036←M →PT1036.001→PT1036.002←M →PT1036.003←M →PT1036.004←M →PT1036.005←M →PT1036.006→PT1036.007←M →PT1036.008←M →PT1036.009←M →PT1036.010→PT1036.011←M →PT1036.012←M →PT1037→PT1037.001→PT1037.002→PT1037.003→PT1037.004→PT1037.005→PT1040→PT1041→PT1046→PT1047→PT1048→PT1048.003→PT1049→PT1053→PT1053.002→PT1053.003→PT1053.005→PT1053.006→PT1053.007→PT1055←M →PT1055.001←M →PT1055.002←M →PT1055.003←M →PT1055.004←M →PT1055.005←M →PT1055.008←M →PT1055.009←M →PT1055.011←M →PT1055.012←M →PT1055.013←M →PT1055.014←M →PT1055.015←M →PT1056←M →PT1056.001→PT1056.002←M →PT1056.003←M →PT1056.004←M →PT1059→PT1059.001→PT1059.002→PT1059.003→PT1059.004→PT1059.005→PT1059.006→PT1059.007→PT1059.008→PT1059.009→PT1059.010→PT1059.011→PT1059.012→PT1059.013→PT1068←M →PT1069.003→PT1070→PT1070.006←MT1070.010←M →PT1071←MT1071.001←M →PT1071.004←M →PT1072→PT1078→PT1078.001←M →PT1078.002→PT1078.004←M →PT1080→PT1083→PT1090←MT1090.001→PT1090.002→PT1090.003←M →PT1095←MT1098→PT1098.001→PT1098.002→PT1098.003→PT1098.004→PT1098.005←M →PT1098.006→PT1098.007→PT1102←MT1102.001←M →PT1102.002←M →PT1102.003→PT1104→PT1105→PT1106→PT1110→PT1110.001→PT1110.002→PT1110.003→PT1110.004→PT1111←M →PT1112→PT1114.003→PT1119→PT1127→PT1127.001←M →PT1127.002→PT1127.003←M →PT1129→PT1132←M →PT1132.001←M →PT1132.002←M →PT1133→PT1134←M →PT1134.001←M →PT1134.002←M →PT1134.003←M →PT1134.004←M →PT1134.005←M →PT1136→PT1136.001→PT1136.003→PT1137→PT1137.001→PT1137.002→PT1137.003→PT1137.004→PT1137.005→PT1137.006→PT1140→PT1176←M →PT1176.001←M →PT1176.002←P →PT1185←M →PT1187→PT1189←M →PT1190←M →PT1195→PT1195.001→PT1195.002→PT1195.003→PT1197→PT1202←M →PT1203→PT1204→PT1204.001←PT1204.002→PT1204.003←M →PT1204.004←MT1204.005←M →PT1205←M →PT1205.001←M →PT1205.002←M →PT1207←M →PT1210→PT1211←M →PT1212→PT1216←M →PT1216.001←M →PT1216.002→PT1218←M →PT1218.001←P →PT1218.002←P →PT1218.003←M →PT1218.004←M →PT1218.005←M →PT1218.007←M →PT1218.008←M →PT1218.009←M →PT1218.010←M →PT1218.011←M →PT1218.012←M →PT1218.013←M →PT1218.014→PT1218.015←P →PT1219→PT1219.001→PT1219.002→PT1219.003←MT1220←M →PT1221←M →PT1222←M →PT1222.001←M →PT1222.002←M →PT1480←P →PT1480.001←M →PT1480.002→PT1482→PT1484←M →PT1484.001→PT1484.002←M →PT1485→PT1489→PT1490→PT1491→PT1491.001→PT1491.002→PT1495→PT1496→PT1496.001→PT1496.002→PT1496.003→PT1496.004→PT1497→PT1497.001←M →PT1497.002←MT1497.003←PT1498→PT1498.001→PT1498.002→PT1499←F →PT1499.001→PT1499.002→PT1499.003→PT1499.004→PT1505→PT1505.001→PT1505.002→PT1505.003→PT1505.004←P →PT1505.005→PT1505.006→PT1525←P →PT1528←P →PT1529→PT1530→PT1531→PT1534→PT1535←MT1537←M →PT1538→PT1539←F →PT1542←M →PT1542.001←P →PT1542.002←M →PT1542.003←M →PT1542.004→PT1542.005→PT1543→PT1543.001←P →PT1543.002←M →PT1543.003←P →PT1543.004←P →PT1543.005→PT1546←P →PT1546.001←M →PT1546.002→PT1546.003→PT1546.004←P →PT1546.005→PT1546.006←P →PT1546.007←P →PT1546.008←M →PT1546.009→PT1546.010←M →PT1546.011→PT1546.012←P →PT1546.013←P →PT1546.014→PT1546.015←M →PT1546.016←P →PT1546.017→PT1546.018←P →PT1547→PT1547.001←P →PT1547.002→PT1547.003→PT1547.004←P →PT1547.005→PT1547.006←M →PT1547.007→PT1547.008→PT1547.009→PT1547.010→PT1547.012→PT1547.013→PT1547.014→PT1547.015→PT1548←M →PT1548.001→PT1548.002←M →PT1548.003←M →PT1548.004→PT1548.005→PT1548.006←M →PT1550←M →PT1550.001←F →PT1550.002←FT1550.003←M →PT1550.004→PT1552←M →PT1552.001→PT1552.002←MT1552.004←P →PT1552.005←M →PT1552.006→PT1552.007→PT1552.008→PT1553←M →PT1553.001←M →PT1553.002←M →PT1553.003→PT1553.004←M →PT1553.005←M →PT1553.006←M →PT1554←P →PT1555→PT1555.002→PT1555.003→PT1555.004→PT1555.005→PT1555.006→PT1556←M →PT1556.001←M →PT1556.002←F →PT1556.003→PT1556.004←M →PT1556.005→PT1556.006←F →PT1556.007←M →PT1556.008→PT1556.009←M →PT1557→PT1557.001→PT1557.002→PT1557.003→PT1557.004→PT1558→PT1558.001→PT1558.002→PT1558.003→PT1558.004→PT1558.005→PT1559→PT1559.001→PT1559.002→PT1559.003→PT1560.002→PT1561.002→PT1563→PT1563.001→PT1563.002→PT1564→PT1564.001→PT1564.002→PT1564.003→PT1564.004→PT1564.005→PT1564.006→PT1564.007→PT1564.008→PT1564.009→PT1564.010→PT1564.011→PT1564.012→PT1564.013→PT1564.014→PT1565→PT1565.001→PT1565.002→PT1565.003→PT1566.003←MT1567.001→PT1567.004→PT1568→PT1568.002→PT1568.003←P →PT1569→PT1569.001→PT1569.002→PT1569.003→PT1570→PT1571←M →PT1572←M →PT1573→PT1573.001→PT1573.002→PT1574←M →PT1574.001→PT1574.004←M →PT1574.005→PT1574.006←M →PT1574.007←M →PT1574.008→PT1574.009→PT1574.010→PT1574.011←P →PT1574.012←P →PT1574.013←M →PT1574.014←M →PT1578←M →PT1578.001←PT1578.002←M →PT1578.003←MT1578.004←MT1578.005←M →PT1587.001←MT1588.005←P →PT1599←M →PT1599.001←M →PT1600←P →PT1600.001→PT1600.002←P →PT1601←M →PT1601.001←M →PT1601.002←M →PT1602.001→PT1602.002→PT1606←M →PT1606.001←M →PT1606.002→PT1608.005→PT1609→PT1610←P →PT1611→PT1612←M →PT1613→PT1615→PT1620←M →PT1621←M →PT1622←M →PT1647←P →PT1648→PT1649→PT1651→PT1654→PT1659→PT1665←M →PT1666←MT1671←P →PT1674←P →PT1675→PT1677←M →PT1678←M →PT1679←P →PT1685←M →PT1685.001←M →PT1685.002←M →PT1685.003←M →PT1685.004←M →PT1685.005←M →PT1686←F →PT1686.001←M →PT1686.002←M →PT1686.003←M →PT1687←M →PT1688←M →PT1689←M →PT1690←M
Why these map — AI rationale (under review)
- T1001detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure code, configurations and design flaws; this can detect some T1001 implementations (e.g. via pen-testing that exercises C2 channels or static analysis that flags obfuscation patterns), but the control is scoped to pre-deployment development/acceptance testing of systems and does not address runtime detection of live adversary C2 traffic on production platforms.
- T1001.001detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that can surface observable indicators or test failures revealing junk-data C2 in custom in-house or acquired components before or during acceptance, but does not monitor or detect the live technique post-deployment.
- T1001.003detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that surfaces insecure configurations, insecure code, and deviations from secure functions/cryptography — which can catch many Protocol or Service Impersonation artifacts (e.g. malformed SSL handshakes, manipulated headers, or anomalous certs) during development and acceptance, but only for first-party or acquired components and only before deployment, leaving post-deployment runtime C2 impersonation on live systems outside its scope.
- T1003detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure configurations, insecure code and missing security functions; this can detect the presence of credential-dumping vectors (e.g. weak access controls on LSASS, unhardened memory, missing credential-guard equivalents) before production, but does not instrument or surface the T1003 technique once it is executed at runtime.
- T1003prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) during development and acceptance that can surface credential-dumping weaknesses before production, thereby preventing some instances of the technique; it is not a runtime control and does not reach all possible credential locations or custom tools.
- T1003.001detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations, insecure code, and design flaws; these can detect the presence of weak SSP configurations, modifiable registry keys, or missing protections that enable LSASS dumping, but do not broadly detect the runtime technique itself.
- T1003.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface insecure configurations, weak access controls or credential-handling flaws enabling SAM extraction, but does not monitor or detect the live post-deployment adversary technique itself.
- T1003.003detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) during development and acceptance that can surface insecure configurations, weak access controls, or backup handling that would enable T1003.003, but does not monitor or detect the technique when it is executed in production.
- T1003.004detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure configurations, insecure code and design flaws; this can detect the presence of the LSA-secrets weakness (e.g. overly permissive registry ACLs or use of vulnerable credential-dumping patterns) before deployment, but does not monitor or surface the technique once it is executed at runtime on a production host.
- T1003.005detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure credential caching or storage mechanisms before production; this is genuine but only a minority slice of the post-deployment technique (SYSTEM-level extraction of live cached hashes via Mimikatz, secretsdump, etc.) that the control does not instrument or observe in operation.
- T1003.006detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments to surface security flaws before production; this can surface misconfigurations or missing ACLs on domain replication that enable DCSync, but does not monitor or detect the live technique once it runs on a production domain controller.
- T1003.007detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface insecure configurations, memory handling flaws or credential exposure patterns (including procfs access) before production, but does not monitor or detect the live adversary technique at runtime on deployed systems.
- T1003.008detects — A.8.29 requires vulnerability scanning and penetration testing (plus code review) that can surface insecure configurations or access-control weaknesses enabling /etc/shadow dumping, but only as one possible test target among many and only when the test plan elects to include it; it does not mandate ongoing or specific detection of this technique.
- T1006detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface T1006-enabling flaws such as missing volume-access restrictions or insecure configurations before production, but does not monitor or detect the technique once it runs in an operational environment.
- T1008detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure configurations, insecure code and design flaws; fallback-channel C2 mechanisms are observable as anomalous or insecure network behavior during such tests, but only for in-house or explicitly tested acquired components and only where the test plan chooses to exercise them.
- T1012detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface insecure registry-query patterns or exposed registry data flows, but does not monitor or detect the live technique at runtime on production systems.
- T1014detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure code, design and configurations; these can detect rootkit-like hiding techniques before production, but only for first-party or evaluated components and not for already-deployed kernel/boot-level rootkits on running systems.
- T1020.001detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that can surface misconfigurations or modifications enabling traffic mirroring/duplication, but only during development, acceptance or acquisition — not against live production infrastructure where the technique is actually abused post-compromise.
- T1021detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface insecure remote-service configurations, weak authentication in those services, or vulnerable remote-management tools (e.g., outdated RDP/SSH/ARD implementations) before or at deployment, but does not monitor or detect the live adversarial use of valid accounts over remote services in production.
- T1021.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus remediation verification), which surfaces insecure RDP configs, weak auth or exposed services before production; this is genuine detection of the enabling conditions for T1021.001 but only a minority slice, as the technique itself runs post-deployment against live credentials and the control does not monitor runtime RDP usage.
- T1021.003detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface insecure DCOM configurations, exposed methods, or weak ACLs before production, but does not monitor or detect the live adversarial technique post-deployment.
- T1021.004detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance, which can surface insecure SSH configurations, weak auth, or related flaws before production, but does not monitor or detect the live technique once adversaries are using valid accounts over SSH.
- T1021.005detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development and acceptance, which can surface VNC-specific flaws (weak auth, brute-force exposure, memory issues, insecure configs) before production but does not monitor or detect live adversary abuse of VNC post-deployment.
- T1021.006detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure configurations, insecure code and design flaws; WinRM abuse via valid accounts can be discovered by pen-testing or scanning for exposed/poorly-secured WinRM endpoints, but this is only a slice of the technique's post-authentication behavioral surface rather than a bounded remainder.
- T1021.008detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure configurations, code and design flaws that could enable direct VM access; this surfaces a slice of the technique (e.g. overly permissive defaults or weak auth in IaaS components) but does not broadly detect live adversary use post-deployment.
- T1027detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review (including for unanticipated inputs) that can surface obfuscated malicious payloads or command obfuscation during dev/acceptance testing, but this is limited to tested code/components in a non-production environment and does not broadly detect the technique post-deployment or in transit.
- T1027prevents — A.8.29 mandates security testing (code review, SAST, vulnerability scanning, penetration testing) during development and acceptance that surfaces insecure code and design, including command obfuscation and evasion patterns that would otherwise reach production; this stops many instances of the technique from being deployed but does not address all adversary obfuscation methods (e.g. runtime, network, or post-deployment payloads) nor guarantee complete coverage of every possible obfuscated artifact.
- T1027.001detects — A.8.29 mandates vulnerability scanning, code review and penetration testing that can surface binary padding as an evasion artifact or insecure coding practice when performed in development/acceptance, but the control is scoped to pre-production testing of the organization's own systems and does not address post-deployment detection of padded adversary malware in the environment.
- T1027.002detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure code and configurations; these can surface many (but not all) packing artifacts or custom virtual-machine protectors when the adversary technique is exercised in test, yet the control stops at pre-production and has no view of post-deployment adversary packing of payloads that never enter the organization's SDLC.
- T1027.003detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/testing that can surface steganography use in custom or acquired code/components (e.g. hidden payloads in images or scripts), but does not address runtime or post-deployment detection of the technique in operation.
- T1027.004detects — A.8.29 mandates vulnerability scanning, code review, and penetration testing (including of secure coding and configurations) that can surface compiled-after-delivery artifacts or the anomalous build step in a test environment, but this is limited to pre-production acceptance testing of in-house/outsourced systems rather than runtime detection on victim endpoints where the technique is actually used.
- T1027.005detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus remediation verification), which surfaces many tool indicators such as signatures, insecure patterns or detectable artifacts before production; this is genuine detection of the technique's output but only a slice, as the control is scoped to pre-deployment testing of in-house/outsourced code and does not instrument or detect post-deployment adversary modifications of tools in live environments.
- T1027.006detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in development/testing that can surface HTML smuggling indicators (e.g. anomalous JS Blobs, Data URLs, download attributes or insecure code patterns), but this is limited to pre-production acceptance testing of in-house or acquired systems rather than runtime detection on delivered payloads.
- T1027.007detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review (including for insecure code/design) that can surface dynamic API resolution artifacts or patterns in malware during development/acceptance testing, but this is scoped only to in-house or acquired code under test and does not broadly detect the technique in deployed production malware.
- T1027.008detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure code and configurations; these can surface stripped payloads as an obfuscation indicator when the test environment and tooling are configured for it, but the control is scoped to pre-production testing of the organization's own or acquired systems rather than runtime detection of adversary payloads in the wild.
- T1027.009detects — A.8.29 mandates vulnerability scanning, code review, and penetration testing (including automated tools) that can surface embedded/obfuscated payloads as insecure code or design flaws during dev/acceptance testing, but only for first-party or evaluated components and only where the test plan actually exercises the relevant vectors; it has no view of post-deployment adversary use of the technique.
- T1027.009prevents — A.8.29 mandates security testing (including code review, SAST, vulnerability scanning, and penetration testing) during development and acceptance that can surface embedded-payload techniques before production, thereby preventing some instances of the technique from reaching deployment; it is not a universal barrier and leaves many post-deployment or evasion variants untouched.
- T1027.010detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface some command-obfuscation patterns (e.g. via static analysis or dynamic testing of delivered payloads), but does not require runtime detection of obfuscated commands once in production use.
- T1027.011detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface fileless storage artifacts or related insecure configurations in tested systems, but only within the bounded scope of development/acceptance testing of new or changed code (not ongoing production monitoring or all adversary uses of the technique).
- T1027.012detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments to surface security flaws before production; this can catch LNK Icon Smuggling when the malicious LNK or its delivery mechanism is present in tested code or components, but does not address post-compromise use on production endpoints or LNKs arriving via phishing.
- T1027.013detects — A.8.29 mandates vulnerability scanning, code review, and penetration testing in development and acceptance to surface security flaws including insecure code and configurations; this can catch some T1027.013 implementations (e.g. detectable encoding patterns or custom schemes in reviewed artifacts) but does not broadly detect the technique once deployed on victim hosts.
- T1027.014detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including unanticipated inputs) that can surface polymorphic code or its indicators during development/acceptance testing, but this is scoped only to in-house or acquired code under test and does not address runtime detection of already-deployed polymorphic malware.
- T1027.015detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/testing that can surface compressed/obfuscated malicious payloads or self-extracting archives when they are introduced into systems or components under test, but does not monitor or detect their use at runtime or in delivered spearphishing.
- T1027.016detects — A.8.29 explicitly requires vulnerability scanning, code review, and penetration testing (including against secure coding per 8.28) that can surface junk/dead code patterns as anomalous or suspicious during development and acceptance, but this is scoped only to in-house or acquired code under test and does not broadly detect the technique post-deployment or in third-party malware.
- T1027.017detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including for unanticipated inputs) in development and acceptance testing, which surfaces SVG smuggling as an insecure coding or configuration issue before production; this is limited to the pre-deployment testing slice rather than runtime or post-deployment detection.
- T1027.017prevents — A.8.29 mandates security testing (including secure coding per 8.28, code review, vulnerability scanning, and penetration testing) during development and acceptance, which can surface and block SVG smuggling flaws before production; this is a genuine but minority slice because the control is scoped to tested in-house or acquired systems under explicit requirements, not universal prevention of the technique across all delivery vectors or post-deployment use.
- T1027.018detects — A.8.29 explicitly requires vulnerability scanning, code review, and penetration testing that surface insecure code and hidden payloads (including those evading basic static analysis), but the control is scoped to development/acceptance testing of new or changed systems rather than ongoing production detection of this technique.
- T1027.018prevents — A.8.29 mandates security testing (code review, SAST, vulnerability scanning, penetration testing) during development that surfaces hidden Unicode abuse as a static-analysis evasion or insecure-coding defect, thereby stopping many instances from reaching production; it is not a universal barrier because the control is scoped to tested systems, test depth is risk-proportional, and runtime reconstruction via eval/proxy traps can still evade incomplete test coverage.
- T1036detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test that can surface masquerading artifacts (e.g. renamed binaries, suspicious metadata, insecure configs) before production; this is genuine detection but only a minority slice of the technique's post-deployment, runtime evasion surface across live environments.
- T1036.001detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure code, design and configurations; these can catch invalid-signature binaries that mimic legitimate ones, but only for first-party or acquired components under test, not for arbitrary adversary-produced artifacts post-deployment.
- T1036.002detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in development/testing that can surface RTLO-based masquerading when it appears in code, filenames, configs or test artifacts, but does not monitor production execution or user-facing rendering where the technique is most commonly realised.
- T1036.002prevents — A.8.29 mandates security testing (including secure coding per 8.28, code review, vulnerability scanning, and penetration testing) during development that can surface and block RTLO-based filename disguises before production, but this is a narrow slice of the technique's attack surface (e.g., phishing attachments, registry edits, or post-deployment use) rather than a broad barrier.
- T1036.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus automated tools) that can surface renamed/masqueraded utilities when they are introduced or exercised during acceptance testing, but this is limited to pre-production discovery of test artifacts rather than runtime detection of the technique in a live environment.
- T1036.004detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/acceptance testing that can surface masquerading artifacts (e.g. anomalous service names or descriptions) before production, but this is limited to pre-deployment testing of in-house or acquired components rather than runtime detection of the technique.
- T1036.005detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance that can surface naming/location masquerading artifacts (especially in containers or custom code) before production, but does not monitor or detect the technique at runtime in deployed environments.
- T1036.006detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure code, design and configurations; these can catch the filename-space masquerading pattern when exercised against sample artifacts or during acceptance, but the control is scoped to pre-production testing of new/changed systems rather than runtime or deployed-file detection on endpoints.
- T1036.007detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in a production-like test environment to surface insecure code/configurations before deployment; this can catch double-extension masquerading in test payloads or email-attachment scenarios, but the control is scoped to pre-production acceptance testing of systems/components and does not instrument or monitor live user execution or file-open events where the technique is typically realized.
- T1036.008detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in a production-like test environment that surfaces masquerading artifacts (wrong signatures, polyglots, anomalous extensions) before deployment, directly matching the technique's core indicators.
- T1036.008prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and acquired components in development and acceptance; this catches many masquerading payloads that violate secure coding, configuration, or functional security requirements before they reach production, but does not stop an adversary from performing the technique post-deployment or on already-deployed systems.
- T1036.009detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in a production-like test environment, which can surface process-tree evasion artifacts (e.g. unexpected forking, daemonization or anomalous PPID patterns) when they appear in tested malware or components, but the control is scoped to pre-deployment testing of systems/code rather than runtime detection of the live technique on production endpoints.
- T1036.010detects — A.8.29 requires vulnerability scanning, penetration testing and code review in dev/test environments that can surface masquerading account names (e.g. via anomalous account creation, insecure configs or post-change discovery), but this is limited to pre-production testing of in-house or acquired systems and does not broadly detect the technique at runtime on deployed production environments across its full platform scope.
- T1036.011detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface process-argument spoofing if the technique appears in test artifacts, custom code or insecure configurations, but this is limited to pre-production discovery and does not address runtime detection of the in-memory overwrite on deployed Linux systems.
- T1036.012detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure configurations, code and design flaws; this can detect the presence of fingerprinting/spoofing logic or weak anti-fingerprinting defenses during development, but does not instrument or monitor live adversary use of the technique at runtime.
- T1037detects — A.8.29 mandates security testing (including vulnerability scanning, code review, and penetration testing) during development and acceptance that can surface insecure boot/logon initialization scripts or related misconfigurations before production, but does not monitor or detect the technique once it is already present and executing in a running environment.
- T1037.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface a malicious or anomalous logon script (or its registry artifact) during development, acceptance or post-deployment testing, but this is scoped only to tested changes and new systems rather than continuous production monitoring of an already-deployed persistence technique.
- T1037.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance that can surface insecure configurations or code allowing login-hook persistence (especially in test environments matching production), but this is limited to pre-deployment testing of new/changed systems and does not broadly detect the technique post-deployment or in running production environments.
- T1037.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface malicious or anomalous logon scripts (including those planted via GPO/AD) when performed in dev/test or on production-like environments, but this is scoped only to tested changes and new deployments rather than continuous runtime detection of persistence.
- T1037.004detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface the modified RC script as an insecure configuration, backdoor, or anomalous boot-time change when performed in a representative test or acceptance environment; this is genuine detection of the technique but only a slice because the control is scoped to development/acceptance testing of new or changed systems rather than continuous runtime monitoring of production systems where the persistence would actually be introduced by an adversary.
- T1037.005detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface the presence of unauthorized startup-item artifacts or the insecure configurations/code enabling them, but only when those tests are deliberately run against the relevant environment and only for the subset of cases inside the chosen test scope and criteria.
- T1040detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) of new systems, upgrades, and code before production deployment, which can surface network sniffing vectors such as insecure protocols, missing encryption, or misconfigurations that enable promiscuous-mode capture; this is limited to the pre-deployment test window and does not address live post-deployment sniffing on running production systems.
- T1041detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure configurations, insecure code and design flaws in development and acceptance; this can detect the presence of exfiltration-over-C2 logic or channels before deployment, but only for first-party or evaluated components and only during pre-production testing, leaving post-deployment runtime use and third-party/outsourced code outside its scope.
- T1046detects — A.8.29 mandates vulnerability scanning and penetration testing (plus code review) during development and acceptance to surface insecure configurations, system vulnerabilities and insecure code that could enable network service discovery; this surfaces the technique in pre-production but does not address adversary-performed discovery post-deployment on production systems.
- T1047detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface misuse of WMI (e.g. via insecure code, unexpected inputs or insecure configurations) before production but does not monitor or detect live adversary abuse of WMI post-deployment.
- T1048detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus remediation verification), which surfaces insecure configurations, coding, or design that enable T1048 (e.g. open alternate-protocol services, missing egress filters, or unsafe cloud API exposure) before production; this is genuine detection of technique precursors but only a minority slice of the class, as most T1048 realizations use permitted protocols/utilities post-deployment with no dev-test signal.
- T1048.003detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) during development and acceptance that can surface insecure configurations, missing encryption functions, and insecure coding that would enable unencrypted exfiltration, but this is limited to pre-deployment testing of in-house or acquired systems rather than runtime detection of the technique in operation.
- T1049detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure configurations, exposed services or weak network segmentation that would enable T1049-style discovery, but does not require runtime monitoring or detection of the technique once the system is in production.
- T1053detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in dev/test environments (plus automated tools) that can surface T1053 abuse when it appears in tested code, scheduled tasks, or insecure configs, but this is limited to pre-deployment testing of in-house/outsourced systems rather than runtime detection across deployed production environments.
- T1053.002detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface at-abuse indicators (e.g. anomalous scheduled-job code or insecure configurations) before production, but does not monitor or detect live technique execution post-deployment.
- T1053.003detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface malicious or anomalous cron jobs/configurations when performed in dev/test environments matching production, but this is limited to pre-deployment testing of changes rather than ongoing runtime detection of adversary cron abuse.
- T1053.005detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in a production-like test environment, which surfaces hidden or anomalous scheduled tasks created via schtasks, WMI or registry manipulation as insecure configurations or code before or during deployment
- T1053.006detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface malicious or anomalous systemd timer/service unit files when they are introduced as part of new or changed code or packages, but does not monitor or detect their later runtime use or installation on production systems.
- T1053.007detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that surfaces insecure configurations, code, and design flaws in development and acceptance; this can detect the malicious container orchestration job or CronJob artifact when it is introduced or tested in a pre-production environment that mirrors production, but does not broadly detect live post-deployment abuse of the technique on running clusters.
- T1055detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including for unanticipated inputs) that surface process-injection techniques or the insecure code/configurations enabling them, but only as one slice of broader security testing whose scope and depth are left to risk-based test-plan criteria rather than mandating comprehensive coverage of all injection vectors.
- T1055prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) during development and acceptance that can surface and block process-injection weaknesses before production, but this is a testing practice whose coverage depends on the rigour and scope chosen by the implementer rather than a universal mechanism that stops the technique.
- T1055.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface many (but not all) DLL injection vectors in custom or acquired code before production; it does not instrument or monitor running production processes for the technique in flight.
- T1055.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface PE injection indicators or insecure patterns that enable it in tested code or components, but this is limited to pre-production testing of in-scope systems and does not broadly detect the live technique post-deployment.
- T1055.003detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface process-injection techniques such as thread hijacking when performed in test or acceptance environments, but the control is scoped only to pre-production testing of new/changed systems and does not address runtime detection of the technique in deployed production environments.
- T1055.003prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of applications and components in development and acceptance to catch insecure code, functions, and configurations before production; this can surface the injection vectors or flawed process-handling code that enable T1055.003 but does not stop the technique from being written or used at runtime.
- T1055.003responds — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that can surface in-process injection artifacts during development or acceptance, enabling response actions once the technique is exercised in test.
- T1055.004detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including for insecure code/design) that can surface APC injection as a flaw during development or acceptance testing of in-house or acquired components.
- T1055.004prevents — A.8.29 mandates security testing (including secure coding per 8.28, vulnerability scanning, code review, and penetration testing) during development that can surface and block APC-injection flaws before production, but does not guarantee their absence in all shipped code or third-party components.
- T1055.005detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including for insecure code/design and unanticipated inputs) that surface TLS callback injection flaws during development and acceptance testing, but only where the test plan and environment cover this specific technique (proportionate to risk, not mandated universally).
- T1055.008detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) during development and acceptance to surface insecure code, design and configurations; these can detect the presence of ptrace-based injection logic or patterns before production, but only for first-party/in-house code under test and not for live post-deployment execution of the technique against running processes.
- T1055.009detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure code, design and configurations; these can catch proc-memory-injection artifacts or test cases in development/acceptance, but the control is scoped to pre-production testing of the organization's own systems/components and does not instrument or monitor live production processes for the technique itself.
- T1055.009prevents — A.8.29 mandates security testing (including secure coding per 8.28, vulnerability scanning, penetration testing, and code review) during development and acceptance, which can surface and help eliminate proc-memory-injection vectors before production; this is a genuine but minority slice of the Linux-specific technique that lives in runtime process manipulation rather than in the tested application code itself.
- T1055.011detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface EWM injection as an insecure coding or design flaw before production, but does not monitor or detect the live technique at runtime.
- T1055.011prevents — A.8.29 mandates security testing (including secure coding per 8.28, vulnerability scanning, code review, and penetration testing) during development that can surface and block EWM injection flaws before production, but does not guarantee their absence in all Windows graphical processes or runtime evasion paths.
- T1055.012detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including unanticipated inputs/conditions) that can surface process-hollowing artifacts or the injected code in development, acceptance and pre-acquisition testing; this is genuine detection but only a slice, as the control is scoped to pre-production/test environments and does not mandate runtime monitoring of production process-injection behavior.
- T1055.013detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface process-doppelganging indicators or related insecure coding patterns before production, but the control is scoped to pre-deployment testing of the organization's own systems/components and does not address runtime detection of the live technique on production Windows endpoints.
- T1055.014detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface VDSO hijacking artifacts or anomalous behavior in tested code/components before production, but this is limited to pre-deployment testing of new/changed systems rather than runtime detection of the live technique on Linux.
- T1055.015detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure code/design and system vulnerabilities in development and acceptance; this can catch ListPlanting-style injection vectors when they appear in custom in-house code or components, but the control stops at pre-deployment testing in a non-production environment and has no view of post-deployment runtime use of the technique against live processes.
- T1056detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure code, design and configurations capable of enabling input capture, but does so only pre-deployment in development and acceptance testing, not against live adversary TTPs at runtime.
- T1056.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus automated tools) that can surface keylogging mechanisms (e.g. hooks, drivers, registry mods) before or during deployment, but does not monitor or detect the technique once running in production.
- T1056.001prevents — A.8.29 mandates security testing (including secure coding, configs, vuln scanning, code review and pen testing) that can surface and block many keylogging vectors before production, but leaves residual paths such as custom drivers, hardware-buffer reads, and post-deployment runtime techniques unaddressed.
- T1056.002detects — A.8.29 mandates security testing (including vulnerability scanning, code review, and penetration testing) that can surface GUI input capture techniques when exercised in test environments or during code inspection, but this is limited to pre-deployment testing of in-house or acquired components and does not address runtime detection of the technique in production.
- T1056.003detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface web portal credential-capture code (or the insecure design enabling it) before or after deployment in test environments that mirror production.
- T1056.003prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components before production deployment, which can surface and block insertion of credential-capturing code on web portals during initial build or change windows; it does not address post-compromise installation via admin access on already-deployed systems.
- T1056.004detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface hooking-based credential theft mechanisms (especially in custom in-house code or components) but does not address runtime detection of the technique after deployment.
- T1056.004prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) during development and acceptance to catch insecure code and design that could enable hooking mechanisms, thereby preventing many but not all instances of the technique from reaching production.
- T1059detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface misuse of interpreters or insecure configurations enabling T1059, but this is limited to pre-deployment discovery in tested code/components and does not address runtime or post-deployment detection of the technique.
- T1059prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configs, code review, vuln scanning, and pen testing) during development and acceptance, which can surface and block insecure interpreter configurations or unsafe interpreter usage before production, but does not remove or disable the built-in interpreters the technique relies on.
- T1059.001detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including for insecure code/configurations) that can surface PowerShell abuse techniques or malicious scripts during development and acceptance testing, but this is limited to pre-production testing of in-house/outsourced code rather than runtime detection of the technique in deployed environments.
- T1059.002detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface AppleScript-based execution techniques (or the malicious scripts/binaries that embed them) before production; this is limited to the pre-deployment test window and to what the chosen test plan actually exercises, leaving post-deployment or untested vectors unreached.
- T1059.002prevents — A.8.29 mandates security testing (including secure coding per 8.28, vulnerability scanning, code review, and penetration testing) during development and acceptance to catch flaws before production; this can surface or block insecure AppleScript usage patterns in custom in-house or acquired macOS code, but leaves the built-in interpreter, its legitimate uses, and post-deployment abuse vectors untouched.
- T1059.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface insecure configurations, insecure code or design allowing cmd.exe abuse (e.g. via unexpected inputs or weak restrictions), but this is limited to pre-deployment discovery in a test environment and does not broadly detect the technique at runtime in production.
- T1059.004detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface indicators of shell-abuse techniques (e.g. dangerous script patterns, insecure configurations enabling shell execution, or post-deployment anomalies), but only within the tested scope and before or at deployment rather than runtime detection across live environments.
- T1059.005detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including for unanticipated inputs) that surface insecure code and design, which would detect many VB-based execution payloads during development and acceptance testing; however, it is scoped only to in-house or acquired systems under test and does not address runtime detection of adversary VB abuse post-deployment.
- T1059.006detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including for insecure code/design) that can surface Python-based execution abuse after it is present in tested systems or components.
- T1059.007detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface malicious or anomalous JavaScript usage in tested code or components, but only within the scoped test environment and development pipeline, not production runtime or post-deployment adversary execution.
- T1059.007prevents — A.8.29 mandates security testing (including secure coding per 8.28, code review, vulnerability scanning, and penetration testing) during development and acceptance, which can surface and stop insecure JS implementations or obfuscated payloads before production, but does not guarantee prevention of all adversary JS abuse vectors (e.g. post-deployment downloaded/obfuscated scripts or runtime environments outside tested code).
- T1059.008detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure code, configurations and flaws that could enable CLI abuse on network devices; this is genuine but limited to pre-deployment testing of in-scope systems rather than runtime detection of the technique in operation.
- T1059.009detects — A.8.29 requires vulnerability scanning and penetration testing (plus code review) that can surface insecure configurations, code, or design enabling cloud API abuse, but only in pre-production test environments for new/changed systems — not runtime detection of the technique in a live tenant.
- T1059.010detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including of unexpected inputs/conditions) that surface malicious or anomalous automation-script behavior in development and acceptance testing, but this is scoped only to in-house or acquired code under test and does not address runtime detection of already-deployed AHK/AutoIT abuse.
- T1059.011detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface the presence or abuse of Lua interpreters/scripts as insecure code, embedded components, or anomalous execution paths before production.
- T1059.012detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface insecure configurations or code enabling hypervisor CLI abuse (e.g. on ESXi) before production, but does not monitor or detect the technique once it is running in an operational environment.
- T1059.013detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure configurations, insecure code or design that would enable container CLI/API abuse (e.g. overly permissive APIs, missing auth on dockerd/K8s control plane, insecure images), but this is limited to pre-deployment testing in a matched test environment and does not address runtime detection of the technique once in production.
- T1068detects — Testing for insecure configurations, coding flaws, and design weaknesses before release limits the availability of privilege-escalation vulnerabilities that adversaries could exploit after gaining a foothold.
- T1068prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) during development and acceptance to catch insecure code, configurations, and exploitable flaws before production, which stops many but not all T1068 opportunities (e.g., zero-days, BYOVD, or post-deployment vulns).
- T1069.003detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that surfaces insecure configurations, access restrictions and permission-related flaws during development and acceptance; this can detect the reconnaissance technique when it appears in test environments or as part of evaluated code/config, but only for in-scope, pre-production activity on a slice of the platforms and not once the technique runs in production.
- T1070detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface T1070-style indicator-removal behaviors when they leave detectable anomalies or insecure configurations in tested artifacts.
- T1070.010detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in a near-production test environment that surfaces insecure code/configurations and defects before deployment; this can catch relocation-capable malware samples or the test artifacts they leave, but does not address post-deployment runtime relocation of already-resident payloads on live victim systems.
- T1071.001detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) of new/upgraded systems in dev/test environments that can surface misuse of web protocols for C2 in custom code or components before production, but does not monitor or detect the live technique in deployed/operational environments.
- T1071.004detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that surfaces insecure configurations, insecure code, and design flaws; this can discover DNS-tunneling implementations or test cases that allow covert C2, but the control is scoped to pre-deployment testing of the organization's own systems/components and does not broadly detect adversary use of DNS tunneling in production environments.
- T1072detects — A.8.29 requires vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface misconfigurations or insecure setups in deployment tools (especially those integrated into CI/CD) before production, but does not monitor or detect live adversary abuse of those tools post-deployment.
- T1078detects — Testing authentication and access-control mechanisms helps ensure that default, local, or domain accounts cannot be trivially abused because weak or missing controls have been identified and corrected.
- T1078.001detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations, default credentials, and authentication weaknesses in systems/components before and during deployment, directly detecting the technique's enabling conditions across the listed platforms.
- T1078.001prevents — A.8.29 mandates security testing (including secure configurations, vulnerability scanning, penetration testing, and code review) that surfaces and enables remediation of default accounts and insecure defaults before production, directly stopping many from being exploitable; it is partial because testing scope, depth, and remediation are risk-proportional rather than exhaustive, and post-deployment or integration-created defaults (e.g., vpxuser) can still arise outside tested changes.
- T1078.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface insecure credential handling, weak authentication or misconfigurations that enable domain account compromise (e.g. via T1003 paths), but this is limited to pre-deployment testing of in-scope systems and does not broadly detect the live technique post-compromise.
- T1078.004detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure configurations, insecure code and missing security functions (including auth and access controls), which can discover misconfigurations or weak cloud account setups before production; this is limited to pre-deployment testing of in-scope systems rather than runtime detection of the live technique across all cloud platforms.
- T1080detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in dev/test environments (plus remediation verification), which can surface tainted shared content or the insecure code/config that enables it before production; this is genuine but only a slice because the control is scoped to pre-deployment testing of new/changed systems rather than runtime or production monitoring of already-deployed shares.
- T1083detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that can surface insecure configurations, permissions or code patterns enabling T1083, but this is limited to the pre-deployment testing phase and does not broadly detect the technique at runtime across production environments.
- T1090.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments that can surface proxy-related code, insecure configs or unexpected network behavior before production, but does not monitor or detect the live technique once adversaries are inside a compromised environment.
- T1090.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure configurations, insecure code or design that would enable external proxy usage (e.g. open redirectors or weak boundary controls), but does not monitor or surface the live technique once an adversary is using it in a production environment.
- T1090.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance to surface insecure configurations, insecure code and design flaws; these can discover some multi-hop proxy implementations (e.g. custom onion-routing code added via T1601.001 or insecure network-device configs) before production, but miss runtime adversary use of Tor/ORB/P2P chains, post-deployment proxies, or already-compromised infrastructure.
- T1098detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in dev/test environments (plus automated tools) that can surface account manipulation artifacts such as insecure permission changes, backdoors, or anomalous credential modifications before production, but this is limited to pre-deployment testing of new/changed systems rather than runtime detection across the broad set of live platforms and post-compromise scenarios named by T1098.
- T1098.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure configurations, code and design flaws; this can surface some T1098.001 patterns (e.g. overly permissive credential-addition APIs or weak key-handling code) before production but does not address post-deployment adversary use of the technique in a live cloud account.
- T1098.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface security flaws (including insecure configurations and access control issues); this can detect misconfigurations enabling T1098.002 in tested systems or code but only for in-scope, pre-production changes and not post-deployment adversary actions on live mailboxes.
- T1098.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus remediation verification), which can surface insecure IAM/role configurations or privilege-related flaws before production but does not monitor or detect the live post-deployment technique of an adversary adding cloud roles via APIs.
- T1098.004detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations, insecure code, and deviations from secure configurations including access restriction (8.3) and SSH-related auth settings; this catches post-modification authorized_keys anomalies in tested environments but only as part of development/acceptance testing, not runtime or production monitoring, leaving most live technique executions on deployed systems unreached.
- T1098.004prevents — A.8.29 mandates security testing (including secure configurations, secure coding, vulnerability scanning, and penetration testing) during development and acceptance to catch insecure SSH setups before production, which would prevent many instances of this persistence technique from being introduced; it does not address post-deployment modifications, runtime changes via cloud APIs, or network devices.
- T1098.005detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development/acceptance to surface insecure configurations, code, and design flaws; this can detect the insecure MFA/device enrollment paths or self-enrollment weaknesses that enable T1098.005, but only for first-party or acquired systems built or tested under the control, not for post-deployment adversary actions on production IdP/MFA systems.
- T1098.006detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus remediation verification) that can surface insecure RBAC/ABAC configurations or permission-granting code before or during deployment, but does not monitor or detect the live post-deployment technique of an adversary creating RoleBindings or modifying accounts in a running container orchestration system.
- T1098.006prevents — A.8.29 mandates security testing (including secure configurations, access restrictions, code review, vulnerability scanning and penetration testing) during development and acceptance; this surfaces or stops insecure RBAC/ABAC that would allow the technique, but only for first-party or newly-acquired code/components and only to the extent that tests are thorough and cover the container orchestration surface — which is a minority slice of where the technique can be exercised post-compromise or in live cloud environments.
- T1098.007detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface post-deployment anomalous group membership or privilege escalation artifacts on tested systems, but this is limited to the test environment and acceptance phase rather than continuous or production monitoring of the live technique.
- T1102.001detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure code, configurations and design flaws in developed or acquired systems; this can detect the presence of dead-drop resolver logic or embedded C2 indicators during development or acceptance testing, but only for in-house or supplier-evaluated components and not for post-deployment adversary use of legitimate external services.
- T1102.002detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that can surface insecure code or configurations enabling outbound C2 over legitimate web services, but only during development/acceptance of in-house or acquired systems — it does not detect the live technique post-deployment on production hosts.
- T1102.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus remediation verification), which can surface insecure code or configs enabling one-way web-service C2 before production; this is genuine but only a minority slice of the post-compromise runtime technique itself.
- T1104detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) during development and acceptance that can surface multi-stage C2 designs or loaders when they appear in in-house or acquired code/components, but this is limited to pre-deployment discovery in tested artifacts and does not address runtime detection of the live technique.
- T1105detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface malicious or anomalous ingress-tool-transfer mechanisms (e.g. suspicious download utilities, insecure download paths or backdoors) before production; this is genuine detection of a slice of the technique but leaves the post-deployment runtime use of common benign tools (curl, certutil, PowerShell, etc.) on production systems untouched.
- T1106detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure API usage or syscall patterns that enable T1106 behaviors before production; this is a genuine but minority slice because the control is scoped to pre-deployment testing of new/changed systems rather than runtime detection of the technique in operation.
- T1110detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance that can surface weak authentication mechanisms (e.g. insufficient password complexity, missing lockouts or rate limiting) before production, but does not instrument or monitor live brute-force attempts against deployed accounts or services.
- T1110prevents — A.8.29 mandates security testing (including of auth functions per 8.5, secure coding per 8.28, and configs per 8.9/8.20/8.22) that can surface and drive remediation of brute-force-enabling flaws such as weak password policies, missing rate limiting, or insufficient credential hashing before production, but does not itself stop the technique from running against already-deployed accounts or services.
- T1110.001detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface weak authentication mechanisms (including those vulnerable to guessing) before production, but does not monitor or detect the live technique once deployed.
- T1110.001prevents — A.8.29 mandates security testing (including of auth functions per 8.5, secure coding per 8.28, and configs per 8.9/8.20/8.22) that can surface and drive remediation of password-guessing vectors before production, but this is a process that depends on test scope, environment fidelity, and remediation follow-through rather than a universal barrier.
- T1110.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface weak password-handling or crackable hashes in applications/configurations before production, but does not monitor or detect the offline cracking technique itself once hashes are exfiltrated.
- T1110.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus remediation verification), which surfaces password-spraying weaknesses such as weak auth configurations, missing lockouts or insecure service exposure before production; this is genuine detection of the enabling conditions but only a minority slice of the live technique itself, which is an operational authentication attack that the control does not instrument or alert on at runtime.
- T1110.003prevents — A.8.29 mandates security testing (including of auth functions per 8.5, secure coding per 8.28, and configs per 8.9/8.20/8.22) that can surface and drive remediation of weak/default password handling or overly permissive auth before production, thereby stopping some spraying vectors; this is only a slice of the technique (e.g., does not reach throttling, LDAP/Kerberos paths, or post-deployment credential hygiene).
- T1110.004detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface insecure authentication implementations or exposed credential-handling flaws (including those enabling stuffing), but does not require or guarantee detection of the live technique itself once an adversary begins using dumped credentials against production login services.
- T1110.004prevents — A.8.29 mandates security testing (including auth functions, secure coding, configs, code review, vuln scanning and pen-testing) that can surface credential-stuffing vectors such as weak auth, missing lockouts or poor password handling before production, but does not guarantee their absence or block the technique itself.
- T1111detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure MFA implementations or interception vectors (e.g. weak token handling, insecure out-of-band channels) before production, but does not monitor or detect the live adversary technique once deployed.
- T1112detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/testing that can surface insecure registry configurations or code enabling T1112, but this is limited to pre-deployment discovery in tested systems and does not broadly detect post-deployment adversary use of the technique.
- T1114.003detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface insecure configurations, hidden rules, or logic that enables email forwarding abuse before production, but does not monitor or detect the technique once it is in use on deployed systems.
- T1119detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure configurations, insecure code and design flaws that could enable automated collection tooling; this is a genuine but minority slice of the broad post-compromise technique that lives in runtime behaviors rather than in the tested artifacts.
- T1127detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development/acceptance testing, which surfaces many (but not all) instances of abuse of trusted developer utilities before production
- T1127prevents — A.8.29 mandates security testing (including secure coding, configs, code review, vuln scanning and pen testing) during development and acceptance to catch and block insecure developer utilities or code that could enable T1127 before production; this stops some but not all instances since the technique can still arise from untested third-party/outsourced components, post-deployment changes, or incomplete test coverage.
- T1127.001detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review (including for insecure code/design and unanticipated inputs) that can surface the malicious inline-task abuse of MSBuild during development or acceptance testing, but only when the technique appears inside in-house or acquired code/components under test; it does not require runtime or production monitoring that would catch the signed-binary proxy technique after deployment.
- T1127.002detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/acceptance to surface insecure code, configurations, and flaws; this can detect some ClickOnce abuse patterns (e.g. malicious .application files or startup placement) if they surface in tested components, but the control is scoped only to pre-production testing of in-house/outsourced systems and does not monitor or detect live runtime abuse of the OS utility on deployed production endpoints.
- T1127.002prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components before production deployment, which can surface and block insecure ClickOnce usage or malicious .NET payloads during development or acquisition, but does not stop an adversary from introducing or abusing ClickOnce post-deployment on a live Windows system.
- T1127.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface JamPlus abuse when it appears in build scripts or test environments, but does not monitor or detect the technique at runtime in production.
- T1129detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review (including for insecure code/design and unanticipated inputs) that surface malicious or anomalous shared-module loading behavior in development and acceptance testing.
- T1132detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure code, configurations and design flaws; this can detect the presence of encoding routines that implement T1132 in custom or acquired components, but does not broadly detect the technique when it is used at runtime in C2 traffic.
- T1132.001detects — A.8.29 mandates security testing (including automated code analysis, vulnerability scanning, and penetration testing) that can surface encoding-based C2 evasion in developed or acquired systems before production, but this is limited to pre-deployment testing of custom/outsourced code rather than runtime detection of the live adversary technique across platforms.
- T1132.002detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure code/design and insecure configurations; non-standard encoding in C2 is a detectable design or implementation defect when exercised in a test environment that approximates production, but the control is scoped only to development/acquisition-time testing of in-scope systems and does not broadly detect the technique at runtime across deployed production environments or arbitrary adversary C2.
- T1133detects — A.8.29 requires vulnerability scanning and penetration testing (plus code review) that can surface misconfigurations or exposed remote services (e.g. unauthenticated Docker/K8s APIs, weak VPN gateways, or insecure Tor hidden services) before or after deployment, but this is scoped only to development/acceptance testing of new or changed systems rather than continuous detection of live adversary use.
- T1134detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development and acceptance to surface security flaws including insecure code/design/configurations that could enable token manipulation; this surfaces the technique in tested systems but is scoped only to pre-production testing of in-house or acquired components, leaving runtime/post-deployment detection of live T1134 use unaddressed.
- T1134prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configs, code review, vuln scanning, and pen testing) during development that can surface and block token-manipulation flaws before production, but this is a process-level requirement whose effectiveness is implementation-dependent and leaves many runtime Windows token-stealing vectors (e.g. in already-deployed code or non-development paths) untouched.
- T1134.001detects — A.8.29 requires vulnerability scanning, penetration testing and code review (including of security functions and secure configurations) that can surface token-impersonation flaws or insecure token-handling code in custom or acquired software before or after deployment, but does not monitor or detect live technique execution on a running Windows system.
- T1134.002detects — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) that can surface the insecure code or configuration enabling T1134.002, but only during development/acceptance and only where the test plan and environment happen to exercise the relevant paths; it does not mandate runtime or operational detection of the technique in production.
- T1134.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface token-creation/impersonation flaws (e.g. insecure use of LogonUser/SetThreadToken) before production, but does not monitor or detect the technique when it runs at runtime on a deployed Windows system.
- T1134.004detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including for unanticipated inputs/conditions) that surface insecure code and design flaws enabling PPID spoofing, but only in the pre-production/development phase and only where the test plan chooses to cover it.
- T1134.005detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance that can surface SID-History injection flaws or insecure configurations enabling it, but only in tested code or components and not in live production environments where the technique is actually executed.
- T1136detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that surfaces insecure configurations, missing access restrictions, and flawed authentication — all of which can reveal the unauthorized or backdoor accounts created by T1136 — but only in the pre-production test environment, not after deployment on live victim systems where the technique is actually used.
- T1136.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments that can surface insecure account-creation paths or backdoors before production, but does not monitor or detect the technique once it runs on a live victim system.
- T1136.003detects — A.8.29 requires vulnerability scanning and penetration testing (plus code review) that can surface insecure configurations, unexpected account-creation functions, or post-creation anomalies when performed in a test or acceptance environment that mirrors production; this is genuine detection of the technique or its artifacts but only a minority slice because the control is scoped to development/testing of new/changed systems rather than ongoing monitoring of production account-creation activity.
- T1137detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which surfaces insecure code, configurations or macros that enable T1137-style Office persistence before production; this is genuine detection but only a slice (pre-deployment, in-house or acquisition-gated components, test-environment fidelity), leaving post-deployment runtime abuse of deployed Office features outside its scope.
- T1137prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configs, code review, vuln scanning, and pen testing) during development and acceptance to catch and block insecure mechanisms like Office add-ins, template macros, or Outlook rules before production, but this only reaches a slice of the technique (in-house/custom Office customizations) while leaving the bulk (pre-existing Office features, third-party add-ins, O365 configs, and post-deployment abuse) untouched.
- T1137.001detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including unanticipated inputs) that surface insecure code/configurations and security flaws in developed or acquired systems; this can catch malicious Office template macro implants during acceptance testing of affected applications or environments, but the control is scoped to development/testing phases rather than runtime detection of the persistence technique post-deployment.
- T1137.001prevents — A.8.29 mandates security testing (including secure coding per 8.28, vulnerability scanning, code review for unanticipated inputs, and penetration testing) during development and acceptance; this catches and stops malicious Office-template macro persistence before production deployment in in-house or acquired components, but only for code written or evaluated under the control — it does not reach already-deployed systems, runtime macro policy, or search-order hijacks outside the tested baseline.
- T1137.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure configurations and code flaws; this can catch the anomalous Registry key or DLL load in test environments matching production, but the control is scoped only to pre-deployment testing of new/changed systems and does not address post-deployment detection of an adversary-added key on live Office installations.
- T1137.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance that can surface insecure custom forms or code-execution templates before production, but does not monitor or detect the post-deployment persistence technique once it is active in a running Outlook instance.
- T1137.004detects — A.8.29 mandates security testing (including vulnerability scanning, code review, and penetration testing) that surfaces insecure code/configurations and defects before production; this can detect the malicious HTML/URL persistence mechanism when it is introduced via in-house or acquired components, but only within the development/testing window and only where the test plan's scope and environment actually exercise the Outlook Home Page feature.
- T1137.004prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components in development and acceptance to catch insecure code/design/configurations before production; this catches the malicious HTML/URL abuse in T1137.004 during in-house or outsourced development but leaves a bounded remainder for post-deployment abuse of already-installed Outlook on compromised endpoints.
- T1137.005detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface insecure configurations or code patterns that enable malicious Outlook rules, but does not monitor or detect the technique at runtime on production systems.
- T1137.006detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance, which can surface malicious or anomalous add-ins (or the insecure configurations/code that enable them) before or at deployment, but does not monitor or detect their use for persistence after deployment on production systems.
- T1137.006prevents — A.8.29 mandates security testing (including secure coding, configurations, code review, vulnerability scanning and penetration testing) during development and acceptance, which can surface and block malicious/persistent add-in patterns before production deployment; this reaches only the slice introduced by in-house or contractually-covered development, not add-ins installed post-compromise or via already-deployed Office.
- T1140detects — A.8.29 mandates vulnerability scanning, penetration testing and code review (including unanticipated inputs) that can surface deobfuscation utilities, malware artifacts or insecure configurations enabling T1140, but only as one slice of broader security testing rather than targeted detection of the technique.
- T1176detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface malicious or insecure extensions (or their behaviors) before or during deployment to production, but this is limited to the pre-production/test phase and does not address post-deployment detection of already-installed malicious extensions on victim systems.
- T1176prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components before production deployment, which can surface and block malicious or insecure extensions during in-house or outsourced development/acquisition, but leaves open post-deployment abuse of benign extensions, manual user installs, compromised marketplaces, and runtime blending that the control does not address.
- T1176.001detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) during development and acceptance to surface insecure code, configurations, and flaws; this can detect malicious or vulnerable browser extensions before deployment to production, but does not address post-deployment installation or runtime abuse of extensions on end-user systems.
- T1176.001prevents — A.8.29 mandates security testing (including secure coding, configurations, vulnerability scanning, code review, and penetration testing) during development and acceptance, which can surface and block malicious or insecure browser extensions before production deployment, but does not address post-deployment installation vectors, social engineering, or file manipulation on running systems.
- T1176.002detects — A.8.29 explicitly requires vulnerability scanning, code review, and penetration testing during development and acceptance, which can surface malicious or abused IDE extensions (especially those introduced via marketplace or side-loading) before production, but this is limited to the pre-deployment testing window and does not address post-install runtime detection of already-trusted extensions on victim systems.
- T1176.002prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components in development and acceptance to validate security requirements and catch insecure code/configurations before production; this directly prevents malicious IDE extensions from being introduced via the development toolchain or acquired components, but leaves open the post-deployment/abuse of already-installed benign extensions and side-loaded extensions outside the tested development process.
- T1185detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review during development and acceptance testing, which surface the browser vulnerabilities and injection vectors that enable T1185 before production deployment.
- T1185prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure-coding checks) during development and acceptance that can surface and block browser-injection or session-hijacking flaws before production, but only for first-party or contractually covered code; it does not stop adversary exploitation of untested third-party browser components or inherent browser functionality on already-deployed systems.
- T1187detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure configurations, insecure code or design that enable forced authentication (e.g. unsafe SMB/WebDAV defaults or untrusted resource loading), but does not mandate runtime/operational detection of the technique once deployed.
- T1189detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which surfaces insecure code/configurations that enable drive-by delivery (e.g. XSS, vulnerable browser plugins, insecure web components) before production; this is genuine but only a slice of the full technique surface (post-deployment watering-hole compromises of live sites are outside its scope).
- T1189prevents — A.8.29 mandates security testing (including secure coding, vulnerability scanning, penetration testing, and code review) during development and acceptance to catch flaws like XSS, insecure configurations, or vulnerable components before production; this directly stops many of the web-site compromise vectors named in T1189 from reaching users, but leaves a bounded remainder (e.g., zero-days, supply-chain compromises of third-party sites or browser plugins, and post-deployment changes) that the control does not address.
- T1190detects — Security testing and vulnerability scanning of new or upgraded systems before deployment reduces the likelihood that publicly exposed applications contain exploitable flaws that adversaries can use for initial access.
- T1190prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure-coding/config/function checks) during development and acceptance, which prevents many classes of exploitable weaknesses (OWASP Top 10, CWE Top 25, misconfigurations) from reaching production Internet-facing hosts; it is only partial because the control is a process whose effectiveness is bounded by test coverage, environment fidelity, and residual defects that still ship.
- T1195detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review during acceptance testing of acquired/outsourced components to surface supply-chain-introduced flaws before production, but this is limited to pre-deployment evaluation of the delivered product rather than ongoing or in-transit detection across all supply-chain stages named in T1195.
- T1195prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and verification of remediation) plus supplier contracts and acceptance testing before acquisition/deployment, which can surface and block many manipulated components or insecure code from supply-chain stages like open-source dependencies, development environments, and updates, but leaves gaps for pre-existing compromises (e.g., factory-infected images, shipment interdiction, or second-order attacks) that testing may not reliably detect.
- T1195.001detects — A.8.29 explicitly requires vulnerability scanning, code review, and penetration testing (including of secure coding, configurations, and dependencies in development/CI-CD pipelines) which surfaces malicious or tampered components before production, but this is scoped only to in-house/outsourced development acceptance testing rather than broadly detecting all pre-receipt supply-chain manipulations of arbitrary third-party dependencies or abandoned packages.
- T1195.001prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing) of new systems, upgrades, dependencies and CI/CD components in a production-like environment before deployment, which can surface and block many manipulated dependencies or malicious development tools from reaching production — but does not stop the upstream compromise itself, nor catch every supply-chain insertion (especially distributed or post-test ones).
- T1195.002detects — A.8.29 requires vulnerability scanning, penetration testing, and code review during development/acceptance testing (including for outsourced/purchased components via supplier evaluation), which can surface supply-chain manipulations like tainted source, updates, or binaries before or at deployment, but this is limited to what the organization's own test environment and criteria catch rather than reliably detecting all pre-consumer upstream compromises.
- T1195.002prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and acquired components before production deployment, which can surface and block manipulated supply-chain software in the acquisition and acceptance path; it does not address upstream source-code or distribution-mechanism manipulation that occurs before the organization receives the artifact.
- T1195.003detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) of acquired/outsourced components and new systems in a production-like test environment, which surfaces some supply-chain hardware/firmware implants that manifest as detectable insecure configurations, vulnerabilities or anomalous behavior; however, many sophisticated hardware backdoors remain difficult to detect per the technique description itself and the control's focus is primarily on functional/security-requirement testing rather than dedicated supply-chain integrity verification.
- T1197detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface insecure configurations, insecure code or design allowing BITS abuse (e.g. via COM/PowerShell interfaces or persistence), but this is limited to pre-deployment discovery in tested systems and does not broadly detect live adversary use of BITS jobs post-deployment.
- T1202detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface indirect command execution patterns (e.g. unsafe use of forfiles, pcalua.exe, ProxyCommand) before production, but this is limited to pre-deployment discovery in tested code and does not address runtime detection of the technique in operation.
- T1203detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which surfaces exploitable client-application vulnerabilities (including those stemming from insecure coding) before production deployment.
- T1203prevents — A.8.29 mandates security testing (including secure coding, vulnerability scanning, code review, and penetration testing) during development and acceptance, which directly surfaces and enables remediation of the unsecure coding practices and resulting vulnerabilities that T1203 exploits before production deployment.
- T1204detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure code, configurations and functions in systems under development or acquisition; this can detect delivery artifacts or execution vectors (e.g. malicious documents, JavaScript, RAT-enabling flaws) before they reach production, but does not observe or surface the live user-action technique itself once deployed.
- T1204.002detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in dev/test environments to surface insecure code/configurations that could enable malicious file execution, but does not monitor or detect the runtime user-action technique itself on production systems.
- T1204.003detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) of new systems, upgrades, images and components before production deployment, which surfaces malicious/backdoored images in test environments that match production; this is genuine detection of the technique but only a slice (pre-deployment testing of selected images, not runtime or post-deployment detection across all deployed instances).
- T1204.003prevents — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, code review, and secure configuration checks) of new systems, upgrades, images, and components before production deployment, which would surface many backdoored or malicious images in dev/test environments matching production, thereby preventing the technique from succeeding in most cases; however, it is only a slice because it does not address public-repo supply-chain uploads, user naming tricks, or post-acquisition runtime execution of untested third-party images.
- T1204.005detects — A.8.29 explicitly requires vulnerability scanning, code review, and penetration testing (including of dependencies and secure configurations) that can surface malicious libraries supplied via package managers or repos, but this is scoped only to in-house/acceptance testing of systems being deployed rather than ongoing detection of user-installed malicious libraries in production environments.
- T1204.005prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure coding/config checks) during development and acceptance that can surface malicious or backdoored libraries before production deployment, but it is scoped to in-house and acquired components under contract and does not stop users from later installing unvetted third-party libraries via package managers or public repos.
- T1205detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that can surface traffic-signaling backdoors or hidden functionality during development and acceptance, but only for in-house or acquired code/components that reach testing; it does not detect the technique at runtime or in production systems.
- T1205.001detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that can surface port-knocking implementations or the insecure firewall/custom-software configurations enabling them during development or acceptance, but this is limited to pre-deployment testing of in-scope systems and does not broadly detect the technique at runtime or in production.
- T1205.002detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface the presence of a socket filter or its triggering behavior in tested code or running systems, but only where that code is part of in-house or acquired development under test; the technique's stealth, low activity, and raw-socket nature leave substantial detection gaps outside the development window.
- T1207detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface the insecure configurations, privilege escalations, or anomalous AD objects/schema changes involved in registering a rogue DC, but only as part of pre-deployment or acceptance testing of systems/components rather than runtime/operational detection of the live technique.
- T1210detects — Pre-deployment penetration testing and configuration validation of remote services and components reduces the chance that lateral-movement paths remain open due to unpatched or misconfigured services.
- T1210prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure-coding/config/function checks) during development and acceptance, which catches many exploitable vulnerabilities in remote services before they reach production and thereby prevents the T1210 technique from being available post-deployment.
- T1211detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that surfaces exploitable flaws in code, configurations, and components whose abuse would enable stealth/evasion techniques such as T1211; this is discovery before deployment, with the named remainder being post-deployment or unknown/zero-day flaws that escape the test regimen.
- T1211prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) during development and acceptance to catch and remediate flaws before production, which would prevent many exploitable vulnerabilities that T1211 relies on (especially in custom code, configs, or components under organizational control); it is only partial because the control is scoped to tested in-house or acquired systems, does not reach all possible stealth-exploitable flaws (e.g., in untested third-party SaaS/cloud infrastructure or post-deployment vulns), and the extent of testing is risk-proportional rather than exhaustive.
- T1212detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review (including for insecure code/design and unanticipated inputs) in development and acceptance testing, which surfaces exploitable credential-related vulnerabilities before production.
- T1212prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure-coding checks) during development and acceptance, which catches many exploitable flaws in credentialing/auth mechanisms before production; this prevents the technique for defects that would have shipped, but leaves a genuine remainder (0-days, post-deployment vulns, and flaws outside the tested scope or test environment fidelity).
- T1216detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that can surface the presence of vulnerable signed scripts or LOLBAS proxies in test environments before production, but does not require ongoing runtime detection of their abuse as a technique.
- T1216prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configurations, code review, vulnerability scanning and penetration testing) that can surface and block introduction of script-proxy weaknesses or insecure defaults enabling T1216, but only as one slice of the development process with no guarantee the specific bypass vectors are exercised or removed.
- T1216.001detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in a production-like environment, all of which surface the abuse of a signed living-off-the-land binary such as PubPrn.vbs for remote scriptlet execution.
- T1216.001prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure coding/config checks) during development and acceptance, which can surface and block insecure code or design that would enable PubPrn abuse before production; this is a genuine but minority slice of the technique's surface because the control is a process that depends on implementation rigor and does not itself remove the signed living-off-the-land binary or enforce runtime restrictions.
- T1216.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface this signed-script abuse pattern when it appears in tested code, configs or deployed components; the control stops at discovery and does not itself act on runtime execution.
- T1218detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface proxy-execution flaws (e.g. unsafe use of signed binaries or insecure configurations enabling LOLBAS), but does not require runtime or operational detection of the technique once deployed.
- T1218.001detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure code, design, and configurations in developed or acquired components; this can detect the presence of a malicious or vulnerable CHM that would enable T1218.001, but only for first-party or supplier-evaluated artifacts in the SDLC, not for arbitrary delivered CHM files post-deployment.
- T1218.002detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface malicious or anomalous Control Panel item behavior (e.g. via suspicious .cpl loading or registry patterns) in tested code or components, but only within the tested scope and environment, not production runtime or untested adversary activity.
- T1218.003detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in a production-like test environment, which surfaces CMSTP abuse (as anomalous/malicious INF-driven execution or signed-binary bypass) when exercised during development or acceptance testing of affected components.
- T1218.003prevents — A.8.29 mandates security testing (including secure coding, configurations, vulnerability scanning, code review and penetration testing) during development and acceptance, which can surface and block CMSTP-abusing code or insecure configurations before production, but does not guarantee prevention of all such technique implementations (especially in third-party or post-deployment scenarios).
- T1218.004detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface InstallUtil abuse when it appears in tested code or deployed systems, but the control is scoped to development/acceptance testing of new or changed systems rather than ongoing production monitoring of adversary technique execution.
- T1218.005detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure code, configurations and flaws (including those enabling proxy execution via trusted binaries like mshta), but does not require or perform runtime/operational detection of the technique once deployed in production.
- T1218.005prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configs, vulnerability scanning, code review, and penetration testing) during development and acceptance to catch flaws before production; this can surface or block insecure allowance of mshta.exe abuse in custom apps or configs, but does not address adversary abuse of the built-in trusted binary on production Windows systems or third-party/outsourced components where the technique is already present.
- T1218.007detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance that can surface abuse of signed binaries like msiexec (e.g. via insecure configs, unexpected execution paths or policy settings), but this is limited to pre-deployment testing of in-house or acquired components and does not broadly detect the technique at runtime or in production environments.
- T1218.008detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface the presence or abuse of living-off-the-land binaries such as odbcconf.exe when those activities are performed against in-scope systems or code, but the control is scoped to development and acceptance testing rather than continuous production monitoring and does not guarantee detection of every possible proxy-execution variant.
- T1218.009detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure code, design, and configurations; these can detect the malicious attribute usage or anomalous proxy execution in developed/outsourced components, but only as part of pre-deployment testing rather than runtime or post-compromise detection of the technique.
- T1218.010detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface insecure code/design enabling Regsvr32 abuse (e.g. via improper allowlisting or COM handling), but does not monitor or detect the technique at runtime in production.
- T1218.011detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure code, design and configurations; these can surface some T1218.011 abuse patterns (e.g. malicious DLLs, masquerading, script proxies) when exercised against representative test environments, but miss many post-deployment, runtime or environment-specific variants.
- T1218.012detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure code, design and configurations; these can surface the insecure COM/CLSID registration or proxy-abuse pattern if it is present in the tested codebase or components, but the control is scoped to pre-production testing and does not require ongoing runtime detection of the technique once deployed.
- T1218.013detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface mavinject.exe abuse (or the resulting DLL/import injection) when the technique appears in tested code, configurations or running test environments; this is limited to the development/testing slice rather than production runtime detection.
- T1218.014detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface insecure configurations, insecure code and design flaws enabling MMC abuse (e.g. malicious .msc/CLSID registration), but only in pre-production and only where the test plan chooses to cover it; it does not monitor or detect the technique at runtime on production systems.
- T1218.015detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure code, design and configurations; these can detect Electron-specific abuse patterns (e.g. malicious JS injection, unsafe command-line flags or sandbox bypasses) before production, but the control is scoped only to pre-deployment testing of the organization's own or acquired applications and does not instrument or detect the technique at runtime in deployed Electron apps.
- T1218.015prevents — A.8.29 mandates security testing (including secure coding per 8.28, code review, vulnerability scanning, and penetration testing) during development and acceptance, which can surface and block insecure Electron configurations or malicious JS planting before production, but does not guarantee prevention of all abuse vectors in third-party Electron apps or runtime command execution.
- T1219detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface RATs or their installation artifacts when they are introduced as part of new/updated code or components, but does not monitor or detect live post-compromise use of legitimate remote access tools in production.
- T1219.001detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface IDE tunneling as an insecure configuration, unauthorized remote access mechanism, or anomalous extension, but only for tested in-house or acquired components in a pre-production environment — not for live post-deployment adversary use of built-in IDE features on production systems.
- T1219.002detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface insecure configurations, remote access features, or unexpected remote desktop capabilities before production, but does not monitor or detect live adversary use of such tools post-deployment.
- T1220detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review (including for unanticipated inputs) plus automated tools such as vulnerability scanners; these surface the insecure code, design, or configuration that enables T1220 (XSL script abuse for bypass/execution) before or during acceptance, though post-deployment runtime detection is outside its scope.
- T1220prevents — A.8.29 mandates security testing (including secure coding per 8.28, vulnerability scanning, code review, and penetration testing) during development and acceptance, which can surface and block XSL script-processing bypasses before production; this is a genuine but minority slice of the technique's surface because the control is scoped to tested in-house or acquired components rather than all possible abuse vectors or post-deployment use.
- T1221detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including unanticipated inputs) in development and acceptance testing, which surfaces template injection flaws in custom or acquired code/documents before production; this is a genuine but minority slice of the technique (limited to tested in-house/outsourced artifacts, not post-deployment documents or runtime evasion).
- T1221prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of applications and components in development and acceptance, which surfaces and can stop template-injection flaws before production deployment; this is a genuine but minority slice of the technique because the control only governs first-party/in-house or explicitly contracted development and does not constrain adversary-crafted malicious documents delivered via phishing or tainted content to end-user environments.
- T1222detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface permission-modification flaws or insecure ACLs before production, but does not monitor or detect the T1222 technique once adversaries execute it at runtime on deployed systems.
- T1222.001detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development/acceptance that can surface insecure permissions or ACL misconfigurations before production, but does not monitor or detect the live technique once adversaries run icacls/takeown/etc. post-deployment.
- T1222.001prevents — A.8.29 mandates security testing (including secure configurations, secure coding, vulnerability scanning, code review and penetration testing) that can surface and block insecure permission-related code or configs before production, but does not stop an adversary already present from using icacls/takeown/etc. at runtime to modify DACLs.
- T1222.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance that can surface insecure permission-related code or configs (e.g. via secure-configuration testing), but does not instrument or monitor running Linux/macOS systems for live adversarial use of chown/chmod to evade ACLs.
- T1480detects — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) that can surface guardrail logic or environment-specific checks as part of identifying insecure code/design or unexpected behaviors, but this is not its purpose and only catches a minority slice of T1480 implementations.
- T1480.001detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/acceptance that can surface environmental keying artifacts (e.g. unusual crypto usage, target-specific checks, or guardrail logic) when they appear in reviewed code or test environments, but the control is scoped only to pre-production testing of in-house or acquired systems and does not address runtime detection of deployed malware employing this technique.
- T1480.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface mutex-based instance checks as anomalous code/behaviour or insecure design during development acceptance, but this is limited to tested in-house or acquired components and does not broadly detect the technique at runtime or in production.
- T1482detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that can surface reconnaissance behaviors such as domain trust enumeration when performed in test or acceptance environments that mirror production, but this is limited to pre-deployment testing of systems/components rather than runtime detection of the live adversary technique.
- T1484detects — A.8.29 requires vulnerability scanning and penetration testing (plus code review) of systems/components in dev/acceptance to surface insecure configurations and design flaws; this can detect some T1484-enabling policy misconfigurations or weak trust settings before production, but only a minority slice of the technique (pre-modification testing of deployed policy objects or federation setups) and nothing of post-deployment or runtime abuse.
- T1484.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure configurations, code and design flaws; these can discover malicious or anomalous GPO settings before production but only for changes introduced through the tested development or acquisition pipeline, not for post-deployment runtime GPO abuse by an already-privileged adversary.
- T1484.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance that can surface misconfigurations or insecure trust setups before production, but does not monitor or detect the live technique once adversaries are already manipulating trusts in a running identity provider or domain.
- T1485detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance, which can surface data-destruction primitives (e.g. dangerous delete/overwrite routines, missing integrity checks) before deployment, but does not monitor or detect the live technique on production systems.
- T1489detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that can surface insecure configurations, weak access controls, or missing protections around service management before production, thereby detecting some T1489 vectors; it does not instrument or monitor running systems for the technique itself.
- T1490detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure configurations, missing recovery features or destructive patterns before production, but does not monitor or detect the live T1490 technique once adversaries execute it post-deployment.
- T1491detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure code, configurations and design flaws before production; this can detect the specific conditions (e.g. weak auth, missing access controls or insecure configs on web assets) that enable T1491, but does not broadly detect the post-deployment technique itself.
- T1491.001detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface insecure configurations, code, or design that would enable internal defacement (e.g. weak auth, improper access controls, or modifiable web resources), but does not monitor or detect the post-deployment technique in operation.
- T1491.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface the insecure code or configuration that enables external defacement (e.g. weak auth, missing input sanitization, or exposed admin interfaces), but does not monitor or detect the defacement technique once it is executed in production.
- T1495detects — A.8.29 mandates vulnerability scanning, penetration testing and code review (including in test environments matching production) that can surface firmware corruption or insecure firmware configurations as part of acceptance/security testing, but this is limited to pre-deployment or in-house/outsourced evaluation and does not broadly detect post-deployment adversary execution of T1495.
- T1496detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface resource-hijacking indicators (e.g. unexpected compute usage, anomalous network calls, insecure configurations enabling cryptomining) before production; this is genuine but only a minority slice because the control is scoped to pre-deployment testing of new/changed systems and does not address runtime detection of hijacking on already-deployed production assets.
- T1496.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface insecure configurations, exposed APIs or weak access controls that enable compute hijacking (e.g. exposed Docker, weak IAM), but does not require runtime detection of the technique once deployed.
- T1496.002detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/testing that can surface malware or insecure code enabling bandwidth hijacking (e.g. botnet implants or proxyware), but this is limited to pre-deployment discovery in tested systems and does not address post-deployment runtime detection of the technique.
- T1496.003detects — A.8.29 requires security testing (including vulnerability scanning and penetration testing) that can surface anomalous SMS-pumping behavior or insecure form/OTP endpoints during development and acceptance, but only for in-house or acquired components that reach testing; it does not mandate runtime or production monitoring of live SMS traffic or costs.
- T1496.004detects — A.8.29 requires security testing (including vulnerability scanning and penetration testing) of applications/code before production deployment, which can surface insecure configurations, weak access controls, or other flaws that would enable SaaS hijacking, but does not monitor or detect the live technique once adversaries are already leveraging a compromised SaaS service.
- T1497detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in a test environment that matches production, which surfaces many VME/sandbox artifacts and evasion behaviors during development/acceptance testing of in-house or acquired components.
- T1497.001detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure configurations, code and design flaws in developed or acquired systems; this can discover many common VME/Sandbox artifacts and checks (especially those tied to insecure configs or detectable via pen-testing in a near-production test environment), but does not address the runtime adversary technique itself once malware is already on a victim endpoint.
- T1498detects — A.8.29 requires vulnerability scanning, penetration testing and security testing (including of secure configurations and network-facing components) that can surface some Network DoS vectors such as exposed bandwidth-exhaustible services or weak boundary protections, but does not mandate ongoing detection of the technique in flight or of the volumetric traffic itself.
- T1498.001detects — A.8.29 mandates vulnerability scanning, penetration testing and security testing (including of secure configurations and network-facing components) that can surface the ability of a system or network to withstand or reveal a direct network flood, but this is limited to pre-deployment testing in a test environment rather than runtime detection of the live technique.
- T1498.002detects — A.8.29 mandates vulnerability scanning and penetration testing (plus code review) that can surface misconfigurations or insecure services enabling reflection/amplification (e.g. exposed NTP/DNS/memcache responders), but this is limited to pre-deployment testing of the organization's own systems rather than runtime detection of the attack in flight.
- T1499detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface security flaws (including those that could lead to resource exhaustion or crashes), but this is limited to pre-deployment testing of in-house or acquired systems and does not address runtime or post-deployment detection of live T1499 attacks.
- T1499prevents — Security testing (including vulnerability scanning, penetration testing, code review, and secure configuration checks) during development and acceptance can identify and eliminate many endpoint DoS vectors before production deployment, but leaves open those arising from runtime resource exhaustion, botnets, spoofing, or post-deployment changes.
- T1499.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface OS-exhaustion weaknesses (e.g. missing SYN cookies, connection limits or state-table tuning) before production; this is genuine detection of the flaw class but only a minority slice because the control stops at pre-deployment testing and has no view of runtime detection of an in-flight T1499.001 flood against a live endpoint.
- T1499.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface DoS-exposing flaws (e.g. missing rate limits, SSL renegotiation enabled, insecure configs) before production; this is genuine but only a slice because the control is scoped to pre-deployment testing of the organization's own or acquired systems, not ongoing detection of the live T1499.002 technique against production services.
- T1499.002prevents — A.8.29 mandates security testing (including secure configs, secure coding, vulnerability scanning, and penetration testing) during development and acceptance, which can surface and help eliminate DoS-exposing flaws such as missing rate limits, insecure SSL renegotiation settings, or resource-unbounded HTTP handling before production; this prevents some but not most instances of the technique, which also arises from runtime volumetric floods, network-layer exhaustion, and post-deployment configuration drift outside the development testing scope.
- T1499.003detects — A.8.29 mandates vulnerability scanning, penetration testing and security testing (including of secure configurations and functions) that can surface application resource-exhaustion vectors before or after deployment, but does not require runtime monitoring or anomaly detection of live flood attempts against those features.
- T1499.003prevents — A.8.29 mandates security testing (including secure coding, configurations, vulnerability scanning, and penetration testing) during development and acceptance to validate requirements and catch flaws before production; this can surface and block resource-exhaustion DoS vectors in application features, but only for in-scope, tested code paths and does not guarantee prevention of all such adversarial requests or untested conditions.
- T1499.004detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review (including for insecure code/design and unanticipated inputs) that surface exploitable vulnerabilities before production, directly detecting the class of flaws adversaries would weaponize for T1499.004; mostly because it is scoped to pre-deployment testing of new/changed systems rather than runtime detection of in-the-wild exploitation.
- T1499.004prevents — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, code review, and secure-coding/config/function checks) during development and acceptance, which surfaces and enables remediation of exploitable crash vulnerabilities before production, thereby preventing the technique from being available to run; extent is partial because the control is scoped to tested changes/systems, does not guarantee discovery of all (esp. zero-day) flaws, and relies on test-environment fidelity and post-test remediation rather than a universal barrier.
- T1505detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface malicious or anomalous server components before or (in limited ongoing cases) after deployment, but does not require or perform runtime detection of abuse in production.
- T1505prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure coding/config checks) during development and acceptance, which can surface and block malicious or vulnerable server extension components before production deployment, but does not guarantee prevention of all adversary-installed extensions (especially post-deployment, in outsourced code without rigorous enforcement, or novel abuse of legitimate extensibility).
- T1505.001detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review (including for insecure code/design and unanticipated inputs) that surface malicious or anomalous stored procedures and CLR assemblies before or during deployment to production.
- T1505.001prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure coding/config checks) during development and acceptance that would surface malicious or vulnerable stored procedures before production, but does not guarantee their prevention as it is a testing process whose effectiveness depends on test coverage, remediation follow-through, and applicability to outsourced/third-party components.
- T1505.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure code, design and configurations; this can detect malicious or anomalous transport-agent implementations before deployment, but the control is scoped only to pre-production testing of in-house or acquired components and does not address post-deployment runtime detection of a registered malicious agent on a live Exchange server.
- T1505.003detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development and acceptance testing, which surfaces web shell indicators (insecure code, backdoors, anomalous server scripts) before or at deployment to production.
- T1505.003prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) during development and acceptance that surfaces and enables remediation of web-shell-class backdoors before production, but does not guarantee their absence in all outsourced, legacy, or post-deployment code.
- T1505.004detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) during development, acceptance and before acquisition, which surfaces malicious or vulnerable IIS components before they reach production; this is genuine detection of the technique but only a minority slice because the control is scoped to pre-deployment testing of new/changed systems rather than runtime or post-deployment detection on live IIS servers.
- T1505.004prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components in development and acceptance to catch insecure code/configurations before production; this directly prevents malicious IIS components from being introduced via in-house or acquired software, but only for changes that fall under the tested SDLC slice rather than post-deployment or untested legacy IIS extensions.
- T1505.005detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure code, design, and configurations in development and acceptance; this would detect many (but not all) malicious modifications or replacements of termsrv.dll before production deployment.
- T1505.006detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development/acceptance to surface insecure code, configurations, and flaws (including in acquired components via supplier contracts), which can detect malicious VIBs or their masquerading before deployment; this is only a slice of the full technique because it is scoped to pre-production testing of new/changed systems rather than runtime detection on live ESXi hosts.
- T1525detects — Independent acceptance testing and vulnerability scanning of new or upgraded systems detect malicious implants or backdoors introduced during development or supply-chain stages.
- T1525prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components before production deployment, which would surface malicious implants/backdoors in images during acceptance or acquisition testing; however, it is silent on runtime image registries, post-deployment pulls, or infrastructure-as-code that bypasses the tested baseline, leaving a large named remainder of the technique unaddressed.
- T1528detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface insecure token handling, OAuth misconfigurations, or related flaws before production, but does not monitor or detect the live technique (token theft) once deployed in runtime/container/CI-CD environments.
- T1528prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configs, code review, vuln scanning, and pen testing) during development and acceptance to catch flaws before production; this can surface token-handling weaknesses (e.g. insecure storage, improper OAuth flows, or CI/CD exposure) that would otherwise enable T1528, but leaves social-engineering, post-compromise container/VM theft, and runtime token misuse outside its scope.
- T1529detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that can surface insecure configurations, privilege issues or unsafe APIs that enable T1529, but does not require or guarantee detection of the technique in operation or of the shutdown/reboot artifacts themselves.
- T1530detects — A.8.29 mandates vulnerability scanning and penetration testing (plus code review) that can surface misconfigured cloud storage buckets, exposed objects, or insecure IAM in test or pre-prod environments that mirror production, but does not monitor or detect the live adversary access technique itself once deployed.
- T1531detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review that can surface account-manipulation flaws or insecure configurations enabling T1531, but only during pre-deployment testing of new/changed systems, not in production where the technique is actually executed.
- T1534detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure code, configurations and authentication weaknesses which are the root causes enabling internal spearphishing campaigns; this is genuine but only a slice because the control is scoped to pre-deployment testing of new/changed systems rather than runtime detection of live internal phishing activity.
- T1537detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that can surface insecure configurations, access controls, or design flaws enabling intra-cloud data transfers, but this is limited to pre-deployment testing of systems/components rather than runtime detection of the live T1537 technique.
- T1538detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that surfaces insecure configurations, insecure code, and missing security functions; this can detect the dashboard's exposure of enumerable assets/ports/findings when those are treated as insecure configuration or missing access restriction, but the technique itself is post-authentication GUI use of valid credentials and is not the primary target of development-time testing.
- T1539detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance to surface security flaws (including insecure auth, configs and code that enable session cookie theft vectors like XSS, insecure storage or weak MFA bypasses), but this is limited to pre-production testing of in-house or acquired systems and does not broadly detect the post-deployment technique in operation.
- T1539prevents — A.8.29 mandates security testing (including secure coding, secure configs, code review, vuln scanning, and pen testing) during development and acceptance to validate that security requirements are met before production deployment; this can prevent classes of session-cookie theft that originate in insecure web-app code or configs (e.g. missing HttpOnly/Secure flags, XSS vectors, or weak auth functions), but leaves the post-deployment malware, phishing, and network-stealing vectors untouched.
- T1542detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface insecure firmware/BIOS/UEFI configurations or boot-time code flaws before production, but these occur only in the development/test environment and do not monitor or detect live Pre-OS Boot abuse on deployed systems.
- T1542.001detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface insecure firmware configurations or modification artifacts during development/acceptance testing of systems and components, but this is limited to pre-production evaluation of in-scope new or changed systems rather than runtime detection of post-deployment firmware modification on production platforms.
- T1542.002detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface malicious or anomalous firmware modifications in components during development, acceptance, and pre-deployment testing; this is genuine detection but only a minority slice of the post-deployment, in-the-wild persistence technique described in T1542.002.
- T1542.002prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure configuration checks) during development and acceptance that can surface or block insecure firmware update mechanisms, weak integrity checks, or vulnerable component code before production, but does not reach sophisticated post-deployment or supply-chain firmware modification attacks on deployed components.
- T1542.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review (including in pre-production environments that match production) which can surface bootkit indicators such as anomalous MBR/VBR/ESP modifications or insecure boot configurations, but only for changes introduced during development, upgrades or acquisitions — not for live post-deployment bootkits on running production systems.
- T1542.004detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure code, configurations and firmware issues before production; this can detect adversary ROMMON modification attempts or indicators in tested images, but only for in-house or evaluated supplier components and only pre-deployment, leaving post-deployment runtime detection on live network devices outside its scope.
- T1542.005detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) of systems/components in development and acceptance, which surfaces insecure boot configurations, unauthorized TFTP usage, or modified images on network devices before production; this is genuine detection but only a slice because the control is scoped to pre-deployment testing of new/upgraded systems rather than runtime or continuous detection of the live technique on deployed devices.
- T1543detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review that can surface malicious or anomalous system process creations/modifications (especially during development, acceptance, and configuration testing), but this is limited to pre-production testing in a matched environment and does not broadly detect post-deployment runtime adversary use of the technique.
- T1543.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure configurations and code that could enable launch-agent persistence techniques; this is genuine detection of the weakness before production but only a slice (pre-deployment testing of in-house or acquired components, not runtime detection of deployed agents).
- T1543.002detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) of new/changed systems in a production-like environment, which surfaces malicious or anomalous systemd .service files and generators as insecure configurations or code; this is genuine detection of the technique post-deployment but only a slice, as the control is scoped to development/acceptance testing of new or upgraded systems rather than continuous monitoring of production services.
- T1543.002prevents — A.8.29 mandates security testing (including secure configurations, secure coding, vulnerability scanning, code review and penetration testing) of new systems, upgrades and components before production deployment, which can surface and block malicious or insecure systemd service files introduced during in-house or outsourced development; this is only a slice of the technique because it does not constrain post-deployment creation or modification of services by an already-present adversary.
- T1543.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure code, configurations and flaws (including those enabling malicious service creation/modification), but does not address runtime or post-deployment detection of adversary T1543.003 activity on production Windows systems.
- T1543.003prevents — A.8.29 mandates security testing (including secure configurations, secure coding, vulnerability scanning, code review and penetration testing) of new systems/upgrades before production deployment, which can surface and block malicious or insecure service creation/modification in developed or acquired components, but does not constrain post-deployment adversary actions on a running Windows system.
- T1543.004detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface malicious or anomalous Launch Daemon plists, insecure configurations, and unexpected startup behaviors in test or acceptance environments, but this is limited to pre-deployment testing rather than runtime detection on production systems and does not cover all variants (e.g., post-deployment hijacks of existing plists).
- T1543.005detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure configurations, insecure code and system vulnerabilities; this can detect some T1543.005 artifacts (e.g. a malicious DaemonSet, restart=always container, or modified kubelet) if they are introduced or present in tested code/images, but does not monitor or surface the technique at runtime on production hosts.
- T1543.005prevents — A.8.29 mandates security testing (including secure configurations, secure coding, vulnerability scanning, code review and penetration testing) of new systems, upgrades and components before production deployment, which can surface and block insecure container service configurations or modifications that enable T1543.005; this is a genuine but minority slice because the control is scoped only to pre-deployment testing of new/changed artifacts and does not constrain post-deployment adversary modification of running container services on production hosts.
- T1546detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review that can surface malicious or anomalous event-trigger mechanisms (e.g. via insecure code/config or post-deployment vuln scanning), but only as one slice of broader security testing rather than continuous or dedicated detection of the live technique.
- T1546prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components before production deployment, which can surface and block malicious or insecure event-trigger mechanisms introduced during development or acquisition, but does not stop post-compromise abuse of legitimate ones by an already-present adversary.
- T1546.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure configurations and code that could enable registry-based persistence like T1546.001; this surfaces the weakness before production but does not guarantee detection of post-deployment adversary use of the technique.
- T1546.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure configurations and code that could enable T1546.002-style registry and binary abuse; this surfaces the technique in tested systems but does not cover production runtime detection or all deployment paths.
- T1546.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface malicious or anomalous WMI event subscriptions when performed in dev/test or on production-like environments, but does not require ongoing runtime monitoring of WMI activity and the control's scope is limited to acceptance testing rather than production detection.
- T1546.004detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations and code that could enable shell config modification persistence; this is a genuine but minority slice of the broad technique (most real-world instances are post-deployment and not caught in dev/acceptance testing of new systems/upgrades).
- T1546.004prevents — A.8.29 mandates security testing (including secure coding review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components before production deployment, which can surface and block malicious shell config modifications introduced during development or acquisition, but does not address post-deployment runtime changes to shell configs by adversaries.
- T1546.005detects — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) that can surface trap-based persistence mechanisms when they are introduced in in-house or acquired code/scripts during development and acceptance, but this is limited to pre-deployment testing of known patterns rather than runtime detection of the technique in operation.
- T1546.006detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance that can surface tainted Mach-O binaries or unexpected LC_LOAD_DYLIB entries before production, but does not require or perform ongoing runtime detection of the persistence technique after deployment.
- T1546.007detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface malicious or anomalous Netsh Helper DLL registrations before production, but only for in-house or evaluated outsourced code changes, not for post-deployment adversary activity on live systems.
- T1546.008detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations, insecure code, and design flaws in development and acceptance; these can catch many of the binary-replacement, registry, and debugger-injection patterns that realize T1546.008, but only for in-house or evaluated supplier code — not for post-deployment adversary abuse of production accessibility features.
- T1546.008prevents — A.8.29 mandates security testing (including secure coding, configurations, vulnerability scanning, code review and penetration testing) during development and acceptance that would surface and block many of the binary-replacement, registry-pointer and insecure-configuration changes that enable T1546.008; it does not reach every possible implementation vector or post-deployment change, leaving a genuine minority slice unaddressed.
- T1546.009detects — A.8.29 mandates vulnerability scanning, penetration testing and code review (including in test environments matching production) that can surface the malicious AppCert DLL Registry value or anomalous loading behavior, but this is scoped only to development, acceptance and acquisition testing of new/changed systems rather than ongoing runtime detection across deployed production processes.
- T1546.009prevents — A.8.29 mandates security testing (including secure coding, configurations, code review, vulnerability scanning and penetration testing) during development and acceptance, which can surface and block insecure AppCert DLL registration or loading logic before production, but does not guarantee prevention of the runtime abuse vector itself.
- T1546.010detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure configurations, code and design flaws; this can detect the presence of a malicious AppInit_DLLs Registry value or the resulting loaded DLL during testing, but only for in-house or evaluated acquired components and only before deployment, leaving post-deployment runtime use on production systems outside its scope.
- T1546.010prevents — A.8.29 mandates security testing (including secure coding, configurations, code review, vulnerability scanning and penetration testing) during development and acceptance, which can surface and block insecure AppInit_DLLs registry settings or related code before production deployment on Windows systems that still support the mechanism.
- T1546.011detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface shim abuse (e.g. as insecure code, unexpected hooking behaviour or privilege-escalation vectors) before or at deployment; this is genuine but only a slice because the control is scoped to pre-production testing of new/changed systems rather than runtime detection of shim abuse in already-deployed production environments.
- T1546.011prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configurations, code review, vulnerability scanning, and penetration testing) during development and acceptance to validate requirements and catch flaws before production; this catches and stops many shim-abuse vectors (e.g. malicious custom .sdb, insecure hooks, or privilege-elevation shims) but leaves a genuine remainder for post-deployment shim installation, admin-privileged abuse of built-in shims, or untested legacy components.
- T1546.012detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface IFEO registry abuse, insecure debuggers, or related misconfigurations during development and acceptance, but only for tested code/components in a test environment and not for live post-deployment adversary activity on production systems.
- T1546.013detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface malicious or anomalous PowerShell profile content (as insecure code/configuration) before or during deployment to production; this is limited to the development/testing phase and does not address post-deployment runtime detection of profile modifications.
- T1546.014detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure configurations, code and design flaws; this can detect emond rule abuse or misconfigurations that enable the technique in tested systems, but only for in-scope, in-house or evaluated components and not for live post-deployment abuse on production macOS endpoints.
- T1546.015detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review in development/acceptance testing (including secure configurations and secure coding), which surfaces COM hijacking Registry changes, insecure TypeLib references, or anomalous code before or during deployment to production.
- T1546.015prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components in development and acceptance to catch insecure configurations, secure coding violations, and other flaws before production; this would surface many COM hijacking Registry and code changes if they are introduced during in-house or outsourced development, but does not stop an already-deployed or runtime Registry modification by an adversary after acceptance.
- T1546.016detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review during development and acceptance testing, which surfaces malicious or anomalous installer scripts and post-install content before production deployment.
- T1546.016prevents — A.8.29 mandates security testing (including secure coding, vulnerability scanning, penetration testing, and code review) of new systems/upgrades/installers in dev and acceptance, which can surface and block malicious or vulnerable installer scripts before production; this is genuine but only a slice because the control is scoped to tested in-house or acquired components under contract, does not reach adversary modification of legitimate third-party installers post-acquisition or during user-driven install, and testing cannot guarantee discovery of every crafted postinst/preinst abuse.
- T1546.017detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface udev rule abuse as an insecure configuration or design flaw during acceptance testing, but only for in-house or acquired components that reach the defined test phase and environment; it does not continuously or broadly detect the technique post-deployment or in live production systems.
- T1546.018detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including for unanticipated inputs/conditions) in development and acceptance testing, which surfaces Python startup hook abuse as insecure code, configuration or vulnerability before or at deployment.
- T1546.018prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components before production deployment, which can surface and block malicious Python startup hooks introduced during development or acquisition, but does not stop an adversary from later adding them to a running production environment where Python is present.
- T1547detects — A.8.29 requires vulnerability scanning, penetration testing and code review (including of secure configurations and secure coding) that can surface misconfigurations or malicious autostart mechanisms after they are introduced, but this is scoped only to development, acceptance and pre-deployment testing of new/changed systems rather than ongoing detection on production systems where the T1547 technique is typically realized.
- T1547.001detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface malicious or anomalous persistence entries in registry run keys and startup folders when performed on developed or acquired systems/configurations.
- T1547.001prevents — A.8.29 mandates security testing (including secure configurations, secure coding, vulnerability scanning, code review and penetration testing) during development and acceptance; this catches many improper persistence entries before they reach production, but does not stop an adversary from adding a run-key or startup-folder entry post-deployment or on an already-deployed system.
- T1547.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review (including in test environments) that can surface insecure configurations or code enabling registry-based LSA authentication package abuse, but does not require ongoing runtime/operational monitoring of the live production LSA process or registry to detect the technique once deployed.
- T1547.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface a malicious time-provider DLL registered for boot-time execution, but only when the test environment and test plan happen to exercise the W32Time registry path and the technique is already present in the tested build or component
- T1547.003prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components before production deployment, which can surface and block malicious time-provider DLL registration during development or acquisition but does not stop post-deployment abuse of this boot-time persistence mechanism on live Windows systems.
- T1547.004detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/testing that can surface insecure configurations or code enabling Winlogon abuse (e.g. malicious registry changes), but this is limited to pre-deployment checks in a test environment and does not broadly detect post-deployment runtime abuse or persistence.
- T1547.004prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components in development and acceptance to catch insecure configurations and code before production; this can surface malicious or vulnerable Winlogon registry modifications in tested software but does not stop the technique in already-deployed systems, third-party components outside the test scope, or runtime abuse of legitimate features.
- T1547.005detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface insecure configurations or code enabling SSP abuse, but this is scoped to pre-deployment testing of new/changed systems rather than runtime detection of the post-boot technique on production systems.
- T1547.006detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure code, design and configurations; this can detect malicious LKM/kext patterns or rootkit-like kernel modifications before production, but only for in-house or evaluated supplier code and only at test time, leaving deployed runtime kernel tampering on Linux/macOS largely unreached.
- T1547.006prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure coding/config checks) during development and acceptance to catch flaws before production; this can surface malicious or vulnerable LKM/kext loading mechanisms in in-house or acquired components, but does not stop adversaries from introducing or exploiting them post-deployment on Linux/macOS kernels.
- T1547.007detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface the plist modification as an insecure configuration or code/design flaw during development/acceptance, but this is limited to pre-production testing of in-house or acquired systems rather than runtime detection of the live technique on deployed macOS endpoints.
- T1547.008detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including for insecure code/design) in development and acceptance testing, which surfaces LSASS driver modification/persistence techniques when they appear in tested in-house or acquired components; this is limited to pre-production discovery rather than runtime detection on deployed systems.
- T1547.009detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface malicious or anomalous shortcuts placed in startup locations or masquerading as legitimate, but only as part of pre-deployment or acceptance testing of new/changed systems rather than ongoing detection of post-compromise adversary activity.
- T1547.010detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface the anomalous port monitor DLL or registry entry after it is present, but only where those tests are scoped to cover boot-time persistence mechanisms rather than functional requirements.
- T1547.012detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure configurations, insecure code and system vulnerabilities; these can discover a malicious print processor registration or anomalous boot-loaded DLL, but only for in-house or tested components and only before or at deployment, leaving post-deployment runtime instances on production systems outside its scope.
- T1547.012prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components in development and acceptance to catch insecure code/configurations before production; this can surface the malicious print-processor registration or DLL-loading logic if exercised in test, but the technique is a post-deployment boot-time abuse of a legitimate Windows component that testing does not stop from being introduced later.
- T1547.013detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface malicious or anomalous autostart .desktop entries (especially in test or acceptance environments), but this is scoped only to development/acquisition testing of new or changed systems rather than ongoing production monitoring of the live technique.
- T1547.014detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface malicious Active Setup Registry entries or the malware they launch when performed in dev/test or on production-like environments, but does not require ongoing runtime monitoring of the HKLM Active Setup keys themselves.
- T1547.015detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including unanticipated inputs) that surface insecure configurations, insecure code and design flaws; these can discover malicious or anomalous login-item additions when performed in a representative test environment, but the control is scoped to development/acceptance testing of new or changed systems rather than runtime detection on production endpoints where the technique is typically executed.
- T1548detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface abuse of elevation mechanisms (e.g. via insecure configurations or flawed auth/access functions) in pre-production; this is genuine detection but only a minority slice of the technique's post-deployment, runtime attack surface across all listed platforms.
- T1548prevents — A.8.29 mandates security testing (including of access restrictions, secure coding, configs, code review, vuln scanning and pen testing) that surfaces and enables remediation of elevation-control bypasses before production, thereby preventing many instances of the technique from reaching deployment; it is not a runtime control and does not reach every possible bypass method or post-deployment change.
- T1548.001detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations and vulnerable setuid/setgid binaries before production, but this is scoped only to the development and acceptance testing window and does not address post-deployment detection of the technique.
- T1548.001prevents — A.8.29 mandates security testing (including secure configurations, secure coding, vulnerability scanning, code review and penetration testing) during development and acceptance; this surfaces and can stop insecure setuid/setgid bits from reaching production, but does not guarantee their absence in all custom or third-party binaries nor block post-deployment abuse of existing ones.
- T1548.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface many UAC-bypass techniques (especially those relying on insecure code, auto-elevation, or weak configurations) before production, but does not monitor or surface the technique once it is used at runtime on a deployed system.
- T1548.002prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configs per 8.9/8.20/8.22, code review, vuln scanning, and pen testing) during development and acceptance to catch flaws before production; this surfaces and can stop many UAC-bypass implementation defects (e.g. insecure COM auto-elevation, weak auto-elevated binaries, injection into trusted processes) but leaves a bounded remainder (runtime bypasses, config weakening, lateral-movement paths, and post-deployment methods) unaddressed by testing alone.
- T1548.003detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface misconfigurations or insecure sudo/sudoers settings before production but does not monitor or detect the technique at runtime on deployed systems.
- T1548.003prevents — A.8.29 mandates security testing (including secure configurations, secure coding, vulnerability scanning, and penetration testing) during development and acceptance, which can surface and block insecure sudo/sudoers settings before production deployment, but does not guarantee their absence in all shipped systems or runtime configurations.
- T1548.004detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) during development and acceptance to surface insecure code, design, and configurations; these can detect the presence of this macOS-specific technique in custom or acquired software before production, but only for first-party or supplier-evaluated code and not for post-deployment adversary abuse on production systems.
- T1548.004prevents — A.8.29 mandates security testing (including secure coding, configurations, code review, vulnerability scanning, and penetration testing) during development and acceptance to validate requirements before production, which can surface and block insecure use or modification of the deprecated API in first-party or acquired code but does not reach adversary abuse of the still-functional API on existing macOS systems or world-writable file loading.
- T1548.005detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations, insecure code, and privilege-related design flaws in deployed or acquired systems, which would catch many misconfigured just-in-time/impersonation/pass-role permission setups before or after they reach production; it is not scoped to runtime behavioral detection of the technique in flight.
- T1548.005prevents — A.8.29 mandates security testing (including secure configurations, access restrictions, and vulnerability scanning) during development and acceptance, which can surface and block misconfigured just-in-time/impersonation/pass-role permissions before production deployment, but only for in-house or newly acquired components and does not reach runtime admin misconfigurations of existing cloud resources.
- T1548.006detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations, insecure code, and design flaws in development and acceptance; TCC database manipulation and related bypasses (e.g. via injection or SIP disablement) are detectable as insecure code/config/design issues, but only for in-house or evaluated outsourced code and only before production deployment, leaving post-deployment runtime abuse on live systems outside its scope.
- T1550detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface insecure handling or exposure of alternate auth material (e.g. weak ticket/caching logic, insecure storage) before production; this is genuine but only a minority slice of the technique's post-deployment runtime use across the listed platforms.
- T1550.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure token-handling patterns, misconfigurations or implementation flaws that enable T1550.001, but does not monitor or detect live token theft or abuse at runtime.
- T1550.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments that can surface PtT-enabling flaws (e.g. insecure credential handling, weak Kerberos configs, or missing auth checks), but does not monitor or detect the live technique on production Windows systems.
- T1550.004detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface insecure session cookie handling (e.g. missing HttpOnly/Secure flags, weak generation or transmission flaws) before production; this is genuine but only a slice because the technique is primarily realized at runtime via theft or replay of already-issued cookies, which post-deployment monitoring (not required by this clause) would surface.
- T1552detects — Security testing that verifies proper handling of credentials and cryptographic functions decreases the probability that credentials or keys are left exposed in files, registries, or configuration stores.
- T1552prevents — A.8.29 mandates security testing (including secure coding, configurations, vulnerability scanning, code review, and penetration testing) that can surface and block many insecure credential storage patterns before production, but does not guarantee their absence across all platforms, storage locations, or post-deployment changes.
- T1552.001detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/acceptance to surface insecure credential storage in files, configs, source, and deployments before production.
- T1552.001prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configs per 8.9/8.20/8.22, code review, vuln scanning, and pen testing) during development and acceptance to catch insecure credential storage before production, which stops many instances of the technique from being present; it is partial because the control is limited to tested changes/releases, does not reach all credential files (e.g. user-created, runtime logs, or post-deployment), and testing extent is risk-proportional rather than exhaustive.
- T1552.004detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure storage or exposure of private keys (e.g. via insecure configs, weak permissions or hard-coded material) before production; this is genuine but limited to the pre-deployment window and to what the chosen test plan actually covers.
- T1552.004prevents — A.8.29 mandates security testing (including secure configurations, secure coding, vulnerability scanning, and penetration testing) during development and acceptance to catch insecure storage of keys before production, but this only prevents a slice of the technique (poorly-stored keys introduced by the organization) while leaving post-compromise search, export from enrolled devices, network-device CLI extraction, and passphrase attacks untouched.
- T1552.005detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface SSRF flaws that enable T1552.005 but does not address runtime detection of direct API queries from an already-compromised instance.
- T1552.006detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface the presence of GPP XML files containing decryptable credentials (or the insecure configuration that enables the technique), but only when those artifacts are introduced or present during the tested development/acceptance phase of in-scope systems; it does not continuously or broadly detect the technique against already-deployed domain controllers or SYSVOL shares in production.
- T1552.007detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that surfaces insecure configurations, insecure code, and missing security functions in containerized systems before production; this can detect the exposed or weakly permissioned APIs that enable T1552.007, but only as a pre-deployment slice rather than runtime detection of the live technique.
- T1552.008detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that surfaces insecure configurations, coding, and design flaws during development and acceptance; this can detect the insecure credential-sharing patterns or integration-tool weaknesses that enable T1552.008, but only as a minority slice of a post-deployment technique that primarily lives in operational chat services rather than in the tested application code itself.
- T1553detects — Testing of secure configurations and code signing controls catches misconfigurations or trust-control bypasses that would allow adversaries to subvert code integrity checks.
- T1553prevents — A.8.29 mandates security testing (including secure coding, configurations, code review, vulnerability scanning and penetration testing) during development and acceptance, which can surface and block introduction of subvertible trust mechanisms (e.g. weak signing, insecure defaults) before production; this prevents some but not most instances of the technique, which also covers runtime subversion methods, stolen certs, and post-deployment attacks outside the development window.
- T1553.001detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure code, design, and configurations; these can detect Gatekeeper bypasses when they manifest as logic errors, unchecked file-type handling, or weak notarization/code-signing in tested macOS applications, but only for in-house or acquired components that actually reach the organization's test environment and test plan.
- T1553.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure code, configurations and flaws, which can discover adversary-created or stolen code-signing materials when they are introduced or tested; this is a genuine but minority slice of the technique (post-compromise use of already-signed malware on endpoints is outside its scope).
- T1553.003detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development/acceptance testing, which surfaces insecure configurations, insecure code and design flaws that enable SIP/trust-provider hijacking (including registry tampering and DLL search-order abuse) before production.
- T1553.003prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configurations per 8.9/8.20/8.22, code review, vulnerability scanning, and penetration testing) during development and acceptance to validate requirements before production; this catches many SIP/trust-provider tampering flaws in custom or acquired components but leaves a genuine remainder (e.g., post-deployment runtime hijacks, supply-chain components not caught in testing, or non-code Registry/DLL attacks).
- T1553.004detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) during development, acceptance and pre-deployment, which surfaces atypical/pre-installed or supply-chain root certificates as insecure configurations or design flaws; this does not address post-compromise installation of a root cert on a running production system (the dominant case in the T1553.004 prose).
- T1553.005detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure code, design and configurations; these can detect MOTW-bypass artifacts or test cases in developed/acquired components before production, but the control is scoped only to the development/testing phase and does not mandate ongoing runtime or post-deployment detection of the technique.
- T1553.006detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/testing that can surface policy-modification vectors, insecure configurations and vulnerable signed drivers, but does not monitor or detect the technique at runtime on production systems.
- T1554detects — A.8.29 mandates vulnerability scanning, penetration testing, code review and security testing (including of secure coding and configurations) that surface binary modification/patching flaws before production deployment, with automated tools explicitly called out; this is detection in the development pipeline, with a bounded remainder for post-deployment or runtime binary modifications on live systems.
- T1554prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and versions in development and acceptance to catch insecure code/configurations before production; this directly stops many classes of binary modification/patching that would otherwise introduce backdoors or hooks, but leaves open post-deployment modifications, supply-chain binaries accepted without full testing, and the technique's update-blocking step.
- T1555detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that can surface insecure credential storage or weak password-manager implementations before production, but does not monitor or detect the live adversary technique of searching for and extracting credentials at runtime.
- T1555.002detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations, insecure code, and design flaws; these can detect the presence of an insecure in-memory credential caching design that enables T1555.002, but only as part of pre-deployment or acceptance testing rather than runtime detection of the technique itself.
- T1555.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments to surface security flaws before production; this can detect browser-credential extraction weaknesses (e.g. insecure storage, weak encryption, or memory patterns) during testing of the relevant components, but does not monitor or surface the T1555.003 technique at runtime on deployed systems.
- T1555.004detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance to surface security flaws (including insecure configurations and code that could enable credential access), but does not address runtime or post-deployment detection of the T1555.004 technique itself
- T1555.005detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface insecure password-manager implementations (e.g. memory-exposure flaws or weak master-password handling) before production, but does not monitor or detect the live adversary technique of credential extraction or brute-force against deployed instances.
- T1555.006detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance that can surface insecure configurations, weak access controls or missing authz on secrets-manager interactions, but only in pre-production test environments and only for the organization's own developed or acquired components; it has no view of post-deployment runtime adversary behavior (privilege abuse, API calls) against managed cloud services on IaaS platforms.
- T1556detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which surfaces modifications to auth mechanisms (e.g. PAM, LSASS, plugins) before or at deployment, but does not monitor or detect the technique once it is performed in production.
- T1556prevents — A.8.29 mandates security testing (including of auth functions, secure coding, configs, code review, vuln scanning and pen testing) during development and acceptance, which can surface and block modifications to auth mechanisms before they reach production; this is a genuine but minority slice because the control only governs pre-deployment testing of in-house or acquired code, not runtime prevention of post-deployment adversary modification of auth processes across all platforms.
- T1556.001detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface the presence of a Skeleton Key-style patch in tested DC/LSASS binaries before production, but only for in-house or evaluated supplier code and only if the test plan includes relevant adversarial-simulation coverage; it does not instrument or detect the live technique post-deployment.
- T1556.002detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure code, design and configurations; these can surface a malicious password filter DLL (or its registration) if performed on the relevant components, but the control is scoped only to pre-production testing of new/changed systems and does not address detection of this technique once deployed in production.
- T1556.003detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which surfaces malicious PAM modifications or insecure configurations before production; this is limited to pre-deployment testing of in-house or acquired components rather than runtime detection of live adversary modifications.
- T1556.003prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components in development and acceptance, which can surface and block malicious PAM modifications or insecure PAM configurations before production deployment; this is a genuine but minority slice of the technique (pre-deployment only, and the control does not constrain post-deployment PAM changes or runtime abuse).
- T1556.004detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development/acceptance that can surface the backdoor password (as insecure code, insecure config or anomalous auth function), but this is limited to pre-deployment testing of in-house or acquired components and does not address post-deployment detection on live network devices.
- T1556.005detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations and insecure code/design, which would detect the reversible-encryption setting when it is introduced or present in tested systems or AD configurations.
- T1556.005prevents — A.8.29 mandates security testing (including secure configs, secure coding, vulnerability scanning, and penetration testing) during development and acceptance that would surface the reversible-encryption setting as an insecure configuration before production, thereby preventing the technique from being present in deployed systems; it is only partial because the control is limited to the pre-deployment testing window and does not constrain an adversary who can still enable the property post-deployment via Group Policy or PowerShell.
- T1556.006detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface insecure MFA configurations, bypassable implementations, or flawed fail-open logic before or (in limited operational re-testing) after deployment; this is genuine detection of the technique's enablers but only a slice, as the control is scoped to pre-production acceptance and test environments rather than continuous runtime detection of post-compromise MFA modification.
- T1556.006prevents — A.8.29 mandates security testing (including of auth functions per 8.5, secure configs per 8.9/8.20/8.22, and code review/pen-testing) that can surface and block MFA-disabling defects before production, but only catches a slice of the technique's vectors (e.g. misconfigs, vulnerable MFA methods) while post-compromise patching, policy abuse, and runtime bypasses remain outside its scope.
- T1556.007detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface backdoors or malicious modifications in on-premises hybrid authentication components (PTA agents, AD FS configs, DLLs) before or during deployment to production, but does not address runtime detection of post-deployment modifications or cloud-side PTA agent registration.
- T1556.007prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing) of new systems/upgrades in development and acceptance to catch insecure code, configurations, and authentication functions before production; this can surface backdoors or modifications to hybrid auth processes (e.g. malicious DLLs or config changes) if they are introduced during in-house or outsourced development, but does not stop post-deployment runtime patching or cloud-side modifications by a privileged adversary.
- T1556.008detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance that can surface insecure configurations and registry-based credential-manager implants before production, but does not monitor or detect the technique once it is already present and running on a deployed Windows system.
- T1556.008prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components in development and acceptance to catch insecure code, configurations, and functions before production; this catches malicious or vulnerable network provider DLL registration in custom or acquired software but leaves the technique possible in unmodified COTS Windows systems, post-deployment changes, or testing gaps.
- T1556.009detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface misconfigurations or insecure policy implementations (including conditional access flaws) before or during deployment to production, but does not monitor or detect live adversarial modifications of policies in an already-deployed identity provider environment.
- T1557detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/testing that can surface AiTM-enabling flaws (weak crypto configs, insecure protocol handling, downgrade vectors, insecure defaults) before production, but does not monitor or detect the live network technique itself.
- T1557prevents — A.8.29 mandates security testing (including secure coding, configurations, crypto use, vulnerability scanning, and penetration testing) during development and acceptance, which can surface and block AiTM-enabling flaws such as weak TLS negotiation, insecure DNS/ARP handling, or missing boundary protections before production; this is only a slice of the technique's full surface (e.g., runtime protocol abuse on deployed systems, post-deployment configuration changes, or network-device behaviors outside the tested code).
- T1557.001detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface name-resolution poisoning vectors, insecure configs, and authentication weaknesses in developed or acquired systems, but only during pre-deployment testing of new/changed code — not ongoing detection of the live-network technique itself.
- T1557.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface ARP poisoning (as insecure network config, design flaw or insecure coding), but only in the pre-production test environment for new/changed systems — it does not instrument or surface the live technique on deployed production networks.
- T1557.003detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface rogue DHCP server artifacts, insecure network configs, and related design flaws in tested systems, but only in pre-production/test environments matching production — not ongoing detection of live adversary DHCP spoofing on deployed networks.
- T1557.004detects — A.8.29 mandates vulnerability scanning and penetration testing (including in test environments matching production) that can surface evil twin setups or related insecure wireless configs/certs during acceptance testing of network devices or changes, but this is limited to pre-deployment or change windows rather than ongoing detection of rogue APs in the live environment.
- T1558detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that can surface Kerberos ticket-related weaknesses such as insecure configurations, weak cryptography or authentication flaws before production, but does not monitor or detect the live adversary technique of stealing or forging tickets at runtime.
- T1558.001detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that can surface insecure configurations, weak cryptography or credential-handling flaws enabling KRBTGT hash theft, but does not monitor or detect the golden-ticket technique once it is executed in a production AD environment.
- T1558.002detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface insecure configurations, insecure code or design flaws enabling silver ticket forgery, but only during development/acceptance testing of new or changed systems — not against already-deployed production environments where the technique would actually be used.
- T1558.003detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface insecure configurations, weak cryptography (RC4 in TGS tickets), and related flaws that enable Kerberoasting, but only in tested systems/components before or at deployment, not in live production environments where the technique is actually executed.
- T1558.004detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance; these surface insecure configurations, weak cryptography (RC4) and authentication flaws that enable AS-REP roasting, but only in tested code/components and only before production, leaving runtime instances and post-deployment accounts undetected.
- T1558.005detects — A.8.29 requires vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface insecure configurations, weak Kerberos setups, or code that enables ccache theft, but does not monitor or detect the live adversary technique post-deployment.
- T1559detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface insecure IPC usage or exploitable IPC flaws before production, but does not monitor or detect the technique at runtime or in deployed systems.
- T1559.001detects — A.8.29 requires vulnerability scanning and penetration testing (plus code review) that can surface COM abuse as insecure code, design or configuration in tested systems, but only where the test plan and environment actually exercise the relevant interfaces and the technique is observable in the test scope.
- T1559.002detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/testing that can surface DDE-enabled Office/CSV payloads or insecure registry configs enabling the technique, but only in pre-production artifacts under test and not in live deployed environments or post-compromise use.
- T1559.003detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which surfaces XPC client validation failures, poor input sanitization and insecure configurations that enable T1559.003; it is scoped only to pre-production testing of in-house or acquired components rather than runtime detection on deployed systems.
- T1559.003prevents — A.8.29 mandates security testing (including secure coding, input sanitization, code review, vulnerability scanning and penetration testing) during development that would surface and allow remediation of the improper XPC client validation or poor input sanitization that enables T1559.003, but does not guarantee those flaws are absent from all shipped code.
- T1560.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface malicious or anomalous use of archival libraries (e.g. unexpected calls to zlib/libzip in collected data paths), but only in pre-production code review or test environments, not in live adversary execution on production systems.
- T1561.002recovers — A.8.29's test environment that matches production and its emphasis on verifying remediation of defects (including secure configurations and boot-related components) surfaces recovery needs for wiped structures, but the control's core purpose is pre-deployment validation rather than post-incident state restoration.
- T1563detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus automated tools) that can surface session-hijacking flaws such as weak session tokens, missing binding, or insecure remote-service configs before production; this is genuine detection of technique precursors but only a slice, as the control stops at pre-deployment testing and does not instrument or detect live hijacking of production sessions.
- T1563.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface SSH agent hijacking flaws, insecure SSH configs or weak auth implementations before production, but does not monitor or detect the live technique post-deployment.
- T1563.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments that can surface RDP session hijacking flaws (e.g. weak session handling, insecure RDP configs or missing auth enforcement) before production, but does not monitor or detect the live technique post-deployment.
- T1564detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test that can surface hidden artifacts or the techniques used to create them (e.g. insecure configs, unexpected behaviors), but this is limited to pre-deployment testing of in-house or acquired systems and does not broadly detect post-deployment adversary use of T1564
- T1564.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface hidden-file techniques when they appear in custom code, configs or test artifacts, but does not require runtime detection of the live adversary technique on production systems.
- T1564.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface hidden-user techniques when they appear as insecure configurations, hidden attributes or anomalous account creation in the tested code or environment, but only for in-house or evaluated outsourced components and only before deployment — not for post-deployment adversary use of the technique on production systems.
- T1564.003detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure code, configurations and design flaws; hidden-window techniques rely on such flaws (e.g. abused APIs, insecure plist/registry settings, un-reviewed LOLBins) that would be found during those tests, but the control is scoped to pre-deployment/development testing and does not address runtime or post-deployment detection of the technique in operation.
- T1564.004detects — A.8.29 requires vulnerability scanning and penetration testing (plus code review) that can surface NTFS attribute misuse when performed in a representative environment, but does not mandate or guarantee coverage of this specific hiding technique or its artifacts.
- T1564.005detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface hidden file system artifacts or non-standard structures when they appear in reviewed/analyzed code or test environments, but this is limited to pre-deployment discovery of developer-introduced or component-borne instances rather than runtime detection on production systems.
- T1564.006detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments that can surface insecure configurations, hidden VMs or virtualization artifacts before production, but does not monitor or detect the live adversary technique on production endpoints.
- T1564.007detects — A.8.29 explicitly requires vulnerability scanning, code review, and penetration testing (including of secure coding per 8.28) that can surface VBA stomping artifacts or anomalous compiled p-code in Office documents during development/acceptance testing, but this is limited to tested in-house or acquired components in a matching test environment and does not broadly detect the technique post-deployment or in arbitrary documents.
- T1564.007prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of new systems, upgrades, and components in development and acceptance to validate security requirements and catch flaws before production; this catches VBA stomping in in-house or acquired Office-based applications as a secure-coding or hidden-malicious-payload defect, but only for tested releases and not for arbitrary documents users later open.
- T1564.008detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance; these can surface insecure email-rule configurations or rule-creation logic in custom/outsourced components before production, but do not address post-deployment rule abuse by a valid credentialed user or admin on live mailboxes.
- T1564.009detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure code, design and configurations; these can catch resource-fork hiding techniques on macOS when the test environment matches production, but the control is scoped only to pre-deployment testing of new/changed systems rather than runtime or deployed detection.
- T1564.009prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of in-house and acquired components before production deployment, which can surface and block resource-fork hiding techniques when they appear in tested code or bundles, but the control is silent on runtime detection, deprecated macOS fork handling, and post-deployment adversary use.
- T1564.010detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review in development/testing that can surface memory manipulation and argument-spoofing flaws before production, but does not mandate runtime detection of the live technique on deployed Windows systems.
- T1564.011detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure code, design and configurations; these can surface the use of nohup, -ErrorAction SilentlyContinue or equivalent interrupt-ignoring patterns when they appear in reviewed or tested artifacts, but only for first-party or evaluated third-party code and only before deployment.
- T1564.012detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface the presence of excluded malicious artifacts or the insecure exclusion configurations themselves when performed in a representative test environment, but does not monitor or surface the live post-deployment abuse of exclusions by an adversary.
- T1564.013detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in a production-like test environment, which can surface anomalous bind mounts or hidden /proc artifacts when they are exercised during security testing, but does not require or guarantee detection of this post-deployment Linux-specific hiding technique in running production systems.
- T1564.014detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations, hidden payloads or design flaws in deployed systems; this can catch xattr abuse when tests inspect beyond standard file hashes, but the control is scoped to development/acceptance testing of new or changed systems rather than runtime detection of the live technique across production environments.
- T1565detects — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) that surfaces insecure code, configurations, or functions whose exploitation could enable data manipulation, but does not require ongoing runtime detection of the technique itself once in production.
- T1565prevents — A.8.29 mandates security testing (including secure coding, configurations, code review, vuln scanning and pen testing) that surfaces and can block data-manipulation flaws before production, but only for defects reachable by those test types and only where the organization chooses to apply the proportionate test depth; it does not stop runtime manipulation techniques that bypass the tested paths.
- T1565.001detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in dev/test environments (plus remediation verification) that can surface stored-data manipulation flaws before production, but this is limited to pre-deployment discovery of introduced defects rather than runtime or post-deployment detection of the live technique against data at rest.
- T1565.002detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that surfaces insecure configurations, coding, and design flaws enabling transmitted data manipulation, but only during development/acceptance and not against live adversary activity on deployed systems.
- T1565.003detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface indicators of runtime data manipulation techniques (e.g. altered binaries or insecure configurations) before production but does not monitor or detect the technique once it is in use on a live system.
- T1565.003prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure-coding/config/function checks) during development and acceptance; this catches or blocks many classes of binary alteration and insecure design that enable runtime data manipulation before production, but leaves a bounded remainder for post-deployment adversary modifications, insider changes, or complex targeted expertise that testing in a matched environment does not fully eliminate.
- T1567.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface insecure configurations, code or design that would enable exfiltration to a code repository (e.g. overly permissive outbound rules, missing egress filtering, or insecure API credential handling), but does not monitor or detect the live technique once deployed.
- T1567.004detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface webhook-related exfiltration vectors (e.g. insecure SaaS integrations, unexpected outbound HTTP/S in code, or misconfigurations) before production but does not monitor or detect the live technique post-deployment.
- T1568detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure code, configurations and design flaws; dynamic resolution is observable as anomalous network behavior, unexpected domain generation or C2 patterns during testing, but the control is scoped to pre-production acceptance testing of in-house or acquired systems rather than runtime detection of deployed malware employing the technique.
- T1568.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface observable DGA artifacts (e.g. anomalous domain-generation code, insecure network configs, or runtime C2 beacons) during development or acceptance, but only for in-house or evaluated supplier code and only where those tests are scoped to include the technique; it has no view of deployed adversary malware using DGA post-acceptance.
- T1568.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments that can surface this DNS-calculation C2 technique when exercised in test traffic or code, but the control is scoped only to pre-production acceptance testing and does not require ongoing detection in production where the technique would actually be used by an adversary.
- T1569detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface malicious/abused services or insecure service configurations after they are present in test or production environments, but this is scoped only to development acceptance testing rather than ongoing detection of live abuse.
- T1569.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface launchctl abuse (as anomalous/malicious service execution or insecure configuration) when performed in a representative test environment, but does not require runtime monitoring or detection of the technique in production.
- T1569.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface insecure service configurations or malicious service-related code before production, but does not monitor or detect the live technique at runtime on deployed systems.
- T1569.003detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface misuse of systemctl in test environments or custom code/scripts that integrate it, but this is limited to pre-production discovery of developer-introduced patterns rather than runtime detection of the post-deployment technique.
- T1570detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments that can surface insecure configurations, insecure code or unexpected file-transfer mechanisms (e.g. enabled services, weak auth on SMB/RDP/scp/ftp) before production, but does not monitor or detect the technique once it is running in a live compromised environment.
- T1571detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that can surface non-standard port usage or configuration changes when performed in development, acceptance or pre-production environments, but does not require or perform ongoing detection of the live technique post-deployment.
- T1572detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments that can surface tunneling-capable code, insecure configs or weak protocol implementations before production, but does not monitor or detect the live technique once adversaries execute it on deployed systems.
- T1573detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure cryptography and design flaws in custom or acquired components; this can detect the weak key-handling slice of T1573 but does not broadly instrument or surface encrypted C2 channels at runtime.
- T1573.001detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that can surface insecure or non-compliant use of cryptography in developed or acquired systems before production, thereby detecting the technique when it appears in custom or third-party components.
- T1573.002detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure cryptography implementations or misconfigurations in developed/acquired systems, which would detect use of asymmetric crypto for C2 when it deviates from approved secure configurations or introduces vulnerabilities, but this is limited to the pre-production testing phase and does not broadly detect the technique at runtime across deployed environments.
- T1574detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/testing that can surface hijack vectors (e.g. insecure library loading, poisoned search paths, weak configurations) before production, but does not monitor or detect the technique at runtime or in deployed systems.
- T1574prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configs per 8.9/8.20/8.22, code review, vuln scanning, and pen testing) that can catch and block many hijack vectors (e.g. poisoned paths, insecure library loading, weak configs) before production, but does not guarantee coverage of all variants or runtime hijacks that survive testing.
- T1574.001detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/acceptance testing that surfaces insecure configurations, insecure code, and design flaws enabling DLL sideloading, search-order hijacking, phantom hijacking, and substitution before production.
- T1574.001prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configurations, code review, vulnerability scanning, and penetration testing) during development and acceptance, which can surface and stop many DLL sideloading/search-order/phantom-hijacking flaws before production; it does not reach all implementation paths, runtime behaviors, or post-deployment substitutions, leaving a genuine minority slice prevented.
- T1574.004detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure code, design and configurations that enable dylib hijacking (e.g. weak linking, search-path ordering, missing dylibs), which directly detects the technique before production.
- T1574.004prevents — A.8.29 mandates security testing (including secure coding per 8.28, code review, vulnerability scanning, and penetration testing) during development and acceptance to catch design/implementation flaws like insecure dylib search paths or weak linking before production, which would stop the technique from being viable in deployed apps; it is partial because the control is a process whose coverage depends on test rigor, scope, and whether the vulnerable app was developed in-house versus acquired.
- T1574.005detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which surfaces installer permission weaknesses (and the insecure configurations or code that enable T1574.005) before production.
- T1574.005prevents — A.8.29 mandates security testing (including secure configurations, secure coding, vulnerability scanning, and penetration testing) during development and acceptance, which can surface and block installer permission weaknesses before production deployment; this is a genuine but minority slice of the technique's attack surface because the control is limited to tested in-house or acquired components and does not reach untested third-party installers, runtime environments, or post-deployment instances.
- T1574.006detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations, insecure code, and design flaws in development and acceptance; these can catch many LD_PRELOAD/DYLD_INSERT_LIBRARIES hijack vectors (e.g. via static analysis for unsafe env use or dynamic testing that observes anomalous library loads), but the control is scoped only to pre-production testing of in-house or acquired systems and does not instrument or detect the technique at runtime in production environments.
- T1574.006prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configurations, code review, vulnerability scanning, and penetration testing) during development and acceptance, which can surface and block insecure dynamic linker practices (e.g., unsafe LD_PRELOAD usage or library loading) before production, but does not guarantee their absence in all code, configurations, or runtime environments.
- T1574.007detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review in development/acceptance testing (including secure configurations and secure coding), which surfaces PATH interception flaws before production; the remainder is post-deployment or runtime instances outside the tested change window.
- T1574.007prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configurations per 8.9/8.20/8.22, code review, vulnerability scanning, and penetration testing) during development and acceptance, which can surface and stop PATH interception flaws before production but does not guarantee their absence across all code, configurations, or runtime environments.
- T1574.008detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface search-order hijacking flaws (e.g. as insecure code or configuration) before production; this is genuine detection but only a slice because the control is scoped to pre-deployment testing of new/changed systems rather than runtime or deployed detection of the live technique.
- T1574.008prevents — A.8.29 mandates security testing (including secure coding, code review, vulnerability scanning, and penetration testing) during development and acceptance, which surfaces and can block search-order-hijacking flaws before production; it is not a universal mechanism and leaves residual risk from incomplete test coverage or post-deployment changes.
- T1574.009detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in a production-like environment to surface insecure configurations, insecure code and design flaws; unquoted paths are a named, discoverable insecure configuration and code defect that these activities surface before or after deployment.
- T1574.009prevents — A.8.29 mandates security testing (including secure coding per 8.28, code review, vulnerability scanning, and penetration testing) during development and acceptance, which can surface and block unquoted-path defects before production; this is a genuine but minority slice of the technique's surface because the control is limited to tested in-house or acquired components under the organization's SDLC and does not reach already-deployed systems, third-party software outside the acquisition process, or runtime configuration drift.
- T1574.010detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review in development/acceptance to surface insecure configurations, insecure code, and permission-related flaws before production, which would detect the services file permissions weakness in tested components.
- T1574.010prevents — A.8.29 mandates security testing (including secure configurations, vulnerability scanning, penetration testing and code review) that surfaces permission weaknesses before production, so it prevents the technique from reaching deployed systems when those tests catch it; this is only a slice because testing is not guaranteed to be exhaustive or to cover every possible service binary/path, and the control stops at verification rather than mandating the configuration fix.
- T1574.011detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that surface insecure configurations and insecure code/design, which directly catches the permission misconfiguration on service Registry keys before or during deployment to production.
- T1574.011prevents — A.8.29 mandates security testing (including secure configurations, vulnerability scanning, penetration testing and code review) that surfaces insecure Registry/service permissions before production, thereby preventing the weakness from reaching the running environment in tested systems; it is only a slice because the control is limited to the development/acceptance phase, does not itself enforce correct ACLs, and leaves untested or post-deployment instances untouched.
- T1574.012detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure code, design and configurations; these can catch COR_PROFILER abuse patterns (e.g. suspicious environment-variable or DLL-loading logic) before production, but only for first-party or reviewed in-house/outsourced code — not for already-deployed third-party .NET processes or runtime registry/in-memory abuse on live Windows systems.
- T1574.012prevents — A.8.29 mandates security testing (including secure coding per 8.28, vulnerability scanning, code review, and penetration testing) during development and acceptance to catch insecure configurations, code, or design that could enable COR_PROFILER abuse before production; this prevents a slice of the technique (e.g., via flawed .NET component integration or unhardened defaults) but leaves runtime environment variable/registry abuse and post-deployment persistence largely untouched.
- T1574.013detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface this technique when it is present in in-house or acquired code/components before production, but does not monitor or detect live execution of the technique post-deployment.
- T1574.013prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) during development and acceptance that can surface and block insecure code/design enabling KernelCallbackTable abuse before production, but does not guarantee prevention of every implementation of this technique.
- T1574.014detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in development/testing that can surface AppDomainManager hijacking indicators (insecure loading, tampered configs, unexpected assemblies) before production, but does not mandate runtime or post-deployment detection of the technique in operation.
- T1574.014prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) of security functions, secure coding, and configurations during development and acceptance, which can surface and block AppDomainManager hijacking flaws before production, but only for in-house code under the organization's own test plan and does not reach tampered configs/environment variables in already-deployed third-party .NET apps.
- T1578detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface misconfigurations or insecure modifications to cloud compute components (e.g. via IaC testing) before production, but does not monitor or detect the live adversary technique post-deployment.
- T1578.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure configurations or policy weaknesses that would enable T1578.002, but does not monitor or detect the live technique once an adversary executes instance creation in a running IaaS environment.
- T1578.005detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface misconfigurations or insecure settings (including in cloud/IaaS environments when tested pre-production or via ongoing scans), but does not require or guarantee detection of post-deployment live modifications to tenant policies, quotas or compute settings by an adversary.
- T1588.005detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which can surface known exploits or the vulnerabilities they target in in-house or acquired components before production, but this is limited to tested systems and does not broadly detect pre-attack acquisition, theft, or monitoring of exploits by adversaries.
- T1599detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface misconfigurations or flaws in perimeter devices/firewalls (the very components T1599 targets), but this is scoped only to pre-deployment acceptance testing of new/changed systems rather than ongoing detection of live adversary compromise or reconfiguration.
- T1599.001detects — A.8.29 requires vulnerability scanning and penetration testing (plus code review) of systems/components in dev/test environments that match production, which can surface misconfigured NAT on boundary devices or insecure code/config that enables the technique, but this is limited to pre-deployment testing rather than runtime detection of post-compromise NAT modifications on live network devices.
- T1600detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure configurations, insecure code and missing/weak crypto functions before production; this surfaces many T1600 instances (e.g. weakened ciphers, disabled hardware, reduced key space) but only those introduced or present at test time in the tested build, leaving post-deployment or runtime manipulations on live network devices outside its scope.
- T1600.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus remediation verification), which can surface weakened crypto parameters or insecure configurations before or during acceptance, but does not monitor or detect the post-deployment technique on live network devices.
- T1600.001prevents — A.8.29 mandates security testing (including of cryptography per 8.24, secure configs, code review, vuln scanning and pen testing) that would surface a weakened key space before production deployment, thereby preventing the technique from being present in the released system; it is partial because the control is scoped to new/changed systems under test, does not reach already-deployed devices, and its effect depends on test coverage and remediation rigor rather than a universal mechanism.
- T1600.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance to surface insecure configurations, insecure code and design flaws; this can surface the disabled-hardware-encryption state (or its enabling misconfiguration) when the device image or config is tested in a representative environment, but the control is scoped only to pre-production testing of new/upgraded systems and does not require ongoing detection of the technique post-deployment.
- T1601detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including on secure configurations and secure coding) that surface insecure modifications to system images/components in development, acceptance and pre-acquisition testing; this catches many T1601 instances before production but is limited to the test environment and pre-deployment phase, leaving runtime/live modifications on deployed devices outside its scope.
- T1601.001detects — A.8.29 explicitly requires vulnerability scanning, penetration testing, and code review during development/acceptance testing to surface insecure code, configurations, and flaws before production; this surfaces the technique when performed on in-house or acquired network device images but only in pre-deployment testing, not on live production devices where the technique is described as occurring.
- T1601.001prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing, and secure configuration checks) during development, acceptance, and before production deployment, which can surface and block many classes of patchable weaknesses or insecure images before they reach a live network device, but does not address in-memory runtime patching, post-deployment changes, or bootloader-implant vectors that occur outside the tested development cycle.
- T1601.002detects — A.8.29 requires vulnerability scanning and penetration testing (plus code review) of systems/components before production deployment, which can surface a downgraded image as an insecure/outdated configuration or vulnerable version if the test environment and test plan cover it; this is a genuine but minority slice of the technique's full surface (adversary action post-deployment on live network devices).
- T1601.002prevents — A.8.29 mandates security testing (including secure configurations, vulnerability scanning, penetration testing, and code review) of new systems/upgrades/versions before production deployment, which would surface and block many downgrade-induced weaknesses in OS ciphers or defensive features during acceptance; it does not address post-deployment adversarial replacement of the running image on live network devices.
- T1602.001detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that can surface SNMP/MIB exposure or insecure SNMP configurations during development and acceptance, but this is limited to pre-production testing of in-house or acquired systems and does not address runtime detection of the post-deployment adversary technique on production network devices.
- T1602.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface insecure configurations or exposed management interfaces enabling T1602.002, but this is limited to the pre-deployment testing window for new/changed systems rather than runtime detection of the technique on production network devices.
- T1606detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces insecure code, design and configurations capable of enabling credential forgery, but only during pre-deployment development and acceptance phases, not against live adversary behavior post-deployment.
- T1606.001detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in development/acceptance that can surface insecure cookie generation, weak signing or predictable values before production, but does not instrument or monitor running systems for the post-deployment technique itself.
- T1606.001prevents — A.8.29 mandates security testing (including secure coding per 8.28, secure configs, code review, vuln scanning, and pen testing) during development and acceptance, which can surface and block cookie-forging flaws in the application's own session-handling code before production; this is a genuine but minority slice of the technique, which also succeeds against third-party SaaS, misconfigured off-the-shelf apps, or stolen secrets outside the tested codebase.
- T1606.002detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review in a near-production test environment, which surfaces the insecure configurations, certificate handling and code/design flaws that enable T1606.002 forgery before or after deployment, but does not instrument runtime detection of forged SAML tokens in flight.
- T1608.005detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) of new systems, upgrades, and components before production deployment; this surfaces malicious link targets hosted on acquired infrastructure, cloned phishing sites, or insecure code/configurations that would enable T1608.005, but only for in-house/outsourced development and acquisition — not for adversary-controlled external resources created entirely outside the organization's SDLC.
- T1609detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that can surface insecure configurations, weak access controls, or exposed container admin interfaces before production, but does not monitor or detect the live technique once adversaries are abusing a running container admin service.
- T1610detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development/acceptance to surface insecure configurations, vulnerable images or privileged containers before production; this catches many T1610 deployments but only those introduced through tested code or components, leaving runtime/ad-hoc deployments (e.g. via compromised Kubernetes APIs or dashboards) outside its scope.
- T1611detects — A.8.29 mandates vulnerability scanning, penetration testing and code review that can surface container escape flaws (e.g. insecure configs, privileged containers, missing isolation) before production, but only in the pre-deployment test environment and only for defects the chosen tests actually exercise.
- T1611prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, penetration testing) of secure configurations, secure coding, and security functions during development and acceptance, which can surface and block many container/virtualization escape vectors (e.g. insecure bind mounts, privileged containers, weak configs) before production; it is not a runtime mechanism and does not reach all exploitation paths or post-deployment changes, so only a slice of the technique.
- T1612detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review during development/acceptance testing (including of secure configurations and code), which can surface the malicious custom image build or its embedded malware on-host before deployment, but this is limited to the test environment and pre-production phase rather than runtime detection of the build technique itself.
- T1613detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that surfaces insecure configurations, insecure code, and other flaws in containerized systems during development and acceptance; this can detect the discovery-enabling conditions named in T1613 (e.g., exposed dashboards, leaky logs, weak API auth) before production, but only for defects present in the tested build and only within the test environment slice, not runtime adversary behavior.
- T1615detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) that can surface insecure Group Policy configurations or overly permissive settings during development and acceptance, but does not monitor or detect live adversary execution of discovery commands such as gpresult or Get-DomainGPO at runtime.
- T1620detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface reflective loading techniques (or the insecure coding/configurations that enable them) before production, but does not monitor or detect the live technique at runtime.
- T1620prevents — A.8.29 mandates security testing (including code review, vulnerability scanning, and penetration testing) during development and acceptance that can surface and block reflective loading techniques before production, but this is limited to in-house or contractually covered code and does not stop adversaries from using the technique post-deployment in running processes.
- T1621detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus automated tools) that can surface MFA request-generation weaknesses such as missing rate limits, fatigue-resistant prompts or improper SSPR push config before production, but does not monitor or detect the live technique at runtime or in deployed identity-provider/SaaS environments.
- T1622detects — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review (including unanticipated inputs/conditions) during development and acceptance testing, which surfaces many debugger-evasion artifacts and anti-analysis patterns before production; it does not guarantee detection of every possible evasion check or runtime variant.
- T1647detects — A.8.29 explicitly requires vulnerability scanning and penetration testing (plus code review) that can surface plist-modification artifacts or insecure configurations in tested applications/components before production, but this is limited to the pre-deployment test window on in-house or acquired code and does not continuously or broadly detect the post-deployment adversary technique on live macOS systems.
- T1648detects — A.8.29 mandates security testing (including vulnerability scanning, code review, and penetration testing) of new systems, upgrades, and code before production deployment, which can surface malicious or backdoored serverless functions/artifacts during acceptance testing, but only for in-house or evaluated outsourced code and not for post-deployment adversary-created/invoked serverless resources in live cloud environments.
- T1649detects — A.8.29 mandates vulnerability scanning, penetration testing and code review in dev/test environments (plus remediation verification), which surfaces certificate-related misconfigurations, insecure storage, improper EKU/SAN issuance and other flaws that enable T1649, but does not address runtime detection of theft or forgery once certificates are deployed to production systems.
- T1649prevents — A.8.29 mandates security testing (including of authentication functions, secure coding, configs, code review, vuln scanning and pen testing) that can surface certificate-related flaws before production, thereby preventing some steal/forge paths that originate in insecure code, configs or untested enrollment logic; it does not address runtime theft of already-issued certs, golden-certificate attacks via CA key compromise, or post-deployment misconfigurations.
- T1651detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) of systems/components in dev/test environments that can surface insecure configurations, weak access controls, or improper agent/service setups that enable T1651, but does not monitor or detect the live technique in a running production cloud environment.
- T1654detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that surfaces insecure configurations, insecure code, and missing security functions in systems under development or acceptance; this can detect the insecure logging configurations or missing audit protections that enable T1654, but does not itself monitor or surface the live enumeration technique once an adversary is running it post-deployment.
- T1659detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance testing, which can surface insecure configurations, weak cryptography or flawed input handling that enable content injection, but does not monitor or detect the live technique once deployed in production network traffic.
- T1665detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that surfaces insecure configurations, code, and design flaws; this can detect some T1665 artifacts (e.g., hidden/masked domains or filtering logic) when they appear in tested systems or components, but the control is scoped to development/acceptance testing of in-scope software and does not broadly detect live adversary C2 hiding on production networks.
- T1671detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development/acceptance to surface insecure configurations, code, and design flaws; this can detect malicious or anomalous OAuth integrations and related misconfigurations in custom or acquired SaaS/cloud applications before or at deployment, but only a minority slice of the post-deployment persistence technique itself.
- T1674detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance, which can surface insecure code or configurations enabling input injection (e.g. weak input handling or HID filtering) before production, but does not monitor or detect the live technique on deployed systems.
- T1675detects — A.8.29 mandates security testing (including vulnerability scanning and penetration testing) during development and acceptance that can surface insecure configurations or code enabling ESXi guest command abuse, but only in pre-production test environments matching production and only for systems under development or acquisition.
- T1677detects — A.8.29 explicitly requires vulnerability scanning, code review, and penetration testing (including of secure coding, configurations, and security functions) during development and acceptance, which surfaces poisoned pipeline code or insecure CI configs before production; this is a genuine but minority slice of the technique because the control is scoped to in-house/outsourced development testing rather than runtime or post-deployment pipeline monitoring, and public/indirect scenarios often evade pre-merge detection.
- T1677prevents — A.8.29 mandates security testing (including code review, SAST, vulnerability scanning, and penetration testing) of new systems, upgrades, and versions in a production-like environment, which catches many forms of pipeline poisoning (especially indirect and public scenarios that introduce malicious code, scripts, or configs) before deployment, but does not stop direct modification of CI config files by an insider or pre-commit attacker, nor does it address all pull-request trust or self-hosted runner scenarios at the point of injection.
- T1678detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing and code review) that surfaces timing-based evasion in developed or acquired code/components before production, but does not monitor or detect the live technique at runtime on deployed systems.
- T1679detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) that can surface selective-exclusion logic or test-case gaps during development and acceptance, but only for in-house or contractually-covered code; it has no view of post-deployment adversary behavior or third-party ransomware that applies the technique at runtime.
- T1685detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) during development and acceptance to surface flaws before production; this can detect some classes of tool-tampering weaknesses (e.g. insecure configs or bypassable anti-tampering in the tools themselves) but does not detect live adversary use of T1685 post-deployment.
- T1685.001detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development and acceptance to surface insecure configurations, insecure code and design flaws that could allow disabling the Event Log service; this surfaces the technique in pre-production but does not address post-deployment runtime use or already-deployed systems.
- T1685.002detects — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, and code review) during development and acceptance to surface insecure configurations and flaws that could allow disabling/modifying logging, but this only detects the enabling weakness pre-deployment in tested systems and does not detect the live technique post-deployment.
- T1685.003detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance to surface insecure code, configurations, and design flaws (including in security components); this can surface UI-spoofing or tampering logic before deployment on Linux/macOS/Windows, but only as a pre-production slice with no coverage of post-deployment adversary behavior.
- T1685.004detects — A.8.29 requires vulnerability scanning, penetration testing and code review during development and acceptance to surface insecure configurations and system vulnerabilities (including audit-related ones), but this is limited to pre-deployment testing of new/changed systems and does not address runtime or post-deployment detection of an adversary disabling auditd on a live Linux system.
- T1685.005detects — A.8.29 requires vulnerability scanning and penetration testing (plus code review) that can surface the post-exploitation log-clearing artifacts or the enabling insecure configurations/privileges, but only as one slice of broader security testing rather than dedicated detection of the technique itself.
- T1686detects — A.8.29 requires vulnerability scanning and penetration testing that can surface insecure firewall configurations or rules (explicitly listed under secure configurations), but this is limited to pre-deployment testing of new/changed systems rather than runtime detection of post-compromise tampering by an adversary.
- T1686prevents — A.8.29 mandates security testing (including secure configurations of firewalls) during development and acceptance, which can catch and block insecure firewall rules or modifications from reaching production, but does not stop post-deployment tampering by a privileged adversary on live systems.
- T1686.001detects — A.8.29 requires vulnerability scanning and penetration testing (plus code review) that can surface misconfigured or modifiable cloud firewalls and insecure rules during development, acceptance and pre-deployment testing, but does not monitor or detect the live adversarial technique post-deployment in a running cloud environment.
- T1686.002detects — A.8.29 mandates vulnerability scanning, penetration testing and code review during development and acceptance to surface insecure configurations and system vulnerabilities (including in firewalls and security components), which can detect misconfigurations or weaknesses that would enable T1686.002; this is limited to pre-deployment testing of in-scope systems rather than runtime detection of the live technique on network devices.
- T1686.002prevents — A.8.29 mandates security testing (including of secure configurations, access restrictions, and vulnerability scanning/penetration testing) during development and acceptance to catch insecure firewall rules or device configs before production, which would prevent many instances of the technique from being present; it does not address post-deployment changes via valid accounts or exploits on live network devices.
- T1686.003detects — A.8.29 mandates vulnerability scanning and penetration testing (plus code review) that can surface insecure firewall configurations or rule changes when performed in a test or acceptance environment that closely matches production, but does not require ongoing runtime monitoring of the live host firewall state or adversary modifications to it.
- T1687detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review during development and acceptance testing, which surfaces exploitable flaws (including in defensive components) before production, but does not monitor or detect live exploitation of those flaws once deployed.
- T1687prevents — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, secure coding review and secure configuration checks) during development and acceptance, which surfaces and enables remediation of exploitable flaws in defensive components before they reach production, thereby stopping many instances of T1687 from being possible.
- T1688detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/acceptance to surface insecure configurations, code, and design flaws; this can detect the BCD edits, registry changes, or malicious COM objects that enable safe mode abuse, but only if those artifacts are introduced or visible during tested changes, not post-deployment runtime abuse on production hosts.
- T1689detects — A.8.29 mandates vulnerability scanning, penetration testing, and code review in development/acceptance testing that surfaces insecure configurations, vulnerable/outdated components, and design flaws enabling downgrade attacks (e.g. weak protocol versions, disabled Secure Boot, missing logging).
- T1689prevents — A.8.29 mandates security testing (including vulnerability scanning, penetration testing, secure coding/config checks, and acceptance testing) during development and before production deployment, which can surface and block many downgrade-vulnerable components or designs; however, it is a process that depends on test scope, environment fidelity, and whether the specific backward-compatibility vector is known and covered in the test plan, leaving a genuine slice unaddressed.
Prevented OWASP Web Top 10 (2025) risks (30)
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).
Why these map — AI rationale (under review)
- A01mitigates — A.8.29's security testing (including access restriction checks, code review, vuln scanning, and pen testing) surfaces and enables remediation of many Broken Access Control defects before production, bounding their realized impact without stopping every bypass (e.g., CSRF, path traversal edge cases).
- A02mitigates — Security testing (including config scanning, vuln scanning, and pen testing in a near-production environment) surfaces and allows remediation of many misconfigurations before they reach production, thereby reducing (but not eliminating) the realized consequences of the weakness class.
- A03finds — A.8.29 explicitly requires vulnerability scanning, code review and penetration testing that surface insecure configurations, insecure code and system vulnerabilities in dependencies or components (including via acquisition evaluation), but does not address build pipelines or signing infrastructure at all.
- A04mitigates — Security testing (including of cryptography per 8.24, secure configs, and vulnerability/penetration testing) surfaces and drives remediation of weak or misused crypto before production, bounding the realized consequence of the weakness without preventing its introduction.
- A05mitigates — A.8.29's security testing (including code review, vuln scanning, and penetration testing) surfaces injection flaws before production and verifies their remediation, which bounds the realized consequence of any that remain; this is mitigation rather than prevention or removal, but only partial because the control is a testing process whose coverage depends on test-plan scope, environment fidelity, and whether the specific injection vector is exercised.
- A06mitigates — A.8.29's security testing (including code review, vuln scanning, and pen testing) surfaces and drives remediation of design-level flaws before production, bounding the realized impact of insecure design without eliminating the baked-in architectural weakness itself.
- A07mitigates — A.8.29's security testing (including auth-function testing, code review, vuln scanning and pen-testing) surfaces authentication failures so they can be fixed before production, which bounds the realized impact of the weakness without stopping the defect from being written.
- A08mitigates — Security testing (including code review, vuln scanning, and pen testing) surfaces integrity failures such as insecure deserialization or unsigned updates so they can be fixed before production, bounding the realized weakness without stopping the root trust-without-verification defect itself.
- A09finds — A.8.29 explicitly requires vulnerability scanning, penetration testing and code review that surface missing or broken logging/alerting (a detectable insecure configuration or functional failure), but this is only one slice of the many security functions and requirements the control tests against.
- A10mitigates — Security testing (including code review, vuln scanning, and penetration testing) surfaces error-handling defects that leak info, fail open, or create inconsistent states, allowing them to be fixed before production and thereby bounding the realized weakness's consequences.
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.