They often treat SAST and SCA as a complete risk picture when they are really early signals. SAST tells you what looks dangerous in code, and SCA tells you what you shipped, but neither proves whether attackers can reach the flaw in production. Reachability still has to be tested separately.
Why This Matters for Security Teams
SAST and SCA are often useful, but they are not an end-to-end proof of security. SAST can highlight insecure patterns in source, and SCA can identify vulnerable dependencies, yet neither answers the operational question that matters most: can an attacker actually reach and exploit the issue in the running system? NIST Cybersecurity Framework 2.0 frames this gap well by treating security as an ongoing risk management problem, not a one-time code scan outcome.
That distinction is especially important in environments that rely on non-human identities, build pipelines, and automated deployment flows. NHIMG notes that 97% of NHIs carry excessive privileges and 96% of organisations store secrets outside secrets managers in vulnerable locations, which means code findings often sit alongside identity and secret-exposure issues that scanners do not fully correlate. The Ultimate Guide to NHIs is a useful reference for understanding how identity sprawl changes the risk picture.
In practice, many security teams encounter exploitability only after a production incident or a pentest has already shown the path from finding to impact.
How It Works in Practice
The practical mistake is to treat scan output as equivalent to exposure. SAST is strongest at finding code constructs that deserve review, such as unsafe deserialisation, injection paths, or weak crypto use. SCA is strongest at mapping shipped components to known CVEs and licence exposure. Neither tool, by itself, proves whether the vulnerable code path is invoked, whether the dependency is actually loaded at runtime, or whether compensating controls block exploitation.
Teams get better results when they combine scan data with runtime validation. That usually means tracing the application path from request to sink, validating which dependencies are packaged in the deployed artefact, and checking whether the vulnerable function is reachable from an external interface or from an internal service account. The NIST Cybersecurity Framework 2.0 supports this broader view by tying identification and protection activities to actual risk reduction rather than scanner coverage alone.
- Use SAST to prioritise code review, not to declare a finding exploitable.
- Use SCA to confirm dependency posture, version drift, and patch obligations.
- Test reachability in staging or production-like environments where possible.
- Correlate findings with secrets exposure, service account privileges, and network paths.
- Treat high-risk findings as candidates for runtime validation and exploit simulation.
NHIMG research shows that 79% of organisations have experienced secrets leaks and 77% of those incidents caused tangible damage, which is a reminder that scanner findings often coexist with identity and credential failures that determine whether a flaw can be reached. The Ultimate Guide to NHIs also notes that 91.6% of secrets remain valid five days after notification, underscoring how long exposure can persist after a finding is known. These controls tend to break down when build artefacts, runtime configuration, and deployed secrets diverge because the scanner is looking at one state while the attacker targets another.
Common Variations and Edge Cases
Tighter scan-driven governance often increases triage overhead, so teams have to balance faster detection against the noise that comes from treating every finding as equally urgent. Current guidance suggests that the right threshold depends on whether the application is internet-facing, heavily privileged, or wired into automated release pipelines.
There is no universal standard for reachability scoring yet. Some organisations use code-coverage data, some use runtime access logs, and some add exploitability checks in CI/CD. The best practice is evolving toward risk-based prioritisation, where SAST and SCA findings are enriched with context such as asset criticality, identity privilege, secret location, and whether the vulnerable function is actually invoked.
Edge cases matter. A dependency may be flagged by SCA but never loaded in production. A SAST issue may look severe but be unreachable behind a feature flag. Conversely, a low-severity code smell can become material when a CI service account has broad permissions or when secrets are stored in source control. That is why the Ultimate Guide to NHIs remains relevant even for application security teams: identity posture often decides whether a code flaw becomes a breach.
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 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Scan findings often miss exposed or long-lived secrets tied to NHIs. |
| NIST CSF 2.0 | DE.CM-8 | Reachability and runtime validation fit continuous monitoring expectations. |
| NIST AI RMF | Risk framing is needed so scan outputs are not mistaken for complete assurance. |
Review NHI secret rotation and revocation whenever SAST or SCA exposes risky code paths.
