Software Composition Analysis: Making Dependency Alerts Actionable

A critical vulnerability in a dependency you use for one narrow feature, in a function your code never calls, carries far less real risk than a medium-severity issue in a library that processes every incoming request.

Before triaging by severity score alone, check whether the vulnerable function is actually reachable from your code, either manually for your highest-severity alerts or with an SCA tool that does call-graph analysis rather than just matching package versions against a vulnerability database. This single filter usually cuts the needs-attention-this-week pile by more than half.

Federal agencies work off a hard deadline: patch a critical, internet-facing vulnerability within 15 days of detection, and a high-severity one within 30¹. Your organization isn't bound by that directive, but it's a reasonable floor to adopt internally, because the same public disclosure that starts the federal clock also tells every attacker scanning the internet that the vulnerability exists.

An SCA tool is what tells you a critical vulnerability just landed in a dependency you ship, so your internal clock starts on day one instead of whenever someone happens to notice the alert.

• Auto-close alerts for vulnerabilities in dependencies only used in your test or build tooling, never shipped to production, unless the issue specifically affects the build process itself.
• Auto-escalate anything critical-severity in a directly imported, not transitive, dependency that's reachable from an internet-facing code path.
• Batch everything else into a weekly review where an engineer checks reachability before deciding to patch, suppress with a documented reason, or accept the risk with an expiration date on that acceptance.
• Track time-to-remediation as a team metric, separate from alert volume, since alert volume rewards ignoring the tool and remediation time rewards actually using it.

Treating every alert as equally urgent regardless of severity or reachability, which trains engineers to ignore the tool entirely within a few weeks. Patching by blindly bumping to the latest major version of a dependency to clear an alert, which can introduce breaking changes riskier than the vulnerability it fixed. Never revisiting a suppressed or accepted-risk alert, so a decision that made sense with last year's threat landscape stays permanently unexamined.

Say your SCA tool flags a critical vulnerability in a logging library used across dozens of services. Severity alone says drop everything. Reachability analysis narrows it fast: only services that log a specific kind of untrusted user input through that library's vulnerable code path are actually exposed, and the rest can be patched on a normal release cadence rather than an emergency one.

That split, emergency patch for the reachable services, normal patch cycle for the rest, is what keeps a critical-severity alert from turning into an all-hands fire drill across a codebase where most of the exposure never actually existed.

Sometimes the fix genuinely isn't available yet, or the available fix is a major version bump with breaking changes that need real testing time. For those, a documented, time-boxed risk acceptance beats an alert that just sits open indefinitely: state why it's not patched yet, what compensating control is in place in the meantime, like a WAF rule or added input validation, and a date to revisit. An alert with no expiration date on its acceptance tends to stay accepted forever, long after the original reasoning stopped applying.