A vulnerable package sitting in a dependency manifest tells a team almost nothing on its own. The application might load it and never call the buggy function inside it, in which case the finding carries little urgency regardless of its published severity. This part separates the findings that need fast attention from the ones where the application never calls the vulnerable function at all, and doing that separation well keeps the rest of the program from collapsing under raw scanner volume.

Start by adding a software composition step to the build pipeline, a feature already built into most modern CI platforms or available as a straightforward extension, producing a software bill of materials (SBOM) and flagging known vulnerabilities against it as part of every build. That step alone identifies what could be a problem. Pair it with runtime visibility that confirms which of those flagged functions the application calls under real traffic, using whichever category of tool fits the stack in question. A flagged function that never executes gets suppressed from the priority queue automatically. One called on every request moves forward to the damage check.

Volume is the real obstacle here, and it shows up at every company size. A codebase of any real age produces far more findings than a team can review by hand, and that volume is the reason both steps belong inside the pipeline, running automatically, rather than sitting as a manual review someone schedules whenever time allows. For a large or unfamiliar codebase, tracing whether a flagged function actually gets invoked can turn into slow, tedious work for a person to carry out alone, so use pattern based tooling that can propose an answer faster than manual tracing manages, with an engineer confirming the most critical answers before these change a ticket's priority, since unusual call structures still slip past automated tools on occasion.

There are two sources of friction that show up often, based on experience, and they need to be planned for. Developers who see the raw volume of findings before the susceptibility check has filtered any of it tend to write the whole program off as noise. The fix is rather simples, and it involves keeping every finding inside security's queue until it clears the susceptibility check, so the first thing a developer sees has already been confirmed as real rather than a raw dump they have to sort through themselves. On the other hand, teams running an older or more fragile pipeline sometimes resist adding new steps out of fear they will break a build that already works. Roll the scan out first as a step that reports without failing anything, earning trust and visibility before it gains the authority to hold up a release.

What checking for susceptibility produces is a filtered set of findings, confirmed as real against the running application rather than theoretical against a list. That filtered set moves into the third check, where the question shifts from whether the vulnerability is real to how much it would cost the business if someone used it.

Go to Part 3: Damage.