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

At a glance

What this is: This analysis argues that legacy SAST is mismatched to AI-driven development because it flags too much noise, scans too late, and misses reachable risk.

Why it matters: It matters because AppSec and IAM-aligned security teams must secure fast-moving development pipelines where human users and AI agents both create code and secrets exposure risk.

By the numbers:

• 84% of developers now use AI tools and AI agents contribute a growing share of net-new code across engineering orgs.
• Legacy SAST tools routinely exceed 50% false positive rates, leaving developers skeptical of every finding.

👉 Read Arnica's analysis of post-legacy SAST for AI-driven development

Context

Post-legacy SAST is about code security governance in environments where code is produced faster than traditional scanners can contextualise it. Legacy SAST assumed slower release cycles and human-paced review, but AI-assisted development changes the volume, timing, and shape of risk. The primary issue is not simply more findings, but weaker trust in what those findings mean.

This matters to identity and access governance because modern development pipelines are also NHI-heavy environments. Service accounts, API keys, and CI/CD credentials are often introduced, copied, and reused alongside code, so scanning that ignores reachability and runtime context creates blind spots in both code risk and secrets governance. Arnica’s framing aligns with the broader need to manage software systems where human developers and AI agents both act inside controlled workflows.

Key questions

Q: How should security teams handle code scanning when AI agents generate large volumes of code?

A: They should move security feedback into the same workflow where code is created, especially pull requests and agent-time checks. Batch scans after merge are too late for fast-moving pipelines. Teams should also prioritise findings by reachability and exploitability, so reviewers focus on issues that can actually be reached in production.

Q: Why do legacy SAST tools struggle in AI-assisted development environments?

A: Because they were built for slower delivery cycles and rule sets that assume predictable code patterns. AI-generated code can arrive faster than traditional scanners can contextualise it, which inflates false positives and leaves teams with alert queues they cannot trust or clear efficiently.

Q: How do organisations know whether SAST findings are actually actionable?

A: They should ask whether the vulnerable code is reachable from a real entry point, whether the issue affects active paths, and whether the fix changes production risk. Findings that exist only in dead code or blocked paths are lower priority than issues tied to live execution.

Q: What should AppSec teams do when scan noise is higher than remediation capacity?

A: They should reduce the finding set to reachable, high-impact issues, then tune workflow placement so alerts arrive during review rather than after release. If developers routinely ignore the queue, the control design needs to change, not just the threshold settings.

Technical breakdown

Why legacy SAST produces noise in fast code pipelines

Legacy SAST is pattern matching. It compares source code against a fixed library of signatures and flags anything that resembles a known weakness, even when the code path is dead or blocked by runtime controls. That approach worked when release cycles were slow and teams could manually triage large queues. In AI-driven development, the same logic creates alert saturation because volume rises faster than human review capacity. The result is not just more findings, but lower confidence in the scanner itself, which is often the real failure mode.

Practical implication: teams should measure signal quality and developer trust, not just scan coverage or finding counts.

How reachability analysis changes vulnerability prioritisation

Reachability analysis builds a call graph and checks whether a vulnerable function is actually callable from a live entry point. This filters out dead code, blocked paths, and theoretical exposures that cannot be exploited in practice. The technical shift is from static pattern detection to path analysis. That is especially important in large codebases where libraries, wrappers, and generated code can create many apparent issues that are not reachable from an attack surface. Reachability is not a replacement for secure coding, but it is a better mechanism for deciding which findings deserve immediate attention.

Practical implication: prioritise fixes on reachable code paths first and suppress unreachable findings with documented policy.

Why PR-native and agent-time scanning matter for AI coding agents

PR-native scanning places findings inside the developer workflow before merge, while agent-time scanning intercepts risk as an AI coding agent generates code. Both reduce the lag between creation and review, which is critical when a single session can produce a large volume of new code. This changes the control point from post-build remediation to in-flow governance. In practice, earlier feedback lowers friction, improves fix rates, and prevents low-quality code from compounding into a larger remediation backlog.

Practical implication: move code security controls upstream into review and generation workflows rather than relying on batch pipeline scans.

NHI Mgmt Group analysis

Legacy SAST failure is now a governance problem, not just a tooling problem. Once AI-assisted development became normal, scanners that depend on delayed batch review stopped matching how code is created. The issue is not simply false positives, but the organisational assumption that security can catch up later. That assumption no longer holds when human and AI actors both contribute to code at machine speed. The practical conclusion is that AppSec governance must move to where code is produced.

Reachability analysis is the right concept for separating exploitable risk from theoretical noise. If a flagged path cannot be reached from an entry point, the finding may be technically true but operationally irrelevant. This is a stronger control lens than raw signature matching because it ties detection to actual attackability. For security programmes, the important shift is from counting vulnerabilities to prioritising exposure that an attacker can actually use.

AI-assisted development creates code security debt that looks a lot like NHI sprawl. When agents generate code, credentials, and workflow changes across many pipelines, governance has to track both the software artifact and the identities behind it. That intersection of code security and NHI governance is where many programmes will fail if they treat AI tooling as just another developer aid. The practical conclusion is to govern agents, service accounts, and secret-bearing workflows as one control surface.

Post-legacy SAST is a symptom of the broader move toward in-flow security controls. Security teams are being pushed away from after-the-fact review and toward controls embedded in the runtime of development itself. That direction aligns with Zero Trust thinking for software delivery, where trust is conditional and continuously re-evaluated. The practical conclusion is that organisations should align AppSec, IAM, and secrets governance around continuous verification rather than end-stage inspection.

What this signals

Code security is converging with identity governance because AI-generated development depends on service accounts, tokens, and workflow identities. The more code is produced by agents, the more security teams need visibility into the credentials that let those agents operate. That makes the Ultimate Guide to NHIs relevant to AppSec planning, not just identity teams.

Reachability-first prioritisation will become a stronger control pattern than raw vulnerability counts. Organisations that cannot distinguish exploitable paths from theoretical findings will keep spending security effort on the wrong issues. The practical move is to align code scanning with risk-based triage and continuous credential governance, supported by external control references such as NIST SP 800-53 Rev 5 Security and Privacy Controls.

Agentic development expands the control surface beyond source code into the identities that produce and deploy it. As AI agents take on more code creation, the governance question becomes who or what is allowed to write, review, and merge. That is where NHI controls, secrets management, and software delivery governance need to be designed together rather than in separate silos.

For practitioners

• Measure false-positive drag in developer workflows Track how many findings are ignored, suppressed, or reopened, and compare that with time-to-fix for reachable issues. If triage fatigue is high, the scanner is failing as a governance control, not just as a detector.
• Prioritise reachable code paths over theoretical findings Use call graph and data flow evidence to rank issues by exploitability, then route unreachable or dead-code findings into a lower-priority queue with explicit review policy.
• Move scanning into pull requests and agent workflows Surface findings during review and generation rather than after merge, so developers and AI agents get feedback while code context is still fresh and fix cost is lowest.
• Treat secrets detection as part of AppSec governance Continuously scan for hardcoded API keys, tokens, and certificates across code, configs, and CI/CD assets, because post-legacy code security and secret governance now overlap in the same delivery pipeline.

Key takeaways

• Legacy SAST is no longer well matched to AI-driven development because batch scanning and rule matching cannot keep up with modern code velocity.
• Reachability analysis changes the prioritisation model by separating live exploit paths from dead-code noise, which is what teams actually need.
• Security teams should move scanning into developer and agent workflows, then govern the associated machine identities and secrets as part of the same control surface.

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.
• PR-Native Scanning: Security scanning that runs inside pull request workflows rather than after merge. It gives developers feedback while code context is still fresh, reducing handoff friction and shortening the time between issue discovery and fix.
• 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.
• Post-Legacy SAST: A newer class of static application security testing that uses behaviour, data flow, and reachability to reduce false positives and improve relevance. It is built for fast delivery pipelines where code is written by humans and AI systems at the same time.

What's in the full article

Arnica's full blog covers the operational detail this post intentionally leaves for the source:

• Concrete examples of how post-legacy SAST prioritises reachable findings over theoretical matches
• Workflow guidance for PR-native and agent-time scanning in modern development pipelines
• Implementation detail on hardcoded secret detection across code, config, and CI/CD assets
• Arnica's own framing of hybrid AI SAST behaviour analysis and remediation guidance

👉 Arnica's full post covers reachability analysis, PR-native scanning, and agent-time detection in more implementation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It helps practitioners connect identity control to the delivery pipelines and machine actors that now shape modern security risk.