A vulnerability-specific detection pass is a scanning step tailored to one class of issue, such as SQL injection, SSRF, XSS, or access control failure. Each pass uses different prompts, evidence requirements, and validation logic because the signals that prove risk vary by vulnerability type.
Expanded Definition
A vulnerability-specific detection pass is a targeted security scan that looks for one vulnerability class at a time, rather than trying to identify every possible weakness in a single sweep. This approach is common in application security, cloud security, and agentic AI review workflows where the evidence needed to prove risk differs sharply by issue type. A pass for SQL injection may inspect query construction and database error handling, while a pass for SSRF focuses on outbound request behavior and network reachability. That separation matters because the same finding logic does not reliably apply across classes.
Usage in the industry is still evolving, especially where teams combine automated scanners, LLM-assisted analysis, and manual validation. The term is best understood as a method design choice: one set of prompts, checks, and acceptance criteria per vulnerability family. This aligns well with the broader control logic in the NIST Cybersecurity Framework 2.0, which emphasises risk-informed detection and response. The most common misapplication is treating a generic scan as if it were a vulnerability-specific pass, which occurs when teams expect one detection pattern to validate every issue class.
Examples and Use Cases
Implementing vulnerability-specific detection passes rigorously often introduces workflow complexity, requiring teams to balance narrower false-positive rates against greater tuning effort and more review steps.
- A web application team runs one pass for XSS, using payload reflection checks and output encoding review, then a separate pass for access control failures that tests role boundaries and object-level authorisation.
- A cloud security group performs an SSRF-specific pass against internal metadata and outbound request controls, while a second pass checks for open redirects that could support SSRF chaining.
- An agentic AI review process uses one pass for tool abuse paths, another for prompt injection exposure, and another for secrets leakage, because each failure mode produces different evidence.
- A red team uses targeted passes informed by current exploit patterns from CISA cyber threat advisories to prioritise issue classes that are actively being exploited.
- A governance team maps repeated passes for the same issue family into a control checklist informed by CIS Controls v8, making sure each pass has a clear validation objective and acceptance threshold.
Why It Matters for Security Teams
Security teams need vulnerability-specific detection passes because broad scans often miss edge cases, overstate confidence, or generate findings that cannot be validated with the right evidence. When the pass is designed around one issue class, reviewers can define what success looks like, what constitutes a true positive, and what proof is needed to escalate remediation. That discipline is especially important in modern pipelines where application code, infrastructure-as-code, and AI-enabled components are all changing quickly.
The identity connection becomes important when a pass examines authorisation logic, token handling, or secrets exposure in NHI and agentic AI systems. A pass aimed at access control failure may need to verify whether a service account, API key, or autonomous agent can reach resources beyond its intended scope. Teams that ignore this distinction often inherit noisy results and miss the operational path from weakness to abuse, which is why threat context from the ENISA Threat Landscape is useful when choosing which passes to run first. Organisations typically encounter the real cost only after a release, incident, or exploitation event forces them to rebuild validation around the specific flaw that was missed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack surface, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM | Detection workflows in CSF map to monitoring for specific vulnerability signals. |
| NIST SP 800-53 Rev 5 | RA-5 | RA-5 covers vulnerability scanning and supports targeted vulnerability checks. |
| ISO/IEC 27001:2022 | A.8.8 | ISO 27001 requires technical vulnerability management, which this pass operationalises. |
| OWASP Non-Human Identity Top 10 | NHI guidance stresses finding credential, token, and access-control weaknesses separately. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance distinguishes prompt injection, tool misuse, and data leakage tests. |
Run dedicated passes for secrets, tokens, and service-account misuse instead of one generic check.
Related resources from NHI Mgmt Group
- What is the difference between detection and observability in vulnerability management?
- What breaks when organisations treat agent detection like ordinary vulnerability management?
- Why do organisation-specific behavioural baselines matter for detection?
- Why does code context matter so much in AI-powered vulnerability detection?
