Live AIBOM generator

Type any Hugging Face model ID, supply the few facts the Hub cannot know, and generate a resolved CycloneDX 1.6 AIBOM against the live registry — then check it against the advisories that actually affect the loading stack.

Step 1

What you need to provide

Only the model ID is required. Everything else either comes from the Hub, or is something the Hub structurally cannot know — jurisdiction and legal entity have no field in CycloneDX or SPDX, and no registry publishes them.

The org/name path from the model's Hub URL.

Leave blank to resolve the current head and pin whatever SHA it returns.

The Hub gives an org handle, not a legal person. Nobody to serve an advisory on otherwise.

Decides whether hosted use is an export. No native field exists — it goes in as a property.

The BOM subject.

Used to check the advisories below. Nothing is sent anywhere.

Reference

Which bill of materials covers what

Every advisory in this tool sits in the SBOM and AIBOM overlap. That is the whole argument for merging them rather than filing an AIBOM and calling the job done.

SBOM AIBOM packages, versions weights, lineage +-------------------+---------+-------------------+ | | loader | | | syft, trivy | stack | transformers | | lockfiles | <- CVEs | reads this | +---------+---------+---------+---------+---------+ | | crypto | all | signing | | | | libs | three | sigstore| | +---------+---------+---------+---------+---------+ | CBOM | | algorithms, keys | +-----------------------------+ SBOM only packages, versions, transitive dependencies AIBOM only weights, base-model lineage, training datasets CBOM only algorithms, key lengths, certificates SBOM n AIBOM the loader stack. EVERY published CVE lives here. SBOM n CBOM crypto libraries (openssl, cryptography) AIBOM n CBOM model signing and attestation all three a signed, pinned, verified artifact Not shown, because they do not overlap: HBOM accelerator, firmware, country of origin SaaSBOM endpoints, trust boundaries, tools and MCP servers