Legacy scanning-led programs often overfocus on custom code and known CVEs while underweighting the wider application surface, including dependencies, infrastructure as code, cloud settings, and API controls. That creates false positives, alert fatigue, and misprioritised work. Attackers usually prefer simpler, known weaknesses, so the program needs to reflect exploitability, context, and likely attacker behavior.
Why This Matters for Security Teams
Legacy scanning-led AppSec programs often treat “what can be scanned” as the same thing as “what matters most.” That usually means custom code and known CVEs receive the bulk of attention, while dependency risk, secrets exposure, cloud configuration drift, API authorization gaps, and build pipeline weaknesses remain underweighted. The result is not just missed coverage but misallocated effort: teams spend time chasing low-value findings while exploitable issues stay live in production. The broader risk picture described in NHIMG’s Top 10 NHI Issues and the Ultimate Guide to NHIs shows why identity, secrets, and access controls are often the real attack path, not just vulnerable code. NIST’s Cybersecurity Framework 2.0 also pushes teams toward risk-based prioritisation rather than checkbox coverage. In practice, many security teams discover this only after attackers exploit the easiest path, not after their scanners have finished reporting.
How It Works in Practice
A scanner is good at finding known patterns in code and packages, but it cannot fully judge exploitability in context. A medium-severity library flaw may be less important than an exposed secret, a permissive cloud role, or an API endpoint that authorises the wrong tenant. That is why mature programs combine scanning with asset inventory, runtime telemetry, cloud posture review, dependency provenance, and control validation mapped to frameworks such as NIST SP 800-53 Rev. 5 Security and Privacy Controls. NHIMG’s The State of Secrets in AppSec is especially relevant here: it highlights how secrets management gaps, fragmented tooling, and slow remediation create persistent exposure that scanners alone do not resolve.
A practical operating model usually includes:
- Risk ranking based on exposure, privilege, reachable attack paths, and business criticality.
- Dependency and secrets detection paired with ownership and revocation workflows.
- IaC and cloud policy checks that validate live configuration, not just committed code.
- API testing that focuses on authentication, authorisation, and object-level access control.
This is where current guidance suggests a shift from “find everything” to “prove what is exploitable.” It is especially important when the application estate includes ephemeral services, external SaaS integrations, or CI/CD pipelines that change faster than review cycles. These controls tend to break down when security tooling is isolated from deployment pipelines because the scanner sees code that no longer matches the running environment.
Common Variations and Edge Cases
Tighter scanning coverage often increases operational noise, requiring organisations to balance detection breadth against analyst capacity. Not every missed issue is equally important, and there is no universal standard for prioritisation yet, so best practice is evolving toward context-aware triage rather than raw finding counts. For example, a low-severity issue in an internet-facing API with weak authentication may deserve higher priority than a critical flaw in a component that is not deployed or cannot be reached. Similarly, secrets exposure in source control may be more urgent than a code vulnerability because compromise paths are faster and more reliable.
NHIMG’s OWASP NHI Top 10 is useful for teams modernising beyond scanner-first thinking, because it reinforces that identity, tokens, and runtime permissions are part of the application attack surface. The same lesson appears in the industry data from The State of Secrets in AppSec, which shows how remediation delays and fragmented secrets tooling can undermine even well-funded programs. A scanner-first model works least well in fast-moving cloud-native environments, where access is dynamic, workloads are short-lived, and the most dangerous weaknesses often sit outside source code.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA | Risk assessment is the core fix for scanner-only prioritisation. |
| NIST SP 800-53 Rev 5 | RA-5 | Vulnerability scanning must be paired with risk-based triage and validation. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Secrets and identity gaps are often missed by code-centric scanners. |
| NIST AI RMF | Context-aware risk framing helps avoid overreliance on tool output. | |
| NIST Zero Trust (SP 800-207) | RA-3 | Attack-path thinking aligns with zero trust validation of access and exposure. |
Rank findings by exploitability, exposure, and business impact before assigning remediation.
Related resources from NHI Mgmt Group
- Why do security audits often miss the most important identity risks?
- Why do AI observability programs often miss important failures in JVM based applications?
- Why do posture assessments often miss the biggest access risks?
- Why do point-in-time pentests miss important risks in fast-changing environments?
