A security vulnerability is a weakness or flaw in a system, application, or process that an attacker can exploit to compromise confidentiality, integrity, or availability. That is the whole definition, and every word earns its place. It is a weakness (not an attack), it must be exploitable (not merely theoretical), and the payoff is undermining one of the three core security properties. Getting this precise matters, because "vulnerability," "threat," and "risk" get used interchangeably in conversation and mean quite different things in practice.
The precise definition
Break the security vulnerability definition into its parts:
- A weakness or flaw: it can live in code (a bug like SQL injection), in configuration (a database exposed to the internet), in design (an authentication scheme with a logical gap), or in process (no review before deploying to production).
- Exploitable: someone can actually take advantage of it. A weakness that no attacker can reach or trigger is a latent defect, not yet a practical vulnerability.
- Leads to compromise: the exploit undermines confidentiality (data exposure), integrity (unauthorized modification), or availability (denial of service). These three properties, the CIA triad, define what "compromise" means.
So a hardcoded admin password in a public repository is a vulnerability: it is a flaw, it is exploitable, and it leads to compromise. A typo in a comment is a defect but not a vulnerability, because it cannot be exploited to any security effect.
Vulnerability versus threat versus risk
These three words form a chain, and mixing them up causes real confusion in security discussions.
A vulnerability is the weakness itself: an unpatched server, an injectable input field.
A threat is the potential danger that could exploit a vulnerability: a ransomware group, a malicious insider, an automated botnet scanning for that exact flaw.
Risk is the combination of the two plus impact: the likelihood that a threat exploits a vulnerability, multiplied by what it would cost you. Risk is what you actually manage. A vulnerability on a system holding no sensitive data and reachable by no one is low risk even if the vulnerability itself is severe.
A useful shorthand: risk equals threat times vulnerability times impact. Remove any factor and the risk drops. You often cannot control threats (you do not decide whether ransomware groups exist), but you can control vulnerabilities (patch them) and reduce impact (segment, encrypt, back up).
Where vulnerabilities come from
Vulnerabilities enter systems through a handful of recurring channels:
- Coding errors: injection flaws, buffer overflows, broken access control, unsafe deserialization. These are first-party bugs in software you wrote.
- Vulnerable dependencies: the open source libraries an application pulls in. Because modern apps are mostly third-party code, this is the largest source by volume, and a single flawed library can affect thousands of downstream projects. An SCA tool exists specifically to find these.
- Misconfiguration: default credentials, overly permissive access, exposed services, disabled security features.
- Design flaws: weaknesses baked into the architecture, which are the hardest and most expensive to fix after the fact.
Understanding the source matters because it dictates the fix. A coding error needs a patch; a vulnerable dependency needs an upgrade; a misconfiguration needs a settings change.
How vulnerabilities get named and scored
The security industry uses shared systems so everyone can talk about the same flaw.
CVE (Common Vulnerabilities and Exposures) assigns a unique identifier to each publicly disclosed vulnerability, like CVE-2021-44228. The CVE is just a name and a description; it does not tell you how bad the flaw is.
CVSS (Common Vulnerability Scoring System) provides a severity score from 0.0 to 10.0, along with a vector describing the characteristics (attack complexity, privileges required, impact). A CVSS score of 9.0 or above is critical.
CWE (Common Weakness Enumeration) categorizes the type of weakness, like CWE-89 for SQL injection, independent of any specific product.
A single real-world flaw might have a CVE identifier, a CVSS score, and a CWE category all at once: a name, a severity, and a class.
Not all vulnerabilities are equal
The final and most practical point: a vulnerability's severity score is not the same as its priority to you. CVSS measures technical severity in the abstract. Your priority depends on whether the flaw is exploitable in your environment, whether the vulnerable code is actually reachable, and whether the affected asset matters. A critical-rated vulnerability in a component you never load at runtime is lower priority than a moderate one on your internet-facing login. This is why every serious enterprise vulnerability assessment ranks by real-world risk rather than raw score, a topic the Safeguard Academy covers in depth.
FAQ
What is the difference between a vulnerability and an exploit?
A vulnerability is the weakness; an exploit is the code or technique that takes advantage of it. The vulnerability is the unlocked window; the exploit is the act of climbing through it. A vulnerability can exist for years before an exploit is written, and the existence of a public exploit sharply raises the urgency of fixing the underlying flaw.
Does every vulnerability get a CVE?
No. CVEs are assigned to publicly disclosed vulnerabilities in widely used software, typically coordinated through a CVE Numbering Authority. Flaws found internally in your own custom code, or issues that are never publicly disclosed, usually do not receive a CVE, even though they are real vulnerabilities you still need to fix.
How is a security vulnerability different from a bug?
Every security vulnerability is a kind of bug, but not every bug is a vulnerability. A bug becomes a vulnerability only when it can be exploited to compromise confidentiality, integrity, or availability. A rendering glitch is a bug; an input field that lets an attacker read the database is a vulnerability.
Why is vulnerability severity not the same as priority?
Severity scores like CVSS measure a flaw's technical danger in isolation, without knowing your environment. Priority depends on context: is the vulnerable code reachable, is the asset exposed, does it hold valuable data, and is there an active exploit? A high-severity flaw on an unreachable component can be lower priority than a moderate one on a critical, exposed system.