Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Vulnerability

Concept

A foundational idea to recognize and understand.

Context

This is a tactical pattern. No matter how carefully you design a system, weaknesses exist. A vulnerability is a specific weakness in code, configuration, design, or process that an attacker could exploit to cause harm. Vulnerabilities are the concrete instances of risk that your threat model tries to anticipate.

In agentic workflows, vulnerabilities can live in your code, in the agent’s tooling, in the libraries the agent selects, and in the boundary between trusted instructions and untrusted content. Understanding what makes something a vulnerability is the foundation for building software that holds up under real-world conditions.

Problem

Software is built from layers of code, libraries, configurations, and human decisions. Any of these layers can contain mistakes that create exploitable weaknesses. The trouble is that vulnerabilities are often invisible during normal operation. They only show up when someone actively tries to exploit them, or when an unlucky edge case triggers them. How do you find and fix weaknesses before attackers do?

Forces

  • Every line of code is a potential source of vulnerabilities, but you can’t review everything with equal scrutiny.
  • Dependencies bring their own vulnerabilities, and you have limited control over third-party code.
  • Some vulnerabilities are simple mistakes (a missing check); others are subtle design flaws that take deep understanding to recognize.
  • Fixing vulnerabilities costs developer time, risks regressions, and takes deployment cycles. That effort must be prioritized against feature work.

Solution

Treat vulnerability management as an ongoing practice, not a one-time audit.

Find vulnerabilities through multiple channels: automated scanning tools (SAST, DAST, dependency scanners), code review, penetration testing, and bug bounty programs. No single method catches everything. Automated tools find known patterns; humans find novel ones.

Assess severity using a consistent framework. The Common Vulnerability Scoring System (CVSS) provides a standard way to rate how serious a vulnerability is based on how it can be exploited and what damage it can cause. Not every vulnerability needs an emergency fix. A low-severity issue in a non-critical component can wait for the next release cycle.

Fix vulnerabilities promptly, especially in attack surface areas that are directly reachable. Apply input validation to block malformed data. Update dependencies when patches are available. Remove or isolate components with known unfixable weaknesses.

Learn from vulnerabilities by doing root-cause analysis. A SQL injection isn’t just a missing parameterized query. It’s a sign that the codebase lacks a consistent data access pattern. Fix the instance, then fix the pattern.

How It Plays Out

A team runs a dependency scanner and discovers that a logging library they use has a known remote code execution vulnerability. The library is used in every service. The scanner ranks it as critical. The team updates the dependency across all services within 48 hours, uses the incident to set up automated dependency monitoring, and adds a policy that dependencies with known critical vulnerabilities must be patched within one week.

A developer directing an AI agent asks it to build a user registration form. The agent generates code that concatenates user input directly into a SQL query. The developer spots the SQL injection vulnerability (a textbook weakness) and asks the agent to use parameterized queries instead. The agent complies. This is why human review of agent-generated code still matters: agents reproduce patterns from their training data, including insecure ones.

Note

AI-generated code is neither more nor less trustworthy than human-written code by default. Apply the same security review standards to both. The difference is that agents can produce large volumes of code quickly, so vulnerabilities can pile up faster if review doesn’t keep pace.

Example Prompt

“Run the dependency scanner and show me any packages with known vulnerabilities. For each critical finding, check whether our code uses the affected functionality and prioritize updates accordingly.”

Consequences

Active vulnerability management reduces the number of exploitable weaknesses in your system over time. It shifts security from reactive (responding to breaches) to proactive (finding and fixing issues before exploitation). It also builds institutional knowledge about common weakness patterns, making future code less likely to repeat the same mistakes.

The cost is ongoing effort. Scanning, reviewing, patching, and deploying fixes takes time away from feature development. False positives from automated scanners create noise. And there’s an irreducible gap: you will never find every vulnerability before an attacker does. The goal isn’t perfection but a responsible, sustained effort to minimize exploitable weaknesses.

  • Depends on: Threat Model. The model prioritizes which vulnerabilities matter most.
  • Depends on: Attack Surface. Vulnerabilities on reachable surfaces are more dangerous.
  • Enables: Input Validation. Many vulnerabilities are prevented by validating input.
  • Enables: Sandbox. Sandboxing contains the impact of exploited vulnerabilities.
  • Refined by: Prompt Injection. A specific class of vulnerability relevant to AI systems.
  • Enables: Output Encoding. Proper encoding prevents many vulnerability classes.