SANS / CWE Top 25

1. Introduction: The SANS / CWE Top 25 Most Dangerous Software Weaknesses

The CWE Top 25 Most Dangerous Software Weaknesses, historically published jointly by MITRE and the SANS Institute and now maintained by the MITRE Corporation on behalf of the Common Weakness Enumeration (CWE) programme, is a demonstrative and consensus-driven list of the software and hardware weaknesses that are most prevalent and most impactful across real-world systems. Unlike a prescriptive control framework such as PCI DSS or ISO/IEC 27001, the CWE Top 25 is a weakness taxonomy: it names, categorises and ranks the underlying flaws in code and design that adversaries repeatedly exploit. For any organisation building, procuring or assuring software, the CWE Top 25 provides a defensible, evidence-backed baseline against which secure-development practices, static and dynamic testing, code review, and vendor assurance can be measured.

This guide is written for engineering leaders, application-security architects, product security teams, QSAs, CERT-In empanelled assessors and internal auditors who must translate the CWE Top 25 from an academic list into an operational assurance programme. It sets out what the list is, who should use it, how it is structured, a master assessment checklist covering every one of the twenty-five weaknesses and their supporting categories, a phased implementation approach, a maturity model, an audit methodology, evidence expectations, roles, KPIs and mappings to adjacent frameworks. Throughout, we adopt British/Indian English and auditor-grade specificity, using the canonical CWE identifiers (CWE-79, CWE-787, and so on) so that findings are unambiguous and traceable.

2. What is the SANS / CWE Top 25?

The Common Weakness Enumeration is a community-developed, formal dictionary of common software and hardware weakness types. A weakness (as distinct from a vulnerability) is a condition in the architecture, design, code or deployment of a product that, under the right circumstances, can contribute to the introduction of a vulnerability. Where a vulnerability (tracked as a CVE) is a specific, exploitable instance in a specific product, a weakness (tracked as a CWE) is the reusable root-cause pattern. For example, CWE-89 (SQL Injection) is the weakness class; a particular CVE in a particular content-management system is a concrete manifestation of that class.

The CWE Top 25 is produced annually using a data-driven scoring methodology. MITRE analyses the previous period's published CVE records from the National Vulnerability Database (NVD), maps each CVE to its root-cause CWE, and combines two factors for each weakness: frequency (how often the weakness appears in real CVEs) and severity (the average CVSS base score of those CVEs). The product of a normalised frequency and a normalised severity yields a score, and the twenty-five highest-scoring weaknesses form that year's list. Because it is re-derived from fresh data each year, the ranking shifts: out-of-bounds write, cross-site scripting, SQL injection, use-after-free and improper input validation have consistently featured near the top in recent editions, while the exact order and membership change annually.

Two closely related MITRE products frequently accompany the Top 25 and should be treated as part of the same assurance toolkit: the CWE/SANS 'On the Cusp' list (weaknesses that narrowly missed the top 25) and the CWE Top 25 Software Errors 'Monster Mitigations' guidance. In addition, MITRE publishes 'views' such as CWE-1000 (Research Concepts), CWE-699 (Software Development) and CWE-1194 (Hardware Design), plus category nodes (for example CWE-1215 Data Validation Issues) that group related weaknesses. The Top 25 is thus best understood as a curated, prioritised entry point into the far larger CWE corpus of over 900 weakness entries.

Key characteristics

• Data-driven and re-derived annually from NVD/CVE data, so it reflects the current real-world threat landscape rather than opinion.
• Root-cause oriented: it targets the weakness that must be fixed, not merely the symptom, enabling durable remediation.
• Language- and platform-agnostic in principle, though many entries (memory-safety weaknesses in particular) are more relevant to C/C++/unmanaged code.
• Hierarchical: each Top 25 entry is a node in the broader CWE tree, with parent categories, child variants and 'peer' relationships.
• Non-prescriptive: it tells you which weaknesses matter most; it does not, by itself, mandate specific controls, though it maps cleanly onto SSDF, ASVS and other prescriptive frameworks.

3. Who must comply with (or should adopt) the CWE Top 25?

The CWE Top 25 is not a regulation, so no organisation is legally 'bound' to it in the way one is bound to the DPDP Act or PCI DSS. However, it is referenced directly and indirectly by numerous mandates, contracts and standards, which effectively makes conformance expected across large parts of the software supply chain. The following table sets out the principal audiences and the driver for adoption.

4. Structure of the CWE Top 25

The Top 25 can be organised into logical weakness families that map to the phases and domains of software engineering. The table below presents a representative structuring of the twenty-five weaknesses commonly appearing in recent editions, grouped by family, with the canonical CWE-ID and a plain-language description. Exact ranking varies by year; the families and identifiers are stable reference points for building an assessment programme.

Each of these entries sits within MITRE's broader research view (CWE-1000) under abstract 'pillar' and 'class' weaknesses such as CWE-664 (Improper Control of a Resource Through its Lifetime), CWE-707 (Improper Neutralisation), CWE-284 (Improper Access Control) and CWE-693 (Protection Mechanism Failure). Understanding these parents helps assessors reason about root cause and about weaknesses that are 'On the Cusp' but not in the current 25.

5. Master assessment checklist

This is the core of the guide. For every weakness family in the Top 25 we provide a dedicated sub-section with a verification table. Each table states, per weakness, what an assessor must verify in the design, code and testing evidence, and the typical evidence artefacts that demonstrate the control is present and effective. No weakness area is skipped. Assessors should complete every row and record a status (Implemented / Partial / Absent / Not Applicable with justification).

5.1 Memory-safety weaknesses (CWE-787, 125, 416, 476, 190, 119)

5.2 Injection weaknesses (CWE-79, 89, 78, 77, 94, 1321)

5.3 Improper input validation (CWE-20)

5.4 Path and file-handling weaknesses (CWE-22, 434)

5.5 Authentication weaknesses (CWE-287, 306, 798)

5.6 Authorisation and access-control weaknesses (CWE-862, 863, 269, 918)

5.7 Web session and request-forgery weaknesses (CWE-352)

5.8 Sensitive-data exposure (CWE-200)

5.9 Unsafe deserialisation (CWE-502)

5.10 Cross-cutting secure-development controls

Beyond the individual weaknesses, assessors should verify the systemic controls that make weakness elimination durable rather than accidental.

6. Scoping

Because the CWE Top 25 is a weakness catalogue rather than a system-boundary standard, scoping is about deciding which assets, code repositories and weakness classes are in play and to what depth. A disciplined scope statement prevents both under-assessment (ignoring memory-safety in a mixed C/Java estate) and wasted effort (fuzzing pure-managed code for use-after-free).

• Enumerate the software portfolio: first-party applications, services, APIs, mobile apps, firmware/embedded, infrastructure-as-code and significant third-party components.
• Classify each asset by technology stack, because relevance of weaknesses differs: memory-safety CWEs (787/125/416/476/190) dominate C/C++/unmanaged and embedded code, while injection, authN/authZ and CSRF dominate web and API tiers.
• Rank assets by exposure and criticality (internet-facing, handles PII/PCI/PHI, safety-relevant) to prioritise depth of assessment.
• Define which analysis techniques apply per asset class: SAST/SCA for all, DAST for web/API, fuzzing and sanitisers for native code, manual review for high-risk components.
• Decide the CWE baseline: current-year Top 25 as a minimum, optionally extended with 'On the Cusp' entries and organisation-specific weaknesses from past incidents.
• State exclusions with justification (e.g. a weakness class marked Not Applicable because the technology cannot exhibit it), and record residual-risk acceptance owners.
• Fix the assessment period and the CVE/CWE list version, since the Top 25 changes annually.

7. Implementation approach

Embedding CWE Top 25 assurance into an organisation is a programme, not a single scan. We recommend a five-phase approach. Each phase lists activities and the deliverables an auditor should expect.

Phase 1 — Baseline and gap analysis

• Activities: inventory applications and stacks; run an initial SAST/SCA/secret-scan/DAST sweep; map existing findings to CWE-IDs; assess current SDLC practices against the master checklist; identify the highest-risk weakness classes per asset.
• Deliverables: application and technology inventory; CWE-mapped current-state findings register; gap-analysis report; prioritised remediation backlog; scoping and applicability statement.

Phase 2 — Guardrails and secure-development foundation

• Activities: adopt secure coding standards mapped to the Top 25; introduce or configure safe frameworks/libraries (parameterised DB access, auto-escaping templates, vetted auth/crypto libraries); enable compiler hardening and sanitisers for native code; establish a secrets-management solution; roll out developer secure-coding training.
• Deliverables: secure-coding standard document; approved libraries/frameworks list; compiler-hardening configuration; secrets-vault integration; training curriculum and initial completion records.

Phase 3 — Pipeline integration and gating

• Activities: integrate SAST, DAST, SCA and secret scanning into CI/CD; define severity thresholds that fail builds; wire findings into the issue tracker keyed by CWE-ID; add PR security-review checklists; introduce fuzzing for critical native components.
• Deliverables: CI/CD pipeline configuration; gating policy; CWE-tagged vulnerability tracking; PR checklist templates; fuzzing harnesses and coverage reports.

Phase 4 — Remediation and hardening

• Activities: remediate the prioritised backlog starting with highest score (frequency x severity); apply 'monster mitigations' that eliminate whole weakness classes (e.g. move to memory-safe languages, adopt ORM everywhere, enforce output encoding globally, deny-by-default authorisation); retest and confirm closure.
• Deliverables: remediation evidence per finding; before/after scan results; architecture-decision records for class-level eliminations; residual-risk register with acceptance sign-off.

Phase 5 — Continuous assurance and governance

• Activities: schedule periodic re-assessment against each year's refreshed Top 25; track KPIs and weakness trends; run threat modelling on changes; conduct annual penetration tests; feed incident and bug-bounty findings back into standards and training.
• Deliverables: recurring assessment reports; KPI dashboard; updated threat models; pentest reports; governance/steering minutes; annual programme review.

8. Maturity / capability model

To measure programme maturity we use a five-level capability model. Assessors rate the organisation per weakness family and overall, then track improvement over time. The model draws on the spirit of CMMI, OWASP SAMM and NIST SSDF.

9. Assessment and audit approach

An auditor-grade assessment against the CWE Top 25 follows a repeatable methodology that blends documentation review, tooling corroboration and manual verification.

1. Confirm scope and applicability: agree the asset list, technology stacks, in-scope weakness classes and the Top 25 version/year to be used.
2. Review documentation: secure-coding standards, threat models, SDLC policies, prior scan reports and the vulnerability register keyed by CWE.
3. Corroborate with tooling: obtain or re-run SAST, DAST, SCA and secret-scan results; verify they cover the codebase and that gating is enforced, not merely configured.
4. Perform manual verification: sample high-risk code paths for each weakness family (injection sinks, memory operations, auth/authz checks, deserialisation) and inspect actual mitigations.
5. Conduct or review penetration testing: validate exploitability of representative weaknesses (XSS, SQLi, IDOR/authz, SSRF, path traversal, CSRF) with proof-of-concept where safe.
6. Assess process effectiveness: check remediation SLAs, ageing, escape rate and that CI gating actually blocks high-severity findings.
7. Rate maturity per weakness family using the capability model and record status against every master-checklist row.
8. Report findings by CWE-ID with severity, evidence, root cause and remediation guidance; distinguish design flaws from implementation bugs.
9. Agree a remediation plan with owners and dates; define re-test criteria.
10. Schedule re-assessment aligned to the annually refreshed Top 25 and to major releases.

10. Evidence request list

The following categorised artefacts should be requested at the outset of an assessment. Availability and quality of this evidence is itself a maturity signal.

• Governance and policy: secure-coding standard mapped to the Top 25; SDLC/SSDLC policy; vulnerability-management and remediation-SLA policy; secrets-management policy.
• Architecture and design: threat models and data-flow diagrams; architecture-decision records; access-control (RBAC/ABAC) model; data-classification register.
• Tooling outputs: latest SAST, DAST, SCA and secret-scanning reports; fuzzing and sanitiser (ASAN/UBSAN/Valgrind) results; CI/CD pipeline configuration showing gating.
• Vulnerability management: CWE-tagged vulnerability register; ageing/MTTR reports; remediation evidence and re-test results; residual-risk acceptance records.
• Code and configuration: samples of parameterised queries, output encoding, authorisation checks, input validation, deserialisation handling; compiler-hardening flags; CSP/SameSite/CORS headers.
• Supply chain: SBOMs; approved-libraries list; dependency-patch cadence evidence.
• People and process: developer secure-coding training records; PR security-review checklists and sampled reviews; penetration-test reports; bug-bounty/incident records feeding back into standards.

11. Roles and responsibilities

12. KPIs to track

• Weakness density: number of Top 25 findings per 1,000 lines of code or per application, trended over releases.
• Coverage: percentage of repositories/services under SAST, DAST, SCA and secret scanning.
• Gating efficacy: percentage of builds correctly blocked on high-severity CWE findings.
• Mean time to remediate (MTTR) by severity, and percentage of findings remediated within SLA.
• Escape rate: proportion of Top 25 weaknesses found in production or by external testers versus caught pre-release.
• Recurrence rate: reappearance of the same CWE class after a class-level mitigation.
• Class-elimination progress: number of Top 25 classes designed out (e.g. no raw SQL anywhere, memory-safe language adoption percentage).
• Training coverage: percentage of developers current on secure-coding training and their assessment scores.
• Dependency hygiene: mean age of known-vulnerable dependencies and patch cadence.
• Maturity score per weakness family from the capability model, trended over time.

13. Readiness checklist

• Software and technology inventory complete, with stacks classified for weakness applicability.
• Secure-coding standard mapped to the current-year CWE Top 25 published and adopted.
• SAST, DAST, SCA and secret scanning integrated into CI/CD with enforced severity gating.
• Findings tracked by CWE-ID with defined remediation SLAs and ageing reports.
• Parameterised database access, context-aware output encoding and CSP enforced across web/API tiers.
• Server-side, allow-list input validation applied at every entry point.
• Deny-by-default authorisation and object-level access checks verified (no IDOR).
• Authentication uses vetted protocols with MFA; no hard-coded credentials (secret scan clean).
• SSRF, path traversal and unrestricted-upload protections implemented and tested.
• Unsafe deserialisation avoided or constrained by type allow-lists and integrity checks.
• Memory-safety controls (bounds checks, sanitisers, hardening, safe languages) in place for native code.
• Threat modelling performed for new and changed features and mapped to CWE classes.
• Developers trained on the Top 25; PR security-review checklist in use.
• SBOM produced and dependencies monitored for relevant CVEs.
• Independent penetration test and re-assessment scheduled against each annual Top 25 refresh.

14. Common gaps

• Client-side-only validation, leaving server endpoints exposed to CWE-20 and injection weaknesses.
• Parameterised queries used in most places but bypassed for 'dynamic' reporting or search, reintroducing CWE-89.
• Output encoding applied inconsistently across contexts, so CWE-79 XSS persists in JS/attribute/URL sinks.
• Authorisation checks present at the UI/route level but missing at the object level, causing CWE-862/863 IDOR.
• Secrets removed from code but still present in CI logs, container images or history, defeating CWE-798 controls.
• SSRF (CWE-918) overlooked in features that fetch remote resources (webhooks, previews, image proxies).
• Memory-safety tooling (ASAN/fuzzing) configured but not run continuously, so CWE-787/125/416 regress.
• Scans run but not gated, so findings accumulate without enforced remediation.
• Findings not mapped to CWE-IDs, preventing trend analysis and class-level elimination.
• Deserialisation of untrusted data (CWE-502) hidden inside third-party libraries and frameworks, unnoticed by manual review.
• Programme frozen against an old Top 25, missing newly risen weaknesses in the current year's list.
• Prototype pollution (CWE-1321) and other ecosystem-specific weaknesses ignored because tooling defaults do not detect them.

15. CWE Top 25 mapped to other frameworks

The Top 25 dovetails with prescriptive standards. The table shows how key weaknesses and the programme as a whole align with widely used frameworks, enabling a single body of evidence to satisfy multiple requirements.

16. How CyberSigma helps

Frequently asked questions

Need help with SANS / CWE?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.