Home / Knowledge hub / CWE
Knowledge hub
CWE
A catalogue of vulnerability types, rather than individual bugs.
What it means
CWE is a community-built catalogue of weakness types, maintained by MITRE. A CVE says this product, this flaw. A CWE says this kind of flaw: missing authorisation, input used without checking, a response that leaks whether an account exists.
Good reports carry one on every finding, because it answers the question that follows what happened. That question is what kind of mistake this was.
Why it matters
Types are how a team notices itself repeating. Three findings in three features look like three pieces of work. Three findings sharing a CWE look like one missing habit, and you only have to fix a habit once.
It also changes what you build in response. A single bug gets a patch. A repeating type gets a shared fix: a helper everybody calls, a check in the pipeline, a line in the review checklist. That is the difference between a day per finding for a year and a week once. You cannot tell which you are facing without the types. They cost nothing, and any decent report already carries them.
How it shows up
Sort your last report by CWE instead of by page or severity. A pattern usually appears within a minute. Authorisation gets checked in the interface rather than on the server. Or input gets trusted because it arrived from your own front end.
The catalogue also gives you a sanity check. MITRE publishes a Top 25 of the weaknesses doing the most damage, drawn from real CVE records. It is a fair starting list for a team with no idea where to begin.
Questions people ask
CWE, answered
What is the difference between CWE and CVE?
CWE is the category, CVE is the instance. CWE-79 is cross-site scripting as a class of mistake. A CVE is one product, one version, one occurrence of it.
You fix a CVE by upgrading. You fix a CWE by changing how you write that kind of code.
Does a CWE id actually help a developer, or is it security paperwork?
It helps when you use it to group. On its own, CWE-639 in a ticket title tells a developer very little.
Next to the request, the response and the line of code, it tells them this is the fourth time this pattern has appeared, which usually changes what they build.
What is the CWE Top 25?
MITRE ranks the most dangerous software weaknesses each year by analysing tens of thousands of CVE records, and publishes the list with its methodology.
It is a useful conversation starter, not a syllabus. Your own last three reports say more about your codebase than any industry ranking does.
Why does one finding get mapped to several CWEs?
Because the catalogue is a hierarchy. A weakness has parents that describe it more broadly and children that describe it more precisely, and some entries chain together.
MITRE marks certain high-level entries as discouraged for mapping real vulnerabilities, and asks you to pick the most specific one that fits. That is the one worth putting in the ticket.
Do we need to track CWEs if we already track CVEs?
If you only ever consume other people's software, CVEs cover most of what you need. The moment you write your own code, they stop being enough.
Your own bugs never get a CVE. The type is the only handle you have on them.
Sources
Where this comes from
Related
Terms that sit next to this one
CVE
A public reference number for one known flaw in one piece of software.
CVSS
A scoring system that turns a vulnerability into a number out of ten.
Severity
How bad a finding is, from critical down to informational.
Vulnerability
A weakness that somebody could use to cause harm.
Remediation
The actual work of fixing a finding: the change, the review, the release.
The same mistake in three features?
Every finding we send carries its type, the request, the response and the line responsible, so a repeating pattern shows up instead of hiding. Thirty days on one application costs $199.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.