CWE Code Review

Use this skill for manual security review when the result needs defensible CWE mapping, not just a list of suspicious patterns. Prefer a narrower language, framework, CI, cloud, or infrastructure review skill when one clearly fits; use this skill to add CWE precision and cross-cutting review logic.

Review Principles

• Start from architecture, trust boundaries, attacker-controlled inputs, sensitive assets, and reachable sinks.
• Confirm a code path before assigning a CWE. A keyword match or a dangerous API alone is not a finding.
• Use CWE as a root-cause taxonomy. Prefer the most precise supported weakness over a broad Pillar, Class, Category, or View.
• Treat mapping notes as part of the evidence. Allowed and Allowed-with-Review entries are usually better finding mappings than Discouraged or Prohibited entries.
• Use Top 25, OWASP, language, and lifecycle views for coverage and prioritization context, not as severity proof.
• Keep unsupported hypotheses as open questions or coverage gaps instead of forcing a CWE mapping.
• Always create or update one standalone poc_<finding_slug>.py artifact per confirmed finding in the review workspace, with exploit prerequisites and validation steps for that finding.

References