A.8.31 Technological
Separation of development, test and production environments
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
Mapped NIST 800-53 r5 controls (16)
Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- AC-3mostlyaligns with — Both controls enforce access restrictions that prevent a single individual from modifying both development and production environments without review or approval.
- CM-2mostlyaligns with — Both controls require distinct, controlled environments for development, testing, and production to prevent unauthorized or untested changes from reaching operational systems.
- CM-4mostlyaligns with — The ISO requirement to test changes in a separate staging environment before production deployment directly supports the NIST objective of analyzing the security impact of changes prior to implementation.
- AC-6partialaligns with — The ISO guidance to restrict compilers, editors, and utilities from production systems and to segregate access rights implements the principle of least privilege across environment boundaries.
- AU-2partialaligns with — The ISO mandate for detailed logging and real-time monitoring when a single person can access both development and production supports the generation of audit records for security-relevant events.
- CM-3partialaligns with — Documented rules and authorization for moving software from development to production align with the NIST requirement for formal configuration change control procedures.
- 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.
- AC-6covers — 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.
- CM-2covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- CM-4covers — 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 (17)
NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- PR.AA-05mostlyaligns with — By requiring segregation of access rights and prohibiting a single person from modifying both development and production without review, the control implements policy-driven access permissions and authorizations across environments.
- PR.IR-01mostlyaligns with — The control enforces logical separation of development, test, and production environments to prevent unauthorized access and changes, directly supporting the CSF outcome of protecting networks and environments from unauthorized logical access.
- PR.PS-01mostlyaligns with — The control mandates secure configuration, patching, and change monitoring of development, test, and production systems, aligning with the CSF outcome of establishing and applying configuration management practices.
- ID.AM-08partialaligns with — By defining distinct life-cycle stages for systems and requiring controlled transitions between development, test, and production, the control supports managing assets throughout their life cycles.
- PR.PS-04partialaligns with — The control requires secure monitoring and detailed logging of changes in development and production environments, which contributes to generating log records for continuous monitoring.
- ID.AM-08implements — 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.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.
- PR.PS-04implements — 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 (10)
Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- V13.2.4mostlycovers — Requiring explicit rules and authorization for moving code between development and production implements the same objective as maintaining an allow-list of permitted external or cross-environment resources.
- V13.2.3partialaligns with — The ISO requirement that a single person must not unilaterally change both development and production environments directly supports the ASVS rule that service credentials must not be default or shared across environments.
- V13.4.2partialaligns with — Mandating that development and test tools are inaccessible from production systems aligns with the ASVS control that debug modes must be disabled in production to avoid unintended exposure.
- V15.2.3partialaligns with — The ISO directive to keep development and test environments separate from production mirrors the ASVS requirement that production must contain only the functionality needed for live operation.
- V8.3.1partialaligns with — Enforcing deployment rules and authorization at the boundary between development and production environments corresponds to the ASVS expectation that authorization decisions are enforced at a trusted service layer rather than by untrusted clients.
Related weaknesses / CWE (25)
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).
Why these map — AI rationale (under review)
- CWE-1125noneprevents — Environment separation reduces risk from development artifacts but does not address production attack surface size.
- CWE-344noneprevents — Separation of environments highlights the need for different configurations, indirectly mitigating the weakness.
- CWE-11mitigates — Separation of environments reduces the chance that debug builds reach production but does not address the configuration weakness itself.
- CWE-114mitigates — Environment separation reduces risk of cross-contamination but does not directly address untrusted code execution.
- CWE-1269mitigates — Separation of development, test and production environments prevents accidental promotion of non-release configurations.
- CWE-1291prevents — Separation of development/test and production environments extends to cryptographic material, preventing shared signing keys.
- CWE-1295mitigates — Separation of environments reduces risk of debug exposure in production but does not address the weakness itself.
- CWE-200prevents — Prohibiting the copy of sensitive data into less-protected development and test environments lowers the likelihood that production secrets will be exposed through weaker controls in those environments.
- CWE-215prevents — Separation of environments reduces accidental exposure of debug builds to production.
- CWE-250mitigates — Segregating environments and limiting tool availability in production stops developers from retaining unnecessary elevated privileges once code moves into the live system.
- CWE-284mitigates — Requiring distinct domains, access rules, and approval gates between development and production environments directly blocks unauthorized actors from reaching production resources they should never touch.
- CWE-489prevents — Separation of environments reduces risk of debug code reaching production but does not directly address its removal.
- CWE-527mitigates — Segregating development, test and production environments reduces the chance that repositories are placed in publicly accessible locations.
- CWE-531mitigates — Separation of dev/test/prod environments limits exposure of test code containing secrets.
- CWE-540mitigates — Environment separation reduces risk of accidental exposure but does not address secrets already in code.
- CWE-553prevents — Environment separation limits the blast radius but does not stop the shell from existing in the production web root.
- CWE-653prevents — Separation of development, test and production environments is a direct application of compartmentalization.
- CWE-669prevents — Environment separation limits unintended resource leakage between spheres.
- CWE-732mitigates — Mandating secure configuration and access control for development and test systems reduces the chance that overly permissive file or resource permissions will be inherited by production.
Mitigated MITRE ATT&CK techniques (365)
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).
Why these map — AI rationale (under review)
- T1003.003prevents — A.8.31's separation of dev/test/prod environments, rules on deployment, non-production testing, restricted dev tools in prod, and access segregation directly block several listed T1003.003 methods (e.g. ntdsutil.exe, Invoke-NinjaCopy, or dev-driven Volume Shadow Copy) from running against production DCs, but leave other vectors (e.g. direct admin access or prod backups) untouched.
- T1003.006detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test/prod environments (with real-time monitoring and detailed logging in exceptional cases), which can surface anomalous DCSync replication behavior when it touches monitored production or dev/test systems, but this is scoped only to environment-change detection rather than comprehensive technique coverage.
- T1021prevents — A.8.31's separation of dev/test/prod environments (including distinct domains, access rules for deployment, no dev tools on prod, and segregated rights with monitoring) directly constrains domain-credential abuse and remote login paths that cross environment boundaries, but leaves intra-prod remote service usage and non-environment-specific lateral movement untouched.
- T1037.003detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which can surface anomalous logon-script modifications or deployments as part of change detection, but this is scoped only to dev/test/prod separation rather than broadly detecting the T1037.003 technique at runtime or in production logon initialization.
- T1037.003prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, prohibition on testing in prod, and access segregation directly block an adversary from using dev/test access or deployment paths to plant a malicious network logon script (T1037.003) into production GPOs or AD, but do not address an already-privileged admin directly modifying production logon scripts without traversing the separated pipeline.
- T1037.004detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring in some cases), which can surface unauthorized modifications to RC scripts in dev/test or approved production deployment paths, but does not broadly instrument or detect the technique when performed directly in production environments outside those controls.
- T1037.004prevents — A.8.31's separation of dev/test from production (including access rules, no dev tools in prod, change review, and environment monitoring) stops an adversary from reaching and modifying RC scripts in the production boot environment from a dev/test context, but leaves direct production compromise paths (e.g. via existing prod access or non-dev vectors) untouched.
- T1047detects — A.8.31 requires monitoring of changes to the development/test environments and code plus secure monitoring of those environments (and real-time monitoring on elevated-privilege paths), which can surface anomalous WMI use originating from dev/test activity before it reaches production, but the control is silent on production-environment monitoring of WMI abuse and does not require detection of the technique itself.
- T1053detects — A.8.31 requires monitoring of changes to the environment and code, plus secure monitoring and real-time monitoring for unauthorized changes, which can surface abuse of task scheduling in dev/test environments but does not broadly instrument production task schedulers or remote scheduling.
- T1053prevents — A.8.31's separation of dev/test/prod environments (including access rules, no dev tools in prod, change testing outside prod, and monitored segregation of duties) stops adversaries from using dev/test systems to schedule tasks that reach or compromise production, but leaves the technique fully available inside each environment and on production systems themselves.
- T1053.003detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging in some cases), which surfaces anomalous or unauthorized cron job creation/usage in dev/test/production separation; this is a genuine but minority slice of the technique's full surface across all platforms and persistence scenarios.
- T1053.005detects — A.8.31 explicitly requires secure monitoring and monitoring of changes to the development/test/production environments and code, which surfaces anomalous scheduled-task creation especially when crossing environment boundaries or using elevated rights, but does not address the bulk of in-production hidden-task or direct schtasks abuse on end-user systems.
- T1053.006detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which surfaces anomalous systemd timer or .service file creation/alteration in dev/test or production, but does not mandate detection of the runtime execution or remote activation of the timer itself.
- T1053.006prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, access controls, and prohibition on dev tools in production directly blocks many paths for introducing or activating malicious systemd timers from dev/test activities, but leaves open user-level timers, direct privileged writes in production, and non-dev-originated abuse.
- T1053.007detects — A.8.31 explicitly requires monitoring of changes to the environment and code, plus secure monitoring of development/test environments and real-time monitoring for unauthorized changes; this surfaces malicious container-orchestration job scheduling when it touches monitored dev/test or crosses the prod boundary, but leaves production-only scheduling outside the control's explicit scope.
- T1053.007prevents — A.8.31's separation of dev/test/prod environments (including rules for deployment, no dev tools in prod, access controls, and change monitoring) directly constrains an adversary's ability to create or schedule malicious orchestration jobs from a development context, but leaves open production-side abuse vectors such as direct cluster access or compromised admin credentials.
- T1055.003detects — A.8.31 requires secure monitoring and change monitoring of development/test environments plus real-time monitoring for unauthorized changes in exceptional cases; this can surface anomalous process/thread behavior tied to hijacking performed from or against dev/test tools, but the control's scope is limited to those segregated environments and does not broadly instrument production process injection.
- T1055.008detects — A.8.31 requires secure monitoring and change monitoring of development/test environments plus real-time monitoring for unauthorized cross-environment changes, which can surface ptrace-based injection attempts originating from dev/test tooling or processes, but this is scoped only to those environments and does not broadly instrument production process tracing or runtime behavior.
- T1055.009detects — A.8.31 requires secure monitoring and change monitoring of development/test environments plus real-time monitoring for unauthorized cross-environment changes; this can surface anomalous process/memory activity tied to injection attempts originating from dev/test, but the control's scope is limited to environment separation and does not broadly instrument production process injection via /proc.
- T1055.013detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments; this can surface anomalous development/test activity that produces or stages a doppelganging artifact, but the technique itself runs in production against live processes and is not required to touch the separated dev/test environments.
- T1059prevents — A.8.31's separation of environments, rules on deployment, prohibition of dev tools in production, and access segregation directly stop an adversary from using interpreters in production via dev/test compromise paths or unauthorized cross-environment execution, but this leaves the bulk of T1059 (abuse of built-in interpreters already present and accessible in production) untouched.
- T1059.004prevents — A.8.31's separation of dev/test/prod environments, rules on deployment, prohibition on dev tools in production, and access segregation directly stop an adversary from reaching and abusing Unix shells in production via dev/test compromise paths, but this leaves many other vectors (lateral movement, C2, persistence scripts on already-compromised production systems) untouched.
- T1059.006prevents — A.8.31's separation of dev/test/prod (including no dev tools in prod, no sensitive data copied to dev/test without equivalent controls, and rules for deployment) stops adversaries from using Python in dev/test environments to reach or compromise production systems, but leaves the technique fully executable in production, on endpoints, or in dev/test environments themselves.
- T1059.007detects — A.8.31 requires secure monitoring and change monitoring of dev/test environments (plus real-time monitoring for exceptional elevated-access cases), which can surface anomalous JavaScript execution or deployment inside those separated environments; this is a genuine but minority slice of the technique's surface (most T1059.007 abuse occurs in production user/browser/automation contexts outside dev/test separation).
- T1059.008detects — A.8.31 requires secure monitoring and monitoring of changes to the development/test environments and code (plus real-time monitoring in exceptional cases), which can surface anomalous CLI use or unauthorized changes on those network devices, but does not address production network devices or the technique in general.
- T1059.012prevents — A.8.31 requires separation of dev/test from production (including distinct domains, access rules, no dev tools in prod, and monitored change), which can prevent an adversary from reaching and abusing a hypervisor CLI in the production ESXi environment from a compromised dev/test context; this is only a slice of the technique because the control does not address direct abuse by a production-level admin or via other vectors.
- T1059.013detects — A.8.31 explicitly requires secure monitoring of the development/test environments plus monitoring of changes to the environment and code stored therein, which surfaces anomalous CLI/API usage inside those separated containerized environments; production is excluded by design so the coverage is a deliberate slice rather than the bulk of the technique.
- T1059.013prevents — A.8.31's separation of dev/test/prod environments (including access rules, no dev tools in prod, and protected dev/test configs) stops adversaries from using dev/test container CLIs/APIs to reach and abuse production ones, but leaves the technique fully available inside any single environment.
- T1072detects — A.8.31 requires monitoring of changes to the environment and code, plus secure monitoring of the environments and real-time monitoring for unauthorized changes in exceptional cases; this surfaces abuse of deployment tools in dev/test pipelines or production transitions but does not broadly instrument or detect the technique across all enterprise deployment tools, SaaS, or network devices referenced in T1072.
- T1072prevents — A.8.31's separation of dev/test/prod environments (including deployment rules, no dev tools in prod, and access segregation) directly constrains abuse of deployment tools integrated into CI/CD pipelines or used to push from dev to prod, but leaves untouched standalone enterprise deployment suites (SCCM, Intune, etc.) already resident in production domains.
- T1078prevents — A.8.31's separation of dev/test/prod environments (including access rules, no shared tools, segregated rights, and monitoring for unauthorized cross-environment changes) directly constrains an adversary's ability to abuse valid accounts for pivoting or escalation between those environments, but leaves the core technique (obtaining and abusing credentials within a single environment or via unrelated vectors) untouched.
- T1080detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which would surface unauthorized tainting of shared content in dev/test/production separation (especially code repos), but this is scoped only to those controlled environments rather than all shared storage or lateral-movement vectors on the technique's full platform set.
- T1080prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, prohibition on testing in prod, and controls on dev/test access and monitoring directly block tainting of production shared storage or code repositories from dev/test activities, but leave open tainting vectors that do not cross the environment boundary (e.g. direct compromise of a prod share or repository).
- T1098detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring plus real-time monitoring (with logging) of any cross-environment changes by a single person; this surfaces some account manipulation (esp. permission or credential changes crossing dev/test/prod) but does not broadly instrument or surface the technique across all its platforms and vectors.
- T1098prevents — A.8.31's separation of environments, rules for deployment, access segregation, and monitoring of changes directly block many forms of account manipulation (e.g. unauthorized credential/permission changes crossing dev/test/prod boundaries), but the control does not address manipulation performed entirely within a production environment or by already-privileged actors inside it.
- T1098.003detects — A.8.31 explicitly requires monitoring of changes to the environment and code, plus secure monitoring and real-time monitoring for unauthorized changes, which surfaces the addition of cloud roles/permissions when it occurs inside a monitored dev/test/production separation boundary; this is a genuine but minority slice of the technique (most instances occur directly in production IAM without crossing an env-separation boundary).
- T1098.004detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging in exceptional cases), which surfaces unauthorized authorized_keys modifications in dev/test/production separation but does not cover all platforms or non-environmental vectors such as direct cloud API calls or network device CLI usage.
- T1098.004prevents — A.8.31's separation of dev/test/prod environments, access rules for deployment, and prohibition on dev tools in production directly blocks many vectors for an adversary (esp. in dev/test) to reach and modify authorized_keys files on production Linux/IaaS/ESXi hosts, but leaves open modification via cloud APIs, network device CLI, or post-compromise actions on already-production systems.
- T1098.006detects — A.8.31 explicitly requires monitoring of changes to the environment and code plus secure monitoring of the environments (with real-time monitoring and detailed logging in exceptional cases), which surfaces unauthorized role/permission additions in container orchestration systems that fall inside the monitored scope; this is a genuine but minority slice because the control's focus is on environment separation and change control rather than comprehensive detection of all RBAC/ABAC modifications across all platforms.
- T1098.006prevents — A.8.31's separation of dev/test/prod environments (including access rules, no shared tools, and segregation of rights with review/approval) constrains an adversary from reaching the privileged account or RBAC/ABAC objects needed to add container cluster roles, but leaves open paths such as direct compromise of a production service account or cloud IAM that the control does not address.
- T1114.003detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging on any shared-access exceptions), which surfaces the creation or modification of email forwarding rules when performed inside a monitored dev/test or production environment.
- T1127detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (with real-time monitoring and detailed logging in some cases), which surfaces abuse of developer utilities present in those environments; this is only a slice of T1127 because the technique can be used outside dev/test environments or on production systems where the control's separation rules prohibit the utilities.
- T1127prevents — A.8.31 explicitly requires separating dev/test from production (different domains, no dev tools accessible from prod, rules for deployment, no testing in prod except approved cases), which stops adversaries from using or proxying through trusted developer utilities that exist only in the dev/test side, but leaves production-side utilities (e.g. signed system tools, LOLBAS) untouched.
- T1127.001detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of development/test environments; this surfaces anomalous or unauthorized use of build tools such as MSBuild for proxy execution, but only inside the separated dev/test domains and only for monitored change events, leaving production or unmonitored build activity unreached.
- T1127.001prevents — A.8.31's separation of dev/test/prod environments, rules on software deployment, prohibition on dev tools in production, and access segregation directly stop MSBuild abuse (a build tool) from being available or runnable in production where the bypass would succeed; the remainder is dev/test environments themselves where the technique can still run.
- T1127.002detects — A.8.31 explicitly requires secure monitoring of development/test environments plus monitoring of changes to the environment and code stored therein, which surfaces anomalous deployment or execution activity that could indicate ClickOnce abuse originating from or crossing those environments; this is only a slice of the full technique (which also occurs in production via user execution, rundll32, or startup folder without touching dev/test).
- T1127.003detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the development/test environments; this surfaces abuse of a build utility such as JamPlus inside those environments, but the control's scope is limited to dev/test (not production execution or the broader enterprise) and does not mandate detection of the specific .jam-file technique.
- T1127.003prevents — A.8.31 explicitly requires separating dev/test from production (different domains, no dev tools accessible from prod, rules for deployment, no testing in prod except approved cases), which stops JamPlus abuse from a production context and thereby prevents the technique from running there; it is only partial because the control is silent on preventing JamPlus abuse inside the dev/test environments themselves where the build utility legitimately lives.
- T1136prevents — A.8.31's separation of environments, access rules, deployment authorizations, and segregation of duties (no single person changing both without review) directly blocks an adversary from creating accounts in the production domain from dev/test environments or tools, but leaves open creation within a single already-compromised production environment or via other vectors.
- T1137.001detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments; this surfaces anomalous template or macro modifications that realize T1137.001 but does not guarantee detection of all vectors such as registry hijacks or remote template loads outside the monitored development/test/production separation.
- T1137.001prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, restricted dev-tool access from production, and change monitoring can block an adversary from reaching and modifying Office templates in production user profiles or system paths, but this is only a slice — the technique can still be realized entirely in a production user context, via registry hijacks, remote templates, or macro policy without crossing environment boundaries.
- T1137.002detects — A.8.31 requires monitoring of changes to the development/test environment and code stored therein plus secure monitoring and real-time monitoring for unauthorized changes; this can surface the addition of a malicious Office Test registry key/DLL during development or test activity, but the control's scope is limited to dev/test environments and does not address the same abuse when performed directly against a production user's registry.
- T1137.002prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, prohibition on testing in prod, and controls on dev tools/compilers directly blocks the dev/debug pathway that Office Test was created for, but does not stop an adversary who already has code execution on a production system from writing the Registry key there.
- T1137.003detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging in exceptional cases), which can surface the addition or loading of malicious Outlook forms in dev/test or production but does not guarantee detection of the technique across all vectors or stages.
- T1137.004detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of the environments (with real-time monitoring and detailed logging in some cases), which can surface the addition of a malicious Outlook Home Page URL as an anomalous change, but this is scoped only to development/test/production separation and does not broadly instrument end-user Outlook clients or mailboxes where the persistence actually occurs.
- T1137.004prevents — A.8.31's separation of dev/test/prod environments (with rules on deployment, access controls, no dev tools in prod, and change monitoring) directly stops the dev/test activity of adding a malicious Outlook Home Page URL to a production mailbox, but leaves open the possibility of the adversary performing the same abuse directly against production (e.g. via compromised user credentials or other vectors).
- T1137.005prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, access controls, and prohibition on testing in production directly constrain the ability to introduce and activate malicious Outlook rules (a production persistence mechanism) from dev/test activities, but leaves open vectors such as direct user-level abuse in already-compromised production Outlook instances.
- T1137.006detects — A.8.31 requires monitoring of changes to the development/test environment and code plus secure monitoring of those environments, which can surface anomalous add-in installation or code changes that enable the persistence technique in dev/test (before reaching production), but this is limited to the dev/test slice and does not broadly detect the technique in production Office instances.
- T1137.006prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, testing changes prior to production, and restrictions on development tools in production directly constrain the ability to introduce malicious Office add-ins for persistence via development or deployment paths, but this is only a slice of the technique (e.g., does not address add-ins installed directly in a production Office instance post-compromise or via other vectors).
- T1176.002prevents — A.8.31's separation of dev/test/prod environments, rules on deployment, non-accessible dev tools from prod, and secure config/access controls on dev environments directly constrain the installation and persistence of malicious IDE extensions (or abuse of benign ones) in production IDEs, but only for the production slice of the technique while leaving dev/test environments and side-loading vectors reachable.
- T1195detects — A.8.31 explicitly requires monitoring of changes to the development/testing environment and code plus secure monitoring and real-time monitoring for unauthorized changes, which surfaces manipulation of development tools/environments/repositories as described in T1195; this is only a slice of the full technique (e.g. no coverage of distribution mechanisms, shipment interdiction, or second-order compromises outside the org's dev env).
- T1195prevents — A.8.31 explicitly requires separation of dev/test/prod environments, rules for deployment, no dev tools in production, secure configuration/patching/monitoring of dev environments, and segregation of duties — directly blocking manipulation of development tools, environments, and code that T1195 names as primary supply-chain vectors; partial because it does not address upstream supply-chain stages such as open-source dependencies, distribution mechanisms, shipment interdiction, or second-order compromises after initial access.
- T1195.001detects — A.8.31 explicitly requires monitoring of changes to the development/test environment and code plus secure monitoring of those environments (and real-time monitoring on exceptions), which surfaces adversary manipulation of tools, dependencies or CI/CD components inside the org's own dev pipeline; this is only a slice of the technique, which also covers upstream public-package and external-supply-chain manipulation before receipt.
- T1195.001prevents — A.8.31 requires separation of dev/test/prod environments plus rules for deployment, access controls on tools, secure configuration/patching/monitoring of dev tools and CI/CD environments, and no single-person changes without review; this directly stops many upstream manipulations of dependencies, build tools, and pipeline components (including typosquatting and GitHub Actions compromise) before they reach production consumers, but leaves a slice where the adversary compromises an external open-source dependency or abandoned package before the org's separated environment ever touches it.
- T1195.002detects — A.8.31 requires monitoring of changes to the development/test environment and code plus secure monitoring and real-time monitoring (in some cases) of those environments, which can surface supply-chain manipulation occurring inside them; this is a genuine but minority slice of the broad T1195.002 class that also covers upstream manipulation before the code reaches any organizational environment.
- T1195.002prevents — A.8.31's separation of dev/test/prod (with rules for deployment, no dev tools in prod, testing changes in staging, and access segregation) directly blocks several supply-chain manipulation vectors such as source-code tampering in prod builds or unauthorized promotion of modified releases, but leaves open upstream or external supply-chain compromises (e.g. vendor source, distribution mechanisms) that occur before the organization's environments.
- T1204.005prevents — A.8.31's separation of dev/test/prod environments plus rules on deployment, access controls, secure configuration, patching of dev tools, and monitoring of changes directly blocks many supply-chain paths for malicious libraries reaching production (e.g. preventing unvetted dev/test installs or compromised dependencies from being promoted), but leaves open user-driven installs of third-party libraries directly in production or via unmonitored channels.
- T1213.001prevents — A.8.31's separation of dev/test/prod environments and rules on sensitive data copying directly constrain the presence and accessibility of Confluence instances containing valuable info (esp. in dev environments), preventing the technique from being available to adversaries in production contexts, but leaves a bounded remainder where dev/test environments or approved exceptions still allow mining.
- T1213.003prevents — A.8.31's separation of dev/test/prod environments plus rules on deployment, access segregation, and not copying sensitive data into lower environments directly stops adversaries from reaching production code repositories (and the proprietary code/credentials inside them) via dev or test compromise paths, but leaves the production repository itself reachable by other vectors such as direct credential theft or SaaS compromise.
- T1216detects — A.8.31 requires secure monitoring and change monitoring of dev/test environments plus real-time monitoring for unauthorized cross-environment changes; this can surface anomalous use of proxy scripts or deployment rules in those environments, but has no view of the Windows production technique itself.
- T1216.002detects — A.8.31 requires secure monitoring and change monitoring of development/test environments plus real-time monitoring for unauthorized changes; this can surface abuse of SyncAppvPublishingServer.vbs when it occurs inside those separated environments, but the control does not require monitoring of production endpoints where the technique is typically executed
- T1218.003detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of development/test environments, which can surface anomalous use of CMSTP.exe or malicious INF/SCT payloads during dev/test activity, but does not require or guarantee detection of the technique when used directly in production.
- T1218.005detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (including development/test ones where mshta abuse for execution often originates), which can surface the technique when it touches those monitored domains, but this is scoped only to environment/code changes rather than general detection of mshta.exe abuse in production or across all execution paths.
- T1218.005prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, prohibition on dev tools in production, and access segregation can block an adversary from introducing and executing a malicious HTA payload via mshta.exe from a development or test context, but the control does not address runtime abuse of a trusted production utility like mshta.exe for initial compromise or execution of already-present malicious scripts.
- T1218.007detects — A.8.31 requires monitoring of changes to the environment and code, plus secure monitoring of dev/test/prod environments, which can surface anomalous msiexec.exe abuse (especially in dev/test or during approved deployment), but this is scoped only to environment/code changes rather than broadly detecting the technique across all execution contexts.
- T1218.008detects — A.8.31 requires monitoring of changes to the environment and code, plus secure monitoring of development/test environments; this can surface anomalous use of odbcconf.exe (a signed binary) during development or test activity, but the control's scope is limited to non-production environments and does not address detection of the technique in production.
- T1218.012detects — A.8.31 requires secure monitoring and monitoring of changes to development/test environments (and real-time monitoring plus detailed logging in the exceptional case of shared access rights), which can surface anomalous use of verclsid.exe or related COM abuse when it occurs inside those environments, but this is a minority slice of the technique's possible execution surfaces.
- T1219.001detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test environments, which can surface anomalous IDE tunneling activity (especially when it crosses environment boundaries or uses dev tools in production), but the control's scope is limited to environment separation and does not broadly instrument for IDE tunneling as C2 or persistence inside a single compromised environment.
- T1219.001prevents — A.8.31 mandates separation of dev/test/prod environments plus rules for software deployment, tool access, and change review; this directly constrains IDE tunneling by keeping dev tools (and their tunneling features) out of production and by requiring monitored segregation that stops a single compromised dev workflow from reaching prod systems, but leaves a slice where the technique can still run entirely inside a sanctioned dev environment or via approved jump hosts.
- T1484detects — A.8.31 explicitly requires monitoring of changes to the environment (including production) plus secure monitoring and real-time monitoring for unauthorized changes, which surfaces policy modifications in managed domains/tenants; this is only a slice of the full technique because the control is scoped to dev/test/prod separation rather than mandating comprehensive detection of all domain-policy abuse vectors (e.g. trust forging or rogue DC config).
- T1484prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, testing changes prior to prod, restricted dev tools in prod, and access segregation directly block many GPO/trust/federation modifications that originate from dev/test activities or unauthorized cross-environment changes, but do not address modifications performed directly with prod/admin privileges inside the production domain itself.
- T1484.001prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, access segregation, and prohibition on dev tools in production directly blocks many paths that would let a dev/test actor reach and modify domain GPOs, but leaves open production-side privilege-delegation and admin-access vectors that the control does not address.
- T1484.002detects — A.8.31 requires monitoring of changes to the environment and code, plus secure monitoring and real-time monitoring for unauthorized changes, which can surface trust modifications performed from dev/test environments but does not broadly detect the technique across production identity providers or tenants.
- T1491.001detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring and real-time monitoring for unauthorized changes, which can surface defacement performed from dev/test environments or via unauthorized deployment paths, but does not broadly instrument production user systems, websites, or login messages against post-intrusion internal defacement.
- T1496detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test/prod environments, which can surface anomalous resource consumption (e.g. unexpected compute or network use indicative of cryptomining or proxying) once it is present in a monitored environment.
- T1496.001detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test/prod environments, which can surface anomalous compute usage or unauthorized mining processes once present, but this is scoped only to environment-change and access anomalies rather than general resource-consumption detection across all platforms and deployment vectors named in the technique.
- T1505detects — A.8.31 requires monitoring of changes to the environment and code, plus secure monitoring and real-time monitoring for unauthorized changes, which can surface abuse of server extensibility features in dev/test flows or production deployments but does not broadly instrument or detect the technique across all platforms or post-install execution.
- T1505prevents — A.8.31's separation of dev/test/prod environments, deployment rules, testing-before-prod mandates, and dev-tool restrictions directly block the dev-side installation path that T1505 abuses for persistence on production servers; the remainder is in-place abuse of already-deployed production server extensibility features that the control does not reach.
- T1505.001detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (including production), which can surface malicious stored-procedure or CLR-assembly changes after they are deployed.
- T1505.002detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of the environments (with real-time monitoring and detailed logging in some cases), which can surface the registration or presence of a malicious transport agent in a production Exchange environment; this is limited to a slice because the control is scoped to separation of dev/test/prod rather than mandating comprehensive runtime detection of all persistence mechanisms.
- T1505.002prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, testing changes in staging, and restrictions on dev tools in production directly block the developer-written-and-registered malicious transport agent from reaching the production Exchange server, but only for the subset of T1505.002 that originates in dev/test code rather than direct admin registration or runtime abuse on an already-compromised prod system.
- T1505.003detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of development/test/production environments, which can surface web shell placement as anomalous code or file changes on production web servers; this is only a slice of the technique because the clause's scope is limited to environment-separation monitoring rather than general web-server or network anomaly detection.
- T1505.003prevents — A.8.31's separation of dev/test/prod environments, deployment rules, testing-before-prod mandates, and dev-tool restrictions directly block the most common web-shell insertion paths (uploading via dev/staging or test-in-prod), but do not stop all vectors such as direct exploitation of a production web server vulnerability or supply-chain insertion into production code.
- T1505.004detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring on exceptions), which surfaces unauthorized installation of malicious IIS components on production systems; this is a genuine but minority slice of the technique (most deployment paths and non-production environments sit outside its scope).
- T1505.006detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging on any shared-access exceptions), which surfaces anomalous or unauthorized VIB installation activity on ESXi; this is only a slice of the full technique because the control is scoped to dev/test/prod separation rather than mandating comprehensive host telemetry or signature validation that would catch all masqueraded or forced VIBs.
- T1525detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (including development/test), which can surface unauthorized image implants or modifications in registries used by those environments, but does not mandate detection for production image registries or the provisioning process itself.
- T1525prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, testing changes prior to production, and restrictions on dev tools in prod directly block many paths for an adversary to implant a malicious image into a production registry or provisioning workflow; the remainder is attacks that occur entirely inside an already-compromised production environment or via non-dev channels.
- T1528detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test environments, which can surface anomalous activity that steals tokens from CI/CD pipelines or compromised containers, but this is scoped only to dev/test separation and does not address token theft vectors in production, OAuth phishing, or Azure IMDS.
- T1528prevents — A.8.31's separation of dev/test/prod environments (including CI/CD pipelines, distinct domains, deployment rules, no dev tools in prod, and protected dev/test configs) directly stops many T1528 vectors that rely on compromising a dev/test pipeline or container to steal tokens, but leaves social-engineering OAuth flows, already-compromised prod resources, and non-pipeline vectors untouched.
- T1543prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, testing changes in staging, and restrictions on tools/access prevent an adversary from introducing or modifying system processes (services/daemons) via development or test activities that could reach production, but this does not address direct creation/modification of system processes in production environments themselves.
- T1543.001detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which surfaces anomalous .plist modifications or launch-agent installs in dev/test/production separation; this is genuine but only a slice of the full technique surface (e.g., user-level disguised agents outside monitored domains or post-login execution remain unreached).
- T1543.001prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, access controls, and prohibition on dev tools in production directly blocks an adversary from using dev/test activities or compromised dev environments to create/modify launch agents in production (a common developer-task vector), but leaves user-level persistence mechanisms in production environments untouched.
- T1543.002detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which can surface unauthorized systemd service file creation or modification in dev/test but does not mandate coverage of production service directories or generator activity.
- T1543.002prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, testing changes in staging, and restrictions on dev tools in production directly block many paths for creating/modifying systemd services as persistence (especially via dev workflows or generators), but not all (e.g. direct root/admin changes in production or post-deployment abuse).
- T1543.003prevents — A.8.31's separation of dev/test/prod environments (including access rules, no dev tools in prod, change testing in staging, and segregated rights with monitoring) prevents an adversary from using dev/test systems to create/modify Windows services in the production environment for persistence, but leaves direct attacks on a production system (or production-only workflows) unaddressed.
- T1543.004detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which surfaces unauthorized Launch Daemon plist or executable modifications after they occur in dev/test or production.
- T1543.004prevents — A.8.31's separation of dev/test from production (with rules on deployment, no dev tools in prod, access controls, change monitoring, and no sensitive data copying) constrains an adversary's ability to introduce or modify Launch Daemons from dev/test activities or poor configs, but does not block direct admin-level installation or modification in production itself.
- T1543.005detects — A.8.31 requires monitoring of changes to the environment and code, plus secure monitoring of development/test environments and real-time monitoring for unauthorized changes; this surfaces some adversary modifications of container services (e.g. in dev/test or via change detection) but does not broadly instrument or detect the technique on production hosts where it is typically executed.
- T1543.005prevents — A.8.31's separation of dev/test/prod environments (with rules on deployment, access segregation, no dev tools in prod, and protected test environments) directly stops an adversary from using dev/test access to create/modify container services like Docker/Podman/kubelet in production, but leaves open production-only vectors such as direct admin access or compromised prod credentials.
- T1546detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test environments (with real-time monitoring and detailed logging in some cases), which can surface malicious event-trigger modifications in those separated environments but does not address production systems or runtime event triggers themselves.
- T1546.001detects — A.8.31 requires monitoring of changes to the environment and code (including in production) plus secure monitoring and real-time monitoring for unauthorized changes, which surfaces Registry modifications that implement this technique but does not mandate coverage of all possible vectors or post-execution detection of the triggered payload.
- T1546.002detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which surfaces anomalous registry or file changes that implement this screensaver persistence on dev/test systems (and production if misconfigured), but does not address the runtime execution trigger or user-specific registry manipulation on production endpoints outside those environments.
- T1546.003detects — A.8.31 requires monitoring of changes to the environment and code, plus secure monitoring and real-time monitoring for unauthorized changes, which can surface WMI-based persistence artifacts (e.g. event subscriptions or MOF changes) in dev/test/prod separation but does not mandate or guarantee detection of the technique itself across all execution paths.
- T1546.004detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which surfaces unauthorized modifications to shell config files (the core of this persistence technique) in dev/test/prod separation; partial because the control's scope is limited to those segregated environments rather than all possible shell configs on every host.
- T1546.004prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, restricted dev-tool access from production, and change monitoring directly block an adversary from reaching and modifying production shell config files (e.g. /etc/profile, ~/.bash_profile) via dev/test activities, but the control does not address direct modification in production by other means (e.g. via existing compromised accounts or non-dev vectors).
- T1546.005detects — A.8.31 requires secure monitoring and change monitoring of development/test environments (plus real-time monitoring for exceptional elevated-access cases), which can surface anomalous trap-based persistence mechanisms placed in those environments, but does not address production runtime detection of the technique.
- T1546.006detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of development/test environments, which can surface unauthorized binary/header modifications that implement this technique, but only inside those separated environments and not on production endpoints where the tainted binary would actually execute.
- T1546.007detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging in some cases), which can surface anomalous netsh helper DLL registrations or related code changes on production systems; this is a genuine but minority slice of the technique's full attack surface (registry writes can occur outside monitored dev/test/production boundaries or via unmonitored paths).
- T1546.009detects — A.8.31 requires secure monitoring and change monitoring of development/test environments plus real-time monitoring for unauthorized changes in exceptional cases; this can surface anomalous DLL/registry activity tied to the technique in those environments, but the control's scope is limited to dev/test separation and does not mandate detection of the technique in production.
- T1546.011prevents — A.8.31's separation of dev/test/prod environments, rules on software deployment, and restrictions on dev tools in production directly block many paths for installing or triggering malicious shims (a dev-time or admin-privileged activity), but the control does not reach runtime shim abuse, custom .sdb placement by already-privileged actors, or production-only shim installation.
- T1546.012detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which surfaces anomalous IFEO Registry modifications or debugger registrations after they occur.
- T1546.013detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging in the exceptional case of shared access), which surfaces unauthorized modification of a PowerShell profile in a development or test environment before it reaches production.
- T1546.014detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which would surface unauthorized rule additions or modifications in /etc/emond.d/rules/ on a production system; this is a genuine but minority slice of the full technique surface (writing/using the rule, service execution, privilege escalation).
- T1546.015detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging in exceptional cases), which can surface unauthorized Registry changes involved in COM hijacking on production systems; this is limited to a slice because the control's scope is separation of dev/test/prod rather than comprehensive endpoint or Registry monitoring for persistence techniques.
- T1546.016detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which surfaces anomalous installer activity or modified maintainer/postinstall scripts in dev/test/production separation; this is genuine but only a slice of the technique's full surface (e.g. supply-chain distribution of trojaned packages to end-users outside monitored environments).
- T1546.017detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging in exceptional cases), which can surface unauthorized udev rule additions or modifications on Linux systems, but this is scoped only to development/test/production separation rather than universal coverage of all udev rule locations or runtime triggers.
- T1546.017prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, access controls, change monitoring, and prohibition on unapproved testing in production directly constrain the ability to add/modify udev rules (which require root and live in production system paths) from dev/test activities, but do not block all vectors such as direct prod compromise or approved emergency changes.
- T1546.018detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging when a single person can touch both dev and prod), which surfaces the placement or modification of .pth / sitecustomize.py / usercustomize.py files that realize the technique; the coverage is only a slice because the clause's scope is limited to the defined separation between dev/test/prod environments rather than universal host or Python-interpreter monitoring.
- T1546.018prevents — A.8.31's separation of dev/test/prod environments (with rules on deployment, no dev tools in prod, access controls, and change monitoring) directly stops adversaries from placing .pth/sitecustomize.py hooks into production Python environments, but leaves open the possibility of the technique being introduced legitimately through approved production changes or in non-Python production contexts.
- T1547.003detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging in exceptional cases), which can surface the registry change and malicious DLL registration that T1547.003 performs, but only where that change occurs inside the monitored development/test/production separation boundary rather than on an arbitrary production endpoint.
- T1547.006detects — A.8.31 explicitly requires secure monitoring and monitoring of changes to the development/test environments and code (including tools that could produce kernel modules), which surfaces anomalous or unauthorized kernel-module activity in those environments; this does not extend to production systems or in-the-wild LKM/kext use on Linux/macOS endpoints.
- T1547.006prevents — A.8.31's separation of dev/test from production (including rules for deployment, no dev tools in prod, change testing outside prod, and access segregation) stops malicious kernel modules from being introduced via dev/test activities in production environments, but does not block direct loading of LKMs/kexts by already-privileged code or admins on production systems themselves.
- T1547.012detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of development/test environments (and production separation), which can surface anomalous print-processor registration or DLL loading in those environments, but has no defined scope or mechanism for production boot-time spoolsv.exe behavior or the specific registry/API technique on end-user systems.
- T1547.013detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which surfaces unauthorized modifications to XDG Autostart .desktop files in production; this is a genuine but minority slice of the technique (most instances are user-level in ~/.config/autostart rather than production-system changes).
- T1547.014detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments, which surfaces anomalous registry changes or unauthorized persistence mechanisms on production systems; this is a genuine but minority slice of the technique (post-compromise detection on prod only, not the initial registry abuse itself).
- T1552.001prevents — A.8.31's separation of dev/test/prod environments (including rules on deployment, no dev tools in prod, no sensitive data copied to dev/test without equivalent controls, and access segregation) directly stops many common ways credentials end up insecurely stored in files that adversaries can search, especially in dev/test artifacts, configs, backups, and container logs; however, it leaves a bounded remainder for user-created credential files or embedded creds in production code/configs outside the separation rules.
- T1553.003detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging on any shared-access exceptions), which surfaces tampering with production SIP/trust-provider components or their registry values when those live in the protected production domain.
- T1553.006detects — A.8.31 explicitly requires monitoring of changes to the environment and code, plus secure monitoring and real-time monitoring for unauthorized changes, which surfaces policy modifications (especially in dev/test or via deployment rules) but does not guarantee coverage of all kernel/registry/boot-modification vectors on production endpoints.
- T1553.006prevents — A.8.31's separation of dev/test/prod environments (with rules on deployment, no dev tools in prod, no sensitive data copies without controls, and access segregation) directly constrains the developer/testing exception that the technique explicitly relies on to modify signing policies, but leaves production systems reachable via other vectors such as registry edits, kernel memory alteration, or privilege escalation that the control does not address.
- T1554detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring and real-time monitoring (in some cases) of development/test/production environments, which can surface unauthorized binary modifications on those systems, but this is scoped only to environment-separation contexts rather than general production binaries or post-deployment host software across the enterprise.
- T1554prevents — A.8.31's separation of dev/test/prod plus rules on deployment, no dev tools in prod, change testing, and access segregation directly stops many dev/test-origin binary modifications from reaching production hosts, but leaves open adversary modification of already-deployed production binaries (e.g. in-place patching of SSH clients or browsers) which the control does not address.
- T1555.006detects — A.8.31 requires secure monitoring and change monitoring of development/test environments plus real-time monitoring for unauthorized changes when segregation is relaxed; this surfaces anomalous access or retrievals that could realize T1555.006 but only inside those environments, not production secrets-manager API calls on IaaS.
- T1556prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, testing changes outside prod, restricted dev tools in prod, and access segregation directly block many paths for an adversary to reach and maliciously modify auth mechanisms (e.g. PAM, LSASS, plugins) from dev/test activities, but leaves open modification vectors in already-deployed production auth processes themselves.
- T1556.001detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring plus real-time monitoring for unauthorized changes; this surfaces the LSASS patching activity on a domain controller (a production system) but does not guarantee detection of all variants or in-memory-only patches before use.
- T1556.003detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging in exceptional cases), which can surface malicious modifications to PAM components on production systems; this is only a slice of the technique because the control is scoped to environment separation and does not mandate detection of all possible PAM modifications or credential-harvesting behaviors.
- T1556.003prevents — A.8.31's separation of dev/test/prod (with rules on deployment, no dev tools in prod, change review, and secure configs/patching/monitoring in all environments) prevents many malicious modifications or patching of PAM components from dev/test activities reaching production systems, but does not stop an adversary with prod access from directly modifying PAM in place.
- T1556.007detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging when a single person can touch both dev and prod), which surfaces the on-premises modification/backdooring steps that dominate the technique but does not address the cloud-side registration of a malicious PTA agent.
- T1556.007prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, access controls, change monitoring, and prohibition on single-person changes without review directly constrain on-premises modification of PTA/AD FS agents and related hybrid auth processes (the dominant attack surface), but the technique's cloud-side vectors (e.g., Global Admin registering a PTA agent) and fully cloud-hosted identity providers sit outside the control's production-environment focus.
- T1556.008detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of development/test environments (and real-time monitoring plus detailed logging for exceptional elevated-access cases); this surfaces anomalous DLL registration or code changes on dev/test systems but does not address production deployment, runtime credential-capture behavior, or monitoring on production servers/domain controllers where the technique is explicitly targeted.
- T1561.002recovers — A.8.31 explicitly requires taking backups of the development/test/production environments and protecting them so that production can be restored after compromise or destructive events such as disk-structure wipe.
- T1563.001detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test environments (and real-time monitoring for exceptional cases), which can surface anomalous SSH agent/socket access or unauthorized lateral movement originating from those environments, but does not mandate detection of SSH hijacking in production sessions or on production systems.
- T1563.002detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of the environments (and real-time monitoring plus detailed logging in exceptional cases), which can surface anomalous RDP hijacking activity in dev/test/production separation but does not mandate or guarantee detection of the technique itself.
- T1564.006detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test environments, which can surface rogue VM creation or anomalous virtualization activity inside those separated domains, but does not mandate host-level detection of hidden VMs or sandboxed instances running on production systems.
- T1565detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring plus real-time monitoring (in some cases) of production vs dev/test, which surfaces some data manipulation performed from dev/test environments or via unauthorized cross-environment changes, but does not broadly detect manipulation inside production data or processes.
- T1565prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, testing changes outside prod, restricted dev tools in prod, and access segregation directly block many paths for an adversary to reach and manipulate production data, but do not stop manipulation achieved via other vectors such as compromised credentials, supply-chain compromise, or direct production access.
- T1565.001detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring and real-time monitoring for unauthorized changes, which surfaces some stored data manipulation in dev/test/prod environments but does not broadly detect the technique across arbitrary stored data such as Office files, databases or emails outside those segregated environments.
- T1565.001prevents — A.8.31's separation of dev/test/prod environments, deployment rules, change testing, restricted tool access, and environment protections directly block many paths for an adversary to reach and manipulate stored production data at rest, but do not stop all insider or post-compromise manipulation vectors that could still reach production stores.
- T1565.003detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring and real-time monitoring for unauthorized changes, which can surface runtime binary or data manipulations performed in dev/test or during promotion to production.
- T1565.003prevents — A.8.31's separation of dev/test/prod environments, deployment rules, change testing, restricted dev tools in prod, and access segregation directly block many paths for altering production binaries or runtime data manipulators from dev/test activities, but do not stop all in-production modification vectors (e.g. via existing prod tools, supply-chain binaries, or post-deployment exploits).
- T1567.001detects — A.8.31 requires monitoring of changes to the development/test environment and code stored therein plus secure monitoring and real-time monitoring for unauthorized changes; this can surface anomalous exfiltration of data into a code repo from dev/test hosts (especially if the repo is internal or the action crosses env boundaries), but the control is scoped only to dev/test/prod separation and does not broadly instrument or detect the technique across production networks or non-dev exfiltration paths.
- T1567.001prevents — A.8.31's separation of dev/test/prod environments (including rules for software deployment, no dev tools in prod, no sensitive data copied to dev/test without equivalent controls, and access segregation) directly stops adversaries from using dev/test code repositories or environments as exfiltration targets from production systems, but leaves production-to-external-public-repo paths and non-environment-specific exfiltration untouched.
- T1569prevents — A.8.31's separation of dev/test/prod (with rules on deployment, no dev tools in prod, access controls, change monitoring, and no single-person changes without review) constrains the ability to create/modify/abuse system services from dev/test activities reaching production, but leaves many in-production abuse vectors (local/remote service interaction, boot persistence, or direct admin abuse) untouched.
- T1569.003detects — A.8.31 explicitly requires secure monitoring and monitoring of changes to the development/test environments (and real-time monitoring plus detailed logging for exceptional cross-environment changes), which surfaces abuse of systemctl in those environments but does not address production environments where the technique is typically used.
- T1574detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of the environments (with real-time monitoring and detailed logging in some cases), which can surface hijack attempts that alter dev/test artifacts or cross-environment flows, but this is scoped only to the separated environments rather than production execution flow hijacks in general.
- T1574prevents — A.8.31's separation of dev/test/prod environments, rules on deployment, non-production testing, restricted dev tools in prod, and access segregation directly block several hijack vectors (e.g. poisoned libraries, directories, or tools crossing from dev/test into prod execution), but many T1574 techniques (registry poisoning, DLL search-order hijacking, or in-place binary replacement on production systems) remain fully reachable.
- T1574.001detects — A.8.31 explicitly requires monitoring of changes to the environment and code plus secure monitoring of dev/test environments, which surfaces anomalous DLL planting, substitution or hijacking activity in those separated domains before it reaches production.
- T1574.001prevents — A.8.31's separation of dev/test/prod environments, rules on software deployment, non-accessible dev tools from prod, and secure configs/backups directly block several DLL abuse vectors (e.g. sideloading, search-order hijacking, substitution) that rely on mixing untrusted code or dev artifacts into production, but leaves many in-production mechanisms (phantom hijacking, remote DLL loading, registry redirection) untouched.
- T1574.004prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, access controls, and secure configuration of dev tools can stop malicious dylibs from being introduced via development or test activities into production search paths, but leaves the runtime search-order and weak-linking vectors in already-deployed production applications untouched.
- T1574.005prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, non-production testing, restricted dev tools in prod, and secure config/access controls in dev/test environments can block many installer-permission-weakness scenarios that arise from dev/test activity or mixed environments, but the technique's core (weak perms on %TEMP% subdirs or installer binaries in production installs) is not directly addressed and can still occur independently.
- T1574.006prevents — A.8.31's separation of dev/test/prod environments (including rules on deployment, no dev tools in prod, controlled access, and no sensitive data copying without equivalent controls) directly stops developers from using LD_PRELOAD-style hijacking in production binaries or processes, but leaves open the possibility in dev/test environments or via approved production changes.
- T1574.007prevents — A.8.31's separation of dev/test/prod environments, rules for deployment, restricted dev tools in production, and secure configuration/access controls in dev/test environments prevent many PATH hijacking vectors that rely on mixing untrusted dev artifacts or modifications into production search paths, but leave residual cases (e.g., legitimate but writable production directories or user-controlled $PATH in non-dev contexts) unaddressed.
- T1574.008detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test environments (and real-time monitoring on elevated-risk changes), which can surface anomalous binaries placed via search-order hijacking in those environments, but does not address production runtime detection of the technique itself
- T1574.008prevents — A.8.31's separation of dev/test/prod environments plus rules on deployment, access control, change monitoring, and not copying sensitive data into dev/test directly blocks an adversary from placing a malicious payload in a production program's directory via dev/test activities, but leaves other vectors (e.g. supply-chain compromise, insider in prod, or non-dev/test placement) untouched.
- T1574.009detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test/prod environments, which can surface anomalous binaries placed for path interception (especially in dev/test or during deployment), but this is indirect, limited to monitored environments, and does not broadly detect the technique on production endpoints or in the Windows resolution behavior itself.
- T1574.009prevents — A.8.31's separation of dev/test/prod environments plus rules on deployment, access control, change monitoring, and not copying sensitive data into test/dev directly blocks many opportunities for an adversary-placed executable to be introduced or resolved in production paths, but leaves residual cases (e.g. already-deployed unquoted paths in production services/shortcuts or insider changes that bypass the single-person rule).
- T1574.010detects — A.8.31 explicitly requires monitoring of changes to the environment and code plus secure monitoring of the environments (with real-time monitoring and detailed logging in some cases), which surfaces anomalous file replacements or permission misuse that realize this technique, but only within the scoped development/test/production separation rather than on arbitrary production Windows services.
- T1574.012detects — A.8.31 explicitly requires secure monitoring and change monitoring of development/test environments plus real-time monitoring for unauthorized changes when segregation is relaxed; this surfaces abuse of COR_PROFILER (a dev-time profiling hook) inside those environments but does not address production .NET processes or in-memory registry-free variants outside the dev/test boundary.
- T1574.014detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of the environments (and real-time monitoring in some cases), which can surface AppDomainManager hijacking artifacts such as tampered .config files, unexpected environment variables, or anomalous assembly loads in dev/test/production separation; this is only a slice of the full technique surface (e.g., in-process creation of malicious AppDomains without config/env changes is less directly covered).
- T1578detects — A.8.31 explicitly requires monitoring of changes to the environment and code, plus secure monitoring and real-time monitoring for unauthorized changes, which surfaces modifications to compute infrastructure in dev/test/prod separation (especially cloud IaaS where environments overlap), but this is scoped only to the environments under the control's separation rules rather than broadly across all adversary modifications.
- T1578prevents — A.8.31's separation of dev/test/prod (with rules on deployment, access segregation, no dev tools in prod, and change monitoring) directly constrains an adversary's ability to modify production cloud compute infrastructure from a dev/test foothold, but leaves open modifications performed entirely within production or via other vectors.
- T1578.001detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring for exceptional cases), which surfaces snapshot creation as an anomalous change in IaaS compute environments; this is only a slice of the technique because the control's scope is limited to dev/test/prod separation rather than universal cloud activity monitoring.
- T1578.002prevents — A.8.31 requires separation of dev/test/prod environments (including virtual domains, access rules, no dev tools in prod, and controlled deployment), which directly stops an adversary from creating a cloud instance in the production environment to bypass its defenses or run malicious activity there.
- T1578.003detects — A.8.31 explicitly requires monitoring of changes to the environment plus secure monitoring and real-time monitoring (with logging) of development/test/production environments, which surfaces deletion of a cloud instance as an anomalous change; this is only a slice of the technique because the control's scope and monitoring requirements are set by the organization rather than mandating universal coverage of all IaaS instances.
- T1578.003recovers — A.8.31 requires backups of development/test/production environments and their data, which can restore a deleted cloud instance (and its artifacts) after the T1578.003 event; this is genuine recovery but only partial because the control's scope is environment separation and its backup mandate is not universal across all IaaS instances an adversary could target.
- T1578.004detects — A.8.31 explicitly requires monitoring of changes to the environment and code plus secure monitoring of the environments (with real-time monitoring and detailed logging in exceptional cases), which surfaces reversion of a cloud instance via snapshot restore or ephemeral storage reset after malicious activity.
- T1578.004prevents — A.8.31's separation of dev/test/prod environments (including distinct domains, deployment rules, no dev tools in prod, and access segregation) directly constrains an adversary's ability to reach and use the cloud management dashboard/APIs needed to revert a production VM/snapshot, but leaves open the remainder where the adversary already holds sufficient privileged access inside the production environment itself.
- T1578.005detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test/prod environments (with real-time monitoring and detailed logging in some cases), which can surface unauthorized configuration modifications in cloud compute settings, but only for monitored environments and changes rather than all possible quota/policy/region modifications on IaaS platforms.
- T1601detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring and real-time monitoring (with logging) of development/test/production environments to surface unauthorized changes; this surfaces T1601 attempts on the monitored systems but only reaches a slice (network devices are outside ordinary dev/test/prod separation, and monitoring scope is set by the implementer).
- T1601.001detects — A.8.31 explicitly requires monitoring of changes to the environment and code stored therein plus secure monitoring of the environments (and real-time monitoring plus detailed logging when a single person can touch both dev/prod), which surfaces the modification of a production network-device OS image or its in-memory state; this is only a slice of the full technique because the control is scoped to dev/test/prod separation rather than mandating comprehensive detection coverage of all T1601.001 vectors (e.g. boot-loader ROMMONkit, TFTP-boot, or debug-command memory patches on non-monitored network devices).
- T1601.001prevents — A.8.31's separation of dev/test/prod environments, deployment rules, testing-before-production, restricted dev tools in prod, and access segregation directly block many standard operator procedures (TFTP/FTP/SCP/console-based patching of stored images or debug-command memory edits) that assume unified or insufficiently separated environments; however, bootloader/ROMMONkit paths, already-compromised prod access, or in-memory runtime patching on network devices remain outside its scope.
- T1601.002detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring and real-time monitoring for unauthorized changes, which can surface a downgrade of a production network device image; this is only a slice of the technique (post-deployment on managed production devices, not development/test or pre-boot embedded replacement).
- T1610detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test/prod environments (with real-time monitoring in some cases), which can surface unauthorized or anomalous container deployments but does not mandate coverage of all deployment vectors or runtime indicators across production.
- T1610prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, testing changes prior to production, and access controls on production systems constrain many of the means and configurations by which an adversary can deploy a malicious or bypass container (especially via dev pipelines, dashboards, or unvetted images), but do not block all vectors such as direct API use on production nodes or already-compromised production environments.
- T1611detects — A.8.31 explicitly requires monitoring of changes to the environment and code plus secure monitoring of the development/test environments (and real-time monitoring for exceptional cases), which surfaces anomalous escape-related activity such as unauthorized mounts, privilege escalations, or configuration changes that enable T1611, but only within the dev/test slice rather than production or all possible escape vectors.
- T1611prevents — A.8.31 explicitly requires adequate separation of dev/test/prod in separate domains (virtual/physical), rules for deployment, no dev tools in prod, no sensitive data copied without equivalent controls, and secure configuration/access control/monitoring of those environments; this directly counters the isolation failures that enable T1611 container/VM escapes (e.g. bind mounts, privileged containers, shared sockets), but leaves residual paths via unpatched tools, misconfigurations, or approved exceptions.
- T1612detects — A.8.31 requires monitoring of changes to the environment and code stored therein plus secure monitoring of development/test environments; this can surface anomalous build activity on a host (especially in dev/test domains), but the control is scoped only to dev/test/prod separation and does not mandate host-level detection of container builds in production or runtime.
- T1612prevents — A.8.31 requires separation of dev/test from production (different domains, no dev tools on prod, rules for deployment, no testing in prod, access controls, change monitoring) which directly stops build-image activity from occurring inside the production environment itself; the technique can still be executed from a dev/test environment or from outside the separated domains, which is a genuine open slice rather than a named remainder.
- T1651detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test/prod environments (with real-time monitoring and detailed logging in exceptional cases), which can surface abuse of cloud admin commands that affect or cross environment boundaries, but this is scoped only to separation rules rather than broadly detecting the technique in production VMs.
- T1666detects — A.8.31 explicitly requires monitoring of changes to the environment and code, plus secure monitoring and real-time monitoring for unauthorized changes; this surfaces some hierarchy-modification actions (especially in approved/tested deployment paths or via access segregation) but does not broadly instrument the IaaS control-plane APIs (LeaveOrganization, CreateAccount, subscription transfers) that realize T1666.
- T1677detects — A.8.31 explicitly requires monitoring of changes to the environment and code plus secure monitoring of the environments (with real-time monitoring and detailed logging in some cases), which surfaces pipeline-poisoning activity once it occurs, but only for a slice of the technique (primarily direct/indirect changes inside controlled environments, not public/fork-based scenarios or self-hosted runner execution).
- T1677prevents — A.8.31's separation of dev/test/prod environments, rules for deployment from dev to prod, testing changes in staging, no dev tools in prod, and access segregation directly block several poisoning vectors (esp. direct/indirect modification of CI configs or referenced files from prod or unapproved paths), but leaves public/PR-based and self-hosted-runner scenarios largely untouched.
- T1685.002detects — A.8.31 requires secure monitoring, change monitoring, and real-time monitoring (with detailed logging) of development/test/production environments and access rights; this surfaces tampering with logging configurations or unauthorized changes that could disable/modify cloud logs, but only for a slice of the technique (environment-specific changes, not all cloud logging toggles or license downgrades).
- T1685.004detects — A.8.31 requires monitoring of changes to the environment and code, plus secure monitoring of the environments themselves; this surfaces tampering with auditd, its rules or its daemon but does not guarantee detection of every hooking or configuration-bypass method an adversary can use once root is obtained.
- T1686detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of dev/test/prod environments (with real-time monitoring in exceptional cases), which can surface unauthorized firewall modifications when performed from or affecting those environments, but this is scoped only to separation/change-control contexts rather than general host/network firewall tampering post-compromise.
- T1686.001detects — A.8.31 requires monitoring of changes to the environment and code plus secure monitoring of the environments (including production), which surfaces unauthorized firewall/security-group modifications once they occur.
Prevented OWASP Web Top 10 (2025) risks (11)
OWASP Web Top 10 (2025) risk categories this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- A01mitigates — segregation of environments, access rights, change rules, and monitoring limit the blast radius and consequence of a realized broken-access-control flaw (e.g., a dev/test compromise cannot easily reach production data or authorization logic), but do not bound or reduce the impact of most A01 member defects once they exist in production code
- A01prevents — A.8.31's separation of environments, deployment rules, access segregation, and testing requirements prevent many Broken Access Control defects (e.g. path traversal or IDOR arising from shared/dev data, missing checks from un-reviewed prod changes, or CSRF via test bleed) but leave the dominant logical-authorization-decision failures (CWE-862/863/284) untouched.
- A02mitigates — separation of environments plus access rules and monitoring limit the blast radius and consequence when a misconfiguration occurs in one environment (especially production), but do not address the core weakness of weak defaults or incomplete hardening itself
- A02prevents — A.8.31's separation of environments, rules for deployment, testing prior to prod, non-production of dev tools, and secure config/patching/access controls in dev/test directly prevent many classes of weak defaults and exposed attack surface from reaching production, but not all (e.g. runtime server/framework misconfigs or incomplete hardening that arise independently in prod).
- A03mitigates — separation plus access rules, change monitoring and approvals limit the blast radius and consequence of a compromised build pipeline or dependency introduced from dev/test, but do not bound or reduce impact of already-compromised signing infrastructure or runtime exploitation of vulnerable dependencies in production
- A05mitigates — separation plus access rules and change monitoring limit the blast radius and unauthorized propagation of an injection flaw introduced in dev/test into production, but do not change the realized consequence of an injection that is already present and executed in production
- A08mitigates — separation plus deployment rules, testing-before-prod, and access segregation limit the blast radius and consequence of a realized integrity failure (e.g. stopping a compromised CI/CD pipeline or unsigned change from reaching production), but do not reduce the presence or realization of the weakness itself
- A08prevents — A.8.31's separation of environments, deployment rules, testing-before-prod mandates, dev-tool isolation, and change-review requirements directly block multiple CI/CD compromise paths and unsigned-update vectors that are core to A08:2025, but leave insecure deserialization and other runtime integrity failures untouched.
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.