Vulnerability

A vulnerability is a specific weakness in code, configuration, design, or process that an attacker can exploit to cause harm; the word gives a team a way to talk about defects as exploitable rather than merely incorrect.

What It Is

A vulnerability is a defect that an attacker can use against the system. The defect can live in any layer: a buffer overflow in a parser, a missing authorization check in an endpoint, a default password in a configuration file, a race condition in a deployment script, a logic gap that lets one tenant read another tenant’s data. What unites these otherwise-different problems is the second word in the definition: an attacker can use the weakness to do something the system’s owner doesn’t want done.

The word is older than computer security. Cryptographers used “vulnerability” in the 1970s to describe weaknesses in cipher implementations, and software-engineering literature picked the term up in the 1990s as commercial systems started getting attacked at scale. The U.S. government formalized the modern usage in 1999 when MITRE began issuing Common Vulnerabilities and Exposures identifiers (CVEs) under contract with NIST, giving the industry a shared namespace for naming specific weaknesses. Today the word covers everything from a missing input check in a startup’s web form to a kernel-level memory-safety bug in an operating system shipped to a billion devices.

It helps to keep three close-but-distinct ideas separate:

• A weakness is the underlying defect class: missing input validation, unsafe deserialization, hard-coded credentials, race condition. MITRE catalogs these as Common Weakness Enumeration (CWE) entries — categories that describe kinds of mistakes.
• A vulnerability is a specific instance of a weakness in a specific system: this version of this library, on this endpoint, accepting this payload. CVEs catalog these instances, one identifier per finding.
• An exploit is a working technique that turns a vulnerability into actual harm: the payload, the chain of requests, the carefully crafted input that flips the defect into damage. A vulnerability without a known exploit is still a vulnerability; an exploit without a fixed-version timestamp is the urgent shape of one.

A neighbor concept worth holding onto: vulnerability is about what is broken inside the system; attack surface is about where the system can be reached from outside; blast radius is about how far damage spreads once a vulnerability is exploited. The three answer different questions, and a team that conflates them tends to over-invest in one dimension and ignore the others.

Why It Matters

Without the word, a team treats every defect the same. A typo in a comment, a missing null check that crashes the server, and a missing authorization check that exposes other tenants’ data all show up in the same backlog with the same triage. That mixes incomparable things. Some defects are bugs; some are vulnerabilities; the second kind has an attacker on the other side, and that changes the math on priority, on disclosure, and on how the fix is delivered.

The vocabulary also lets a team grade severity. The Common Vulnerability Scoring System (CVSS) turns a vulnerability into a number between 0 and 10 based on how it can be exploited (network vs. local, authenticated vs. anonymous), what damage it can cause (read, modify, destroy), and what the impact on confidentiality, integrity, and availability looks like. The number isn’t perfect, and CVSS gets argued about for good reasons, but a team that scores its findings has a defensible way to decide that a critical remote code execution on the public API gets a same-day fix while a low-severity issue on an internal-only service can wait for the next release.

This matters more under agentic coding, not less. An AI agent generates code that compiles, passes existing tests, and reads as competent. The agent has no incentive to write secure code unless it’s prompted to, and a striking amount of its training data contains common weaknesses (string-concatenated SQL, missing input validation, secrets hard-coded in source) precisely because the open web is full of those mistakes. A reviewer who can name the relevant weakness class (this is SQL injection because the input is interpolated rather than parameterized) can fix the instance and the pattern in one pass. A reviewer who lacks the vocabulary tends to merge the unsafe code, ship it, and discover the vulnerability when the scanner catches it weeks later or the attacker catches it first.

The agent itself also introduces new vulnerability classes. An agent trap, a malicious instruction hidden in content the agent reads, is a weakness specific to agentic systems; it doesn’t fit cleanly into the pre-2023 CWE taxonomy because there wasn’t anything to inject into before agents could be steered by content. Teams that name the new classes can defend against them deliberately; teams that don’t tend to discover them by incident.

How to Recognize It

Several signs distinguish a vulnerability from an ordinary bug:

• There’s a plausible attacker. Someone, somewhere, has a reason to misuse the defect. The attacker doesn’t have to be a nation-state — an annoyed user, a competitor scraping data, a bot scanning the open internet, or even an automated tool the user pointed at the wrong target all count. The test is whether the defect can be used, not whether it has been.
• There’s a path from input to harm. The defect connects an entry point (a form field, an API parameter, a parsed file, a logged HTTP header, a tool an agent can call) to a consequence (data read, data modified, code executed, credentials exposed, service degraded). If the path doesn’t exist or is fully gated, the defect may be a bug but not a vulnerability.
• The harm is asymmetric. A small input produces a large effect: one malformed line of SQL exposes the whole users table; one crafted filename writes outside the upload directory; one polluted URL in a fetched page redirects the agent to a different repository. Asymmetric impact is the signature of an exploitable weakness.
• The defect has a category. Almost every vulnerability fits into an established class: injection, broken authentication, sensitive data exposure, broken access control, security misconfiguration, vulnerable dependency, insufficient logging. The OWASP Top 10 list reorganizes itself every few years, but the categories are durable. If a finding doesn’t fit any category, suspect the categorization, not the finding.

A team that takes vulnerabilities seriously can usually answer the following:

• Where do new vulnerabilities show up? Code reviews flag missing checks; static analysis catches some weakness classes automatically; dependency scanners report known CVEs in libraries; penetration tests find logic flaws that scanners miss; bug bounty reports surface things internal teams couldn’t see. Each channel catches a different slice, and a team that relies on only one channel misses the rest.
• How are findings ranked? Severity by CVSS, exposure by attack surface, contractual obligation by compliance regime, business impact by the data at stake. Ranking by raw severity alone tends to over-fix internal low-impact issues while under-fixing externally reachable high-impact ones.
• What’s the time-to-fix? A team that fixes critical issues in days, high issues in weeks, and accepts low issues until the next release has a working program. A team that has hundreds of open critical findings has a backlog problem that no amount of new scanning will fix.

Signs the vulnerability discipline has slipped:

• The scanner output is ignored because it’s mostly false positives, and nobody’s tuned the rules.
• A library with a known critical CVE has been on the deprecation list for six months and is still in the build.
• An incident reveals a vulnerability the team never knew about, in a feature path nobody remembered shipping.
• Two teams discover the same weakness independently, fix it locally each time, and never write the pattern down.

How It Plays Out

A team runs a dependency scanner against their build and finds that a logging library they ship has a known remote code execution CVE. The library is used in every service. They update the dependency across the fleet within 48 hours, then use the incident as a forcing function: they set up automated dependency monitoring, add a policy that critical CVEs in production dependencies must be patched within one week, and put the scan results in front of the team weekly so the backlog doesn’t accumulate quietly.

A developer directing an AI agent asks it to build a user registration form. The agent concatenates the submitted username directly into a SQL query: a textbook injection vulnerability. The developer spots the pattern during review, asks the agent to switch to parameterized queries, and then asks it to walk the codebase for the same pattern elsewhere. The agent finds three more instances. The instance fix took a minute; the pattern sweep took ten; the absence of the vocabulary would have shipped four vulnerabilities in one feature.

A platform team is asked to characterize the agent fleet’s exposure to prompt injection. They enumerate the input channels (issue bodies, fetched web pages, RAG documents, tool outputs) and rate each by attacker control: an issue body is fully attacker-controlled; an internal RAG document is not, but a public knowledge-base article scraped into the same index is. They tighten the agents’ permissions on the channels that rank high, route the high-risk channels through a stricter input validation layer, and add monitoring on the agent’s outgoing tool calls so a successful injection at least shows up in logs. The exposure didn’t go to zero, but the team can now defend a specific position rather than hoping no one notices the gap.

Consequences

Naming vulnerabilities as a distinct category of defect changes how a team allocates attention. Bugs that crash a process and bugs that expose customer data no longer share a queue; the second kind gets specific treatment with specific timelines and specific reviewers. Over months, the discipline accumulates: the codebase grows toward fewer instances of each weakness class because the team learns to see the class, and the next agent-generated SQL query gets parameterized in review rather than after deploy.

Benefits. Findings get acted on consistently. Severity becomes a defensible decision rather than a feeling. The team builds institutional knowledge about which weakness classes appear most often in their code and where the structural fixes belong — switching to an ORM that parameterizes by default, adding a templating layer that escapes by default, replacing a hand-rolled auth check with a centralized middleware. Under agentic coding, the same discipline lets reviewers catch agent-introduced weaknesses by class, fix the instance, and tighten the prompt or the post-process to prevent the class. Vulnerability work becomes routine rather than heroic.

Liabilities. Vulnerability management is ongoing work that produces no new features. Scanners create false positives that consume review time; CVSS scoring is contested and sometimes wrong about real-world impact; chasing every low-severity finding is a way to feel busy without becoming safer. The discipline is to spend the effort where the math justifies it — high severity on reachable surfaces, classes the codebase repeats — and to accept that some findings will be acknowledged and deferred rather than fixed.

The other failure mode is treating the absence of known vulnerabilities as evidence of security. A clean scan means the scanner found nothing it knows about, not that nothing is there. New classes appear faster than scanners catch up to them; agent traps and prompt-injection variants are recent enough that most legacy tooling doesn’t look for them. A team that closes the loop on scanner output but never invests in penetration testing, threat modeling, or design review tends to ship vulnerabilities the scanners can’t see and discover them only when someone exploits them.

Related Patterns

Sources

• The MITRE Corporation has maintained the Common Vulnerabilities and Exposures (CVE) list since 1999 under sponsorship from the U.S. Cybersecurity and Infrastructure Security Agency. The CVE program established the shared namespace that lets vendors, researchers, and defenders refer to the same vulnerability by the same identifier across products and disclosures.
• MITRE’s Common Weakness Enumeration (CWE) catalogs the weakness classes that vulnerabilities instantiate. CWE provides the taxonomy a reviewer reaches for when naming what kind of defect a particular finding is, and the CWE Top 25 is the working list of the classes that account for the largest share of exploitable bugs in shipped software.
• The OWASP Top 10, maintained by the Open Worldwide Application Security Project since 2003, is the working practitioner’s reference for the categories most worth defending against in web applications. The list reorganizes every few years as the field changes; the categories are durable enough to anchor reviewer vocabulary across versions.
• Gary McGraw, Software Security: Building Security In (Addison-Wesley, 2006), made the case that vulnerabilities are defects of design and process as much as defects of code, and that security has to be built in across the software development lifecycle rather than tested in at the end. McGraw’s “touchpoints” framing pushed the field beyond find-and-fix toward systemic prevention.
• The FIRST Common Vulnerability Scoring System (CVSS) specification is the canonical reference for how severity is scored. CVSS gets argued about for good reasons — base scores under-weight context, environmental factors are inconsistently applied — but it remains the lingua franca of vulnerability triage and the score that compliance regimes and customers most often ask for.