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, the runtime's listening sockets attributed from /proc, and a deterministic PASS/WARN/FAIL verdict from a policy, with a completeness beside it — no LLM in the path.

Axis-by-axis

Both produce an AI-BOM. The difference is which question the artifact answers.

AxisOWASP AIBOM GeneratorSIGIL
Input sourceHugging Face model ID (e.g. google-bert/bert-base-uncased)Local Ollama store path (default ~/.ollama/models)
Information sourceModel card, configurations, repo filesOllama OCI manifest + referenced blobs on disk
Integrity modelWhat the model card declaresStreaming SHA-256 of every blob vs. manifest digest
Output formatCycloneDX 1.6 JSON (SPDX AI Profile compatible)The session (sigil-session/1) and AI-BOM v2 (sigil-aibom/2), JSON with JSON Schemas, plus Markdown
License detectionModel card license fieldSPDX id from the Ollama license layer — 10 families by shortname or body match
Runtime exposureOut of scopeObserve mode: the listener held by ollama serve, found through its fd table, classed by address; with --active api-probe, whether the API answered at one literal address
Native binary capabilityOut of scopePlanned: call-site evidence in the runtime's binaries (M1)
VerdictAIBOM completeness score (0–100) + recommendationsPASS / WARN / FAIL from findings and a TOML policy, with completeness (COMPLETE / INCOMPLETE: was every required check closed) beside it; no LLM
Network egressYes — fetches from huggingface.coNone — every byte read is local, unless the active API probe is asked for
DistributionPython (pip install -r requirements.txt) + hosted web UIA single Rust CLI binary
License (project)NOASSERTION (see repo)MIT
Project homeOWASP GenAI Security ProjectIndependent 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 each layer under the digest the manifest declared, with where its blob was found and what was read.

# 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 inspect ollama --model gemma4:e2b --format aibom --out out/aibom.json
# → out/aibom.json   (AI-BOM v2, hashed evidence, naming its session by SHA-256)

Specification example (golden example 14, tool.version 0.0.0-example), not a real system. An excerpt of SIGIL's AI-BOM v2 Markdown, as it is written:

# SIGIL AI-BOM

| AI\-BOM |  |
|---|---|
| Schema | sigil\-aibom\/2 |
| Mode | observe |

## Outcome

**Verdict:** PASS · **Completeness:** COMPLETE

## Listeners

| Listener | Address | Port | Owner |
|---|---|---|---|
| listener\:tcp\/127\.0\.0\.1\:11434\#7001 | 127\.0\.0\.1 | 11434 | process 4242 \(start 1000\) |

## Models

| Model | Name | Provenance | Layers | License |
|---|---|---|---|---|
| model\:models\/registry\.ollama\.ai\/library\/m\/latest | m\:latest | registry\.ollama\.ai\/library\/m\:latest | 3 \(found 3\, absent 0\, unresolved 0\, not looked up 0\) | MIT |

Standard schema vs. versioned schemas

CycloneDX gives the OWASP tool broad downstream interop. SIGIL writes its own versioned formats, the session (sigil-session/1) and the AI-BOM v2 (sigil-aibom/2), each with a JSON Schema. The Markdown and the AI-BOM are rendered from the one session, so they cannot drift. The tradeoff is narrower interop today; the upside is a format small enough to review end-to-end and stable enough to diff across review cycles.

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

When SIGIL is the wrong choice

Both tools have honest limits. SIGIL is not the right pick if the surface you care about is a HF model card.

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.