A vulnerability in cyber security is a weakness in a system, application, or process that an attacker can exploit to cause harm. That harm might be stealing data, running unauthorized code, escalating privileges, or knocking a service offline. The weakness itself is neutral until someone or something acts on it, which is exactly why understanding what is a vulnerability in cyber security means separating the flaw from the actor who abuses it.
People use the word loosely, so it is worth being precise. A missing patch is a vulnerability. A misconfigured storage bucket is a vulnerability. A hardcoded password in source code is a vulnerability. What they share is that each one is a condition an attacker can turn to their advantage.
Vulnerability vs Threat vs Risk
These three terms get blended together constantly, and the confusion leads to bad decisions. Keep them distinct.
A vulnerability is the weakness itself, for example an outdated library with a known flaw. A threat is the potential event or actor that could exploit it, such as a criminal group scanning for that flaw. Risk is the combination: the likelihood that a threat exploits a vulnerability, multiplied by the impact if it does.
A useful way to hold it in your head: a vulnerability is an unlocked window, a threat is a burglar in the neighborhood, and risk is how likely you are to be robbed and how much you would lose. You reduce risk by closing windows (fixing vulnerabilities), because you cannot control which burglars exist.
Where Vulnerabilities Come From
Vulnerabilities enter systems through several well-worn paths:
- Code defects — logic errors, missing input validation, unsafe deserialization, or memory bugs written into the application.
- Known flaws in dependencies — third-party libraries and container base images that ship with published CVEs.
- Misconfiguration — overly permissive access rules, default credentials, disabled encryption, exposed admin interfaces.
- Design weaknesses — flawed authentication flows or trust assumptions that no single line of code creates but the architecture invites.
Modern applications lean heavily on open source, so the second category dominates most inventories. A typical service pulls in hundreds of transitive dependencies, and any one of them can carry a flaw you never wrote.
How Vulnerabilities Are Named and Scored
To coordinate response across the industry, most notable software flaws get a CVE identifier (Common Vulnerabilities and Exposures), a unique reference like CVE-YYYY-NNNNN. Severity is commonly expressed with CVSS (Common Vulnerability Scoring System), which produces a 0 to 10 score based on factors like attack vector, complexity, and impact.
Two caveats matter. First, CVSS measures technical severity in the abstract, not the risk to your specific environment. A "critical" scored flaw in a component you do not actually reach at runtime may be lower priority than a "medium" in an internet-facing path. Second, not every weakness has a CVE; internal code defects usually do not. Scoring is a starting point for prioritization, not the final answer.
Finding Vulnerabilities Before Attackers Do
Discovery uses layered tooling because no single scanner sees everything:
- SAST (static analysis) reads source code for defects without running it.
- SCA (software composition analysis) inventories your dependencies and matches them against vulnerability databases. Our SCA overview explains how this catches flaws buried in transitive packages.
- DAST (dynamic analysis) tests the running application from the outside, the way an attacker probes it.
- Secrets scanning looks for credentials committed to code.
Layering these gives coverage across the code you wrote, the code you imported, and the app as it actually runs. For teams building a program from scratch, our security academy walks through how these fit together.
Prioritizing and Fixing What You Find
A scanner will happily hand you thousands of findings. The goal is not zero findings; it is reducing real risk fast. Triage by asking whether the vulnerable component is reachable in your code path, whether it is exposed to untrusted input, whether an exploit exists in the wild, and what the blast radius is if abused.
Then fix in order. Most dependency vulnerabilities resolve by upgrading to a patched version, sometimes via a direct bump and sometimes by forcing a transitive override. Code defects need a real fix and a regression test. Misconfigurations often close with a policy change applied fleet-wide. The discipline that matters is closing the loop: verify the fix landed and rescan, because a vulnerability marked "resolved" in a ticket but still live in production is worse than one you are honest about.
FAQ
What is a vulnerability in cyber security in simple terms?
It is a weakness in software, hardware, or a process that an attacker can exploit to do something they should not, like steal data or run malicious code. The weakness exists whether or not anyone attacks it.
How is a vulnerability different from a threat?
A vulnerability is the weakness; a threat is the actor or event that could exploit it. You control risk mainly by fixing vulnerabilities, since you cannot control which threats exist.
Do all vulnerabilities have a CVE number?
No. CVEs are assigned mostly to flaws in widely used software. Defects in your own private codebase and many misconfigurations typically have no CVE, even though they are still exploitable weaknesses.
Should I fix every vulnerability a scanner reports?
Not blindly. Prioritize by real risk, whether the flaw is reachable, exposed to untrusted input, and exploitable, then fix the highest-impact issues first. Chasing a zero-finding count wastes effort on flaws that cannot actually be reached.