Skip to content

Back to the catalog

Finding vulnerabilities at every stage: what to run, and when
aikido.devarticle

Finding vulnerabilities at every stage: what to run, and when

Aikido breaks down four distinct approaches to finding vulnerabilities in code: deterministic pattern-matching SAST, Deep PR Review (reasoning about a diff's impact on the wider codebase before merge), Code Security Audit/'AI SAST' (LLM-based reasoning across a whole repo without a live target), and AI pentesting (the same reasoning validated via live exploitation against a running app). It explains why each produces different false-positive profiles, why whitebox AI pentests (with source access) found a median 7x more high/critical findings than greybox in over 1,000 Aikido engagements at roughly half the compute cost per finding, and gives guidance on which layer to run at which stage of the SDLC and for which compliance needs (SOC 2, ISO 27001).

TL;DR Aikido's framework for choosing between SAST, AI code review, AI code audit, and AI pentesting across the dev lifecycle, backed by whitebox-vs-greybox pentest data.
Open original ↗
Document

What it is

A vendor argument piece from Aikido laying out how to sequence four vulnerability-finding layers across a real budget and SDLC, plus the concrete metrics behind its whitebox-pentest claim. The existing summary names the four approaches and the headline 7x figure; what it doesn't carry is the actual deployment recommendation, the product names, and two supporting numbers.

What to do

The page's operational recommendation, which the summary compresses to "guidance on which layer to run":

  • Start with Code Security Audit — it's the recommended "Get Started" step. It needs only repo access (no staging environment, no auth wiring), so it's the layer a small team can stand up before anything else exists.
  • Layer in Deep PR Review next for ongoing per-change coverage as new code ships.
  • Keep SAST in CI/CD and the IDE as the cheap, deterministic gate on every commit.
  • Run an AI pentest periodically (yearly or per major release) — the only layer that satisfies SOC 2 / ISO 27001 live-pentest requirements.
  • Remediate with the reasoning layers before the pentest. A cleaner target means fewer pentest findings spent on issues catchable cheaper upstream — the page's explicit cost-reduction lever.
  • Select whitebox in Aikido Attack (give the pentest agent source access) — it's a single UI toggle.

Product mapping: Deep PR Review is marketed elsewhere as "AI Code Review"; Code Security Audit is "AI SAST"; AI pentest is Aikido Attack; continuous pentest is a separate tier, Aikido Infinite.

Supporting numbers the summary omits

  • Across 1,000+ engagements, greybox needed 31 agent launches to surface one vulnerability vs. 15 for whitebox — the mechanism behind the "half the compute cost per finding" claim.
  • 65% of teams say false positives force risky behavior (delaying fixes, dismissing alerts, bypassing checks). Aikido's AutoTriage is positioned to cut this noise before it reaches a developer.

Caveats

This is Aikido marketing; every "layer" maps to an Aikido product and the metrics are self-reported from Aikido's own platform, not independently verified. The page also concedes Code Security Audit cannot stand in for a compliance-mandated live pentest, and that its no-live-target findings are prioritized by likelihood, not confirmed by execution — so some will be guarded by controls the model couldn't see from source.

Technologies named here

Techniques named here

Related in AppSec