Building your AI vulnerability harness, Part 1

What it is

A concrete adoption roadmap and set of operating principles for the three-layer AI vulnerability triage pipeline (AWS Security Blog, part 1 of a two-part series). The companion post, "Configuring your AI vulnerability harness," covers the steering file with the confidence formula and control multipliers — not covered here.

How it works

The key architectural claim the summary omits: the model never runs against the codebase directly — code is passed as context to a model with a specific prompt, and the model reasons over data flow, trust boundaries, and security patterns. Context scoping is called out as one of the hardest parts: too much context overwhelms the model's reasoning window, too little produces false negatives. The post's concrete heuristic is to start narrow (e.g., for a basic Lambda, just the function plus its IAM role) and expand only when the initial assessment is inconclusive, rather than passing the whole dependency graph up front.

Preconditions / Affected

Applies to teams already running multiple SAST/scanner tools (e.g., Semgrep, CodeQL) who have IaC (CDK/CloudFormation/Terraform) defining their deployment, since Layer 3 depends on parsing those templates.

What to do

Explicit five-step adoption order, each gated on the prior step being stable, by immediate return on investment:

1. Index first — build an AST-based index of entry points, sinks, and auth config. No AI involved, costs nothing to run.
2. Multi-scanner triage — feed existing Semgrep/CodeQL output through the AST gate plus an LLM exploitability classification.
3. Hypothesis generation — add AI-driven discovery of multi-hop chains, business-logic flaws, cross-package flows once triage is stable.
4. Infrastructure context — parse CDK/CloudFormation, map controls to vulnerability classes, apply multipliers.
5. Live verification — run PoCs against a deployed pre-production target with structured success criteria; run this last, only on findings that already passed the confidence threshold, since it carries the most operational overhead.

flowchart TD
    A[AST indexing] --> B[Multi-scanner triage]
    B --> C[AI hypothesis generation]
    C --> D[Infra context + CDK/CFN parsing]
    D --> E[Live PoC verification]

Caveats

The post explicitly states four things the harness does NOT solve: it doesn't fix code (remediation is separate tooling/process), doesn't replace human review for final action (even P0 findings need engineer review before driving code changes), doesn't catch vulnerability classes outside the scanner ensemble's detection profile, and doesn't verify live infrastructure state by default — parsing IaC tells you what was defined, not whether a WAF rule was disabled or a security group modified after deployment. Live-state verification requires a separate integration.