DEV Community

endoflife-ai
endoflife-ai

Posted on Originally published at endoflife.ai

How to Audit an SBOM for End-of-Life Software — Four Real SBOMs, 21,347 Components, and Why Name Matching Is the Wrong Tool

An SBOM lists what you ship; it does not say whether any of it is still supported. How to join CycloneDX and SPDX components to lifecycle data by package…

What the map covers

Ecosystem (purl type) Package URLs What it typically identifies
pkg:rpm 169 Red Hat, Fedora, SUSE, Amazon Linux packages of runtimes and servers
pkg:github 160 Source repositories (rarely emitted by SBOM tools; present for completeness)
pkg:docker 186 Official and vendor container images — the most valuable rows for base-image audits
pkg:maven 86 Java frameworks, drivers and libraries with published lifecycles
pkg:deb 80 Debian and Ubuntu packages
pkg:apk 55 Alpine packages
pkg:scoop, pkg:chocolatey, pkg:winget 49, 22, 9 Windows package managers
pkg:oci 45 Registry-neutral container images
pkg:npm 42 JavaScript frameworks and build tools (React, Angular, Vue, webpack, ESLint, Strapi…)
pkg:generic 45 Runtimes without a registry home (Node, OpenSSL, PostgreSQL…)
pkg:golang 20 Go modules with published support lines
pkg:nuget 18 .NET packages
pkg:composer 17 PHP frameworks (Laravel, Symfony, Drupal…)
pkg:brew 16 Homebrew formulae
pkg:pypi 7 Python frameworks and libraries with published lifecycles (Django, NumPy…)

What's covered

  • Why the join key has to be the purl
  • What the map covers
  • Four real SBOMs, one afternoon
  • Three ways to run the audit
  • Reading the results
  • Making it a gate

Full guide with every version, risk scores, and live updates: https://endoflife.ai/article-sbom-eol-audit

Top comments (0)