Generate SBOM for Local LLM Artifacts CLI Python

Generate SBOM for Local LLM Artifacts: CLI Python Walkthrough

We built L-BOM to handle a specific friction point in local AI development: inventorying model artifacts without triggering network calls or requiring heavy runtime dependencies. You have a directory full of .gguf and .safetensors files on your disk, and you need an accurate Software Bill of Materials (SBOM) for governance, compliance, or just knowing what you’re actually running. This tool parses those binaries directly to emit metadata including file identity, format specifics, architecture details, and parsing warnings. It’s a lightweight Python CLI designed for local inspection only.

What is L-BOM and Why Use It?

Standard SBOMs are often associated with enterprise supply chains involving thousands of npm or pip packages. That overhead doesn’t fit the local-first AI workflow. L-BOM fills the gap by treating model weights as artifacts with identities that need recording. We inspect files like llama-3.1-8b-instruct-Q4_K_M.gguf to extract metadata automatically.

The output includes warnings if a parser fails on a specific field, file identity hashes, format specifics, and model architecture information. This enables local AI model governance by generating compliant SBOMs with a simple command-line interface. You aren’t uploading your weights to a cloud scanner; the analysis happens entirely in your shell.

Installation and Quick Start Commands

Getting this running is intentionally frictionless. We want you skipping straight to the scan. Install the package globally or in editable mode using pip install . for immediate development use. If you are working on the codebase itself, use the -e flag so changes reflect instantly.

Verify installation version with l-bom version before scanning large model directories. This sanity check ensures the CLI is available on your PATH without needing to re-import a module every time.

Scan a single file to JSON output via l-bom scan <path> or generate SPDX tag-value formats for compliance reports. The default behavior is usually JSON, which is easy to parse in scripts, but SPDX is the standard for many enterprise registries if you need that specific format.

Advanced Output Formats and Hugging Face Integration

One of the most practical uses for an SBOM in a local context is documentation. Export scans as Hugging Face-ready README.md content using --format hf-readme. This generates a front-matter YAML block followed by Markdown that describes the model based on what we found inside the binary. You can customize titles and descriptions to match your specific project namespace or demo space requirements.

Configure static SDK builds and index.html generation for seamless deployment of model documentation pages. We support serving this output as a static asset, which is useful if you are hosting a local documentation server alongside your models. Override inferred metadata fields like short description to match specific organizational naming conventions without editing the source JSON later.

Recursive Scanning and Large File Optimization

Most local setups aren’t just single files; they are directories containing multiple quantizations of the same model or various adapters. Scan entire model directories recursively using l-bom scan <directory> to render Rich tables for quick overview. The CLI uses rich to display progress bars and summary tables in your terminal, making it easy to see which files were processed and if any returned parsing errors.

Skip SHA256 hashing with the --no-hash flag when processing very large model artifacts to reduce runtime overhead. Calculating a hash over a 7GB file adds significant wall-clock time and I/O pressure. If you only need the metadata for your inventory and not the cryptographic checksum, omitting this step speeds up the scan considerably.

Write full scan results directly to disk using the --output flag for offline archival or CI/CD pipeline integration. Sometimes you want to generate the SBOM once during a build step and then reuse the JSON artifact in a separate deployment script. This decouples the analysis phase from the reporting phase, which simplifies complex automation pipelines.

Sample SBOM JSON Structure and Metadata Analysis

Review generated JSON output containing file size, architecture type, parameter count, quantization level, and context length. We map these fields to standard conventions so they are immediately recognizable to other tools. The structure includes sbom_version for schema tracking, generated_at timestamps, and the full model_path.

Extract deep metadata fields including license details, supported languages, block counts, and attention head configurations. We parse the internal headers of GGUF and Safetensors formats to pull these specific keys. For example, we can extract the general.architecture string, the lfm2.block_count, or the general.languages array directly from the binary blob.

Identify parsing warnings or null values in training framework and base model fields to assess data provenance gaps. If a file is missing standard header fields or contains corrupted metadata, we surface that in the output rather than silently ignoring it. This helps you spot models that might be partially downloaded or modified versions where critical information has been stripped.

Explore Related Tools from CHKDSK Labs

We maintain a sister program GUI-BOM for a friendly GUI wrapper to deploy L-BOM functionality easily. If you prefer clicking buttons over typing flags, this tool wraps the same core logic in an interface that handles file selection and format switching automatically.

Visit the main repository at CHKDSKLabs/l-bom to view source code, issues, and contribution guidelines. The project is open source under the MIT license. We welcome pull requests that improve parsing robustness for obscure quantization schemes or add new output formats. Keep pull requests focused: one change per PR makes review faster and merges cleaner.

Contributions are accepted under the same license as the project (MIT). Search existing issues before opening a new one to avoid duplicates. Provide clear reproduction steps and context when reporting bugs. Be patient with review timelines; maintainers are a small team and will get to your contribution.