From SBOM to ZSBOM: Why Metadata-First Risk Classification Matters

Why Today’s SBOMs Aren’t Enough

Every major breach in the last five years has one thing in common: the attackers didn’t break through the front door, they slipped in through dependencies.

That’s why governments rushed to make Software Bills of Materials (SBOMs) mandatory. From the Cyber Resilience Act (CRA) in Europe to Executive Order 14028 in the United States, SBOMs are now table stakes for selling software.

But here is the problem: most SBOMs are glorified spreadsheets. They generate long lists of dependencies, tick a compliance box, and then gather dust. They don’t tell you whether a dependency is abandoned, hijacked by a malicious maintainer, or actively being exploited in the wild.

And that gap is dangerous. Attackers are betting on one thing: that your SBOM will tell you what you’re using, but not whether you can trust it.

Limitations of Current SBOM Tools

When you peel back the layers, it becomes obvious why current approaches don’t work well for security teams:

1. Static Snapshots SBOMs capture a moment in time. But software ecosystems change daily. Packages are updated, deprecated, or quietly replaced.

2. Blind to Registry-Level Threats Attacks like typosquatting (e.g. reqeusts vs requests) and dependency confusion happen at the package registry level, which most SBOM tools don’t analyse.

3. CVE Noise and Misalignment CVE databases often lag behind real-world exploits. Some critical vulnerabilities aren’t exploitable in context, while others labelled “low” cause major incidents. The XZ Utils backdoor in 2024 is a clear reminder of this.

4. Developer Fatigue Flat SBOM outputs flood developers with thousands of findings, few of which are actionable. This creates fatigue and apathy rather than security.

5. Compliance over Security SBOMs were born from regulation, and too often remain checklist artefacts instead of risk intelligence tools.

If your SBOM can’t tell you which dependency is the ticking time bomb, it isn’t solving the right problem.

Beyond CVEs: Assessing Dependency Risk Through Metadata

The key to fixing SBOMs lies in metadata. Instead of only asking “What version did we install?”, a metadata-first approach asks:

• Who published it? Maintainer trust history, account stability, and organisational ties.

• How active is it? Release cadence, commit velocity, contributor diversity.

• What’s the ecosystem health? Download patterns, dependency graph, forks.

• Are there anomalies? Sudden account handovers, unusual code injections, suspicious naming.

• What’s the CVE lag? How quickly do maintainers patch compared to peers?

This transforms a passive inventory into an active early-warning system.

Where a traditional SBOM says:

“This project uses tar version 1.35.”

A metadata-first model says:

“This project uses tar version 1.35, last updated nine months ago, maintainer inactive, three dependencies flagged as abandoned, and CVE-2023-39804 is still unpatched.”

That’s the level of context teams need to prioritise risk.

How to Prioritise SBOM Vulnerabilities

A common pain point is deciding which vulnerabilities matter. Most teams face alert fatigue because traditional scanners treat all CVEs as equal.

Metadata-driven classification provides a way forward:

• Highlight packages with maintainers who are slow to patch.

• Flag abandoned dependencies even if they don’t yet carry CVEs.

• Detect anomalies that signal compromise, even when no CVE has been assigned.

This shift enables true vulnerability prioritisation, a risk-ranked view of your dependencies rather than a flat list.

Introducing ZSBOM: An Evolution of the SBOM

At Zerberus.ai, we built ZSBOM (Zerberus Software Bill of Materials) to bridge the gap between compliance and actionable security.

What Makes ZSBOM Different

• Metadata-First: Uses registry-level metadata, not intrusive source code access.

• Multi-Dimensional Risk Classification: Analyses typosquatting, dependency confusion, package abandonment, CVE calibration, and maintainer trust.

• Black-Box Analysis: Works without requiring deep integration, making it fast and scalable.

• Actionable Prioritisation: Surfaces the vulnerabilities and anomalies that actually matter.

Real-World Example: XZ Utils

When XZ Utils was compromised in 2024, CVE scoring did not initially reflect the catastrophic risk. ZSBOM would have flagged:

• Maintainer role change anomalies.

• Injection of unusually complex code.

• High reliance across Linux distributions.

That’s the difference between ticking a box and preventing an incident.

Automating Vulnerability Management in the CI/CD Pipeline

ZSBOM is not just about generating a smarter manifest. It’s designed to integrate into modern developer workflows:

• CI/CD Integration: Configure branch-level rules so only critical branches trigger risk scans.

• Pull Request Scanning: Detect anomalies or high-risk packages before code merges.

• Continuous Monitoring: Go beyond static SBOMs — keep risk scores live as ecosystems evolve.

• Remediation Hooks: With Remed-AI, high-risk findings generate automated pull requests with just-in-time provisioning.

This automation means security doesn’t block velocity, it accelerates it.

Why Teams Choose ZSBOM

• For Security Engineers: Better precision/recall, fewer false positives, faster triage.

• For Compliance Officers: Outputs map directly to CRA, NIST, and ENISA supply chain guidance.

• For Developers: Clear prioritisation, fewer distractions, seamless CI/CD integration.

• For Businesses: Strengthens customer trust, reduces breach exposure, accelerates procurement.

A traditional SBOM proves you can generate a list.

 A ZSBOM proves you can manage risk.

From ZSBOM to Trace-AI: Turning Insight into Action

ZSBOM is the foundation of our product ecosystem:

• Trace-AI: Runs continuous risk scoring against your repositories.

• Remed-AI: Automates remediation with just-in-time pull requests.

• Compl-AI™: Produces compliance-ready evidence for ISO 27001, SOC 2, and CRA audits.

This ensures SBOMs don’t just exist as compliance paperwork, they become operational security assets.

The Future of Software Supply Chain Security

The next wave of supply chain security won’t be won by static manifests. It will be driven by living SBOMs: risk-aware, context-rich, and embedded directly into developer workflows.

Our thesis is simple:

Compliance without risk context is dangerous. Risk context without compliance is incomplete. ZSBOM bridges both.

Call to Action: Move Beyond Checkbox SBOMs

If you’re still relying on flat SBOMs and drowning in CVE noise, you’re exposed.

The next supply chain attack won’t wait for your tooling to catch up.

👉 Secure early access to ZSBOM and Trace-AI today at Here 

🚀 Join us as we launch during Product Hunt week this September.

Let’s move the industry beyond checkbox compliance and make supply chain security actionable.

About the Author

By Ramkumar Sundarakalatharan, Co-founder & Chief Architect, Zerberus.ai Ram has over 20 years of experience leading engineering and security functions across startups and MNCs. He has driven ISO 27001, PCI-DSS, and SOC 2 certifications, consulted for VC portfolio companies, and is now building Zerberus.ai to automate compliance and secure the modern software supply chain. Connect on LinkedIn