Two of the most direct ways an attacker gets code into your stack are a poisoned package on the way in and a poisoned model artifact on the way to inference. Both slip past scanners that only look at your first-party code, and both execute the moment they land — a post-install hook fires, or a checkpoint deserializes. Today we're rolling out two capabilities aimed squarely at those two doors: the Package Firewall and AI model-artifact scanning, the latter now covering ONNX in addition to the formats we already handled.
Both are available now, tenant-scoped, audit-logged, and admin-toggleable. Here's what each one does and, just as important, what it does not.
The Package Firewall: prevention at install time
Most dependency security is a report you read after the bad package is already in your lockfile. The Package Firewall moves that decision earlier — to the moment of install. It sits in front of your package managers as an install-time proxy for npm and pip, inspecting every resolution before it reaches your tree.
It blocks three concrete classes of attack inline:
- Typosquats — packages whose names are a keystroke away from something you meant to install.
- Dependency and namespace confusion — internal package names shadowed by public look-alikes, the attack class we've written about more than once.
- Known-malicious packages — anything already identified as hostile in the advisory ecosystem.
Beyond name and reputation checks, a non-executing behavioral analyzer examines package contents — install scripts, entry points, and manifest metadata — without running them. This is deliberate: the whole point of blocking at install time is to avoid executing attacker-controlled code, so the analysis is static by design.
The firewall runs in one of two modes so it can fit how your team actually works:
- Audit mode logs what it would have blocked without stopping installs — the safe way to roll it out and measure signal before you enforce.
- Quarantine mode holds a suspicious package out of the resolution and routes it to review.
When a quarantined package is cleared — a false positive, or a newly-vetted release — an auto-release loop lets it through without a manual re-run. Every decision, in either mode, lands in the tenant-scoped audit log.
For a fuller picture of where this sits in the platform, see the capabilities page and our background on typosquatting and dependency confusion.
AI model-artifact scanning: catching malware before the weights load
A model file is not inert data. Several popular serialization formats can carry code that runs at load time, which makes a downloaded checkpoint a supply-chain artifact every bit as much as an npm package. Our AI security posture management (AI-SPM) scanning treats it that way — it inspects model artifacts for malware and unsafe deserialization before they reach your inference plane, so a poisoned checkpoint becomes a finding like any other.
What we inspect today:
- Pickle-based formats via opcode disassembly, catching unsafe deserialization and code-execution constructs (CWE-502, CWE-94) without executing the payload.
- PyTorch (torch-zip) archives, which are pickle under the hood.
- safetensors and GGUF validation, confirming the artifact really is the safe-by-construction format it claims to be.
New: ONNX support. ONNX is now a first-class target. We scan for two ONNX-specific risks: custom operators that can smuggle arbitrary code into a graph (CWE-94), and external-data path escape, where a model references data files via paths that traverse outside the intended directory (CWE-22). If a model tries to reach outside its own bundle or ship a custom op you didn't ask for, you'll see it before it loads.
What this builds on
Neither capability is a standalone bolt-on. They emit into the same unified findings model as the rest of the platform, which already includes first-party SAST and DAST, defensive red-team and breach-and-attack simulation gated by a signed rules-of-engagement safety kernel, runtime and CNAPP correlation, DSPM data classification, AutoTriage noise reduction, function-level reachability, and proof-based verification. New engines roll out behind feature flags, so a Package Firewall finding and an ONNX finding show up in the same review queue, under the same policy language, as a container CVE or a reachable sink.
What's next
The two capabilities above are shipping today. The rest of this section is roadmap — where we're headed, not what's live. We call that out plainly because the fastest way to lose your trust is to describe a plan as a product.
On the roadmap, and clearly labeled as such:
- SecOps — SIEM, SOAR, and XDR with an agentic SOC analyst.
- Endpoint — EDR/EPP.
- Exposure management — CTEM and EASM, plus vulnerability and exposure management.
- Posture and identity — SSPM, ITDR, and DLP.
- Build and runtime integrity — trusted-artifacts build-from-source, an AI gateway, and RASP.
These are directions we're investing in, not switches you can flip today. When any of them ships, you'll hear it described exactly the way the Package Firewall and model-artifact scanning are here: available, scoped, and audit-logged.
How Safeguard Helps
The through-line for both of today's launches is the same: stop attacker-controlled code at the moment it tries to enter, whether it arrives as a dependency or as a model weight. The Package Firewall closes the install-time door for npm and pip; model-artifact scanning — now including ONNX — closes the load-time door for AI models. Both are prevention, not just reporting, and both feed the same unified findings store the rest of the platform already uses. If you want to turn either on for your tenant, start in audit mode, watch what it catches, and enforce when you're ready — or reach out and we'll walk you through it.