To scope a recall quickly, keep a software bill of materials for every released build and tie it to the products and model years that shipped it. When a flaw is disclosed, you search the inventory instead of asking teams to remember. The 2015 Jeep recall shows how wide the gap between first estimate and final scope can be.
The scoping gap in a real case
After researchers demonstrated a remote attack on a Jeep Cherokee, they estimated that up to 400,000 vehicles were affected. The manufacturer's recall covered about 1.4 million US vehicles, roughly 3.5 times that estimate, across several brands and model years from 2013 to 2015.
The researchers worked from the outside. A manufacturer with a clear inventory works from the inside. The point is not that anyone was careless. It is that a shared platform spreads a flaw across more products than any outside observer can count.
What you need on file
For each released software build:
- A component list with versions, including transitive dependencies.
- The product, variant and model year that received the build.
- The date it shipped and the date it was last updated in the field.
- The supplier of each major component.
- A way to query all of the above across products.
Without item two, you have an inventory of software and no way to turn it into an inventory of vehicles. Without item three, you cannot tell which units have already been fixed.
The scoping steps
When a component is disclosed as vulnerable:
- Search by component and version range. List every build that contains it, directly or as a dependency of something else.
- Check reachability. Is the vulnerable code actually used in that build? Reachability analysis helps separate builds that call the flawed function from builds that only carry it.
- Map builds to products. Turn the build list into a list of models and years.
- Estimate field population. Combine shipped volume with update status.
- Decide the mitigation path. A server-side control may protect everyone quickly, as in the Jeep case, where network-level protections were applied on 23 July 2015 while the software update reached owners over USB or dealers.
- Write down the scope and the reasoning. Regulators and customers will ask how you arrived at it.
Traps
- Transitive dependencies. The flawed library may sit three levels down.
- Forked or vendored copies. A copied library does not show up as a dependency unless your tooling looks for it.
- Supplier black boxes. If a supplier delivers a binary with no component list, ask for an SBOM, and record that you asked.
- Stale inventories. An SBOM generated once at project start describes the product you planned, not the one you shipped.
Making it routine
Generate an SBOM in the build pipeline for every release candidate, store it with the release, and run a search drill each quarter against a made-up disclosure. A drill that takes days teaches you what to fix before a real event.
Safeguard generates SBOMs and scans dependencies for software you build, and its reachability analysis helps rank which affected builds call the vulnerable code.
Click through it at your own pace, or open it full screen.
Quick check
Is an SBOM enough to scope a recall?
No. You also need the mapping from builds to products and model years, and the update status of the field population.
Sources
Last reviewed: 19 October 2026.
