Forge experiment · Software supply chain
What's in this site
I turned the lens on this very codebase: a real SBOM of the site you are reading, what its dependency graph actually contains, the lifecycle of work around it, and a field guide to the formats and rules driving software supply-chain work.
Last generated 2026-06-26. SBOM produced with cdxgen against this repository.
A real SBOM, from a real codebase
This site looks simple: a static Astro app on Cloudflare Pages with a handful of direct dependencies. Generate its CycloneDX SBOM and that handful expands to 512 packages once you follow the graph. Producing the document is the easy part and needs no paid tool. The point is what it then tells you, and what you do next.
What it surfaced
Most of the tree is permissive, as expected. But the scan also flagged 26 packages carrying copyleft terms that no one declared or thought about. They trace to exactly two upstream tools:
- LGPL-3.0-or-later
sharp, the image library, is Apache-2.0, but its bundledlibvipsnative binaries (@img/sharp-libvips-*) are LGPL. A permissive wrapper hiding a weak-copyleft engine, pulled in by image optimization. - MPL-2.0
lightningcss, the CSS transformer behind the styling toolchain, is Mozilla Public License 2.0, file-level copyleft.
For a site you deploy rather than redistribute, the practical obligation here is modest. That is the point. Most teams cannot tell you whether it is modest or material, because they cannot see it at all. Surfacing it, tracking it across releases, and proving it to an auditor or an acquirer is the job.
License distribution
| License (SPDX) | Count |
|---|---|
| MIT | 424 |
| Apache-2.0 | 22 |
| ISC | 16 |
| MPL-2.0 copyleft | 12 |
| LGPL-3.0-or-later copyleft | 10 |
| BSD-2-Clause | 9 |
| BSD-3-Clause | 3 |
| CC0-1.0 | 3 |
| Apache-2.0 AND LGPL-3.0-or-later copyleft | 3 |
| MIT OR Apache-2.0 | 3 |
| BlueOak-1.0.0 | 2 |
| CC-BY-4.0 | 1 |
| Python-2.0 | 1 |
| (MIT OR CC0-1.0) | 1 |
| Apache-2.0 AND LGPL-3.0-or-later AND MIT copyleft | 1 |
| 0BSD | 1 |
One component, as the SBOM records it
Lifted verbatim from the generated CycloneDX document.
{
"type": "library",
"bom-ref": "pkg:npm/lightningcss@1.32.0",
"name": "lightningcss",
"version": "1.32.0",
"purl": "pkg:npm/lightningcss@1.32.0",
"licenses": [
{ "license": { "id": "MPL-2.0",
"url": "https://opensource.org/licenses/MPL-2.0" } }
]
}The lifecycle: before and after the SBOM
Generating the SBOM is the cheap, commoditized step in the middle. The value is on either side: getting an accurate inventory out of your build, then actually doing something with it on every release. That second half is where a platform like FOSSA earns its keep.
Before the SBOM · your code and CI
- 1 Pick dependencies You
You add open-source packages. Each one quietly pulls in its own, so a few direct choices become hundreds of transitive ones.
- 2 Build in CI CI
Every build resolves the full dependency graph. This is the moment the real, shipped component list actually exists.
- 3 Generate the SBOM Scanner
A scanner reads the build and writes the inventory, ideally on every build so it never goes stale. Free tools (cdxgen, Syft) do this, and so does FOSSA.
The SBOM
One machine-readable inventory (CycloneDX or SPDX)
Everything below reads from this one document.
After the SBOM · operationalize, where FOSSA lives
- 4 Ingest and normalize FOSSA
Bring SBOMs and scan results from every tool, team, and format into one consistent view, across SCA, containers, and binaries.
- 5 Analyze FOSSA
Match each component against vulnerability databases (NVD, OSV, GitHub Advisory) and detect its license. FOSSA runs this as reachability-based composition analysis.
- 6 Prioritize FOSSA
Rank findings by whether the vulnerable code is actually reachable and exploitable, plus upgrade impact and effort, so engineering fixes what matters instead of every alert.
- 7 Enforce policy FOSSA
Turn rules like "no AGPL in shipped code" or "no critical vulnerabilities" into a check wired into CI, not a spreadsheet nobody reads.
- 8 Remediate You + FOSSA
Upgrade, replace, or formally accept each issue, with guidance on the lowest-impact fix.
- 9 Report and attribute FOSSA
Produce the attribution and notice files plus the audit, due-diligence, and regulator-ready reports a customer or acquirer will accept.
- 10 Monitor continuously FOSSA
New vulnerabilities are disclosed daily, so a clean SBOM can be unsafe tomorrow. The same inventory is re-checked, looping back to analysis.
It is a loop, not a line. Step 10 feeds back into step 5: the same SBOM is re-analyzed as new vulnerabilities are disclosed, which is why a one-time scan is never enough.
Steps 1 and 2 are your developers and CI. Step 3 a free tool can handle. Steps 4 through 10, the part that actually reduces risk and satisfies an auditor, are the work a platform like FOSSA exists to do.
See those steps on this repo: What FOSSA adds →The category, in one screen
The shorthand worth having before a technical conversation about SBOMs. Every date and claim below is sourced; the two soft spots are called out honestly.
SBOM formats
SPDX vs CycloneDX →ISO/IEC 5962:2021 standardizes SPDX 2.2.1. SPDX 3.0 (April 2024) adds security, build, and AI/ML profiles but is not yet the ISO-published version, so an "ISO SBOM" today still means 2.2.1.
Ratified as Ecma International standard ECMA-424 (1st edition, June 2024 = CycloneDX 1.6). Security-first, with first-class VEX, services, and ML-BOM support. The scan above emitted CycloneDX 1.7.
NTIA minimum elements
What is an SBOM? →The 2021 NTIA baseline (three categories: data fields, automation support, practices and processes). CISA published a revised, expanded Minimum Elements draft in 2025, so treat the seven fields as the foundation, not the ceiling.
What is driving demand
Who needs an SBOM? →Directed NTIA to define SBOM minimum elements and NIST to publish secure-development guidance. The origin point for SBOMs as a procurement requirement for software sold to the US government.
Require a producer self-attestation of conformance to the NIST SSDF (SP 800-218), with SBOMs as a supporting artifact. The attestation form and CISA collection program have been in flux through 2024 to 2025, so confirm live status before relying on it.
Reporting obligations apply Sep 11, 2026; the main obligations, including a machine-readable SBOM for products with digital elements, apply Dec 11, 2027. Format-agnostic in the text, SPDX and CycloneDX in practice.
Added by the Consolidated Appropriations Act, 2023. "Cyber devices" must include an SBOM in premarket submissions. FDA began Refuse-to-Accept decisions on these grounds from Oct 1, 2023.
License families, by risk
What is copyleft? →Use, modify, and ship with minimal obligation (keep the notice). Apache-2.0 adds an express patent grant, which is why legal teams often prefer it over MIT or BSD for patent safety.
You can combine with proprietary code, but changes to the covered files (and, for LGPL, the ability to relink) must be shared. This is exactly the band the scan above flagged in this site: sharp’s libvips binaries (LGPL-3.0) and lightningcss (MPL-2.0).
Derivative works must be released under the same license. AGPL-3.0 Section 13 is the enterprise landmine: if you modify it and make that version available to users over a network, you must offer them your source. It closes the GPL "SaaS loophole." Use the -only or -or-later SPDX forms; bare GPL-3.0 is deprecated.
Go deeper in the knowledge base
Plain-English explainers on every concept above: what an SBOM is, copyleft, what "no AGPL" really means, SPDX vs CycloneDX, software composition analysis, and the regulations driving it all.
Open the knowledge base →Built while prepping for a Sales Engineer conversation in the software-supply-chain space (FOSSA). The scan, the numbers, and the component above are real output from this repository, not illustrations.