lab700xdev

@altomek - Thanks for the suggestion! Just shipped v0.3.0 which includes a native GGUF header parser. It now extracts metadata and checks for license risks in .gguf files.

This is incredibly valuable feedback. I’ve been reading through the pickle-fuzzer repo this morning, specifically about stack manipulation bypassing static heuristics. You nailed the trade-off: AIsbom is designed for the "90% hygiene" case in a fast CI/CD pipeline (where spinning up a VM/Fuzzer might be too heavy/slow for every commit). We aim to catch the low-hanging fruit (obvious RCE) and generate the Inventory (SBOM) rapidly. That said, moving toward an "Allowlist Only" (Strict Mode) approach seems like the better way to make static analysis resilient against the obfuscation you mentioned. We are prioritizing that for upcoming release. Would love to potentially reference your fuzzer in our docs as the "Deep Scan" alternative!

That barrier to entry ("laziness") is the #1 security vulnerability. If it takes 3 minutes to set up a scanner, nobody does it. That's actually why we built the Web Viewer - so you can just drag-and-drop the JSON output rather than reading terminal logs. But a native OS "Right Click --> Scan with AIsbom" Context Menu integration is a fantastic idea for a future desktop release. Thanks.

The comparison to npm is spot on. We are seeing the exact same pattern: a massive explosion of dependency complexity, but now the "dependencies" aren't 50KB JavaScript files, they are 10GB binary blobs that we treat as black boxes. The "Shadow AI" problem (developers cloning a random repo + downloading a model from a Google Drive link to get a specific uncensored tune) is exactly what we built the CLI for. We want to make it trivial to run a "hygiene check" on that download folder before mounting it into a container.

Fair point on the terminology overlap with "Zip Bombs" (resource exhaustion). I used "Pickle Bomb" colloquially to describe a serialized payload waiting to detonate upon load, similar to how "Logic Bomb" is used in malware. "Malicious Pickle Stream" is definitely the more precise technical term, but it doesn't quite capture the visceral risk of "I loaded this file and my AWS keys are gone" as well as Bomb does!

You are right that the inference ecosystem (llama.cpp, vLLM) has moved aggressively to GGUF and Safetensors. If you are just consuming optimized models, you are safer. However, I see two reasons why the risk persists: 1) The Supply Chain Tail: The training ecosystem is still heavily PyTorch native. Researchers publishing code, LoRA adapters, and intermediate checkpoints are often still .pt. 2) Safetensors Metadata: Even if the binary is safe, the JSON header in a .safetensors file often carries the License field. AIsbom scans that too. Detecting a "Non-Commercial" (CC-BY-NC) license in a production artifact is a different kind of "bomb" - a legal one - but just as dangerous for a startup.

Thanks for the link! fickling is excellent work (and definitely the gold standard for deep analysis). The goal with AIsbom was to build something lightweight enough to run in a fast CI/CD loop that creates a standard inventory (CycloneDX SBOM) alongside the security check. We are definitely looking at fickling's symbolic execution approach for inspiration on how to make our safety.py module more robust against obfuscation.

The Golden Rule holds: "Don't unpickle untrusted data." The problem I'm trying to solve is that "Untrusted" has become blurry in the AI age. Data Scientists treat Model Hubs (like Hugging Face) as trusted repositories, similar to PyPI or NPM. They shouldn't, but they do. This tool effectively serves as a "Loud Warning Label" to break that assumption. It tells the engineer: "Hey, you think this is just weights, but I see socket calls in here. Do not load this."

That is entirely fair feedback regarding the new accounts. We all have to start somewhere! That is exactly why I open-sourced the engine (Apache 2.0) and kept the logic in Python rather than a compiled binary - so you don't have to trust "me", you can audit scanner.py and safety.py yourself to see exactly how we parse the zip headers. Regarding Safetensors: I agree 100%. If everyone used Safetensors, this tool wouldn't need to exist, but looking at the Hugging Face hub, there are still millions of legacy .pt files being downloaded daily. This tool is a guardrail for the messy reality we live in, not the perfect future we want.

Ideally, CI/CD Pipeline (Pre-Merge) - We recently released a GitHub Action for this exact workflow. The goal is to block a Pull Request if a developer tries to merge a .pt file that contains CRITICAL risk opcodes. If you wait until Runtime to check, you’ve likely already unpickled the file to inspect it, which means you’re already pwnd. This needs to happen at the artifact ingestion stage (before it touches your production cluster).

You are absolutely right - blocklisting is a game of whack-a-mole. However, in the context of serialized ML weights, the "allowlist" of valid imports is actually quite small (mostly torch.nn, collections, numpy). Right now, we are flagging the obvious low-hanging fruit (script kiddie RCE) because generic SCA tools miss even that. The roadmap includes moving to a strict "Allowlist" mode where we flag any global import that isn't a known mathematical library. That’s much safer than trying to list every dangerous function

Hi HN,

I’ve been working with ML infrastructure for a while and realized there’s a gap in the security posture: we scan our requirements.txt for vulnerabilities, but blindly trust the 5GB binary model files (.pt) we download from Hugging Face.

Most developers don't realize that standard PyTorch files are just Zip archives containing Python Pickle bytecode. When you run torch.load(), the unpickler executes that bytecode. This allows for arbitrary code execution (RCE) inside the model file itself - what security researchers call a "Pickle Bomb."

I built AIsbom (AI Software Bill of Materials) to solve this without needing a full sandbox.

How it works: 1. It inspects the binary structure of artifacts (PyTorch, Pickle, Safetensors) without loading weights into RAM. 2. For PyTorch/Pickles, it uses static analysis (via pickletools) to disassemble the opcode stream. 3. It looks for GLOBAL or STACK_GLOBAL instructions referencing dangerous modules like os.system, subprocess, or socket. 4. It outputs a CycloneDX v1.6 JSON SBOM compatible with enterprise tools like Dependency-Track. 5. It also parses .safetensors headers to flag "Non-Commercial" (CC-BY-NC) licenses, which often slip into production undetected.

It’s open source (Apache 2.0) and written in Python/Typer. Repo: https://github.com/Lab700xOrg/aisbom Live Demo (Web Viewer): https://aisbom.io

Why I built a scanner? https://dev.to/labdev_c81554ba3d4ae28317/pytorch-models-are-...

I’d love feedback on the detection logic (specifically safety.py) or if anyone has edge cases of weird Pickle protocols that break the disassembler.