> but blindly trust the 5GB binary model files (.pt) we download from Hugging Face.
I thought the ecosystem had mostly moved to .safetensors (which was explicitly created to fix this problem) and .gguf (which I'm pretty sure also doesn't have this problem); do you really need to download giant chunks of untrusted code and execute it at all?
People will take the risk with uncensored models tuned for specific things. I'm glad we're talking about this now rather than 10 years later like with npm. The amount of ad-hoc AI tools on github is staggering, and people are just downloading these things like it's no big deal.
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.
Consider adding a little UI to this. If I can just right-click a model/zip/folder and click "scan", then there's really no reason not to have this around (speaking in terms of removing any practical barrier, including laziness).
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.
Maybe because the trained habit of doing the same with npm??? Why write your own code when there's 30 packages "doing the same thing" and I don't have to look at the code at all and just include with no clue what's going on under the hood? What could possibly go wrong?
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.
This is great tool! Would it be possible to add GGUF to your tool? It may be a little tricky format to parse but GGUF format already seen few attack vectors and I consider it untrustworthy. Been able to snan GGUF files would be great!
@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.
I thought the ecosystem had mostly moved to .safetensors (which was explicitly created to fix this problem) and .gguf (which I'm pretty sure also doesn't have this problem); do you really need to download giant chunks of untrusted code and execute it at all?