After three months of integrating Wiz into our AI/ML pipeline security monitoring, I'm ready to call it: Wiz is a powerful scanner, not a tailored AI supply chain security solution. It gives you excellent raw data, but the burden of building context and meaningful alerts for AI workloads falls entirely on your team. If you're expecting out-of-the-box policies for Hugging Face tokens, model registry vulnerabilities, or training data lineage gaps, you will be disappointed.
Our initial goal was to gain visibility into the entire lifecycle of our production models: from the data ingestion and feature store, through the training pipelines (running on Kubeflow and custom containers), to the final deployed model endpoints and the associated infrastructure. Here is what we found, broken down.
**The Good: Foundational Cloud Security**
* **Agentless Scanning Depth:** The breadth of cloud resource scanning is undeniable. It identified misconfigured compute clusters hosting our inference endpoints, overly permissive service accounts used by pipeline runners, and exposed storage buckets containing (anonymized) training datasets.
* **Graph-Based Relationships:** The "graph" view is valuable for tracing a vulnerability in a container image back to all running pods, and to the workloads and identities using it. This helped us prioritize patching for a vulnerable `pandas` library in an active training image.
* **Infrastructure-as-Code (IaC) Security:** This was a standout. Catching security misconfigurations in our Terraform modules for ML pipeline orchestration *before* deployment prevented several potential data exfiltration paths.
**The Gaps: Where "AI Security" is Just Generic Cloud Security**
The primary issue is that Wiz treats an AI supply chain as a collection of generic cloud resources. The specific context of AI components is missing.
* **Model Registries & Artifact Repositories:** A vulnerability scan of a container image holding a PyTorch model is treated the same as a scan of a nginx web server. There's no concept of "this image is a model artifact, deployed to these endpoints, trained on this dataset." We had to build this mapping ourselves using custom tags and external tooling.
* **Secret Management for AI Tools:** Wiz flagged a hard-coded API key in a Jupyter notebook stored in a bucket. Good. But it has no specific logic for detecting improperly scoped Hugging Face tokens, Weights & Biases API keys, or cloud provider access keys used solely for model deployment. These require custom rules.
* **Data Lineage & Sensitive Training Data:** It can identify an S3 bucket with PII (using its built-in classifiers), but it cannot tell if that bucket is the *source* for a feature engineering job or a training run. Understanding the flow of sensitive data through the ML pipeline is a manual correlation exercise.
* **Pipeline-Specific Risks:** No visibility into risks within the pipeline orchestration itself. For example, a compromised step in a Kubeflow pipeline that writes poisoned data to a feature store is not a detectable pattern.
**Our Current Workflow & The Toil**
We now use Wiz as our primary cloud vulnerability scanner and feed its findings, via their API, into our own data platform. We enrich Wiz findings with context from our ML metadata store (MLMD) and pipeline logs to create a true "AI supply chain" risk view.
```sql
-- Example of the join we run internally to add context to Wiz vuln findings
SELECT
w.asset_id,
w.vulnerability_name,
w.severity,
ml.pipeline_name,
ml.pipeline_stage,
ml.model_name,
ml.dataset_used
FROM
wiz_vulnerabilities w
LEFT JOIN
ml_metadata_store ml
ON w.resource_tags['pipeline-id'] = ml.pipeline_id;
```
**Conclusion**
If you are already a Wiz shop and are expanding into AI/ML, you can extend it to cover the infrastructure layer. Its data is high-quality. However, if your primary need is securing the AI supply chain—models, data, pipelines, and AI-specific secrets—you are essentially paying for a powerful data source and must build the analytical layer on top. For a platform marketed heavily towards cloud-native and cutting-edge tech, the lack of AI-aware security primitives is a significant omission. You will need supplementary tooling or a significant investment in internal platform development.
—davidr
—davidr
>the burden of building context and meaningful alerts for AI workloads falls entirely on your team.
That's the part I'm worried about. We're looking at this for our basic model deployments, but our team is tiny. The "raw data" issue you mention sounds like a full-time job to translate.
So, for the graph relationships on Kubeflow pipelines, did you find that useful context was auto-generated, or did you have to manually map every custom container to a business process first?
Exactly. The raw data from their agentless scanner is comprehensive, but the "graph" is a generic cloud asset graph. It won't magically understand your Kubeflow DAGs as a business process.
You have to manually build that context. For each custom container image in a pipeline step, you're tagging it with metadata like `pipeline-name: customer-churn-v3` and `stage: feature-engineering` so Wiz can group findings. The graph shows the container runs on a node pool, which uses a service account, which has storage permissions. That's useful, but it's infrastructure-up, not business-process-down. You're doing the mapping.
For a tiny team, this is a heavy lift. The real work is writing the correlation logic outside Wiz to say "alert me if a container tagged with `stage: model-serving` has a critical CVE" versus just another dev container. Wiz gives you the CVE scan, you build the policy.
—davidr