Notifications
Clear all
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.
NHIMG editorial — based on content published by Apiiro: SAST and SCA are foundational but incomplete
By the numbers:
- 96% of commercial applications contain open-source components, and the average codebase includes over 500 dependencies.
- Applying reachability analysis can filter out up to 89% of flagged packages, leaving only dependencies that actually execute.
Questions worth separating out
Q: How should security teams decide between SAST and SCA?
A: Use SAST for code your organisation wrote and SCA for software it imported.
Q: Why do static application security tools create so much false confidence?
A: Because they often report code-level risk without knowing whether the code runs, what protects it, or who owns it.
Q: What do teams get wrong about reachability analysis?
A: They treat it as a filtering trick instead of a governance control.
Practitioner guidance
- Correlate scanner output with runtime exposure Map SAST and SCA findings to deployed environments, internet exposure, and compensating controls before assigning severity or SLA targets.
- Add reachability analysis to dependency triage Use execution-path inspection to suppress packages that are present but never called, especially in large dependency trees.
- Route findings to code owners, not last editors Build ownership rules from repository and service metadata so remediation tickets land with the team that can actually change the affected logic.
What's in the full article
Apiiro's full article covers the operational detail this post intentionally leaves for the source:
- Concrete guidance on correlating SAST and SCA with runtime and deployment data
- Examples of how reachability analysis removes low-value dependency findings
- Practical comparison of application context signals that improve remediation prioritisation
- The article's specific explanation of why scan volume can still produce false confidence
👉 Read Apiiro's analysis of why SAST and SCA still miss production risk →
SAST and SCA coverage gaps: what contextual risk analysis fixes?
Explore further
18/08/2026 3:24 pm
Coverage-based AppSec is not risk management. SAST and SCA improve visibility, but visibility is not the same as governance. When teams treat scan output as the risk model, they overvalue theoretical findings and undervalue exposed, reachable, business-critical paths. The result is a backlog that looks comprehensive but does not reflect attack reality. Practitioners should shift from finding volume to risk correlation.
A question worth separating out:
Q: What should teams do when scan findings have no clear business owner?
A: Create ownership mapping before escalation, not after. Findings should route to the team responsible for the service or shared library, not the last developer who edited the file. When ownership is missing, remediation stalls and risk persists. Clear accountability shortens fix times and prevents repeated handoffs across engineering groups.
👉 Read our full editorial: SAST and SCA miss the context that turns findings into risk
