Home / Knowledge hub / Vulnerability
Knowledge hub
Vulnerability
A weakness that somebody could use to cause harm.
What it means
A vulnerability is a weakness somebody could use to cause harm. A missing check. A mistaken assumption. A component with a published flaw. A setting left at its default.
NIST defines it as a weakness a threat source could exploit or trigger. It describes a possibility, not an event, and the word stretches from a flaw needing administrator access to one anybody can use before lunch.
Why it matters
The distinctions decide what you do next. A vulnerability becomes a finding when somebody shows it works, and an incident when somebody uses it who was never asked to.
Most lists blur all three. A queue of theoretical weaknesses sitting beside demonstrated ones resists prioritisation, and the usual result is that everything waits. Ownership shifts too. A theoretical weakness is a backlog item for whoever owns that area. A demonstrated finding on a live system is somebody's week.
How it shows up
Ask the same question of the report itself. Does it show the flaw working, or only describe where one might be? When a list arrives, ask each line what it would take to use this. If the answer depends on conditions that are not true in your system, file it for later. If the answer is a request anybody could send, it is work for this week.
A report that cannot answer that question about its own entries is handing you the triage it skipped. Choose your words carefully with customers as well. Saying you have vulnerabilities and saying you have had an incident are very different statements, and people conflate them easily.
Questions people ask
Vulnerability, answered
What is the difference between a vulnerability, a threat and a risk?
The vulnerability is the weakness. The threat is whoever or whatever might use it. The risk is what you lose if the two meet.
The practical value of splitting them is that you control the first one directly. You rarely control the second at all.
Is a vulnerability the same as an exploit?
No. The vulnerability is the unlocked door. The exploit is the particular way somebody walks through it.
A vulnerability with a working, public exploit is a different priority from one that stays theoretical. A scoring tool may hand both the same number.
Does every vulnerability get a CVE?
No. CVE identifiers cover flaws in published software that other people run, which is why your dependencies have them.
A flaw in your own application gets no identifier at all. Nobody else runs your code, so there is nothing for the outside world to track.
Who decides how severe a vulnerability is?
A scoring system like CVSS gives you a starting number based on how the flaw behaves. Only you can finish the job, because only you know what the affected system holds.
The same score means something different on a marketing site and on a payroll database.
Do we have to fix every one?
No, and pretending otherwise is how backlogs become fiction. Some findings cost more to fix than the harm they could cause.
What matters is deciding rather than drifting. Write down what you accepted, who accepted it and when you will look again.
Sources
Where this comes from
Related
Terms that sit next to this one
Exploit
The specific sequence that turns a suspected weakness into a real one.
Severity
How bad a finding is, from critical down to informational.
Proof of concept
The smallest demonstration that a vulnerability is genuinely real.
Remediation
The actual work of fixing a finding: the change, the review, the release.
Data breach
Information you hold ends up somewhere it should not be.
Weakness, finding or incident?
Cyberlop reports findings rather than possibilities. Each one arrives with the request, the response, a screenshot and the source line that allowed it. Ask to see how that reads.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.