A.8.30 Technological
Outsourced development
AttributesPreventiveDetectiveC·I·AIdentifyProtectDetectSystem and network securityApplication securitySupplier relationships securityGovernance and EcosystemProtection
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
The implementation guidance for this control is published in
ISO/IEC 27002:2022
and is not reproduced here. The structured attributes and the cross-walk
rationales below are derived facts and our own AI-authored analysis.
Mapped NIST 800-53 r5 controls (17)
Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- SA-11mostlyaligns with — The ISO control’s emphasis on requiring and reviewing evidence of testing for vulnerabilities and malicious content directly supports the NIST requirement for developer testing and evaluation of security functionality.
- CA-2partialaligns with — The contractual right to audit and the review of assurance reports constitute control assessments performed on external development activities.
- SA-4partialaligns with — Specifying secure design, coding, testing, and acceptance criteria in contracts is a core element of the acquisition process addressed by SA-4.
- SR-2partialaligns with — Documenting and enforcing security expectations across the external development supply chain contributes to the supply-chain risk management plan required by SR-2.
- SR-3partialaligns with — Requiring contractual controls, audit rights, and evidence of secure practices from external developers implements the supply-chain controls and processes mandated by SR-3.
- SA-9noneimplements — Both controls require the organization to impose security and privacy requirements on external development providers and to verify that those requirements are met through ongoing oversight and evidence.
- SA-4implements — A.8.30 directly requires security measures in outsourced development; SA-4 operationalizes this by mandating that those exact security, assurance, and control requirements be explicitly included in the acquisition contract for the outsourced system/service.
Aligned NIST CSF 2.0 outcomes (20)
NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- GV.SC-07mostlyaligns with — Ongoing monitoring and review of outsourced deliverables to confirm security and privacy capabilities are met aligns with the CSF outcome of understanding, recording, and prioritizing supplier risks.
- PR.PS-06mostlyaligns with — Mandating secure design, coding, and testing practices plus evidence of vulnerability and malicious-code testing integrates secure-development requirements into outsourced work.
- GV.SC-03partialaligns with — Integrating outsourced-development controls into the broader supply-chain risk program links supplier oversight with enterprise cybersecurity risk management.
- ID.RA-09partialaligns with — Requiring proof that deliverables are free from known vulnerabilities and malicious content before acceptance aligns with assessing authenticity and integrity of acquired software.
- ID.RA-10partialaligns with — Requiring evidence of security capabilities and testing before accepting deliverables supports the CSF practice of assessing critical suppliers prior to acquisition and use.
- GV.SC-05noneimplements — The ISO control’s contractual clauses for secure design, coding, testing, and audit rights directly implement the CSF requirement to embed cybersecurity requirements into supplier contracts.
- GV.SC-03implements — 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.
- GV.SC-07implements — Assessed as NOT holding by the authoring instrument at v1.19-2026-08-23. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- ID.RA-09implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- ID.RA-10implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PR.PS-06implements — A.8.30 directly operationalizes secure outsourced development practices (a core slice of PR.PS-06's integrated-and-monitored SDLC practices) within the CSF outcome's domain
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)
- V15.1.1mostlyaligns with — The ISO control's requirement to agree on and monitor secure design, coding, and testing practices for outsourced development directly supports the ASVS mandate for documented risk-based remediation timelines for third-party component vulnerabilities.
- V15.1.2mostlyaligns with — Requiring evidence of security capabilities and testing from external developers aligns with maintaining an up-to-date inventory of all third-party libraries and their versions used in the application.
- V1.5.2partialaligns with — Requiring evidence that testing has guarded against malicious content in outsourced deliverables aligns with the ASVS requirement for safe deserialization of untrusted data using allowlists or type restrictions.
- V13.3.1partialaligns with — The ISO control's requirement for secure development environment controls and escrow agreements for source code aligns with using a secrets management solution to protect backend credentials and keys.
- V15.2.1partialaligns with — Contractual monitoring and acceptance testing of outsourced deliverables helps ensure that third-party components have not exceeded documented vulnerability remediation timeframes.
- V15.2.4partialaligns with — The ISO control's emphasis on contractual rights to audit and verify the origin of outsourced code supports the ASVS requirement that third-party components and transitive dependencies come from expected repositories.
Related weaknesses / CWE (12)
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-1103mitigates — Outsourced development controls can enforce platform-portability requirements on third-party deliverables.
- CWE-111prevents — Outsourced development contracts can require safe JNI practices, though the weakness itself is not addressed by the control.
- CWE-1357prevents — Outsourced-development controls address third-party code/components that may be insufficiently trusted.
- CWE-200prevents — Requiring privacy and security capability evidence plus audit rights limits the chance that sensitive data exposure flaws will be shipped without detection or remediation.
- CWE-284prevents — Contractual mandates for secure design, coding, testing, and audit rights force external developers to implement proper access-control mechanisms rather than leaving authorization decisions to unverified third-party code.
- CWE-434prevents — Mandated testing for malicious content and known vulnerabilities reduces the likelihood that an outsourced component will contain or accept dangerous file types that could later be uploaded or executed.
- CWE-74prevents — Outsourced development agreements can require injection-prevention practices from suppliers.
- CWE-798prevents — Contractual requirements for secure coding practices and evidence of testing make it less likely that hard-coded credentials will be introduced or remain undetected in delivered code.
- CWE-862prevents — Requiring evidence of minimum security capabilities and acceptance testing ensures that missing or bypassed authorization checks are detected before the delivered software is accepted.
- CWE-943prevents — Outsourced development agreements can require secure coding practices, indirectly mitigating the weakness.
Mitigated MITRE ATT&CK techniques (145)
Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
T1001.003←MT1006←FT1027→PT1027.001←MT1027.002←MT1027.004←MT1027.006←MT1027.007←MT1027.008←MT1027.009←M →PT1027.010←MT1027.014←MT1027.016←M →PT1027.017→PT1027.018←MT1036.003←MT1036.005←MT1036.008←MT1055←MT1055.001←MT1055.002←FT1055.003←MT1055.004←MT1055.005←MT1055.008←MT1055.009←MT1055.011←MT1055.012←MT1055.013←MT1055.014←MT1055.015←MT1056.003→PT1059.007→PT1068→PT1071.004←MT1078←PT1080→PT1098.005←MT1127←M →PT1127.001←MT1134.004←MT1137.001→PT1176.002→PT1190→PT1195→PT1195.001←M →PT1195.002→PT1199→PT1203→PT1204.005→PT1207←MT1210→PT1211←P →PT1212→PT1216←MT1216.001←FT1218←MT1218.005←MT1218.007←MT1218.008←MT1218.010←MT1218.011←MT1218.012←MT1218.013←MT1221←MT1222←MT1480.001←MT1484←MT1484.002←MT1497←MT1497.002←MT1499.004→PT1505→PT1505.001→PT1505.002→PT1505.003→PT1525→PT1528→PT1535←MT1542←MT1542.002←MT1546.011→PT1546.016←P →PT1547.006→PT1550←MT1550.001←FT1550.004←FT1552.001→PT1553.001←MT1553.002←PT1553.003←MT1553.004←PT1553.005←MT1554→PT1556.007→PT1559.003→PT1565→PT1571←PT1572←MT1574←PT1574.001←M →PT1574.004←M →PT1574.005→PT1574.006→PT1574.008→PT1574.013←MT1578←PT1578.002←MT1578.004←MT1587→PT1587.001→PT1588.001←MT1601.002←MT1606.001←MT1610←PT1611→PT1612←MT1620←MT1647←PT1677←M →PT1687→PT1688←MT1689←P
Why these map — AI rationale (under review)
- T1027prevents — A.8.30's contractual requirements for secure design/coding/testing (incl. threat modeling, malicious-content and known-vulnerability checks) can stop outsourced developers from introducing the obfuscation techniques described in T1027, but this is only a slice of the technique's surface (in-house development, post-delivery obfuscation, command obfuscation, and non-development vectors remain untouched).
- T1027.009prevents — A.8.30 requires contractual secure-coding/testing mandates, threat-model sharing, malicious-content/vulnerability testing evidence, and acceptance testing on outsourced deliverables, which directly constrains the introduction of embedded-payload techniques during outsourced development; it is only a slice because the technique can still be introduced by in-house developers, non-outsourced supply-chain components, or post-delivery modifications.
- T1027.016prevents — A.8.30 requires contractual requirements for secure design/coding/testing practices (including evidence of testing against malicious content and known vulnerabilities) plus acceptance testing and audits; these directly constrain the insertion of junk code during outsourced development, but only for the slice of supply-chain code the organization actually outsources and only to the extent the contract is enforced.
- T1027.017prevents — A.8.30 requires contractual requirements for secure design/coding/testing practices, threat models, acceptance testing, evidence of vulnerability/malicious-content scanning, and audits of the supplier's development environment and processes; these directly constrain the introduction of SVG-smuggling code during outsourced development, but only for the slice of the supply chain the organization actually outsources and only to the extent the contract is enforced.
- T1056.003prevents — A.8.30 requires contractual requirements for secure design/coding/testing (8.25-8.29), threat modeling, acceptance testing, evidence of vulnerability/malicious-code testing, and secure dev environment controls, which can prevent an outsourced developer from introducing the web-portal credential-capture code; it does not reach post-compromise admin-install cases or non-outsourced development.
- T1059.007prevents — A.8.30 requires contractual secure design/coding/testing practices, threat models, acceptance testing, evidence of vulnerability/malicious-content scanning, and secure dev-environment requirements across the outsourced supply chain; this directly constrains the introduction of JS abuse vectors (e.g. malicious/obfuscated payloads) in first-party outsourced code but leaves attacker-controlled external JS, browser-hosted scripts, and non-outsourced execution untouched.
- T1068prevents — A.8.30 requires contractual requirements for secure design/coding/testing, threat modeling, acceptance testing, evidence of vulnerability/malicious-content scanning, and secure dev-environment controls on outsourced work; this prevents a slice of T1068 by reducing exploitable programming errors and vulnerable components introduced via outsourced development, but leaves the bulk (in-house code, already-shipped vulnerable drivers, BYOVD, and non-outsourced components) untouched.
- T1080prevents — A.8.30 requires contractual requirements for secure design/coding/testing practices, threat models, evidence of testing against malicious content and known vulnerabilities, and audits of the development environment; this constrains the supply-chain slice that could introduce tainted content into internal/shared repositories but leaves the remainder of post-delivery tainting, user behavior, and non-outsourced shared content untouched.
- T1127prevents — A.8.30 requires the organization to communicate, agree and enforce contractual requirements for secure design/coding/testing practices (including threat modeling, acceptance testing, evidence of vulnerability/malicious-code scanning, and secure dev environments) on outsourced development; this constrains the introduction of the signed/trusted developer utilities that adversaries later abuse for T1127, but only for first-party outsourced code and only where the contract is followed, leaving a large remainder of in-the-wild signed utilities, legacy/third-party tools, and non-outsourced developer environments.
- T1137.001prevents — A.8.30 requires contractual requirements for secure design/coding/testing (8.25-8.29), threat models, acceptance testing, evidence of vulnerability/malicious-content scanning, and development-environment security, all of which directly reduce the chance that a malicious Office-template macro is introduced into delivered software; this is a genuine but minority slice of the technique (which also covers post-compromise local template modification and registry hijacking on already-deployed systems).
- T1176.002prevents — A.8.30 requires contractual requirements for secure design/coding/testing, threat models, acceptance testing, evidence of testing against malicious content and known vulnerabilities, and secure dev environment — all of which can stop malicious IDE extensions from being developed, delivered, or installed in outsourced work, but leaves the benign-extension-abuse vector, non-outsourced IDEs, and post-delivery side-loading untouched.
- T1190prevents — A.8.30 requires the organization to impose, agree and verify secure design/coding/testing practices plus vulnerability/malicious-code evidence on outsourced developers, which stops many (but not all) exploitable weaknesses from reaching production Internet-facing applications; it does not address in-house development, already-deployed code, misconfigurations, or non-outsourced components that T1190 also targets.
- T1195prevents — Contractual mandates for secure design, coding, testing, and evidence of malicious-content and vulnerability checks directly reduce the likelihood that a supplier will deliver compromised code or components.
- T1195detects — A.8.30 requires the organization to obtain and review evidence of testing for malicious content and known vulnerabilities plus acceptance testing of deliverables, which surfaces supply-chain tampering after it has occurred but before final acceptance; this is genuine detection of a subset of T1195 vectors (especially in outsourced code) while the clause's governance/monitoring focus leaves many upstream manipulation stages (e.g. development-tool or open-source-dependency compromise) outside its view.
- T1195.001prevents — A.8.30 requires the organization to communicate, agree and enforce security requirements (including secure design/coding/testing, threat models, evidence of testing for malicious content/vulnerabilities, audits, and development-environment controls) on outsourced development and the supply chain; this directly constrains the adversary's ability to manipulate dependencies, tools, or CI/CD components before delivery, but remains partial because the control only governs what the organization can contractually impose on its own suppliers and cannot stop upstream/open-source compromises, typosquatting, or attacks on non-contracted public ecosystems that the technique also targets.
- T1195.002prevents — A.8.30 requires the organization to communicate, agree and monitor contractual requirements for secure design/coding/testing, threat models, evidence of testing against malicious content and known vulnerabilities, and audit rights; this constrains the attack surface for source-code and build manipulation in outsourced development but does not stop all supply-chain vectors (e.g. upstream third-party components, distribution mechanisms, or non-outsourced suppliers).
- T1199prevents — A.8.30 requires the organization to set, communicate, agree, and monitor security requirements (including secure design/coding/testing, threat modeling, vulnerability/malicious-code testing, and audit rights) across the outsourced development supply chain; this directly constrains the subset of T1199 that arises from poorly secured outsourced development relationships, but leaves the bulk of the technique (e.g., compromise of non-development third-party IT, MSP, physical-plant, or reseller accounts) untouched.
- T1203prevents — A.8.30 requires contractual requirements for secure design/coding/testing, threat models, evidence of vulnerability/malicious-content testing, and audits across the outsourced supply chain; this directly constrains the unsecure coding practices named in T1203's description and thereby prevents many (but not all) exploitable client-application vulnerabilities from reaching production.
- T1204.005prevents — A.8.30 requires contractual requirements for secure design/coding/testing, threat models, evidence of testing against malicious content and known vulnerabilities, and supply-chain oversight; this constrains the upstream introduction of malicious libraries (including uploaded or backdoored ones) in outsourced development but does not stop external actors from uploading to public repositories or typosquatting on libraries installed by end-users outside the outsourced chain.
- T1210prevents — A.8.30 requires contractual security requirements, threat modeling, secure design/coding/testing practices, vulnerability evidence, and malicious-content testing for outsourced development; this reaches the introduction of exploitable remote-service vulnerabilities in in-house or supplier-built software but leaves a bounded remainder (COTS/third-party remote services, unpatched legacy systems, and post-delivery configuration/patching outside the development contract).
- T1211prevents — A.8.30 requires contractual secure design/coding/testing, threat modeling, vulnerability/malicious-code testing evidence, and audits across the outsourced supply chain; this directly lowers the chance that exploitable flaws (the root of T1211) are delivered into production, but only for first-party outsourced development and leaves in-house, COTS, and post-delivery vulnerabilities untouched.
- T1212prevents — A.8.30 requires contractual secure design/coding/testing, threat modeling, vulnerability/malicious-code testing evidence, and audits across the outsourced supply chain; this directly lowers the chance that exploitable credential-access vulnerabilities are introduced into delivered software, but does not guarantee their absence and leaves in-house or non-outsourced code untouched.
- T1499.004prevents — A.8.30 requires contractual requirements for secure design/coding/testing, threat modeling, vulnerability/malicious-code testing evidence, and audits across the outsourced supply chain; this prevents many (but not all) exploitable vulnerabilities from reaching production, especially zero-days or those outside the contract's rigor.
- T1505prevents — A.8.30 requires the organization to communicate, agree and enforce secure design/coding/testing practices, threat models, acceptance testing, vulnerability/malicious-code scanning evidence, and audit rights across the outsourced supply chain; this directly constrains the introduction of malicious extensible server components (the core of T1505) in outsourced development, but only for the outsourced slice rather than all server software and without guaranteeing complete enforcement or coverage of in-house or already-deployed components.
- T1505.001prevents — A.8.30 requires the organization to communicate, agree and monitor secure design/coding/testing practices plus evidence of testing for malicious content and known vulnerabilities in outsourced development, which directly constrains the crafting of malicious stored procedures or CLR assemblies during outsourced work but leaves in-house development, post-delivery changes, and non-outsourced environments untouched.
- T1505.002prevents — A.8.30 requires contractual requirements for secure design/coding/testing (8.25-8.29), threat models, acceptance testing, evidence of vulnerability/malicious-content scanning, and audit rights over the outsourced development process that produces the transport agent; this constrains the introduction of a malicious one but does not reach the registration/activation step performed by an already-privileged insider or post-delivery administrator on an Exchange server.
- T1505.003prevents — A.8.30 requires contractual requirements for secure design/coding/testing, threat modeling, acceptance testing, evidence of vulnerability/malicious-code scanning, and audit rights; these directly constrain the introduction of web shells during outsourced development of the affected web servers, but only for first-party outsourced code (not post-deployment adversary placement, third-party components, or non-outsourced development).
- T1525prevents — A.8.30 requires contractual requirements for secure design/coding/testing (8.25-8.29), threat models, acceptance testing, evidence of vulnerability/malicious-content scanning, and audit rights over the outsourced development process; these directly constrain the supply-chain steps that would otherwise allow an adversary to implant a backdoored image, but only for development that the organization itself outsources (the technique can still be performed by an internal actor or by an un-contracted external party).
- T1528prevents — A.8.30 requires contractual secure-design/coding/testing practices, threat modeling, acceptance testing, evidence of vulnerability/malicious-content scanning, and secure dev-environment requirements across the outsourced supply chain; this directly constrains the CI/CD-pipeline and container-development vectors named in T1528 (and the malicious-app-registration vector when the app itself is developed externally), but leaves social-engineering OAuth flows, post-compromise token theft from already-deployed IaaS/identity-provider resources, and non-outsourced development untouched.
- T1546.011prevents — A.8.30 requires contractual secure design/coding/testing, threat models, malicious-content/vulnerability testing, and audits across the outsourced supply chain; this constrains (and can stop) malicious shim insertion during outsourced development but does not reach in-house shim abuse or post-delivery installation.
- T1546.016prevents — A.8.30 requires contractual requirements for secure design/coding/testing (8.25-8.29), threat models, acceptance testing, evidence of vulnerability/malicious-content testing, and audit rights over the outsourced supply chain; this directly constrains the developer modification of installer scripts that realises T1546.016, but only for first-party outsourced development — it does not reach adversary-supplied third-party packages, compromised legitimate installers in the supply chain, or post-delivery abuse.
- T1547.006prevents — A.8.30 requires contractual secure-design/coding/testing mandates, threat-model sharing, malicious-code/vulnerability testing evidence, and audit rights over outsourced development; this constrains how an LKM/kext rootkit could be introduced by a supplier but leaves the technique executable via in-house modification, compromised build pipelines, or non-outsourced code.
- T1552.001prevents — A.8.30 requires contractual requirements for secure design/coding/testing (8.25-8.29), threat modeling, acceptance testing, evidence of vulnerability/malicious-content scanning, and secure dev environment controls, all of which can stop insecure credential storage from being introduced into outsourced code or configs; this is only a slice of the technique (development-time insertion into source/configs) and leaves runtime/user-created files, backups, container logs, and non-outsourced cases untouched.
- T1554prevents — A.8.30 requires contractual requirements for secure design/coding/testing (8.25-8.29), threat models, acceptance testing, evidence of vulnerability/malicious-content scanning, and audit rights over the outsourced development process; this constrains the supply-chain introduction of backdoored or patched binaries but reaches only a slice (development-phase prevention) of an adversary technique that also includes post-deployment modification of installed binaries on the victim host.
- T1556.007prevents — A.8.30 requires contractual requirements for secure design/coding/testing (8.25-8.29), threat models, acceptance testing, evidence of testing against malicious content/vulnerabilities, and audit rights over the outsourced development of hybrid identity components; this constrains the backdooring technique when performed by external developers but leaves internal on-prem/cloud modifications, misconfigurations, and non-outsourced code untouched.
- T1559.003prevents — A.8.30 requires contractual requirements for secure design/coding/testing (including input sanitization, threat modeling, and evidence of testing for malicious content/vulnerabilities), which directly targets the improper validation and poor sanitization that enable T1559.003; this constrains the technique in outsourced macOS development but is not universal (in-house code, non-outsourced components, or weak enforcement leave a large remainder).
- T1565prevents — A.8.30 requires contractual secure design/coding/testing, threat modeling, acceptance testing, evidence of vulnerability/malicious-content scanning, and development-environment security across the outsourced supply chain; these directly constrain the introduction of data-manipulation logic or backdoors during outsourced development, but only for first-party outsourced code (not post-delivery runtime manipulation, third-party components, or insider threats after deployment).
- T1574.001prevents — A.8.30 requires contractual requirements for secure design/coding/testing (8.25-8.29), threat models, acceptance testing, evidence of vulnerability/malicious-content scanning, and secure dev-environment controls, all of which can stop outsourced code from introducing the insecure DLL loading, search-order, or sideloading logic that enables T1574.001; it reaches only the outsourced slice and does not constrain in-house development or already-deployed software.
- T1574.004prevents — A.8.30 requires contractual requirements for secure design/coding/testing (8.25-8.29), threat models, acceptance testing, evidence of testing against malicious content and known vulnerabilities, and secure development environment requirements; these directly address the insecure search-path and weak-linking practices that enable dylib hijacking when development is outsourced, but only for the outsourced slice and without mandating specific loader-hardening mechanisms.
- T1574.005prevents — A.8.30 requires the organization to communicate, agree and enforce contractual requirements for secure design/coding/testing (including secure development environment, threat modeling, acceptance testing, evidence of vulnerability/malicious-content scanning) on outsourced developers; this directly constrains the insecure file/directory permission and installer-unpacking practices that enable T1574.005, but only for the outsourced slice of the supply chain and only as a governance requirement whose actual preventive effect depends on downstream implementation rigor.
- T1574.006prevents — A.8.30 requires contractual requirements for secure design/coding/testing practices (8.25-8.29), threat models, acceptance testing, evidence of testing against malicious content and known vulnerabilities, and secure development environment requirements; these reach a slice of the developer practices that could stop unsafe use or exposure of LD_PRELOAD/DYLD_INSERT_LIBRARIES but do not mandate or enforce the specific linker-hardening, library whitelisting, or runtime controls that close the technique.
- T1574.008prevents — A.8.30 requires contractual secure design/coding/testing practices, threat modeling, acceptance testing, and evidence of vulnerability/malicious-content scanning in outsourced development; this can stop vulnerable code (lacking full paths) from being delivered, but does not guarantee complete elimination of the flaw class across all outsourced components or non-development supply-chain vectors.
- T1587prevents — A.8.30 mandates that the organization impose and verify secure-development, testing, threat-model and malicious-code requirements on any outsourced development; when the adversary is the organization outsourcing to a contractor this directly constrains the contractor's ability to deliver the malicious capability the adversary shaped, preventing the T1587 technique in that outsourced slice (the in-house development slice and any contractor that evades or is exempted from the controls remain).
- T1587.001prevents — A.8.30 requires the organization to communicate, agree and monitor secure development/testing requirements (including threat models, evidence of testing for malicious content/vulnerabilities, and secure practices) when outsourcing development; this constrains an adversary's outsourced malware development by forcing defensive requirements into the supply chain, but only reaches the legitimate-outsourcing slice of the technique (in-house development and adversary-controlled malicious contractors remain untouched).
- T1611prevents — A.8.30 requires contractual requirements for secure design/coding/testing, threat models, acceptance testing, evidence of vulnerability/malicious-content testing, and secure dev-environment controls, which can prevent many container-escape misconfigurations and vulns from reaching production; it does not itself enforce runtime isolation, kernel hardening, or correct hypervisor configuration on the delivered system.
- T1677detects — A.8.30 requires evidence of sufficient testing to guard against malicious content and known vulnerabilities plus acceptance testing and monitoring of outsourced deliverables, which can surface poisoned pipeline artifacts in the received build but does not instrument or observe the CI/CD build process itself.
- T1677prevents — A.8.30 requires the organization to communicate, agree and enforce contractual requirements for secure design/coding/testing practices, threat models, evidence of testing against malicious content and known vulnerabilities, and security of the development environment across the outsourced supply chain; this directly constrains the Direct, Indirect and (via contractual flow-down) Public pipeline poisoning scenarios when the CI/CD pipeline itself is part of outsourced development, but leaves a large remainder where the pipeline is internal, the adversary is an insider, or the contract is not enforced.
- T1687prevents — A.8.30 requires contractual security practices, threat modeling, testing/evidence for vulnerabilities and malicious code, and audits across the outsourced supply chain; this prevents many exploitable flaws from reaching production defensive components, but leaves a bounded remainder (unpatched 0-days, insider threats in the supplier, or non-outsourced in-house defensive code).
Prevented OWASP Web Top 10 (2025) risks (16)
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 — Contractual requirements, acceptance testing, evidence of secure practices and audits (points b,d,e,f,g,i) can reduce the realized impact or likelihood of broken access control defects reaching production, but do not bound or change the consequence of any that still ship.
- A03mitigates — A.8.30 requires contractual requirements, evidence of testing against malicious content/vulnerabilities, acceptance testing, and monitoring of the supply chain; this bounds the realized impact of vulnerable/outdated/compromised dependencies and pipelines (the A03 class) without eliminating the underlying weakness itself.
- A05mitigates — Contractual requirements, acceptance testing, evidence of testing against malicious content/vulnerabilities, and monitoring can limit the successful exploitation or impact of injection flaws in outsourced code, but do not address the realized weakness itself.
- A06mitigates — A.8.30 requires communicating secure design expectations, threat modeling, acceptance testing for quality/accuracy, and evidence of security capabilities, which can bound the realized impact of baked-in design flaws without removing the architectural weakness itself.
- A06prevents — A.8.30 requires the organization to communicate, agree and enforce secure design requirements (including threat modeling) on outsourced developers, which directly prevents design-level weaknesses from being baked into the delivered architecture for the slice of development that is outsourced.
- A08mitigates — Contractual requirements, acceptance testing, evidence of testing against malicious content/vulnerabilities, and monitoring reduce the likelihood or impact of unverified/integrity-failed code or data reaching production, but do not bound or address the dominant technical failure modes (e.g. insecure deserialization logic, unsigned updates in deployment, or CI/CD pipeline compromise) once delivered.
- A08prevents — A.8.30 requires contractual requirements for secure design/coding/testing (8.25-8.29), threat models, acceptance testing, evidence of vulnerability/malicious-content testing, and audit rights, which directly target the integrity failures named in A08:2025 and thereby prevent many (but not all) such defects from reaching production.
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.