Reducing SCA Noise with Reachability
How code-level reachability evidence helps teams prioritize large SCA finding lists by distinguishing reachable from unreachable vulnerable functions, while acknowledging residual risks such as reflection, dynamic loading, and incomplete analysis.
Primary question: How can reachability analysis help teams prioritize large numbers of SCA findings?
Direct answer
Reachability evidence helps prioritize SCA findings by showing which vulnerable functions are actually reached from application code
Traditional SCA produces a large list of vulnerable components, many of which may not be reached from application code. Reachability analysis adds code-level evidence to this list, enabling teams to prioritize findings based on whether the vulnerable function is actually called. [derscanner-sca]
Reachability evidence helps reduce triage noise and focus remediation effort on the findings more relevant for immediate investigation. Reachable vulnerable functions are higher priority than unreachable ones. [derscanner-sca]
Residual risks remain — reflection, dynamic loading, configuration-dependent paths, and runtime behavior may make a static result of "not found reachable" a false negative in specific deployment contexts. Reachability helps prioritize but does not eliminate the need for careful triage. [derscanner-sca]
Definitions
SCA noise
The large number of vulnerability findings produced by SCA analysis, many of which may not be reachable from application code, making triage time-consuming and error-prone.
Reachability-based prioritization
The practice of using code-level reachability evidence to rank SCA findings, so that reachable vulnerable functions receive higher priority than unreachable ones.
Residual risk
The remaining risk that a static result of "not found reachable" may be a false negative because unsupported dynamic behavior, reflection, native boundaries, framework behavior, or configuration can create runtime paths not represented in the static model.
The engineering problem
SCA analysis can produce a large number of vulnerability findings, many of which may not be reachable from application code. Triage teams spend significant time evaluating findings that are not confirmed exploitable. [derscanner-sca]
Without reachability evidence, component-level SCA findings lack application-specific call-path evidence, even when they already differ in severity or other risk metadata, making it difficult to distinguish between a vulnerable component that is imported and called and one that is present but not used. [derscanner-sca]
Teams that rely solely on SCA findings may over-prioritize unreachable vulnerabilities and under-prioritize reachable ones that have lower severity but greater application relevance or immediate investigation priority. [derscanner-sca]
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Reachability-based prioritization
SCA finding prioritization using reachability evidence- Artifact
- SCA findings correlated with SAST findings to determine reachability of vulnerable functions.
- Risk
- Triage teams spending time on unreachable vulnerabilities while reachable ones are under-prioritized.
- Output
- Prioritized SCA findings ranked by reachability evidence, with reachable vulnerable functions flagged as higher priority.
Evidence: DerScanner software composition analysis documentation
Residual risk assessment
Residual risk evaluation during triage- Artifact
- Reachability evidence combined with knowledge of reflection, dynamic loading, configuration-dependent paths, and runtime behavior.
- Risk
- Incorrectly dismissing unreachable vulnerabilities that may still be exploitable through non-standard code paths.
- Output
- Triage decision that accounts for both reachability evidence and residual risk factors.
Evidence: DerScanner software composition analysis documentation
Verification workflow
- Run SCA analysis to identify all vulnerable components and produce the initial finding list.
- Run hybrid SAST+SCA analysis to determine reachability of each vulnerable function from application code.
- For each SCA finding, attach reachability evidence — reachable, unreachable, or partially reachable.
- Prioritize findings — reachable vulnerable functions receive higher priority than unreachable ones.
- During triage, evaluate residual risks for unreachable findings — consider reflection, dynamic loading, configuration-dependent paths, and runtime behavior.
- Use reachability evidence to focus remediation effort on the highest-priority reachable findings first.
- Deprioritize not-found-reachable findings only under documented policy and analysis-coverage assumptions; do not automatically close them.
- Integrate reachability-based prioritization into the CI/CD pipeline so that new findings are automatically ranked at scan time.
DerScanner · Enterprise
Relationship to DerScanner
DerScanner provides hybrid SAST+SCA analysis, enabling reachability-based prioritization of SCA findings.
DerScanner performs hybrid SAST+SCA analysis to correlate SCA findings with SAST findings for reachability-based prioritization of SCA findings. [derscanner-sca]
Limits of verification
- Reachability analysis provides evidence about code paths but does not by itself prove exploitability. A static result of "not found reachable" may be a false negative because unsupported dynamic behavior, reflection, native boundaries, framework behavior, or configuration can create runtime paths not represented in the static model.
- Dynamic imports and framework-level dependency injection may introduce code paths that are difficult to trace statically.
- Reachability analysis does not eliminate the need for careful human triage; it helps prioritize findings for triage.
- Production acceptance remains an organizational engineering decision.
Related knowledge
Dependency Security for AI-Generated Code
Umbrella page covering the broader dependency security analysis model for AI-generated applications
Relationship: related-toSBOM vs SCA vs Hybrid Analysis
Hybrid analysis as the third layer of dependency security
Relationship: related-toHybrid SAST + SCA Analysis
Overview of hybrid SAST+SCA analysis concept and engineering model
Relationship: related-toVulnerable Function Reachability
Deep technical explanation of reachability analysis
Relationship: related-toDependency Security Gates for AI Coding
Where dependency security checks are placed in the AI-assisted development workflow
Relationship: related-toDerScanner
Product line providing reachability-based prioritization capabilities
Relationship: related-toCanonical terms used: SCA noise; Reachability-based prioritization; Residual risk; Triage.
Evidence and references
- DerScanner software composition analysis documentationDerScanner SCA identifies component vulnerabilities, dependencies, software supply chain risks, and license risks. DerScanner provides hybrid SAST+SCA analysis to correlate SCA findings with SAST findings for dependency vulnerability prioritization, including reachability analysis.
derscanner-sca
Reduce SCA triage noise