Partly. Static analysis tends to fit weaknesses where untrusted data flows to a dangerous operation, such as SQL injection or path traversal. It fits less well where the flaw is missing business logic, such as missing authorization. Fit varies by tool, language and framework, so test your own code.
What the list is
MITRE publishes a yearly list of the most dangerous software weaknesses. The 2025 list is ranked by a score and includes a column counting CVEs in the CISA Known Exploited Vulnerabilities catalog. A weakness is an underlying condition that can lead to vulnerabilities. A CVE is a specific instance in a specific product.
Because the list names weaknesses, not products, it is a useful question to ask a SAST vendor: which of these can you detect, in my language?
A fit guide, not a measurement
The table below is a general reading of how each type behaves under static analysis. It is guidance for planning an evaluation, not a measured detection rate for any tool.
| 2025 rank | Weakness | General fit for static analysis |
|---|---|---|
| 1 | CWE-79 Cross-site scripting | Often a good fit when data flows to output |
| 2 | CWE-89 SQL injection | Often a good fit |
| 3 | CWE-352 CSRF | Depends on framework awareness |
| 4 | CWE-862 Missing authorization | Weak fit, the absence of a check is hard to see |
| 5 | CWE-787 Out-of-bounds write | Possible for C and C++, hard in general |
| 6 | CWE-22 Path traversal | Often a good fit |
| 9 | CWE-78 OS command injection | Often a good fit |
| 15 | CWE-502 Deserialization of untrusted data | Often a good fit when sinks are known |
| 21 | CWE-306 Missing authentication | Weak fit |
Why authorization is the hard one
OWASP lists authentication problems, access control issues and insecure use of cryptography among the flaws that are very difficult to find automatically. It says the current state of the art lets such tools find a relatively small percentage of application security flaws in those areas. That matches the table: several entries ranked in the top 25 are about checks that should exist and do not.
Finding a missing check means the tool needs to know which routes need protection. That is application knowledge, and a rule engine does not have it by default.
How to use the list in an evaluation
- Pick six weaknesses from the list that apply to your stack.
- Write a small vulnerable and a small safe example for each, in your real framework.
- Run the tool and see which it flags, which it ignores and which it flags wrongly.
- Record the result per weakness, not as one score.
For the gaps, plan other methods: code review for authorization logic, dynamic testing, and tests you write yourself for access rules.
A caution about "coverage" claims
A vendor may say it covers a large share of a list. Ask what "cover" means. Detecting one pattern of a weakness in one framework is different from detecting the weakness in general. Ask for the rule names behind each claim.
A worked example: building a six case test
Say your service is written in a common web language and framework. You pick six weaknesses from the list: cross-site scripting (rank 1), SQL injection (rank 2), path traversal (rank 6), OS command injection (rank 9), deserialization of untrusted data (rank 15) and missing authorization (rank 4).
For each, you write two tiny functions. The unsafe one passes request data to the dangerous operation. The safe one uses the framework's recommended protection, such as a parameterized query or an allow list of paths. For missing authorization, the unsafe function returns another user's record without an ownership check, and the safe one includes the check.
You run the tool and fill in a table.
| Weakness | Unsafe flagged? | Safe flagged wrongly? | Notes |
|---|---|---|---|
| Cross-site scripting | Yes | No | Needed template engine support |
| SQL injection | Yes | No | Followed the value across two files |
| Path traversal | Yes | Yes | Did not recognize our path helper |
| OS command injection | Yes | No | None |
| Deserialization | No | No | Tool lacked a rule for our library |
| Missing authorization | No | No | Expected, needs review and tests |
This example table is illustrative of the format, not a result for any real product. The value is the shape: it shows where the tool is strong, where it needs configuration, and where you need another method.
Reading partial results
Three outcomes matter most.
- Missed the unsafe case. Ask the vendor whether a rule exists, and whether your framework is supported. If the answer is no, record a gap.
- Flagged the safe case. The tool may not recognize your protection. Ask whether you can teach it about your own helper functions.
- Handled both. Good. Repeat with a more complex variant, for example data passing through a third function.
Memory safety entries and your language
Several top ranked entries, such as out-of-bounds write and use after free, apply to languages with manual memory management. If your code is in a memory safe language, those entries matter less for your own code, although they can still affect native libraries you depend on. Dependency scanning covers known flaws in those libraries, which is a different method from SAST.
Using the list to plan other methods
| Weakness group | Better paired method |
|---|---|
| Authorization and authentication gaps | Targeted tests and code review |
| Request forgery and session issues | Dynamic testing of the running app |
| Resource exhaustion | Load and abuse testing |
| Known flaws in libraries | Dependency scanning |
No single method covers the whole list. A balanced program assigns each weakness group a primary method and a backup.
Keep the list in perspective
The list ranks weaknesses across many products. It does not know your threat model. A weakness absent from the list can still be your biggest risk, for example a flaw in a custom payment flow. Use the list to make sure you are not missing the common cases, then add your own.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which weakness name each finding carries.
Quick check
Is the CWE Top 25 a checklist a SAST tool must pass?
No. It is a ranked list of common weaknesses. Use it to shape test cases, not as a pass mark.
Which top 25 entries should I test with something other than SAST?
Missing authorization, incorrect authorization and missing authentication are good candidates for code review and dynamic tests.
How often does the CWE Top 25 change?
MITRE publishes it as a yearly list, and rankings shift between editions. Check the current edition each year before you update your test cases.
Safeguard offers SBOM and dependency scanning and reachability analysis, and a free scan is at gold.safeguard.sh/scan.
Sources
- MITRE, 2025 CWE Top 25 Most Dangerous Software Weaknesses
- MITRE, CWE FAQ
- OWASP, Static Code Analysis
Last reviewed: 19 October 2026.
