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

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

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 and presented at:

Current Version: 0.0.6

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.