How should AppSec teams use LLMs without replacing SAST?

Why This Matters for Security Teams

AppSec teams are under pressure to find more issues faster, but LLMs change the shape of the problem rather than removing the need for a proving control. SAST remains valuable because it is deterministic, repeatable, and auditable across every build. LLMs can help surface likely hotspots, explain patterns, and accelerate developer response, but they can also miss context, hallucinate root causes, or overstate confidence. That is why current guidance from the NIST AI Risk Management Framework matters here: AI should support risk decisions, not silently become the decision.

The practical risk is not simply false positives. It is control substitution, where teams let natural-language output stand in for analysis that should be enforced by code scanning rules, policy checks, and traceable findings. This becomes especially dangerous in release pipelines, where speed pressure makes AI summaries feel “good enough” even when evidence is incomplete. The safer pattern is to use LLMs as a discovery and triage layer, then require SAST to confirm whether a finding is real, reproducible, and actionable. In practice, many security teams encounter AI drift only after a rushed release has already bypassed the control they thought was still in place.

How It Works in Practice

The most effective pattern is layered validation. LLMs can review diffs, summarize stack traces, suggest likely weakness classes, and cluster similar findings so analysts spend less time on repetitive sorting. SAST then performs the harder job: scanning source code against known rules, data flows, and policy thresholds. That division of labor matches the intent behind the NIST AI 600-1 Generative AI Profile, which emphasizes managing generative AI risk in context rather than treating model output as ground truth.

In practice, AppSec teams usually get the best results when LLMs are inserted before or around SAST, not in place of it:

• Use the model to prioritize files, functions, and changes that deserve deeper scanning.
• Have it explain suspected issues in developer language, then link those summaries back to scanner evidence.
• Use it to deduplicate noisy findings and suggest ownership for remediation.
• Keep policy decisions, severity assignment, and release gating inside SAST or a comparable deterministic control.

This is also where prompt discipline matters. If an LLM is allowed to infer security impact without ground truth, it can introduce its own failure modes, which the OWASP Agentic AI Top 10 and the MITRE ATLAS adversarial AI threat matrix both treat as important risk areas. A practical implementation should therefore log prompts, preserve scanner evidence, and require human review for any AI-assisted exception. These controls tend to break down when the codebase is highly dynamic, the scanner has weak language coverage, and teams start relying on AI summaries to compensate for missing SAST rule depth.

Common Variations and Edge Cases

Tighter AI-assisted workflows often increase analyst overhead at first, requiring organisations to balance speed gains against governance, review effort, and model risk. That tradeoff is worth making when the pipeline is noisy, but current guidance suggests avoiding full automation where the model cannot be anchored to source evidence. For teams working on agentic systems, the distinction matters even more, because the same model that explains a finding may also be capable of tool use or workflow initiation, which raises additional control concerns under the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework.

Edge cases usually appear in three places. First, legacy codebases may produce so much scanner noise that teams are tempted to trust AI triage too much. Second, highly regulated environments may require explainability, evidence retention, and traceability that an LLM alone cannot provide. Third, if the model is connected to repositories or tickets, it can be influenced by malicious comments, poisoned examples, or prompt injection. Best practice is evolving, but the operational rule is stable: let LLMs assist with discovery and communication, while SAST remains the control that decides whether a code path meets policy. That split is especially important when release speed is high and exception handling is informal, because those conditions make silent control replacement most likely.

Related resources from NHI Mgmt Group

• How should security teams use LLMs for identity analytics without losing control?
• How should security teams use LLMs in vulnerability research without overtrusting them?
• How should security teams use UEBA without replacing IAM controls?
• How should security teams use activity-based access control without replacing RBAC entirely?