Topic starter
18/08/2026 2:40 pm
TL;DR: SAST and SCA still miss the runtime, ownership, and business context needed to distinguish exploitable issues from noise, even though they catch real flaws and dependency vulnerabilities, according to Apiiro. The practical shift is from coverage-based scanning to contextual risk analysis that correlates signals across tools and prioritizes what attackers can actually reach.
Editorial analysis by NHI Mgmt Group, based on content published by Apiiro: “Why SAST and SCA Together Still Leave High-Risk Gaps”.
By the numbers:
- 96% of commercial applications contain open-source components.
- The average codebase includes over 500 dependencies.
- Applying reachability analysis can filter out up to 89% of flagged packages.
Key questions
Q: How should teams prioritise SAST and SCA findings when scanners disagree?
A: Treat disagreement as a signal that context is missing, not as a reason to trust one scanner over the other.
Q: Why do SAST and SCA findings still create false confidence in secure development?
A: Because a clean or noisy scan does not prove that the application is either safe or unsafe.
Q: What are the signs that application security testing is not covering real-world risk?
A: Weak coverage usually shows up as recurring vulnerabilities in production, excessive false positives that teams ignore, and missed issues in APIs, dependencies, or runtime behavior.
Practitioner guidance
- Correlate scanner results across tools Join SAST, SCA, and runtime signals into one triage view so teams can see when separate findings converge on the same deployed service.
- Apply reachability before prioritising dependencies Confirm whether vulnerable libraries are actually invoked in production call paths before creating high-priority remediation work.
- Map findings to service owners Route each issue to the team accountable for the code or dependency, not to whoever last touched the file.
Bottom line: SAST and SCA remain essential, but they do not resolve whether a finding is actually exploitable in the deployed environment.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:24 pm
Context, not coverage, is the missing control plane in application security. SAST and SCA can both be accurate and still leave teams blind to exploitability because they do not model runtime exposure, ownership, or compensating controls. The real governance failure is treating scanner breadth as a substitute for risk judgement. Practitioners should move toward correlation layers that explain which findings matter, not just which findings exist.
A question worth separating out:
Q: How should security teams test whether an exploit is actually usable in production?
A: Security teams should validate exploitability against the live environment, not just against a scan result. The goal is to confirm whether a weakness can be chained with real identities, reachable services, and current privileges before an attacker does. That approach turns security testing into operational risk triage instead of report generation.
👉 Read our full editorial: SAST and SCA miss the context that turns findings into risk