SIGIL

Compare · SBOM family

SIGIL vs Anchore Syft

Syft 1.38 added a GGUF cataloger that emits CycloneDX ML-BOM components — the closest mainstream tool to SIGIL on the AI-BOM axis. This is what each tool covers, where they overlap, and where they don't.

COMPARE SIGIL / SYFT
GAP RUNTIME VERDICT

Pick Syft when

You need general-purpose SBOM coverage across packages, OS layers, language ecosystems, container images, and now GGUF model files. CycloneDX 1.6 is a hard requirement. Your AI artifacts live as standalone .gguf files on disk or inside vnd.docker.ai.gguf.v3 OCI layers.

Pick SIGIL when

Your local AI runs through Ollama (~/.ollama/models/), you need every blob's SHA-256 verified against the manifest digest, you want runtime exposure classified from /proc, you need SPDX from the Ollama license layer, and you want a deterministic PASS/WARN/FAIL verdict aggregated from the analyzer's per-finding severities — no LLM in the path.

Axis-by-axis

Each row is a piece of evidence that ends up — or doesn't — in the resulting BOM artifact.

Axis Syft 1.45 (gguf-cataloger) SIGIL
Output format CycloneDX 1.6 / 1.7, SPDX SIGIL AI-BOM schema_version: 1.1 (JSON + Markdown)
Local source Filesystem walk for .gguf files ~/.ollama/models/ manifest walk
OCI source application/vnd.docker.ai.gguf.v3 Ollama manifest layers (model / config / params / license)
Integrity check GGUF header magic + format version Streaming SHA-256 of every blob vs. manifest digest
License detection License field from GGUF metadata when present SPDX id from Ollama license layer — 10 families by shortname or body match
Provenance GGUF metadata fields (name, source URL) registry / namespace / model / tag tuple parsed from manifest path
Runtime exposure Out of scope /proc walk → localhost / lan / public_bind / docker_published / proxy
Native binary capability Out of scope x86_64 → IR → SafeISA; network / file_read / process_spawn / …
Verdict None (inventory-first) PASS / WARN / FAIL aggregated deterministically from analyzer-emitted finding severities (no LLM; the YAML-policy path applies to sigil assess for native binaries)
Subprocess spawn Yes for some catalogers None — /proc parsed directly
Network egress Yes when pulling OCI / matching vulns None
Language / distribution Go, single static binary Rust, single static binary

The gap that matters: Ollama OCI manifests

Syft's OCI AI source resolves layers tagged application/vnd.docker.ai.gguf.v3 — Docker's AI image format. Ollama ships a different OCI layer schema (application/vnd.ollama.image.model, application/vnd.ollama.image.license, and friends) and a different on-disk layout (~/.ollama/models/manifests/<registry>/<namespace>/<model>/<tag>). Syft as of 1.45 does not parse it.

SIGIL parses the Ollama manifest, walks each referenced blob, streams SHA-256, and reports any digest mismatch as a FAIL finding tied to the model and tag. 

# SIGIL AI-BOM: [PASS]

- Schema: `1.1`

## Runtime
| Property         | Value                       |
|------------------|-----------------------------|
| Host             | `http://127.0.0.1:11434`    |
| Runtime exposure | `localhost` (source: `proc`)|

## Models

### `gemma4:e2b`
- **License:** `Apache-2.0` (digest `sha256:7339...`, 11355 B)
- **Provenance:** `registry.ollama.ai / library / gemma4 / e2b`

| Kind    | Size            | Digest             |
|---------|-----------------|--------------------|
| model   | 7162394016 B    | `sha256:4e30...`   |
| license | 11355 B         | `sha256:7339...`   |

Standard schema vs. pinned schema

CycloneDX gives Syft broad ecosystem interop — vulnerability scanners, viewers, registries, and policy engines speak it. That is real value.

SIGIL's AI-BOM uses a custom schema_version: "1.1" pinned by tests in the workspace. JSON and Markdown share the same internal model so they cannot drift. 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. A CycloneDX export path is on the roadmap.

  • Syft → CycloneDX 1.6 / 1.7 / SPDX
  • SIGIL → SIGIL AI-BOM 1.1 (JSON + Markdown)
  • Both → single static binary

Verdict path vs. inventory

Syft answers "what is here". SIGIL also answers "and is it acceptable, right now". For the AI-BOM, the verdict is aggregated deterministically from the analyzer's per-finding severities — never from an LLM, never from a remote service. A separate YAML-policy path applies to native binary capability evaluation via sigil assess.

  • Syft: components list, no verdict
  • SIGIL AI-BOM: components + findings + aggregated verdict
  • SIGIL assess (binary capability): analyzer + YAML policy → violations + call sites
  • Both deterministic and scriptable in CI

Use both

They are complementary, not exclusive.

When SIGIL is the wrong choice

If you are not running a local LLM runtime, or your AI runs entirely against hosted APIs (OpenAI / Bedrock / Vertex), SIGIL has nothing to inspect today. If you need CycloneDX output for a downstream tool, run Syft and revisit SIGIL when the CycloneDX export path lands. If your model store is plain .gguf files outside of any Ollama install, Syft is the right tool right now.

Sources

Facts above are checked against the linked code and releases.

Syft PR #4279 "feat: 4184 gguf parser (ai artifact cataloger) part 1" — merged 2025-11-13, shipped in v1.38.0. Syft gguf-cataloger Source: syft/pkg/cataloger/ai/cataloger.go — name gguf-cataloger. Syft OCI model source application/vnd.docker.ai.gguf.v3 layer media type, header-only fetch. SIGIL Ollama inspection Manifest walk, SHA-256, SPDX detection, /proc exposure classes, findings.