What Happened
A mid-market SaaS company discovered unauthorized data access in their production environment. The entry point wasn't their code. An attacker exploited a known vulnerability in a third-party logging library that had been deprecated by its maintainer six months earlier. The security team had no inventory of which applications used this library. They learned about the exposure from their incident response vendor, not their own tools.
The company maintained SBOMs for each application. They generated them during CI/CD builds and stored them in an S3 bucket. No one looked at them between audits.
Timeline
Month -6: Library maintainer publishes CVE and deprecation notice
Month -3: Automated scanner flags the vulnerability in quarterly report
Month -2: Security team triages finding as "medium priority" for next sprint
Month -1: Attacker begins reconnaissance of public endpoints
Day 1: Initial access through vulnerable logging endpoint
Day 3: Lateral movement to database containing customer PII
Day 7: Anomaly detection triggers alert
Day 8: IR team identifies compromised library; begins containment
Day 12: All instances patched; forensic analysis complete
Total exposure window: 13 days from detection. Six months from public disclosure.
Which Controls Failed
The company's SBOMs existed but served no operational purpose. Here's what broke down:
No continuous monitoring: The team generated SBOMs at build time but never cross-referenced them against vulnerability feeds. When the CVE dropped, they had no automated way to identify affected applications.
Manual vulnerability triage: The quarterly scanner caught the issue, but the finding entered a backlog with 200 other items. Without context about which applications actually used the library, the team couldn't assess the impact.
Vendor lifecycle gaps: The logging library appeared in 14 different applications. No one tracked whether dependencies were actively maintained. The SBOM showed component names and versions. It didn't show maintainer status or end-of-life dates.
Access review blind spots: The compromised service had vendor API credentials with read access to the customer database. These credentials weren't tied to specific components in the access review process. When the team reviewed "third-party integrations," they looked at SaaS vendors, not code libraries.
What Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that you maintain an inventory of bespoke and custom software and third-party software components. Not just "have an inventory" but maintain it. That means treating your SBOM as a living document that feeds security decisions.
NIST 800-53 Rev 5 SA-10 requires you to track security flaws in developer-delivered configurations and tools, then update them when new vulnerabilities emerge. You can't do this if your SBOM lives in a compliance folder.
ISO/IEC 27001:2022 Control 5.19 (supplier relationships) expects you to monitor supplier service delivery. For software dependencies, your SBOM is the supplier list. If you're not checking it against threat intelligence, you're not monitoring.
SOC 2 Type II CC7.1 requires you to identify and assess changes that could significantly impact your system of internal control. A deprecated library with a published exploit is exactly that kind of change. Your SBOM should trigger the assessment, not your incident response team.
Lessons and Action Items
1. Wire SBOMs into vulnerability management
Don't wait for quarterly scans. Set up a daily job that:
- Pulls your latest SBOMs from your artifact repository
- Cross-references components against NVD, GitHub Security Advisories, and your threat intel feeds
- Creates tickets with application context and owner assignment
- Flags components that haven't been updated in 12+ months
2. Add dependency health to your SBOM
Your SBOM should include:
- Last commit date for each component
- Number of active maintainers
- Known security advisories
- License information (some licenses create supply chain risk)
Tools like Syft and SPDX support custom fields. Use them.
3. Map components to access grants
When a library makes external API calls or database connections, document those relationships in your SBOM or link it to your service catalog. During access reviews, ask: "Which components use this credential?" If you can't answer from your SBOM, you can't scope the impact of a compromised dependency.
4. Build SBOM awareness into incident response
Add this to your IR playbook: "Pull the SBOM for the affected application. Identify all third-party components with network access or data handling responsibilities." You'll cut your forensic timeline in half.
5. Set component deprecation alerts
GitHub, GitLab, and most package registries publish deprecation notices. Configure alerts for any component in your SBOM that gets deprecated. Treat it like a CVE: assess impact, plan replacement, track remediation.
6. Use SBOMs for vendor risk scoring
When you evaluate a new vendor or renew a contract, request their SBOM. Look for:
- Unmaintained dependencies
- Components with known CVEs
- Licenses that conflict with your policies
- Excessive transitive dependencies (more surface area)
This gives you concrete data points for vendor risk assessments instead of questionnaire responses.
The team in this incident had everything they needed to prevent the breach. They had SBOMs. They had scanners. They had access controls. What they didn't have was a workflow that connected these pieces. Your SBOM isn't a compliance artifact. It's an operational tool that should inform decisions every day: which vulnerabilities to prioritize, which vendors to trust, which credentials to rotate when something goes wrong.
If you're generating SBOMs but not reading them between audits, you're performing security theater. Start with one use case: vulnerability correlation. Automate it. Then expand.
