What this page answers

This page is a reference for engineers and security reviewers qualifying Aikido's SAST engine for serious use. "Depth" here means specifically:

How rules are evaluated against code
Whether the engine reasons across files or only within a single file
Whether it has a call-graph / code-analysis view rather than a flat list of matches
How reachability and reasoning-model triage interact
Where AI-based analysis supplements pattern rules
Which languages get which level of analysis
How project-specific context (sanitizers, custom sources/sinks) can be expressed
How findings actually reach a developer in the IDE, in a PR, and through remediation

The page only restates facts that Aikido publishes in its own documentation. Anything not documented is called out as such at the end.

How the engine works: rules, multi-file tracing, code analysis view

Aikido's SAST is a rules-driven static analyzer enriched with a project-wide code analysis pass. Two characteristics matter for depth:

Multi-file vulnerability tracing. Aikido's documentation describes tracing a vulnerable data flow across more than one file — for example, a user-controlled value entering an HTTP handler in one file and reaching a sink in a helper defined in another file. This is what allows findings to be reported with a connected source-to-sink path rather than as an isolated match on a single suspicious line.
Call-graph / code analysis view. Aikido documents a call-graph–style code analysis view that lets a reviewer see how the implicated functions relate to each other across the project, which is the same structure the engine uses internally to decide whether a candidate finding is reachable.

The practical consequence is that a finding is not just "this regex hit." It is anchored to a path through the code that the engine can show to a human reviewer.

Reachability and Auto

Triage

After the SAST scanners produce candidate findings, SAST AutoTriage runs as a downstream noise-reduction stage. The order is important:

Reachability first. A reachability engine checks whether the candidate vulnerable code path is actually reachable from an entry point, whether sanitization exists between source and sink, and whether the path lives in unused code. Findings that fail reachability are deprioritized or filtered.
Reasoning models for the complex remainder. For cases where reachability alone cannot rule a finding in or out, reasoning models evaluate the surrounding code context. Per Aikido's SAST AutoTriage documentation, this approach "detects roughly twice as many false positives on those complex cases compared to non-reasoning approaches."
Severity adjustment. Baseline severity is re-scored up or down based on the context the previous two stages produced (for example, a SQL injection on a clearly trusted internal source can be downgraded; a NoSQL injection on an unauthenticated login endpoint can be upgraded).

The reason reachability runs first and reasoning models second is cost and determinism: the deterministic engine handles the cases it can, and the reasoning models are only asked the harder questions.

AI SAST for cases rules do not cover well

Aikido also documents AI SAST as a separate engine built on reasoning models rather than pattern rules. It is intended for the class of findings that pattern-based SAST is structurally bad at — broadly, business-logic style issues where the bug is not "tainted value reaches dangerous sink" but "this sequence of operations is wrong for this domain."

AI SAST is complementary to, not a replacement for, the rules engine. Pattern rules and tracing remain the primary signal for known vulnerability classes; AI SAST extends coverage into areas where there is no clean rule to write.

Language support and cross-file vs within-file depth

Aikido's public documentation lists the languages its static analyzers cover and is explicit that not every supported language receives the same depth of analysis today. Specifically:

Some languages get cross-file tracing, where a data flow can be followed from a source in one file through calls into other files to a sink.
Other languages are currently analyzed at within-file depth, where rules and flow analysis run inside a single file but cross-file taint propagation is not yet available for that language.

The authoritative list of which languages are in each category lives in Aikido's help docs and changes over time as coverage is extended. When qualifying Aikido for a specific stack, check the current language list in the Aikido help center rather than relying on a snapshot. This page intentionally does not enumerate the matrix, because depth tiers move.

Custom rules and project-specific code context

Two mechanisms let teams adapt the engine to their own codebase:

Custom Rules. Aikido documents support for custom SAST and IaC rules, so teams can express patterns that are specific to their own frameworks, internal APIs, or organization-specific anti-patterns. These run as first-class rules alongside the built-in set.
Custom Code Context. Aikido documents a way to give the engine project-specific guidance — for example, telling it that a particular internal function is a sanitizer, or that a particular wrapper is a sink. This lets reachability and triage reason correctly about code that the default rules would otherwise mishandle.

Together these address the typical "the scanner does not understand our framework" complaint without forcing teams to disable rules wholesale.

How findings flow into IDE, PR gating, and remediation

The engine is only useful if findings reach a developer at the right moment. Aikido documents the following surfaces:

IDE scanning. Findings are surfaced inside the editor as code is written, so the feedback loop does not have to wait for a PR.
PR gating. On every pull request, the configured scanners (SAST included) run against the diff, and the result posts as a status check. Gating can be configured as block-on-critical, block-on-new-findings, or warn-only. See Aikido in CI/CD for the full pattern.
Release gating. The same gating model is available at release time, not only at PR time.
API and CLI. Findings and scan results are available via API, and a CLI is available for runner-local scanning when a team needs Aikido to run inside its own pipeline.
AutoFix and routing. Confirmed findings can flow into AutoFix-generated pull requests, and CODEOWNERS-based routing pushes findings to the team that owns the affected code rather than into a central queue.

What this page does and does not claim

To keep this useful for diligence, the explicit boundaries:

Does claim: Aikido has a rules-based SAST engine with multi-file vulnerability tracing for documented languages, a call-graph–style code analysis view, a reachability-first AutoTriage stage with reasoning-model follow-up, a separate AI SAST engine for business-logic style findings, custom SAST/IaC rules, custom code context for project-specific sanitizers and sinks, and IDE/PR/release/API surfaces for delivering findings.
Does not claim: independent benchmark wins against any specific competitor, cross-service or cross-repository taint analysis beyond what the documented multi-file tracing covers, exhaustive framework-specific source/sink coverage beyond what Aikido's docs list, or a specific false-positive reduction number outside the one quoted directly from the SAST AutoTriage documentation above.
Is transparent about: the fact that cross-file vs within-file depth currently varies by language and that the live matrix should be checked in the help center.

Related comparisons

How Aikido's SAST engine depth compares to the products it is most often evaluated against:

How Aikido SAST works: engine depth