Deepsec: When Your Security Audit Needs to Think, Not Just Pattern Match

Hook

A single security audit of a medium-sized codebase with Deepsec can cost $15,000. Security teams are paying it anyway, because finding one critical vulnerability before attackers do makes that price tag look trivial.

Context

Traditional static analysis security testing (SAST) tools are fast and cheap, but fundamentally limited by what they can express in rules. Semgrep can catch SQL injection if you write the right pattern. CodeQL can track taint flow through your application with sophisticated dataflow analysis. But neither can reason about whether your custom authorization framework properly validates tenant isolation in a multi-tenant SaaS application, or whether your bespoke cryptographic protocol actually provides the security properties you think it does.

This gap becomes acute in three scenarios: legacy codebases being prepared for acquisition due diligence, complex applications with project-specific security invariants, and organizations that have already picked the low-hanging fruit with conventional tools. Deepsec, from Vercel Labs, takes a radically different approach: instead of writing static analysis rules, you teach a reasoning-capable LLM about your codebase's security model, then let it drive a multi-phase investigation workflow that combines pattern matching with deep contextual analysis.

Technical Insight

Deepsec's architecture inverts the traditional SAST pipeline. Instead of running expensive analysis on every file, it uses a three-phase funnel: matchers filter the codebase down to suspicious sites, processors investigate those sites with LLM reasoning, and an optional revalidation phase checks git history to eliminate findings that were already patched.

The matcher phase is where most codebases get reduced by 99%. Matchers are TypeScript modules that export either regex patterns or AST-based checks. Here's a simplified example of a custom matcher for finding authentication bypasses:

export const authBypassMatcher = {
  name: 'auth-bypass-check',
  pattern: /(?:if|unless)\s*\([^)]*\.isAdmin\s*(?:===|==)\s*false\)/g,
  description: 'Finds conditions that check if user is NOT admin',
  severity: 'high',
  cwe: 'CWE-287'
};

When this matcher fires, Deepsec doesn't immediately report a vulnerability. Instead, it queues that file location for the processor phase. This is where the architecture gets interesting: the processor tarballs your working tree and spawns ephemeral Vercel Sandbox microVMs. Each sandbox gets the tarball, relevant file context, and your project's INFO.md—a 50-100 line document that you (or an agent) write once to explain the codebase's security primitives.

The INFO.md is critical. It might contain details like: "This application uses a custom AuthContext that wraps Next.js middleware. All routes under /api/admin/* must call requireRole(['admin']) before processing requests. The User model has a tenantId field that must be validated on all queries to prevent cross-tenant data access." The LLM uses this context to reason about whether the matched code is actually vulnerable or a false positive.

All intermediate state lives in .deepsec/data/ with explicit SQLite-like schemas. The FileRecord table tracks which files have been processed, and RunMeta stores configuration and checkpoint data. This design choice enables crash recovery—if your $20K scan dies halfway through, rerunning skips already-analyzed files. For a 100K-line codebase, this can save hours and thousands of dollars.

The distributed execution model solves a problem that plagues most agent frameworks: safely running LLM-generated code. Deepsec sandboxes have explicit network egress whitelisting—they can only reach out to LLM APIs, not exfiltrate data to arbitrary endpoints. AI credentials are injected server-side rather than passed from the client, preventing leakage even if the sandbox is compromised.

The revalidation phase is clever. It runs git log against each finding to check if the vulnerable code was modified in recent commits, particularly looking for patterns like "fix: security" or "patch: CVE-*". If it finds evidence of a patch, it flags the finding as potentially stale. This cuts false positive rates dramatically in codebases with active security remediation.

The tool is explicitly designed to be agent-driven rather than human-driven. The repository includes SKILL.md (teaches coding agents how to use Deepsec), SETUP.md (guides agents through bootstrapping project context), and writing-matchers.md (enables agents to generate new matchers). This meta-loop is fascinating: an LLM can read the documentation, understand your codebase, write custom matchers for project-specific patterns, then drive the scan workflow—all without human intervention beyond approving the scan budget.

Gotcha

The economics are brutal. Deepsec targets 'deep-thinking' models at maximum reasoning levels—OpenAI's o3 or Anthropic's Claude Opus. Even with aggressive matcher filtering, a medium-sized repository can generate hundreds of suspicious sites that each require multi-file context analysis. At $0.01-0.05 per reasoning step, costs escalate quickly. The documentation openly warns that scans can cost 'thousands or tens of thousands of dollars.' This isn't a tool you run on every pull request; it's a quarterly audit tool or a pre-acquisition due diligence step.

The matcher-driven approach has blind spots. If your custom matchers don't cover a vulnerability class, Deepsec never investigates it. Unlike CodeQL's comprehensive dataflow analysis that can find taint flows regardless of source pattern, Deepsec only looks where you tell it to look. A sophisticated attacker exploiting an uncommon pattern—say, prototype pollution in a custom serialization library—will slip through unless you've written a matcher for it. You're trading coverage for precision, which is the right tradeoff for targeted audits but wrong for comprehensive security postures.

The revalidation git-history check assumes clean version control hygiene. Merge-heavy workflows, cherry-picks across branches, or backports to maintenance releases will confuse it. It might mark real issues as 'already fixed' because it sees a similar commit message on a different branch, or flag fixed issues as vulnerable because the patch landed in an unconventional way. Teams with messy git histories should treat revalidation results skeptically.

Verdict

Use if: You're conducting security due diligence for an acquisition, auditing a legacy codebase with complex project-specific security invariants (custom authz frameworks, bespoke crypto protocols), or preparing for regulatory compliance audits where finding one critical vulnerability justifies five-figure costs. The agent-steered workflow shines when you have unique security requirements that off-the-shelf SAST can't express. Skip if: You need CI-integrated security checks (too slow and expensive), your primary risks are dependency vulnerabilities or infrastructure misconfigurations (Deepsec only analyzes application code), you lack budget authority for four-to-five-figure scans, or your team can't distinguish LLM hallucinations from real findings. For daily scanning, stick with Semgrep or Snyk. For deep audits where finding one pre-auth RCE pays for the entire tool, Deepsec is worth evaluating.