With a current inventory, a vendor SDK advisory becomes three lookups: which services use the SDK and at what version, which of them exercise the affected code and expose it, and who owns each one. Without an inventory, the same advisory starts with a search across repositories and a round of questions.
The lookups in order
- Who uses it? Filter the inventory by vendor or package name. You get services, versions and owners. If you also keep dependency scan data per build, you can tell which deployed builds contain the affected version.
- Is the vulnerable code in play? Ask whether the affected feature is called by your code and whether input from outside can reach it. Reachability analysis helps here, because a vulnerable function that your code never calls is a lower priority than one on a public request path.
- What does the SDK touch? Check the row for data classes and credentials. An SDK that holds production credentials or handles personal data raises urgency regardless of the score.
- Who fixes it? The owner column gives the person to contact, and the failure behavior column tells you what a rollout can break.
- How do we know it is done? Re-run the scan, confirm the fixed version in each build and update the row.
Comparing the two situations
| Step | Without inventory | With inventory |
|---|---|---|
| Find affected services | Search many repos, ask in chat | Filter by package or vendor |
| Find owners | Guess from commit history | Read the owner column |
| Judge exposure | Ask each team | Use reachability and data class fields |
| Report progress | Spreadsheet built during the incident | Live view of rows by status |
Two cases the inventory should cover
Transitive copies. An SDK may pull in other libraries. The SBOM layer shows these, the integration layer says why the SDK is there.
Vendor-hosted fixes. Some issues are fixed on the vendor side with nothing for you to upgrade. The row should say how you learn about that: a vendor notice, a status page or an advisory feed.
Prepare before the advisory
Do a drill. Choose a vendor SDK at random, pretend an advisory arrived, and time how long it takes to list affected services, owners and exposure. The gaps you find, such as missing owners or no per-build scan data, are your work list. OWASP's inventory guidance centers on knowing hosts, versions and data flows, and a drill checks that knowledge under time pressure.
Try it yourself
Open the reachability demo and look at how it separates vulnerable code that can be reached from code that cannot. Use that idea when you triage which services to fix first.
Click through it at your own pace, or open it full screen.
Quick check
Do I need an inventory if I scan dependencies?
A scan finds affected builds. The inventory adds owners, data classes and vendor context, which speed the decision and the fix.
What if the SDK is vendored or copied into the repo?
Record that in the row, since scanners that read manifests may miss it. Add a manual check when an advisory lands.
Safeguard offers SBOM and dependency scanning and asset discovery that can feed this kind of inventory. You can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
