Understanding the Limitations of SBOMs
In third-party risk management discussions, a common question arises: "We've got SBOMs from all our critical vendors, so why are we still in the dark when something breaks?" The recent Shai-Hulud attack highlights the need for real-time visibility into production code and affected services. Your SBOM tells you what components should be there, but it doesn't reveal what's actually running, what got compromised, or which services are affected right now.
These questions come from practitioners who've mandated SBOMs in contracts, built intake workflows around them, and checked the boxes. Yet, when an incident hits, you're still scrambling to figure out the scope. Here's what teams are actually asking and what you need to know.
Q1: Why Can't We Use an Old SBOM to Assess New Vulnerabilities?
An SBOM is a snapshot, not a live feed. It shows what was compiled into a release you received months ago. It doesn't reflect recent patches, library swaps after a CVE disclosure, or runtime dependencies that only appear in production.
SBOMs are build-time artifacts, great for understanding declared dependencies and license compliance, but they're not designed to show you what's executing in your vendor's production environment right now. To scope a supply chain compromise, you need to know what's running, not what was built.
Start asking vendors for runtime attestation alongside SBOMs. This means evidence of what's actually deployed: container image digests, service mesh configurations, or runtime dependency graphs. If your vendor can't provide that, you're assessing risk with outdated data.
Q2: Isn't Requiring SBOMs in Contracts Enough for Supply Chain Risk Management?
No, it's just the beginning. SR 23-4 expects you to manage risks throughout the relationship lifecycle, including "Continuous Monitoring of Active Arrangements of the third party's performance and risk profile." An SBOM received at contract signature doesn't satisfy continuous monitoring.
The EBA Guidelines on Sound Management of Third-Party Risk also require institutions to monitor third-party arrangements on an ongoing basis, focusing on operational resilience and ICT risk. A static SBOM doesn't show whether your vendor's dependency posture has degraded since onboarding.
Pair your SBOM requirement with a monitoring obligation. Specify in your contract that the vendor must notify you within a defined timeline (24-48 hours is reasonable for critical vendors) when a component listed in the SBOM is updated, deprecated, or found vulnerable. Better yet, require access to a vendor-maintained SBOM feed or API that reflects the current state.
Q3: What Does "Real-Time Visibility" Mean in Practice?
Real-time visibility doesn't mean live access to your vendor's systems. It means having instrumentation that provides near-current awareness of what's running and what's changed.
Practical options include:
- Signed SBOM updates pushed on every deployment: Your vendor's CI/CD pipeline generates and signs a new SBOM each time they deploy, and pushes it to a location you can access.
- Runtime attestation via service catalogs: If your vendor uses a service mesh or API gateway, they can expose a catalog of running services and their dependency trees, updated continuously.
- Cyber risk ratings with component-level drill-down: Some platforms now surface specific vulnerable components detected in your vendor's external footprint. This isn't perfect, but it's more current than a six-month-old SBOM.
- Vendor-hosted dashboards with change logs: The vendor maintains a portal showing current component versions and flags changes that affect your integration points.
None of this requires you to audit their code. It requires them to instrument their deployments and share the output with you under a clear data-sharing agreement.
Q4: How Do We Prioritize Which Vendors Need This Level of Monitoring?
Use your existing criticality classification. If you've tiered your vendors by impact to Critical or Important Functions, operational resilience, or data sensitivity, those tiers tell you where to start.
Focus real-time monitoring on:
- Tier 1 / Critical vendors: Those supporting functions where a 4-hour outage would trigger regulatory reporting or material financial impact.
- Vendors processing sensitive data: Especially those handling data subject to breach notification timelines (GDPR, state breach laws).
- Vendors in your software supply chain: Any vendor whose code runs in your production environment or is embedded in products you ship to customers.
For lower-tier vendors, an annual SBOM refresh plus standard continuous monitoring (financial viability, cyber risk ratings, news monitoring) is proportionate.
Q5: How Do We Use Real-Time SBOM Data Effectively?
You're not analyzing every update manually. You're integrating it into your vulnerability management workflow and incident response playbook.
Set up automated correlation:
- Ingest vendor SBOM feeds into your vulnerability scanner or TPRM platform. Many tools now accept SBOM formats (SPDX, CycloneDX) and can match components against known CVEs.
- Define thresholds for alerting. Not every component change matters. Alert on critical or high-severity CVEs in components used in production, removal of security-critical libraries, or introduction of components from untrusted sources.
- Incorporate into incident response. When a supply chain compromise is disclosed publicly, query your SBOM repository: which vendors use the affected component? Which of our services depend on those vendors? This turns a 48-hour scoping exercise into a 2-hour query.
The value isn't in reading every SBOM. It's having queryable, current data when you need to answer "are we exposed?" in the first hour of an incident.
Q6: How Do We Respond If a Vendor Can't Provide Runtime Visibility?
This is a negotiation point. Ask what specific security concern they're raising. If it's about exposing internal architecture, you can scope the disclosure to components that touch your data or integration points, not their entire stack.
If it's about operational overhead, propose a phased approach: start with SBOM updates on major releases, then move to automated feeds once they've built the tooling.
If they're genuinely unable to provide runtime visibility, adjust your risk posture. That vendor may not be suitable for a Tier 1 classification. Document the gap, escalate the residual risk to your risk committee, and consider whether you need contractual commitments around incident notification timelines and breach transparency to compensate. You can't manage what you can't see. If they won't give you visibility, you need stronger contractual controls or a different vendor.
Next Steps
If you're building out supply chain monitoring capabilities, start with ISO 27036 for the baseline framework on information security in supplier relationships. For regulatory context, review SR 23-4 and the EBA Guidelines on Sound Management of Third-Party Risk.
On the tooling side, explore SBOM management platforms that support continuous ingestion and vulnerability correlation. When revising vendor contracts, add SBOM update frequency and runtime attestation as negotiable terms. Vendors who meet these terms are investing in their own supply chain hygiene, which is exactly the signal you're looking for.
