TL;DR: Nearly 70% of organisations have found flaws tied to AI-generated code, 1 in 5 reported serious incidents, and engineers spend 6.1 hours a week triaging findings with 72% of that time wasted on false positives, according to Aikido’s 2026 comparison. The real issue is not scan coverage alone, but whether SAST can suppress noise, prioritise reachability, and fit developer workflows at commit time.
At a glance
What this is: Aikido argues that AI-generated code has made SAST effectiveness hinge on noise reduction, reachability, and workflow integration rather than scan volume.
Why it matters: For AppSec, IAM, and platform teams, the issue is whether security controls can still surface actionable findings fast enough to keep pace with machine-assisted development.
By the numbers:
- Nearly 70% of organisations say they have uncovered flaws tied to AI-generated code.
- 1 in 5 organisations reported serious incidents linked to AI code.
- 72% of that triage time is wasted on false positives.
Context
Static application security testing is meant to catch risky code before it ships, but its usefulness depends on whether findings are actionable enough to influence developer behaviour. In AI-assisted development, the problem is no longer just code volume, but whether review systems can separate reachable issues from noise without slowing delivery.
That creates a governance problem as much as a tooling problem. When findings flood the pipeline, security teams lose signal, developers lose trust, and the organisation inherits a weaker control even if the scanner has wide coverage. The identity angle is indirect but real: the pipeline is increasingly being fed by machine-produced code that must still be governed as part of the software supply chain.
Key questions
Q: How should security teams reduce repetitive false positives in SAST programs?
A: Start by encoding the context your scanner cannot infer reliably. Focus first on non-production code paths, then on framework protections such as authentication middleware, ORM query builders, and output encoding. Treat each memory as governed detection policy, not a one-off dismissal, so the same decision is applied consistently across future scans.
Q: Why do AI coding agents make SAST governance harder?
A: AI coding agents increase code volume and can generate findings faster than manual review can absorb, which magnifies alert fatigue. They also complicate ownership because the human reviewer, prompt author, and code maintainer may be different people. That means routing, accountability, and prioritisation all need to be identity-aware.
Q: What are the signs that a SAST or DAST program is not working well in practice?
A: Common warning signs include excessive false positives, developer fatigue, missed runtime issues, and scans that do not keep pace with delivery cycles. If teams ignore findings, delay remediation, or cannot explain which issues matter most, the program is not delivering value. A healthy program produces actionable results, fits workflows, and improves confidence in release decisions.
A: Choose AI-native SAST when you need reasoning over business logic, access control, and multi-step exploit chains that rule-based scanners often miss. Choose AI-assisted SAST when you already have deterministic scanning and want better triage, broader language support, or faster developer workflows. Many teams benefit from both, but the right mix depends on whether depth, scale, or reproducibility is the primary goal.
Technical breakdown
Why SAST gets noisier as code generation scales
SAST works by matching source code against known vulnerability patterns before deployment. That makes it deterministic, fast, and suitable for CI, but it also means the engine produces many findings that are technically true yet operationally irrelevant. As AI-generated code increases the volume of commits, the number of alerts grows faster than human review capacity. The real bottleneck is not detection itself but filtering for reachability, duplicate issues, and findings that matter in production paths. Tools that treat dead code and hot paths the same create review fatigue instead of control value.
Practical implication: Use reachability and deduplication as selection criteria, not optional enhancements.
How AI changes SAST triage and remediation
Most modern SAST tools now add AI to the layers around detection rather than replacing the underlying rule engine. AI is most useful for ranking findings, explaining why they matter, and attaching a probable fix. That changes the operational model: the scanner no longer just produces alerts, it becomes part of the remediation workflow. But AI-assisted triage only helps if the underlying output is still grounded in deterministic analysis. If the model overstates risk or proposes low-quality patches, it can increase trust problems rather than solve them.
Practical implication: Test AI triage and autofix on your own repositories before relying on vendor claims.
Why workflow integration now matters as much as detection coverage
A scanner that lives outside the developer workflow becomes a separate security queue, which is where many AppSec programmes lose momentum. The article shows why the useful control point is commit time, pull requests, and the tools developers already use. IDE feedback, PR comments, and ticketing integration reduce the chance that findings are ignored or re-entered manually. For growing teams, the control question is whether remediation reaches the people changing the code while the change is still cheap to fix, not after release.
Practical implication: Require native pull request and IDE integration before approving a SAST platform.
NHI Mgmt Group analysis
AI-generated code has turned SAST into a signal-management problem, not a scan-volume problem. The article’s core finding is that organisations are now reviewing far more machine-produced code, which amplifies the cost of noisy output. A control that cannot distinguish reachable issues from theoretical ones will eventually be bypassed by developers. Practitioners should treat alert quality as the primary AppSec governance metric.
Static analysis still matters, but its value now depends on where it sits in the delivery path. The closer findings arrive to the commit and pull-request workflow, the more likely they are to influence behaviour. This is not just a developer convenience issue. It is a control-design issue because delayed feedback turns security into after-the-fact reporting instead of change-time governance.
Human review capacity is the limiting factor that most SAST buying criteria still underestimate. The article’s 6.1-hour triage burden and high false-positive waste show that the operational constraint is reviewer attention, not scanner coverage. AppSec programmes that optimise for language counts or raw rule totals can miss the real constraint. The right design target is decision quality per alert, not alert quantity.
Reachability analysis is emerging as the practical line between governance and noise. When a finding sits in dead code, it is not equivalent to one in a live execution path, and teams need tools that respect that difference. That distinction matters for CI policy, developer trust, and escalation handling. A useful SAST programme should prove that its findings map to exploitable paths, not just syntactic matches.
AI in SAST should be assessed as a triage control, not a substitute for analysis. The article shows that AI adds value when it suppresses noise, improves prioritisation, and helps with remediation. It does not change the need for deterministic scanning or security ownership. Teams should measure whether AI improves reviewer efficiency and remediation speed without obscuring why a finding was raised.
What this signals
AppSec programmes will need to measure reviewer attention, not just scan breadth. Once AI-generated code becomes a normal part of delivery, the weak point is the queue of findings that humans have to evaluate. Security leaders should expect SAST governance to shift toward prioritisation quality, reviewer load, and whether alerts still arrive early enough to influence code before merge.
Code review controls are becoming part of identity-adjacent governance because machine-generated changes still enter human-controlled pipelines. The governance question is who or what is allowed to introduce code, under what review model, and with what assurance that the output remains explainable. Teams that treat AI-generated code as ordinary developer output will miss the need for tighter change-control discipline at commit time.
For practitioners
- Prioritise reachable findings over raw alert counts Choose SAST tools that score findings based on execution path, not just CWE match or severity labels. That reduces time wasted on dead-code issues and improves trust in the queue.
- Test autofix quality on your own repositories Validate AI-generated fixes against representative code before allowing them into production workflows. Check whether the patch preserves coding standards, test coverage, and contributor review expectations.
- Require native pull request and IDE integration Make sure findings appear where engineers already work, including editor plugins, PR comments, and ticketing systems. A separate dashboard usually becomes a separate queue.
- Tune rules for developer throughput and governance Use custom rules, deduplication, and branch-aware handling to avoid repeated alerts across merges. Revisit policy thresholds when AI-generated code volume changes the review load.
Key takeaways
- AI-generated code has pushed SAST from a detection question into a governance question about how much signal humans can still absorb.
- The practical failure mode is not lack of scanning, but alert overload that wastes reviewer time and erodes trust in the control.
- Teams should favour tools that surface reachable issues, integrate into developer workflows, and prove that AI assistance improves remediation without obscuring risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8, NIST CSF 2.0 and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | The article is about code analysis and secure development feedback loops. |
| Recommendation — Use V15 to keep security findings tied to code change and architecture review. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article focuses on application security testing inside the development lifecycle. |
| Recommendation — Apply CIS-16 to integrate SAST into software development and review workflows. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity of information and software is protected | SAST helps protect the integrity of software before it reaches production. |
| Recommendation — Use PR.DS-10 to validate code integrity and catch risky changes before release. | ||
| OWASP SAMM | Software Construction — Software Construction | The article is about how teams embed security analysis into the build and review process. |
| Recommendation — Measure and improve software construction practices that catch defects earlier. | ||
Key terms
- Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
- 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.
- False Positive: A false positive is a scanner result that looks like a secret but is not actually sensitive. In secret governance, false positives matter because they consume analyst time, weaken trust in alerts, and can delay response to the findings that truly change exposure and access risk.
- Autofix: An automated remediation workflow in which a machine reviewer not only identifies an issue but also applies a code change. In practice, this shifts the tool from advisory review into delegated execution, which requires clear permission boundaries, auditability, and rollback controls.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and the access-control principles that underpin modern security programmes. It is a fit for practitioners who need a stronger identity governance foundation across code, cloud, and AI-enabled delivery.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org