Why do SAST findings show CWE ids instead of CVE ids?

A CWE identifies a type of weakness, such as SQL injection. A CVE identifies a specific vulnerability in a specific product. A SAST tool finds possible weaknesses in code you wrote, which has no CVE unless someone publishes one, so its findings carry CWE ids. Dependency scanners report CVEs.

The definitions

MITRE's CWE FAQ puts it this way: a weakness is an underlying condition that can lead to vulnerabilities in a variety of products. A vulnerability, such as those listed in the Common Vulnerabilities and Exposures (CVE) List, is a specific instance of one or more weaknesses in a specific product that can be exploited, causing a negative impact to confidentiality, integrity or availability.

So the two ids answer different questions. CWE answers "what kind of mistake is this?" CVE answers "which known flaw in which release is this?"

Why the difference matters when you read tool output

If your SAST report lists "CWE-89" at a line in your service, nobody has assigned that line a CVE. It is a pattern the tool believes is risky. If your dependency scan lists a CVE against a library version, that flaw has been published and has a fix version to look for.

Why a CVE search will not help for SAST findings

Teams sometimes search a CVE database for their SAST finding and find nothing. That is expected. There is nothing to find unless the same flaw was published for a product. Use the CWE entry instead. It explains the weakness, shows examples and lists mitigations.

Using both ids together

The two systems connect. Published CVE records are often mapped to one or more CWEs, which tells you the root cause. MITRE says accurate root cause mapping between vulnerabilities and weaknesses helps show where investment, policy and practices can address root causes.

You can use that in two practical ways:

1. Group by CWE to see which mistake types recur in your code, then fix the habit, not just the instance.
2. Cross check by CWE when a CVE in a dependency shares a weakness type with something your SAST tool found in your own code. The shared type is a hint about where similar patterns may hide.

Deduplicating across tools

When SAST and dynamic testing report the same flaw, the CWE id is the common key you can use to match them. A related post explains how to dedupe findings with CWE.

What to put in your tracker

For a SAST ticket, include the CWE id, the code location, a plain description and a status. For a dependency ticket, include the CVE id, the package, the affected and fixed versions, and whether the vulnerable code is called.

A worked example: one codebase, two reports

A team runs two scans on the same service. The first is a SAST scan of the code they wrote. The second is a dependency scan of the libraries it uses. Their tracker receives entries like these, shown with made up details to illustrate the format.

The two SAST rows have no CVE because nobody has published a vulnerability record for this private code. They are patterns the tool believes are risky. The dependency rows each have a published record and a fix version.

Why the identifiers behave this way

The CWE FAQ describes a weakness as an underlying condition that can lead to vulnerabilities in a variety of products. CWE ids are stable names for these conditions. A SAST rule can map to one or more CWE ids because the rule describes a pattern, and the pattern is an example of a weakness type.

A CVE record is created when a specific vulnerability in a specific product is identified and published. The record often carries a CWE mapping that says which weakness caused it. That mapping is how the two systems connect.

How to use CWE ids well in a SAST program

1. Filter and group. Sort the backlog by CWE to see which mistake types are most common in your code.
2. Set rules of engagement. For example, decide that any finding of a given injection type in internet facing code blocks a merge.
3. Teach by type. Run a short training on the top three weakness types in your own findings, using examples from your code.
4. Track over time. If the count for one type drops after training, you have evidence that the effort worked.

Pitfalls

• Assuming the CWE id means severity. A CWE names a type. Severity depends on context such as exposure and impact.
• Assuming a missing CVE means low risk. Private code will never have a CVE unless someone publishes one.
• Mixing ids in one field. Keep separate fields for CWE and CVE in your tracker so reports stay clean.
• Using inconsistent mappings. Different tools can map the same rule to different CWE ids, so compare carefully when you merge results from two tools.

What if a SAST finding matches a published CVE

Sometimes a pattern your tool finds in your code is the same flaw published for a product you use. For example, you may have copied a snippet from a project that later received a CVE. In that case, look up the CVE record, read the fix, and apply the same approach. A reference to the CVE in the ticket helps reviewers understand the risk. This overlap is unusual, though, and not something to expect.

Reporting to non-technical readers

For managers and auditors, translate ids into plain language. "Injection flaws in two services, type CWE-89" is clear. A list of raw ids is not. Keep the ids in an appendix for those who want to look them up, and cite the MITRE entry so readers can confirm the definition.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a single view can hold findings of different types with their ids.

Quick check

Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.

Sources

• MITRE, CWE FAQ

Last reviewed: 19 October 2026.