Cyber Resilience

← ISO 27001 Annex A

A.8.25 Technological

Secure development life cycle

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

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

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

AT-3←P →P CM-2→P SA-10←M SA-11←M →M SA-15←M →M SA-17←M →P SA-4←P SA-8←P →P SA-3gov

Why these map — AI rationale (under review)

SA-11mostlyaligns with — Both mandate security testing activities such as code review, vulnerability scanning, and penetration testing during development.
SA-15mostlyaligns with — Both require the use of secure development processes, standards, and tools to produce secure software and systems.
AT-3partialaligns with — Both require role-based security training for developers to ensure they can identify and remediate vulnerabilities.
CM-2partialaligns with — Both address the need for secure baseline configurations and controlled repositories for source code and system components.
SA-17partialaligns with — Both require security architecture and design considerations to be addressed during the development life cycle.
SA-8partialaligns with — Both embed security and privacy engineering principles into the development process to reduce vulnerabilities.
SA-3noneimplements — Both controls establish a secure development life cycle that integrates security requirements, testing, and controls across all phases of system creation.

Aligned NIST CSF 2.0 outcomes (11)

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

GV.SC-05←M →P ID.IM-02←P →P ID.RA-09→M PR.AT-02←M →M PR.IR-01←P PR.PS-01←M PR.PS-06←F →F

Why these map — AI rationale (under review)

PR.PS-06fullcovers — The ISO control mandates embedding security requirements, testing, and developer training throughout the software development lifecycle, which directly fulfills the CSF outcome of integrating and monitoring secure development practices.
ID.RA-09mostlyaligns with — Requiring security checkpoints, code scanning, and penetration testing before release ensures the authenticity and integrity of software are assessed prior to acquisition and use.
PR.AT-02mostlyaligns with — The control explicitly calls for application-security knowledge, training, and developer capability to prevent, find, and fix vulnerabilities, matching the CSF requirement for specialized-role awareness and training.
GV.SC-05partialaligns with — When development is outsourced, the control requires the organization to obtain assurance that the supplier follows its secure-development rules, which corresponds to establishing and integrating cybersecurity requirements into supplier contracts.
ID.IM-02partialaligns with — Security testing, regression testing, and penetration testing performed during development generate findings that the organization can use to identify improvements, aligning with the CSF outcome of sourcing improvements from security tests and exercises.

Related OWASP ASVS 5.0 requirements (14)

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

V15.1.1←M →P V15.1.2←M →P V15.1.5←P V15.2.1←M →P V15.2.4→P V15.2.5←P →P V15.3.2→P V15.3.3→P V15.3.5→P V2.1.1←P

Why these map — AI rationale (under review)

V15.1.1partialaligns with — The ISO control's emphasis on security checkpoints, testing, and remediation timelines in the development lifecycle directly supports the ASVS requirement for documented risk-based remediation time frames for vulnerable third-party components.
V15.1.2partialaligns with — Requiring secure repositories and version control under the ISO control aligns with the ASVS mandate to maintain an inventory of third-party libraries and their versions as part of secure development governance.
V15.2.1partialaligns with — The ISO control's requirement for developers to prevent, find, and fix vulnerabilities supports the ASVS expectation that no components remain in production beyond their documented remediation time frames.
V15.2.4partialaligns with — Secure source-code repositories and version-control practices in the ISO control align with the ASVS requirement that third-party components and transitive dependencies come only from expected, approved repositories.
V15.2.5partialaligns with — The ISO control's call for secure coding guidelines and developer training corresponds to the ASVS requirement for additional protections around documented dangerous functionality.
V15.3.2partialaligns with — Secure development practices and testing checkpoints in the ISO control align with the ASVS requirement that backend calls to external URLs do not follow redirects unless explicitly intended.
V15.3.3partialaligns with — The ISO control's secure-coding guidelines and developer capability expectations support the ASVS requirement to implement countermeasures against mass-assignment attacks by limiting allowed fields.
V15.3.5partialaligns with — Requiring secure coding guidelines and developer training under the ISO control aligns with the ASVS expectation that the application enforces correct variable types and strict equality/comparator operations.

Related weaknesses / CWE (915)

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

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

CWE-1007←P CWE-102←P →P CWE-1022←P →P CWE-1024←P →P CWE-1025←P →P CWE-1037←P →P CWE-1038←P →P CWE-1039←P →P CWE-1049←P →P CWE-1050→P CWE-1051←P →P CWE-1055←P →P CWE-1057←P →P CWE-1058←P →P CWE-1059←P →P CWE-1066←P →P CWE-1067←P →P CWE-1068←P →P CWE-1072→P CWE-1076←P →P CWE-1078→P CWE-1083←P →P CWE-1088←P →P CWE-1091←P →P CWE-11←P →P CWE-1100→P CWE-1102←P →P CWE-1103←P CWE-1106→P CWE-1107←P →P CWE-1108←P →P CWE-111←P →P CWE-1112←P CWE-1113→P CWE-1116←P →P CWE-1118←P →P CWE-1119→P CWE-112←P →P CWE-1124←P →P CWE-1125←P →P CWE-113←P →P CWE-114←P →P CWE-115←P →P CWE-116←P →P CWE-1164←P →P CWE-117→P CWE-1173←P →P CWE-1174←P →P CWE-1176←P CWE-118←P →P CWE-119←P →P CWE-1191→P CWE-12←P →P CWE-120←P →P CWE-1204→P CWE-121←P →P CWE-122←P →P CWE-1221←P →P CWE-1223←P →P CWE-1224←P →P CWE-123←P →P CWE-1231←P →P CWE-1236←P →P CWE-124←P →P CWE-1240←P →P CWE-1241→P CWE-1242←P →P CWE-1244←P →P CWE-1245←P →P CWE-1246←P →P CWE-125←P →P CWE-1250←P →P CWE-1254←P →P CWE-126←P →P CWE-1264←P →P CWE-1265←P →P CWE-1269←P →P CWE-127←P →P CWE-1270←P →P CWE-1272→P CWE-128←P →P CWE-1281←P →P CWE-1282←P →P CWE-1284←P →P CWE-1285←P →P CWE-1286←P →P CWE-1287←P →P CWE-1288←P →P CWE-129←P →P CWE-1291←P →P CWE-1298←P →P CWE-130←P →P CWE-131←P →P CWE-1310→P CWE-1320←P →P CWE-1321←P →P CWE-1322←P →P CWE-1325←P →P CWE-1328→P CWE-1329←P →P CWE-1333←P →P CWE-1335←P →P CWE-1336←P →P CWE-134←P →P CWE-1341←P →P CWE-135←P →P CWE-1357→P CWE-138←P →P CWE-1386←P →P CWE-1389←P →P CWE-1391←P →P CWE-14→P CWE-140→P CWE-141←P →P CWE-142←P →P CWE-143←P →P CWE-144←P →P CWE-145←P →P CWE-146←P →P CWE-147←P →P CWE-148←P →P CWE-149←P →P CWE-150←P →P CWE-153←P →P CWE-154←P →P CWE-155←P →P CWE-156←P →P CWE-157←P →P CWE-158←P →P CWE-159←P →P CWE-160←P →P CWE-162←P →P CWE-164←P →P CWE-166←P →P CWE-167←P →P CWE-168←P →P CWE-170←P →P CWE-172←P →P CWE-176←P →P CWE-177→P CWE-178←P →P CWE-179←P →P CWE-180←P →P CWE-182←P →P CWE-185←P →P CWE-186←P →P CWE-187←P →P CWE-188←P →P CWE-190←P →P CWE-191←P →P CWE-192←P →P CWE-193←P →P CWE-194←P →P CWE-195←P →P CWE-196←P →P CWE-197←P →P CWE-198←P →P CWE-20→P CWE-200→P CWE-201←P →P CWE-204←P →P CWE-205←P →P CWE-207→P CWE-209←P →P CWE-210←P CWE-212←P →P CWE-215←P →P CWE-219←P →P CWE-22←P →P CWE-226→P CWE-228←P →P CWE-229←P →P CWE-23←P →P CWE-231←P →P CWE-232←P →P CWE-233←P →P CWE-234←P →P CWE-235←P →P CWE-236←P →P CWE-237←P →P CWE-239←P →P CWE-24←P →P CWE-240←P →P CWE-241←P →P CWE-242←P →P CWE-244→P CWE-248←P →P CWE-25←P →P CWE-252←P →P CWE-253←P →P CWE-257←P →P CWE-258→P CWE-26←P →P CWE-267→P CWE-27←P →P CWE-270←P →P CWE-271→P CWE-274→P CWE-277←P →P CWE-278←P →P CWE-28←P →P CWE-280→P CWE-284→P CWE-287→P CWE-288→P CWE-290←P →P CWE-30←P →P CWE-302←P →P CWE-303←P →P CWE-304→P CWE-305→P CWE-31←P →P CWE-316→P CWE-318→P CWE-32←P →P CWE-325→P CWE-329→P CWE-330→P CWE-331→P CWE-332→P CWE-336←P →P CWE-337←P →P CWE-338→P CWE-34←P →P CWE-340→P CWE-341→P CWE-342→P CWE-343→P CWE-344←P →P CWE-345→P CWE-349←P →P CWE-35←P →P CWE-351←P →P CWE-356←P →P CWE-357←P →P CWE-358←P →P CWE-36←P →P CWE-362←P →P CWE-363←P →P CWE-364←P →P CWE-366←P →P CWE-368←P →P CWE-369←P →P CWE-372←P →P CWE-374←P →P CWE-377←P →P CWE-378←P →P CWE-38←P →P CWE-384→P CWE-386←P →P CWE-390←P →P CWE-391←P →P CWE-392←P →P CWE-393←P →P CWE-394←P →P CWE-396→P CWE-401←P →P CWE-403←P →P CWE-407←P →P CWE-409→P CWE-41←P →P CWE-412→P CWE-413←P →P CWE-414←P →P CWE-415←P →P CWE-416←P →P CWE-421←P →P CWE-422←P →P CWE-424←P →P CWE-425→P CWE-428←P →P CWE-43←P →P CWE-430←P →P CWE-431←P →P CWE-433←P →P CWE-434→P CWE-435←P →P CWE-436←P →P CWE-437←P →P CWE-440←P →P CWE-441←P →P CWE-444←P →P CWE-446←P →P CWE-447←P →P CWE-448←P →P CWE-449←P →P CWE-450←P →P CWE-451←P →P CWE-453←P →P CWE-454←P →P CWE-455←P →P CWE-456←P →P CWE-457←P →P CWE-459←P →P CWE-460←P →P CWE-462←P →P CWE-463←P →P CWE-466←P →P CWE-467→P CWE-468←P →P CWE-469←P →P CWE-470←P →P CWE-471→P CWE-472←P →P CWE-473←P →P CWE-474←P →P CWE-475←P →P CWE-476←P →P CWE-477←P →P CWE-478→P CWE-479←P →P CWE-482→P CWE-484→P CWE-488←P →P CWE-489←P →P CWE-491←P →P CWE-495←P →P CWE-499←P →P CWE-50←P →P CWE-501←P →P CWE-507←P →P CWE-511←P →P CWE-520→P CWE-526←P →P CWE-531←P →P CWE-535←P →P CWE-539←P →P CWE-540←P →P CWE-541←P →P CWE-544←P →P CWE-547←P →P CWE-548←P →P CWE-550←P →P CWE-551←P →P CWE-553←P →P CWE-561←P →P CWE-562←P →P CWE-564←P →P CWE-567←P →P CWE-57←P →P CWE-570←P →P CWE-571←P →P CWE-573←P →P CWE-587←P →P CWE-588←P →P CWE-59←P →P CWE-590←P →P CWE-597←P →P CWE-6→P CWE-600←P →P CWE-602←P →P CWE-606←P →P CWE-610←P →P CWE-611←P →P CWE-615←P →P CWE-616←P →P CWE-617←P →P CWE-618←P →P CWE-621←P →P CWE-622←P →P CWE-623←P →P CWE-624←P →P CWE-625←P →P CWE-626←P →P CWE-627←P →P CWE-628←P →P CWE-637←P →P CWE-639→P CWE-640→P CWE-641←P →P CWE-642→P CWE-643←P →P CWE-644←P →P CWE-646←P →P CWE-648←P →P CWE-652←P →P CWE-657←M →P CWE-66←P →P CWE-662←P →P CWE-663←P →P CWE-664←P →P CWE-665←P →P CWE-667←P →P CWE-669←P →P CWE-67→P CWE-670←P →P CWE-674←P →P CWE-675←P →P CWE-676←P →P CWE-680←P →P CWE-681←P →P CWE-682←P →P CWE-683→P CWE-684←P →P CWE-686←P →P CWE-687←P →P CWE-688←P →P CWE-689←P →P CWE-690←P →P CWE-691←P →P CWE-692→P CWE-694→P CWE-695←P →P CWE-696←P →P CWE-697←P →P CWE-698←P →P CWE-704←P →P CWE-705←P →P CWE-706←P →P CWE-707←P →P CWE-710←P →P CWE-73←P →P CWE-733←P →P CWE-74←P →P CWE-749←P →P CWE-75←P →P CWE-754←P →P CWE-755←P →P CWE-756←P →P CWE-757→P CWE-758←P →P CWE-759→P CWE-76←P →P CWE-760→P CWE-761→P CWE-762←P →P CWE-763←P →P CWE-764←P →P CWE-765←P →P CWE-767←P →P CWE-768←P →P CWE-77←P →P CWE-771←P →P CWE-772←P →P CWE-774←P →P CWE-775←P →P CWE-776←P →P CWE-782→P CWE-783←P →P CWE-786←P →P CWE-787←P →P CWE-788←P →P CWE-789←P →P CWE-79→P CWE-790←P →P CWE-791→P CWE-792←P →P CWE-794←P →P CWE-80←P →P CWE-805←P →P CWE-81←P →P CWE-820←P →P CWE-821←P →P CWE-822←P →P CWE-823←P →P CWE-824←P →P CWE-825←P →P CWE-826←P →P CWE-827←P →P CWE-828←P →P CWE-83←P →P CWE-832←P →P CWE-833←P →P CWE-834←P →P CWE-835←P →P CWE-837←P →P CWE-838←P →P CWE-839←P →P CWE-84→P CWE-841←P →P CWE-843←P →P CWE-86←P →P CWE-862→P CWE-87←P →P CWE-88←P →P CWE-89→P CWE-90←P →P CWE-908←P →P CWE-909←P →P CWE-91←P →P CWE-910←P →P CWE-911←P →P CWE-912←P →P CWE-913←P →P CWE-914←P →P CWE-915←P →P CWE-917←P →P CWE-93←P →P CWE-941→P CWE-943←P →P CWE-95←P →P CWE-96←P →P CWE-97←P →P CWE-98←P →P CWE-99←P →P

Why these map — AI rationale (under review)

CWE-102partialprevents — Secure SDLC practices reduce duplicate-form validation errors through design and code review.
CWE-1022partialprevents — Secure development lifecycle processes require design and code reviews that should identify missing rel="noopener" or target="_blank" mitigations.
CWE-1024partialprevents — Secure development life cycle mandates type-safe coding practices that reduce incompatible-type comparisons.
CWE-1025partialprevents — Secure development lifecycle includes requirements and reviews that can catch incorrect comparison logic.
CWE-1037partialprevents — Secure development lifecycle requires compiler/optimization settings that preserve security-critical code.
CWE-1038partialprevents — Secure development lifecycle mandates review of automated build/optimization steps that could introduce security side-effects.
CWE-1039partialprevents — Secure development lifecycle requires adversarial testing and robustness validation for ML-based recognition components.
CWE-1049partialprevents — Secure development lifecycle requires design and code reviews that can catch excessive joins before deployment.
CWE-1050partialprevents — Secure SDLC processes can catch the weakness during reviews but do not inherently prevent it.
CWE-1051partialprevents — Secure development life cycle requires avoiding hard-coded secrets and network identifiers during design and coding.
CWE-1055partialprevents — Secure development life cycle requires design reviews that can catch problematic inheritance patterns.
CWE-1057partialprevents — Secure SDLC mandates use of approved data-access components and prevents ad-hoc direct access.
CWE-1058partialprevents — Secure development lifecycle mandates thread-safety reviews that can catch non-final static fields in multi-threaded code.
CWE-1059partialprevents — Secure SDLC mandates artefacts such as architecture and interface documentation.
CWE-1066partialprevents — Secure development lifecycle requires proper serialization handling to avoid missing control elements.
CWE-1067partialprevents — Secure development lifecycle requires performance and query-efficiency reviews that can catch missing indexes.
CWE-1068partialprevents — Secure SDLC mandates that implementation matches documented design artifacts, catching the inconsistency early.
CWE-1072partialprevents — Secure development life cycle can include architectural guidance on connection pooling but does not specifically enforce it.
CWE-1076partialprevents — Secure SDLC processes typically enforce coding and design conventions.
CWE-1078partialprevents — Secure development life cycle includes coding standards, but style enforcement is only one small part of the control.
CWE-1083partialprevents — A secure development life cycle mandates that all data access paths be routed through the approved data manager component.
CWE-1088partialprevents — Secure SDLC practices require timeout handling for external calls, directly addressing the missing timeout.
CWE-1091partialprevents — Secure SDLC practices can mandate proper resource-cleanup patterns that prevent missing destructor calls.
CWE-11partialprevents — Secure development life cycle mandates removal of debug symbols and verbose error handling before deployment.
CWE-1100partialprevents — Secure development life cycle processes encourage modular design but do not specifically address isolation of system-dependent functions.
CWE-1102partialprevents — Secure development life cycle mandates portable, architecture-independent coding practices that reduce reliance on machine-specific data representations.
CWE-1106partialprevents — Secure SDLC processes encourage consistent coding practices that reduce literal constants.
CWE-1107partialprevents — Secure development life cycle requires centralized, well-managed definitions that reduce scattered symbolic constants.
CWE-1108partialprevents — Secure SDLC practices discourage global state by enforcing modular design and encapsulation.
CWE-111partialprevents — Secure SDLC mandates review of native/JNI interfaces, reducing exposure to unsafe foreign code.
CWE-1113partialprevents — Secure SDLC includes coding standards enforcement that may indirectly address comment style.
CWE-1116partialprevents — Secure development life cycle includes code review and documentation standards that reduce inaccurate comments.
CWE-1118partialprevents — Secure development life cycle requires documentation of error-handling techniques.
CWE-1119partialprevents — Secure SDLC processes include code-quality gates that can catch excessive branching, but the control itself does not prescribe coding style.
CWE-112partialprevents — Secure development lifecycle mandates input validation and schema enforcement for untrusted XML.
CWE-1124partialprevents — Secure development life cycle mandates code reviews and design rules that can catch or prevent excessive nesting.
CWE-1125partialprevents — Secure SDLC practices include attack-surface reduction reviews during design and release.
CWE-113partialprevents — Secure development lifecycle mandates input validation and output encoding that directly prevents CRLF injection into HTTP headers.
CWE-114partialmitigates — Secure development lifecycle practices include controls on external code and command execution paths.
CWE-115partialprevents — Secure development lifecycle mandates input validation and canonicalization that directly prevent misinterpretation of inputs.
CWE-116partialprevents — Secure development life cycle mandates output encoding/escaping practices that directly prevent improper encoding.
CWE-1164partialprevents — Secure SDLC mandates code reviews and clean-up that remove dead/irrelevant code.
CWE-117partialprevents — Secure SDLC includes coding standards that reduce log-related weaknesses but does not specifically address logging.
CWE-1173partialprevents — Secure development life cycle mandates use of approved validation frameworks and libraries.
CWE-1174partialprevents — Secure development life cycle mandates validation of input models to prevent improper handling.
CWE-118partialprevents — Secure development lifecycle includes input validation and bounds checking that can prevent range errors.
CWE-119partialprevents — Secure development lifecycle mandates memory-safety practices that directly prevent buffer-boundary violations.
CWE-1191partialprevents — Secure SDLC encourages hardware security requirements but does not mandate debug-port controls.
CWE-12partialprevents — Secure development life cycle includes configuration hardening and error-handling requirements.
CWE-120partialprevents — Secure development life cycle mandates processes that can include input validation and bounds checking to prevent buffer overflows.
CWE-1204partialprevents — Secure SDLC processes can embed cryptographic standards and reviews that catch weak IV generation.
CWE-121partialprevents — Secure SDLC mandates buffer-safety practices that directly prevent stack overflows.
CWE-122partialprevents — Secure development lifecycle mandates practices that reduce the likelihood of introducing heap overflows.
CWE-1221partialprevents — Secure development life cycle requires review and validation of hardware design parameters to prevent insecure defaults.
CWE-1223partialprevents — Secure development lifecycle practices can include hardware design reviews that detect write-once register race conditions.
CWE-1224partialprevents — Secure development lifecycle includes hardware design reviews that can catch improper sticky-bit implementation.
CWE-123partialprevents — Secure development lifecycle practices directly reduce the likelihood of write-what-where flaws such as buffer overflows.
CWE-1231partialprevents — Secure development life cycle can require lock-bit immutability in design, yet does not ensure the implemented hardware prevents later changes.
CWE-1236partialprevents — Secure SDLC mandates input validation and output encoding that directly prevents formula injection in CSV exports.
CWE-124partialprevents — Secure SDLC mandates input validation and bounds checking that directly prevent buffer underflow.
CWE-1240partialprevents — Secure SDLC requires vetted crypto libraries and standards, reducing risky custom implementations.
CWE-1241partialprevents — Secure SDLC requires vetted RNG components, reducing likelihood of predictable algorithms.
CWE-1242partialprevents — Secure development life cycle requires documented design and review, reducing hidden or undocumented features.
CWE-1244partialprevents — Secure development lifecycle can include debug interface design reviews but does not guarantee correct access-level assignment.
CWE-1245partialprevents — Secure development lifecycle includes hardware design reviews that can catch FSM flaws.
CWE-1246partialprevents — Secure development life cycle requires design-time consideration of hardware constraints such as wear-leveling in limited-write NVM.
CWE-125partialprevents — Secure development life cycle mandates input validation and bounds checking that directly prevent out-of-bounds reads.
CWE-1250partialprevents — Secure SDLC practices can include consistency requirements yet do not specifically mandate distributed-state synchronization.
CWE-1254partialprevents — Secure development lifecycle processes can require constant-time comparison functions to prevent timing side-channels.
CWE-126partialprevents — Secure SDLC mandates input validation and bounds checking that can prevent buffer over-reads.
CWE-1264partialprevents — Secure development lifecycle practices can catch insecure hardware control/data channel synchronization during design and verification.
CWE-1265partialprevents — Secure SDLC practices can include reentrancy analysis and design rules that reduce the likelihood of nested non-reentrant calls.
CWE-1269partialprevents — Secure development life-cycle practices include release-gate checks that catch non-release configurations.
CWE-127partialprevents — Secure SDLC mandates input validation and bounds checking that can prevent buffer under-reads.
CWE-1270partialprevents — Secure development lifecycle practices include requirements and reviews that prevent flawed token-generation logic.
CWE-1272partialprevents — Secure SDLC can include state-transition checks, yet the control does not specifically require data clearing.
CWE-128partialprevents — Secure development lifecycle includes input validation and bounds checking that can prevent wrap-around errors.
CWE-1281partialprevents — Secure development lifecycle can include processor-specific validation to avoid instruction sequences that cause lock-ups.
CWE-1282partialprevents — Secure development life cycle mandates hardware-enforced immutability or protected storage for bootloaders and device identifiers.
CWE-1284partialprevents — Secure development lifecycle mandates input validation for quantity fields, directly preventing CWE-1284.
CWE-1285partialprevents — Secure development lifecycle includes input validation requirements that can prevent improper index handling.
CWE-1286partialprevents — Secure development life cycle mandates input validation to ensure syntactic correctness.
CWE-1287partialprevents — Secure development lifecycle mandates input validation and type checking to prevent improper type handling.
CWE-1288partialprevents — Secure development lifecycle requires input validation and consistency checks that directly address CWE-1288.
CWE-129partialprevents — Secure development lifecycle mandates input validation and bounds checking that directly prevents improper array indexing.
CWE-1291partialprevents — Secure SDLC practices include key-separation and signing-process controls that prevent reuse of the same key across environments.
CWE-1298partialprevents — Secure development lifecycle includes hardware design reviews that can catch race conditions.
CWE-130partialprevents — Secure development lifecycle mandates input validation and length checks that directly address inconsistent length fields.
CWE-131partialprevents — Secure development lifecycle mandates size-checking practices that reduce buffer-size miscalculations.
CWE-1310partialprevents — Secure development lifecycle practices encourage updatable firmware design but do not enforce post-deployment ROM patching.
CWE-1320partialprevents — Secure development lifecycle includes requirements for proper error and alert handling.
CWE-1321partialprevents — Secure development lifecycle mandates input validation and object-handling controls that directly prevent prototype pollution.
CWE-1322partialprevents — Secure development lifecycle requires architectural and coding practices that avoid blocking calls in non-blocking contexts.
CWE-1325partialprevents — Secure development life cycle includes resource-management requirements that can prevent uncontrolled per-object allocations.
CWE-1328partialprevents — Secure SDLC practices can embed anti-rollback mechanisms during hardware/firmware design.
CWE-1329partialmitigates — Secure-SDLC practices encourage selection of maintainable components, but the weakness may still arise from third-party or legacy choices.
CWE-1333partialprevents — Secure development lifecycle mandates review of algorithmic efficiency, directly addressing ReDoS-prone regex.
CWE-1335partialprevents — Secure development life cycle includes practices that can catch or prevent undefined bitwise-shift behavior.
CWE-1336partialprevents — Secure development life cycle mandates input validation and sanitization that directly prevents template-injection weaknesses.
CWE-134partialprevents — Secure SDLC mandates input validation and safe API usage that can prevent externally-controlled format strings.
CWE-1341partialprevents — Secure development lifecycle practices can include resource-management rules that reduce double-release bugs.
CWE-135partialprevents — Secure development life cycle includes requirements that can catch incorrect multi-byte string length calculations during design and coding.
CWE-1357partialmitigates — Secure SDLC practices include component selection and trust evaluation steps.
CWE-138partialprevents — Secure development life cycle mandates input validation and sanitization that directly prevents improper neutralization of special elements.
CWE-1386partialprevents — Secure development lifecycle can mandate junction/mount-point validation during design and coding.
CWE-1389partialprevents — Secure development lifecycle requires input validation and parsing rules that would catch radix assumptions.
CWE-1391partialprevents — Requires security activities throughout the SDLC that can catch weak credentials, but does not mandate their elimination.
CWE-14partialprevents — A secure SDLC can include compiler-flag and code-review requirements that mitigate dead-store removal, yet the control is broader.
CWE-140partialprevents — Secure development life cycle incorporates practices that reduce the likelihood of delimiter-neutralization defects.
CWE-141partialprevents — Secure development life cycle mandates input validation and sanitization that directly prevents delimiter injection.
CWE-142partialprevents — Secure development life cycle mandates input validation and sanitization that directly addresses delimiter neutralization.
CWE-143partialprevents — Secure development lifecycle mandates input validation and sanitization that directly prevents improper record-delimiter handling.
CWE-144partialprevents — Secure SDLC mandates input validation and sanitization that can prevent line-delimiter injection.
CWE-145partialprevents — Secure development life cycle mandates input validation and output encoding that directly neutralizes section delimiters.
CWE-146partialprevents — Secure development life cycle mandates input validation and output encoding that directly neutralizes expression/command delimiters.
CWE-147partialprevents — Secure development lifecycle mandates input validation and sanitization that directly prevents improper neutralization of terminators.
CWE-148partialprevents — Secure development lifecycle includes input-handling requirements that can prevent malformed leader sequences.
CWE-149partialprevents — Secure development life cycle mandates input validation and output encoding that directly prevent quote-injection flaws.
CWE-150partialprevents — Secure development lifecycle mandates input validation and output encoding that directly neutralizes escape/meta sequences.
CWE-153partialprevents — Secure development lifecycle mandates input validation and sanitization that directly prevents substitution-character injection.
CWE-154partialprevents — Secure SDLC mandates input validation and output encoding that directly neutralizes variable-name delimiter characters.
CWE-155partialprevents — Secure development lifecycle mandates input validation and sanitization that directly prevents wildcard injection.
CWE-156partialprevents — Secure development lifecycle includes input validation and sanitization practices that can prevent improper whitespace handling.
CWE-157partialprevents — Secure development life cycle requires input validation and sanitization practices that mitigate delimiter-handling flaws.
CWE-158partialprevents — Secure development lifecycle mandates input validation and sanitization that directly prevents null-byte injection.
CWE-159partialprevents — Secure development lifecycle mandates input validation and sanitization that directly prevents improper handling of special elements.
CWE-160partialprevents — Secure development life cycle mandates input validation and sanitization that directly prevents leading special-element injection.
CWE-162partialprevents — Secure development lifecycle includes input-handling requirements that can prevent trailing-special-element issues.
CWE-164partialprevents — Secure development life cycle mandates input validation and sanitization that directly prevents improper neutralization of internal special elements.
CWE-166partialprevents — Secure SDLC practices can include input validation rules that detect missing special elements.
CWE-167partialprevents — Secure development lifecycle mandates input validation and handling of unexpected data elements.
CWE-168partialprevents — Secure development lifecycle includes input-handling requirements that can prevent inconsistent special-element issues.
CWE-170partialprevents — Secure SDLC mandates input validation and string handling rules that prevent missing null terminators.
CWE-172partialprevents — Secure development lifecycle includes input/output validation and encoding practices that reduce encoding errors.
CWE-176partialprevents — Secure development lifecycle mandates input validation and encoding handling that can prevent Unicode mishandling.
CWE-177partialprevents — Secure SDLC processes include validation steps that reduce CWE-177, yet the control is broader than this single weakness.
CWE-178partialprevents — Secure SDLC practices should include case-sensitivity requirements in design and coding standards.
CWE-179partialprevents — Secure development life cycle mandates validation after canonicalization or sanitization, directly preventing early-validation bypasses.
CWE-180partialprevents — Secure SDLC mandates input validation and canonicalization order, directly addressing CWE-180.
CWE-182partialprevents — Secure development lifecycle mandates input validation and sanitization that directly prevents unsafe data collapse.
CWE-185partialprevents — Secure development lifecycle includes validation of input-handling constructs such as regex.
CWE-186partialprevents — Secure development lifecycle includes input-validation and regex-review practices that can catch overly restrictive patterns.
CWE-187partialprevents — Secure development lifecycle practices can include requirements to avoid partial string comparisons in authentication or validation logic.
CWE-188partialprevents — Secure development lifecycle includes architecture and design reviews that can catch invalid memory-layout assumptions.
CWE-190partialprevents — Secure SDLC mandates input validation and arithmetic checks that prevent integer overflows.
CWE-191partialprevents — Secure development lifecycle mandates input validation and arithmetic checks that prevent integer underflow.
CWE-192partialprevents — Secure development life cycle includes input validation and type-safety checks that reduce integer coercion errors.
CWE-193partialprevents — Secure development life cycle includes requirements and reviews that can catch off-by-one errors.
CWE-194partialprevents — Secure development lifecycle includes practices that can catch sign-extension issues during design and review.
CWE-195partialprevents — Secure development life cycle mandates practices that can catch signed-to-unsigned conversion errors during design and coding.
CWE-196partialprevents — Secure development lifecycle mandates practices that can catch or prevent unsafe type conversions.
CWE-197partialprevents — Secure development lifecycle mandates practices that can catch numeric truncation during design and code review.
CWE-198partialprevents — Secure development lifecycle requires handling of data formats and endianness in design and coding.
CWE-20partialprevents — Secure-coding guidelines and mandatory security testing (including code scans) compel developers to validate and sanitize inputs at design and implementation time, lowering the incidence of malformed or malicious data reaching downstream components.
CWE-200partialprevents — Penetration testing and code-scanning activities within the SDLC surface unintended exposure paths, allowing sensitive information leaks to be identified and corrected before release.
CWE-201partialprevents — Secure-SDLC practices include data-flow reviews that catch unintended transmission of secrets.
CWE-204partialprevents — Secure SDLC practices include error-handling and response standardization to avoid information disclosure.
CWE-205partialprevents — Secure development lifecycle practices can include design reviews that eliminate observable behavioral discrepancies.
CWE-207partialprevents — Secure development lifecycle practices can eliminate observable behavioral discrepancies.
CWE-209partialprevents — Secure SDLC mandates error-handling rules that avoid leaking sensitive information.
CWE-212partialprevents — Secure SDLC practices include requirements to strip sensitive data from artifacts before release.
CWE-215partialprevents — Secure SDLC mandates removal of debug code and sensitive data before release.
CWE-219partialmitigates — Secure SDLC practices include placing sensitive data outside the document root.
CWE-22partialprevents — Secure SDLC mandates input validation and path sanitization that directly prevent path traversal.
CWE-226partialprevents — Secure SDLC includes requirements for clearing sensitive data during resource lifecycle transitions.
CWE-228partialprevents — Secure development life cycle mandates input validation and error handling that directly prevents improper handling of syntactically invalid structures.
CWE-229partialprevents — Secure development lifecycle includes input validation and parameter handling requirements that reduce missing-value errors.
CWE-23partialprevents — Secure development lifecycle mandates input validation and path-handling controls that directly prevent relative path traversal.
CWE-231partialprevents — Secure development lifecycle includes input validation and parameter handling that can prevent extra-value processing flaws.
CWE-232partialprevents — Secure development life cycle requires handling of invalid/undefined inputs during design and coding.
CWE-233partialprevents — Secure development lifecycle includes input validation and parameter handling requirements that reduce improper parameter handling.
CWE-234partialprevents — Secure development lifecycle mandates input validation and parameter checking that can prevent missing-parameter failures.
CWE-235partialprevents — Secure development lifecycle includes input validation and parameter handling requirements that can prevent extra-parameter issues.
CWE-236partialprevents — Secure development lifecycle requires explicit definition and validation of all parameters, reducing undefined-parameter handling issues.
CWE-237partialprevents — Secure development lifecycle requires structured input validation and error handling that can mitigate improper handling of complex structures.
CWE-239partialprevents — Secure development lifecycle requires input validation and completeness checks that reduce incomplete-element handling failures.
CWE-24partialprevents — Secure SDLC mandates input validation and path canonicalization that directly block ../ traversal.
CWE-240partialprevents — Secure development lifecycle requires consistent handling of structural elements across design, coding and testing phases.
CWE-241partialprevents — Secure development lifecycle includes input validation and type checking that directly mitigates improper handling of unexpected data types.
CWE-242partialprevents — Secure SDLC processes include code review and static analysis that can detect dangerous function usage.
CWE-244partialprevents — Secure SDLC processes can incorporate memory-safety requirements but do not specifically mandate heap clearing.
CWE-248partialprevents — Secure development lifecycle includes exception-handling standards that reduce uncaught exceptions.
CWE-25partialprevents — Secure development lifecycle mandates input validation and path sanitization that directly prevents traversal sequences.
CWE-252partialprevents — Secure development life cycle mandates verification of return values to prevent undetected failures.
CWE-253partialprevents — Secure SDLC mandates return-value checks and error handling, directly reducing CWE-253.
CWE-257partialprevents — Secure SDLC includes requirements that reduce the likelihood of introducing recoverable password storage.
CWE-258partialprevents — Secure development lifecycle includes controls that should prevent shipping empty passwords in configuration artifacts.
CWE-26partialprevents — Secure development lifecycle mandates input validation and path canonicalization that directly prevent directory traversal sequences.
CWE-267partialmitigates — Secure development lifecycle can catch unsafe privilege definitions during design but does not prevent them at runtime.
CWE-27partialprevents — Secure development lifecycle mandates input validation and path sanitization that directly prevents directory traversal.
CWE-270partialprevents — Secure-SDLC practices can catch privilege-handling defects early but do not guarantee runtime correctness.
CWE-271partialprevents — Secure development lifecycle includes privilege management reviews, providing indirect coverage of the weakness.
CWE-274partialprevents — Secure SDLC practices can include privilege checks, yet the control itself does not mandate handling of insufficient privileges.
CWE-277partialprevents — Secure development lifecycle practices can include permission model reviews but do not guarantee secure inherited permissions.
CWE-278partialprevents — Secure development lifecycle practices include permission handling requirements that prevent insecure inherited permissions in new code.
CWE-28partialprevents — Secure development lifecycle mandates input validation and path sanitization that directly blocks ..\ traversal.
CWE-280partialprevents — Secure-SDLC practices include privilege checks during design and coding.
CWE-284partialprevents — Embedding security requirements and checkpoints throughout the development lifecycle forces explicit consideration of access-control decisions before code is written, reducing the chance that missing or incorrect authorization logic is introduced.
CWE-287partialprevents — Security requirements specified early and verified through testing drive the consistent implementation of authentication mechanisms, decreasing the likelihood that authentication steps are omitted or incorrectly applied.
CWE-288partialprevents — Secure development lifecycle can prevent introduction of bypass flaws but does not mitigate existing ones.
CWE-290partialprevents — Secure development lifecycle reduces authentication flaws when followed but is not specific to spoofing.
CWE-30partialprevents — Secure SDLC mandates input validation and path canonicalization that directly blocks leading-backslash traversal sequences.
CWE-302partialprevents — Secure SDLC practices include threat modeling and input-validation requirements that catch assumed-immutable data flaws.
CWE-303partialprevents — Secure development lifecycle includes verification steps that can catch incorrect authentication implementations.
CWE-304partialprevents — Secure development lifecycle can catch missing auth steps during design, but does not directly enforce runtime authentication.
CWE-305partialprevents — Secure development lifecycle reduces likelihood of introducing bypass flaws during implementation.
CWE-31partialprevents — Secure development lifecycle mandates input validation and path sanitization that directly blocks directory traversal sequences.
CWE-316partialprevents — Secure-SDLC processes include memory-handling reviews that catch this weakness.
CWE-318partialprevents — Secure SDLC processes can catch the weakness during design or code review but do not prescribe the technical fix.
CWE-32partialprevents — Secure SDLC mandates input validation and path-handling rules that directly block triple-dot traversal.
CWE-325partialprevents — Secure SDLC processes reduce the likelihood of missing crypto steps but do not guarantee algorithm completeness.
CWE-329partialprevents — Secure SDLC processes catch cryptographic flaws like bad IVs during design and review phases.
CWE-330partialprevents — Secure SDLC processes include verification steps that can catch insufficient randomness but do not directly specify RNG requirements.
CWE-331partialprevents — Secure-SDLC activities include entropy validation during design and testing.
CWE-332partialprevents — Secure SDLC requires selection of approved cryptographic primitives including proper RNG sources.
CWE-336partialprevents — Secure SDLC practices require cryptographic randomness to be addressed during design and implementation.
CWE-337partialprevents — Requires secure development practices that should include proper PRNG seeding.
CWE-338partialprevents — Secure SDLC processes should catch weak PRNG usage during design and code review.
CWE-34partialprevents — Secure development life cycle mandates input validation and path-handling controls that directly prevent path traversal sequences.
CWE-340partialprevents — A secure SDLC incorporates threat modelling and secure-design reviews that flag predictable identifier generation early in the lifecycle.
CWE-341partialprevents — SDLC requirements encourage secure design but do not directly mandate removal of predictable state.
CWE-342partialprevents — Secure SDLC mandates secure random-number practices during design and coding.
CWE-343partialprevents — Secure SDLC mandates cryptographic and randomness requirements that prevent predictable RNG weaknesses.
CWE-344partialprevents — Secure development life cycle requires parameterization and environment-aware design, directly addressing invariant values.
CWE-345partialprevents — Secure SDLC incorporates authenticity verification requirements throughout development.
CWE-349partialprevents — Secure development lifecycle mandates input validation and trust-boundary enforcement that directly prevents acceptance of untrusted data alongside trusted data.
CWE-35partialprevents — Secure SDLC mandates input validation and path-handling controls that directly mitigate path traversal.
CWE-351partialprevents — Secure development lifecycle practices can include type-safe design and validation to reduce type confusion.
CWE-356partialprevents — Secure development life cycle requires UI design to warn users before unsafe actions.
CWE-357partialprevents — Secure development lifecycle requires usable security prompts and warnings to be designed into the UI.
CWE-358partialprevents — Secure development life cycle mandates verification that security checks required by standards are correctly implemented.
CWE-36partialprevents — Secure development lifecycle includes input validation and path-handling requirements that reduce absolute path traversal risk.
CWE-362partialprevents — Secure SDLC mandates concurrency controls and synchronization primitives that directly prevent race conditions.
CWE-363partialprevents — Secure development lifecycle practices can include TOCTOU-safe file handling, but do not guarantee elimination of link-following races.
CWE-364partialprevents — Secure SDLC practices can require avoidance of unsafe signal handling patterns.
CWE-366partialprevents — Secure development lifecycle includes concurrency and synchronization practices that reduce race conditions.
CWE-368partialprevents — Secure development lifecycle practices can require atomic context-switch handling and race-condition testing.
CWE-369partialprevents — Secure development lifecycle includes input validation and error-handling practices that can prevent divide-by-zero faults.
CWE-372partialprevents — Secure development lifecycle practices can include state-machine validation and invariant checks that reduce incomplete internal state errors.
CWE-374partialprevents — Secure development lifecycle practices can mandate defensive copying of mutable objects before passing them to untrusted code.
CWE-377partialprevents — Secure development life cycle mandates secure handling of temporary files during design and coding.
CWE-378partialprevents — Secure SDLC mandates secure handling of temporary files and permissions.
CWE-38partialprevents — Secure development lifecycle mandates input validation and path-handling controls that directly prevent absolute-path traversal.
CWE-384partialprevents — Secure-SDLC requirement can embed session-fixation checks, but eliminating the weakness does not satisfy the full SDLC control.
CWE-386partialprevents — Secure development lifecycle practices can require explicit object resolution instead of relying on symbolic names that may change.
CWE-390partialprevents — Secure development lifecycle practices encourage proper error handling, but do not mandate it for every detected condition.
CWE-391partialprevents — Secure development life cycle requires systematic error handling, reducing unchecked conditions.
CWE-392partialprevents — Secure development lifecycle practices include requirements for proper error handling and status reporting.
CWE-393partialprevents — Secure development lifecycle includes code review and testing that can catch incorrect status codes.
CWE-394partialprevents — Secure development lifecycle requires handling of all return values and status codes.
CWE-396partialprevents — Secure SDLC processes encourage disciplined exception handling, yet the control itself does not mandate specific coding rules.
CWE-401partialprevents — Secure development life cycle mandates memory-management practices that reduce missing-release defects.
CWE-403partialprevents — Secure SDLC practices include code reviews and static analysis that can detect leaked descriptors.
CWE-407partialprevents — Secure development life cycle includes design reviews that can catch inefficient algorithms before deployment.
CWE-409partialprevents — Secure development lifecycle includes input validation and resource-limit checks that mitigate data-amplification attacks.
CWE-41partialprevents — Secure development lifecycle includes path-handling requirements that reduce equivalence-based disclosure.
CWE-412partialprevents — Secure development lifecycle practices can prevent introducing externally controllable locks during design.
CWE-413partialprevents — Secure development lifecycle requires proper resource management patterns that prevent improper locking.
CWE-414partialprevents — Secure SDLC practices include concurrency and synchronization reviews that catch missing lock checks.
CWE-415partialprevents — Secure development life cycle includes memory-safety practices that can prevent double-free bugs.
CWE-416partialprevents — Secure SDLC mandates memory-safety practices that reduce use-after-free defects.
CWE-421partialprevents — Secure development practices can identify and eliminate race conditions involving alternate channels.
CWE-422partialprevents — Secure development life cycle mandates input validation and privilege separation that directly prevent shatter-style message injection.
CWE-424partialprevents — Secure development lifecycle includes design reviews that should identify and close alternate paths.
CWE-425partialprevents — Secure SDLC can include authorization design, yet the control itself does not guarantee runtime enforcement.
CWE-428partialprevents — Secure development lifecycle practices include input validation and path handling that reduce unquoted search-path weaknesses.
CWE-43partialprevents — Secure SDLC requires input validation and path-handling controls that can prevent malformed filenames.
CWE-430partialprevents — Secure development life cycle includes handler registration and dispatch validation that prevents wrong-handler assignment.
CWE-431partialprevents — Secure development life cycle requires defined error/exception handling, reducing missing-handler defects.
CWE-433partialprevents — Secure development lifecycle mandates proper file-type handling and server configuration to prevent raw content exposure.
CWE-434partialprevents — Secure-coding guidelines and security testing explicitly address restrictions on allowed file types and upload handling, reducing the risk that dangerous file uploads are accepted without validation.
CWE-435partialprevents — Secure SDLC practices include integration and interface testing that can detect interaction flaws.
CWE-436partialprevents — Secure development lifecycle can require consistent interface contracts and canonicalization rules that reduce interpretation conflicts between components.
CWE-437partialprevents — A secure SDLC can mandate complete endpoint capability modeling during design and threat modeling phases.
CWE-440partialprevents — Secure development life cycle mandates verification against specifications, directly reducing expected-behavior violations.
CWE-441partialprevents — Secure-SDLC practices include design reviews that detect and eliminate confused-deputy proxy patterns before deployment.
CWE-444partialprevents — Secure SDLC practices require threat modeling and testing for HTTP parsing inconsistencies in intermediaries.
CWE-446partialprevents — Secure development lifecycle requires UI security features to be correctly implemented and verified, directly preventing misleading security-state feedback.
CWE-447partialprevents — Secure development lifecycle requires that security features are actually implemented, not just presented in the UI.
CWE-448partialprevents — Secure development lifecycle requires removal or deprecation of obsolete UI features before release.
CWE-449partialprevents — Secure development lifecycle includes UI/UX requirements and testing that directly prevent the interface from executing the wrong action.
CWE-450partialprevents — Secure development lifecycle can require UI input handling to be unambiguous and user-prompted on ambiguous choices.
CWE-451partialprevents — Secure development lifecycle includes UI/UX security requirements that can prevent misrepresentation of critical information.
CWE-453partialprevents — Secure development life cycle requires explicit secure initialization of variables.
CWE-454partialprevents — Secure development lifecycle mandates validation of all inputs used to initialize trusted variables or data stores.
CWE-455partialprevents — Secure development lifecycle requires proper error handling and secure initialization, addressing the weakness.
CWE-456partialprevents — Secure development life cycle mandates initialization checks that prevent uninitialized-variable defects.
CWE-457partialprevents — Secure development life cycle mandates practices that reduce uninitialized-variable defects.
CWE-459partialprevents — SDLC practices include cleanup steps, yet the weakness can still occur if those steps are omitted.
CWE-460partialprevents — Secure SDLC mandates exception-handling and cleanup practices that reduce improper state after thrown exceptions.
CWE-462partialprevents — Secure development lifecycle includes input validation and data-structure checks that can prevent duplicate-key bugs.
CWE-463partialprevents — Secure SDLC practices can include sentinel handling rules that reduce accidental deletion.
CWE-466partialprevents — Secure SDLC practices can include pointer-range validation and bounds checking to prevent out-of-range returns.
CWE-467partialprevents — Secure SDLC processes include coding standards that reduce this class of defect.
CWE-468partialprevents — Secure SDLC processes can introduce pointer-safety reviews that reduce incorrect scaling, but the control is broader than this single coding flaw.
CWE-469partialprevents — Secure SDLC mandates design and code reviews that can catch unsafe pointer arithmetic.
CWE-470partialprevents — Secure development lifecycle mandates input validation and design reviews that reduce unsafe reflection risks.
CWE-471partialprevents — Secure SDLC practices include design reviews that identify and protect data assumed to be immutable.
CWE-472partialprevents — Secure development lifecycle mandates input validation and integrity checks that directly prevent external tampering of assumed-immutable parameters.
CWE-473partialprevents — Secure development lifecycle mandates input validation and variable handling rules that directly prevent external variable tampering.
CWE-474partialprevents — Secure SDLC requires consistent API selection and platform abstraction, reducing use of inconsistently implemented functions.
CWE-475partialprevents — Secure development lifecycle includes API specification and validation that can prevent undefined behavior from invalid inputs.
CWE-476partialprevents — Secure SDLC mandates defensive coding practices that can prevent NULL dereferences.
CWE-477partialprevents — Secure SDLC processes include code reviews and maintenance that catch obsolete functions.
CWE-478partialprevents — Secure SDLC processes encourage defensive coding but do not directly mandate default-case coverage.
CWE-479partialprevents — Secure SDLC mandates safe coding practices that can prevent non-reentrant calls in signal handlers.
CWE-482partialprevents — Secure SDLC processes include coding standards that reduce this class of error.
CWE-484partialprevents — Secure SDLC processes include code review and testing that can catch missing breaks, but do not specifically mandate them.
CWE-488partialprevents — Secure development lifecycle practices include session-management controls that prevent exposure of data to the wrong session.
CWE-489partialprevents — Secure development life cycle mandates removal of debug code before release.
CWE-491partialprevents — Secure development lifecycle includes design and code reviews that can catch non-final clone methods.
CWE-495partialprevents — Secure SDLC practices can mandate encapsulation and return-value design rules that prevent leaking private structures.
CWE-499partialprevents — Secure SDLC requires design reviews that can mandate explicit non-serializability for sensitive classes.
CWE-50partialprevents — Secure development lifecycle requires input validation and path-handling controls that mitigate path-equivalence issues.
CWE-501partialprevents — Secure development lifecycle mandates separation of trusted and untrusted data flows, directly preventing mixing in the same structure.
CWE-507partialprevents — Secure development lifecycle reduces the chance of hidden malicious code being introduced.
CWE-511partialprevents — Secure development lifecycle processes include code review and testing that detect logic/time bombs before deployment.
CWE-520partialprevents — Secure SDLC practices can catch impersonation misconfigurations early, but removing the weakness does not fulfill the full lifecycle control objective.
CWE-526partialprevents — Secure SDLC practices include requirements to avoid storing secrets in cleartext environment variables.
CWE-531partialprevents — Secure SDLC mandates review of test artifacts, reducing risk of sensitive data in test code.
CWE-535partialprevents — Secure SDLC practices include proper exception handling to avoid leaking sensitive data in error messages.
CWE-539partialprevents — Secure development lifecycle requires avoiding persistent storage of sensitive data in cookies.
CWE-540partialprevents — Secure SDLC practices include removing secrets from code before commit or deployment.
CWE-541partialprevents — Secure SDLC practices ensure sensitive data is not hard-coded in include files.
CWE-544partialprevents — Secure development life cycle requires consistent, standardized error-handling practices across the codebase.
CWE-547partialprevents — Secure SDLC processes can catch hard-coded constants during reviews and testing.
CWE-548partialprevents — Secure development life cycle includes configuration hardening that disables directory listing in production web servers.
CWE-550partialprevents — Secure SDLC mandates handling of error messages to avoid information disclosure.
CWE-551partialprevents — Secure development lifecycle requires proper URL parsing and canonicalization before authorization checks.
CWE-553partialprevents — Secure development lifecycle practices include review and removal of dangerous files before deployment.
CWE-561partialprevents — Secure SDLC mandates code reviews and static analysis that detect and remove unreachable code.
CWE-562partialprevents — Secure SDLC practices can catch stack-variable misuse during design and code review.
CWE-564partialprevents — Secure SDLC mandates input validation and ORM usage that reduce dynamic SQL injection risk.
CWE-567partialprevents — Secure development lifecycle includes thread-safety and concurrency requirements that reduce unsynchronized access.
CWE-57partialprevents — Requires secure development practices that include canonicalization and input validation to prevent path-equivalence flaws.
CWE-570partialprevents — Secure development life cycle includes static analysis and code review that can detect always-false expressions.
CWE-571partialprevents — Secure development life cycle includes static analysis and code review that can detect always-true expressions.
CWE-573partialprevents — Secure development life cycle mandates adherence to language, framework and protocol specifications, directly reducing improper caller behavior.
CWE-587partialprevents — Secure development life cycle mandates practices that can prevent hard-coded pointer assignments.
CWE-588partialprevents — Secure SDLC mandates design and code reviews that can catch unsafe pointer casts.
CWE-59partialprevents — Secure SDLC practices can mandate link-resolution checks and canonicalization before file access.
CWE-590partialprevents — Secure development lifecycle mandates memory-safety practices that reduce use-after-free and invalid-free bugs.
CWE-597partialprevents — Secure SDLC practices include code reviews and static analysis that catch incorrect string comparisons.
CWE-6partialprevents — Secure development life cycle includes configuration hardening that would catch weak session settings.
CWE-600partialprevents — Secure development lifecycle mandates exception-handling and error-handling standards that prevent uncaught servlet exceptions.
CWE-602partialprevents — Secure development lifecycle mandates server-side validation and prevents reliance on client enforcement.
CWE-606partialprevents — Secure development lifecycle requires input validation and bounds checking that can prevent unchecked loop conditions.
CWE-610partialprevents — Secure development lifecycle mandates validation of all external references to prevent uncontrolled resource access.
CWE-611partialprevents — Secure development life cycle mandates input validation and entity handling that directly prevents XXE.
CWE-615partialprevents — Secure SDLC practices can include code-review gates that catch sensitive comments before release.
CWE-616partialprevents — Secure development lifecycle mandates proper input handling and file-upload validation, directly addressing the outdated global-variable approach.
CWE-617partialprevents — Secure development lifecycle mandates defensive coding and input validation that prevent reachable assertions from being triggered by untrusted data.
CWE-618partialprevents — Secure development lifecycle mandates review of exposed interfaces and dangerous methods before release.
CWE-621partialprevents — Secure development lifecycle mandates input validation and variable handling rules that reduce extraction errors.
CWE-622partialprevents — Secure development lifecycle requires input validation and API design reviews that would catch missing hook-argument checks.
CWE-623partialprevents — Secure development lifecycle processes include security reviews that would catch and reject unsafe-for-scripting markings.
CWE-624partialprevents — Secure development lifecycle includes input validation and regex review that can prevent executable regex patterns.
CWE-625partialprevents — Secure development lifecycle requires validation of input mechanisms, including regex, reducing permissive patterns.
CWE-626partialprevents — Secure SDLC practices can include input validation and boundary checks that prevent null-byte mishandling.
CWE-627partialprevents — Secure development lifecycle mandates input validation and variable handling rules that reduce dynamic evaluation risks.
CWE-628partialprevents — Secure development lifecycle includes code review and testing that can catch incorrect function arguments.
CWE-637partialprevents — Secure development life cycle includes design reviews that can catch overly complex protection mechanisms.
CWE-639partialprevents — Secure development lifecycle includes authorization design but does not itself implement runtime access checks.
CWE-640partialprevents — Secure-SDLC practices can embed strong recovery design, yet the control is broader than this single weakness.
CWE-641partialprevents — Secure development life cycle mandates input validation and safe resource naming practices that directly prevent CWE-641.
CWE-642partialprevents — Secure development practices can avoid placing critical state in externally writable locations.
CWE-643partialprevents — Secure SDLC mandates input validation and query parameterization that directly prevent XPath injection.
CWE-644partialprevents — Secure development lifecycle mandates input validation and output encoding that directly prevents header-injection flaws.
CWE-646partialprevents — Secure SDLC requires proper file-type validation, directly mitigating reliance on untrusted names or extensions.
CWE-648partialprevents — Secure development lifecycle includes API usage standards that can prevent incorrect privileged calls.
CWE-652partialprevents — Secure SDLC mandates input validation and query parameterization that directly prevent XQuery injection.
CWE-657partialprevents — A secure development life cycle directly requires adherence to established secure design principles.
CWE-66partialprevents — Secure development lifecycle practices can include input validation and path-handling rules that reduce the risk of mishandling virtual file names.
CWE-662partialprevents — Secure development lifecycle requires concurrency controls and synchronization primitives to prevent race conditions.
CWE-663partialprevents — Secure SDLC requires thread-safety and re-entrancy analysis that can prevent non-reentrant calls in concurrent contexts.
CWE-664partialprevents — Secure SDLC embeds resource lifecycle controls from design through decommissioning.
CWE-665partialprevents — Secure development life cycle mandates initialization checks and secure defaults that directly prevent improper resource initialization.
CWE-667partialprevents — Secure development lifecycle includes concurrency and locking requirements that reduce improper locking defects.
CWE-669partialmitigates — Secure SDLC practices can catch incorrect resource-transfer flaws early.
CWE-67partialprevents — Secure development lifecycle requires input validation and path handling rules that would prevent device-name misuse.
CWE-670partialprevents — Secure development lifecycle processes can catch incorrect control-flow logic during design and code review.
CWE-674partialprevents — Secure development life cycle requires controls that prevent uncontrolled recursion through design and code review.
CWE-675partialprevents — Secure development lifecycle practices can catch duplicate resource operations during design and code review.
CWE-676partialprevents — Secure SDLC processes include code review and static analysis that can detect use of risky functions.
CWE-680partialprevents — Secure development life cycle mandates practices that can catch integer overflows before deployment.
CWE-681partialprevents — Secure development lifecycle includes type-safety and conversion checks that reduce numeric truncation risks.
CWE-682partialprevents — Secure development lifecycle mandates verification steps that catch incorrect calculations before they reach production.
CWE-683partialprevents — A secure SDLC process encourages practices that reduce such weaknesses but does not directly address argument ordering.
CWE-684partialprevents — Secure development life cycle includes requirements and verification activities that directly reduce the risk of delivering functionality that deviates from published specifications.
CWE-686partialprevents — Secure development life cycle includes coding standards and reviews that can catch type-mismatch errors.
CWE-687partialprevents — Secure development lifecycle includes code review and testing that can catch incorrect argument values.
CWE-688partialprevents — Secure development lifecycle includes code review and testing that can catch incorrect argument usage.
CWE-689partialprevents — Requires secure development practices that include proper permission handling in copy routines.
CWE-690partialprevents — Secure SDLC mandates error-handling and input-validation practices that reduce unchecked return values.
CWE-691partialprevents — Secure development life cycle mandates structured control-flow design and review that directly reduces unexpected flow manipulation.
CWE-692partialprevents — Secure-SDLC processes encourage proper input/output handling, but do not specifically address denylist shortcomings.
CWE-694partialprevents — Secure development lifecycle practices can catch duplicate-ID issues during design and code review.
CWE-695partialprevents — Secure development life cycle mandates avoidance of prohibited low-level APIs.
CWE-696partialprevents — Secure development life cycle mandates correct sequencing of security activities, directly preventing incorrect behavior order.
CWE-697partialprevents — Secure development lifecycle includes code review and testing that can catch incorrect comparison logic.
CWE-698partialprevents — Secure development lifecycle requires proper handling of redirects and exit logic, reducing EAR risk.
CWE-704partialprevents — Secure development lifecycle includes type-safety reviews that reduce incorrect casts.
CWE-705partialprevents — Secure development lifecycle practices can catch improper control-flow scoping during design and code review.
CWE-706partialprevents — Secure SDLC practices include design reviews that can catch incorrect name or reference handling before deployment.
CWE-707partialprevents — Secure development life cycle mandates input validation and output encoding that directly prevent improper neutralization.
CWE-710partialprevents — Secure SDLC mandates coding standards and rules.
CWE-73partialprevents — Secure development lifecycle mandates input validation and path-handling controls that directly prevent external file/path manipulation.
CWE-733partialprevents — Secure SDLC requires compiler and build-process controls that can prevent optimization removal of security code.
CWE-74partialprevents — Secure development life cycle mandates input validation and output encoding that directly prevent injection flaws.
CWE-749partialprevents — Secure development life cycle requires removal or protection of dangerous APIs during design and coding.
CWE-75partialprevents — Secure development life cycle mandates input validation and sanitization practices that directly prevent special-element injection.
CWE-754partialprevents — Secure development life cycle mandates exception handling and input validation that directly prevent missing checks for unusual conditions.
CWE-755partialprevents — Secure SDLC mandates exception-handling requirements and testing that directly prevent improper handling of exceptional conditions.
CWE-756partialprevents — Secure development lifecycle includes error-handling standards that reduce exposure of sensitive data via default error pages.
CWE-757partialprevents — Secure SDLC practices include selecting strong crypto algorithms during design and implementation.
CWE-758partialprevents — Secure development life cycle requires defined, portable coding practices that reduce reliance on undefined behavior.
CWE-759partialprevents — Secure SDLC processes can include password-handling rules but do not guarantee salted hashes.
CWE-76partialprevents — Secure development life cycle mandates input validation and neutralization of all equivalent special elements.
CWE-760partialprevents — Secure development life cycle includes secure coding practices that would catch predictable-salt usage during design and implementation.
CWE-761partialprevents — Secure SDLC processes reduce the likelihood of such memory-management errors but do not specifically address them.
CWE-762partialprevents — Secure development lifecycle mandates consistent allocation/deallocation patterns that prevent mismatched memory routines.
CWE-763partialprevents — Secure SDLC practices can mandate proper memory-management APIs and reviews that catch incorrect deallocation.
CWE-764partialprevents — Secure development lifecycle practices can include concurrency and locking guidelines that reduce the risk of multiple-lock defects.
CWE-765partialprevents — Secure development lifecycle practices can include resource-locking discipline and review to prevent multiple-unlock defects.
CWE-767partialprevents — Secure development life cycle mandates encapsulation and access-control design practices.
CWE-768partialprevents — Secure SDLC practices can include code-review rules that catch short-circuit side-effect bugs.
CWE-77partialprevents — Secure development life cycle mandates input validation and command construction practices that directly prevent command injection.
CWE-771partialprevents — Secure development lifecycle practices can include resource-management rules that prevent missing references.
CWE-772partialprevents — Secure-SDLC practices include resource-management reviews, yet the control covers the entire lifecycle, not just this weakness.
CWE-774partialprevents — Secure development lifecycle requires resource-limit checks during design and coding.
CWE-775partialprevents — Secure SDLC practices can require resource-release reviews, yet the control is broader than this single weakness.
CWE-776partialprevents — Secure SDLC mandates input validation and parser hardening that can prevent unbounded entity expansion.
CWE-782partialprevents — Secure development lifecycle includes design-time access-control requirements for device interfaces.
CWE-783partialprevents — Secure development lifecycle includes code review and testing that can catch precedence errors.
CWE-786partialprevents — Secure development lifecycle includes buffer-boundary checks that reduce out-of-bounds reads before buffer start.
CWE-787partialprevents — Secure development life cycle mandates practices that prevent out-of-bounds writes.
CWE-788partialprevents — Secure development life cycle includes buffer-handling practices that reduce out-of-bounds accesses.
CWE-789partialprevents — Secure development lifecycle includes input validation and size checks that prevent unbounded allocations.
CWE-79partialprevents — Requiring language-specific secure-coding standards and automated scanning during the SDLC catches missing output encoding or improper neutralization of untrusted data before the software reaches production.
CWE-790partialprevents — Secure development life cycle mandates input validation and sanitization that directly prevents improper filtering of special elements.
CWE-791partialprevents — Secure development life cycle processes include validation activities that reduce the likelihood of CWE-791 but do not specify the control itself.
CWE-792partialprevents — Secure development lifecycle mandates input validation and sanitization that directly prevents incomplete filtering of special elements.
CWE-794partialprevents — Secure development lifecycle mandates input validation and sanitization that directly addresses incomplete filtering of special elements.
CWE-80partialprevents — Secure SDLC mandates input validation and output encoding that directly prevent basic XSS.
CWE-805partialprevents — Secure development life cycle mandates buffer-safety practices that directly prevent incorrect length values.
CWE-81partialprevents — Secure development life cycle mandates input validation and output encoding that directly prevent unneutralized script in error pages.
CWE-820partialprevents — Secure SDLC practices can mandate concurrency controls and synchronization primitives.
CWE-821partialprevents — Secure SDLC practices include concurrency and synchronization requirements that reduce race conditions.
CWE-822partialprevents — Secure development lifecycle includes pointer-safety practices that reduce untrusted pointer dereference risk.
CWE-823partialprevents — Secure SDLC mandates input validation and bounds checking that can prevent out-of-range pointer offsets.
CWE-824partialprevents — Secure development life cycle mandates practices that reduce uninitialized pointer defects.
CWE-825partialprevents — Secure development lifecycle practices can include pointer lifetime and memory-management rules that reduce expired-pointer dereferences.
CWE-826partialprevents — Secure development lifecycle practices can include resource-lifetime checks that reduce premature-release defects.
CWE-827partialprevents — Secure development lifecycle mandates input validation and external-entity restrictions that directly prevent unsafe DTD references.
CWE-828partialprevents — Secure development life cycle requires safe coding practices that can prevent non-reentrant signal handlers.
CWE-83partialprevents — Secure SDLC mandates input validation and output encoding that directly prevents script injection in HTML attributes.
CWE-832partialprevents — Secure development lifecycle practices can include concurrency and locking rules that prevent unlock-without-lock errors.
CWE-833partialprevents — Secure development lifecycle requires deadlock analysis and avoidance techniques during design and coding.
CWE-834partialprevents — Secure development lifecycle requires input validation and loop bounds, directly limiting excessive iteration.
CWE-835partialprevents — Secure development life cycle mandates practices that can detect and prevent infinite-loop defects.
CWE-837partialprevents — Secure SDLC practices can require design controls for single-use actions, but the control addresses the entire lifecycle.
CWE-838partialprevents — Secure development life cycle requires encoding-aware output handling, but does not mandate context-specific encoding checks.
CWE-839partialprevents — Secure development life cycle mandates input validation and boundary checks that would catch missing minimum-range verification.
CWE-84partialprevents — Secure development life cycle incorporates the above controls, providing indirect but systematic coverage.
CWE-841partialprevents — Secure development lifecycle requires explicit workflow enforcement in multi-step processes.
CWE-843partialprevents — Secure SDLC mandates type-safe design and review that can catch type-confusion flaws.
CWE-86partialprevents — Secure development life cycle mandates input validation and sanitization that directly prevents improper neutralization of invalid characters in identifiers.
CWE-862partialprevents — Security checkpoints and explicit authorization requirements in the design phase ensure that every sensitive function is paired with an access-control check, reducing missing-authorization defects.
CWE-87partialprevents — Secure SDLC mandates input validation and output encoding that directly prevent alternate XSS syntax.
CWE-88partialprevents — Secure development lifecycle mandates input validation and command construction practices that directly prevent argument injection.
CWE-89partialprevents — Secure-coding rules and security testing phases mandate the use of parameterized queries or equivalent escaping, preventing the construction of dynamic SQL statements from untrusted input.
CWE-90partialprevents — Secure development lifecycle mandates input validation and query construction practices that directly prevent LDAP injection.
CWE-908partialprevents — Secure development life cycle mandates initialization checks and static analysis that can catch uninitialized resource use.
CWE-909partialprevents — Secure development life cycle mandates initialization of resources before use.
CWE-91partialprevents — Secure SDLC mandates input validation and output encoding that directly prevent XML injection.
CWE-910partialprevents — Secure development lifecycle practices can include resource-cleanup rules that reduce use-after-close errors.
CWE-911partialprevents — Secure development lifecycle practices can include reference-counting rules and automated checks that reduce the likelihood of improper updates.
CWE-912partialprevents — Secure development life cycle mandates documented requirements and design reviews that would expose undocumented hidden functionality.
CWE-913partialprevents — Secure development lifecycle mandates controls on dynamic code generation and resource management.
CWE-914partialprevents — Secure development lifecycle requires input validation and variable handling rules that reduce dynamic-variable misuse.
CWE-915partialprevents — Secure development lifecycle requires input validation and object-property whitelisting that directly mitigates mass-assignment risks.
CWE-917partialprevents — Secure SDLC mandates input validation and output encoding that directly prevent expression-language injection.
CWE-93partialprevents — Secure development lifecycle mandates input validation and output encoding that directly prevents CRLF injection.
CWE-941partialprevents — Secure SDLC practices can catch destination errors during design, but coverage is indirect.
CWE-943partialprevents — Secure development life cycle mandates input validation and query parameterization that directly prevent injection flaws.
CWE-95partialprevents — Secure development life cycle mandates input validation and safe coding practices that directly prevent eval injection.
CWE-96partialprevents — Secure development life cycle mandates input validation and sanitization that directly prevents static code injection.
CWE-97partialprevents — Secure SDLC mandates input validation and output encoding that directly prevent SSI injection.
CWE-98partialprevents — Secure development lifecycle mandates input validation and safe include/require patterns that directly prevent remote file inclusion.
CWE-99partialprevents — Secure SDLC mandates input validation and resource-identifier sanitization that directly prevents resource injection.
CWE-1007nonenone — Secure development lifecycle can require UI design standards that improve glyph distinguishability.
CWE-1103nonemitigates — Secure SDLC practices can include portability and cross-platform testing requirements for third-party components.
CWE-1112nonenone — Secure development life cycle mandates documentation of execution controls, yet coverage depends on process rigor.
CWE-1176nonenone — Secure development lifecycle includes performance and efficiency reviews that can catch inefficient CPU algorithms.
CWE-1342nonemitigates — Secure SDLC can incorporate hardware-specific threat modelling and mitigation for transient-execution issues.
CWE-210nonemitigates — Secure SDLC mandates error-handling rules that prevent leakage of sensitive information.
CWE-556nonenone — Secure development lifecycle includes configuration reviews that can detect and prevent unsafe impersonation settings.

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

T1059→P T1195→M T1195.001→P T1505.003→P

Why these map — AI rationale (under review)

T1195mostlyprevents — Requiring security checkpoints, testing, and secure repositories throughout the development lifecycle reduces the likelihood that an adversary can insert malicious code or components into software before it reaches production.
T1059partialprevents — Enforcing secure coding standards and code reviews limits the introduction of command or scripting interpreter vulnerabilities that adversaries could later exploit for execution.
T1195.001partialmitigates — Mandating secure coding guidelines, vulnerability scanning, and developer training makes it harder for attackers to compromise software dependencies or build tools used in the development process.
T1505.003partialprevents — Security testing, code scanning, and secure repositories make it more difficult for adversaries to implant web shells during the development or deployment of web applications.
T1027nonemitigates — Secure coding guidelines and developer training for vulnerability prevention reduce the chance that obfuscated or packed malicious payloads are introduced into source code.
T1554nonemitigates — Requiring separation of environments, version control security, and integrity checks during development reduces opportunities for attackers to compromise host software binaries at build time.
T1608nonemitigates — Secure version control, source-code repositories, and separation of environments limit an adversary’s ability to stage or upload malicious code into production builds.

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

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

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

A01→P A02→M A04→P A05→P A06→M

Why these map — AI rationale (under review)

A02mostlyprevents — Requiring separation of environments, secure repositories, and version control reduces the chance that default or insecure settings will be deployed into production systems.
A06mostlyprevents — Embedding security requirements, checkpoints, and testing throughout the development lifecycle forces security to be considered from the outset rather than bolted on later, directly reducing the likelihood of insecure design patterns.
A01partialprevents — Security requirements and testing activities performed during design and build phases can catch missing or incorrect access-control logic before the application is released.
A04partialmitigates — Security requirements specified early in the lifecycle and validated through testing help ensure cryptographic controls are correctly chosen and implemented rather than added as an afterthought.
A05partialprevents — Mandating secure coding guidelines, developer training, and vulnerability scanning equips teams to avoid and detect injection flaws before code reaches production.
A07noneprevents — Secure-development practices that include authentication-related requirements and testing reduce the introduction of weak or missing authentication mechanisms.

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.