About SBOM Play

SBOM Play is a client-side web application for analyzing Software Bill of Materials (SBOM) data from GitHub repositories, organizations, and users. Built for security professionals to identify dependency vulnerabilities, assess license compliance, and understand software supply chain risks in real-time.

The tool features comprehensive SBOM analysis including dependency tracking, vulnerability detection via OSV.dev integration, license compliance checking, author analysis with funding detection, and SBOM quality assessment.

Key Principle: All analysis happens directly in your browser - no data ever leaves your machine.

SBOM Play is designed with privacy and security as top priorities:

• Client-Side Processing: All SBOM analysis, dependency resolution, and vulnerability checking happens entirely in your browser
• No Data Transmission: Your SBOM data never leaves your machine - it's processed locally
• Local Storage: Analysis results are stored in your browser's IndexedDB, giving you full control
• API Calls: Only public registry APIs are queried (npm, PyPI, crates.io, etc.) - no sensitive data is transmitted
• GitHub Token: Optional GitHub Personal Access Token is used only for API rate limits and is never stored

For security-conscious environments, airgapped networks, or self-hosted deployments, the following domains must be allowed through your firewall or proxy. Domains are grouped by functionality and criticality.

CDN / Static Assets (Required for UI)

GitHub APIs (Core Functionality)

Vulnerability Database

Package Registries (Dependency Resolution)

Map Services (Optional - Authors Page)

Analytics (Optional - Can Be Blocked)

1. Input: Enter a GitHub organization name, username, repository, or GitHub URL
2. SBOM Fetching: The tool queries GitHub's Dependency Graph API to retrieve SBOM data for public repositories
3. Dependency Resolution: Full dependency trees are resolved by querying package registries (npm, PyPI, crates.io, etc.)
4. Analysis: Dependencies are analyzed for vulnerabilities (OSV.dev), licenses, authors, and quality metrics
5. Storage: Results are stored locally in your browser's IndexedDB for future reference
6. Visualization: View results across multiple pages: Overview, Licenses, Vulnerabilities, Quality, Dependencies, and Authors

Every dependency in a portfolio is classified per consuming repository as either direct (the repo's own code declares it) or transitive (the repo only inherits it through the dependency tree of something else it declared). The same package can be direct in one repo and transitive in another. SBOM Play computes this attribution centrally with a deterministic two-pass algorithm so every page that splits Direct vs Transitive — Licenses, Vulnerabilities, Dependencies, Findings — reads from the same source of truth.

Pass 1 — SBOM Truth

For every repository in the portfolio, walk that repo's SBOM-declared dependencies and consult its directDependencies set (built from the SBOM's DEPENDS_ON relationships from the root package). Each (dep, repo) pair is added as direct in that repo if the SBOM declared it as a top-level edge from the repository, and as transitive in that repo otherwise.

Pass 2 — Per-Repo BFS Through the Tree

Some transitives never appear in the SBOM at all — they're discovered later when SBOM Play walks each direct dep's full version graph through the registry resolver (deps.dev, packages.ecosyste.ms). For every repo we BFS from its direct seed set through each dep's child registry edges and mark every reached (dep, repo) pair transitive in that repo. Pass 1 always wins on direct classification — Pass 2 never overwrites a direct mark with a transitive one.

Why we don't trust GitHub-flat SBOMs alone

GitHub's dependency-graph SBOMs flatten the tree — every DEPENDS_ON relationship goes from the repo's main package, so the SBOM marks every listed dep as a direct dep of the repo, including transitives. If we only trusted the SBOM (Pass 1), the Direct/Transitive split for GitHub-fetched portfolios would be meaningless. Pass 2's BFS through resolver-discovered edges is what recovers the real shape — anything reached only via dep.children is transitive, regardless of what the flat SBOM said.

Imputed Direct (cross-portfolio inference)

For organisation-wide aggregations, a dep that's transitive in every repo it touches can still be considered "imputed-directly used" by the org if the package is also directly declared in any other repo in the portfolio (or a sister portfolio sharing the same lockfile family). This is a forward-looking concept that the forthcoming Insights page surfaces — it gives M&A and CTO audiences a more honest picture of "what the org actually owns" beyond SBOM-listed direct edges.

References

• SPDX 2.3 — Relationships between SPDX elements (DEPENDS_ON semantics)
• CycloneDX 1.5 — Dependency graph
• GitHub Dependency Graph SBOM API
• deps.dev v3alpha — package versions and dependency edges

The Insights page computes a single Tech-Debt composite score (0-100, higher is healthier) from six weighted sub-components. Direct dependencies carry 3× weight compared to transitive ones, reflecting the higher risk and remediation urgency of code you directly control.

Component Weights

Grading Scale

Visualization

Charts on the Insights page are rendered with Chart.js 4.4, loaded from the jsdelivr CDN. Theme-aware colors are driven by --chart-text-color and --chart-grid-color CSS custom properties.

References

• Chart.js 4.4 Documentation
• OSV API — vulnerability severity data
• endoflife.date API — EOL/EOS data

SBOM Play uses multiple data sources and heuristics to identify end-of-life (EOL) and end-of-support (EOS) dependencies. Understanding which software components are no longer maintained is critical for supply chain security.

1. Confirmed EOL/EOS (Primary Source)

We query the endoflife.date API for official end-of-life information. This database tracks EOL dates for major software products including:

• Programming languages: Python, Node.js, Ruby, PHP, Go, Java, .NET, Rust
• Frameworks: Django, Rails, Laravel, Angular, React, Vue, Spring
• Databases: PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch
• Infrastructure: Kubernetes, Docker, Terraform, Nginx, Apache

2. Probable EOL (Staleness Heuristic)

When official EOL data is unavailable, we use staleness analysis to infer probable abandonment. Research shows that packages without updates for extended periods are likely unmaintained.

Note: This heuristic has limitations. Some stable packages (e.g., small utilities) may be "complete" and not require updates. We recommend manual review for probable EOL findings.

3. Archived Repositories

When a GitHub repository is archived, it's a clear signal from the maintainer that the project is no longer active. We detect dependencies whose source repositories have been archived and flag them accordingly.

References

• endoflife.date API Documentation
• OpenEOX Standard - Emerging standard for EOL data exchange
• GitHub: Archiving Repositories

Dependency confusion (also known as "namespace confusion" or "substitution attacks") is a supply chain attack where an attacker publishes a malicious package to a public registry with the same name as an internal/private package. When developers or CI/CD systems resolve dependencies, they may inadvertently download the malicious public package instead of the intended private one.

How SBOM Play Detects Dependency Confusion

SBOM Play uses a multi-layered approach to detect potential dependency confusion vulnerabilities in your SBOMs:

Supported Registries (36+)

SBOM Play checks packages against 36+ public registries via the ecosyste.ms API, plus GitHub for Actions:

Detection Process

1. PURL Parsing: Extract ecosystem and package name from Package URLs (PURLs) in the SBOM
2. Namespace Extraction: Parse scoped packages (e.g., @scope/package) to identify namespaces
3. Registry Query: Check if namespace/package exists via ecosyste.ms or direct registry APIs
4. GitHub Verification: For GitHub Actions, verify organization and repository exist via GitHub API
5. Evidence Collection: Store API response URLs as proof for findings

Mitigation Strategies

• Namespace Squatting: Register your organization's namespace on public registries (even if unused)
• Scoped Packages: Use organization scopes (e.g., @mycompany/) for all internal packages
• Private Registry Priority: Configure package managers to check private registries first
• Package Lock Files: Use lock files with integrity hashes to prevent substitution
• Registry Allowlisting: Configure CI/CD to only allow packages from approved registries

References

• Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies - Alex Birsan's original disclosure
• DepConfuse - Original dependency confusion detection tool that inspired our implementation
• ecosyste.ms API Documentation - Registry aggregation API

For every package in the SBOM, SBOM Play attempts to attribute a list of authors — the humans (and bots) whose accounts can ship code into the package. This list is what powers the Authors page, the geographic risk map, the sanctioned-country detector, and the contributor correlation in the Findings report. Because no single registry exposes all the information we need, the pipeline draws from up to three sources per package, in a fixed precedence order, and every API call is made once per package and reused.

1. Source Precedence

Sources 1 and 2 are mutually exclusive (we use whichever is available for the ecosystem). Source 3 runs in addition to whichever of 1 or 2 returned data — registries publish only the maintainer-of-record, but real-world risk lives in the broader contributor population that can land code through pull requests.

2. Why GitHub contributors?

For a Maven artifact like org.springframework.boot:spring-boot-starter-web, the registry publishes a single "Pivotal" maintainer entry. The actual humans who can merge code into that package are the contributors of spring-projects/spring-boot on GitHub — currently around 1,000 people, of whom we capture the top 10 by contribution count. These are tentative correlations (we have no email/identity authority for them), so they're flagged with a ⚠️ badge in the Authors page so you can distinguish them from registry-attested maintainers.

3. Cost model

Per-run we issue exactly one /repos/{owner}/{repo}/contributors REST call per unique GitHub repository, deduped by an in-memory cache keyed on ${owner}/${repo}. Profile fields (location, company, GitHub user type) are filled in afterwards by a single batched GraphQL query — never per-user REST calls. So a 159-package Spring Boot SBOM where every package points at spring-projects/spring-boot issues 1 contributors call and a handful of GraphQL profile calls, not 159 + 1,590.

4. Shared-repository attribution

From a threat-model perspective, those packages share a single supply-chain blast radius. A contributor with merge rights to the shared repository can land malicious code into every package that ships from it, in a single commit. Listing the contributors once per package (rather than once per repository) makes that fan-out explicit on the Authors page: an author shown as having "23 packages" across "1 repo" is actually a single point of failure for 23 packages, and that's exactly what the Repository Usage column on the Authors page surfaces with the High Risk / Moderate Risk badges.

The downside is visual repetition — a Spring-heavy SBOM will show the same ~10 Pivotal employees on every Spring artifact. The upside is risk fidelity: the count of packages those employees appear on directly reflects the number of packages an account compromise would compromise.

5. Bots and automated accounts

GitHub contributors include automated accounts: dependabot[bot], github-actions[bot], renovate[bot], pre-commit-ci[bot], and similar. We do not filter them out at the enrichment stage — instead the Authors page detects bot accounts (by the canonical [bot] suffix, GitHub's type: 'Bot' profile field, and a denylist of common automation accounts) and routes them to a dedicated Active Bots in the Environments section. The human authors table stays clean, while the bot inventory remains visible — bots that can ship code through PRs are part of the threat model and worth knowing about.

References

• GitHub REST API: List repository contributors
• ecosyste.ms API Documentation — aggregated package metadata for ecosystems without a native authors endpoint
• npm package.json: author and contributors fields
• PyPI core metadata: Author / Maintainer fields

SBOM Play assesses SBOMs against multiple international compliance standards. Understanding these standards helps organizations ensure their SBOMs meet regulatory requirements.

CISA 2025 Minimum Elements (US Federal)

The Cybersecurity and Infrastructure Security Agency (CISA) updated SBOM requirements in August 2025, building upon the 2021 NTIA guidelines. Key additions marked with NEW.

BSI TR-03183-2 v2.0 (German/EU)

The German Federal Office for Information Security (BSI) Technical Guideline provides requirements for SBOMs in the European context, with stricter requirements around cryptographic hashes.

References

• CISA 2025 SBOM Minimum Elements
• CISA 2025 SBOM PDF Document
• BSI TR-03183-2 v2.0 (PDF)
• NTIA 2021 Minimum Elements (Historical)
• sbomqs - SBOM Quality Scoring Tool

Our quality scoring is aligned with sbomqs v2.0, an industry-leading SBOM quality assessment tool. The overall score is calculated from 7 weighted categories:

SBOM Play has been featured, launched, and presented at the following venues:

Current Version: 0.0.8

View Changelog

Technologies Used

• Bootstrap 5: UI framework
• Font Awesome: Icons
• IndexedDB: Local storage
• GitHub API: SBOM data source
• OSV.dev API: Vulnerability data
• Package Registries: npm, PyPI, crates.io, RubyGems, Maven, etc.

Inspirations

The following open-source projects provided insights and inspiration for key features:

• sbomqs - Quality scoring logic and SBOM assessment methodology
• DepConfuse - Dependency confusion detection logic

Acknowledgments

This project was developed with the assistance of AI tools, most notably Cursor IDE and Claude Code. These tools helped accelerate development and improve velocity. All AI-generated code has been carefully reviewed and validated through human inspection to ensure it aligns with the project's intended functionality and quality standards.