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

There are now four genuinely different ways to look for vulnerabilities in an application, and each one tests something the others structurally can’t. This goes on a spectrum from pattern based matching (known as traditional SAST, which checks code against known patterns), to deep agentic reviews. Those agentic reviews are either early signals (Deep PR Reviews), which reasons about how a change interacts with code elsewhere in the repository, AI Code Analysis (what the market often refers to as “AI SAST”), which reasons about a codebase’s logic without needing to be deployed anywhere, or AI pentesting, which reasons the same way, but against a live, running target, and proves what it finds by attempting to exploit it. This piece helps you understand which tool is best for which use case. TL:DR These four aren't competitors. Each works differently, not just at different depths. SAST is deterministic: the same code always produces the same result, but only for patterns it already knows. Deep PR Review, AI Code Analysis, and AI Pentest all reason about logic and intent instead, catching what SAST structurally can't, at different scopes and different points in the lifecycle. Coverage: SAST. Broad, continuous and cheap. It runs on every commit, pull request and known pattern. This is your gate. It is also very valuable in the IDE, where it can run while the developer or agent is creating code, so you get feedback before any code is even committed. Early-signal: Deep PR Review. Reasons about business logic on every pull request, catching IDORs, broken access control, and other flaws that SAST and a fast human review both miss. It reviews each change as it's opened, reasoning about what that change affects elsewhere in the codebase. Confidence: AI Code Analysis. The same reasoning as Deep PR Review, applied across the whole repository rather than one change at a time. This reach makes it the right layer for meaningful changes and hard-to-test targets, surfacing real logic flaws well before a live target even exists to test against. Proof: AI Pentest. The same reasoning, validated against a live system through real exploitation. This provides clear evidence rather than an estimate, which is also why it also satisfies compliance needs. Together, they cover the full lifecycle: every commit, every meaningful change, and every release that needs proof. Here's what each one covers in practice, starting with the base layer. What SAST tests: known patterns, deterministically Static Application Security Testing works on flagging patterns, for example, a tainted parameter flowing into a database call. If you run the same code through it twice, you’ll get the exact same result. The limitation is that it doesn’t have the ability to reason. A rules engine has no model of what the application is actually doing. Instead, it reads code line by line, matching patterns it already knows, and it can’t tell trusted data from untrusted data as that data moves through the app. Take the textbook SQL injection: a user input dropped straight into a query. It still happens, but in mature code it rarely looks that clean. Untrusted data usually enters somewhere harmless, like a request header, then travels through several unrelated functions before it reaches a sink and turns dangerous, often several layers downstream. A pattern-matching scanner can't follow that path. It can't separate trusted data from untrusted as the data moves, so it flags anything that resembles an injection whether or not an attacker could ever reach it. Those unreachable flags are where the noise comes from, and they are why pattern matching gave SAST its reputation for false positives. But that doesn't mean SAST shouldn't be used. If SAST flags twelve issues on Monday and nine on Tuesday against identical code, developers stop trusting it. Research shows that 65% of teams say false positives force them into risky behavior, whether that's delaying fixes, dismissing alerts, or bypassing checks, though Aikido's AutoTriage is built specifically to cut through that noise before it reaches a developer. Even with that cost, SAST still runs cheaply enough to gate every commit, which is exactly what CI/CD, regression testing, and compliance all need. Deep PR Review reasons about a change before it merges Reviewing a diff on its own misses how that change behaves once it meets the rest of the application. Deep PR Review (often called AI Code Review in the industry) is built to look past the diff. Rather than judging a change in isolation, it reasons about how that change interacts with code elsewhere in the repository, including shared libraries and services in linked repos. It’s essentially what you’d ask a senior engineer to do, if they had the bandwidth to actually trace every dependency before approving a PR (wishful). As a result, you can surface bugs like crossover data leaks or broken access control - business logic flaws that neither a quick human review nor a pattern-matching tool would be able to catch, because none of it is visible from the changed lines alone. These are usually the kind of findings that would otherwise turn up in a pentest, or in production, weeks or months after the code was written, once the person who wrote it has moved on and no longer has the context to explain the decision. Deep Review moves them earlier, into the pull request itself, so that the person who wrote the change still remembers why they wrote it that way. Feedback can be provided directly on the PR, so “this is intentional" or “this is a false positive” provides clarity without having to switch tools or leave the review. AI Code Analysis tests intent and logic, without a live environment Rather than matching patterns, AI Code Analysis (what the market often calls "AI SAST") reads your source code and reasons about it the way a senior engineer would during review. It follows references across files, traces a request from the route handler down through the database query, and asks whether the code does what it's supposed to. It can do this across a repository, or several connected repos including monorepos across front-end, back-end and infrastructure-as-code. All it needs is access to the repo. Reasoning allows it to catch business logic flaws, something SAST can’t do. IDORs are a good example of this, because reasoning is required to know whether an endpoint should be scoped to the requesting user or not. Changing a user ID to view someone's public profile might be expected behavior. Changing it to view their private messages or account settings is a breach. That distinction depends on what the endpoint is supposed to enforce, not on the resource itself, which isn't something you can write a static rule for. It also doesn’t need a live target to do this. You don’t need to set up a staging environment (meaning no configured auth flow) because the review runs directly against the code repo, which means it can reach things a live pentest can’t, such as code sitting behind a feature flag, admin-only routes with no credentials supplied, and denial-of-service patterns that wouldn’t be safe to run against a production system. The same reasoning can be applied to mobile apps, smart contracts, desktop applications, and essentially any programming language, including older or niche ones a rule-based scanner was never written to support. This is the same kind of reasoning Deep PR Review applies at PR level but the difference is that the Deep PR Review catches issues for each change, checking one pull request against the wider codebase. AI Code Analysis on the other hand, reasons across the entire codebase at once, which is why it fits best on major changes and full releases (it’s the recommended ‘Get Started’ step), while Deep PR Review covers the ongoing PR-level analysis after. It's worth being clear about why this isn't the same as asking a model directly to review your code. A model asked directly gives you one general-purpose pass, closer to a developer skimming for obvious breakage than a thorough review. AI Code Analysis wraps that same model in a harness that runs recon, hunts in parallel, and validates independently across every repo, and that orchestration is what accounts for most of the real-world difference in bugs found. The tradeoff between traditional SAST and AI Code Analysis isn't just cost. Reasoning across an entire codebase takes more compute and more time than pattern matching, and because there's no live application to exploit against, findings are prioritized by how likely they are to be real rather than confirmed through execution. SAST's speed and determinism are what let you put it directly in CI/CD, which is why AI Code Analysis fits best on meaningful changes and major releases rather than on every commit. But the cost and efficiency of agentic features is continuously improving, and so we will see all of these AI capabilities become commonplace for organizations. AI pentesting reads your code and runs against your app AI pentesting, which is what Aikido Attack is, uses the same underlying reasoning approach as AI Code Analysis. But pentesting goes a step further by running against a live application. This means it can attempt actual exploitation through agents issuing real requests and mapping a real attack surface. That live validation is what removes most of the false-positive problem (which we’ll get into in more detail in the next section). AI Code Analysis can reason that a business-logic flaw like IDOR looks present from the code; a pentest can attempt the exploit against the running system and confirm whether it actually works. A pentest needs a stable environment, working authentication, and real configured user roles already in place, none of which AI Code Analysis requires since it reads straight from source. Once that environment exists, the test itself runs quickly, but processing live traffic and working out what a given interaction actually does still costs more per run than reasoning over text, which is why a pentest sits above both SAST and AI Code Analysis on compute cost. An AI pentest is also the only one of these three that satisfies the compliance requirements for frameworks such as SOC2 and ISO 27001 for a live penetration test. AI Code Analysis can't stand in for a live penetration test where compliance requires one, but running it beforehand can still be beneficial. Cleaning up logic flaws ahead of the audited pentest means fewer findings for the live test to catch, at a lower cost per engagement. It’s also worth noting that giving a pentest agent access to source code (called whitebox testing) significantly changes what it finds (and the cost to do so). Across more than 1,000 AI pentests run on Aikido’s platform, engagements with code access (whitebox) surfaced a median of seven times more high and critical findings than engagements without it (greybox), at roughly half the compute cost per finding. Greybox testing needed 31 agent launches to surface a single vulnerability, against 15 for whitebox. So by effectively combining the two (source-code access reasoning provided in AI Code Analysis) with the live exploitation of AI pentesting, you’re finding more of the picture than either one running alone. This is an easy selection choice for “whitebox” in the UI for Aikido Attack. If you're unsure about how to assess AI pentesting products, check out our buyer's guide. Why one produces more false positives AI Code Analysis reasons about your code without running it. It can see that a request reaches a dangerous operation and that nothing along the way stops it, and flag that as exploitable. Because it works from source rather than a live target, some of what it flags will turn out to be guarded by something the model couldn't see from the repo alone. A pentest adds live exploitation on top of that same reasoning. It fires the suspected vulnerability against the running app and reports what actually landed, which is why its findings come with evidence rather than an estimate. Running both closes the gap in each direction. AI Code Analysis reaches code a pentest never touches, like anything behind a feature flag or an admin route without credentials. A pentest confirms what AI Code Analysis flags, once a live target exists to test against. Which one do you need? Matching spend to risk Budget and risk tolerance decide how much of your estate each agentic tool needs to cover. A small team gets a strong, cost-effective baseline from AI Code Analysis alone, running against existing code to catch what’s gone unnoticed so far. There's no environment to stand up first, no auth to wire up, which makes it the layer that can start covering risk before anything else is in place. Layering in Deep PR Review from there keeps that baseline from skipping as new code ships, catching business logic issues on each pull request without needing a live environment or a scheduled pentest cycle. An AI pentest (Aikido Attack) sits above the reasoning layers as periodic, live validation, typically yearly or with major releases, checking the complete environment and configuration rather than the code alone. Most orgs run AI Pentest at that cadence, often to satisfy a compliance requirement like SOC 2 or ISO 27001. Continuous AI pentesting (Aikido Infinite) sits above that as a separate tier, for teams whose security posture demands exploitability checked on an ongoing basis rather than at scheduled intervals, regardless of company size. Most teams are somewhere in this progression, where the real question is scoping: which repos and releases justify a scheduled pentest, and which ones AI Code Analysis and Deep PR Review can cover between them day to day. Running the reasoning layers first and remediating before the pentest is one way to make that spend go further, since a cleaner target means fewer pentest findings spent on things caught cheaper upstream. Treat this as a starting default that teams adjust from their own risk profile. To summarize In practice, full-lifecycle coverage means running all four together, depending on your needs at a given time. SAST covers every commit and pull request, and runs continuously. Deep PR Review reasons about business logic on every change as it lands, before it merges. AI Code Analysis extends that same reasoning across the whole repository on meaningful changes, before anything is even deployed, and can catch misconfigurations or environment-specific settings a live test might miss. AI Pentest covers periodic live validation, the most thorough check available and the one compliance frameworks expect, with Continuous Pentest available for teams whose security posture calls for that validation on an ongoing basis rather than at scheduled intervals. The strongest security programs run all four, layered, rather than choosing between them.