Forge experiment · Software supply chain
What FOSSA adds
I generated an SBOM of this site with a free tool, then connected the same repository to FOSSA via GitHub and let the platform scan it. This is what the platform did that the generator could not, shown with the real results.
Live FOSSA scan of this repository on 2026-06-27, connected through the GitHub integration. The panels below reproduce the real dashboard output.
The setup
On the SBOM page I scanned this codebase with cdxgen, a free generator, and got a 512-package CycloneDX inventory. Here I did the enterprise version: connected the same GitHub repository to FOSSA via OAuth (no CLI, no key in my code), and let the platform import and scan the default branch. Generating an inventory is the commodity step. What a platform does with it is the product.
What FOSSA found
The first validation is quiet but important: FOSSA independently resolved the same 512 dependencies and 16 license types the free generator found. Then it added the layer the generator cannot.
Issues in main
24 issues
- 14 Flagged license issues Review & Fix
- 5 Outdated dependencies Review & Fix
- 5 Vulnerabilities Review & Fix
Reproduced from the live FOSSA project summary, 2026-06-27.
cdxgen vs FOSSA, same input
Both tools read the identical repository, and they agree on the inventory exactly. cdxgen does the generation job well, which is the point: that step is solved and free. The difference is everything that happens after, where FOSSA turns the inventory into policy, prioritized risk, and audit-ready evidence.
| cdxgen (free) | FOSSA (platform) | |
|---|---|---|
| Dependencies resolved | 512 | 512 (identical) |
| Distinct license types | 16 | 16 (identical) |
| Copyleft surfaced (sharp / libvips LGPL-3.0) | listed as raw data | 14 flagged license issues, license scan fails |
| Known vulnerabilities | none | 5 (all in astro), security scan fails |
| Remediation | none | Upgrade astro to 6.4.6, fixes all 5 |
| Outdated dependencies | none | 5 flagged by policy |
| Reports | one SBOM document | attribution + SBOM export + remediation |
| Policy gate in the repo | none | pass / fail wired into GitHub |
The copyleft, turned into a policy gate
cdxgen reported that 26 packages carried copyleft terms, tracing to sharp’s libvips binaries (LGPL-3.0) and lightningcss (MPL-2.0). FOSSA took the same finding and raised 14 flagged license issues against the @img/sharp-libvips-* packages, which is what makes the license scan fail. The raw fact became an enforced decision.
- @img/sharp-libvips-darwin-arm64 1.2.4 LGPL-3.0 · transitive
- @img/sharp-libvips-darwin-x64 1.2.4 LGPL-3.0 · transitive
- @img/sharp-libvips-linux-arm 1.2.4 LGPL-3.0 · transitive
- @img/sharp-libvips-linux-arm64 1.2.4 LGPL-3.0 · transitive
- @img/sharp-libvips-linuxmusl-arm64 1.2.4 LGPL-3.0 · transitive
- + 9 more sharp / libvips variants
Read the background: what copyleft is and permissive vs copyleft.
Vulnerabilities and a one-click fix
This is the half a generator is not built to give you. All 5 vulnerabilities sit in one direct dependency, the astro framework (5.18.2), and FOSSA resolves every one with a single action: upgrade to 6.4.6. Each finding carries a severity and an exploit-prediction percentile so you fix what matters.
- Medium 6.1 CVE-2026-41067 Cross-site scripting (improper input neutralization)
- Unknown CVE-2026-54299 General vulnerability
- Unknown CVE-2026-50146 General vulnerability
- + 2 more advisories on the same package
FOSSA also offers automated upgrade pull requests (fossabot) with breaking-change and app-impact analysis, the remediation stage of the lifecycle.
Audit-ready reports
The last stage is evidence. FOSSA generates the documents a customer security review, an acquirer’s due-diligence team, or a regulator will accept, from the same scan:
Both files are the actual documents this scan produced. The licensing report is hosted unmodified; the SPDX SBOM has only its project-owner field relabeled to the site name, with every dependency, version, checksum, and license left exactly as FOSSA exported it. The free-tier export lists the direct dependencies with full metadata; FOSSA resolved the full 512-component graph internally.
Where it fits in the lifecycle
On the SBOM page I mapped the supply-chain lifecycle: a commoditized, automatable middle (generate the SBOM) and a hard, ongoing back half (ingest, analyze, prioritize, gate, remediate, report, monitor). This scan is that back half, made concrete. FOSSA ingested the repo, analyzed it for license and vulnerability risk, prioritized the fix, failed the policy gate, and produced the reports. The free generator and the platform agree on the inventory; everything after it is the product.
The honest summary
A free tool told me this site has 512 dependencies and some copyleft buried in them. FOSSA told me which copyleft fails a license policy, which dependency carries five real CVEs, exactly how to fix them, and handed me the audit report, all from connecting one repository. That difference is the category.
Want to set this up yourself?
The step-by-step version: connect, set policy, and wire the two-layer CI gate, with a copy-paste checklist.
Real output from a live FOSSA scan of this repository on 2026-06-27, run while prepping for a Sales Engineer conversation in the software-supply-chain space. The dashboard panels above are reproduced from that scan.