Directory context | AI Supply-Chain Security

AIsbom

Disassembles Pickle bytecode and parses SafeTensors/GGUF binary headers to detect malware and license risks in ML model files before load. Generates CycloneDX/SPDX SBOMs.

Direct answer

What is AIsbom?

AIsbom is included in the Awesome MLSecOps AI Supply-Chain Security directory. The community-maintained README describes it as: “Disassembles Pickle bytecode and parses SafeTensors/GGUF binary headers to detect malware and license risks in ML model files before load. Generates CycloneDX/SPDX SBOMs.” Its MLSecOps relevance is the protection of model provenance, artifact integrity, dependencies, signing, bills of materials, registries, or delivery pipelines. The linked first-party source is the Lab700xOrg/aisbom repository on GitHub. A technical review should test the project's documented evidence across four criteria: Provenance and signing support, ML-BOM formats, Registry and CI integration, and Policy enforcement. Compare that evidence with the intended architecture and threat model. Catalog inclusion establishes relevance to this security category; it is not a certification, comparative ranking, or endorsement. Confirm current capabilities, maintenance, licensing, limitations, and deployment assumptions in the first-party documentation before adoption.

Disassembles Pickle bytecode and parses SafeTensors/GGUF binary headers to detect malware and license risks in ML model files before load. Generates CycloneDX/SPDX SBOMs.

Neutral catalog description synchronized from the Awesome MLSecOps README

Before adoption

What should teams verify about AIsbom?

Answer these questions from current first-party documentation and testing evidence rather than relying on the directory listing alone.

  1. 01

    Which artifacts, identities, hashes, signatures, and provenance records are covered?

  2. 02

    Which CycloneDX, SPDX, SLSA, Sigstore, or model-specific formats are supported?

  3. 03

    Can evidence be verified across build, registry, conversion, and deployment boundaries?

  4. 04

    How are trust roots, policy exceptions, key management, and failures handled?