Post-legacy SAST redefines code security for AI-driven development

At a glance

What this is: This article explains why legacy SAST struggles in AI-driven development and why post-legacy SAST focuses on behavioral analysis, reachability, and earlier scanning.

Why it matters: It matters because AppSec teams need controls that can keep pace with human and agentic code production, reduce noise, and surface exploitable issues before merge or release.

By the numbers:

• Legacy SAST tools exceed 50% false positive rates, according to Arnica.
• AI agents contribute a growing share of net-new code across engineering orgs, and 84% of developers now use AI tools, according to Arnica.

Context

Legacy SAST was designed for slower release cycles, smaller change volumes, and code that could be reviewed after the fact without overwhelming engineering teams. AI-assisted development breaks that model by increasing throughput, changing code patterns, and shortening the window in which security findings remain useful. The governance problem is no longer whether code is scanned, but whether scanning is aligned with how modern software is produced and reviewed.

For identity and access practitioners, the key intersection is that agentic development now behaves like a non-human production actor inside the software supply chain. When agents create code, introduce secrets, or commit changes autonomously, the control point shifts from post-merge inspection to issuance-time and workflow-time governance. That is a familiar pattern for NHI security, even if the domain here is application security.

The article's starting position is typical for current AppSec programmes: most teams have inherited controls that still assume human pacing and bounded change volume. AI coding agents expose that mismatch quickly, especially where triage capacity and developer trust are already under strain.

Key questions

Q: What breaks when AI SAST is used as a replacement for normal SAST?

A: AI SAST is strongest on logic-heavy defects, but it is slower and less deterministic than traditional SAST. If you replace fast pattern-based scanning with reasoning-only analysis, you lose cheap continuous coverage on known vulnerability classes and create blind spots in CI/CD. The better model is layered: deterministic SAST for volume, AI SAST for logic, and runtime testing for proof.

Q: Why does reachability analysis reduce SAST noise?

A: Reachability analysis reduces noise by checking whether a flagged weakness sits on a code path an attacker can actually traverse. That removes dead code and unreachable library functions from the highest-priority queue, which improves developer trust and makes remediation bandwidth go further.

Q: What do security teams get wrong about post-merge scanning?

A: Teams often treat post-merge scanning as if it were still timely enough to guide fixes, but by then the code may have moved through multiple hands and lost context. That turns security feedback into backlog management instead of decision support, which is too late for fast-moving development.

Q: When should teams reconsider their SAST model for AI-assisted development?

A: They should reconsider it when findings are consistently dismissed, false positives dominate the queue, or scan latency starts interfering with delivery. Those are signs that the control is no longer aligned with how code is actually produced and reviewed in the organisation.

Technical breakdown

Why rule-based SAST misses exploitable paths

Legacy SAST relies on static pattern matching. It compares source code against a library of known bad signatures and flags anything that resembles them, which works only when the risk pattern was anticipated in the rule set. That approach breaks down when code contains novel logic, context-dependent safety conditions, or AI-generated structures that do not map cleanly to known templates. Behavioral analysis is different because it follows data flow and execution logic rather than simple syntax. Reachability adds another filter by asking whether the vulnerable path is actually callable from an entry point. Together, those mechanisms separate theoretical defects from exploitable ones.

Practical implication: Prioritise tools that combine behavioral analysis with reachability so reviewers spend time on live risk, not dead-code noise.

How agent-time scanning changes the control point

Agent-time scanning moves security review closer to the moment code is produced. Instead of waiting for a CI/CD batch job after merge, the control evaluates AI-generated output while the context is still fresh and the change set is small. That matters because AI agents can generate large volumes of code in a single session, and delayed scanning allows risk to compound before anyone reviews it. PR-native scanning serves a similar goal for human developers by putting findings into the workflow where decisions are made. The architectural shift is from after-the-fact inspection to in-flow governance.

Practical implication: Place scanning as close as possible to code generation or pull request review so remediation stays attached to the original decision.

Why false positives become a governance problem

False positives are not just an inconvenience. When a scanner routinely produces noisy results, developers stop trusting it and security teams lose the ability to influence real design choices. The article's point about exceeding 50% false positives is important because high noise turns vulnerability management into queue management, which is an unsustainable operating model in AI-driven development. Reachability, contextual analysis, and better severity ranking are all attempts to restore trust in the control. Without that trust, the scanner exists but the governance function does not.

Practical implication: Track alert precision and developer dismissal rates as operating metrics, not just total findings or scan coverage.

NHI Mgmt Group analysis

Post-legacy SAST is really about governance latency, not just scanner accuracy. When development cycles compress, a control that produces findings after the code has already moved on is no longer a preventative control in practice. The relevant question is whether security feedback lands while developers can still act on it without rework becoming expensive. Practitioners should treat scan timing as a governance attribute, not a deployment detail.

Behavioral analysis creates a more durable security model than pattern matching. Rule sets only work as long as the vulnerability shape is known in advance, which is a weak assumption in AI-assisted development. A behavioral model that traces execution and reachability better matches how exploitable defects actually emerge in modern codebases. For AppSec teams, that means evaluating evidence of live paths rather than raw issue counts.

AI coding agents are acting like non-human contributors to the software supply chain. That makes their output a governance object, not just a developer productivity artifact. If agents can introduce secrets, generate flawed code, or accelerate merge volume, then the security model has to account for machine-speed creation and review. The practitioner conclusion is straightforward: workflow-time controls matter more when code is produced by software as well as people.

Legacy SAST exposes a structural assumptions gap that many programmes have not named. The old assumption was that security could review code after creation without losing context or trust. AI-driven development breaks that assumption because the volume, novelty, and speed of changes overwhelm after-the-fact triage. Teams should reframe the issue as a control design problem, not a tuning problem.

Reachability filtering is the named concept that best captures the post-legacy shift. It defines the difference between defects that exist and defects that matter operationally. In practice, reachability helps AppSec teams defend developer attention as a scarce resource and reserve escalation for code paths an attacker can actually traverse. The practitioner conclusion is to make exploitability the triage standard.

From our research library:

• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Reachability is becoming the practical divider between security theatre and usable AppSec control. When teams cannot tell whether a flagged issue is actually callable, they end up spending attention on defects that do not change exposure. That is why post-legacy SAST is best understood as a shift toward exploitability-aware governance, not just better tooling.

Agentic development forces security teams to treat code creation as a non-human workflow worth governing directly. When AI agents can introduce risk at production speed, review-only controls arrive too late to be decisive. The stronger programme posture is to embed policy and detection at the point of code generation, then use pull request workflow controls to preserve developer trust.

For practitioners

• Adopt reachability-based triage Filter SAST findings by whether the vulnerable code path is callable from a live entry point before routing them to developers.
• Move scanning into pull request workflows Surface findings while code review context is still fresh so the original author can resolve issues without a separate security back-and-forth.
• Evaluate agent-time detection for AI-generated code Treat AI coding agents as high-velocity code producers and inspect their output during generation, not only after merge.
• Measure alert precision as an operating metric Track false positive rate, dismissal rate, and time-to-remediation to determine whether developers still trust the scanner output.

Key takeaways

• Legacy SAST struggles when AI-assisted development increases code volume, novelty, and the speed at which security feedback expires.
• Reachability and behavioral analysis help separate exploitable paths from dead-code noise, which changes triage priorities.
• AppSec teams should move controls earlier in the workflow if they want developers to trust and act on findings.

Key terms

• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Behavioural Analysis: Behavioural analysis is the practice of judging an identity by how it acts, not only by the credentials it presents. For AI agents, this means monitoring task paths, tool use, and interaction patterns so deviations from approved behaviour can be detected and investigated.
• Agent-Time Scanning: Security inspection that happens while an AI coding agent is generating code rather than only after the code is committed. It is designed to catch risky output before it enters the review queue or expands into a larger remediation backlog.
• False Positive Rate: False positive rate is the share of alerts, detections, or test results that incorrectly indicate a problem when none exists. In security and identity operations, it measures how often a control flags benign activity as suspicious, usually expressed as a percentage of all negative cases. Lower rates reduce analyst noise and wasted response effort.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to govern non-human access patterns alongside modern engineering workflows.