Cyber Resilience

← ISO 27001 Annex A

A.8.26 Technological

Application security requirements

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

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

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

AU-10←P AU-2→P SA-17←M →P SI-10←P SI-11←P RA-3gov SA-3gov SA-4gov SA-8gov

Why these map — AI rationale (under review)

SA-4mostlyaligns with — Both controls require security requirements—including authentication, access segregation, input validation, encryption, and non-repudiation—to be explicitly defined and incorporated during system or application acquisition and development.
SA-8mostlyaligns with — The ISO control’s enumerated security requirements map directly to the engineering principles that NIST expects organizations to apply when designing applications to enforce confidentiality, integrity, and resilience.
AC-3partialaligns with — Defining segregation of access, authorization limits, and output controls within application requirements supports the access-enforcement mechanisms that AC-3 implements at runtime.
AU-2partialaligns with — Mandating transaction logging and monitoring as part of application requirements contributes to the event-logging capability that AU-2 establishes for security-relevant activities.
SA-17partialaligns with — Specifying application-level security requirements such as authentication, access controls, and non-repudiation contributes to the security and privacy architecture and design activities that SA-17 governs.
SC-28partialaligns with — Including requirements for protecting data at rest in application security specifications supports the objective of SC-28 to safeguard information stored on systems.
SC-8partialaligns with — Requiring encryption and integrity protection for data in transit within application specifications aligns with the transmission confidentiality and integrity protections mandated by SC-8.
AC-3covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
SA-4implements — A.8.26's mandate to identify/address all security requirements when acquiring applications directly operationalizes the inclusion of those exact security/functional/assurance requirements in acquisition contracts that SA-4 requires
SA-8implements — A.8.26's governance mandate to identify/address security requirements when developing/acquiring applications directly operationalizes the application of security engineering principles throughout the SDLC that sa-8 names, within the shared engineering domain (but without naming the specific principles).
SC-28covers — 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.
SC-8covers — 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 (22)

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

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

PR.PS-06←M GV.OC-03gov ID.RA-05gov PR.AA-05gov PR.DS-01gov PR.DS-02gov PR.IR-01gov PR.PS-01gov

Why these map — AI rationale (under review)

ID.RA-05mostlyaligns with — The ISO control's risk-assessment-driven derivation of application security requirements directly supports the CSF outcome of using threat, vulnerability, and impact information to understand inherent risk and prioritize responses.
PR.AA-05mostlyaligns with — Specifying segregation of duties, access levels, and authorization rules for application functions and data aligns with the CSF outcome of defining, managing, and enforcing access permissions and entitlements.
PR.DS-01mostlyaligns with — Requirements for protecting data at rest, in transit, and in use, plus encryption and integrity controls, map to the CSF outcome of safeguarding the confidentiality, integrity, and availability of data-at-rest.
PR.DS-02mostlyaligns with — Mandating secure encryption of communications and protection of data in transit directly addresses the CSF outcome of protecting the confidentiality, integrity, and availability of data-in-transit.
GV.OC-03partialaligns with — Incorporating legal, statutory, regulatory, and privacy obligations into application security requirements aligns with the CSF outcome of understanding and addressing cybersecurity-related legal and contractual requirements.
PR.IR-01partialaligns with — Resilience requirements against malicious attacks and unintentional disruptions support the CSF outcome of protecting networks and environments from unauthorized logical access and usage.
PR.PS-01partialaligns with — Input validation, integrity checks, and automated approval controls constitute configuration and control practices that align with the CSF outcome of establishing and applying configuration management.
GV.OC-03implements — Assessed as NOT holding by the authoring instrument at v1.19-2026-08-23. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
ID.RA-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
PR.AA-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
PR.DS-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.DS-02implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
PR.IR-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.

Related OWASP ASVS 5.0 requirements (15)

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

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

V1.2.4→P V11.1.1←P →M V14.1.1←M →F V16.1.1←P →P V16.5.1→P V2.1.1←M →F V6.1.1←M →M V7.1.1←P V8.1.1←M →F

Why these map — AI rationale (under review)

V14.1.1fullcovers — Requiring classification of information processed by the application and the associated protection levels satisfies the ASVS demand for documented identification and classification of all sensitive data into protection tiers.
V2.1.1fullcovers — The ISO requirement to identify and document input validation rules and business-process expectations directly satisfies the ASVS mandate that application documentation define how data items are validated against expected schemas and business rules.
V8.1.1fullcovers — Defining segregation-of-access and authorization rules for data and functions in the ISO control meets the ASVS requirement that authorization documentation explicitly state function-level and data-specific access restrictions based on consumer permissions.
V11.1.1mostlyaligns with — Mandating secure encryption of communications and protection of data at rest, in transit, and in use aligns with the ASVS requirement for a documented cryptographic-key-management policy and lifecycle.
V6.1.1mostlycovers — Specifying authentication-related trust levels and controls in the application security requirements fulfills the ASVS need for documented rate-limiting, anti-automation, and adaptive-response measures that protect authentication functions.
V1.2.4partialaligns with — The explicit call for resilience against SQL injection through input validation and parameterized queries aligns with the ASVS requirement that database queries use parameterization or equivalent safe mechanisms.
V16.1.1partialaligns with — Including transaction-logging, monitoring, and non-repudiation requirements in the security specification partially satisfies the ASVS need for an inventory documenting what security events are logged at each layer.
V16.5.1partialaligns with — Requiring controlled error-message handling in the ISO control aligns with the ASVS mandate that generic messages be returned for unexpected or security-sensitive errors to avoid information leakage.

Related weaknesses / CWE (740)

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

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

CWE-1004←P →P CWE-1007←P →P CWE-102←P →P CWE-1021←P →P CWE-1022←P →P CWE-1023←P →P CWE-1024←P CWE-1025←P →P CWE-1039←P →P CWE-1049←P →P CWE-1057→P CWE-1058←P →P CWE-1066←P →P CWE-1067←P CWE-1068→P CWE-1083←P →P CWE-1088←P →P CWE-1091←P →P CWE-1103←P →P CWE-111←P →P CWE-1118←P CWE-112←P →P CWE-113←P →P CWE-114←P →P CWE-115←P →P CWE-116←P →P CWE-1173←P →P CWE-1174←P →P CWE-118←P →P CWE-119←P →P CWE-12→P CWE-120←P →P CWE-1204→P CWE-121←P →P CWE-122←P →P CWE-123←P →P CWE-1236←P →P CWE-124←P →P CWE-1240←P →P CWE-125←P →P CWE-1250←P →P CWE-1254←P →P CWE-126←P →P CWE-127←P →P CWE-1270←P →P CWE-1275←P →P CWE-128←P →P CWE-1284←P →P CWE-1285←P →P CWE-1286←P →P CWE-1287←P →P CWE-1288←P →P CWE-1289←P →P CWE-129←P →P CWE-130←P →P CWE-131←P →P CWE-1320←P →P CWE-1321←P →P CWE-1333→P CWE-1335←P →P CWE-1336←P →P CWE-134←P →P CWE-135←P →P CWE-138←P →P CWE-1385←P →P CWE-1386←P →P CWE-1389←P →P CWE-140←P →P CWE-141←P →P CWE-142←P →P CWE-143←P →P CWE-144←P →P CWE-145←P →P CWE-146←P →P CWE-147←P →P CWE-148←P →P CWE-149←P →P CWE-150←P →P CWE-153←P →P CWE-154←P →P CWE-155←P →P CWE-156←P →P CWE-157←P →P CWE-158←P →P CWE-159←P →P CWE-160←P →P CWE-162←P →P CWE-164←P →P CWE-166←P →P CWE-167←P →P CWE-168←P →P CWE-170←P →P CWE-172←P →P CWE-173←P →P CWE-176←P →P CWE-177←P →P CWE-178←P →P CWE-179←P →P CWE-180←P →P CWE-182←P →P CWE-183←P →P CWE-184←P →P CWE-185←P →P CWE-186←P →P CWE-187←P →P CWE-188←P →P CWE-190←P CWE-191←P →P CWE-192←P →P CWE-193←P →P CWE-194←P →P CWE-195←P →P CWE-196←P →P CWE-197←P CWE-198←P →P CWE-20→P CWE-200→P CWE-201←P →P CWE-202←P →P CWE-204←P →P CWE-209→P CWE-210←P →P CWE-219←P →P CWE-22←P →P CWE-228←P →P CWE-229←P →P CWE-23←P →P CWE-230←P →P CWE-231←P →P CWE-232←P →P CWE-233←P →P CWE-234←P →P CWE-235←P →P CWE-236←P →P CWE-237←P →P CWE-239←P →P CWE-24←P →P CWE-240←P →P CWE-241←P →P CWE-248←P →P CWE-25←P →P CWE-252←P →P CWE-253←P →P CWE-26←P →P CWE-27←P →P CWE-28←P →P CWE-284→P CWE-287→P CWE-288→P CWE-29←P →P CWE-290←P →P CWE-293→P CWE-294→P CWE-297←P →P CWE-30←P →P CWE-301→P CWE-302←P →P CWE-303←P →P CWE-304→P CWE-31←P →P CWE-311→P CWE-315→P CWE-317→P CWE-32←P →P CWE-322→P CWE-328→P CWE-337→P CWE-338→P CWE-34←P →P CWE-342→P CWE-343→P CWE-344→P CWE-345→P CWE-346←P →P CWE-348←P →P CWE-349←P →P CWE-35←P →P CWE-350←P →P CWE-351←P →P CWE-353←P →P CWE-354←P →P CWE-356←P →P CWE-357←P →P CWE-358←P →P CWE-36←P →P CWE-362←P →P CWE-363←P →P CWE-366←P →P CWE-369←P →P CWE-37←P →P CWE-372←P →P CWE-374←P →P CWE-377←P →P CWE-378←P →P CWE-38←P →P CWE-384→P CWE-39←P →P CWE-391←P →P CWE-392←P →P CWE-394←P →P CWE-40←P →P CWE-400→P CWE-401←P →P CWE-409→P CWE-41←P →P CWE-412→P CWE-413←P →P CWE-415→P CWE-416←P →P CWE-42←P →P CWE-422←P →P CWE-425→P CWE-43←P →P CWE-430←P →P CWE-431←P →P CWE-433←P →P CWE-435←P →P CWE-436←P →P CWE-437←P →P CWE-44←P →P CWE-440←P →P CWE-441←P →P CWE-444←P →P CWE-446←P →P CWE-447←P →P CWE-448←P →P CWE-449←P →P CWE-450←P →P CWE-451←P →P CWE-454←P →P CWE-456←P →P CWE-457→P CWE-46←P →P CWE-460←P →P CWE-462←P →P CWE-466←P →P CWE-469←P CWE-470←P →P CWE-471→P CWE-472←P →P CWE-473←P →P CWE-475←P →P CWE-476←P →P CWE-488←P →P CWE-491←P →P CWE-495←P →P CWE-499←P →P CWE-5→P CWE-50←P →P CWE-501←P →P CWE-523→P CWE-525←P →P CWE-526←P →P CWE-532→P CWE-535→P CWE-539←P →P CWE-541→P CWE-544←P →P CWE-548←P →P CWE-550←P →P CWE-551←P →P CWE-556→P CWE-564←P →P CWE-565←P →P CWE-566←P →P CWE-567←P →P CWE-57→P CWE-573←P →P CWE-588←P →P CWE-59←P →P CWE-598←P →P CWE-599→P CWE-6→P CWE-600←P →P CWE-602←P →P CWE-603←P →P CWE-606←P →P CWE-610←P →P CWE-611←P →P CWE-614→P CWE-616←P →P CWE-617←P →P CWE-618←P →P CWE-621←P →P CWE-622←P →P CWE-623→P CWE-624←P →P CWE-625←P →P CWE-626←P →P CWE-627←P →P CWE-639→P CWE-640→P CWE-641←P →P CWE-642→P CWE-643←P →P CWE-644←P →P CWE-646←P →P CWE-647←P →P CWE-648←P →P CWE-649←P →P CWE-650←P →P CWE-652←P →P CWE-66←P →P CWE-667←P →P CWE-67→P CWE-674→P CWE-675←P →P CWE-680←P →P CWE-681←P →P CWE-682←P →P CWE-684←P →P CWE-686←P →P CWE-687←P →P CWE-690←P →P CWE-692→P CWE-695←P →P CWE-697←P →P CWE-698←P →P CWE-704←P →P CWE-706←P →P CWE-707←P →P CWE-73←P →P CWE-74←P →P CWE-749←P →P CWE-75←P →P CWE-754←P →P CWE-755←P →P CWE-756←P →P CWE-757→P CWE-759→P CWE-76→P CWE-760→P CWE-763←P →P CWE-767→P CWE-768←P CWE-77←P →P CWE-774←P →P CWE-776←P →P CWE-777→P CWE-780→P CWE-782→P CWE-784→P CWE-786←P →P CWE-787←P →P CWE-788←P →P CWE-789←P →P CWE-790←P →P CWE-791←P →P CWE-792←P →P CWE-794←P →P CWE-799←P →P CWE-80←P →P CWE-804←P →P CWE-805←P →P CWE-807←P →P CWE-81←P →P CWE-82←P →P CWE-820←P →P CWE-821←P →P CWE-822←P →P CWE-823←P →P CWE-824←P CWE-825→P CWE-826←P →P CWE-827←P →P CWE-83←P →P CWE-830←P →P CWE-834←P →P CWE-835→P CWE-837←P →P CWE-838←P →P CWE-839→P CWE-84←P →P CWE-841←P →P CWE-843←P →P CWE-85←P →P CWE-86←P →P CWE-87←P →P CWE-88←P →P CWE-90←P →P CWE-908←P →P CWE-909→P CWE-91←P →P CWE-910←P →P CWE-911←P →P CWE-912←P →P CWE-913←P →P CWE-914←P →P CWE-915←P →P CWE-917←P →P CWE-923→P CWE-924←P →P CWE-925←P →P CWE-926←P →P CWE-927←P →P CWE-93←P →P CWE-939←P →P CWE-940→P CWE-941→P CWE-942←P →P CWE-943←P →P CWE-95←P →P CWE-96←P →P CWE-97←P →P CWE-98←P →P CWE-99←P →P

Why these map — AI rationale (under review)

CWE-1118nonemitigates — Application security requirements include specifying error-handling mechanisms.
CWE-190noneprevents — Application security requirements include bounds checking and safe arithmetic to avoid overflow conditions.
CWE-296nonemitigates — Application security requirements include proper TLS/certificate handling.
CWE-1004prevents — Application security requirements can mandate HttpOnly on sensitive cookies.
CWE-1007prevents — Application security requirements can mandate visual safeguards against homoglyph confusion.
CWE-102prevents — Application security requirements can mandate unique validation-form names and validation coverage.
CWE-1021prevents — Application security requirements can mandate frame-ancestors / X-Frame-Options, directly addressing UI redressing risks.
CWE-1022prevents — Application security requirements can mandate explicit handling of external links and window.opener protections.
CWE-1023prevents — Application security requirements can mandate complete multi-factor comparisons, but the control is broader than this single weakness.
CWE-1025prevents — Application security requirements can specify correct comparison criteria and validation rules.
CWE-1039prevents — Application security requirements can mandate detection and handling of adversarial perturbations in automated recognition systems.
CWE-1049prevents — Application security requirements can mandate query-performance and data-volume constraints.
CWE-1057prevents — Application security requirements can specify central data-manager usage, mitigating the weakness.
CWE-1058prevents — Application security requirements can specify thread-safety and immutability rules that mitigate unsafe static state.
CWE-1066prevents — Application security requirements include specifying correct serialization methods for data elements.
CWE-1068prevents — Application security requirements can reference design, but do not themselves ensure implementation matches that design.
CWE-1083prevents — Application security requirements can specify exclusive use of the designated data manager, reducing the likelihood of direct access code.
CWE-1088prevents — Application security requirements typically mandate timeout settings for remote resource access.
CWE-1091prevents — Application security requirements can explicitly require deterministic cleanup of objects and resources.
CWE-1103prevents — Application security requirements can specify platform-independence or equivalent functionality across target platforms.
CWE-111prevents — Application security requirements can specify safe JNI usage and validation of native libraries.
CWE-112prevents — Application security requirements explicitly call for validation of external data formats including XML.
CWE-113prevents — Application security requirements explicitly call for controls against injection flaws including HTTP header manipulation.
CWE-114prevents — Application security requirements can mandate validation of external inputs and libraries.
CWE-115prevents — Application security requirements explicitly call for robust input handling and sanitization to avoid misinterpretation.
CWE-116prevents — Application security requirements include explicit rules for safe output handling and encoding.
CWE-1173prevents — Application security requirements explicitly call for proper input validation mechanisms.
CWE-1174prevents — Application security requirements explicitly call for model-level validation controls.
CWE-118prevents — Application security requirements can mandate bounds checking and safe indexing practices.
CWE-119prevents — Application security requirements can specify memory-safety rules, but do not prescribe implementation details.
CWE-12prevents — Application security requirements can mandate custom error pages as a non-functional security control.
CWE-120prevents — Application security requirements can specify input-size validation and safe buffer handling to mitigate classic buffer overflows.
CWE-1204prevents — Application security requirements can specify cryptographic standards including IV uniqueness and unpredictability.
CWE-121prevents — Application security requirements can specify buffer-size and input-validation rules.
CWE-122prevents — Application security requirements can specify bounds-checking and safe memory APIs that mitigate heap overflows.
CWE-123prevents — Application security requirements can mandate input validation and bounds checking that mitigate arbitrary write conditions.
CWE-1236prevents — Application security requirements include rules for safe CSV generation and handling of untrusted data.
CWE-124prevents — Application security requirements can specify buffer-size and pointer-safety rules.
CWE-1240prevents — Application security requirements can specify approved cryptographic standards and disallow risky primitives.
CWE-125prevents — Application security requirements include explicit bounds and memory-safety specifications that mitigate buffer over-reads.
CWE-1250prevents — Application security requirements may specify consistency rules but do not guarantee their implementation.
CWE-1254prevents — Application security requirements can explicitly call for constant-time string comparisons in authentication and cryptographic code.
CWE-126prevents — Application security requirements can specify buffer-size and bounds-checking rules.
CWE-127prevents — Application security requirements can specify safe buffer handling and bounds checking.
CWE-1270prevents — Application security requirements explicitly call for correct token issuance and validation mechanisms.
CWE-1275prevents — Application security requirements can mandate SameSite attributes on sensitive cookies.
CWE-128prevents — Application security requirements can mandate integer overflow protection and safe arithmetic.
CWE-1284prevents — Application security requirements explicitly call for validation of size/length inputs, mitigating CWE-1284.
CWE-1285prevents — Application security requirements typically mandate bounds checking and validation of offsets/indices.
CWE-1286prevents — Application security requirements explicitly call for validation of input syntax.
CWE-1287prevents — Application security requirements explicitly include validation of input data types and formats.
CWE-1288prevents — Application security requirements include validation of complex inputs and cross-field consistency.
CWE-1289prevents — Application security requirements can mandate input validation rules that prevent unsafe equivalence checks.
CWE-129prevents — Application security requirements include validation of untrusted input used for indexing or addressing memory structures.
CWE-130prevents — Application security requirements include explicit rules for handling message lengths and data structures.
CWE-131prevents — Application security requirements can specify buffer-size validation rules.
CWE-1320prevents — Application security requirements can mandate protection of outbound alerts and signals.
CWE-1321prevents — Application security requirements explicitly call for safeguards against unsafe object attribute manipulation.
CWE-1333prevents — Application security requirements can specify input-validation rules that limit regex complexity.
CWE-1335prevents — Application security requirements can mandate input validation and range checks that avoid invalid shift counts.
CWE-1336prevents — Application security requirements explicitly call for neutralizing special elements in template engines.
CWE-134prevents — Application security requirements can specify safe formatting functions and ban uncontrolled format strings.
CWE-135prevents — Application security requirements can mandate proper handling of multi-byte character encodings to prevent length miscalculations.
CWE-138prevents — Application security requirements explicitly call for controls against injection and malformed input that cause CWE-138.
CWE-1385prevents — Application security requirements can mandate origin validation for WebSocket communications.
CWE-1386prevents — Application security requirements can explicitly require protection against Windows reparse-point attacks.
CWE-1389prevents — Application security requirements include explicit handling of numeric input formats and bases.
CWE-140prevents — Application security requirements include input validation and output encoding that mitigate delimiter mishandling.
CWE-141prevents — Application security requirements explicitly call for neutralizing special characters in inputs passed to downstream components.
CWE-142prevents — Application security requirements include rules for safe handling of untrusted input to prevent injection-style flaws.
CWE-143prevents — Application security requirements include explicit rules for neutralizing special characters such as record delimiters.
CWE-144prevents — Application security requirements typically include rules for neutralizing special characters such as line delimiters.
CWE-145prevents — Application security requirements include explicit rules for sanitizing inputs that could be interpreted as section delimiters.
CWE-146prevents — Application security requirements explicitly call for controls against injection and delimiter-based attacks.
CWE-147prevents — Application security requirements explicitly call for handling of special input elements to avoid injection or termination attacks.
CWE-148prevents — Application security requirements can mandate proper validation of leading characters or sequences.
CWE-149prevents — Application security requirements explicitly call for neutralization of special characters such as quotes.
CWE-150prevents — Application security requirements explicitly call for controls against injection and malformed input sequences.
CWE-153prevents — Application security requirements explicitly call for neutralizing special elements before downstream processing.
CWE-154prevents — Application security requirements explicitly call for controls against injection-style weaknesses including improper delimiter handling.
CWE-155prevents — Application security requirements include rules for neutralizing special characters before downstream processing.
CWE-156prevents — Application security requirements typically mandate proper input validation and neutralization of special characters including whitespace.
CWE-157prevents — Application security requirements include rules for proper handling of paired delimiters in input processing.
CWE-158prevents — Application security requirements include explicit rules for neutralizing dangerous characters such as NUL.
CWE-159prevents — Application security requirements explicitly call for controls against malformed or malicious input.
CWE-160prevents — Application security requirements explicitly call for neutralizing special characters in input handling.
CWE-162prevents — Application security requirements can mandate proper neutralization of trailing special elements in input processing.
CWE-164prevents — Application security requirements explicitly call for controls against injection and malformed input that cause this weakness.
CWE-166prevents — Application security requirements can mandate handling of missing delimiters or markers in input.
CWE-167prevents — Application security requirements explicitly call for robust input validation against malformed or special-element data.
CWE-168prevents — Application security requirements typically mandate robust input validation and sanitization.
CWE-170prevents — Application security requirements can explicitly call for proper string termination and buffer handling.
CWE-172prevents — Application security requirements can mandate proper encoding/decoding to prevent data corruption or injection.
CWE-173prevents — Application security requirements can mandate canonicalization and encoding validation to prevent alternate-encoding bypasses.
CWE-176prevents — Application security requirements include proper handling of character encodings and input sanitization.
CWE-177prevents — Application security requirements explicitly call for input validation and canonicalization, directly preventing improper URL decoding.
CWE-178prevents — Application security requirements must specify case handling for identifiers and paths.
CWE-179prevents — Application security requirements include input validation rules that must be applied after protective transformations.
CWE-180prevents — Application security requirements include proper input handling to prevent validation-before-canonicalization flaws.
CWE-182prevents — Application security requirements include rules for safe data transformation and output encoding.
CWE-183prevents — Application security requirements can mandate strict, minimal allow-lists and input validation rules that prevent overly permissive lists.
CWE-184prevents — Application security requirements can mandate complete input validation rules, but the control itself does not prescribe how to build those rules.
CWE-185prevents — Application security requirements can mandate correct regex design and testing.
CWE-186prevents — Application security requirements explicitly call for correct validation rules, reducing the risk of overly restrictive regex.
CWE-187prevents — Application security requirements can mandate full, exact comparisons for sensitive operations.
CWE-188prevents — Application security requirements can mandate explicit data-structure and protocol-layout specifications.
CWE-191prevents — Application security requirements include bounds checking and safe arithmetic to avoid underflow conditions.
CWE-192prevents — Application security requirements can mandate safe integer handling and range checks.
CWE-193prevents — Application security requirements can specify bounds-checking and input validation to prevent off-by-one errors.
CWE-194prevents — Application security requirements can mandate safe type handling and input validation to avoid sign-extension bugs.
CWE-195prevents — Application security requirements can specify safe integer handling and type-conversion rules.
CWE-196prevents — Application security requirements can specify safe handling of numeric types and bounds checking.
CWE-198prevents — Application security requirements include correct interpretation of external data formats and byte ordering.
CWE-20prevents — Mandating input controls that include integrity checks and input validation ensures that untrusted data is examined before use, blocking the root cause of many injection and malformed-data weaknesses.
CWE-200prevents — Requiring classification of information, privacy needs, and protection of confidential data leads to controls that limit unintended disclosure of sensitive information.
CWE-201prevents — Application-security requirements can mandate filtering or omission of sensitive fields before transmission.
CWE-202prevents — Application security requirements can mandate controls against inference in query interfaces.
CWE-204prevents — Application security requirements typically mandate consistent, non-revealing error messages.
CWE-209prevents — Application security requirements can specify safe error messaging.
CWE-210prevents — Application security requirements can explicitly forbid inclusion of sensitive data in error messages.
CWE-219mitigates — Application security requirements can mandate that sensitive files are not stored under the web root.
CWE-22prevents — Application security requirements include rules for safe file handling and canonicalization.
CWE-228prevents — Application security requirements include explicit rules for input validation and malformed-data handling.
CWE-229prevents — Application security requirements explicitly call for validation of all input parameters and fields.
CWE-23prevents — Application security requirements explicitly call for controls against path traversal and other injection flaws.
CWE-230prevents — Application security requirements can mandate explicit handling of missing parameter values.
CWE-231prevents — Application security requirements typically mandate strict input validation and parameter count checks.
CWE-232prevents — Application security requirements include validation of all parameters and handling of unsupported values.
CWE-233prevents — Application security requirements explicitly call for validation of inputs and parameters, mitigating missing or undefined arguments.
CWE-234prevents — Application security requirements include explicit specification of function interfaces and mandatory parameter validation.
CWE-235prevents — Application security requirements typically mandate strict parameter validation and rejection of unexpected inputs.
CWE-236prevents — Application security requirements mandate complete parameter specifications and error handling for unsupported inputs.
CWE-237prevents — Application security requirements typically mandate robust parsing and validation of structured data inputs.
CWE-239prevents — Application security requirements can mandate handling of incomplete or malformed inputs, mitigating this weakness.
CWE-24prevents — Application security requirements explicitly call for controls against path traversal in file-handling functions.
CWE-240prevents — Application security requirements include rules for consistent data structures and message formats.
CWE-241prevents — Application security requirements typically mandate strong input validation and type enforcement to prevent malformed data processing.
CWE-248prevents — Application security requirements typically mandate robust error and exception handling.
CWE-25prevents — Application security requirements explicitly call for controls against path traversal and directory escape attacks.
CWE-252prevents — Application security requirements include input/output validation and error handling that covers return-value checks.
CWE-253prevents — Application security requirements include robust error handling that mitigates incorrect return-value checks.
CWE-26prevents — Application security requirements explicitly call for controls against path traversal and other injection flaws.
CWE-27prevents — Application security requirements include explicit rules for safe file-path handling and canonicalization.
CWE-28prevents — Application security requirements include explicit rules for safe file-path handling and directory confinement.
CWE-284prevents — Specifying required segregation of access and levels of access to data and functions directly forces the definition of authorization rules that stop improper access control weaknesses from being introduced.
CWE-287prevents — Defining the required level of trust in entity identity and the authentication mechanisms to achieve it ensures that authentication is explicitly addressed rather than omitted.
CWE-288prevents — Application security requirements can specify authentication on all channels but do not enforce it at runtime.
CWE-29prevents — Application security requirements can mandate input validation and path canonicalization to block traversal sequences.
CWE-290prevents — Application security requirements can include anti-spoofing controls but are not limited to them.
CWE-293prevents — Application security requirements would mandate proper authentication design, indirectly reducing this weakness.
CWE-294prevents — Application security requirements can mandate replay-resistant authentication designs, but the control itself does not prescribe the technical measures.
CWE-297prevents — Application security requirements include secure communication and certificate validation for external services.
CWE-30prevents — Application security requirements explicitly call for controls against path traversal and directory-escape attacks.
CWE-301prevents — Application security requirements can mandate secure authentication design, indirectly reducing reflection risk.
CWE-302prevents — Application security requirements can mandate cryptographic or server-side checks for all authentication tokens.
CWE-303prevents — Application security requirements can specify correct authentication algorithm use but do not guarantee correct implementation.
CWE-304prevents — Application security requirements may specify complete auth flows, but the control itself is broader.
CWE-31prevents — Application security requirements explicitly call for controls against path traversal and other injection flaws.
CWE-311prevents — Explicitly calling for protection of data in transit and at rest, plus secure encryption of communications, drives the implementation of encryption that prevents clear-text exposure of sensitive information.
CWE-315prevents — Defines application security requirements that should include cookie protection but does not explicitly address it.
CWE-317prevents — Application security requirements may include masking rules, yet the control is wider than this CWE.
CWE-32prevents — Application security requirements explicitly call for controls against path traversal and directory-escape attacks.
CWE-322prevents — Application security requirements can mandate authenticated key exchange for any cryptographic operations.
CWE-328prevents — Application security requirements can specify strong hashing, but the control is broader.
CWE-337prevents — Application security requirements can specify cryptographic controls that mitigate predictable seeds.
CWE-338prevents — Application security requirements can specify cryptographically strong random number generation.
CWE-34prevents — Application security requirements explicitly call for controls against path traversal and other injection flaws.
CWE-342prevents — Application security requirements can specify cryptographically secure random values.
CWE-343prevents — Application security requirements include proper random-number generation for security functions.
CWE-344prevents — Application security requirements can mandate configurable values, but the control itself does not enforce it.
CWE-345prevents — Application security requirements can mandate data authenticity verification mechanisms.
CWE-346prevents — Application security requirements explicitly call for origin validation of inputs and communications.
CWE-348prevents — Application security requirements can mandate trusted data sources and input validation, directly addressing the weakness.
CWE-349prevents — Application security requirements explicitly call for strict separation and validation of trusted versus untrusted data sources.
CWE-35prevents — Application security requirements include rules for safe file-path construction and canonicalization.
CWE-350prevents — Application security requirements can mandate authenticated host verification instead of reverse DNS.
CWE-351prevents — Application security requirements can mandate explicit type handling and validation rules.
CWE-353prevents — Application security requirements can specify integrity checks for data transmission.
CWE-354prevents — Application security requirements include integrity checks on messages and data, mitigating improper validation.
CWE-356prevents — Application security requirements include user warnings for dangerous operations.
CWE-357prevents — Application security requirements include clear, effective user warnings for dangerous operations.
CWE-358prevents — Application security requirements explicitly call for correct implementation of standardized security mechanisms.
CWE-36prevents — Application security requirements typically mandate controls against path traversal in file-access functions.
CWE-362prevents — Application security requirements can specify thread-safety and locking rules, but do not prescribe implementation details.
CWE-363prevents — Application security requirements can mandate atomic file operations, yet the control is broader than this specific race condition.
CWE-366prevents — Application security requirements can mandate thread-safety and locking controls.
CWE-369prevents — Application security requirements can mandate checks for zero denominators and safe arithmetic handling.
CWE-37prevents — Application security requirements can mandate input validation to block absolute path traversal.
CWE-372prevents — Explicit application security requirements can mandate state-transition validation and error-state handling.
CWE-374prevents — Application security requirements can explicitly require defensive copies or immutability when data crosses trust boundaries.
CWE-377prevents — Application security requirements can specify secure temporary-file creation and access controls.
CWE-378prevents — Application security requirements include secure creation and permissioning of temporary files.
CWE-38prevents — Application security requirements explicitly call for validation of file-path inputs to block traversal attacks.
CWE-384prevents — Application-security requirements can specify session handling, yet the weakness fix alone does not meet the broader requirement.
CWE-39prevents — Application security requirements can mandate input validation to block drive-letter path traversal.
CWE-391prevents — Application security requirements include explicit handling of error conditions.
CWE-392prevents — Application security requirements typically mandate explicit error condition reporting to calling components.
CWE-394prevents — Application security requirements include proper validation of function results and error conditions.
CWE-40prevents — Application security requirements can mandate input validation to reject malicious UNC paths.
CWE-400prevents — Requiring resilience against unintentional disruptions and specifying automated controls such as approval limits reduces the likelihood that resource-exhaustion conditions will be triggered or remain unchecked.
CWE-401prevents — Application security requirements can specify explicit memory-release rules, partially mitigating the weakness.
CWE-409prevents — Application security requirements can mandate limits on decompression size and ratio.
CWE-41prevents — Application security requirements can mandate canonicalization and input validation to block path equivalence.
CWE-412prevents — Application security requirements can mandate that locks remain within the intended control sphere.
CWE-413prevents — Application security requirements can mandate exclusive-access controls and locking mechanisms.
CWE-415prevents — Application security requirements can mandate memory-safety rules that reduce double-free risk.
CWE-416prevents — Application security requirements can specify memory-management rules that mitigate use-after-free.
CWE-42prevents — Application security requirements can mandate input validation to reject ambiguous path forms.
CWE-422prevents — Application security requirements can specify authenticated IPC and message-source verification to block unauthorized Windows messages.
CWE-425prevents — Application security requirements may specify authorization rules, but the control does not implement them.
CWE-43prevents — Application security requirements include validation rules that can block ambiguous path inputs.
CWE-430prevents — Application security requirements can mandate explicit handler-to-object mapping rules.
CWE-431prevents — Application security requirements typically mandate complete handler coverage for expected and unexpected conditions.
CWE-433prevents — Application security requirements include rules for web content delivery and server-side file handling.
CWE-435prevents — Explicit application security requirements can specify expected component interactions.
CWE-436prevents — Explicit application security requirements can mandate unambiguous protocol and data-format specifications that prevent divergent interpretations.
CWE-437prevents — Application security requirements can specify the need for exhaustive endpoint feature, behavior, and state modeling.
CWE-44prevents — Application security requirements can mandate path validation rules that block internal-dot traversal.
CWE-440prevents — Application security requirements explicitly define expected behavior that must be met.
CWE-441prevents — Application-security requirements can mandate explicit source-identity preservation and authorization checks on forwarded requests.
CWE-444prevents — Application security requirements can mandate strict HTTP message validation and canonicalization.
CWE-446prevents — Application security requirements should specify correct UI behavior for security controls, reducing the chance of misleading user feedback.
CWE-447prevents — Application security requirements should specify that advertised security functions must be fully implemented.
CWE-448prevents — Application security requirements can mandate warnings or removal of deprecated UI functions.
CWE-449prevents — Application security requirements explicitly capture correct user-action mapping and expected behavior.
CWE-450prevents — Application security requirements can mandate clear, secure interpretation of user input and explicit user confirmation when needed.
CWE-451prevents — Application security requirements can mandate proper display and validation of critical information in the UI.
CWE-454prevents — Application security requirements explicitly require protection against untrusted initialization of critical internal state.
CWE-456prevents — Application security requirements can explicitly require variable initialization to avoid undefined behavior.
CWE-457prevents — Application security requirements can specify initialization rules, but the control itself does not directly address the weakness.
CWE-46prevents — Application security requirements can mandate input validation for path names, reducing trailing-space equivalence issues.
CWE-460prevents — Application security requirements can specify robust exception handling and resource-release rules.
CWE-462prevents — Application security requirements can mandate unique-key constraints and data-integrity rules.
CWE-466prevents — Application security requirements can mandate pointer safety and range validation to avoid returning invalid addresses.
CWE-470prevents — Application security requirements can explicitly prohibit or constrain reflection based on untrusted input.
CWE-471prevents — Application security requirements can mandate integrity protections for data declared immutable.
CWE-472prevents — Application security requirements explicitly call for validation of all inputs, including hidden fields, mitigating CWE-472.
CWE-473prevents — Application security requirements explicitly call for protection against tainted input sources such as query parameters and cookies.
CWE-475prevents — Application security requirements can mandate explicit input validation and defined behavior for API parameters.
CWE-476prevents — Application security requirements can specify input validation and pointer-safety rules.
CWE-488prevents — Application security requirements explicitly call for proper session isolation and state management.
CWE-491prevents — Application security requirements can mandate defensive coding rules that prevent unsafe cloning.
CWE-495prevents — Application security requirements can explicitly require defensive-copy or immutable return objects to avoid exposing internal state.
CWE-499prevents — Application security requirements can specify that classes holding sensitive data must not be serializable.
CWE-5prevents — Application security requirements may specify encryption for data in transit as a functional requirement.
CWE-50prevents — Application security requirements include rules for safe path handling and canonicalization.
CWE-501prevents — Application security requirements include explicit trust-boundary definitions and data classification at interfaces.
CWE-523prevents — Specifies application security requirements that can include secure credential transmission.
CWE-525prevents — Application security requirements can explicitly require no-cache headers or cache-control directives for sensitive pages.
CWE-526prevents — Application security requirements can mandate that sensitive data not be stored unencrypted in environment variables.
CWE-532prevents — Requiring restrictions on free-text fields and proper error-message handling stops developers from embedding or leaking sensitive data into logs or diagnostic output.
CWE-535prevents — Application security requirements can mandate safe error handling but do not directly address this weakness.
CWE-539prevents — Application security requirements can explicitly prohibit sensitive data in persistent cookies.
CWE-541prevents — Application security requirements can mandate exclusion of secrets from include files.
CWE-544prevents — Application security requirements can mandate standardized error handling as a non-functional requirement.
CWE-548prevents — Application security requirements can mandate disabling directory indexing and enforcing proper access controls on web directories.
CWE-550prevents — Application security requirements can specify safe error handling and generic messages.
CWE-551prevents — Application security requirements should mandate correct authorization order after canonicalization.
CWE-556mitigates — Application security requirements can mandate that impersonation is disabled or tightly scoped.
CWE-564prevents — Application security requirements include secure query construction and ORM parameter binding.
CWE-565prevents — Application security requirements can mandate cookie validation, integrity protection, and server-side session handling.
CWE-566prevents — Defining application security requirements includes mandatory server-side authorization and parameterized queries that block this weakness.
CWE-567prevents — Application security requirements can mandate proper synchronization primitives for shared data.
CWE-57prevents — Defines application security requirements that should mandate path-handling controls.
CWE-573prevents — Application security requirements explicitly capture specification compliance obligations that callers must follow.
CWE-588prevents — Application security requirements can specify safe type handling and pointer-use rules.
CWE-59prevents — Application security requirements can explicitly require safe handling of symbolic links and path traversal.
CWE-598prevents — Application security requirements should mandate avoiding sensitive data in query strings.
CWE-599prevents — Application security requirements may specify certificate validation but do not mandate the specific OpenSSL API usage.
CWE-6prevents — Application security requirements can specify minimum session-ID length as a functional control.
CWE-600prevents — Application security requirements include explicit handling of runtime errors and sensitive information disclosure.
CWE-602prevents — Application security requirements explicitly call for server-side enforcement of security mechanisms.
CWE-603prevents — Defines application security requirements that include server-side authentication enforcement.
CWE-606prevents — Application security requirements include input validation rules that mitigate excessive looping from untrusted data.
CWE-610prevents — Application security requirements explicitly call for controls against externally supplied resource identifiers.
CWE-611prevents — Application security requirements explicitly call for disabling external entity processing in XML parsers.
CWE-614prevents — Application security requirements can include cookie security settings, but the control is broader and does not explicitly mandate the Secure attribute.
CWE-616prevents — Application security requirements include secure file-upload mechanisms that eliminate reliance on the four legacy PHP variables.
CWE-617prevents — Application security requirements can specify that assertions must not be reachable from attacker-controlled inputs.
CWE-618prevents — Application security requirements explicitly call for restricting unsafe ActiveX methods and browser-zone violations.
CWE-621prevents — Application security requirements include explicit checks on external input used for variable naming.
CWE-622prevents — Application security requirements explicitly call for validation of all external inputs, including function-hook parameters.
CWE-623prevents — Application security requirements can mandate safe scripting policies, but do not directly prevent the marking flaw.
CWE-624prevents — Application security requirements can mandate safe regex handling and input sanitization.
CWE-625prevents — Application security requirements mandate strict input validation rules that would catch overly permissive regex.
CWE-626prevents — Application security requirements can mandate proper handling of special characters such as null bytes.
CWE-627prevents — Application security requirements can specify restrictions on dynamic variable or function evaluation.
CWE-639prevents — Application security requirements can mandate authorization controls, yet the control itself is a requirements statement rather than an implemented safeguard.
CWE-640prevents — Application-security requirements can mandate secure recovery flows, but the control covers many other requirements.
CWE-641prevents — Application security requirements include rules for handling untrusted input when constructing file or resource names.
CWE-642prevents — Application security requirements can mandate that critical state not be stored in untrusted locations.
CWE-643prevents — Application security requirements explicitly call for defenses against injection flaws including XPath injection.
CWE-644prevents — Application security requirements explicitly call for neutralizing untrusted data in HTTP headers.
CWE-646prevents — Application security requirements can mandate content inspection, but the control itself does not prescribe the technique.
CWE-647prevents — Defining application security requirements that mandate canonical URL handling and authorization checks mitigates the weakness at design time.
CWE-648prevents — Application security requirements can specify correct invocation of privileged APIs.
CWE-649prevents — Application security requirements should mandate integrity verification for any security-relevant inputs that are encrypted or obfuscated.
CWE-650prevents — Application security requirements can mandate proper HTTP method usage and state-changing operation restrictions.
CWE-652prevents — Application security requirements explicitly call for defenses against injection flaws including XQuery.
CWE-66prevents — Application security requirements can mandate proper handling of file paths and virtual resources to prevent unintended file operations.
CWE-667prevents — Application security requirements can mandate proper lock acquisition/release patterns.
CWE-67prevents — Application security requirements include validation of file/path inputs, mitigating device-name attacks.
CWE-674prevents — Application security requirements can mandate recursion limits or stack-depth checks.
CWE-675prevents — Application security requirements can mandate single-operation semantics for critical resources.
CWE-680prevents — Application security requirements can specify safe integer handling and bounds checking.
CWE-681prevents — Application security requirements can mandate safe numeric handling and range validation.
CWE-682prevents — Application security requirements can explicitly call for numeric accuracy and bounds checking.
CWE-684prevents — Explicit application security requirements and acceptance criteria help ensure the delivered software matches its intended specifications.
CWE-686prevents — Application security requirements can mandate strong typing and interface contracts that prevent incorrect argument types.
CWE-687prevents — Application security requirements can mandate input validation and argument checking.
CWE-690prevents — Application security requirements include defensive coding rules that address missing NULL checks.
CWE-692prevents — Application-security requirements can mandate proper output encoding, but the control itself does not prescribe the technique.
CWE-695prevents — Application security requirements explicitly forbid disallowed low-level functionality.
CWE-697prevents — Application security requirements can mandate correct comparison logic for security decisions.
CWE-698prevents — Application security requirements can mandate safe redirect patterns and post-redirect termination.
CWE-704prevents — Application security requirements can mandate strong typing and safe casting rules.
CWE-706prevents — Application security requirements can mandate validation of all external references and names used at runtime.
CWE-707prevents — Application security requirements explicitly call for data validation and sanitization controls addressing neutralization weaknesses.
CWE-73prevents — Application security requirements explicitly call for controls against untrusted input influencing file operations.
CWE-74prevents — Application security requirements explicitly call for controls against injection attacks in software design.
CWE-749prevents — Application security requirements can mandate that dangerous methods are not exposed in interfaces.
CWE-75prevents — Application security requirements explicitly call for controls against injection flaws including special-element handling.
CWE-754prevents — Application security requirements explicitly call for handling of exceptional conditions and error paths.
CWE-755prevents — Application security requirements explicitly include handling of error and exceptional conditions.
CWE-756prevents — Application security requirements can mandate custom error pages to prevent information leakage.
CWE-757prevents — Application security requirements can specify minimum cryptographic strength to avoid downgrades.
CWE-759prevents — Application security requirements can mandate salted hashing but do not prescribe the technical detail.
CWE-76prevents — Application security requirements include rules for handling special characters and equivalent encodings.
CWE-760prevents — Application security requirements can specify cryptographic standards that prohibit predictable salts.
CWE-763prevents — Application security requirements can specify correct use of release functions and pointer validation.
CWE-767prevents — Application security requirements can specify that private variables must remain inaccessible.
CWE-77prevents — Application security requirements explicitly call for controls against injection flaws including command injection.
CWE-774prevents — Application security requirements can mandate throttling and descriptor limits.
CWE-776prevents — Application security requirements can explicitly call for limits on XML entity recursion and DTD processing.
CWE-777prevents — Application security requirements can mandate anchored regex but do not prescribe the technique.
CWE-780prevents — Application security requirements can specify cryptographic standards including OAEP.
CWE-782prevents — Application security requirements capture the need for proper IOCTL authorization.
CWE-784prevents — Application security requirements can specify cookie validation but do not mandate implementation details.
CWE-786prevents — Application security requirements can mandate bounds checking and pointer validation to prevent pre-buffer accesses.
CWE-787prevents — Application security requirements can specify bounds-checking and safe memory handling.
CWE-788prevents — Application security requirements can mandate bounds checking and safe memory APIs.
CWE-789prevents — Application security requirements mandate bounds checking on size parameters to avoid excessive memory allocation.
CWE-790prevents — Application security requirements explicitly call for input validation controls that mitigate improper special-element filtering.
CWE-791prevents — Application security requirements explicitly call for input validation and sanitization that directly mitigates incomplete special-element filtering.
CWE-792prevents — Application security requirements explicitly call for input validation rules that mitigate incomplete special-element filtering.
CWE-794prevents — Application security requirements include explicit rules for handling and filtering special characters in data flows.
CWE-799prevents — Application security requirements explicitly include controls on interaction frequency and throttling.
CWE-80prevents — Application security requirements explicitly call for neutralization of script-related HTML tags.
CWE-804prevents — Application security requirements mandate effective CAPTCHA challenges that cannot be easily bypassed by bots.
CWE-805prevents — Application security requirements can specify buffer-size validation, but do not prescribe implementation details.
CWE-807prevents — Application security requirements explicitly call for validation of inputs used in security decisions.
CWE-81prevents — Application security requirements explicitly call for proper handling of untrusted input to avoid script injection in error responses.
CWE-82prevents — Application security requirements can mandate input validation and output encoding that prevent script injection in IMG attributes.
CWE-820prevents — Application security requirements can specify thread-safety and locking mechanisms.
CWE-821prevents — Application security requirements can mandate proper locking and thread-safety controls.
CWE-822prevents — Application security requirements can mandate validation of pointers obtained from untrusted sources.
CWE-823prevents — Application security requirements include memory-safety rules that reduce pointer-offset errors.
CWE-825prevents — Application security requirements may mandate safe memory handling, but eliminating this single weakness does not satisfy the broader requirement.
CWE-826prevents — Application security requirements can mandate explicit resource-release rules, partially addressing the weakness.
CWE-827prevents — Application security requirements include rules for safe XML processing and external entity handling.
CWE-83prevents — Application security requirements explicitly call for controls against injection flaws including attribute-based script injection.
CWE-830prevents — Application security requirements can mandate vetting of external web components, but do not guarantee technical enforcement.
CWE-834prevents — Application security requirements include resource-consumption limits that prevent unbounded loops.
CWE-835prevents — Application security requirements can specify loop-termination rules, indirectly reducing the weakness.
CWE-837prevents — Application-security requirements can specify single-action enforcement, yet the control is wider in scope.
CWE-838prevents — Application security requirements can specify correct output encoding, yet the control is broader than this single weakness.
CWE-839prevents — Application security requirements include explicit validation rules for numeric ranges, directly addressing the missing minimum check.
CWE-84prevents — Application security requirements explicitly call for input validation and output encoding that directly prevent URI-scheme injection.
CWE-841prevents — Application security requirements include sequencing and state-transition rules for critical workflows.
CWE-843prevents — Application security requirements can specify strong typing and interface contracts that reduce type confusion.
CWE-85prevents — Application security requirements can mandate input validation, yet the control itself does not prescribe the specific doubled-character filter.
CWE-86prevents — Application security requirements explicitly call for validation of all inputs including identifiers, mitigating this weakness.
CWE-87prevents — Application security requirements explicitly call for neutralization of untrusted input to block XSS variants.
CWE-88prevents — Application security requirements include explicit rules for safe command-line argument handling and escaping.
CWE-90prevents — Application security requirements include explicit rules for safe construction of directory queries, mitigating LDAP injection.
CWE-908prevents — Application security requirements can specify mandatory initialization of variables and resources before use.
CWE-909prevents — Application security requirements can specify resource initialization checks.
CWE-91prevents — Application security requirements explicitly call for defenses against injection flaws including XML.
CWE-910prevents — Application security requirements can mandate proper file-descriptor lifecycle handling.
CWE-911prevents — Application security requirements can mandate correct resource-lifetime management, indirectly addressing reference-count errors.
CWE-912prevents — Application security requirements explicitly define expected functionality, making hidden features a violation.
CWE-913prevents — Application security requirements explicitly address restrictions on dynamic code execution and resource access.
CWE-914prevents — Application security requirements can mandate strict control over dynamically-identified variables.
CWE-915prevents — Application security requirements include explicit rules for allowable object attributes and safe deserialization.
CWE-917prevents — Application security requirements explicitly call for controls against injection flaws including EL injection.
CWE-923prevents — Application security requirements may specify endpoint validation but do not implement it.
CWE-924prevents — Application security requirements can specify integrity protection for transmitted messages.
CWE-925prevents — Application security requirements can mandate intent verification for broadcast receivers.
CWE-926prevents — Defining application security requirements includes specifying proper export restrictions and permission checks for components.
CWE-927prevents — Application security requirements can mandate explicit intents or secure IPC for sensitive data.
CWE-93prevents — Application security requirements include rules for neutralizing special characters such as CRLF in inputs.
CWE-939prevents — Requires security requirements that define which callers are permitted to trigger custom URL handlers, mitigating the authorization gap.
CWE-940prevents — Application security requirements may specify origin checks but do not mandate them.
CWE-941prevents — Application security requirements may mandate destination validation, yet the control is high-level.
CWE-942prevents — Application security requirements should specify secure CSP and cross-domain policy settings, directly addressing the weakness.
CWE-943prevents — Application security requirements explicitly call for controls against injection and improper query construction.
CWE-95prevents — Application security requirements include rules against dynamic code execution of untrusted input.
CWE-96prevents — Application security requirements include rules for neutralizing untrusted input before it is stored in executable resources.
CWE-97prevents — Application security requirements include rules for neutralizing server-side directives in user input.
CWE-98prevents — Application security requirements explicitly call for controls against injection and unsafe file operations.
CWE-99prevents — Application security requirements explicitly call for controls on external identifiers used to access resources.

Mitigated MITRE ATT&CK techniques (674)

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

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

T1001←M T1001.001←M T1001.002←M T1001.003←M T1003.002→P T1003.008→P T1006←M T1014←M T1020→P T1021→P T1021.004→P T1021.006→P T1021.007→P T1027→P T1027.001←M T1027.002←M T1027.003←M →P T1027.004→P T1027.005←M T1027.006←M →P T1027.007←M T1027.008←M T1027.009←M →P T1027.010←M T1027.011←M T1027.013←M T1027.014←M T1027.016←M T1027.017←M →P T1027.018←M →P T1030←M T1036←M T1036.001→P T1036.002←M →P T1036.003←M →P T1036.005←M T1036.007←P T1036.008←M →P T1036.009←M T1036.011←M T1036.012←M T1037.001→P T1040→P T1041→P T1047→P T1048←M →P T1048.001→P T1048.002→P T1048.003←M →P T1053→P T1055←M →P T1055.001←M T1055.002←M T1055.003←M →P T1055.004←M →P T1055.005←M T1055.008←M T1055.009←M T1055.011←M →P T1055.012←M T1055.013←M →P T1055.014←M →P T1055.015←M →P T1056→P T1056.001→P T1056.002←M →P T1056.003→P T1056.004→P T1059→P T1059.003→P T1059.005→P T1059.007→P T1059.008→P T1059.009→P T1059.010→P T1059.013→P T1068←M →P T1069.003→P T1070←M T1070.006←M T1070.008→P T1070.010←M T1071←M T1071.001←M T1071.003←M T1071.004←M T1071.005←P T1072→P T1074→P T1074.001→P T1078→P T1078.001←M →P T1078.002→P T1078.004←P →P T1080→P T1090←M T1090.002←M T1090.003←M T1090.004←M T1095←M T1098→P T1098.001→P T1098.003→P T1098.004→P T1098.005←M →P T1098.006→P T1102←M T1102.001←M →P T1102.002←M →P T1102.003←M T1104←P T1110→P T1110.001→M T1110.002→P T1110.003←M →P T1110.004→P T1111←M →P T1114.001→P T1114.002→P T1127←M →P T1127.001←M →P T1127.002→P T1127.003←M T1129→P T1132←P T1132.001←P T1132.002←M T1133←M →P T1134←M →P T1134.001←M →P T1134.002←M T1134.003←M →P T1134.004←M T1134.005←M T1137→P T1137.001→P T1137.002→P T1137.003→P T1137.004→P T1137.005→P T1137.006→P T1176←M →P T1176.001←P →P T1176.002→P T1185←M →P T1187→P T1189←P →P T1190←M →M T1195→P T1195.001→P T1195.002←P →P T1197→P T1199←P →P T1202←M →P T1203←P →P T1204.001←M →P T1204.002→P T1204.003←M T1204.004←M T1204.005←M →P T1207←M T1210→P T1211←P →P T1212←P →P T1213←P →P T1213.001→P T1213.002→P T1213.003→P T1213.004→P T1213.006→P T1216←M →P T1216.001←M →P T1216.002←M T1218←M T1218.001←P →P T1218.002←P T1218.003←M →P T1218.004←M →P T1218.005←M →P T1218.007←M T1218.008←M →P T1218.009←M →P T1218.010←M T1218.011←M T1218.012←M →P T1218.013←M →P T1218.015→P T1219→P T1219.001→P T1219.003←M T1220←P →P T1221←M →P T1222←M T1222.001←M T1222.002←M T1480.001←M T1484←M →P T1484.002←M →P T1485→P T1486→M T1490←M T1491.001→P T1491.002→P T1496→P T1496.001→P T1496.002→P T1496.003→P T1496.004→P T1497←M T1497.001←P T1497.002←M T1498←P →P T1499←P →P T1499.001←M →P T1499.002←P →P T1499.003←P →P T1499.004←P →P T1505→P T1505.001→P T1505.002→P T1505.003←M →P T1505.004→P T1525→P T1528←M →P T1529→P T1530←P →P T1534→P T1535←M T1537←M →P T1539→P T1542←M T1542.002←M T1542.003←M T1546→P T1546.003→P T1546.007→P T1546.011←M T1546.012←P T1546.015→P T1546.016→P T1546.017→P T1547.002→P T1547.004→P T1547.006→P T1547.012→P T1548←M →P T1548.001←P →P T1548.002←M T1548.003←P →P T1548.004→P T1548.005→P T1548.006←M →P T1550←M →P T1550.001→P T1550.002←F T1550.003←F →P T1550.004←F →P T1552←M →P T1552.001←M →P T1552.003→P T1552.004→P T1552.005←M →P T1552.006→P T1552.008→P T1553←P →P T1553.001←F T1553.002←P T1553.003←M →P T1553.004←M →P T1553.005←M T1553.006←M →P T1554→P T1555→P T1555.003→P T1555.004→P T1555.005→P T1555.006→P T1556←M →P T1556.001←M T1556.002←F T1556.003←F →P T1556.005←M →P T1556.006←M →P T1556.007←M →P T1556.008→P T1556.009←M →P T1557→P T1557.001→P T1557.004←P T1558←M →P T1558.002→P T1558.004→P T1559.002→P T1559.003←P →P T1561←M →P T1563→P T1563.001→P T1563.002→P T1565→P T1565.001→P T1565.002→P T1565.003→P T1566.002→P T1566.003←M T1567→P T1567.001→P T1567.003→P T1567.004→P T1568←P T1568.002←M T1568.003←P T1570→P T1571←M T1572←M →P T1573←P T1573.002→P T1574←M →P T1574.001←M →P T1574.004←M →P T1574.005←P →P T1574.006→P T1574.008←P →P T1574.009→P T1574.010→P T1574.011→P T1574.012←P →P T1574.013←M T1574.014→P T1578←P T1578.001←M T1578.002←M T1578.003←M T1578.004←M T1578.005←M T1587.004→P T1588.005→P T1589.001→P T1599←M T1599.001←M T1600←M T1600.001←P →P T1600.002←P T1601.001←M T1601.002←M T1606←M →P T1606.001←F →P T1606.002←M →P T1608.004→P T1608.005→P T1610←P T1611←M →P T1612←M T1620←M →P T1621←M →P T1622←M T1647←M T1648→P T1649→P T1653←P T1657→P T1659→P T1665←P T1666←M T1671←M →P T1674←P →P T1677←M →P T1678←P T1684→P T1684.001←P →P T1684.002←M →P T1685←M T1685.002←M →P T1685.003←M T1685.004←M T1685.005←M →P T1686←F T1686.001←M T1686.002←M T1686.003←M T1687←M →P T1688←M T1689←M →P T1690←M

Why these map — AI rationale (under review)

T1003.002detects — A.8.26 requires identifying and addressing application security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against attacks; this surfaces anomalous credential-dumping behavior when the application layer (or its mandated monitoring) observes it, but the technique is a host-level OS/registry action outside most application scopes.
T1003.008prevents — A.8.26 requires identification and specification of application security requirements including authentication, access segregation, resilience against malicious attacks, input/output controls, and cryptography — which can prevent the credential-dumping technique when those requirements govern the applications or services that would otherwise allow unprivileged read access to /etc/passwd and /etc/shadow.
T1020detects — A.8.26 mandates identifying and addressing requirements such as transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and output controls, which can surface automated exfiltration when those requirements drive monitoring implementation.
T1020prevents — A.8.26 requires identifying and specifying security requirements (including data classification, protection of data in transit/rest, encryption of communications, input/output controls, logging/monitoring, and non-repudiation) that directly address automated exfiltration vectors when applications are developed or acquired; this constrains the technique in built/acquired software but leaves residual cases (e.g., already-deployed apps, non-application exfiltration, or incomplete implementation of the requirements).
T1021prevents — A.8.26 requires identification and specification of application security requirements (including authentication, segregation of access, resilience against attacks, input/output controls, and non-repudiation) that directly address the use/abuse of remote services for unauthorized access when those services are part of developed or acquired applications.
T1021.004detects — A.8.26 requires identification and specification of application security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against attacks; this surfaces anomalous SSH logins or usage when those requirements drive monitoring implementation, but the control only mandates requirements identification rather than mandating or performing detection itself.
T1021.004prevents — A.8.26 requires identification and specification of application security requirements (including authentication, access segregation, resilience against attacks, input controls, and cryptography) that can constrain SSH usage or configuration in developed/acquired apps, but does not itself enforce, disable, or harden SSH on hosts.
T1021.006detects — A.8.26 requires identifying and addressing security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against attacks; this surfaces anomalous WinRM usage when those requirements are met, but only for the subset of implementations that choose to include WinRM-specific monitoring.
T1021.007prevents — A.8.26 requires identification and specification of application security requirements (including authentication, identity trust, access segregation, resilience against attacks, input/output controls, and cryptography) that can constrain the cloud-service login surface when those requirements are later implemented; this prevents a slice of the technique but not the dominant family of valid-account usage or federation misconfigurations.
T1027prevents — A.8.26 requires applications to specify and address security requirements including resilience against malicious attacks (explicitly naming SQL injection and buffer overflows), input validation, output controls, cryptography use, and secure development practices that can block many common obfuscation vectors in application payloads or command handling, but leaves open-ended the full spectrum of file/command obfuscation techniques (e.g. environment variables, splitting, encoding in transit on non-application layers) that an adversary can still employ.
T1027.003detects — A.8.26 requires applications to identify and address security requirements including input/output controls, integrity checks, transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and error handling; these can surface steganography when it abuses application media handling or produces detectable anomalies, but the control only mandates requirements derivation rather than mandating any specific detection mechanism or coverage depth.
T1027.004detects — A.8.26 requires identifying and specifying application security requirements (including input controls, integrity checks, resilience against malicious attacks, and interfaces to logging/monitoring systems) that can surface anomalous source-code delivery or compilation activity when those requirements drive monitoring rules; this is a genuine but minority slice of the technique's surface (e.g., only where the compiled payload lands in or is built by an in-scope application).
T1027.006prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as injections, input validation, output controls, and secure development practices) that would lead developers to neutralize or block HTML smuggling vectors in web-facing applications; this stops the technique at source in covered apps but leaves a large remainder (non-application delivery vectors, legacy/third-party apps, and client-side execution after delivery).
T1027.009prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, output controls, and cryptography) that, when followed during development or acquisition, reduce the likelihood an application will accept or execute embedded payloads; this is a genuine but minority slice of the broad technique that also covers post-deployment abuse of existing benign files and non-application vectors.
T1027.017detects — A.8.26 requires applications to identify/address security requirements including input controls, integrity checks, input validation, output controls, error handling, and resilience against malicious attacks (explicitly naming SQL injection and buffer overflows as examples), which can surface SVG smuggling vectors when those requirements drive monitoring, logging, or validation logic in the developed/acquired application; it does not mandate detection mechanisms itself and leaves most of the technique (e.g., passive image-like SVGs in non-application contexts or PDFs) unreached.
T1027.017prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as injections, input validation, output controls, and secure development practices), which when applied during development or acquisition can stop SVG smuggling payloads from being introduced or rendered exploitably; this covers only the slice of the technique that arises in in-house or acquired applications built under the control, not the broader use of SVG smuggling in documents, PDFs, or third-party content.
T1027.018detects — A.8.26 requires applications to identify and address security requirements including input validation, output controls, error handling, and resilience against malicious inputs/attacks (explicitly naming SQL injection and buffer overflows); this can surface anomalous Unicode/invisible-character payloads during development or acquisition when those requirements drive testing or static analysis, but the control is a requirements-setting process with no mandated detection mechanism and leaves most runtime or non-application vectors untouched.
T1027.018prevents — A.8.26 requires identification and specification of application security requirements (including input validation, integrity checks, output controls, and resilience against malicious attacks such as injections), which when applied during development can stop invisible Unicode from being accepted/processed in ways that conceal payloads; this is only a slice because the control is a requirements-setting process whose effect depends on what the implementer chooses to specify and enforce.
T1036.001detects — A.8.26 requires applications (esp. those handling transactions, ordering or payments) to identify and embed requirements for non-repudiation, integrity verification, digital signatures, certificate management and output/input controls; these can surface invalid-signature artifacts when the application itself performs or logs signature validation, but the control is a requirements-gathering process that does not mandate detection mechanisms in every relevant application or on the endpoint.
T1036.002detects — A.8.26 requires applications to identify and address security requirements including input controls, integrity checks, input validation, output controls, error message handling, and resilience against malicious attacks; these can surface anomalous or disguised filenames/inputs containing RTLO characters during development or acquisition, but the control is a requirements-setting process whose coverage depends on what the implementer chooses to specify and is silent on runtime detection tooling or defender awareness of rendered display tricks.
T1036.003detects — A.8.26 requires identification of application security requirements including input controls, integrity checks, transaction logging/monitoring, non-repudiation and interfaces to logging/monitoring systems; these can surface renamed-utility evasion when the application itself performs or integrates such detection, but the control only sets requirements rather than mandating any specific detection mechanism and does not address renamed utilities outside application development/acquisition.
T1036.008detects — A.8.26 requires applications to identify and address security requirements including input validation, integrity checks, output controls, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems; these can surface masquerading attempts (e.g. via anomalous file signatures, extensions, or polyglot behavior) when the application processes or receives the file, but the control only sets requirements rather than mandating any specific detection mechanism or coverage depth.
T1036.008prevents — A.8.26 requires identifying and specifying application security requirements (including input validation, integrity checks, output controls, and resilience against malicious attacks such as injections), which when applied during development can stop file-type masquerading from bypassing validation/sanitization; this is only a slice because the control is a requirements-gathering process whose effect depends on what the implementer actually specifies and enforces.
T1037.001detects — A.8.26 requires identification and specification of application security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling; this surfaces anomalous logon-script behaviors when they are part of an application's monitored events, but the control is scoped only to application development/acquisition and does not mandate runtime detection of the persistence technique itself.
T1040prevents — A.8.26 requires applications to identify and address security requirements including encryption of communications (i), protection of data in transit (h), and use of cryptography, which stops sniffing from capturing cleartext credentials or sensitive data when those requirements are met; it is only partial because the control is limited to application development/acquisition (does not reach network devices, promiscuous-mode capture on endpoints, cloud traffic mirroring, or non-application traffic).
T1041detects — A.8.26 requires identifying and specifying application security requirements (including logging/monitoring interfaces, input/output controls, transaction logging, and resilience against attacks), which can lead to detection mechanisms for anomalous exfiltration over C2 channels in developed/acquired apps; however, it only mandates requirements identification rather than mandating or implementing any specific detection capability.
T1041prevents — A.8.26 requires identification and specification of security requirements (including encryption of communications, protection of data in transit, input/output controls, and resilience against attacks) when developing or acquiring applications; this can lead to design choices that stop data from being exfiltrated over C2 by enforcing secure channels or blocking unauthorized outbound encoding, but only for applications built or acquired under the control — it does not reach pre-existing C2 implants, non-application vectors, or implementations that ignore the requirements.
T1047detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against malicious attacks; this can surface anomalous or malicious use of WMI when the application itself uses or exposes WMI, but the control is silent on general system-level detection of WMI abuse outside application development/acquisition.
T1048detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and output controls on who can access outputs; this surfaces some exfiltration-over-alternate-protocol events when they involve monitored applications or trigger DLP-like mechanisms, but leaves the bulk of protocol abuse (especially non-application, OS-utility, or cloud-console exfil) unreached.
T1048prevents — A.8.26 requires identification and specification of application security requirements (including data classification, protection of data in transit/rest, encryption of communications, input/output controls, and resilience against attacks), which when applied during development or acquisition can stop applications from exposing exfiltration vectors over alternate protocols; this is only a slice of T1048 because the technique also covers post-compromise use of OS utilities, cloud APIs, and non-application-specific exfiltration channels.
T1048.001detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and output controls; this surfaces anomalous exfiltration (including over symmetric-encrypted non-C2 channels) when the application itself is the source, but does not mandate detection of exfiltration originating from other processes or at the network boundary.
T1048.002prevents — A.8.26 requires identification and specification of application security requirements (including encryption of data in transit, input/output controls, and resilience against attacks), which when applied during development/acquisition can prevent the insecure exfiltration channel from being available to the adversary; it is only partial because the control is a requirements-gathering process whose effect depends on what the developer actually implements and does not reach exfiltration decisions made at runtime by already-compromised code.
T1048.003detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and output controls; this surfaces exfiltration events when the application itself (or its mandated monitoring) observes anomalous outbound non-C2 traffic, but the control is silent on network-layer or non-application detection and the technique can target non-application vectors.
T1048.003prevents — A.8.26 requires applications to identify/address requirements including encryption of communications (i), protection of data in transit (h), and use of cryptography, which would stop exfiltration of plaintext sensitive data over unencrypted protocols if applied to the relevant apps; this is only a slice because the control is limited to application development/acquisition (not all exfil paths, protocols chosen at runtime, or non-application components) and the technique explicitly allows non-encrypted native protocols with obfuscation.
T1053detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling; these can surface anomalous scheduled-task behavior when the scheduling occurs through or is visible to the monitored application, but the control is silent on host-level task schedulers, non-application abuse, and most platforms, leaving a large remainder
T1055detects — A.8.26 requires applications to identify and address security requirements including resilience against malicious attacks (explicitly naming buffer overflows and SQL injection) plus interfaces to logging/monitoring and data leakage detection systems; this surfaces some process-injection attempts when they target or are visible to the instrumented application, but the control is silent on host-level behavioral monitoring of arbitrary process injection and the technique is designed to evade detection.
T1055prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, segregation of access, and secure development practices), which can lead to design choices that prevent certain process-injection vectors in custom applications, but this is only a minority slice of the broad, platform-specific technique class that also covers OS-level abuse, third-party components, and runtime behaviors outside the development/acquisition scope.
T1055.003detects — A.8.26 requires applications to identify and address security requirements including resilience against malicious attacks, input validation, output controls, transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and error handling; these can surface anomalous process behavior or injection artifacts in application-layer contexts but do not broadly instrument or detect the low-level Windows API thread hijacking technique itself.
T1055.003prevents — A.8.26 mandates identifying and specifying security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, access segregation, and cryptography) during application development or acquisition; this can lead to application-level defenses that stop thread execution hijacking techniques from succeeding in those applications, but the control is a requirements-setting process whose coverage depends on what the implementer chooses to specify and the technique can still succeed against non-application vectors or applications developed without those requirements.
T1055.004prevents — A.8.26 requires identification of application security requirements including resilience against malicious attacks (explicitly naming buffer overflows and SQL injection as examples) and input controls/validation; this can lead to secure development practices that prevent APC injection vectors in custom applications, but the control is a requirements-gathering process (not a mechanism), applies only to developed/acquired apps (not the OS/runtime itself), and leaves most of the technique's Windows API surface and variations untouched.
T1055.011prevents — A.8.26 requires applications to identify and address security requirements including resilience against malicious attacks (explicitly naming buffer overflows and SQL injection) and input validation/integrity controls; this can lead to secure design that avoids EWM-related vulnerabilities in custom graphical Windows apps, but the technique is a low-level runtime injection method in live processes (often by third-party malware), not a defect prevented by application-level requirements in all cases.
T1055.013detects — A.8.26 requires identification and specification of application security requirements (including input validation, integrity checks, transaction logging/monitoring, non-repudiation, interfaces to logging/monitoring systems, and error handling) that can surface anomalous or malicious behavior indicative of process doppelgänging during development or acquisition, but this is limited to requirements-setting for apps rather than runtime detection of the technique itself.
T1055.013prevents — A.8.26 requires identification and specification of application security requirements including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, and related controls that can be applied during development or acquisition to stop process-doppelganging techniques from being introduced into custom or acquired applications.
T1055.014detects — A.8.26 requires applications to identify and address security requirements including resilience against malicious attacks, input validation, output controls, transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling; these can surface anomalous behavior tied to VDSO hijacking in application contexts, but the control is about requirements identification during development/acquisition rather than mandating runtime detection mechanisms, leaving most of the Linux technique (especially non-application processes) unreached.
T1055.015prevents — A.8.26 requires applications to identify and address security requirements including resilience against malicious attacks (explicitly naming buffer overflows and SQL injections) and input controls/validation; this can lead developers to harden list-view handling and message processing against ListPlanting-style shatter attacks, but the control only mandates requirements identification rather than mandating any specific mechanism that stops the technique.
T1056detects — A.8.26 requires identification and specification of application security requirements including input controls, integrity checks, input validation, transaction logging/monitoring, interfaces to logging/monitoring systems, and error message handling; these surface anomalous or malicious input-capture behaviors when implemented in the application layer, but the control is silent on runtime detection of transparent hooking or non-application vectors across all listed platforms.
T1056prevents — A.8.26 requires identification and specification of application security requirements including input controls/validation, authentication, segregation of access, resilience against malicious attacks (explicitly naming SQL injection and buffer overflows), and cryptography; these directly block many forms of input capture when followed in development or acquisition, but the control is a requirements-setting process whose effect depends on what the implementer chooses to specify and enforce, leaving a large slice (e.g., credential API hooking, keyloggers, or non-application vectors) unreached.
T1056.001detects — A.8.26 requires applications to identify and address security requirements including input controls, integrity checks, input validation, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems; these can surface anomalous keystroke-capturing behavior in application contexts but do not broadly instrument the OS-level or driver-level methods listed in the technique.
T1056.001prevents — A.8.26 requires identification and specification of application security requirements (including input controls, integrity checks, input validation, resilience against malicious attacks, and use of cryptography) that can stop keylogging techniques when they would be introduced or enabled by the application itself; this is a genuine but minority slice of the broad technique that also covers OS-level hooks, drivers, hardware buffer reads, and registry changes unrelated to any application under development.
T1056.002detects — A.8.26 requires applications to identify and address security requirements including input controls, integrity checks, input validation, transaction logging/monitoring, interfaces to logging/monitoring systems, and error message handling; these can surface anomalous or spoofed GUI credential prompts when the application itself is the one prompting or when monitoring is integrated, but the control is scoped only to application development/acquisition and does not broadly instrument OS-level GUI events across Linux/macOS/Windows.
T1056.002prevents — A.8.26 requires applications (developed or acquired) to specify and address security requirements including authentication trust, input validation/integrity checks, output controls, and resilience against malicious attacks, which directly constrains the ability of application code to mimic legitimate GUI credential prompts or spoof authentication dialogs.
T1056.003detects — A.8.26 requires identification and specification of application security requirements (including input controls, logging/monitoring, non-repudiation, interfaces to logging systems, and error handling) that can surface anomalous credential-capture behavior on web portals when those requirements drive monitoring implementation.
T1056.003prevents — A.8.26 requires identifying and specifying security requirements (including authentication, input validation, output controls, and resilience against malicious attacks such as injections) when developing or acquiring applications, which can prevent the insertion of credential-capturing code into externally facing portals if those requirements are enforced during development.
T1056.004detects — A.8.26 requires applications to identify and address security requirements including resilience against malicious attacks (explicitly naming buffer overflows and SQL injection) plus input/output controls, logging/monitoring interfaces, and error handling; this surfaces some hooking-based credential theft when it manifests as anomalous API behavior or malformed inputs in the developed application, but leaves the bulk of in-process hooking (IAT/inline/LD_PRELOAD) outside the application's own requirements and detection surface.
T1056.004prevents — A.8.26 requires applications to identify and address security requirements including resilience against malicious attacks (explicitly naming buffer overflows and SQL injection) and input controls/validation; this can lead developers to select or implement APIs/libraries that avoid hookable credential-capturing patterns, but the control is a requirements-setting process that does not itself block hooking mechanisms such as IAT/inline hooks, LD_PRELOAD, or DYLD_INSERT_LIBRARIES.
T1059prevents — Requiring input validation, integrity checks, and restrictions on free-text fields limits an attacker’s ability to inject or execute arbitrary commands through application interfaces.
T1059.003detects — A.8.26 requires identification of application security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against malicious activity; this surfaces anomalous or malicious use of cmd.exe (especially in transactional/electronic-ordering apps) when those requirements drive monitoring instrumentation, but the control itself only mandates requirements identification rather than mandating specific detection coverage.
T1059.005prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, and secure development practices) that would constrain or eliminate unsafe use of VB/VBA/VBScript interpreters and macros during application development or acquisition.
T1059.007detects — A.8.26 requires identifying and specifying application security requirements (including input validation, output controls, logging/monitoring interfaces, error handling, and resilience against malicious attacks), which can surface anomalous or malicious JavaScript usage when those requirements drive monitoring or detection rules; this is only a slice because the control is about requirements identification during development/acquisition rather than mandating runtime detection mechanisms.
T1059.007prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as SQL injections, input validation, and secure development practices), which when applied during development or acquisition can stop adversaries from being able to introduce or exploit JavaScript execution vectors in custom or acquired applications.
T1059.008prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, access segregation, authentication, and cryptography) when developing or acquiring applications; this can constrain CLI abuse vectors on network devices developed in-house or acquired, but does not mandate enforcement mechanisms, covers only a slice of the technique's remote-access and post-compromise uses, and has no bearing on already-deployed third-party network devices.
T1059.009detects — A.8.26 requires identification and specification of application security requirements (including input controls, logging/monitoring interfaces, transaction logging, and resilience against malicious attacks), which can lead to detection mechanisms being built into or around cloud API-using applications, but does not itself perform or mandate detection of the technique.
T1059.009prevents — A.8.26 requires identification and specification of security requirements (including authentication, access segregation, resilience against malicious attacks/injections, input validation, and cryptography) that, when applied during development or acquisition of cloud-facing applications, constrain the attack surface and permission model an adversary would abuse to execute via cloud APIs; this is a genuine but minority slice of the technique (most usage vectors are post-compromise abuse of already-permitted legitimate APIs rather than defects introduced at build time).
T1059.010detects — A.8.26 requires identification and specification of application security requirements (including input controls, integrity checks, resilience against malicious code, logging/monitoring interfaces, and error handling) that can surface anomalous or suspicious use of automation scripting languages like AutoHotKey/AutoIT during development or acquisition of applications.
T1059.013prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, access segregation, authentication, and cryptography) during application development or acquisition; when those requirements govern container-orchestration or management apps this constrains the attack surface for CLI/API abuse, but the control is a requirements-setting process that does not itself implement or enforce any of those protections and leaves the bulk of the technique (abuse of legitimate container CLIs/APIs in already-deployed environments) untouched.
T1068prevents — A.8.26 requires that resilience against malicious attacks (explicitly naming buffer overflows and SQL injections) and related requirements such as input validation, output controls, and secure development be identified and addressed during application acquisition or development; this stops many exploitable programming errors from reaching production and thereby prevents the T1068 technique, but leaves a bounded remainder (vulnerabilities in OS kernels, third-party drivers, already-deployed software, and non-application components) untouched.
T1069.003prevents — A.8.26 requires identification and specification of application security requirements (including segregation of access, authentication, authorization, input/output controls, and resilience against attacks) that, when applied during development or acquisition, constrain the ability of an adversary to discover or exploit cloud groups and permission settings via application interfaces.
T1070.008prevents — A.8.26 requires applications (including mail apps) to specify and address security requirements such as input validation, output controls, transaction logging/monitoring, non-repudiation, and resilience against malicious attacks, which can prevent some vectors for clearing mailbox data or related artifacts when those requirements are implemented in the mail application itself.
T1072prevents — A.8.26 requires identifying and specifying security requirements (including authentication, segregation of access/privileges, resilience against malicious attacks, input controls, and derived requirements from other controls) for applications including those acquired or developed for deployment/CI-CD use; this constrains the class of deployment tools that can be introduced with weak auth/privileges or without attack resilience, but does not block already-deployed tools, misconfigurations, or credential theft that enables the technique.
T1074detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and output controls (who can access outputs), which can surface anomalous staging activity in application-generated data flows but does not broadly instrument the OS, file system, or cloud instances where most T1074 staging occurs.
T1074.001detects — A.8.26 requires identification of requirements for transaction logging, monitoring, interfaces to logging/monitoring systems, and data leakage detection, which can surface local staging activity when those requirements are implemented and enforced.
T1078prevents — A.8.26 requires applications to identify and address security requirements including authentication, segregation of access/privileges, resilience against attacks, input/output controls, and non-repudiation; these can stop adversaries from obtaining or abusing valid accounts in the applications themselves, but the control is limited to requirements identification during development/acquisition and does not reach credential theft, inactive accounts, or pivoting across the broader enterprise.
T1078.001prevents — A.8.26 requires identification and specification of application security requirements (including authentication, segregation of access, resilience against attacks, input controls, and derived requirements from other controls), which when applied during development or acquisition of applications can stop default accounts from being introduced or left unchanged; this covers only the application slice of the technique, not built-in OS, device, or post-integration defaults on non-application platforms.
T1078.002prevents — A.8.26 requires identification and specification of application security requirements (including authentication, segregation of access/privileges, resilience against attacks, input validation, and cryptography) that, when applied during development or acquisition, constrain paths to domain credential compromise such as weak auth, injection, or improper storage; this is a genuine but minority slice of the technique's full surface (credential dumping, reuse, etc. across any domain account).
T1078.004prevents — A.8.26 requires identification and specification of application security requirements (including authentication, access segregation, resilience against attacks like credential abuse, input controls, and cryptography) that can constrain how cloud-account-bearing applications are built or acquired, thereby stopping some T1078.004 vectors such as weak auth, over-privileged roles, or credential creation; it does not address account provisioning hygiene, misconfigurations in cloud IAM policies, or post-compromise persistence outside the application development/acquisition process.
T1080detects — A.8.26 requires applications (incl. those handling shared content or repositories) to identify and address security requirements such as input validation, integrity checks, output controls, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems, which can surface tainted content or anomalous modifications in applicable development/acquisition contexts.
T1080prevents — A.8.26 requires identifying and specifying application security requirements (including input validation, integrity checks, output controls, resilience against malicious code/injections, and secure development practices) that can stop tainted content from being introduced or executed in applications handling shared storage or repositories; this covers only the application-development slice of the technique, not the broader shared-storage, binary-infection, or directory-pivot vectors that live outside any single application.
T1098detects — A.8.26 requires identification and specification of application security requirements (including authentication, access segregation, logging/monitoring, non-repudiation, and interfaces to logging/monitoring or data leakage detection systems), which can surface anomalous account activity or manipulation in application context but does not mandate or perform detection itself and leaves most platforms and non-application vectors untouched.
T1098prevents — A.8.26 requires identifying and specifying security requirements (including authentication, access segregation, resilience against attacks, input validation, and non-repudiation) that can stop many forms of account manipulation from being introduced or succeeding in developed/acquired applications, but this is only a requirements-setting process whose actual preventive effect depends on downstream implementation and does not reach all platforms or post-compromise manipulation vectors.
T1098.001prevents — A.8.26 requires identification and specification of application security requirements (including authentication, access segregation, resilience against malicious attacks, input/output controls, and cryptography) that, when applied during development or acquisition of cloud-facing apps and services, constrain many of the credential-addition vectors and privilege-escalation paths described in T1098.001; this is a genuine but minority slice of the technique, which also covers post-compromise abuse of existing IAM permissions on unmanaged accounts, service principals, and IaaS instances.
T1098.003detects — A.8.26 requires identification of security requirements (including logging/monitoring interfaces, transaction logging, non-repudiation and anomaly-related controls) that can surface IAM/role changes when those requirements drive monitoring implementation; this is a genuine but minority slice of the technique (most instances occur via direct privileged API calls without touching application-level requirements).
T1098.003prevents — A.8.26 requires identification and specification of application security requirements (including segregation of access, resilience against attacks, input/output controls, and authorization) that can constrain how cloud apps and services handle roles/permissions, but this is a governance process whose effect on the post-compromise technique depends on downstream implementation rigor and does not reach the bulk of the technique (e.g. direct IAM policy updates or external tenant role additions).
T1098.004prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, access segregation, resilience against malicious attacks, input/output controls, and cryptography) during development or acquisition; this can prevent insecure SSH key handling in custom apps or cloud management tools, but the technique also targets OS-level files, config edits, network devices, and post-deployment API abuse outside any application SDLC.
T1098.005prevents — A.8.26 requires identifying and specifying security requirements (including authentication trust, segregation of access, resilience against attacks, input controls, and MFA-related considerations) during app/dev or acquisition; this can lead to requirements that block weak self-enrollment paths for device registration, but only reaches a slice of the technique's surface (e.g., MFA/Intune enrollment flows built under the control) rather than the bulk with a bounded remainder.
T1098.006detects — A.8.26 requires identification of security requirements including segregation of access, authorization, transaction logging/monitoring, non-repudiation, and interfaces to logging/monitoring systems; when those requirements drive audit or anomaly detection on role/permission changes they surface the technique, but the control itself only sets requirements rather than mandating any specific detection mechanism or coverage depth.
T1098.006prevents — A.8.26 mandates identification and specification of security requirements (including segregation of access, level of trust in identities, resilience against attacks, and authorization processes) that, when followed in development or acquisition of container orchestration components, would block the ability to add unauthorized roles/permissions; this is a genuine but minority slice because the control is a requirements-gathering process whose effect depends on downstream implementation rigor and does not itself enforce the resulting controls.
T1102.001detects — A.8.26 requires applications (incl. those offering transactional services) to identify and address requirements for transaction logging/monitoring, interfaces to logging/monitoring systems, and error-message handling; these can surface anomalous resolver-like behavior or unexpected external redirects in developed/acquired apps, but the control stops at requirements identification and does not mandate or perform detection itself.
T1102.002detects — A.8.26 requires identification and specification of application security requirements (including input/output controls, transaction logging/monitoring, non-repudiation, interfaces to logging/monitoring systems, and error handling) that can surface anomalous or unauthorized use of web services for C2 when those requirements are enforced in developed/acquired apps, but this is only a slice of the technique's surface (e.g., does not address adversary use of external legitimate services from already-compromised hosts outside app boundaries).
T1110detects — A.8.26 requires applications to identify and address security requirements including authentication, input validation, logging/monitoring, non-repudiation, and interfaces to logging/monitoring or data leakage systems, which can surface brute-force attempts in transactional or auth flows but only for the slice of applications built under it and only where those specific requirements are selected and implemented.
T1110prevents — A.8.26 requires identification and specification of application security requirements including authentication strength, input validation, resilience against attacks, and cryptography (explicitly referencing 8.5 and 8.24), which can stop many online brute-force vectors at the application layer; it does not address offline attacks, non-application vectors, or implementation gaps.
T1110.001detects — A.8.26 requires applications to identify and address security requirements including authentication, input controls, transaction logging/monitoring, non-repudiation, and interfaces to logging/monitoring systems, which can surface password guessing attempts in covered applications but does not mandate detection across all targeted services, protocols, or non-application vectors such as network devices or external SSO.
T1110.001prevents — A.8.26 requires identification and specification of application security requirements including authentication strength, resilience against malicious attacks, input controls, and cryptography (explicitly referencing 8.5 and 8.24), which directly constrain password guessing on application surfaces and services when those requirements are enforced.
T1110.002prevents — A.8.26 requires identification and specification of application security requirements including authentication strength (5.17/8.2/8.5), password-related controls, and resilience against attacks, which when followed prevents many classes of weak/guessable credentials that T1110.002 relies on; it is only partial because the control is a requirements-setting process whose effect depends on what the risk assessment actually selects and the application actually implements.
T1110.003prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust levels, input controls, and resilience against malicious attacks) that can lead to stronger auth mechanisms blocking password spraying; however, it only mandates a requirements process rather than any concrete mechanism, so it prevents only where those requirements are later implemented.
T1110.004detects — A.8.26 requires applications to identify and address security requirements including authentication trust levels, input validation, transaction logging/monitoring, non-repudiation, and interfaces to logging/monitoring or data leakage detection systems, which can surface credential stuffing attempts in application-layer auth flows but does not mandate or guarantee detection across all targeted services, protocols, or non-application vectors listed in the technique.
T1110.004prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust levels, input validation, output controls, and resilience against attacks) that, when implemented, can block credential stuffing vectors in developed or acquired apps; this is only a slice because the control is a requirements-gathering process whose effect depends on downstream implementation rigor and does not constrain reuse of breached credentials at the authentication boundary itself.
T1111detects — A.8.26 requires applications to identify and address security requirements including authentication trust, input validation/integrity checks, logging/monitoring, non-repudiation, and interfaces to logging/monitoring or data leakage detection systems; this surfaces some MFA-interception vectors (e.g. anomalous input or out-of-band compromise) when requirements drive application-level detection but leaves the bulk of hardware-token keylogging, SMS provider compromise, and non-application vectors untouched.
T1111prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, input validation, output controls, and resilience against malicious attacks), which when applied to MFA-handling apps can prevent classes of interception vectors such as weak input capture or insufficient out-of-band protections; this is only a slice of T1111 because the technique also covers hardware token keylogging, SMS provider compromise, and runtime proxying outside the development/acquisition requirements process.
T1114.001prevents — A.8.26 requires identifying and specifying security requirements (including data classification, protection of data at rest/transit, encryption, access segregation, input/output controls, and logging) that, when applied during app development/acquisition, can prevent email-collection techniques by mandating protections on email-handling applications and their local data stores; this is only a slice because the control is a requirements-setting process, not an enforcement mechanism, and does not reach non-application vectors or legacy email clients.
T1114.002detects — A.8.26 requires identification and specification of application security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling, which can surface anomalous email access or collection activity when those requirements are implemented in the mail application or supporting systems.
T1127prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks such as injections, input validation, and controls derived from risk assessment) when developing or acquiring applications, which can prevent the insecure inclusion or allowance of trusted developer utilities that enable proxy execution of malicious payloads.
T1127.001detects — A.8.26 requires identification and specification of application security requirements (including input controls, integrity checks, resilience against malicious attacks, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems), which can surface anomalous or suspicious use of build tools like MSBuild in development pipelines; this is a genuine but minority slice of the technique (mostly post-build or non-development abuse of the signed binary).
T1127.001prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, and secure development practices) when acquiring or developing applications, which can prevent abuse of build tools like MSBuild in custom or acquired software but does not address adversary abuse of the pre-installed trusted MSBuild.exe binary on existing Windows systems.
T1127.002detects — A.8.26 requires identification of application security requirements including input controls/validation, output controls, transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against malicious attacks; these can surface anomalous or suspicious ClickOnce usage (e.g. via monitoring of execution, startup persistence, or untrusted .application/.appref-ms files) but do not mandate or guarantee detection mechanisms for this specific proxy technique.
T1127.002prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, output controls, authentication, segregation of access, and cryptography) when developing or acquiring applications, which can prevent abuse of ClickOnce as a proxy technique if those requirements are enforced in custom or acquired .NET apps.
T1129detects — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks, input controls, logging/monitoring interfaces, and error handling) that can surface anomalous module-loading behavior in custom or acquired applications, but does not mandate runtime detection mechanisms or coverage of OS-level shared-module loading outside the application boundary.
T1133prevents — A.8.26 requires identifying and specifying security requirements (including authentication, access segregation, resilience against attacks, input validation, and cryptography) when developing or acquiring applications, which can prevent some classes of exposed unauthenticated remote services or weak remote access implementations but does not address already-deployed services, misconfigurations, or persistence vectors like Tor hidden services.
T1134detects — A.8.26 requires applications to identify and address security requirements including resilience against malicious attacks, input controls/validation, transaction logging/monitoring, non-repudiation, and interfaces to logging/monitoring or data leakage detection systems; these can surface anomalous token use or related access anomalies in application context but do not broadly detect the Windows-level technique itself.
T1134.001prevents — A.8.26 requires identification and specification of application security requirements (including segregation of access, resilience against malicious attacks, input/output controls, and authentication) that can be met by secure design and coding practices preventing token theft/impersonation flaws at development time; this is only a slice because the control is a requirements-gathering process whose effect depends on what the implementer actually builds and because the technique can also be exercised against already-running processes outside the developed application.
T1134.003detects — A.8.26 requires applications to identify and address security requirements including authentication, access segregation, input validation, transaction logging/monitoring, non-repudiation, and interfaces to logging/monitoring systems, which can surface anomalous token creation or impersonation in application-level logs or monitoring but does not mandate or guarantee detection of the low-level Windows API technique itself.
T1134.003prevents — A.8.26 requires identification and specification of application security requirements including authentication, access segregation, resilience against malicious attacks, input validation, and cryptography; these can prevent token creation/impersonation flaws when baked into the app (e.g. avoiding weak LogonUser patterns), but the control is a requirements process whose coverage depends on what the risk assessment and implementer actually select, leaving a large slice of Windows token logic unreached.
T1137detects — A.8.26 requires identification and specification of application security requirements (including input controls, integrity checks, transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against malicious attacks), which can surface Office-application startup abuse mechanisms when requirements are evaluated or tested; this is a genuine but minority slice of the broad technique (most instances occur in already-deployed configurations rather than during requirements gathering).
T1137prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, and output controls) that can address Office macro/add-in abuse for persistence when those requirements are flowed into development or acquisition; this constrains the technique in custom or in-house Office applications but reaches none of the widely deployed COTS Office suite itself.
T1137.001detects — A.8.26 requires identification of application security requirements including transaction logging/monitoring, non-repudiation, interfaces to logging/monitoring systems, and error handling; these can surface anomalous macro-enabled template behavior at development or acquisition time, but the control stops at requirements and does not mandate runtime detection mechanisms.
T1137.001prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as macro abuse, input controls, and macro-related restrictions derived from business processes or other controls), which when applied during development or acquisition of Office/custom applications can prevent the template-macro persistence vector; this is only a slice because the control is a requirements-setting process whose effect depends on what the implementer chooses to specify and enforce, and it does not constrain already-deployed Office instances or user-enabled macros.
T1137.002detects — A.8.26 requires identifying and specifying application security requirements (including input controls, integrity checks, transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling) that can surface anomalous registry modifications or Office startup behaviors when those requirements drive monitoring implementation.
T1137.003detects — A.8.26 requires identification and specification of application security requirements (including input controls, output controls, transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling) that can surface anomalous or malicious form behavior during development or acquisition, but does not mandate runtime detection mechanisms or monitoring of deployed Outlook forms.
T1137.003prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks, input controls/validation, and output controls) that would surface and block the insecure custom-form design allowing code execution on receipt; this constrains the technique for applications developed or acquired under the control, but does not reach pre-existing Outlook forms or non-development vectors.
T1137.004detects — A.8.26 requires identification and specification of application security requirements (including input controls, output controls, error message handling, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems) that can surface the malicious HTML/URL abuse during development or acquisition of Outlook-integrated applications, but this is limited to requirements-setting for new/custom apps and does not broadly detect the post-compromise persistence technique in deployed Outlook clients.
T1137.004prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks, input controls, output controls, and restrictions on free-text/content that could enable code execution), which when applied to Outlook customizations would block many Home Page abuse vectors; however, it is a requirements-setting process rather than an enforcement mechanism, and the legacy feature's specifics are not named so coverage is a chosen slice rather than the bulk with a bounded remainder.
T1137.005detects — A.8.26 requires identification of application security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and error message handling; these can surface anomalous rules or crafted-email triggers in Outlook apps, but the control only sets requirements rather than mandating any specific detection mechanism or coverage depth.
T1137.005prevents — A.8.26 requires identification and specification of application security requirements (including input controls, integrity checks, resilience against malicious attacks, and restrictions on free-text fields) that, when applied during development or acquisition of Outlook or related email-handling applications, would block the creation or loading of malicious rules that enable this persistence technique.
T1137.006detects — A.8.26 requires identification and specification of application security requirements (including input controls, integrity checks, resilience against malicious attacks, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems), which surfaces the presence of malicious add-ins when those requirements drive monitoring or detection mechanisms; however, the control itself only mandates requirements identification rather than mandating or performing detection, and many add-in types fall outside the transactional/electronic-ordering scope where monitoring is explicitly called out.
T1137.006prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input controls, and mandated controls from other clauses) during app development or acquisition; this can lead to requirements that block malicious add-in registration or auto-execution at Office startup, but the control only sets a requirements process whose coverage of this specific persistence vector is a chosen slice rather than the bulk with a bounded remainder.
T1176prevents — A.8.26 requires identifying and specifying security requirements (incl. resilience against malicious attacks, input validation, authentication, segregation of access, and secure development practices) when building or acquiring applications, which can constrain extension-related weaknesses in custom or in-house apps but does not address third-party marketplaces, user-installed extensions, or runtime abuse of benign ones on Linux/macOS/Windows.
T1176.001prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks, input validation, authentication, segregation of access, and cryptography) when developing or acquiring applications; this can prevent classes of malicious-browser-extension behaviors that arise during app/extension development, but leaves the dominant post-compromise installation vectors, file manipulation, and user-installed extensions on general-purpose browsers untouched.
T1176.002prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, authentication, segregation of access, and cryptography) when developing or acquiring applications; this can prevent malicious IDE extensions from being introduced in custom or in-house IDE-related software but does not constrain adversary abuse of third-party marketplace extensions or side-loading on end-user systems.
T1185detects — A.8.26 requires identification and specification of application security requirements (including input validation, output controls, logging/monitoring interfaces, error handling, and resilience against malicious attacks such as injections), which surfaces the need for detection mechanisms in developed or acquired applications; this can detect some session hijacking behaviors (e.g., anomalous proxying or injection) but only where the application itself is the development target, leaving the bulk of browser pivoting and inherent browser vulnerabilities outside its scope.
T1185prevents — A.8.26 requires identifying and specifying security requirements (incl. authentication, segregation of access, resilience against malicious attacks/injections, input validation, output controls, cryptography, and non-repudiation) that would block most session hijacking vectors if implemented in developed/acquired apps and browsers; it does not guarantee their correct or complete enforcement.
T1187detects — A.8.26 requires applications to identify and address security requirements including input controls, integrity checks, output controls, transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling; these can surface forced-authentication attempts when the technique interacts with a monitored application (e.g. via crafted input, output, or transaction), but the control is silent on endpoint, network, or non-application detection and does not mandate coverage of the dominant vectors (SMB/WebDAV/.LNK/.SCF/EFSRPC).
T1187prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, input controls, output controls, and resilience against malicious attacks) that can be used to prevent forced-authentication vectors in developed or acquired applications, but the control only mandates that these requirements exist and does not itself enforce or implement the preventive mechanisms.
T1189prevents — A.8.26 mandates identification and specification of application security requirements (including resilience against malicious attacks such as SQL injection, input validation, output controls, XSS-relevant content restrictions, and cryptography) that directly address several delivery vectors for drive-by compromise when those requirements are applied during development or acquisition of the affected web applications or browsers.
T1190prevents — Specifying resilience requirements against injection and buffer-overflow attacks forces developers to implement input validation and secure coding practices that reduce the likelihood of successful exploitation of public-facing applications.
T1195detects — A.8.26 requires identifying and specifying security requirements (including risk assessment, input validation, integrity checks, secure development practices, and cryptography) that can surface supply-chain risks during requirements or acquisition review, but it does not mandate or perform detection mechanisms on delivered products, updates, or dependencies.
T1195prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, integrity checks, secure development practices, and supply-chain-relevant topics such as trust in components and cryptography) when acquiring or developing applications, which constrains several supply-chain manipulation vectors (e.g. tainted open-source dependencies, insecure update mechanisms) but does not stop all of them (e.g. physical shipment interdiction, factory-infected hardware, or second-order compromises after initial access).
T1195.001prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as injections, input validation, segregation of access, and secure development practices) that, when followed, stop many classes of compromised dependencies/tools from being introduced into the build; this is a genuine but minority slice of the broad supply-chain technique (e.g. it does not reach abandoned-package revival, typosquatting, or upstream CI/CD compromise before the consuming application is developed).
T1195.002prevents — A.8.26 requires identifying/addressing security requirements (incl. resilience against malicious attacks such as buffer overflows/SQL injections, input validation, integrity mechanisms, cryptography, and secure development practices) when building or acquiring applications, which can stop many forms of source-code or build manipulation before the compromised software ships.
T1197detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against malicious activity; this can surface anomalous BITS job usage when applications are built under it, but the control is about requirements identification during development/acquisition rather than mandating runtime detection mechanisms for the technique itself.
T1199prevents — A.8.26 requires identifying and specifying security requirements (including trust in identities, segregation of access, resilience against attacks, and requirements derived from other controls) when developing or acquiring applications that support trusted third-party relationships, which can constrain the technique by design; however, it only mandates a requirements process rather than mandating any specific protective mechanism, leaving implementation-dependent gaps.
T1202prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, and other controls derived from risk assessment), which can prevent the insecure application behaviors that enable indirect command execution utilities; however, it is a requirements/governance control that does not itself implement or enforce those protections.
T1203prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, output controls, and secure development practices), which when followed during development or acquisition directly stops many classes of client-application vulnerabilities that T1203 relies on; it is only partial because the control is a requirements-gathering process whose effect depends on downstream implementation rigor and does not reach already-deployed third-party client software.
T1204.001prevents — A.8.26 requires applications to specify and address security requirements including resilience against malicious attacks (explicitly naming SQL injection and buffer overflows), input validation, output controls, and cryptography; this can prevent certain malicious-link follow-on paths (e.g. client-side exploits or unsafe file downloads triggered by the link) when the application is built accordingly, but leaves the social-engineering click itself and non-application vectors untouched.
T1204.002detects — A.8.26 requires identification and specification of application security requirements (including input validation, output controls, transaction logging/monitoring, error handling, and interfaces to logging/monitoring or data leakage detection systems) that can surface indicators of malicious files being opened or executed in the resulting application; this is a genuine but minority slice of the technique (user-opened files anywhere on Linux/macOS/Windows, including non-application vectors).
T1204.002prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks such as buffer overflows/SQL injections, input validation, output controls, and cryptography) that can be built into applications to block execution of malicious files, but this is a governance/requirements process whose effect on the technique depends on downstream implementation rigor and does not reach user-opened files outside the developed/acquired applications.
T1204.005prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input controls, integrity, and cryptography) during app development or acquisition, which can prevent use of malicious libraries in first-party or in-house apps but does not constrain user-installed third-party libraries or supply-chain compromise of public packages.
T1210prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, and cryptography) that, when followed in development or acquisition, prevent many exploitable vulnerabilities in remote services or applications; however, it is a requirements process rather than a universal mechanism, does not address patching or configuration of already-deployed services, and leaves many classes of remote-service flaws (e.g., in third-party COTS like SMB/RDP/VMware) outside its direct reach.
T1211prevents — A.8.26 mandates identifying and specifying security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, output controls, logging/monitoring/non-repudiation, and cryptography) at design time for applications under development or acquisition; this prevents the introduction of many exploitable flaws that could later be leveraged for stealth/evasion, but leaves a large remainder of already-deployed third-party apps, runtime environments, cloud/SaaS infrastructure, and post-deployment vulnerabilities unaddressed.
T1212prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, input validation, integrity checks, resilience against SQL injection/buffer overflows, and cryptography) that directly address many of the programming errors and validation failures the technique exploits for credential access; this is a genuine but incomplete slice because the control only mandates requirements derivation via risk assessment rather than mandating or enforcing the specific mechanisms that stop exploitation.
T1213prevents — A.8.26 requires identification and specification of security requirements (including access segregation, authentication, input/output controls, data classification, encryption, and resilience against attacks) when developing or acquiring repository applications, which can stop the broad-access misconfigurations that enable T1213; it is only a slice because the control is a requirements-gathering process whose effect depends on later implementation rigor and does not reach already-deployed repositories or non-development acquisition paths.
T1213.001prevents — A.8.26 requires identifying and specifying security requirements (including access segregation, confidentiality/integrity protection, input/output controls, and non-repudiation) that, when applied during development or acquisition of applications like Confluence, would stop many classes of sensitive content from being stored in the first place or from being left accessible to adversaries.
T1213.002prevents — A.8.26 requires identifying and specifying security requirements (including classification, access segregation, confidentiality/integrity protection, input/output controls, and non-repudiation) when developing or acquiring applications such as SharePoint; this can prevent storing the listed sensitive items in an easily mineable repository, but only for the slice of requirements the organization actually derives and enforces rather than the bulk of the technique.
T1213.003prevents — A.8.26 requires identification and specification of application security requirements (including authentication, access segregation, input validation, output controls, logging, and cryptography) that, when applied to the web apps or services hosting code repositories, can block the initial access or data-collection steps of the technique; this is only a slice because the control is a requirements-setting process whose effect depends on what the implementer chooses to require and on repositories outside the developed/acquired applications.
T1213.004prevents — A.8.26 requires identification and specification of application security requirements (including data classification, access segregation, input/output controls, encryption, logging, and privacy protections) that, when applied during CRM development or acquisition, would stop the application from exposing customer PII to post-compromise mining; this is only a slice because the control is a requirements-gathering process whose effect depends on later implementation rigor and does not itself stop an already-compromised environment from reaching the data store.
T1213.006prevents — A.8.26 requires identification and specification of application security requirements (including authentication, access segregation, input validation, encryption, logging, and resilience against attacks such as SQL injection) that, when applied during development or acquisition of database-backed applications, prevent many common vectors for unauthorized database access and mining; it does not cover already-deployed databases, misconfigurations, or all SaaS/IaaS scenarios.
T1216prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks, input validation, output controls, and secure development practices) that can address proxy-execution vectors when applications are built or acquired, but does not mandate or enforce any runtime mechanism that stops the abuse of signed Microsoft scripts on already-deployed Windows systems.
T1216.001prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as injections, input validation, and output controls) that would address the abuse of signed scripts like PubPrn for proxy execution when those requirements are incorporated into custom or acquired applications.
T1218.001detects — A.8.26 requires applications to identify and address security requirements including input validation, output controls, error message handling, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems; these can surface anomalous or malicious use of CHM files (e.g. via embedded payloads or hh.exe abuse) when the application processes or delivers such content, but the control is scoped only to application development/acquisition and does not mandate detection for general CHM abuse outside that boundary.
T1218.003detects — A.8.26 requires identification of application security requirements including input controls, integrity checks, input validation, transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against malicious attacks such as injections; these can surface anomalous or malicious use of CMSTP/INF processing in developed or acquired applications, but the control stops at requirements identification rather than mandating runtime detection mechanisms and does not address abuse of a signed OS binary outside the application.
T1218.003prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, and output controls) when developing or acquiring applications; this can lead to requirements that harden custom applications against CMSTP abuse vectors (e.g. restricting INF handling or untrusted inputs), but does not prevent the technique against the signed OS binary itself or third-party acquired software.
T1218.004prevents — A.8.26 requires that application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, output controls, and cryptography) be identified and addressed during development or acquisition; this can prevent the insecure design or coding that would allow InstallUtil abuse for proxy execution or signed-binary bypass, but only for custom in-house or acquired applications and not for the pre-existing trusted Microsoft utility itself.
T1218.005detects — A.8.26 requires identifying and specifying application security requirements (including input controls, integrity checks, resilience against malicious attacks, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems), which can lead to detection mechanisms for mshta.exe abuse in developed/acquired applications, but this is only a slice of the technique's use cases (e.g., initial compromise outside custom apps or on unmanaged systems).
T1218.005prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as injections, input validation, output controls, and secure development practices) that would constrain or eliminate the insecure use/abuse of mshta.exe when such requirements are applied during application development or acquisition.
T1218.008detects — A.8.26 requires applications to identify and address security requirements including input controls, integrity checks, transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling; these can surface anomalous use of signed binaries like odbcconf.exe for DLL proxying when the application or its monitoring is in scope, but the control is about requirements for development/acquisition rather than mandating runtime detection of this technique across the enterprise.
T1218.008prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks such as injections, input validation, and secure development practices) when building or acquiring applications; this can lead to application-control or code-level requirements that block abuse of living-off-the-land binaries such as odbcconf.exe, but the control only sets a requirements-identification process rather than mandating any specific blocking mechanism, leaving most of the technique's bypass surface untouched.
T1218.009detects — A.8.26 requires identification and specification of application security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against malicious attacks; this surfaces anomalous use of signed binaries like Regsvcs/Regasm for proxy execution when those requirements drive monitoring scope, but the control itself only mandates requirements rather than mandating instrumentation or detection coverage.
T1218.012detects — A.8.26 requires identification of application security requirements including resilience against malicious attacks, input controls/validation, transaction logging/monitoring, interfaces to logging/monitoring systems, and error message handling; these can surface anomalous use of verclsid.exe or related COM abuse during development or acquisition, but the control stops at specifying requirements rather than mandating runtime detection mechanisms.
T1218.012prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as injections, input validation, and secure development practices) that would prevent vulnerable applications from being built or acquired in a way that enables verclsid.exe abuse for proxy execution; this is a genuine but minority slice of the technique, which primarily targets living-off-the-land binaries on already-deployed Windows systems rather than defects introduced during app development.
T1218.013prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as injections, input validation, and secure development practices), which can prevent unsafe use or integration of mavinject.exe in developed/acquired applications; this is only a slice of the technique's abuse surface (e.g., in existing signed binaries or non-application contexts).
T1218.015detects — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks, input validation, output controls, transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling), which surfaces the need to instrument Electron apps for anomalous JS execution, arbitrary commands, or sandbox bypasses; this is a genuine but minority slice of the technique's surface rather than broad detection coverage.
T1218.015prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks such as injections, input validation, output controls, segregation of access, and secure development practices) when building or acquiring applications; this would constrain Electron-based apps from exposing unsafe mechanics or allowing malicious JS injection if those requirements are enforced in design, but the control only mandates the requirements process itself and does not guarantee their complete or correct implementation against all Electron abuse vectors.
T1219detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against malicious activity; this surfaces anomalous remote access tool usage when the application itself (or its interfaces) is the vector or target, but leaves the bulk of post-compromise RAT deployment and C2 on non-application vectors undetected.
T1219.001detects — A.8.26 requires identifying and specifying security requirements (including monitoring, logging, interfaces to detection systems, and resilience against malicious activity) during app development or acquisition; this surfaces the need for detection of anomalous IDE tunneling in dev workflows but does not itself perform or guarantee detection of the technique.
T1219.001prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input controls, authentication, segregation of access, and cryptography) during application development or acquisition, which can constrain IDE tunneling in custom or acquired dev tools but does not block abuse of built-in IDE features or extensions on compromised developer endpoints.
T1220detects — A.8.26 requires identifying and addressing security requirements (including input validation, output controls, error handling, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems) that can surface anomalous XSL/script-processing behavior in developed or acquired applications, but does not mandate runtime detection mechanisms for the technique itself.
T1220prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as SQL injections, input validation, and output controls) that would address XSL script processing if applied during development or acquisition of affected applications; this is a genuine but minority slice because the control is a requirements-gathering process rather than an enforcement mechanism and does not reach runtime abuse of built-in Windows tools such as msxsl.exe or wmic.
T1221detects — A.8.26 requires identification and specification of application security requirements (including input controls, integrity checks, output controls, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems) that can surface template injection via malformed documents or anomalous fetches, but this is limited to requirements-setting for development/acquisition rather than any runtime or scanning detection mechanism.
T1221prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as SQL injections, input validation, output controls, and cryptography) that can be applied during development or acquisition to stop template references from being abused to conceal/fetch malicious code.
T1484detects — A.8.26 requires identification and specification of application security requirements (including input validation, integrity checks, logging/monitoring interfaces, non-repudiation, and error handling) that can surface anomalous or unauthorized policy modifications when those requirements are implemented in apps managing domain/tenant configs; this is a genuine but minority slice of the broad technique that also covers direct AD/IdP abuse outside any application.
T1484.002detects — A.8.26 requires identification and specification of application security requirements (including authentication trust, segregation of access, resilience against attacks, logging/monitoring interfaces, and non-repudiation) that can surface anomalous or malicious trust modifications during development or acquisition, but this is limited to the requirements-gathering phase for new or acquired apps and does not broadly detect runtime or post-deployment trust manipulation across identity providers or domains.
T1484.002prevents — A.8.26 requires identification and specification of application security requirements (including authentication, trust in identities, segregation of access, resilience against attacks, and cryptography) during development or acquisition; this constrains trust-related misconfigurations in custom or acquired apps but does not reach runtime trust modifications, AD FS/Okta/AWS IAM changes, or non-application identity provider configurations.
T1485recovers — A.8.26 requires applications to identify and address security requirements including resilience, backup-related logging/monitoring, non-repudiation, and (via cross-reference to 8.13) data protection at rest/transit that enable post-destruction recovery of critical data, but this is only a slice of the technique's scope (e.g., does not address VM/container deletion or worm-like propagation).
T1486recovers — A.8.26 requires applications to identify and address security requirements including data protection at rest/transit, encryption of communications, transaction logging/non-repudiation, and (for payment/ordering apps) maintaining confidentiality/integrity while storing transaction details outside public environments; these directly enable recovery mechanisms that restore availability after T1486's encryption impact, with a named remainder for non-application data or unaddressed legacy systems.
T1491.001detects — A.8.26 requires identification of application security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling; these can surface defacement (e.g. via anomalous changes to internal web content or login messages) when the application is built to do so, but the control only sets requirements rather than mandating detection coverage across all internal systems or non-application vectors such as desktop wallpaper changes.
T1491.001prevents — A.8.26 requires identification and specification of application security requirements including resilience against malicious attacks (explicitly naming SQL injection and buffer overflows as examples), input validation, output controls, integrity mechanisms, and secure development practices that can stop defacement vectors in internally-facing applications and web content before they are introduced.
T1491.002prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, output controls, segregation of access, and cryptography) that, when followed in development/acquisition, prevent many common vectors for external defacement such as injection or weak authorization on public-facing web apps; it does not cover all cases (e.g. server misconfigurations, zero-days, or post-deployment changes).
T1496detects — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks, input validation, logging/monitoring interfaces, transaction monitoring and error handling) that can surface anomalous resource consumption or abuse in developed/acquired apps, but this is only a requirements-gathering activity with no guarantee of runtime detection mechanisms being present or effective against post-deployment hijacking techniques like cryptomining or proxying.
T1496.001detects — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input controls, transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and error handling) that can lead to detection mechanisms for anomalous compute usage or mining activity, but this is only a slice of possible requirements rather than mandating detection itself.
T1496.002detects — A.8.26 requires identification of application security requirements including resilience against malicious attacks, transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and error handling; these can surface anomalous bandwidth consumption or related indicators in monitored applications but do not broadly instrument or detect the technique across all co-opted systems, botnets, proxyjacking, or scanning.
T1496.003detects — A.8.26 requires identification of application security requirements including input controls, integrity checks, input validation, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems; these can surface anomalous SMS-pumping traffic (e.g. via rate or volume anomalies on OTP/verification forms) but the control only mandates that such requirements exist and does not itself perform detection.
T1496.003prevents — A.8.26 requires identifying and specifying application security requirements (including input controls, validation, rate limits implied by resilience, and business-derived monitoring/non-repudiation) that can stop abuse of OTP/verification forms used to drive SMS pumping; this is genuine but only a slice because the control is purely requirements-setting and does not mandate or enforce any specific mechanism.
T1496.004detects — A.8.26 requires identification and specification of application security requirements (including resilience against attacks, input/output controls, transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling) that can surface anomalous SaaS usage patterns like bulk spam or LLMjacking, but only as part of requirements gathering rather than mandating runtime detection mechanisms.
T1496.004prevents — A.8.26 requires identifying and specifying security requirements (including authentication, access segregation, resilience against malicious attacks, input/output controls, and non-repudiation) when developing or acquiring applications; this can prevent the initial compromise of a SaaS app that an adversary would then hijack for resource abuse, but it does not stop post-compromise abuse of already-authorized SaaS services or enabling of unused platform services.
T1498detects — A.8.26 requires identification of application security requirements including resilience against malicious attacks, transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and error message handling; these surface anomalous traffic or DoS indicators in application context but only for applications developed/acquired under the control, leaving network-layer, non-application, and volumetric DDoS outside its scope.
T1498recovers — A.8.26 requires applications to identify and address resilience requirements against malicious attacks or disruptions (explicitly naming buffer overflows/SQL injection but extensible to availability), which for web-based apps targeted by T1498 can include recovery mechanisms such as failover, redundancy, or graceful degradation to restore availability post-attack.
T1499detects — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks, input validation, output controls, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems), which surfaces some DoS-relevant conditions during development or acquisition but does not itself perform detection of the live technique.
T1499prevents — A.8.26 requires identifying and specifying resilience requirements against malicious attacks (explicitly naming buffer overflows and SQL injections) plus input validation, output controls, segregation, and cryptography that can stop many endpoint DoS vectors at design time; this is genuine but only a slice because the control stops at mandating requirements rather than enforcing their correct implementation, and many T1499 methods (botnets, spoofing, resource exhaustion at OS or server layers) sit outside the named application-layer examples.
T1499.001detects — A.8.26 requires identification of resilience requirements against malicious attacks (explicitly naming buffer overflows and SQL injections as examples) plus monitoring/logging interfaces; this surfaces some DoS-relevant needs during development but does not mandate runtime detection of OS-exhaustion floods such as SYN/ACK floods.
T1499.001prevents — A.8.26 requires identifying and specifying resilience requirements against malicious attacks (explicitly naming buffer overflows and SQL injections as examples), which can include OS-level DoS protections such as connection limits, SYN cookies or rate limiting when derived from risk assessment; this reaches only a slice of the technique because the control is a requirements-gathering process whose effect depends on what the implementer actually chooses to specify and enforce.
T1499.002detects — A.8.26 requires identification of resilience requirements against malicious attacks (explicitly naming SQL injection and buffer overflows, plus input validation, output controls, logging/monitoring interfaces, and error handling), which surfaces many volumetric or protocol-exhaustion DoS vectors during requirements gathering; it does not itself instrument or perform detection.
T1499.002prevents — A.8.26 requires identifying and specifying resilience requirements against malicious attacks (explicitly naming buffer overflows and SQL injections as examples) and can extend to DoS via risk assessment for web/transactional apps, but it only sets requirements rather than mandating any specific mechanism that stops service-exhaustion floods such as HTTP floods or SSL renegotiation.
T1499.003detects — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks, input controls, output controls, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems), which surfaces the need to detect resource-exhaustion floods but does not itself implement or perform detection.
T1499.003prevents — A.8.26 requires identifying and specifying resilience requirements against malicious attacks (explicitly naming buffer overflows and SQL injections as examples) and input controls/validation during app development/acquisition; this prevents resource-exhaustion DoS vectors when the risk is surfaced in assessment and the resulting requirements are met, but the control only sets a requirements process rather than mandating any specific mechanism that stops the technique.
T1499.004detects — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks, input validation, output controls, error handling, and monitoring/logging derived from business processes), which can surface exploitable vulnerabilities or anomalous crash conditions during development or acquisition, but does not mandate runtime detection mechanisms or ongoing monitoring of exploitation in deployed systems.
T1499.004prevents — A.8.26 requires identifying and specifying resilience requirements against malicious attacks (explicitly naming buffer overflows and SQL injections) and other protections (input validation, integrity, cryptography) that can stop many exploitable vulnerabilities from reaching production, but it is a requirements-gathering process rather than an enforcement mechanism and does not reach zero-days or all crash vectors.
T1505prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, segregation of access, and secure development practices) when acquiring or developing applications; this can prevent the insecure extensible features that T1505 abuses, but only for applications built or selected under the control and does not reach pre-existing or third-party server software.
T1505.001detects — A.8.26 requires identification of application security requirements including resilience against SQL injections, input validation, transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling; these can surface malicious stored-procedure creation or anomalous invocation as part of requirements-driven monitoring, but the control stops at specifying requirements rather than mandating any detection mechanism and leaves many persistence vectors (CLR assemblies, startup procedures, xp_cmdshell enablement) outside its named scope.
T1505.001prevents — A.8.26 requires identifying and specifying security requirements (including resilience against SQL injections, input validation, and secure development practices) when building or acquiring applications, which can prevent creation of malicious or vulnerable stored procedures that enable persistence; however, it is a requirements/governance control that does not itself enforce or implement those protections in code or deployed databases.
T1505.002prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input/output controls, segregation of access, and protections for data in transit/processing) when developing or acquiring applications; this reaches the developer-written .NET transport-agent scenario in the source prose and would prevent registration of a malicious one if those requirements are met, but the control stops at requirement-setting and does not itself enforce or implement those protections.
T1505.003detects — A.8.26 requires identifying and specifying security requirements (including input validation, output controls, error handling, logging/monitoring interfaces, and resilience against attacks such as injections) that can drive detection capabilities for anomalous web-server behavior or web-shell artifacts; however, the control only mandates requirements identification during development/acquisition and does not itself perform or enforce detection.
T1505.003prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as SQL injection and buffer overflows, input validation, segregation of access, and secure development practices), which when followed during web application development prevents many classes of web shell insertion; however, it is a requirements/governance control that does not itself enforce or implement those protections at runtime or across all deployment paths.
T1505.004prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks such as injections, input validation, access segregation, and secure development practices) when building or acquiring applications; this can prevent vulnerable IIS components from being developed or deployed that allow malicious installation, but does not address post-compromise installation of malicious extensions/filters/modules on existing IIS servers.
T1525detects — A.8.26 requires identifying and specifying security requirements (including input validation, integrity checks, resilience against malicious code, logging/monitoring interfaces, and error handling) that can drive detection of anomalous or malicious images during development or acquisition, but the control itself only sets requirements and does not perform or mandate any runtime detection mechanism.
T1528detects — A.8.26 requires identification of security requirements including input controls/validation, output controls, transaction logging/monitoring, non-repudiation, interfaces to logging/monitoring systems, and error handling; these can surface anomalous token issuance, usage, or OAuth flows after the fact, but the control only mandates that such requirements exist rather than mandating any specific detection mechanism or coverage of all token-theft vectors (e.g., container compromise, IMDS requests, or social-engineering OAuth registration).
T1528prevents — A.8.26 requires identifying and specifying security requirements (including authentication, segregation of access, resilience against attacks, input/output controls, and cryptography) when developing or acquiring applications; this can prevent classes of token-theft vectors (e.g., weak OAuth flows, exposed service-account tokens in containers/CI-CD, missing input validation for phishing-driven grants) but leaves many post-compromise or runtime theft vectors (e.g., compromised containers, IMDS requests from already-owned resources) untouched.
T1529detects — A.8.26 requires applications to specify and address security requirements including transaction logging, monitoring, interfaces to logging/monitoring systems, and resilience against malicious attacks; this surfaces anomalous shutdown/reboot attempts when those requirements are implemented in monitored applications or services, but the control only sets requirements rather than mandating detection coverage across all platforms, execution paths (CLI, API, hypervisor), or non-application vectors.
T1530detects — A.8.26 requires identification and specification of application security requirements (including input/output controls, logging/monitoring interfaces, transaction logging, data classification, and error handling) that can surface misconfigurations or anomalous access patterns in cloud-storage-handling applications, but does not itself perform or mandate detection mechanisms.
T1530prevents — A.8.26 requires identification and specification of application security requirements (including data classification, access segregation, protection of data at rest/in transit, input/output controls, and cryptography) that directly address misconfigurations allowing unauthorized cloud storage access; this constrains the technique for applications developed or acquired under the control, but does not reach pre-existing cloud storage, non-application IaaS buckets, or credential abuse vectors outside the development process.
T1534detects — A.8.26 requires applications to incorporate requirements for transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and error-message handling; these surface anomalous internal messages, credential-capture attempts or phishing payloads delivered via chat or email clients, but only for applications built or acquired under the control — leaving the bulk of internal spearphishing vectors (compromised accounts, device control, impersonation in non-instrumented tools) unreached.
T1534prevents — A.8.26 requires identification and specification of application security requirements (including input validation, output controls, authentication trust levels, non-repudiation, and resilience against malicious attacks such as injections), which when applied to internal apps (e.g. chat, email, or transactional tools) can prevent the technique from succeeding; this is only a slice of the multi-staged technique that also relies on prior account compromise, device control, and external vectors.
T1537detects — A.8.26 requires identification and specification of application security requirements (including logging/monitoring interfaces, transaction logging, output controls, and resilience against malicious attacks), which can surface anomalous internal cloud data transfers or sharing mechanisms when those requirements drive monitoring implementation, but only for a slice of in-scope applications rather than broadly across cloud accounts or native provider mechanisms.
T1537prevents — A.8.26 requires identifying and specifying security requirements (including data classification, access segregation, protection of data in transit/rest, input/output controls, encryption, and non-repudiation) that, when applied during development or acquisition of cloud apps, can block many T1537 vectors such as improper sharing links, weak SAS URIs, or unencrypted backups; it is only partial because the control is a requirements-gathering process whose effect depends on what the implementer actually specifies and enforces.
T1539detects — A.8.26 requires applications to identify and address security requirements including input controls/validation, output controls, transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling; these can surface session-cookie theft vectors (e.g. malicious JS injection, anomalous access) when implemented in the app or its supporting controls, but the control itself only mandates requirements identification rather than mandating any specific detection mechanism or coverage of all listed theft vectors (malware on disk/memory, network proxies, etc.).
T1539prevents — A.8.26 requires applications to identify and address security requirements including authentication trust (a), segregation of access (c), resilience against malicious attacks such as injections (d), input validation (j), output controls (l), and cryptography for protecting data/transit (h,i), which can stop many session-cookie theft vectors at the application layer (e.g. HttpOnly/Secure flags, anti-XSS, proper session binding); it does not reach client-side storage, browser memory scraping, or proxy-based MitM outside the developed application.
T1546detects — A.8.26 requires identification and specification of application security requirements (including input validation, output controls, logging/monitoring interfaces, error handling, and resilience against malicious attacks), which can surface anomalous or suspicious event-trigger behaviors during development or acquisition of applications that use such mechanisms.
T1546.003detects — A.8.26 requires identification and specification of application security requirements (including input controls, integrity checks, logging/monitoring interfaces, error handling, and resilience against malicious attacks), which can surface anomalous WMI event subscriptions during development or acquisition of monitored applications, but does not mandate runtime detection mechanisms or cover adversary-installed subscriptions on existing systems.
T1546.007detects — A.8.26 requires identifying and specifying application security requirements (including input controls, integrity checks, resilience against malicious attacks, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems), which can surface anomalous netsh helper DLL registrations or executions when those requirements drive monitoring in developed/acquired apps or related components.
T1546.015detects — A.8.26 requires applications to identify and address security requirements including input validation, integrity checks, output controls, transaction logging/monitoring, non-repudiation, and interfaces to logging/monitoring or data leakage detection systems; these can surface anomalous COM registry changes or hijack-triggered behavior in developed/acquired apps, but the control is scoped only to application development/acquisition (not system-wide COM hijacking or runtime detection on Windows)
T1546.015prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, integrity checks, and secure development practices) that, when applied during development or acquisition of applications using COM, would stop many hijacking opportunities from being introduced; it does not reach all COM hijacking vectors (especially post-deployment registry abuse of existing system components or TypeLib modifications).
T1546.016prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, integrity checks, and secure development practices) that can constrain installer script behaviors and reduce the likelihood of malicious postinstall/preinst content being introduced or executed with elevated privileges; this is a genuine but minority slice of the technique's attack surface (e.g., supply-chain and dev-process vectors), not the dominant execution path.
T1546.017detects — A.8.26 requires identification and specification of application security requirements (including input controls, integrity checks, resilience against malicious attacks, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems), which surfaces anomalous udev rule modifications or executions when those requirements drive monitoring in developed/acquired apps, but only for a slice of the technique rather than broadly across Linux systems.
T1547.002detects — A.8.26 requires identifying and specifying application security requirements (including from risk assessment) that can explicitly cover transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against malicious attacks; this surfaces the need to detect anomalous LSA authentication package changes or loads in relevant applications, but the control only sets requirements rather than mandating any specific detection mechanism or coverage of the OS-level Registry autostart technique itself.
T1547.004detects — A.8.26 requires identification of application security requirements including resilience against malicious attacks (explicitly naming SQL injection and buffer overflows), input validation, output controls, logging/monitoring interfaces, and error handling; these can surface anomalous Winlogon modifications or helper-DLL behavior in custom applications but do not broadly instrument the OS-level registry or Winlogon process itself.
T1547.006prevents — A.8.26 requires that security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, authentication, access segregation, and cryptography) be identified and addressed during application development or acquisition; this can prevent some classes of kernel-module rootkits that arise from flawed application code or insecure development, but leaves the bulk of the technique (direct kernel modification, signed kext loading, LKM rootkits installed outside the application SDLC) untouched.
T1547.012detects — A.8.26 requires identification of application security requirements including resilience against malicious attacks, input controls, transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling; these can surface anomalous print-spooler or boot-time DLL behavior in custom or acquired applications, but the control stops at requirements identification and does not mandate runtime detection mechanisms for this OS-level persistence technique.
T1548prevents — A.8.26 mandates identifying and specifying security requirements (including segregation of access, resilience against malicious attacks, input validation, and authorization processes) that, when followed in development/acquisition, constrain or block common abuse paths for elevation mechanisms such as improper authorization or injection-based bypasses.
T1548.001prevents — A.8.26 requires that resilience against malicious attacks (explicitly naming buffer overflows and SQL injection) and related controls such as input validation, access segregation, and secure development be identified and addressed during application acquisition or development; this stops many unsafe setuid/setgid binaries from being introduced, but leaves the pre-existing vulnerable setuid binaries that adversaries discover and abuse untouched, as well as any setuid decisions made outside the application's own development process.
T1548.003prevents — A.8.26 requires identification and specification of application security requirements (including segregation of access, least-privilege principles, resilience against malicious attacks, and input/output controls) that, when followed during development or acquisition of applications using sudo mechanisms, would prevent many poor configurations abused by T1548.003; it is only partial because the control is a requirements-gathering process whose effect depends on what the risk assessment actually selects and the resulting application implements.
T1548.004prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, integrity checks, authentication, and secure development practices) when building or acquiring applications; this can prevent unsafe use or implementation of APIs like AuthorizationExecuteWithPrivileges in custom or acquired macOS software, but leaves the deprecated API itself, its use in unmodified legitimate apps, and non-development vectors untouched.
T1548.005detects — A.8.26 requires identification of security requirements including transaction logging/monitoring, non-repudiation, interfaces to logging/monitoring systems, and error handling; these can surface anomalous just-in-time elevation, impersonation, or PassRole abuse after the fact, but the control is a requirements-gathering process (not an operational detector) whose coverage depends on what the resulting application or cloud config actually logs.
T1548.005prevents — A.8.26 requires identification and specification of application security requirements (including segregation of access, resilience against malicious attacks, input/output controls, and authorization processes) that, when followed in development or acquisition, would block misconfigurations enabling temporary elevated access via JIT, impersonation, or PassRole; this is only a slice because the control is a requirements-gathering process (not an enforcement mechanism) and applies only to in-scope applications rather than all cloud permission configurations.
T1548.006prevents — A.8.26 requires identification and specification of application security requirements (including authentication, access segregation, resilience against malicious attacks such as injections, input validation, and privacy protections) that, when applied during development or acquisition of macOS applications, can stop the TCC database from being manipulable or inheritable by malicious code; this is only a slice of the technique because the control is a requirements-gathering process whose effect depends on downstream implementation rigor and does not reach already-granted permissions, SIP-disabled states, or non-application vectors.
T1550detects — A.8.26 requires applications to identify and address security requirements including authentication trust levels, input/output controls, transaction logging/monitoring, non-repudiation, and interfaces to logging/monitoring or data leakage detection systems, which can surface use of stolen alternate auth material in app-layer or transactional flows but leaves the bulk of OS-level, in-memory, or non-application theft (e.g., Kerberos tickets on Windows/Linux) outside its scope.
T1550prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust levels, segregation of access, resilience against attacks, input/output controls, and cryptography) that can stop applications from generating, caching, or exposing alternate auth material in ways that enable the technique; this is genuine but only a slice, as the control is a requirements-gathering process whose effect depends on what the implementer actually builds and does not reach non-application vectors (e.g., OS-level tickets or stolen hashes).
T1550.001detects — A.8.26 requires applications to identify and address security requirements including authentication, access segregation, input/output controls, transaction logging/monitoring, non-repudiation, and interfaces to logging/monitoring or data leakage detection systems; these can surface anomalous token usage or related access patterns in application design but do not mandate runtime detection mechanisms and leave many token-theft vectors (e.g., refresh token compromise, federation, misconfigured permissions) outside the requirements list.
T1550.001prevents — A.8.26 requires identification and specification of application security requirements (including authentication, access segregation, resilience against attacks, input/output controls, and cryptography) that, when addressed in development or acquisition, can stop many token-theft vectors from being introduced; it does not guarantee complete coverage of all token-compromise paths (e.g. runtime misconfigurations or post-issuance abuse).
T1550.003detects — A.8.26 requires applications to identify and address security requirements including authentication trust, input validation, output controls, transaction logging/monitoring, non-repudiation, and interfaces to logging/monitoring systems; these can surface PtT anomalies (e.g. via anomalous Kerberos usage or access patterns) in application-layer contexts but leave the bulk of OS-level ticket dumping and lateral movement outside the application's scope.
T1550.004detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling; these can surface anomalous use of a stolen session cookie (e.g. via monitoring for impossible travel or unexpected session behavior), but the control is about requirements identification during development rather than mandating runtime detection mechanisms, leaving most of the technique's post-compromise use undetected.
T1550.004prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, segregation of access, resilience against malicious attacks, input/output controls, and cryptography) that, when followed in development or acquisition, can stop session-cookie replay by mandating short-lived/secure cookies, proper invalidation, binding to additional factors, or cryptographic protections; this is only a slice because the control is a requirements-gathering process whose effect depends on what the implementer actually chooses to require and enforce.
T1552prevents — A.8.26 requires identification and specification of application security requirements (including protection of data at rest/transit, input/output controls, encryption, and restrictions on free-text fields that can store credentials), which when applied during development/acquisition prevents many classes of unsecured credential storage in custom applications; it reaches only a slice of the technique because the control does not govern existing/misplaced credentials in OS, third-party apps, or non-application artifacts on already-deployed systems.
T1552.001detects — A.8.26 requires identification of application security requirements including input/output controls, logging/monitoring interfaces, data leakage detection, and error handling that can surface insecure credential storage in files during development or acquisition, but does not mandate runtime or post-deployment detection mechanisms for the technique itself.
T1552.001prevents — A.8.26 requires identifying and specifying security requirements (including authentication, data classification, protection of confidential data, input/output controls, and cryptography per 8.24) during app development/acquisition, which can prevent insecure credential storage in application-created files/configs/source but does not address user-created files, backups, Group Policy, or existing deployed systems.
T1552.003prevents — A.8.26 requires identifying and specifying application security requirements (including input controls, output controls, free-text restrictions, and non-repudiation) that can address insecure credential handling in custom apps, but it does not reach shell history files created by interactive user sessions outside any application.
T1552.004prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, key protection, encryption, input/output controls, and cryptography per 8.24) that, when followed in development or acquisition, stop insecure storage of private keys from arising in those applications; this is only a slice of the technique, which also covers discovery of pre-existing or OS-generated keys on already-compromised hosts.
T1552.005prevents — A.8.26 requires identification and specification of application security requirements (including authentication, segregation of access, resilience against malicious attacks such as injections, input validation, output controls, and cryptography) that can be applied during development or acquisition to block the SSRF vector and direct instance access that enables T1552.005; this is only a slice of the technique because the control is a requirements process, does not itself implement the protections, and leaves the direct-instance-access vector (when the adversary already has presence on the VM) untouched.
T1552.006prevents — A.8.26 requires identification and specification of application security requirements (including input/output controls, data protection, encryption, and resilience against malicious attacks) when developing or acquiring applications; this can prevent embedding credentials in GPP XML files stored on SYSVOL during policy creation, but the control is a requirements process that does not itself enforce or remove the insecure practice in all cases.
T1552.008detects — A.8.26 requires identification of application security requirements including transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and error handling; this surfaces credential exposure in chat messages when those requirements drive monitoring of communication services, but only for the slice of apps built or acquired under the control (not existing chat services or user behavior).
T1552.008prevents — A.8.26 requires identifying and specifying security requirements (including input/output controls, data classification, protection of data in transit/rest, encryption of communications, and restrictions on free-text fields that can store credentials) when developing or acquiring chat/comms applications, which can stop the unsecured sharing that enables the technique; it is only partial because the control is a requirements-gathering process whose effect depends on what the implementer actually builds or buys, and it does not constrain already-deployed services or user behavior on them.
T1553prevents — A.8.26 requires identifying and specifying security requirements (including authentication, trust in identity, resilience against attacks, input validation, cryptography, and certificate management) that, when followed in development/acquisition, prevent many subversions of trust controls such as weak signing or untrusted inputs; it does not guarantee complete coverage of all T1553 vectors (e.g., post-deployment registry/permission changes or stolen certs on existing systems).
T1553.003prevents — A.8.26 requires applications (incl. those performing signature validation) to identify and address security requirements such as resilience against malicious attacks, input controls, integrity checks, and use of cryptography; this can lead to hardened validation logic that stops SIP/trust-provider hijacking in some development or acquisition contexts, but the control is a requirements-gathering process that does not itself implement or enforce those protections across the OS or existing components.
T1553.004prevents — A.8.26 requires identification and specification of application security requirements (including trust in identities, protection of data in transit, use of cryptography per 8.24, and resilience against malicious attacks), which when applied during development or acquisition can prevent the introduction of applications that would accept or facilitate malicious root certificate installation; this is only a slice of the technique's full surface (e.g., post-compromise OS-level installation, supply-chain pre-installation, or non-application vectors).
T1553.006prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks, input validation, and cryptography) during development or acquisition; this can lead to applications that enforce code signing policies and resist tampering, but the control is a requirements process that does not itself implement or enforce those policies against the technique.
T1554prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks such as buffer overflows/SQL injections, input validation, integrity checks, and cryptography) when developing or acquiring applications, which can prevent some classes of binary modification during the build or procurement phase but does not stop post-deployment patching, replacement, or version-locking of existing host binaries.
T1555prevents — A.8.26 requires identification and specification of application security requirements (including authentication, segregation of access, protection of confidential data at rest/transit, input/output controls, and cryptography) that can stop credential stores from being implemented insecurely or from exposing credentials, but this is only a requirements process whose effect depends on what the developer actually builds and is silent on post-deployment search techniques against existing stores.
T1555.003prevents — A.8.26 requires identifying and specifying security requirements (including authentication, data classification, segregation of access, resilience against attacks, input/output controls, cryptography, and non-repudiation) when developing or acquiring applications such as web browsers; this can prevent the technique when those requirements drive hardened credential storage that blocks file/memory extraction, but the control only mandates the requirements process rather than any specific mechanism and does not reach already-deployed browsers.
T1555.004detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and error handling, which can surface anomalous credential access attempts in custom apps but does not mandate or implement detection of the technique itself (e.g. vaultcmd.exe, CredEnumerateA, or direct file reads against the OS Credential Manager).
T1555.004prevents — A.8.26 requires identification and specification of application security requirements (including authentication, segregation of access, resilience against malicious attacks, input/output controls, and cryptography) that, when applied during development or acquisition of apps using the Credential Manager, can prevent the technique from succeeding; this is only a slice because the control is a requirements-gathering process (not a concrete mechanism), does not reach non-application vectors such as direct file reads or password recovery tools on existing lockers, and the technique can still target the OS component itself.
T1555.005detects — A.8.26 requires identification and specification of application security requirements (including input controls, output controls, logging/monitoring interfaces, error handling, and resilience against attacks), which can lead to detection mechanisms being built into or around password manager applications; however, the control only mandates that such requirements be considered during development or acquisition rather than mandating any specific detection capability.
T1555.005prevents — A.8.26 mandates identifying and specifying security requirements (including authentication, resilience against attacks like injections, input/output controls, encryption, and non-repudiation) when developing or acquiring password manager applications, which can prevent classes of T1555.005 access such as memory scraping or brute-force on weak implementations; it does not cover all vectors (e.g., post-unlock memory extraction via separate exploitation or unaddressed master-password weaknesses).
T1555.006detects — A.8.26 requires identification and specification of application security requirements (including logging/monitoring interfaces, transaction logging, input controls, and resilience against attacks), which can lead to detection mechanisms for anomalous secret retrievals from cloud stores, but only as one optional slice of requirements rather than mandating detection itself.
T1555.006prevents — A.8.26 requires identification and specification of application security requirements (including authentication, access segregation, resilience against attacks, input/output controls, and cryptography) that can constrain the privilege paths and service behaviors leading to secret retrieval, but does not itself enforce those requirements or block the technique when privileges are already obtained.
T1556prevents — A.8.26 requires identifying and specifying security requirements (including authentication trust, segregation of access, resilience against attacks, input validation, and cryptography) during app development or acquisition, which can prevent vulnerable auth implementations that enable T1556; however, it is a requirements/governance control that does not itself implement or enforce the mechanisms, leaving most of the technique's post-deployment attack surface (e.g., on existing OS auth processes like LSASS/PAM) untouched.
T1556.003detects — A.8.26 requires identification and specification of application security requirements (including authentication trust, input validation, integrity checks, logging/monitoring interfaces, and resilience against malicious attacks), which surfaces the need for PAM integrity monitoring or anomaly detection in development/acquisition; this is a genuine but minority slice of the technique (PAM modification on Linux/macOS systems) rather than broad detection of in-place attacks.
T1556.003prevents — A.8.26 requires identifying and specifying security requirements (including authentication trust, segregation of access, resilience against malicious attacks, input validation, and cryptography) that, when followed in development or acquisition, would stop many PAM modifications or backdoors from being introduced; it does not reach runtime PAM tampering on existing systems or all implementation gaps.
T1556.005detects — A.8.26 requires identification and specification of application security requirements (including authentication, encryption, input controls, logging/monitoring, and non-repudiation) that can surface the risky reversible-encryption setting during development or acquisition risk assessments, but does not mandate ongoing detection of the technique in deployed environments.
T1556.005prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, password storage/protection, and resilience against attacks that could expose credentials), which when followed would block enabling reversible encryption in developed or acquired apps; it reaches only a slice because the technique can also be set post-deployment via AD policy or on non-application accounts outside the development/acquisition process.
T1556.006prevents — A.8.26 requires identification and specification of application security requirements including authentication trust levels, resilience against malicious attacks, input/output controls, and cryptography — which can explicitly require MFA mechanisms that, when built in, stop the adversary from disabling or modifying them; this is only a slice of the technique (application-layer MFA in dev/acquisition) rather than the bulk of post-compromise MFA modifications across identity providers, OS configs, or policies.
T1556.007detects — A.8.26 requires identification and specification of application security requirements (including authentication, input validation, logging/monitoring, non-repudiation, and interfaces to logging/monitoring or data leakage detection systems), which can lead to detection mechanisms for anomalous authentication behavior or backdoors in hybrid identity processes when those requirements are implemented.
T1556.007prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, segregation of access, resilience against malicious attacks, input/output controls, and non-repudiation) when developing or acquiring apps; this can address hybrid identity auth processes in development but does not stop post-deployment modification of running PTA/AD FS agents or cloud-side backdooring.
T1556.008detects — A.8.26 requires identification and specification of application security requirements (including authentication trust, input controls, logging/monitoring interfaces, and resilience against malicious attacks), which can lead to detection requirements for anomalous credential-manager behavior or registry changes, but the control itself only mandates requirements identification rather than any runtime detection mechanism.
T1556.008prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, credential handling, input controls, and resilience against malicious attacks) that would block registration of malicious network provider DLLs when those requirements are applied during development or acquisition of affected components.
T1556.009prevents — A.8.26 requires identification and specification of application security requirements including authentication, access segregation, resilience against attacks, input/output controls and non-repudiation; when followed these constrain or eliminate the policy configurations an adversary could later modify to achieve T1556.009, but the control is a requirements-gathering process whose effect depends on downstream implementation rigor and does not itself block the technique.
T1557prevents — A.8.26 requires applications to identify and address security requirements including authentication, encryption of communications, input/output controls, integrity mechanisms, and resilience against attacks (explicitly naming SQL injection and buffer overflows, with cryptography cross-referenced), which directly stops many AiTM enablers such as weak TLS negotiation, unencrypted transit, missing integrity checks, and credential interception in app-layer flows; it leaves untouched lower-layer protocol abuses (ARP, DNS, LLMNR) and non-application vectors, so the covered slice is genuine but not the bulk.
T1557.001prevents — A.8.26 requires applications to identify and address security requirements including authentication trust, segregation of access, resilience against malicious attacks (explicitly naming SQL injection and buffer overflows as examples), input validation, output controls, and cryptography — which can prevent name-resolution poisoning or relay by mandating secure protocols, disabling LLMNR/NBT-NS/mDNS, or requiring stronger authentication that blocks NTLM relay; this is a genuine but minority slice of the technique's network-level attack surface rather than the bulk.
T1558prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, segregation of access, resilience against attacks, input validation, and cryptography) that can constrain how applications handle Kerberos tickets and related auth flows, but the control is a requirements-gathering process rather than an enforcement mechanism and does not reach the dominant ticket-stealing/forging vectors on hosts or in the KDC itself.
T1558.002prevents — A.8.26 requires identification and specification of application security requirements (including authentication, segregation of access, resilience against attacks, input validation, and cryptography) that, when followed in development or acquisition, can stop the conditions enabling silver ticket forgery for application/service accounts, but this is only a slice of the technique's attack surface (e.g., non-application services, post-deployment credential theft via dumping/Kerberoasting).
T1558.004prevents — A.8.26 requires identification and specification of application security requirements (including authentication, encryption, input controls, and resilience against attacks) that, when applied during development or acquisition of relevant applications/services, can mandate Kerberos pre-authentication and stronger algorithms, thereby preventing the technique; this is only a slice because the control is a requirements process that does not itself enforce the setting on existing accounts or non-application components.
T1559.002detects — A.8.26 requires applications to identify and address security requirements including input controls/validation, output controls, transaction logging/monitoring, interfaces to logging/monitoring systems, and error handling; these can surface anomalous DDE usage or poisoned documents in developed/acquired apps but do not mandate runtime detection of the technique itself across the enterprise.
T1559.002prevents — A.8.26 requires identification and specification of application security requirements (including input controls, integrity checks, resilience against malicious attacks such as SQL injection, and output controls) that can be applied during development or acquisition to block DDE-based command execution vectors in documents and spreadsheets.
T1559.003prevents — A.8.26 requires identification and specification of application security requirements (including input validation, integrity checks, resilience against injections, segregation of access/privileges, and secure interfaces) that directly address the improper XPC client validation and poor input sanitization vectors named in the T1559.003 description; this constrains the technique at development time but does not guarantee complete or correct implementation of those requirements.
T1561recovers — A.8.26 requires identifying and specifying application security requirements including resilience, backup-related logging/monitoring, non-repudiation, and cryptography that can support post-wipe recovery mechanisms in developed or acquired applications, but does not itself perform recovery of wiped disk data or system state.
T1563detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, non-repudiation, interfaces to logging/monitoring systems, and error handling, which can surface session hijacking anomalies when those requirements are implemented in remote-service apps.
T1563prevents — A.8.26 requires identification and specification of application security requirements (including authentication, segregation of access, resilience against malicious attacks, input/output controls, and cryptography) that can constrain session hijacking vectors when baked into the design of the remote services themselves; this is a genuine but minority slice of the technique's surface (e.g., SSH/RDP session protections), not the bulk of hijacking methods.
T1563.001detects — A.8.26 requires identification and specification of application security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against malicious attacks, which can lead to detection mechanisms for anomalous SSH session behavior or hijacking attempts in developed/acquired apps, but this is indirect, scope-dependent on what the risk assessment chooses to require, and does not mandate runtime detection of the technique itself.
T1563.001prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, segregation of access, resilience against malicious attacks, input/output controls, and cryptography) that, when applied during SSH-related application development or acquisition, would prevent many but not all SSH hijacking vectors such as agent/socket compromise after initial session establishment.
T1563.002detects — A.8.26 requires identification and specification of application security requirements (including authentication, access segregation, resilience against attacks, input/output controls, transaction logging/monitoring, and interfaces to logging/monitoring or data leakage detection systems), which can lead to detection mechanisms for anomalous RDP session behavior in covered applications, but the control is limited to requirements identification during development/acquisition and does not mandate or implement runtime detection itself.
T1563.002prevents — A.8.26 requires identifying and specifying security requirements (including authentication, access segregation, resilience against attacks, and cryptography) when developing or acquiring applications; this can lead to RDP session protections that stop hijacking but is only a requirements process whose downstream implementation is not guaranteed, leaving a large remainder.
T1565detects — A.8.26 requires identification and specification of application security requirements including transaction logging/monitoring, input validation, integrity checks, output controls, error handling, and non-repudiation, which can surface data manipulation when those mechanisms are implemented and monitored.
T1565prevents — A.8.26 mandates identifying and specifying requirements (incl. input validation, integrity checks, output controls, non-repudiation, resilience against injections, and crypto for transit/rest) that directly block many forms of data manipulation when implemented; it is only partial because the control is a requirements-gathering process whose effect depends on downstream implementation rigor and does not itself enforce the mechanisms.
T1565.001detects — A.8.26 requires identification and specification of application security requirements including transaction logging/monitoring, non-repudiation, interfaces to logging/monitoring systems, and integrity mechanisms (e.g. hashing, signatures, input/output controls); these can surface stored data manipulation when the requirements are implemented in monitoring, but the control itself only mandates requirements identification rather than any detection mechanism or coverage of all stored data types.
T1565.001prevents — A.8.26 requires identification and specification of security requirements (including integrity protection of data at rest, input/output controls, non-repudiation, and cryptography per 8.24) that directly address stored-data manipulation when followed in development or acquisition; this constrains the technique for applications built under it but is a governance/requirements process whose effect depends on downstream implementation rigor and does not reach pre-existing or non-application data stores.
T1565.002detects — A.8.26 requires identification and specification of requirements including transaction logging/monitoring, non-repudiation, interfaces to logging/monitoring systems, integrity mechanisms (hashing, signatures), and error handling, which can surface evidence of transmitted-data manipulation once requirements are implemented.
T1565.002prevents — A.8.26 requires identification and specification of requirements that explicitly include integrity of transmitted data, non-repudiation, input/output controls, cryptographic protection, and resilience against manipulation attacks, which when implemented stop the technique from succeeding; this is only a slice because the control is a requirements-gathering process whose effect depends on downstream implementation rigor and does not itself enforce any mechanism.
T1565.003prevents — A.8.26 mandates identifying and specifying security requirements (including resilience against malicious attacks, input validation, integrity checks, output controls, segregation of access, and cryptography) that directly address runtime data manipulation when followed in development or acquisition.
T1566.002prevents — A.8.26 requires applications (incl. those handling email, web, or OAuth flows) to identify and address security requirements such as authentication, input validation, output controls, resilience against malicious attacks/injections, and cryptography; this can prevent some link-based delivery vectors (e.g., unsafe URL handling, consent phishing via weak OAuth, or browser exploits) when built into email clients, browsers, or apps, but leaves the social-engineering delivery, user execution, and non-application vectors untouched.
T1567detects — A.8.26 requires identification and specification of application security requirements including transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and output controls; this surfaces anomalous exfiltration over web services when those requirements are implemented in the application, but only for monitored applications and not the general technique.
T1567prevents — A.8.26 requires identifying and specifying security requirements (including encryption of communications, input/output controls, data protection in transit, and resilience against malicious attacks) that, when applied during development or acquisition, can prevent applications from enabling or facilitating exfiltration over web services; however, it only mandates the requirements process rather than enforcing specific mechanisms, leaving implementation-dependent gaps.
T1567.001detects — A.8.26 requires identification and specification of application security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and output controls, which can surface anomalous exfiltration to a code repo via monitored application behavior or API calls, but only for applications developed or acquired under this control and only where the implementer chooses to include those specific requirements.
T1567.001prevents — A.8.26 requires identification and specification of application security requirements (including data classification, access segregation, input/output controls, encryption of data in transit, and non-repudiation) that, when applied during development or acquisition, can block exfiltration paths to code repositories in custom or acquired apps; this is only a slice because the technique also applies to already-deployed third-party apps, misconfigurations, or non-application vectors outside the development process.
T1567.003detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and output controls; this surfaces anomalous exfiltration to text storage sites when the application itself is the source or when monitoring is built in, but does not broadly detect the technique across arbitrary apps or non-application vectors.
T1567.004detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring or data leakage detection systems, and output controls; this surfaces webhook exfiltration when the monitored application or SaaS service is in scope, but the control is silent on detection outside application development/acquisition and does not mandate coverage of adversary-owned webhook endpoints or non-application vectors.
T1567.004prevents — A.8.26 requires identification and specification of application security requirements (including input controls, output controls, data protection in transit/rest, encryption of communications, and resilience against malicious attacks) that, when applied during development or acquisition of the relevant applications/services, can stop webhook-based exfiltration paths from being introduced or left enabled; this is a genuine but minority slice of the technique (most webhook abuse vectors sit in already-deployed SaaS, configuration of third-party services, or post-development misuse rather than in the initial application requirements set).
T1570detects — A.8.26 requires applications to specify and address security requirements including transaction logging/monitoring, interfaces to logging/monitoring systems, and output/input controls; these can surface anomalous file transfers or tool staging when the monitored application or service is involved, but the control only sets requirements for development/acquisition and does not mandate detection coverage of native tools, protocols, or lateral movement outside application scope.
T1572detects — A.8.26 requires applications to identify and address security requirements including input/output controls, integrity checks, transaction logging/monitoring, interfaces to logging/monitoring systems, and resilience against attacks, which can surface protocol tunneling when it occurs through or is initiated by the monitored application (e.g. via anomalous traffic or DoH), but this is scoped only to application-level requirements rather than general network or system monitoring.
T1572prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks, input validation, output controls, encryption of communications, and use of cryptography per 8.24), which can prevent certain tunneling implementations (e.g., insecure custom apps or unencrypted tunnels) when those requirements are derived from risk assessment and enforced in development/acquisition; however, it does not address adversary tunneling of existing protocols on endpoints or network infrastructure outside the application's own development.
T1573.002prevents — A.8.26 requires identification and specification of application security requirements including use of cryptography (explicitly referencing 8.24), input validation, output controls, and resilience against attacks such as injections; this can lead to applications that do not employ or accept adversary asymmetric crypto for C2, but the control only mandates a requirements process whose implementation is not guaranteed and leaves many implementation slices (e.g. third-party libraries, misconfigurations) untouched.
T1574prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks such as buffer overflows/SQL injections, input validation, access segregation, and cryptography) when developing or acquiring applications, which can prevent many hijack vectors if those requirements are met during implementation.
T1574.001detects — A.8.26 requires applications to identify and address security requirements including resilience against malicious attacks, input validation, output controls, logging/monitoring interfaces, and error handling; these can surface anomalous DLL loading or related behaviors in custom-developed/acquired apps but do not mandate runtime detection of the technique itself and leave most Windows-platform DLL abuse (e.g. in third-party binaries) unreached.
T1574.001prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, segregation of access, and secure development practices), which can address some root causes of DLL sideloading/hijacking if requirements explicitly cover safe DLL loading, search-order hardening, or code signing; however, it is a requirements-setting process rather than an enforcement mechanism, leaves many implementation-specific vectors (e.g., phantom hijacking, remote shares, substitution) unaddressed, and does not reach runtime or OS-level behaviors.
T1574.004prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks, input controls, and output controls) that can address dylib search-order weaknesses at development time; this prevents the technique in applications built under it, but the control is a requirements process whose coverage depends on what the developer actually specifies and implements.
T1574.005prevents — A.8.26 requires that application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, access segregation, and secure development practices) be identified and addressed during development or acquisition of applications, which would prevent many installer permission weaknesses if applied to the installers themselves; however, the control is a requirements-setting process that does not guarantee complete or correct implementation across all installers (including third-party or legacy ones), leaving a genuine minority slice unaddressed.
T1574.006prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, and protections for data in processing/transit/rest), which can address dynamic linker hijacking when applications are developed or acquired to avoid unsafe environment variable usage or library loading; however, this is a governance/risk-assessment process that does not mandate or enforce specific mechanisms, leaving most implementation details and runtime configurations to the developer.
T1574.008prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks, input controls, and secure development practices that can address path vulnerabilities via full paths or validation), which can prevent the insecure coding pattern that enables T1574.008; it is only partial because the control is a requirements-setting process whose effect depends on what the implementer actually chooses to specify and enforce.
T1574.009prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input controls, and output controls) that, when applied during development or acquisition, would include mandating quoted paths or equivalent safe resolution to stop unquoted-path hijacking in the resulting application or service.
T1574.010prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks, input/output controls, segregation of access, and protection of data in transit/at rest) that, when applied during development or acquisition, would address improper file permissions for service binaries as a named slice of the weakness, but the control is a requirements-setting process whose effect depends on what the implementer actually chooses to specify and enforce.
T1574.011prevents — A.8.26 requires that application security requirements (identified via risk assessment) include resilience against malicious attacks such as buffer overflows or SQL injections, plus input validation, access segregation, and related controls; this can address insecure Registry permission flaws during custom application or service development/acquisition, but leaves a large remainder for OS-level services, third-party components, configuration drift, and non-application contexts where the weakness arises.
T1574.012detects — A.8.26 requires applications to identify and address security requirements including resilience against malicious attacks, input controls/validation, logging/monitoring interfaces, and error handling; these can surface anomalous profiler-driven behavior or registry tampering in .NET apps, but the control only mandates requirements identification rather than mandating runtime detection mechanisms across all .NET processes or non-application scopes.
T1574.012prevents — A.8.26 requires that application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, and other controls) be identified and addressed during development or acquisition of applications; this can prevent abuse of COR_PROFILER in custom .NET applications but does not constrain the technique in third-party or already-deployed .NET processes.
T1574.014detects — A.8.26 requires identifying and addressing security requirements (including input controls, integrity checks, resilience against malicious attacks, logging/monitoring interfaces, and error handling) that can surface anomalous .NET assembly loading or tampering behaviors when implemented in application design and testing, but does not mandate or perform detection itself and leaves most runtime hijacking outside its scope.
T1574.014prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input controls, integrity, and segregation of access) that can be used to address AppDomainManager hijacking during development or acquisition of .NET applications, but does not mandate or enforce any specific mechanism that stops the technique.
T1587.004prevents — A.8.26 mandates identifying and specifying security requirements (including resilience against buffer overflows, SQL injection, input validation, output controls, and cryptography) during application development or acquisition, which directly constrains the class of bugs/vulnerabilities that an adversary could discover via fuzzing/patch analysis and weaponize into custom exploits.
T1588.005prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections) during application development or acquisition, which prevents many exploitable bugs from being introduced and thereby stops adversaries from obtaining usable exploits for those applications; this is only a slice of the technique because it does not constrain buying, stealing, or downloading exploits for third-party or pre-existing vulnerabilities.
T1589.001prevents — A.8.26 requires identification and specification of application security requirements (including authentication, MFA, input validation, output controls, secure storage/transit of credentials, and non-repudiation) that directly block several collection vectors such as credential-storing apps, insecure login forms, and exposed logs/repos; this is only a slice of the technique, which also covers phishing, dark-web purchases, and breaches of non-application data.
T1600.001prevents — A.8.26 requires identification and specification of application security requirements including use of cryptography (explicitly referencing 8.24), protection of data in transit, and resilience against malicious attacks; this constrains the design and acquisition of applications so that weak ciphers/key sizes are not introduced, but does not stop post-compromise modification of already-deployed network device images or configurations.
T1606prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, input validation, output controls, cryptography use, and resilience against malicious attacks) that, when followed in development/acquisition, stop forged web credentials from being generatable or usable in those applications; this covers a genuine but minority slice of the technique (e.g., custom apps vs. abusing cloud APIs or stealing seeds).
T1606.001prevents — A.8.26 requires identification and specification of application security requirements (including authentication trust, input/output controls, cryptography use per 8.24, and resilience against malicious attacks), which when applied during development can prevent cookie-forging vectors by mandating secure session mechanisms; this is only a slice because the control is a requirements-gathering process whose effect depends on what the implementer actually selects and enforces.
T1606.002prevents — A.8.26 requires identifying and specifying application security requirements (including authentication trust, resilience against malicious attacks, input/output controls, cryptography use per 8.24, and non-repudiation) that, when followed in development or acquisition, would block the certificate compromise or improper token-signing logic enabling SAML forgery; this is only a slice because the control is a requirements-gathering process whose effect depends on what the risk assessment actually selects and the implementer actually builds.
T1608.004prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as SQL injection, input validation, output controls, and cryptography) when developing or acquiring applications; this can prevent some classes of drive-by staging content (e.g. exploitable flaws in an org's own web apps or sites) but does not constrain adversary-controlled infrastructure, acquired domains, or injected content on third-party sites that are the dominant slice of T1608.004.
T1608.005prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as SQL injection, input validation, output controls, cryptography, and non-repudiation) when developing or acquiring applications; this can prevent some classes of link targets (e.g. cloned phishing pages or malicious hosted apps) from being introduced in in-house or acquired software, but the control is silent on adversary-controlled external infrastructure, domains, IPFS, or link-shortening services used in PRE.
T1611detects — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks, input validation, output controls, logging/monitoring interfaces, and error handling) that can surface container escape vectors during development or acquisition; this is genuine but only a slice, as the control stops at requirements identification and does not mandate runtime monitoring or anomaly detection mechanisms.
T1611prevents — A.8.26 requires that application/container security requirements (including resilience against malicious attacks, segregation of access, input controls, and protection of data in processing/transit/rest) be identified via risk assessment and addressed in development or acquisition, which can prevent many classes of container escape (e.g. via bind mounts, privileged containers, weak input validation, or missing isolation) when those requirements are translated into secure configuration and code; it does not itself enforce runtime isolation, kernel hardening, or vulnerability patching that close all escape vectors.
T1620detects — A.8.26 requires applications to identify and address security requirements including resilience against malicious attacks, input validation, output controls, logging/monitoring interfaces, and error handling; these can surface reflective loading when it triggers observable anomalies in a developed/acquired application, but the control only sets requirements rather than mandating any specific detection mechanism or coverage depth.
T1620prevents — A.8.26 requires identifying and specifying application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, and secure development practices), which can lead to design/implementation choices that stop reflective code loading techniques from being introduced in custom applications; this is only a slice because the control is a requirements-gathering process (not an enforcement mechanism), does not address third-party or already-deployed code, and the technique can still be used by adversaries against legitimate processes at runtime.
T1621detects — A.8.26 requires identification and specification of application security requirements including authentication trust levels, input controls, transaction logging/monitoring, non-repudiation, and interfaces to logging/monitoring systems, which can surface anomalous MFA request patterns or fatigue indicators in transactional/electronic apps but does not mandate runtime detection mechanisms.
T1621prevents — A.8.26 requires identification and specification of application security requirements including authentication trust levels, resilience against malicious attacks, input controls, and non-repudiation (explicitly referencing 8.5 and 5.17), which when applied during development can prevent MFA request generation abuse and fatigue vectors in custom apps or auth flows; it is only a partial slice because the control is a requirements-gathering process whose effect depends on downstream implementation rigor and does not itself block the technique at runtime.
T1648prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, access segregation, authentication, and cryptography) when developing or acquiring applications; this can prevent some serverless abuse vectors (e.g. weak functions or event triggers) if applied to custom/serverless app development, but leaves the bulk of the technique (abusing provider-managed services, permissions like IAM:PassRole, or office-suite automations) untouched.
T1649detects — A.8.26 requires identifying and specifying security requirements (including authentication trust, integrity mechanisms, logging/monitoring interfaces, and cryptography) that can drive detection capabilities for certificate misuse, but the control itself only mandates requirements identification rather than any runtime detection mechanism.
T1649prevents — A.8.26 requires identifying and specifying security requirements (including authentication trust levels, certificate management via cryptography per 8.24, input/output controls, and secure processing of credentials) during app development or acquisition, which can stop certificate-related weaknesses from being introduced in those apps but does not constrain the broader technique of stealing or forging certificates from existing stores, CAs, or misconfigurations elsewhere.
T1657detects — A.8.26 requires identifying and specifying application requirements (including input validation, output controls, transaction logging/monitoring, non-repudiation, interfaces to logging/monitoring systems, and error handling) that surface anomalous or fraudulent financial activity in transactional/ordering/payment apps; this detects a slice of T1657 techniques (e.g. unauthorized transfers or BEC fraud) but leaves the bulk (ransomware extortion, social engineering outside apps, cryptocurrency exploits, and non-application vectors) unreached.
T1657prevents — A.8.26 mandates identifying and specifying security requirements (including authentication, access segregation, input/output controls, integrity mechanisms, non-repudiation, transaction logging, and cryptography) that directly block common financial-theft vectors such as unauthorized transfers, BEC/social engineering success, and weak transactional apps; this is a genuine but minority slice because the control only sets requirements for development/acquisition and does not itself stop post-compromise extortion, ransomware demands, or already-compromised accounts.
T1659detects — A.8.26 requires identification of application security requirements including input controls, integrity checks, input validation, output controls, transaction logging/monitoring, non-repudiation, and interfaces to logging/monitoring or data leakage detection systems; these can surface anomalous injected content or traffic in application-layer flows but do not broadly instrument or detect upstream ISP-level channel compromises or MITM-style injection before it reaches the application.
T1659prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks, input validation, output controls, encryption of communications, and integrity mechanisms) that would block many forms of content injection when followed in development/acquisition; however, it only sets requirements rather than mandating mechanisms, leaves upstream/ISP-level channel compromises outside its scope, and does not guarantee complete enforcement.
T1671prevents — A.8.26 requires identification and specification of application security requirements (including authentication, segregation of access, resilience against malicious attacks, input/output controls, and non-repudiation) that, when applied during development or acquisition, would block many vectors for malicious OAuth integrations such as weak consent flows, over-privileged service principals, and insufficient token controls; it does not reach the full technique because the control is a requirements-gathering process whose effect depends on downstream implementation rigor and does not constrain post-deployment consent or co-opting of existing integrations.
T1674prevents — A.8.26 requires identifying and specifying application security requirements including input controls, input validation, resilience against malicious attacks (explicitly naming SQL injection and buffer overflows as examples), output controls, and related protections that can stop simulated-keystroke or injected-input techniques from succeeding when they target the application itself.
T1677detects — A.8.26 requires identifying and specifying application security requirements (including input validation, integrity checks, logging/monitoring interfaces, and resilience against malicious attacks such as injections), which can surface poisoned pipeline scenarios when those requirements drive monitoring or testing of the CI/CD build process itself; however the clause stops at requirement-setting and does not itself perform or mandate detection.
T1677prevents — A.8.26 requires identifying and specifying security requirements (including resilience against malicious attacks such as injections, input validation, integrity checks, and secure development practices) for applications including those in CI/CD pipelines; this can prevent many poisoning vectors when followed but does not guarantee enforcement or cover all scenarios such as public PR triggers or self-hosted runners.
T1684detects — A.8.26 requires applications to specify and implement requirements such as transaction logging/monitoring, non-repudiation, input validation, error handling, and interfaces to logging/monitoring or data leakage detection systems, which can surface social engineering attempts (e.g. via anomalous requests, phishing payloads in inputs, or consent flows) when they interact with the application; this is a genuine but minority slice of the broad, multi-channel, human-focused technique.
T1684prevents — A.8.26 requires identifying and specifying security requirements (including authentication, access segregation, input validation, output controls, non-repudiation, transaction logging/monitoring, and resilience against malicious attacks) that, when implemented in developed or acquired applications, constrain or block many social-engineering-induced user actions such as unauthorized approvals, disclosures, or payload execution.
T1684.001detects — A.8.26 requires applications to identify and address security requirements including transaction logging/monitoring, non-repudiation, interfaces to logging/monitoring systems, and error-message handling; these can surface impersonation attempts (e.g. via anomalous transaction patterns, failed non-repudiation checks, or suspicious messaging), but only for application-mediated interactions and only where the implementer elects to include those specific requirements.
T1684.001prevents — A.8.26 requires applications to identify and address security requirements including authentication, trust in claimed identities, non-repudiation, input/output controls, and transaction integrity mechanisms (e.g. digital signatures), which can prevent impersonation techniques that rely on spoofed trust in app-mediated communications or transactions, but leaves the bulk of social-engineering, email, and pre-recon aspects of T1684.001 untouched.
T1684.002prevents — A.8.26 requires identification and specification of application security requirements (including authentication, trust in claimed identities, input validation, output controls, non-repudiation, and cryptography per 8.24/5.17/8.5) when developing or acquiring apps; this can prevent spoofing-vulnerable email apps or transactional services if requirements mandate proper DMARC/SPF/DKIM enforcement, but the control only sets a requirements process and does not itself enforce, implement, or apply those mechanisms universally across environments.
T1685.002prevents — A.8.26 requires that application security requirements (including logging, monitoring, non-repudiation, and interfaces to logging systems) be identified and addressed during development or acquisition of cloud apps, which can prevent some forms of the technique (e.g. by baking in immutable logging) but leaves the bulk of post-deployment admin-permission tampering untouched.
T1685.005detects — A.8.26 requires identification and specification of application security requirements including transaction logging, monitoring, interfaces to logging/monitoring systems, and error handling; this surfaces the need to detect log-clearing attempts in monitored applications, but the control only sets requirements rather than mandating detection mechanisms and does not address non-application Windows event log clearing.
T1687prevents — A.8.26 requires identification and specification of application security requirements (including resilience against malicious attacks such as buffer overflows or SQL injections, input validation, output controls, and cryptography) that, when followed in development or acquisition, stop many exploitable programming errors in defensive components from being introduced.
T1689prevents — A.8.26 requires identifying and specifying security requirements (including resilience against attacks, input validation, cryptography use, secure protocols, and non-repudiation) during app development/acquisition, which can block many downgrade vectors if enforced in the resulting software but leaves residual cases (e.g. OS/bootloader downgrades, legacy protocol fallbacks outside the app, or incomplete implementation of the requirements).

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

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

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

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

Why these map — AI rationale (under review)

A01mitigates — A.8.26 requires identifying and specifying requirements for segregation of access, levels of access to data/functions, authorization processes, and related controls that can bound the impact or realization of broken access control when those requirements are later implemented; this is not prevention of the class itself.
A01prevents — A.8.26 requires identifying and specifying access-related requirements (segregation of access, levels of access to data/functions, authorization processes) that directly target the authorization-decision slice of A01; this is genuine but bounded, as the control does not address path traversal, CSRF, IDOR implementation flaws, or missing function-level checks once requirements are set.
A02mitigates — A.8.26 requires identifying and specifying security requirements (including input validation, access segregation, output controls, encryption, resilience against injections, and secure defaults for transactional/payment apps) that, when followed, reduce the realized impact or attack surface of a misconfiguration without eliminating the underlying configuration weakness itself.
A02prevents — A.8.26 mandates identifying and specifying security requirements (including input validation, access segregation, resilience against injections/buffer overflows, output controls, encryption, and secure defaults for transactional/payment apps) that directly target many misconfiguration vectors when followed in development/acquisition; however, it is a requirements-gathering process whose effect depends on later implementation rigor, leaving residual gaps in runtime hardening, cloud settings, and incomplete enforcement.
A04mitigates — A.8.26 requires identifying/addressing crypto-related requirements (e.g. encryption of data in transit/at rest, secure comms, integrity mechanisms) which bounds the blast radius or impact of realized crypto failures without removing the underlying weakness
A04prevents — A.8.26 explicitly requires identifying and specifying requirements for encryption, protection of data in transit/at rest, input validation against injection, and use of cryptography where applicable, which directly prevents many (but not all) cryptographic failures when followed in development.
A05mitigates — A.8.26 requires identifying/addressing requirements that include resilience against injections (explicitly names SQL injection and buffer overflow) plus input validation, output controls, and cryptography; this bounds the realized consequence of an injection that has already succeeded, but does not itself neutralize data or close the boundary-crossing defect.
A05prevents — A.8.26 explicitly lists identifying requirements for resilience against SQL injections, input validation, output controls, and related protections derived from risk assessment, which directly prevents injection flaws when those requirements are met; however, it only sets requirements rather than enforcing their implementation, leaving a substantial remainder of the broad A05 class (e.g., many template, LDAP, and command-injection variants) unaddressed.
A06mitigates — A.8.26 requires identifying and specifying many design-level security requirements (auth, access segregation, input validation, output controls, resilience against injections/buffer overflows, crypto use, non-repudiation, etc.) that directly address common insecure-design flaws; however, it is only a requirements-gathering process whose effect on the final architecture depends on later implementation and verification steps, leaving a bounded remainder of design weaknesses that can still be baked in.
A06prevents — A.8.26 mandates identifying and specifying security requirements (including resilience against SQLi/buffer overflows, input validation, access segregation, crypto use, and other design-level protections) that directly address many root causes of insecure design when followed; however, it is a process of requirements identification rather than a guarantee that the resulting design will be free of all architectural weaknesses.
A07mitigates — A.8.26 requires identifying and specifying authentication-related requirements (trust in identity, segregation of access, input controls, non-repudiation, etc.) that can reduce the impact or likelihood of realized authentication failures when followed, but does not itself enforce, implement, or bound the consequences of any specific failure mode.
A07prevents — A.8.26 mandates identification and specification of application security requirements (including authentication, identity trust, access segregation, input validation, and resilience against attacks), which when followed prevents many classes of authentication failures; however, it is a requirements-setting/governance control whose effect depends on downstream implementation rigor, leaving residual defects possible.
A08mitigates — A.8.26 requires identifying/addressing integrity requirements (e.g. input validation, output controls, hashing, digital signatures, non-repudiation, transaction logging) that bound the blast radius or consequence of realized integrity failures such as insecure deserialization or unsigned updates, but does not itself enforce those mechanisms or limit impact of CI/CD compromise.
A08prevents — A.8.26 requires identifying and specifying integrity-related requirements (e.g. input validation, output controls, integrity checks, non-repudiation, hashing/digital signatures, secure storage outside public environments) that directly target many software/data integrity failures when followed in development or acquisition.
A09mitigates — A.8.26 requires logging/monitoring/non-repudiation requirements (n,o) and error handling (p) to be identified and addressed in app development, which bounds the realized impact of missing alerts or unprotected logs without preventing the logging failure itself.
A10mitigates — A.8.26 requires identifying and specifying requirements for error message handling, input validation, resilience against attacks, output controls, and related topics that can bound the consequences of mishandled exceptions (e.g., avoiding information leaks or inconsistent states), but it only sets requirements rather than directly implementing or enforcing the mitigations.
A10prevents — A.8.26 explicitly lists error message handling, input validation, resilience against attacks (incl. SQLi and buffer overflows), and several integrity/non-repudiation requirements that directly block classes of exceptional-condition weaknesses before they are coded; the control is a requirements-gathering process rather than an implementation mandate, so coverage is a genuine but incomplete slice of the broad A10 category.

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.