Cyber Resilience

← ISO 27001 Annex A

A.8.28 Technological

Secure coding

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

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

CM-2→P CM-3→P SA-10→P SA-11←M →M SA-15←F →M SA-17←M SA-3←P SA-8←M →M SI-2→P SI-7←P

Why these map — AI rationale (under review)

SA-11mostlyaligns with — Both controls require systematic security testing and evaluation of software during development to identify and mitigate vulnerabilities before deployment.
SA-15mostlyaligns with — Both controls mandate the use of secure development processes, standards, and tools to produce software with fewer exploitable weaknesses.
SA-8mostlyaligns with — Both controls embed security and privacy engineering principles such as least privilege, threat modeling, and secure design into the software development lifecycle.
CM-2partialaligns with — Both controls establish approved, secure baselines for development tools and environments to ensure consistent, hardened configurations.
CM-3partialaligns with — Both controls apply configuration change control and version management to source code to prevent unauthorized modification and maintain integrity.
SA-10partialaligns with — Both controls require configuration management practices for developer-created artifacts to track changes and protect against tampering.
SI-2partialaligns with — Both controls require ongoing identification and remediation of software flaws and vulnerabilities after code is placed into operation.

Aligned NIST CSF 2.0 outcomes (14)

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

DE.AE-07←P GV.SC-05←M →P ID.AM-02←P ID.RA-01→M ID.RA-09←M →M PR.AT-02←P PR.PS-01←P →P PR.PS-02←M →P PR.PS-06←F →F

Why these map — AI rationale (under review)

PR.PS-06fullcovers — The ISO control establishes organization-wide secure coding governance, standards, tool configuration, developer qualification, threat-informed continual improvement, and third-party component vetting—directly fulfilling the CSF outcome of integrating and monitoring secure software development practices.
ID.RA-01mostlyaligns with — By requiring static analysis, review of common programming errors, and mitigation before release, the control systematically identifies and records vulnerabilities in software assets.
ID.RA-09mostlyaligns with — The control mandates vetting, inventorying, and ongoing updates of external libraries and components for authenticity, integrity, and security before and after acquisition.
GV.SC-05partialaligns with — Extending secure-coding governance and component-vetting requirements to third-party and open-source software integrates cybersecurity expectations into supplier contracts and processes.
PR.PS-01partialaligns with — Secure coding standards, IDE/tool configuration, and configuration-management controls for source code constitute configuration-management practices applied to the development environment.
PR.PS-02partialaligns with — The control requires secure packaging, deployment, and regular updates of software, aligning with the outcome of maintaining or replacing software commensurate with risk.

Related OWASP ASVS 5.0 requirements (15)

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

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

V1.3.2←P V11.1.2←P V13.4.1→P V15.1.2←M →M V15.1.4→P V15.1.5←M V15.2.1←M →M V15.2.4→P V15.2.5←P →P V15.3.3←P V15.3.5←P V16.3.4→P

Why these map — AI rationale (under review)

V15.1.2mostlycovers — The ISO control's requirement to maintain an inventory of third-party and open-source libraries with version tracking directly implements the ASVS mandate for an SBOM-style catalog of all third-party components.
V15.2.1mostlycovers — Requiring that components stay within documented remediation timeframes for vulnerabilities is the direct operational outcome of the ISO control's continual monitoring of threats and vulnerabilities.
V13.4.1partialaligns with — The ISO control's requirement to protect source code against unauthorized access and tampering using configuration-management tools aligns with the ASVS requirement to prevent exposure of source-control metadata in production.
V15.1.4partialaligns with — The ISO control's call to qualify developers and apply secure coding standards supports the ASVS expectation that documentation identifies risky third-party libraries.
V15.2.4partialaligns with — The ISO control's emphasis on selecting and authorizing well-vetted external components from reputable sources aligns with the ASVS requirement that third-party components and transitive dependencies come from expected repositories.
V15.2.5partialaligns with — The ISO control's prohibition of insecure design techniques and emphasis on least privilege during review aligns with the ASVS requirement for additional protections around documented dangerous functionality.
V16.3.4partialaligns with — The ISO control's directive to log errors and suspected attacks and regularly review logs aligns with the ASVS requirement to log unexpected errors and security-control failures.

Related weaknesses / CWE (1088)

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

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

CWE-1004←P →P CWE-1007←P CWE-102←P →P CWE-1021←P →P CWE-1022←P →P CWE-1023←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 CWE-1055←P →P CWE-1056←P →P CWE-1057→P CWE-1058←P →P CWE-1066←P →P CWE-1067←P →P CWE-1072→P CWE-1076←P →M CWE-1077←P →P CWE-1078←P →P CWE-1083←P →P CWE-1088←P →P CWE-1091←P →P CWE-11→P CWE-1100←P →P CWE-1102←P →P CWE-1106←P →P CWE-1107←P →P CWE-1108←P →P CWE-111←P →P CWE-1113←P →P CWE-1116←P →P CWE-1118←P →P CWE-1119←P →P CWE-112←P →P CWE-1124←P →P CWE-113←P →P CWE-114←P →P CWE-115←P →P CWE-116←P →M CWE-1164←P →P CWE-117←P →P CWE-1173←P →P CWE-1174←P →P CWE-1176←P CWE-118←P →P CWE-119←P →P CWE-1190→P CWE-12→P CWE-120←M →M CWE-1204←P →P CWE-121←P →P CWE-122←P →P CWE-1221←P →P CWE-1223←P →P CWE-1224←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-1245→P CWE-1246←P →P CWE-125←P →P CWE-1254←P →P CWE-1255←P →P CWE-1256←P →M CWE-1257→P CWE-1258←P CWE-1259→P CWE-126←P →P CWE-1260←P →P CWE-1262→P CWE-1265←P →P CWE-127←P →P CWE-1270←P →P CWE-1272→P CWE-1275←P →P CWE-1279←P →P CWE-128←P →P CWE-1281←P →P CWE-1282→P CWE-1284←P →P CWE-1285←P →P CWE-1286←P →P CWE-1287←P →P CWE-1288←P →P CWE-1289←P →P CWE-129←P →P CWE-1291←P →P CWE-1295←P →P CWE-130←P →P CWE-131←M →P CWE-1312→P CWE-1314→P CWE-1316←P CWE-1320←P →P CWE-1321←P →P CWE-1322←P →P CWE-1325→P CWE-1327→P CWE-1332←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-138←P →P CWE-1385←P →P CWE-1386←P →P CWE-1389←P →P CWE-1391←P →M CWE-14←P →P CWE-140←P →P CWE-141←P →P CWE-142←M →M 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 →M 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←M →P CWE-173←P →P CWE-176←P →P CWE-177←P →P CWE-178←P →P CWE-179←P →P CWE-180←P →P CWE-182←P →P CWE-183←P →P CWE-184←P →P CWE-185←P →P CWE-186←P →P CWE-187←P →P CWE-188←P →P CWE-190←P →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-202←P →P CWE-204←P →P CWE-205←P →P CWE-207→P CWE-209→M CWE-210←P →M CWE-212←P →P CWE-214←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-230←P →P CWE-231←P →P CWE-232←P →P CWE-233←P →P CWE-234←P →P CWE-235←P →P CWE-236←P →P CWE-237←P →P CWE-239←P →P CWE-24←P →M CWE-240←P →P CWE-241←P →P CWE-242←P →P CWE-244←P →P CWE-248←P →P CWE-25←P →M CWE-252←P →P CWE-253←P →P CWE-256→P CWE-257←P →P CWE-258→P CWE-26←P →P CWE-260→P CWE-261→P CWE-267→P CWE-27←P →M CWE-270←P →P CWE-271→P CWE-272→P CWE-273→P CWE-274→P CWE-277←P →P CWE-278←P →P CWE-279→P CWE-28←P →M CWE-280→P CWE-288→P CWE-29←P →P CWE-290←P →P CWE-293→P CWE-296→P CWE-297←P →P CWE-298→P CWE-299→P CWE-30←P →P CWE-301→P CWE-302←P →P CWE-303←P →P CWE-304→P CWE-305→P CWE-31←P →P CWE-313←P →P CWE-314←P →P CWE-315←P →P CWE-316←P →P CWE-317→P CWE-318←P →P CWE-32←P →P CWE-322→P CWE-323→P CWE-325←P →P CWE-328←P →P CWE-329←P →P CWE-330←P →P CWE-331→P CWE-332→P CWE-333→P CWE-334→P CWE-335←P →P CWE-336→P CWE-337→P CWE-338→P CWE-339←P →P CWE-34←P →P CWE-340→P CWE-341←P →P CWE-342→P CWE-343→P CWE-344→P CWE-345→P CWE-346←P →P CWE-348→P CWE-349←P →P CWE-35←P →P CWE-350←P →P CWE-351←P →P CWE-353←P →P CWE-354←P →M CWE-356→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-37←P →P CWE-370→P CWE-372←P →P CWE-374←P →P CWE-377←P →P CWE-378←P →M CWE-379←P →P CWE-38←P →P CWE-384→P CWE-385→P CWE-386←P →P CWE-39←P →P CWE-390←P →P CWE-391←P →M CWE-392←P →P CWE-393←P →P CWE-394←P →P CWE-395←P →P CWE-396←P →P CWE-40←P →P CWE-401←P →P CWE-403←P →P CWE-407←P →P CWE-409→P CWE-41←P →M CWE-412→P CWE-413←P →P CWE-414←P →P CWE-415→P CWE-416←P →P CWE-42←P →P CWE-421←P →P CWE-422←P →P CWE-424←P →P CWE-425→P CWE-426←P →P CWE-427←P →P CWE-428←P →P CWE-43←P →P CWE-430←P →P CWE-431←P →P CWE-433←P →P CWE-436←P →P CWE-44←P →P CWE-440←P →P CWE-441←P →P CWE-444←P →P CWE-446→P CWE-447→P CWE-448←P →P CWE-449←P →P CWE-450←P →P CWE-451←P →P CWE-453←P →P CWE-454←P →M CWE-455←P →P CWE-456←P →P CWE-457←P →P CWE-459←P →P CWE-46←P →P CWE-460←P →P CWE-462←P →P CWE-463←P →P CWE-466←P →P CWE-467←P →P CWE-468←P →P CWE-469←P →P CWE-470←P →M CWE-471→P CWE-472←P →M CWE-473←P →P CWE-474←P →P CWE-475←P →P CWE-476←P →P CWE-477←P →P CWE-478←P →P CWE-479←P →P CWE-480←P →P CWE-482←P →P CWE-484←P →P CWE-488←P →P CWE-489←P →P CWE-491←P →M CWE-495←P →P CWE-499←P →P CWE-50←P →P CWE-501←P →M CWE-502→P CWE-507←P →P CWE-511←P →P CWE-515←P →P CWE-523→P CWE-524←P →P CWE-525←P →P CWE-526←P →P CWE-528←P CWE-531←P →P CWE-535←P →M CWE-539←P →P CWE-540←P →M CWE-541←P →P CWE-544←M →M CWE-547←P →P CWE-548←P →P CWE-549→P CWE-550←P →P CWE-551←P →P CWE-553←P CWE-561←P →P CWE-562←P →P CWE-564←P →P CWE-565←P →P CWE-566→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-591←P →P CWE-597←P →P CWE-598←P →P CWE-599←P →P CWE-600←P →P CWE-602←P →P CWE-603←P →P CWE-605←P →P CWE-606←P →P CWE-61←P →P CWE-610←P →P CWE-611←P →P CWE-614→P CWE-615←P →P CWE-616←P →P CWE-617←P →P CWE-618←P →P CWE-62←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 CWE-639→P CWE-64→P CWE-640→P CWE-641←P →P CWE-642→P CWE-643←P →M CWE-644←P →P CWE-646←P →P CWE-647←P →P CWE-648←P →P CWE-649←P →P CWE-65←P →P CWE-650←P →P CWE-652←P →P CWE-656→P CWE-657←P CWE-66←P →P CWE-662←P →P CWE-663←P →P CWE-664→P CWE-665←P →P CWE-667←P →P CWE-669←P CWE-67→P CWE-670←P →P CWE-672←P →P CWE-674→P CWE-675←P →P CWE-676←P →P CWE-680←P →P CWE-681←P →P CWE-682←P →P CWE-683←P →P CWE-686←P →P CWE-687←P →P CWE-688←P →P CWE-689←P →P CWE-69←P →P CWE-690←P →P CWE-691←P →P CWE-692←P →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 →M CWE-710←P →M 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 →P CWE-76←P →P CWE-760→P CWE-761←P →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 →M CWE-771←P →P CWE-772←P →P CWE-774←P →M CWE-775→P CWE-776←P →P CWE-777←P →P CWE-780←P →P CWE-782→P CWE-783←P →P CWE-784←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 →P CWE-792←P →P CWE-794←P →P CWE-798→P CWE-799→P CWE-80←P →P CWE-804←P →P CWE-805←P →P CWE-807←P →M CWE-81←P →P CWE-82←P →P CWE-820←P →P CWE-821←P →P CWE-822←P →P CWE-823←P →P CWE-824←P →P CWE-825←P →P CWE-826←P →P CWE-827←P →P CWE-828←P →P CWE-83←P →M CWE-830←P →P CWE-832←P →P CWE-833←P →P CWE-834←P →P CWE-835→P CWE-836→P CWE-837←P →P CWE-838←M →P CWE-839←P →P CWE-84←P →P CWE-841→P CWE-843←P →P CWE-85←P →P CWE-86←P →P CWE-87←P →M CWE-88←P →P CWE-89→P CWE-90←P →P CWE-908←P →P CWE-909→P CWE-91←P →P CWE-910←P →P CWE-911←P →P CWE-912→P CWE-913←P →P CWE-914←P →P CWE-915←P →M CWE-916→P CWE-917←P →P CWE-923→P CWE-925←P →P CWE-926←P →M CWE-927←P →P CWE-93←P →P CWE-939←P →P CWE-94→P CWE-940→P CWE-941→P CWE-942←P →P CWE-943←P →P CWE-95←P →P CWE-96←P →P CWE-97←P →P CWE-98←P →P CWE-99←P →P

Why these map — AI rationale (under review)

CWE-1076mostlyprevents — Secure coding standards directly address adherence to coding conventions.
CWE-116mostlyprevents — Secure coding standards explicitly require correct output encoding and escaping to preserve message structure.
CWE-120mostlyprevents — Secure coding directly requires bounds-checked memory operations, addressing the root cause of CWE-120.
CWE-1256mostlyprevents — Secure coding practices can enforce input validation and capability checks on hardware-control APIs, reducing the likelihood of unintended register or memory changes.
CWE-1391mostlyprevents — Secure-coding rules can prohibit hard-coded passwords, yet coverage depends on specific coding standards adopted.
CWE-142mostlyprevents — Secure coding explicitly calls for proper escaping or encoding of value delimiters in downstream contexts.
CWE-156mostlyprevents — Secure coding standards directly require proper input sanitization and neutralization of special elements like whitespace.
CWE-209mostlyprevents — Secure coding standards explicitly forbid exposing sensitive data in errors.
CWE-210mostlyprevents — Secure coding standards directly prohibit embedding sensitive information in generated error messages.
CWE-24mostlyprevents — Secure coding standards require neutralizing ../ sequences and canonicalizing paths before file operations.
CWE-25mostlyprevents — Secure coding standards require canonicalization and neutralization of '../' sequences in path construction.
CWE-27mostlyprevents — Secure coding standards require neutralizing '../' sequences and using safe file APIs, eliminating this exact weakness.
CWE-28mostlyprevents — Secure coding standards explicitly forbid unsafe path construction and mandate neutralization of .. sequences.
CWE-354mostlyprevents — Secure coding standards require proper implementation and validation of checksums or MACs.
CWE-378mostlyprevents — Secure coding standards directly prohibit insecure temporary file creation and permissions.
CWE-391mostlyprevents — Secure coding standards directly prohibit ignoring exceptions and unchecked errors.
CWE-41mostlyprevents — Secure coding standards directly require canonical path resolution and input sanitization to prevent equivalence attacks.
CWE-454mostlyprevents — Secure coding standards directly prohibit initializing trusted data from untrusted sources.
CWE-470mostlyprevents — Secure coding standards directly forbid unsafe reflection and require whitelisting or static alternatives.
CWE-472mostlyprevents — Secure coding standards require server-side verification of client-supplied data, eliminating the root cause of external control of immutable parameters.
CWE-491mostlyprevents — Secure coding standards directly require final clone or defensive-copy patterns to block object hijacking.
CWE-501mostlyprevents — Secure coding standards can enforce input validation and data tagging, but do not guarantee architectural separation.
CWE-535mostlyprevents — Secure coding standards directly require handling exceptions without exposing internal details.
CWE-540mostlyprevents — Secure coding standards explicitly prohibit hard-coding credentials or sensitive data.
CWE-544mostlyprevents — Secure coding explicitly calls for uniform, standardized error handling to avoid introducing weaknesses.
CWE-643mostlyprevents — Secure coding standards require proper neutralization of untrusted input in XPath expressions.
CWE-707mostlyprevents — Secure coding standards directly require proper neutralization of inputs and outputs, eliminating CWE-707.
CWE-710mostlyprevents — Directly requires secure coding practices and standards.
CWE-77mostlyprevents — Secure coding standards require proper escaping and parameterization of commands, directly eliminating CWE-77.
CWE-774mostlyprevents — Secure coding standards explicitly require limits on file-handle allocation.
CWE-807mostlyprevents — Secure coding standards directly prohibit using untrusted inputs for security-critical decisions.
CWE-83mostlyprevents — Secure coding standards require proper escaping of untrusted data in HTML attributes, directly eliminating CWE-83.
CWE-87mostlyprevents — Secure coding standards require proper neutralization of alternate script syntax, directly eliminating CWE-87.
CWE-915mostlyprevents — Secure coding standards explicitly forbid unsafe dynamic attribute assignment and require property allow-lists.
CWE-926mostlyprevents — Secure-coding standards require explicit permission declarations and intent-filter restrictions to avoid improper exports.
CWE-1004partialprevents — Secure coding standards explicitly require the HttpOnly flag for sensitive cookies.
CWE-102partialprevents — Secure coding rules directly prevent duplicate Struts validation forms.
CWE-1021partialprevents — Secure coding practices directly require implementation of frame-busting headers or CSP frame-ancestors directives.
CWE-1022partialprevents — Secure coding standards directly require the use of rel="noopener noreferrer" on external links, eliminating the weakness.
CWE-1023partialprevents — Secure coding standards can forbid incomplete comparisons, but the control covers a wide range of coding issues.
CWE-1024partialprevents — Secure coding standards directly require type-safe comparisons and compiler warnings for incompatible types.
CWE-1025partialprevents — Secure coding standards directly address proper comparison logic and factor selection.
CWE-1037partialprevents — Secure coding standards must explicitly forbid optimizations that eliminate security-critical operations.
CWE-1038partialprevents — Secure coding standards must address risks from compiler or build-tool optimizations that alter intended security behavior.
CWE-1039partialprevents — Secure coding practices can incorporate input sanitization and adversarial robustness checks for ML models.
CWE-1049partialprevents — Secure coding rules directly prohibit or limit complex joins and sub-queries on large tables.
CWE-1050partialprevents — Secure coding standards explicitly forbid resource-consuming loops.
CWE-1051partialprevents — Secure coding standards typically ban hard-coded network resources, yet the control covers many other practices.
CWE-1055partialprevents — Secure coding standards can explicitly prohibit or limit multiple inheritance from concrete classes.
CWE-1056partialprevents — Secure coding standards explicitly forbid variadic parameter lists that bypass static analysis and type safety.
CWE-1057partialprevents — Secure coding standards prohibit direct data access outside the approved data-manager abstraction.
CWE-1058partialprevents — Secure coding standards directly prohibit non-final static fields accessed by multiple threads without synchronization.
CWE-1066partialprevents — Secure coding standards directly address implementing required serialization methods for data elements.
CWE-1067partialprevents — Secure coding standards explicitly require use of indexes and avoidance of full-table scans.
CWE-1072partialprevents — Secure coding standards can discourage direct connection creation but do not explicitly require connection pooling.
CWE-1077partialprevents — Secure coding rules can mandate safe floating-point comparison practices.
CWE-1078partialprevents — Secure coding explicitly requires adherence to style and formatting standards that directly address CWE-1078.
CWE-1083partialprevents — Secure coding standards explicitly forbid direct data access outside the approved data manager, addressing the root cause of CWE-1083.
CWE-1088partialprevents — Secure coding standards directly require proper timeout configuration for synchronous remote calls.
CWE-1091partialprevents — Secure coding standards directly address proper destructor/finalizer invocation to avoid resource leaks.
CWE-11partialprevents — Secure coding practices discourage leaving debug binaries in production but do not explicitly govern configuration settings.
CWE-1100partialprevents — Secure coding standards mandate separating platform-specific code into distinct modules to reduce coupling.
CWE-1102partialprevents — Secure coding standards explicitly prohibit or flag use of machine-dependent data representations, directly mitigating this weakness.
CWE-1106partialprevents — Secure coding standards explicitly require use of symbolic constants instead of magic literals.
CWE-1107partialprevents — Secure coding standards explicitly call for centralized constant definitions to avoid duplication and errors.
CWE-1108partialprevents — Secure coding standards explicitly ban or restrict global variables to reduce coupling and side-effects.
CWE-111partialprevents — Secure coding standards explicitly ban or tightly control unsafe JNI calls, directly mitigating the weakness.
CWE-1113partialprevents — Secure coding policy can mandate consistent comment style as part of coding standards.
CWE-1116partialprevents — Secure coding practices typically mandate accurate, up-to-date comments as part of coding standards.
CWE-1118partialprevents — Secure coding standards mandate documented error-handling practices.
CWE-1119partialprevents — Secure coding standards explicitly prohibit excessive unconditional branching and mandate structured control flow.
CWE-112partialprevents — Secure coding standards directly require validation of untrusted XML against a proper schema.
CWE-1124partialprevents — Secure coding standards explicitly forbid or limit excessive nesting to improve readability and reduce defects.
CWE-113partialprevents — Secure coding standards require neutralization of CRLF sequences before inclusion in HTTP headers.
CWE-114partialprevents — Secure coding standards explicitly forbid executing or loading code from untrusted sources.
CWE-115partialprevents — Secure coding standards require strict input validation and canonical forms to eliminate misinterpretation vulnerabilities.
CWE-1164partialprevents — Secure coding standards explicitly require removal of unused or dead code.
CWE-117partialprevents — Secure coding practices mandate input validation and output encoding, directly preventing log injection.
CWE-1173partialprevents — Secure coding directly requires correct use of language-provided or approved validation libraries.
CWE-1174partialprevents — Secure coding practices directly require proper use of ASP.NET model validation attributes.
CWE-118partialprevents — Secure coding standards directly require bounds checking and safe array access to prevent range errors.
CWE-119partialprevents — Secure coding standards explicitly forbid unsafe buffer operations, directly eliminating CWE-119.
CWE-1190partialprevents — Secure coding practices can prevent early DMA initialization in firmware code.
CWE-12partialprevents — Secure coding practices include avoiding default error messages that leak implementation details.
CWE-1204partialprevents — Requires secure coding practices that include proper cryptographic API usage and IV handling.
CWE-121partialprevents — Secure coding standards explicitly forbid unsafe buffer handling that causes CWE-121.
CWE-122partialprevents — Secure coding standards directly prescribe techniques (safe functions, bounds checks) that prevent heap-based buffer overflows.
CWE-1221partialprevents — Secure coding practices for HDL reduce the likelihood of defining insecure register defaults or IP parameters.
CWE-1223partialprevents — Secure coding guidelines for hardware description languages can enforce proper write-once attribute protection and initialization order.
CWE-123partialprevents — Secure coding standards explicitly forbid unsafe buffer operations that enable arbitrary memory writes.
CWE-1231partialprevents — Secure coding can avoid software paths that modify lock bits, yet cannot guarantee the underlying hardware prevents such writes.
CWE-1236partialprevents — Secure coding standards explicitly require neutralization of special characters when writing CSV files.
CWE-124partialprevents — Secure coding standards explicitly forbid unsafe pointer arithmetic and mandate bounds checks.
CWE-1240partialprevents — Secure coding standards prohibit non-standard or disallowed cryptographic algorithms.
CWE-1241partialprevents — Secure coding standards prohibit use of weak or predictable RNG functions.
CWE-1242partialprevents — Secure coding standards and peer review detect and prohibit undocumented or debug features.
CWE-1245partialprevents — Secure coding guidelines can extend to hardware description languages to prevent FSM coding errors.
CWE-1246partialprevents — Secure coding practices must implement or correctly invoke wear-leveling algorithms for limited-write non-volatile memories.
CWE-125partialprevents — Secure coding standards explicitly forbid unsafe pointer arithmetic and mandate bounds-checked reads, eliminating CWE-125.
CWE-1254partialprevents — Secure coding standards can require constant-time comparison functions to avoid stepwise string comparison vulnerabilities.
CWE-1255partialprevents — Secure coding standards can mandate constant-time comparison routines and power-analysis-resistant implementations.
CWE-1257partialprevents — Secure coding practices can catch alias-permission mismatches during implementation.
CWE-1259partialprevents — Secure coding practices reduce the likelihood of token-assignment bugs but do not define the policy.
CWE-126partialprevents — Secure coding standards directly require bounds-checked buffer access, mitigating over-reads.
CWE-1260partialprevents — Secure coding standards mandate checks for address-range overlap and proper memory-protection configuration, mitigating the weakness at implementation time.
CWE-1262partialprevents — Secure coding practices prevent unauthorized register access in firmware and drivers.
CWE-1265partialprevents — Secure coding standards and reviews directly target reentrancy issues and non-reentrant code patterns.
CWE-127partialprevents — Secure coding standards directly require bounds checking and safe pointer arithmetic.
CWE-1270partialprevents — Secure coding standards reduce the likelihood of implementation errors that produce incorrect tokens.
CWE-1272partialprevents — Secure-coding practices can prevent the weakness if applied, but the control itself is broader than this specific flaw.
CWE-1275partialprevents — Secure coding standards directly require proper SameSite settings to prevent CSRF.
CWE-1279partialprevents — Secure coding practices can prevent cryptographic operations before supporting units are ready.
CWE-128partialprevents — Secure coding standards directly require avoidance of integer overflow and wrap-around conditions.
CWE-1281partialprevents — Secure coding guidelines can require avoidance of known problematic instruction sequences and use of validated libraries.
CWE-1282partialprevents — Secure coding practices can avoid storing immutable data in writable memory but do not address hardware-level protection.
CWE-1284partialprevents — Secure coding standards require explicit checks on numeric quantity inputs, fully addressing CWE-1284.
CWE-1285partialprevents — Secure coding standards directly require validation of indices, positions, and offsets before use.
CWE-1286partialprevents — Secure coding standards directly require proper syntactic validation of all inputs.
CWE-1287partialprevents — Secure coding standards directly require proper type validation of all external inputs.
CWE-1288partialprevents — Secure coding standards explicitly require validation of interrelated input fields to prevent CWE-1288.
CWE-1289partialprevents — Secure coding standards directly require correct validation of resource identifiers and equivalence checks.
CWE-129partialprevents — Secure coding standards explicitly require bounds checking and validation of array indices derived from untrusted data.
CWE-1291partialprevents — Secure-coding standards can mandate distinct signing keys and prohibit reuse between debug and production builds.
CWE-1295partialprevents — Secure coding practices mandate removal or protection of debug output containing sensitive information before release.
CWE-130partialprevents — Secure coding standards directly prohibit improper length handling and enforce defensive parsing practices.
CWE-131partialprevents — Secure coding standards directly require correct buffer-size calculations.
CWE-1312partialprevents — Secure coding practices can avoid mirror-region oversights, yet the weakness is primarily a hardware-design flaw.
CWE-1314partialprevents — Secure coding practices can prevent software from writing to protected parameter areas but do not address the underlying hardware protection gap.
CWE-1320partialprevents — Secure coding practices reduce the risk of improper outbound error handling.
CWE-1321partialprevents — Secure coding standards directly prohibit unsafe prototype attribute assignment and require defensive checks.
CWE-1322partialprevents — Secure coding standards directly prohibit blocking operations inside single-threaded event loops.
CWE-1325partialprevents — Secure coding standards can require explicit limits on memory per object, yet fixing the weakness alone does not satisfy the full control.
CWE-1327partialprevents — Secure coding guidance can catch hard-coded 0.0.0.0 bindings during development but is not the primary mitigation.
CWE-1333partialprevents — Secure coding standards explicitly prohibit or limit the use of inefficient regular expressions.
CWE-1335partialprevents — Secure coding directly addresses the use of safe bitwise-shift operations and bounds checking.
CWE-1336partialprevents — Secure coding standards require proper escaping or sandboxing of template directives, directly mitigating CWE-1336.
CWE-134partialprevents — Secure coding standards directly forbid the use of untrusted format strings and prescribe safe alternatives.
CWE-1341partialprevents — Secure-coding standards directly address proper resource-release discipline, preventing multiple-close errors.
CWE-135partialprevents — Secure coding directly addresses proper calculation of multi-byte string lengths through coding standards and reviews.
CWE-138partialprevents — Secure coding standards require proper escaping and neutralization of special elements, directly eliminating CWE-138.
CWE-1385partialprevents — Secure coding standards can explicitly require origin validation for WebSocket connections.
CWE-1386partialprevents — Secure coding standards directly address safe file/directory handling to prevent insecure junction operations.
CWE-1389partialprevents — Secure coding standards directly mandate safe numeric parsing and validation of input bases.
CWE-14partialprevents — Secure coding rules can mandate explicit volatile or memory-clearing patterns that survive compiler optimization.
CWE-140partialprevents — Secure coding explicitly requires proper neutralization of delimiters to prevent injection and parsing flaws.
CWE-141partialprevents — Secure coding standards require proper escaping or neutralization of parameter delimiters in all downstream calls.
CWE-143partialprevents — Secure coding standards require proper escaping or neutralization of record delimiters in all downstream interfaces.
CWE-144partialprevents — Secure coding standards directly require proper neutralization of line delimiters in input handling.
CWE-145partialprevents — Secure coding standards require correct neutralization of section delimiters in all downstream outputs.
CWE-146partialprevents — Secure coding standards require proper neutralization of special elements, directly eliminating this weakness.
CWE-147partialprevents — Secure coding standards require explicit neutralization of input terminators, directly eliminating this weakness.
CWE-148partialprevents — Secure coding standards directly require proper neutralization of input leaders, covering most of this weakness.
CWE-149partialprevents — Secure coding standards require proper escaping or parameterization, directly eliminating CWE-149.
CWE-150partialprevents — Secure coding standards require proper escaping and neutralization of control characters before downstream processing.
CWE-153partialprevents — Secure coding standards require proper neutralization of substitution characters in all input handling.
CWE-154partialprevents — Secure coding standards require proper escaping or parameterization of all variable-name delimiters, directly eliminating CWE-154.
CWE-155partialprevents — Secure coding standards explicitly require proper escaping or neutralization of wildcard and matching symbols.
CWE-157partialprevents — Secure coding standards directly mandate sanitizing paired delimiters to prevent injection or parsing errors.
CWE-158partialprevents — Secure coding standards explicitly require proper neutralization of null bytes and other metacharacters.
CWE-159partialprevents — Secure coding standards require proper escaping, quoting and validation of special characters in user input.
CWE-160partialprevents — Secure coding standards require proper neutralization of leading special elements in all input paths.
CWE-162partialprevents — Secure coding standards directly require correct neutralization of trailing special elements in input handling.
CWE-164partialprevents — Secure coding standards require proper escaping and neutralization of special elements, directly mitigating CWE-164.
CWE-166partialprevents — Secure coding standards directly require validation for missing special elements, covering most of this weakness.
CWE-167partialprevents — Secure coding standards directly require correct handling of all input elements, eliminating this weakness.
CWE-168partialprevents — Secure coding standards explicitly require proper handling of special characters and reserved words.
CWE-170partialprevents — Secure coding standards directly require correct null termination of strings and arrays.
CWE-172partialprevents — Secure coding explicitly requires correct character encoding and output escaping to avoid CWE-172.
CWE-173partialprevents — Secure coding standards explicitly require proper handling of alternate encodings and canonical forms to avoid injection or bypass flaws.
CWE-176partialprevents — Secure coding standards directly address proper Unicode and character-encoding validation.
CWE-177partialprevents — Secure coding standards mandate proper handling and decoding of encoded inputs, eliminating CWE-177.
CWE-178partialprevents — Secure coding guidelines must mandate explicit case handling to prevent inconsistent lookups.
CWE-179partialprevents — Secure coding standards explicitly require canonicalization before validation to avoid CWE-179.
CWE-180partialprevents — Secure coding standards explicitly require canonicalize-then-validate to eliminate CWE-180.
CWE-182partialprevents — Secure coding standards explicitly forbid unsafe filtering or collapsing of security-critical values.
CWE-183partialprevents — Secure coding standards enforce rigorous input validation and reject unsafe values, mitigating permissive allow-list weaknesses.
CWE-184partialprevents — Secure coding standards directly require exhaustive allow-lists or complete deny-lists for inputs, addressing the root cause of incomplete disallowed-input lists.
CWE-185partialprevents — Secure coding standards directly address proper construction and review of regular expressions.
CWE-186partialprevents — Secure coding standards directly mandate proper regex design and testing, largely preventing this weakness.
CWE-187partialprevents — Secure coding standards can explicitly prohibit substring-based comparisons for security decisions.
CWE-188partialprevents — Secure coding standards and reviews target unsafe reliance on implicit data layout.
CWE-190partialprevents — Secure coding standards explicitly forbid unsafe integer operations and mandate overflow-safe constructs.
CWE-191partialprevents — Secure coding standards directly prescribe safe integer handling and overflow/underflow prevention.
CWE-192partialprevents — Secure coding standards directly address integer coercion through language-specific rules and static analysis.
CWE-193partialprevents — Secure coding directly addresses off-by-one errors through coding standards and peer review.
CWE-194partialprevents — Secure coding standards directly address integer handling and sign-extension pitfalls in source code.
CWE-195partialprevents — Secure coding standards directly prohibit unsafe signed-to-unsigned casts and require defensive checks.
CWE-196partialprevents — Secure coding standards directly address avoiding unsafe casts from unsigned to signed integers.
CWE-197partialprevents — Secure coding standards directly prohibit unsafe narrowing conversions and truncation.
CWE-198partialprevents — Secure coding standards directly require correct byte-order handling when processing external input.
CWE-20partialprevents — Requiring language-specific secure coding standards, peer review, SAST and documented mitigation of common programming errors forces validation of all inputs before they are trusted.
CWE-200partialprevents — Source-code protection via configuration-management tools and access-control rules reduces the chance that sensitive implementation details or credentials will be exposed to unauthorized readers.
CWE-201partialprevents — Secure-coding standards explicitly forbid hard-coded or unfiltered sensitive data in outbound messages.
CWE-202partialprevents — Secure coding practices can implement query restrictions or result-set limits to reduce inference risk.
CWE-204partialprevents — Secure coding standards explicitly require uniform error handling to prevent information leakage.
CWE-205partialprevents — Secure coding standards can require consistent, non-informative error messages and timing behavior.
CWE-207partialprevents — Secure coding practices can prevent implementation differences that leak product identity.
CWE-212partialprevents — Secure-coding standards can mandate removal of secrets and PII from code and logs.
CWE-214partialprevents — Secure coding practices can prevent passing sensitive data via command-line arguments or environment variables.
CWE-215partialprevents — Secure coding standards explicitly prohibit embedding secrets or debug statements.
CWE-219partialmitigates — Secure coding standards explicitly forbid placing sensitive files under the web root.
CWE-22partialprevents — Secure coding standards explicitly forbid unsafe path construction and mandate safe APIs.
CWE-226partialprevents — Secure coding practices can prevent leaving sensitive data in memory or files before reuse.
CWE-228partialprevents — Secure coding explicitly requires validation of all input syntax and structure, directly eliminating CWE-228.
CWE-229partialprevents — Secure coding standards mandate proper handling of missing or undefined parameters, directly addressing this weakness.
CWE-23partialprevents — Secure coding standards require neutralizing path traversal sequences, directly addressing CWE-23.
CWE-230partialprevents — Secure coding standards can require validation that every supplied parameter has a non-null value.
CWE-231partialprevents — Secure coding standards directly require validation of the exact number and type of input parameters.
CWE-232partialprevents — Secure coding standards directly require defensive checks for undefined or unsupported parameter values.
CWE-233partialprevents — Secure coding standards directly address proper handling of function parameters and input validation.
CWE-234partialprevents — Secure coding standards directly address proper argument validation and handling of missing or unexpected parameters.
CWE-235partialprevents — Secure coding standards directly require proper handling of input parameters and arrays to avoid CWE-235.
CWE-236partialprevents — Secure coding standards directly address proper handling of undefined or unsupported parameters during implementation.
CWE-237partialprevents — Secure coding standards directly address proper handling and validation of structured data elements.
CWE-239partialprevents — Secure coding standards typically include rules for validating element completeness, directly addressing CWE-239.
CWE-240partialprevents — Secure coding standards address consistent parsing and validation of structural elements.
CWE-241partialprevents — Secure coding standards explicitly require type checking and input sanitization, directly addressing improper handling of unexpected data types.
CWE-242partialprevents — Secure coding standards explicitly ban or restrict inherently dangerous functions.
CWE-244partialprevents — Mandates secure coding practices that include proper memory sanitization before release.
CWE-248partialprevents — Secure coding standards directly require catching and handling exceptions to prevent crashes or leaks.
CWE-252partialprevents — Secure coding explicitly requires checking return values to avoid CWE-252.
CWE-253partialprevents — Secure coding explicitly demands checking return values, covering most of CWE-253.
CWE-256partialprevents — Secure coding practices would prevent developers from writing code that stores passwords in plaintext.
CWE-257partialprevents — Secure coding practices can prevent developers from implementing recoverable password storage.
CWE-258partialprevents — Secure coding standards explicitly forbid hard-coded or empty credentials.
CWE-26partialprevents — Secure coding standards require neutralizing '../' sequences and canonicalizing paths before file operations.
CWE-260partialprevents — Secure coding standards discourage hard-coded credentials, reducing the likelihood of passwords in configuration files.
CWE-261partialprevents — Enforces secure coding practices that would reject trivial password encoding.
CWE-267partialprevents — Secure coding practices can avoid unsafe privilege implementations but do not address privileges already defined.
CWE-270partialprevents — Secure-coding guidelines can prevent common privilege-switch bugs yet are not exhaustive.
CWE-271partialprevents — Secure coding standards can mandate privilege-dropping calls, yet the control is broader than this single weakness.
CWE-272partialprevents — Secure coding practices can prevent least-privilege violations but do not constitute the control itself.
CWE-273partialprevents — Secure coding practices can prevent missing privilege-drop checks, but the control itself does not mandate verification of privilege changes.
CWE-274partialprevents — Secure-coding standards may require proper privilege-error handling, but the control does not guarantee it.
CWE-277partialprevents — Secure coding standards can explicitly require setting restrictive permissions at object creation, directly mitigating insecure inheritance.
CWE-278partialprevents — Secure coding standards can mandate explicit permission setting instead of relying on inherited defaults.
CWE-279partialprevents — Secure coding practices can prevent the coding error that leads to incorrect permission assignment.
CWE-280partialprevents — Secure-coding standards require proper permission checks before resource access.
CWE-288partialprevents — Secure coding practices help avoid bypass vulnerabilities but do not address deployed instances.
CWE-29partialprevents — Secure coding standards directly require neutralizing path traversal sequences such as '\..\filename'.
CWE-290partialprevents — Secure coding practices reduce implementation errors that enable spoofing.
CWE-293partialprevents — Secure coding standards would forbid using Referer for authentication, mitigating the weakness at the source.
CWE-296partialprevents — Secure coding standards address correct certificate chain validation.
CWE-297partialprevents — Secure coding practices include implementing proper certificate and hostname validation in code.
CWE-298partialprevents — Secure coding practices can include certificate validation checks but do not address the control's broader scope.
CWE-299partialprevents — Secure coding practices should include proper certificate revocation verification.
CWE-30partialprevents — Secure coding standards require neutralizing directory traversal sequences such as '\..\' in path construction.
CWE-301partialprevents — Secure coding practices can implement proper challenge-response logic, but the control is broader than this single weakness.
CWE-302partialprevents — Secure-coding standards prohibit trusting client-controlled data for authentication decisions.
CWE-303partialprevents — Secure coding practices reduce the likelihood of incorrect authentication algorithm implementation.
CWE-304partialprevents — Secure coding practices can prevent missing auth steps, yet the control is not specific to authentication.
CWE-305partialprevents — Secure coding practices help prevent the primary weakness that enables authentication bypass.
CWE-31partialprevents — Secure coding standards require canonicalization and whitelist validation that eliminate CWE-31.
CWE-313partialprevents — Secure coding standards can require encryption of sensitive data before storage.
CWE-314partialprevents — Secure coding standards require encryption or protected storage instead of cleartext registry values.
CWE-315partialprevents — Requires secure coding practices that would eliminate storing sensitive data in cleartext cookies.
CWE-316partialprevents — Secure-coding standards explicitly require avoiding plaintext storage of secrets in RAM.
CWE-317partialprevents — Secure coding practices can prevent the weakness but do not address the control's broader scope.
CWE-318partialprevents — Secure coding standards explicitly forbid embedding secrets or sensitive data in binaries.
CWE-32partialprevents — Secure coding standards require canonicalization and filtering of '...' sequences, directly eliminating CWE-32.
CWE-322partialprevents — Secure coding standards can enforce authenticated key exchange in cryptographic implementations.
CWE-323partialprevents — Secure-coding rules can require unique nonces, but the control is broader than this single weakness.
CWE-325partialprevents — Requires secure coding practices that would catch missing cryptographic steps during development.
CWE-328partialprevents — Requires secure coding standards that forbid weak hash functions in source code.
CWE-329partialprevents — Requires secure coding practices that eliminate predictable IV usage in CBC implementations.
CWE-330partialprevents — Secure coding standards explicitly prohibit use of weak or predictable random number generators.
CWE-331partialprevents — Secure-coding rules can explicitly forbid weak random-number generation.
CWE-332partialprevents — Secure coding standards prohibit weak PRNG usage and require cryptographically secure random functions.
CWE-333partialprevents — Secure-coding rules can require fallback or health checks for TRNG entropy sources.
CWE-334partialprevents — Secure-coding standards explicitly call for cryptographically strong random number generation.
CWE-335partialprevents — Secure-coding standards mandate correct PRNG seeding to avoid predictable random values.
CWE-336partialprevents — Secure-coding standards can forbid static seeds, yet the control is broader than this single weakness.
CWE-337partialprevents — Secure coding standards explicitly forbid predictable PRNG seeds.
CWE-338partialprevents — Secure coding standards prohibit use of weak PRNGs in security contexts.
CWE-339partialprevents — Requires secure coding practices that include proper PRNG seeding and entropy sources.
CWE-34partialprevents — Secure coding standards require canonicalization and neutralization of '....//' sequences, directly eliminating this weakness.
CWE-340partialprevents — Secure-coding standards explicitly forbid predictable random functions and mandate cryptographically secure RNGs, preventing the weakness at the source.
CWE-341partialprevents — Secure coding practices explicitly forbid use of predictable state (time, PID, counters) for secrets or tokens.
CWE-342partialprevents — Secure coding standards prohibit predictable random-value generation.
CWE-343partialprevents — Secure coding standards prohibit predictable RNG implementations.
CWE-344partialprevents — Secure coding standards can prohibit invariant literals, but coverage depends on specific rule sets.
CWE-345partialprevents — Secure coding practices include implementing proper data authenticity checks.
CWE-346partialprevents — Secure coding practices include implementing proper origin validation to prevent spoofing.
CWE-348partialprevents — Secure coding practices can enforce checks that prefer or validate the more trusted data source.
CWE-349partialprevents — Secure coding standards mandate input sanitization and provenance checks that prevent acceptance of extraneous untrusted data.
CWE-35partialprevents — Secure coding standards explicitly forbid unsafe path concatenation and mandate canonicalization routines.
CWE-350partialprevents — Secure coding practices can replace reverse-DNS checks with cryptographically verified identities.
CWE-351partialprevents — Secure coding standards directly address proper type distinction and validation to prevent type-related flaws.
CWE-353partialprevents — Secure coding standards can require integrity verification mechanisms in protocols.
CWE-356partialprevents — Secure coding practices can embed user warnings before unsafe operations.
CWE-357partialprevents — Secure coding practices include implementing noticeable, effective UI warnings for risky actions.
CWE-358partialprevents — Secure coding practices directly address correct implementation of security-relevant checks in standardized algorithms.
CWE-36partialprevents — Secure coding standards directly require neutralization of absolute path sequences in pathname construction.
CWE-362partialprevents — Secure coding standards explicitly forbid unsafe concurrent access patterns and mandate atomic operations or locks.
CWE-363partialprevents — Secure coding standards directly address TOCTOU and link-following vulnerabilities, covering most of the weakness while the control also covers many other issues.
CWE-364partialprevents — Secure coding standards directly prohibit race-prone signal handlers.
CWE-366partialprevents — Secure coding standards directly require proper synchronization primitives to prevent race conditions.
CWE-368partialprevents — Secure coding standards can mandate atomic operations and synchronization primitives for context switches.
CWE-369partialprevents — Secure coding standards directly require validation to prevent divide-by-zero and similar runtime faults.
CWE-37partialprevents — Secure coding standards directly require validation of file-path inputs to stop absolute-path traversal.
CWE-370partialprevents — Secure coding practices can prevent missing revocation checks, but eliminating this weakness does not address broader secure-coding objectives.
CWE-372partialprevents — Secure coding standards can require defensive checks against invalid or ambiguous internal states.
CWE-374partialprevents — Secure coding standards directly address CWE-374 by requiring defensive copies or immutable interfaces when calling untrusted methods.
CWE-377partialprevents — Secure coding standards explicitly require safe temporary-file APIs and permissions.
CWE-379partialprevents — Secure coding standards directly require safe temporary-file creation with restrictive permissions.
CWE-38partialprevents — Secure-coding standards require canonicalization and whitelist validation of file paths, eliminating this weakness.
CWE-384partialprevents — Secure-coding standards can forbid session fixation, but removing the flaw does not achieve the entire coding standard.
CWE-385partialprevents — Secure coding guidelines may recommend constant-time algorithms but coverage is not guaranteed.
CWE-386partialprevents — Secure coding standards can mandate direct object handles or validated lookups rather than symbolic names that drift.
CWE-39partialprevents — Secure coding standards directly require rejecting or normalizing absolute drive-letter paths in file operations.
CWE-390partialprevents — Secure coding standards typically require explicit error handling, reducing the likelihood of silent failures.
CWE-392partialprevents — Secure coding standards require functions to return appropriate error codes or status values.
CWE-393partialprevents — Secure coding standards directly address proper return-value handling and error indication.
CWE-394partialprevents — Secure coding standards directly mandate checking all legitimate return values and status codes.
CWE-395partialprevents — Secure coding rules explicitly forbid catching NullPointerException to detect null dereferences.
CWE-396partialprevents — Secure coding standards explicitly prohibit overly broad exception handlers that mask errors and create exploitable paths.
CWE-40partialprevents — Secure coding standards directly require validation and sanitization of file paths including UNC shares.
CWE-401partialprevents — Secure coding standards directly require proper allocation/deallocation, covering most of this weakness.
CWE-403partialprevents — Secure coding rules require closing inherited file descriptors before spawning child processes.
CWE-407partialprevents — Secure coding practices can include guidelines to avoid or mitigate inefficient algorithms.
CWE-409partialprevents — Secure coding practices directly require bounds checking and safe handling of compressed data.
CWE-412partialprevents — Secure coding guidelines can enforce internal-only lock control during implementation.
CWE-413partialprevents — Secure coding standards directly prohibit missing or incorrect resource locks.
CWE-414partialprevents — Secure coding standards require explicit lock acquisition checks before operating on shared resources.
CWE-415partialprevents — Secure coding standards directly address proper use of free() and similar functions.
CWE-416partialprevents — Secure coding standards directly prescribe avoidance of use-after-free patterns.
CWE-42partialprevents — Secure coding standards directly require validation of path inputs to prevent traversal via trailing dots.
CWE-421partialprevents — Secure coding guidelines help developers avoid race conditions on alternate communication paths.
CWE-422partialprevents — Secure coding practices include validating message sources and avoiding elevated processes that accept unauthenticated Windows messages.
CWE-424partialprevents — Secure coding practices reduce the likelihood of unprotected alternate paths in source code.
CWE-425partialprevents — Secure coding practices reduce the likelihood of missing authorization checks, yet do not guarantee coverage.
CWE-426partialprevents — Secure coding standards require absolute paths or integrity-checked search paths, directly mitigating CWE-426.
CWE-427partialprevents — Secure coding practices directly address the use of fixed or controlled search paths that can be influenced by unintended actors.
CWE-428partialprevents — Secure coding standards directly mandate quoting search paths and avoiding unsafe path construction.
CWE-43partialprevents — Secure coding standards directly require sanitizing and rejecting malformed filenames like multiple trailing dots.
CWE-430partialprevents — Secure coding standards can enforce correct handler registration and prevent mis-wiring.
CWE-431partialprevents — Secure coding standards explicitly call for implementing handlers for all foreseeable inputs and exceptions.
CWE-433partialprevents — Secure coding practices require explicit server configuration and file-extension handling to avoid raw content delivery.
CWE-436partialprevents — Secure coding standards can enforce canonical input handling and strict protocol compliance to avoid misinterpretation between products.
CWE-44partialprevents — Secure coding standards directly require rejecting or normalizing malformed paths such as internal dots.
CWE-440partialprevents — Secure coding practices enforce adherence to functional specifications during implementation.
CWE-441partialprevents — Secure-coding standards can require explicit checks that preserve and verify the original requester identity before acting.
CWE-444partialprevents — Secure coding standards can require strict HTTP header and request validation to prevent smuggling.
CWE-446partialprevents — Secure coding practices help avoid implementation bugs that cause UI discrepancies, though the control is not focused on UI correctness.
CWE-447partialprevents — Secure coding practices reduce the chance of leaving security features unimplemented.
CWE-448partialprevents — Secure coding standards discourage leaving obsolete UI code without user notification.
CWE-449partialprevents — Secure coding practices enforce correct control-flow and input-to-action mapping in the UI layer.
CWE-450partialprevents — Secure coding practices directly address unambiguous input parsing and user confirmation for less-secure interpretations.
CWE-451partialprevents — Secure coding practices can prevent UI flaws that obscure or spoof critical information.
CWE-453partialprevents — Secure coding standards mandate explicit, safe variable initialization.
CWE-455partialprevents — Secure coding practices mandate proper error handling during initialization to prevent insecure fallback states.
CWE-456partialprevents — Secure coding standards directly require explicit initialization of all variables before use.
CWE-457partialprevents — Secure coding explicitly requires variable initialization and static-analysis checks.
CWE-459partialprevents — Secure-coding rules can mandate explicit cleanup of temporary resources, but do not guarantee it.
CWE-46partialprevents — Secure coding standards directly require stripping or rejecting trailing spaces in file paths, addressing the root cause.
CWE-460partialprevents — Secure coding standards directly require proper resource release and state restoration after exceptions.
CWE-462partialprevents — Secure coding standards directly address associative-list key uniqueness and collision handling.
CWE-463partialprevents — Secure coding standards directly address sentinel misuse and deletion errors.
CWE-466partialprevents — Secure coding standards directly address pointer validation and bounds checking, mitigating this specific weakness.
CWE-467partialprevents — Secure coding rules directly forbid sizeof(pointer) mistakes that produce incorrect buffer sizes.
CWE-468partialprevents — Secure-coding standards and training directly target pointer arithmetic mistakes, covering most of this weakness while the control also addresses many other issues.
CWE-469partialprevents — Secure coding standards directly forbid pointer subtraction for size calculations and prescribe safer alternatives.
CWE-471partialprevents — Secure coding standards discourage mutable storage for values that must remain constant.
CWE-473partialprevents — Secure coding standards require disabling register_globals and sanitizing all external inputs, eliminating the root cause of CWE-473.
CWE-474partialprevents — Secure coding standards explicitly prohibit or wrap functions known to behave differently across OSes and versions.
CWE-475partialprevents — Secure coding directly addresses avoiding undefined behavior by enforcing defined inputs and error handling in APIs.
CWE-476partialprevents — Secure coding standards directly require NULL-pointer checks and safe dereference patterns.
CWE-477partialprevents — Secure coding standards explicitly prohibit use of deprecated/obsolete functions.
CWE-478partialprevents — Secure coding standards explicitly require exhaustive switch/case handling to prevent unhandled paths.
CWE-479partialprevents — Secure coding standards explicitly forbid non-reentrant functions inside signal handlers.
CWE-480partialprevents — Secure coding standards and peer review directly prevent accidental use of incorrect operators.
CWE-482partialprevents — Secure coding standards and reviews directly prevent use of comparison operators where assignment was intended.
CWE-484partialprevents — Secure coding rules explicitly require break statements in switch constructs, directly preventing this omission.
CWE-488partialprevents — Secure coding standards mandate correct session handling to prevent exposure of data elements to the wrong session.
CWE-489partialprevents — Secure coding standards explicitly prohibit leaving debug code active in production.
CWE-495partialprevents — Secure coding standards can forbid public methods that return references to private mutable structures, largely eliminating this weakness.
CWE-499partialprevents — Secure coding standards directly require marking sensitive classes as non-serializable or implementing custom serialization controls.
CWE-50partialprevents — Secure coding standards directly address path traversal and equivalence vulnerabilities.
CWE-502partialprevents — Requiring vetted libraries, regular updates and SAST before release reduces the likelihood that deserialization logic will accept and act on attacker-controlled serialized objects.
CWE-507partialprevents — Secure coding practices help detect and eliminate hidden Trojan Horse functionality.
CWE-511partialprevents — Secure coding standards and peer review directly prevent insertion of malicious time- or logic-triggered code.
CWE-515partialprevents — Secure coding practices can avoid some covert storage patterns but cannot cover all implementation flaws.
CWE-523partialprevents — Requires secure coding practices that can prevent unprotected credential transmission.
CWE-524partialprevents — Secure coding practices prevent caching of sensitive data outside intended boundaries.
CWE-525partialprevents — Secure coding standards can mandate proper cache-control headers and form-field handling to prevent sensitive data retention.
CWE-526partialprevents — Secure coding standards typically prohibit storing sensitive information in cleartext environment variables.
CWE-531partialprevents — Secure coding standards can require scrubbing or exclusion of secrets from test modules.
CWE-539partialprevents — Secure coding standards directly forbid embedding sensitive information in persistent cookies.
CWE-541partialprevents — Secure coding standards directly prohibit embedding credentials in include files.
CWE-547partialprevents — Secure coding standards explicitly prohibit hard-coded security constants.
CWE-548partialprevents — Secure coding practices ensure developers do not leave directory listing enabled on production web servers.
CWE-549partialprevents — Secure coding practices would include implementing password masking, but the control is broader than this single weakness.
CWE-550partialprevents — Secure coding standards prohibit embedding sensitive data in server error messages.
CWE-551partialprevents — Secure coding practices directly address canonicalization and authorization sequencing flaws.
CWE-561partialprevents — Secure coding standards require removal of dead code to improve maintainability and reduce attack surface.
CWE-562partialprevents — Secure coding standards directly prohibit returning addresses of stack variables.
CWE-564partialprevents — Secure coding explicitly requires parameterized queries and safe Hibernate usage to prevent injection.
CWE-565partialprevents — Secure coding practices directly eliminate reliance on unvalidated cookies by requiring proper integrity checks and server-side verification.
CWE-566partialprevents — Secure-coding standards mandate parameterized queries and server-side authorization, eliminating the root cause of CWE-566.
CWE-567partialprevents — Secure coding standards directly require synchronization of shared variables across threads.
CWE-57partialprevents — Mandates secure coding techniques such as proper pathname canonicalization and input sanitization.
CWE-570partialprevents — Secure coding standards and practices directly prevent constant-false expressions through disciplined coding and peer review.
CWE-571partialprevents — Secure coding standards and practices directly target logic errors such as tautological expressions.
CWE-573partialprevents — Secure coding standards enforce correct use of APIs, protocols and language features, mitigating caller specification violations.
CWE-587partialprevents — Secure coding standards directly forbid assigning fixed addresses to pointers.
CWE-588partialprevents — Secure coding standards directly forbid casting non-structures to structures and accessing fields.
CWE-59partialprevents — Secure coding standards directly address canonicalization and symlink attacks during implementation.
CWE-590partialprevents — Secure coding standards explicitly forbid freeing pointers not obtained from heap allocators, directly mitigating CWE-590.
CWE-591partialprevents — Secure-coding standards can mandate use of locked-memory APIs, directly preventing the weakness.
CWE-597partialprevents — Secure coding rules directly prohibit use of the wrong string-comparison operator.
CWE-598partialprevents — Secure coding standards directly prohibit placing secrets in query parameters.
CWE-599partialprevents — Requires secure coding practices that would include proper certificate validation in OpenSSL usage.
CWE-600partialprevents — Secure coding standards directly prescribe catching and sanitizing exceptions in servlets to avoid leaking debug data.
CWE-602partialprevents — Secure coding standards require server-side checks and reject client-only enforcement.
CWE-603partialprevents — Secure coding standards discourage reliance on client-side authentication logic.
CWE-605partialprevents — Secure coding practices can include checks to ensure sockets request exclusive port binding.
CWE-606partialprevents — Secure coding standards directly mandate validation of loop-control inputs to prevent unbounded iteration.
CWE-61partialprevents — Secure-coding standards mandate explicit symlink checks and safe open patterns, fully mitigating CWE-61.
CWE-610partialprevents — Secure coding standards require input validation and canonicalization to block externally controlled resource references.
CWE-611partialprevents — Secure coding standards require disabling DTDs and external entities in XML processing.
CWE-614partialprevents — Secure coding practices directly prevent missing the Secure attribute on sensitive cookies, though the control covers many other coding issues.
CWE-615partialprevents — Secure-coding standards and training directly discourage embedding secrets or sensitive data in comments.
CWE-616partialprevents — Secure coding explicitly prohibits use of deprecated upload variables and requires validated, server-side file handling.
CWE-617partialprevents — Secure coding standards explicitly ban the use of assert() or equivalent statements that can be triggered by external input.
CWE-618partialprevents — Secure coding standards directly prohibit unsafe ActiveX method exposure and require least-privilege interfaces.
CWE-62partialprevents — Secure-coding practices can mandate safe file-open APIs and link validation, directly addressing the weakness.
CWE-621partialprevents — Secure coding standards directly prohibit unvalidated variable extraction from external input.
CWE-622partialprevents — Secure coding standards directly require argument validation for any exposed or hooked functions.
CWE-623partialprevents — Secure coding standards explicitly forbid marking ActiveX controls as safe-for-scripting unless truly safe.
CWE-624partialprevents — Secure coding standards directly address safe regex construction and ban user-supplied pattern modifiers.
CWE-625partialprevents — Secure coding standards directly prohibit permissive regex and enforce strict pattern validation.
CWE-626partialprevents — Secure coding standards directly address null-byte handling and input sanitization.
CWE-627partialprevents — Secure coding standards directly prohibit or constrain dynamic variable evaluation to prevent arbitrary access.
CWE-628partialprevents — Secure coding standards directly address proper function-call syntax and argument validation.
CWE-637partialprevents — Secure coding guidelines may discourage complex constructs but do not specifically address protection-mechanism design.
CWE-639partialprevents — Secure coding practices reduce the likelihood of missing authorization checks but do not guarantee their presence at runtime.
CWE-64partialprevents — Secure coding practices can implement proper validation of .LNK targets to prevent unauthorized file operations.
CWE-640partialprevents — Secure-coding standards can prevent weak recovery implementations, yet the control is wider in scope.
CWE-641partialprevents — Secure coding standards explicitly require validation and sanitization of filenames derived from external input.
CWE-642partialprevents — Secure coding guidelines can prevent the practice of storing critical state in externally accessible locations.
CWE-644partialprevents — Secure coding standards require proper escaping or rejection of scripting syntax in HTTP headers.
CWE-646partialprevents — Secure coding standards explicitly require validating file content rather than trusting names or extensions.
CWE-647partialprevents — Secure-coding standards that require URL canonicalization and safe path handling eliminate the root cause of the weakness.
CWE-648partialprevents — Secure coding standards can enforce correct usage of privileged APIs.
CWE-649partialprevents — Secure coding practices include validating integrity of encrypted/obfuscated inputs before use.
CWE-65partialprevents — Secure-coding practices can require canonicalization and path validation to prevent following unintended hard links.
CWE-650partialprevents — Secure coding practices directly address improper HTTP method usage and ensure state-changing operations use POST/PUT/DELETE.
CWE-652partialprevents — Secure coding standards require proper neutralization of untrusted input in query expressions.
CWE-656partialprevents — Secure-coding rules prohibit hidden or undocumented security mechanisms.
CWE-66partialprevents — Secure coding standards directly address safe file-name handling and canonicalization, substantially mitigating this weakness.
CWE-662partialprevents — Secure coding standards explicitly mandate proper use of locks, semaphores, and atomic operations to eliminate race conditions.
CWE-663partialprevents — Secure coding standards explicitly forbid use of non-reentrant functions in multi-threaded or signal-handling code.
CWE-664partialprevents — Secure coding practices help avoid lifetime control bugs but do not address the full scope.
CWE-665partialprevents — Secure coding standards explicitly forbid uninitialized variables and mandate proper resource initialization before use.
CWE-667partialprevents — Secure coding standards directly prohibit missing or incorrect lock usage.
CWE-67partialprevents — Secure coding standards directly address proper handling of Windows reserved device names in pathnames.
CWE-670partialprevents — Secure coding standards and reviews directly target flawed control-flow implementations.
CWE-672partialprevents — Secure-coding rules require checks that prevent operations on freed or expired objects.
CWE-674partialprevents — Secure coding standards directly prohibit or constrain recursive constructs that could exhaust stack or memory.
CWE-675partialprevents — Secure coding standards directly address avoiding multiple operations on a resource in a single-operation context.
CWE-676partialprevents — Secure coding standards explicitly ban or restrict dangerous functions such as strcpy, gets, or system.
CWE-680partialprevents — Secure coding standards directly require prevention of integer overflows that lead to buffer overflows.
CWE-681partialprevents — Secure coding standards directly address correct numeric type conversions and overflow checks.
CWE-682partialprevents — Secure coding standards directly prohibit unsafe arithmetic and require defensive checks against incorrect results.
CWE-683partialprevents — Secure coding standards can mandate argument-order checks and static analysis, but do not guarantee elimination of all ordering mistakes.
CWE-686partialprevents — Secure coding directly addresses type safety, static analysis, and compiler warnings for argument mismatches.
CWE-687partialprevents — Secure coding directly addresses correct function-call argument usage.
CWE-688partialprevents — Secure coding standards directly address proper function-call argument usage and validation.
CWE-689partialprevents — Mandates secure coding techniques to set permissions atomically during copy.
CWE-69partialprevents — Secure-coding standards and reviews can require explicit handling or disabling of alternate data streams, directly addressing the root cause in application code.
CWE-690partialprevents — Secure coding standards explicitly forbid unchecked return values leading to NULL dereference.
CWE-691partialprevents — Secure coding standards explicitly forbid constructs that allow unintended control-flow changes such as missing breaks or unsafe jumps.
CWE-692partialprevents — Secure-coding rules directly require allow-list or context-aware escaping instead of incomplete denylists for XSS.
CWE-694partialprevents — Secure coding standards can mandate unique identifier generation and validation.
CWE-695partialprevents — Secure coding standards directly prohibit disallowed low-level functionality.
CWE-696partialprevents — Secure coding standards enforce correct execution order of security-critical operations.
CWE-697partialprevents — Secure coding standards directly address avoiding incorrect comparison operators and logic.
CWE-698partialprevents — Secure coding standards directly address proper redirect handling and flow termination.
CWE-704partialprevents — Secure coding standards directly forbid or detect incorrect type casts.
CWE-705partialprevents — Secure coding standards directly address correct return and exception handling to prevent control-flow errors.
CWE-706partialprevents — Secure-coding standards directly address canonicalization, input validation and safe name resolution, mitigating CWE-706.
CWE-73partialprevents — Secure coding standards require canonicalization, allow-listing, and bounds checks on file paths, directly eliminating CWE-73.
CWE-733partialprevents — Secure coding standards explicitly address compiler flags and volatile/optimization barriers for security-critical code.
CWE-74partialprevents — Secure coding standards require proper neutralization of special elements, directly addressing CWE-74.
CWE-749partialprevents — Secure coding standards explicitly prohibit inclusion of dangerous methods or functions in production APIs.
CWE-75partialprevents — Secure coding standards require rigorous input sanitization, directly eliminating CWE-75.
CWE-754partialprevents — Secure coding standards directly mandate proper checks for exceptional and unusual conditions.
CWE-755partialprevents — Secure coding standards mandate proper exception handling to avoid CWE-755.
CWE-756partialprevents — Secure coding practices directly address proper error handling and custom error pages.
CWE-757partialprevents — Secure coding standards can mandate checks to reject weaker negotiated algorithms.
CWE-758partialprevents — Secure coding explicitly prohibits constructs whose behavior is undefined, unspecified or implementation-defined.
CWE-759partialprevents — Secure coding standards explicitly forbid unsalted password hashes and require salting.
CWE-76partialprevents — Secure coding standards directly address proper neutralization of all equivalent special elements.
CWE-760partialprevents — Secure coding explicitly prohibits predictable salts and mandates cryptographically secure random salts.
CWE-761partialprevents — Secure coding rules directly forbid freeing a pointer that is not at the start of an allocated buffer.
CWE-762partialprevents — Secure coding standards directly prohibit mismatched memory-management calls and enforce safe patterns.
CWE-763partialprevents — Secure coding standards directly prohibit mismatched or incorrect pointer-release calls.
CWE-764partialprevents — Secure coding standards and reviews can catch and prevent erroneous multiple-lock sequences in source code.
CWE-765partialprevents — Secure coding standards and reviews can catch or prevent erroneous unlock sequences in critical sections.
CWE-767partialprevents — Secure coding standards explicitly forbid exposing private variables through public methods.
CWE-768partialprevents — Secure-coding standards directly forbid short-circuit side effects and require explicit evaluation order.
CWE-771partialprevents — Secure coding standards can require proper reference maintenance for allocated resources.
CWE-772partialprevents — Secure-coding rules can mandate explicit resource-release patterns, but the control is broader than this single weakness.
CWE-775partialprevents — Secure-coding standards can mandate explicit close/release of handles, directly mitigating CWE-775.
CWE-776partialprevents — Secure coding standards directly require disabling or restricting recursive entity references in XML parsers.
CWE-777partialprevents — Secure coding explicitly requires anchored regex to prevent bypass of input validation.
CWE-780partialprevents — Requires secure coding practices that would prevent missing OAEP padding.
CWE-782partialprevents — Secure coding practices prevent omission of access-control checks on IOCTL handlers.
CWE-783partialprevents — Secure coding standards and guidelines directly address operator precedence mistakes.
CWE-784partialprevents — Secure coding practices require integrity checks on security-critical cookies used for decisions.
CWE-786partialprevents — Secure coding standards directly require bounds checking and pointer validation that prevent this weakness.
CWE-787partialprevents — Secure coding directly addresses out-of-bounds writes through language choice and coding standards.
CWE-788partialprevents — Secure coding standards directly forbid writing or reading past buffer ends.
CWE-789partialprevents — Secure coding standards directly prohibit allocating memory from untrusted size values without validation.
CWE-79partialprevents — Secure-coding standards, SAST scans and removal of insecure code samples together eliminate the failure to neutralize script content that produces cross-site scripting flaws.
CWE-790partialprevents — Secure coding standards require proper filtering and encoding of special elements before downstream processing.
CWE-791partialprevents — Secure coding standards mandate complete filtering and escaping of special elements, directly eliminating CWE-791.
CWE-792partialprevents — Secure coding standards require complete sanitization of special elements before downstream processing.
CWE-794partialprevents — Secure coding standards require complete sanitization of all instances of special elements before downstream processing.
CWE-798partialprevents — Explicit prohibition of hard-coded passwords and unauthenticated external services stops credentials from being embedded directly in source code.
CWE-799partialprevents — Secure coding practices can embed input-frequency and throttling checks in code.
CWE-80partialprevents — Secure coding standards require proper escaping of <, >, & to block XSS.
CWE-804partialprevents — Secure coding practices ensure CAPTCHA logic is resistant to automated recognition or guessing attacks.
CWE-805partialprevents — Secure coding explicitly requires correct buffer-length handling, eliminating CWE-805 when followed.
CWE-81partialprevents — Secure coding standards require output encoding and error-message sanitization, directly eliminating CWE-81.
CWE-82partialprevents — Secure coding standards directly require proper neutralization of script in HTML attributes, addressing the root cause of CWE-82.
CWE-820partialprevents — Secure coding standards directly require synchronization primitives to prevent race conditions.
CWE-821partialprevents — Secure coding standards directly require correct synchronization primitives and thread-safety.
CWE-822partialprevents — Secure coding standards explicitly forbid dereferencing pointers derived from untrusted input.
CWE-823partialprevents — Secure coding standards directly forbid unsafe pointer arithmetic and require bounds checks.
CWE-824partialprevents — Secure coding standards directly prohibit use of uninitialized pointers.
CWE-825partialprevents — Secure coding standards directly address pointer lifetime and deallocation discipline, substantially mitigating expired-pointer dereference.
CWE-826partialprevents — Secure coding standards directly prohibit premature resource release, covering most of the weakness.
CWE-827partialprevents — Secure coding standards explicitly forbid unsafe XML parsers and mandate disabling external entities.
CWE-828partialprevents — Secure coding standards directly address asynchronous-safety and reentrancy requirements in signal handlers.
CWE-830partialprevents — Secure coding practices can avoid unsafe inclusion of external scripts, but coverage depends on developer adherence.
CWE-832partialprevents — Secure coding standards can explicitly forbid unlocking resources that were never locked.
CWE-833partialprevents — Secure coding standards mandate safe lock ordering, timeouts, and deadlock detection patterns.
CWE-834partialprevents — Secure coding standards explicitly forbid unbounded loops and require explicit iteration limits.
CWE-835partialprevents — Secure coding standards directly address loop termination and prevent infinite loops.
CWE-836partialprevents — Secure coding guidance can prevent this implementation error but does not address the control's broader intent.
CWE-837partialprevents — Secure-coding standards can mandate checks that prevent repeated actions, but the control covers many coding issues.
CWE-838partialprevents — Secure coding directly addresses proper output encoding for context, covering most of the weakness and the control's intent.
CWE-839partialprevents — Secure coding standards explicitly forbid numeric comparisons that omit the lower bound, directly mitigating CWE-839.
CWE-84partialprevents — Secure coding standards mandate proper neutralization of encoded URI schemes, eliminating the root cause of CWE-84.
CWE-841partialprevents — Secure coding practices can prevent missing workflow checks but do not define the control itself.
CWE-843partialprevents — Secure coding standards directly forbid unsafe type casts and require static-analysis checks for type confusion.
CWE-85partialprevents — Secure coding practices directly require proper sanitization of user input, covering most of this XSS variant.
CWE-86partialprevents — Secure coding standards require proper neutralization of invalid characters in tag names, URIs and identifiers, directly addressing CWE-86.
CWE-88partialprevents — Secure coding standards explicitly require proper neutralization of command arguments, directly eliminating CWE-88.
CWE-89partialprevents — Language-specific secure coding rules, peer review and SAST together prevent the construction of SQL statements from untrusted data without proper parameterization or escaping.
CWE-90partialprevents — Secure coding standards require proper neutralization of LDAP special characters, directly eliminating this weakness.
CWE-908partialprevents — Secure coding standards directly require explicit initialization of all variables and resources, substantially mitigating CWE-908.
CWE-909partialprevents — Secure coding standards explicitly require initialization of variables and resources.
CWE-91partialprevents — Secure coding standards require proper neutralization of XML metacharacters, directly eliminating CWE-91.
CWE-910partialprevents — Secure-coding standards can explicitly forbid use of expired file descriptors.
CWE-911partialprevents — Secure coding standards directly prescribe correct increment/decrement patterns, covering most instances of this weakness.
CWE-912partialprevents — Secure coding standards reduce the likelihood of introducing hidden code but do not address its detection or removal.
CWE-913partialprevents — Secure coding standards directly prohibit unsafe dynamic code resource handling and injection patterns.
CWE-914partialprevents — Secure coding standards directly prohibit uncontrolled dynamic variable access.
CWE-916partialprevents — Secure coding practices include implementing password storage with adequate computational effort.
CWE-917partialprevents — Secure coding standards require proper escaping and parameterization of expression-language statements.
CWE-923partialprevents — Secure coding practices can implement endpoint checks but the control itself is process-oriented.
CWE-925partialprevents — Secure coding practices directly address proper intent verification in broadcast receivers.
CWE-927partialprevents — Secure coding standards explicitly forbid implicit intents when handling sensitive information.
CWE-93partialprevents — Secure coding standards explicitly require neutralization of CRLF sequences, fully addressing this weakness.
CWE-939partialprevents — Mandates secure coding practices that include proper authorization checks before executing actions triggered by custom URL schemes.
CWE-94partialprevents — Banning unapproved code samples and unauthenticated web services, combined with secure-coding standards and SAST, prevents the dynamic generation or inclusion of attacker-supplied code.
CWE-940partialprevents — Secure coding practices can prevent improper source verification if explicitly required.
CWE-941partialprevents — Secure coding guidelines can require destination checks, but enforcement is not guaranteed.
CWE-942partialprevents — Secure coding practices require proper configuration of CSP and cross-domain policies to avoid untrusted domains.
CWE-943partialprevents — Secure coding standards require proper neutralization of special elements in all data queries.
CWE-95partialprevents — Secure coding explicitly requires neutralization of input before dynamic evaluation, directly mitigating eval injection.
CWE-96partialprevents — Secure coding explicitly requires proper neutralization of directives in templates, libraries and configuration files.
CWE-97partialprevents — Secure coding standards explicitly require escaping or disabling SSI constructs in dynamic web content.
CWE-98partialprevents — Secure coding standards directly require whitelisting and sanitization of filenames used in include/require statements.
CWE-99partialprevents — Secure coding standards require strict validation and whitelisting of all resource identifiers before use.
CWE-1007nonenone — Secure coding standards can enforce font or rendering choices that distinguish similar glyphs.
CWE-1176nonenone — Secure coding standards can mandate use of efficient algorithms and prohibit known inefficient patterns.
CWE-1189nonenone — Secure coding practices can mitigate software exploits of SoC isolation flaws but do not prevent the underlying hardware weakness.
CWE-1222nonenone — Secure coding practices can avoid overly coarse lock regions but do not define the hardware protection model itself.
CWE-1224nonenone — Secure coding standards and reviews can enforce write-once bit-field constraints in HDL.
CWE-1233nonenone — Secure coding practices can include checks for proper lock-bit usage in firmware.
CWE-1253nonenone — Secure coding practices can catch incorrect fuse-value logic during development but do not address the hardware configuration itself.
CWE-1258nonenone — Secure coding practices can mandate explicit clearing of debug registers and memory.
CWE-1264noneprevents — Secure coding guidelines can address hardware description language issues that lead to premature data forwarding.
CWE-1283nonemitigates — Secure coding practices can prevent software paths that allow register tampering.
CWE-1298noneprevents — Secure coding guidance can extend to hardware description languages but is primarily software-oriented.
CWE-1299nonenone — Secure coding practices reduce software-level bypasses but do not cover hardware interface protections.
CWE-1303nonenone — Secure coding can avoid software patterns that amplify microarchitectural side-channels but does not address the hardware sharing itself.
CWE-1316nonenone — Secure coding practices include verification that address-map definitions do not create overlapping protected/unprotected regions.
CWE-1332nonenone — Secure coding guidelines may mandate defensive coding against skipped instructions, but do not address underlying hardware circuitry.
CWE-1342nonemitigates — Secure coding guidelines can mandate constant-time algorithms and fences to limit speculative leakage.
CWE-284nonemitigates — Mandating secure design, threat modelling, least-privilege evaluation and access-controlled source-code repositories directly stops developers from introducing missing or incorrect authorization checks.
CWE-514noneprevents — Secure-coding standards can forbid constructs known to create covert channels, but the control does not explicitly require covert-channel analysis.
CWE-520nonenone — Secure-coding standards discourage unsafe impersonation calls, yet eliminating this single weakness contributes little to the overall secure-coding program.
CWE-528nonemitigates — Secure-coding practices can disable or redirect core-dump generation, reducing the weakness at the source.
CWE-553noneprevents — Secure coding standards prohibit placing command shells in publicly accessible paths.
CWE-555nonenone — Promotes secure coding practices that discourage embedding plaintext passwords in configuration files.
CWE-556nonenone — Secure coding standards can prohibit or restrict the use of identity impersonation in ASP.NET code.
CWE-6nonenone — Secure coding guidelines typically require adequate session token entropy and length.
CWE-657nonenone — Secure coding practices help realize secure design principles at implementation time.
CWE-669noneprevents — Secure-coding standards help prevent implementation of improper transfers.

Mitigated MITRE ATT&CK techniques (8)

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

T1068→M T1190→M T1203→P T1505.003→P T1559→P

Why these map — AI rationale (under review)

T1068mostlyprevents — Threat modelling and secure design practices limit the introduction of privilege-escalation bugs that adversaries would otherwise chain after an initial foothold.
T1190mostlyprevents — Secure coding standards, threat modelling, and static analysis directly reduce the number of exploitable flaws in public-facing applications that adversaries rely on for initial compromise.
T1203partialprevents — By enforcing vetted libraries, least-privilege design, and removal of insecure constructs such as hard-coded credentials, the control shrinks the attack surface that client-side exploits target.
T1505.003partialprevents — Secure coding governance and source-code protection controls make it harder for attackers to plant or maintain web shells in production code.
T1559partialprevents — Mandating secure coding techniques and peer review reduces the likelihood of insecure inter-process communication paths that could be abused for execution.
T1525nonemitigates — Inventorying and vetting external libraries and images limits the ability of an adversary to embed malicious code in container or VM images used by the organization.
T1553.002nonemitigates — Requiring vetted, signed components and prohibiting unapproved code samples lowers the chance that adversaries can subvert trust controls via malicious binaries.
T1554nonemitigates — Requiring vetted, version-controlled components and prohibiting hard-coded credentials reduces the chance that an adversary can insert or abuse backdoors in host binaries.

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

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

A02→P A05→M A08→M

Why these map — AI rationale (under review)

A05mostlyprevents — Language-specific secure coding practices, peer reviews, and static analysis during development catch and eliminate many classes of injection flaws before they reach production.
A08mostlyprevents — Protecting source code with access and version controls, plus secure packaging and deployment, reduces the chance that tampering will compromise software integrity after release.
A02partialprevents — Enforcing secure baselines, updated tools, and removal of insecure defaults such as hard-coded credentials prevents many configuration-related weaknesses from being introduced.
A03noneprevents — Mandating vetted, inventoried, and regularly updated third-party and open-source components directly reduces the risk of compromised or outdated dependencies entering the application.
A06noneprevents — Requiring threat modelling, secure design, and approved coding standards before development begins stops insecure architectural decisions from becoming part of the code base.

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.