Home / Knowledge hub / Root cause
Knowledge hub
Root cause
The underlying mistake behind a flaw, which fixing prevents a whole class from returning.
What it means
The root cause of a flaw is the underlying mistake that made it possible, as opposed to the visible symptom. A single page returning another customer's invoice is the symptom. The cause may be that the server never checks who owns the record, in this page and in a dozen others built the same way.
MITRE's CWE list is organised around causes. A CWE entry describes a type of mistake, such as missing authorisation or improper input handling, instead of one product's bug. Naming the cause with a CWE number puts the finding in a family you can search for and fix.
Why it matters
Patching the symptom is fast and incomplete. Fix the single page and the next one built the same way is still open. Fix the cause, for example by moving the ownership check into one shared function, and the whole class is closed, including pages not yet written. That saves repeat findings in every later test.
Finding causes also shows where your process is weak. If the same weakness keeps appearing, the lesson may be in a missing shared library, unclear guidance or a gap in review rather than in any one developer. This links to CWE mapping and to root cause analysis after an incident.
How it shows up
Ask why until the answer is about design rather than a single line. Why was the record returned? No ownership check. Why was there none? Each route author wrote their own. Why? There is no shared helper. The fix is the helper plus a test that fails when a route skips it.
Teams stumble by stopping too early, blaming a person, or fixing only the reported instance. Search the code for the same pattern after each finding, and add a test or a rule that stops it returning. A finding with the file and line makes the search quick.
Questions people ask
Root cause, answered
What is the difference between a root cause and a symptom?
A symptom is what you can see, such as one endpoint leaking data. The root cause is the mistake that allowed it, such as a missing check in shared code.
Fixing the cause closes the symptom and its relatives.
How do I find the root cause of a vulnerability?
Keep asking why the flaw was possible until you reach a design or process answer. Then search the code for the same pattern.
Reading the code that produced the flaw is the quickest route.
Is a CWE the root cause?
A CWE names a type of weakness, which is a way of describing the cause. It helps you group findings and look for related ones.
Your own cause may be more specific, such as no shared authorisation helper.
Should we always fix the root cause rather than patch?
Where you can. A quick patch may be right for urgent fixes, followed by the deeper change soon after.
Record the follow-up so it is not forgotten. The danger is leaving the quick patch in place for good, so give the deeper change an owner.
How do I stop the same cause returning?
Add a shared helper, a lint rule or an automated test that fails when the mistake is made again.
Repeating the original exploit in the pipeline catches it if it comes back.
Sources
Where this comes from
Related
Terms that sit next to this one
Root cause analysis
Working out why an incident happened, so the real cause is fixed.
CWE
A catalogue of vulnerability types, rather than individual bugs.
CWE mapping
Tagging each finding with the weakness type that describes it.
Regression
A bug that was fixed and has come back, usually undone by a later change.
Secure by design
Choosing safe defaults and structures from the start, not bolting protection on later.
Fix the page, or the pattern?
In white-box mode a finding points to the file and line, which makes it quick to search for the same mistake elsewhere. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.