Thanks for sharing this — really solid write-up, and I agree with the core premise. Pickle is a huge blind spot in ML security, and most folks don’t realize that torch.load() is effectively executing attacker-controlled bytecode.

One thing we ran into while working on similar problems is that static opcode scanning alone tends to give a false sense of coverage. A lot of real-world bypasses don’t rely on obvious GLOBAL os.system patterns and can evade tools that depend on pickletools, modelscan, or fickling.

We recently open-sourced a structure-aware pickle fuzzer at Cisco that’s designed specifically to test the robustness of pickle scanners, not just scan models:

• It executes pickle bytecode inside a custom VM, tracking opcode execution, stack state, and memo behavior • Mutates opcode sequences, stack interactions, and protocol-specific edge cases • Has already uncovered multiple scanner bypasses that look benign statically but behave differently at runtime

Repo: https://github.com/cisco-ai-defense/pickle-fuzzer

We also wrote up some of the lessons learned while hardening pickle scanners here (including why certain opcode patterns are tricky to reason about statically): https://blogs.cisco.com/ai/hardening-pickle-file-scanners

I think tools like AIsbom are a great step forward, especially for SBOM and ecosystem visibility. From our experience, pairing static analysis + fuzzing-driven adversarial testing is where things get much more resilient over time.