A.8.30 Technological
Outsourced development
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 (11)
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.
Aligned NIST CSF 2.0 outcomes (12)
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.
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-1103partialmitigates — Outsourced development controls can enforce platform-portability requirements on third-party deliverables.
- CWE-111partialprevents — Outsourced development contracts can require safe JNI practices, though the weakness itself is not addressed by the control.
- CWE-1357partialprevents — Outsourced-development controls address third-party code/components that may be insufficiently trusted.
- CWE-200partialprevents — 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-284partialprevents — 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-434partialprevents — 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-74partialprevents — Outsourced development agreements can require injection-prevention practices from suppliers.
- CWE-798partialprevents — 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-862partialprevents — 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-943partialprevents — Outsourced development agreements can require secure coding practices, indirectly mitigating the weakness.
Mitigated MITRE ATT&CK techniques (7)
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)
- T1195mostlyprevents — 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.
- T1059nonemitigates — Requiring secure coding and testing standards for outsourced development limits the introduction of backdoors or malicious scripts that could later be executed via command interpreters.
- T1195.001nonemitigates — Requiring evidence that testing has been performed to detect malicious or vulnerable dependencies limits the adversary’s ability to insert malicious code into third-party libraries or build tools.
- T1588nonemitigates — Requiring the supplier to demonstrate that known vulnerabilities have been tested for and mitigated limits the adversary’s ability to obtain or weaponize publicly known exploits against the delivered product.
- T1588.006nonemitigates — Mandating that external developers apply known-vulnerability testing and provide assurance reports reduces the chance that publicly known exploits will be present in delivered software.
- T1608nonemitigates — Audit rights and acceptance testing for malicious content make it harder for an adversary to stage or upload compromised code or tools into the organization’s supply chain.
- T1608.001nonemitigates — Contractual rights to audit development processes and to receive evidence of secure coding practices make it harder for an adversary to stage and upload malicious artifacts into the supply chain.
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.