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.

Issues surfaced on the Findings page fall into the categories below. Each category groups one or more rule ids; severity is set per rule based on the underlying risk and how recoverable it is.

Malicious Packages critical

• KNOWN_MALICIOUS_PACKAGE — a dependency matches an OSV MAL-* advisory or the OpenSSF Malicious Packages dataset. Remove or replace immediately and rotate any secrets that may have been exposed.

GitHub Actions — workflow-level (fixable in your repo)

• MUTABLE_TAG_REFERENCE — action referenced by a mutable tag instead of a 40-char commit SHA. high for branch/latest-style tags (main, master, latest); medium for version tags (v2, v2.3.4) — both can be re-pointed by the publisher.
• PULL_REQUEST_TARGET_CHECKOUT — workflow uses pull_request_target and checks out PR code, which executes untrusted code with the elevated permissions of the target branch.
• EXCESSIVE_WORKFLOW_PERMISSIONS / EXCESSIVE_JOB_PERMISSIONS — workflow or job grants broad write-all instead of least-privilege scoping.
• POTENTIAL_HARDCODED_SECRET — environment variable value looks like an API key or token. Should be a GitHub Secret reference, not a literal.

Unpinnable Actions — not fixable by SHA-pinning alone

Patterns from Palo Alto's "Unpinnable Actions" research. Even when your workflow pins the action by commit SHA, the action's runtime still pulls mutable resources from elsewhere, so the SHA pin alone does not protect you. Remediation usually means picking a different action or asking the maintainer to pin their own runtime dependencies.

• DOCKER_IMPLICIT_LATEST / DOCKER_FLOATING_TAG — the action's action.yml references a Docker image by a floating tag (no @sha256: digest), so an attacker who pushes a new image to the same tag is automatically picked up by the next run.
• DOCKERFILE_FLOATING_BASE_IMAGE — the action ships a Dockerfile whose FROM is a floating tag (e.g. ubuntu:22.04 with no digest). Findings link directly to the offending FROM line at the commit your workflow pins.
• DOCKER_UNPINNED_DEPENDENCIES / DOCKER_REMOTE_CODE_NO_INTEGRITY — the action's Dockerfile apt/pip/npm installs unpinned versions, or curl | bashes remote code without checksum verification.
• COMPOSITE_NESTED_UNPINNED_ACTION — a composite action's internal uses: references a child action by tag instead of SHA, breaking the pinning chain.
• COMPOSITE_UNPINNED_DEPENDENCIES / COMPOSITE_REMOTE_CODE_NO_INTEGRITY — composite action's run: steps install unpinned packages or fetch remote scripts without integrity checks.
• UNPINNED_PACKAGE_INSTALL / REMOTE_CODE_NO_INTEGRITY — a JavaScript action installs unpinned npm packages or downloads scripts at runtime without checksum verification.
• INDIRECT_UNPINNABLE_ACTION — an action you pinned transitively pulls in one of the patterns above through a nested action.

Dependency Confusion / Hijacking

• NAMESPACE_NOT_IN_REGISTRY high — the package's namespace/scope/group is not registered on the public registry. An attacker could claim the whole namespace and any package under it.
• PACKAGE_NOT_IN_REGISTRY — the package name itself is not present in the public registry; likely a private/internal package that is vulnerable to confusion attacks if an attacker registers the same name publicly.

See the Dependency Confusion methodology section below for how each ecosystem is checked and which registries are queried.

End-of-Life / End-of-Support

• EOL high — confirmed end-of-life via endoflife.date. No security updates of any kind.
• EOS medium — end of regular support (often security-only patches remain).
• HIGHLY_LIKELY_EOL high — staleness heuristic: no new release in 3+ years.
• PROBABLE_EOL medium — staleness heuristic: no new release in 2–3 years.

See the EOX Detection Methodology section below for thresholds, data sources, and the ecosystem-aware product-mapping logic.

Abandoned / Dead Source Repos

• REPO_NOT_FOUND medium — the source repository URL recorded in the SBOM 404s. The repo was deleted, renamed, or never published. If the slot is later re-registered by someone else, the package can be hijacked through release infrastructure tied to that repo.

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

At the top of the Insights page, the same underlying metrics that feed the Tech-Debt composite are re-projected into three risk domains aimed at due-diligence and M&A audiences. Each domain gets an independent 0–100 score (higher is healthier) and a traffic-light verdict, while the overall Tech-Health Score shown in the header is the Tech-Debt composite score and grade (see Tech-debt scoring).

Domain Scores

Verdict Thresholds

The Agent page (linked from Insights) uses Chrome’s built-in Prompt API with Gemini Nano. All prompts, context, and model output stay on your machine — SBOM Play does not upload your analysis to a cloud LLM for this feature.

How it works

The Agent runs an app-driven tool-use loop: JavaScript executes typed query_sbom() handlers (vulnerabilities, licenses, drift, EOL, supply chain, etc.) against in-memory stored analysis, then asks Gemini Nano to summarize those JSON results. Answers deep-link packages, repositories, authors, and advisory IDs into the matching pages.

Availability

Requires a Chromium browser with the Prompt API and Gemini Nano enabled (see Chrome Prompt API documentation). When the model is missing or unsupported, the page shows a non-blocking “AI not available” state; the rest of SBOM Play continues to work offline from IndexedDB.

References

• Chrome — Prompt API
• Chrome — Get started with built-in AI

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. Location geocoding

GitHub profile location strings are free-form text — "San Francisco, CA", "Germany", "Bengaluru", or joke entries like "Milky Way". SBOM Play resolves them to an ISO country code for the Authors map and sanctioned-country checks using a four-step cascade that avoids hammering any single public geocoder:

All successful and failed resolutions are cached in IndexedDB for 7 days so each unique string is fetched at most once per session. Network requests are serialized through a shared queue with per-provider spacing and cooldown on HTTP 429/503. The Authors map itself never triggers geocoding — it reads only from cache and static tables. Nominatim is no longer used.

6. 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
• GeoNames — static major-city table (cities15000, CC BY 4.0)
• Open-Meteo Geocoding API — primary network geocoding fallback
• Photon (komoot) — secondary geocoding failover

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.2.1

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.