Compare · Institutional reference
SIGIL vs OWASP AIBOM Generator
The OWASP AIBOM Generator is the institutional reference for what an AI Bill of Materials looks like, listed in the CycloneDX Tool Center. SIGIL covers the same artifact name from a different angle — what is actually installed on the box, hashed.
Pick OWASP AIBOM Generator when
The model lives on Hugging Face and you want a CycloneDX 1.6 AIBOM derived from the model card, configurations, and repository metadata. You want institutional-reference output you can hand to anyone familiar with the CycloneDX ecosystem.
Pick SIGIL when
The model is already deployed locally through Ollama and you
want the AI-BOM derived from the on-disk manifest, with every
blob's SHA-256 verified against the declared digest, runtime
exposure classified from /proc, and a deterministic
PASS/WARN/FAIL verdict aggregated from analyzer findings — no
LLM in the path.
Axis-by-axis
Both produce an AI-BOM. The difference is which question the artifact answers.
| Axis | OWASP AIBOM Generator | SIGIL |
|---|---|---|
| Input source | Hugging Face model ID (e.g. google-bert/bert-base-uncased) |
Local Ollama store path (default ~/.ollama/models) |
| Information source | Model card, configurations, repo files | Ollama OCI manifest + referenced blobs on disk |
| Integrity model | What the model card declares | Streaming SHA-256 of every blob vs. manifest digest |
| Output format | CycloneDX 1.6 JSON (SPDX AI Profile compatible) | SIGIL AI-BOM schema_version: 1.1 (JSON + Markdown) |
| License detection | Model card license field |
SPDX id from the Ollama license layer — 10 families by shortname or body match |
| Runtime exposure | Out of scope | API host + /proc listener classification |
| Native binary capability | Out of scope | x86_64 → SafeISA, external symbol → capability mapping |
| Verdict | AIBOM completeness score (0–100) + recommendations | PASS / WARN / FAIL aggregated deterministically from analyzer-emitted finding severities (no LLM; YAML-policy path is separate, via sigil assess for native binaries) |
| Network egress | Yes — fetches from huggingface.co |
None — every byte read is local |
| Distribution | Python (pip install -r requirements.txt) + hosted web UI |
Single static Rust binary |
| License (project) | NOASSERTION (see repo) | MIT |
| Project home | OWASP GenAI Security Project | Independent open-source |
Claimed vs. hashed
The OWASP tool's strength is reach — give it a HF model ID and it produces a standards-aligned AIBOM the rest of the ecosystem can consume. Its honest limit is that it documents what the model card declares; it does not verify that the bytes on a reviewer's machine match the card.
SIGIL starts the other way around: it reads the Ollama
manifest already on disk, walks every layer, streams SHA-256,
and records the digest under the license,
model, params, and config
kinds — all keyed by the digest the manifest declared.
# OWASP AIBOM Generator (input: HF model ID)
$ python3 -m src.cli google-bert/bert-base-uncased \
--output bert.aibom.json
# → bert.aibom.json (CycloneDX 1.6, claimed metadata)
# SIGIL (input: local Ollama store)
$ sigil aibom generate --runtime ollama \
--model gemma4:e2b --format md --out out/aibom.md
# → out/aibom.md (SIGIL 1.1, hashed evidence)
# Excerpt — SIGIL records digests under each kind:
| Kind | Size | Digest |
|---------|-----------------|-------------------|
| model | 7162394016 B | `sha256:4e30...` |
| license | 11355 B | `sha256:7339...` |Standard schema vs. pinned schema
CycloneDX gives the OWASP tool broad downstream interop. SIGIL
uses its own schema_version: 1.1 pinned by tests,
so JSON and Markdown share the same internal model and cannot
drift across renderings. The tradeoff is narrower interop
today; the upside is a schema small enough to review
end-to-end and stable enough to diff across review cycles.
- OWASP → CycloneDX 1.6 (ecosystem interop)
- SIGIL → SIGIL AI-BOM 1.1 (pinned, JSON + Markdown one model)
- CycloneDX export path is on the SIGIL roadmap
Use both — and diff them
The OWASP AIBOM documents the upstream declared model metadata. The SIGIL AI-BOM documents the local realised deployment. A diff between the two is meaningful evidence in a governance review: "we adopted what HF said we were adopting, and the bytes on disk still match."
- OWASP: what HF said about
gemma-4 - SIGIL: what is in
~/.ollama/modelsright now - Together: an upstream-vs-local audit pair
Anti-persona
Both tools have honest limits. SIGIL is not the right pick if the surface you care about is a HF model card.
When SIGIL is the wrong choice
If your AI footprint is entirely Hugging Face hosted and you do not run Ollama, SIGIL has no Ollama store to inspect today. The OWASP AIBOM Generator is the better fit. If your downstream tooling is locked to CycloneDX, run the OWASP tool first and revisit SIGIL when its CycloneDX export lands.
Sources
Facts above are checked against the linked projects.