The use of large language models to help locate software flaws in source code or related artefacts. The model does not replace human judgement, but it can expand the search space, surface patterns faster, and accelerate expert review when the workflow is tightly controlled.
Expanded Definition
LLM-assisted vulnerability discovery is a workflow in which a large language model helps security practitioners identify likely flaws in code, infrastructure-as-code, configuration files, prompts, or adjacent artefacts. The model is used to broaden initial triage, highlight suspicious patterns, and suggest lines of inquiry, while a human analyst still validates whether a finding is real, exploitable, and in scope. This distinction matters because the LLM is not the authority on vulnerability existence, severity, or exploitability.
Definitions vary across vendors and research teams because the phrase can describe everything from natural-language code review support to semi-autonomous scanning pipelines. In practice, it sits between static analysis and manual review, with the strongest use cases appearing where a model can rank candidates, explain code context, or correlate weak signals across files. The governance lens is increasingly shaped by NIST AI Risk Management Framework and the OWASP Agentic AI Top 10, especially where the workflow can trigger tool use or modify downstream security decisions. The most common misapplication is treating model output as a confirmed vulnerability, which occurs when teams skip deterministic validation and severity assessment.
Examples and Use Cases
Implementing LLM-assisted vulnerability discovery rigorously often introduces review overhead and false-positive management, requiring organisations to weigh speed against verification cost.
- A code security team asks the model to inspect a repository for unsafe deserialisation, hard-coded secrets, or weak input handling, then uses SAST and manual review to confirm results.
- A platform team feeds infrastructure-as-code into the model to spot misconfigured storage, exposed management interfaces, or missing encryption settings before deployment.
- A red team uses the model to suggest attack paths across a large codebase, then maps those paths against known weakness classes and test cases documented in NIST SP 800-53 Rev 5 Security and Privacy Controls.
- A vulnerability management function uses the model to cluster similar findings, summarise evidence, and draft remediation notes for engineers.
- A security engineering group prompts the model to compare an implementation against secure patterns described in the NIST AI 600-1 Generative AI Profile before approving the workflow.
These use cases work best when prompts, retrieved context, and outputs are logged, and when the model is constrained from making autonomous changes. The practical value is not just faster reading, but better prioritisation of what a human should inspect first.
Why It Matters for Security Teams
Security teams care about this term because the quality of discovery directly affects risk acceptance, remediation timing, and the credibility of vulnerability programs. If the model misses a flaw, the team may gain false confidence; if it overstates issues, engineers waste time on noisy findings and important defects get buried. The right control objective is not to “trust the model,” but to govern how its suggestions enter the analysis pipeline, how they are validated, and who can approve downstream action. That is especially relevant when the workflow is connected to agentic tooling, where a model may call scanners, open tickets, or change code paths under partial autonomy.
For security leaders, the identity and accountability question is often as important as the technical result: who reviewed the output, which artefacts were used, and whether the model had access to secrets, repositories, or sensitive test data. Guidance from CSA MAESTRO agentic AI threat modeling framework and threat perspectives such as MITRE ATLAS adversarial AI threat matrix help teams think about prompt manipulation, data poisoning, and deceptive outputs. Organisations typically encounter the operational cost of this term only after a noisy model-driven review floods the backlog or, worse, a missed flaw becomes a post-incident finding, at which point LLM-assisted vulnerability discovery becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST AI 600-1, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF governs trustworthy AI use, including human oversight and validation of model outputs. | |
| NIST AI 600-1 | The GenAI profile addresses risks from generative AI workflows and their controlled use. | |
| OWASP Agentic AI Top 10 | Covers risks from agentic AI systems that can act on security tooling or code. | |
| NIST CSF 2.0 | DE.CM-8 | Supports detection process monitoring and awareness of security tooling outputs. |
| NIST SP 800-53 Rev 5 | RA-5 | Vulnerability scanning and analysis controls align with model-assisted discovery workflows. |
Define oversight, validation, and accountability before letting LLMs influence vulnerability decisions.
Related resources from NHI Mgmt Group
- How should security teams reduce false positives in LLM-assisted vulnerability discovery?
- How should security teams respond to faster AI-assisted vulnerability discovery?
- Why does AI-assisted vulnerability discovery create a review bottleneck?
- How should organisations build a vulnerability disclosure program that can handle faster AI-assisted discovery?
