{"slug": "vetting-the-black-box-a-supply-chain-due-diligence-framework-for-ai-and-ml", "title": "Vetting the Black Box: A Supply Chain Due Diligence Framework for AI and ML", "summary": "On March 24, 2026, attackers compromised LiteLLM's CI/CD pipeline and uploaded malicious PyPI packages that stole credentials from environments with three million daily downloads. The incident highlights AI supply chain risks where dependencies are trusted by default, prompting a proposed two-track due diligence framework for vetting models, datasets, and agent dependencies before production deployment.", "body_md": "On March 24, 2026, two PyPI releases of LiteLLM (versions 1.82.7 and 1.82.8) went live carrying a credential stealer and a dropper payload. The attacker, tracked by Datadog Security Labs as TeamPCP, had compromised LiteLLM's CI/CD pipeline via a poisoned Trivy GitHub Action, then used stolen PyPI credentials to upload directly to the registry [1]. The packages were quarantined approximately 40 minutes later. LiteLLM processes roughly three million downloads per day [2].\n\nForty minutes. Three million daily downloads. The payload harvested SSH keys, environment variables, AWS, GCP, Azure, and Kubernetes credentials, database passwords, SSL private keys, shell history, and CI/CD configuration. Every environment that pulled a fresh install during that window was exposed, not because the underlying model was malicious, but because the dependency sitting next to it was.\n\nThis is the AI supply chain problem in concrete form. Engineers `pip install`\n\nand call `from_pretrained()`\n\nwith the same implicit trust they extend to framework code, with none of the scrutiny they'd apply to a new infrastructure vendor. The entity behind the artifact and the artifact itself are both trusted by default, and adversaries know it.\n\nThis article gives practitioners a process for withdrawing that default trust. It describes a two-track due diligence framework (vendor OSINT and technical artifact assessment) that can be applied before onboarding any model, dataset, MCP server, or agent dependency into a production environment.\n\n## Two Vectors of AI supply chain risk\n\nAI supply chains face two structurally distinct threat vectors. Most security coverage focuses on the first and ignores the second. The second is more common in practice.\n\n### Vector A: the compromised publisher\n\nThe first vector is the one the software industry has been fighting for years. A legitimate, known publisher — one you had reason to trust — gets compromised, and a malicious artifact reaches you through a channel you considered safe.\n\nIn December 2020, SolarWinds distributed a trojanized update to its Orion network monitoring software; approximately 18,000 organizations installed it [3]. The attack worked by compromising the build pipeline and injecting SUNBURST into a legitimate, signed binary. Defenders trusted the update because it came through the expected channel, from the expected vendor, signed with the expected certificate.\n\nIn March 2024, a pseudonymous contributor named \"Jia Tan\" was caught having spent nearly two years building maintainer-level trust in the XZ Utils project before inserting a backdoor targeting OpenSSH [4]. The vulnerability, CVE-2024-3094 (CVSS 10.0), was discovered by Microsoft engineer Andres Freund while investigating an anomalous 500ms SSH latency spike — a near-miss that most organizations would never have noticed.\n\nIn December 2024, the Ultralytics YOLO library (61 million total downloads, a dependency for ComfyUI, MinerU, and dozens of downstream ML projects) was compromised via its GitHub Actions runner [5]. Versions 8.3.41, 8.3.42, 8.3.45, and 8.3.46 contained an XMRig Monero miner. The first two versions were injected through CI; when those were pulled, the attacker used compromised PyPI credentials belonging to Ultralytics CEO Glenn Jocher to push the payload a second time, directly from outside CI [5]. The package was legitimate. The publisher was real. The artifact was poisoned anyway.\n\nThis is the pattern: trust exists, then it is exploited. Artifact scanning is the primary defense. Vendor OSINT, on the other hand, would have just shown a clean bill of health right up until the moment of compromise.\n\n### Vector B: the unvetted onboard\n\nPulling unvetted packages from a public registry is not a new attack surface. Typosquatting, dependency confusion, and malicious package campaigns have plagued npm and PyPI for years. What changes in AI supply chains is the severity of the execution mechanism and the size of the scrutiny gap practitioners actually apply.\n\nThe mechanism change is structural. Loading a `.pt`\n\nfile with `torch.load()`\n\nis not equivalent to installing a package: it executes arbitrary Python on deserialization. The artifact can be the payload. That distinction gets its own section below; the relevant point here is that Vector B carries code execution risk with no direct parallel in pulling an unknown npm package. An unknown JavaScript dependency can do significant damage through its runtime behavior. An unknown model file can execute a reverse shell before you have evaluated a single weight.\n\nThe scrutiny gap is a matter of documented practice. A team reviewing a new infrastructure dependency typically examines maintainer history, download counts, linked repository, and open issues. The same team will often pull a HuggingFace model based on a benchmark leaderboard result or a forum recommendation, with no equivalent process. The risk tolerance applied to AI artifacts lags significantly behind what the mechanism actually warrants.\n\nHuggingFace hosts over one million models. Publication requires no identity verification, no code review, and no security scanning by default. Protect AI's analysis of more than four million models on the platform identified approximately 352,000 unsafe or suspicious issues across 51,700 distinct models [6]. JFrog found over 100 models capable of arbitrary code execution [7]. One of them, `baller423/goober2`\n\n, established a reverse shell to an attacker-controlled IP on model load. No CI compromise required. No trusted publisher relationship to exploit. The attacker published a model and waited.\n\nSource repositories add a parallel discovery channel with even less structure. GitHub and GitLab host model weights via Git LFS and packaged releases, fine-tuning and evaluation datasets in Parquet, JSONL, and Arrow formats, and the majority of MCP server implementations — often as the sole distribution point, with no registry-level metadata, download counts, or security scanning. A researcher publishes a fine-tuned model as a GitHub release artifact; a practitioner finds it through a paper's repository link or a search result. The provenance questions are identical to HuggingFace, with less infrastructure to answer them.\n\nDatasets belong in this threat model explicitly. They are pulled from public repositories with the same low-friction workflow as models, and they carry distinct risks on both sides of the pipeline. A poisoned fine-tuning or evaluation dataset shifts the attack to training time: model behavior is corrupted before the weights are ever published, making artifact scanning ineffective against the mechanism. Dataset files also have their own parsing attack surface. CVE-2023-47248 (CVSS 10.0) demonstrated that loading a crafted Apache Arrow IPC file through PyArrow's deserializer could execute arbitrary code on the loading machine [21]. Any dataset pulled from GitHub, Kaggle, Hugging Face Datasets, or any other public repository carries the same provenance questions as a model: who collected the data, under what terms, from what original sources, and whether file integrity is verifiable.\n\nThe same dynamic now applies to MCP servers and agent skill registries. Koi Security's audit of ClawHub, one of the largest repositories of AI agent skills, found 341 malicious entries out of 2,857 total. Of those, 335 were traced to a single coordinated campaign [8]. Engineers integrating these skills into their agent stacks had no process for asking who built them.\n\nVector B is operationally more common than Vector A for most AI teams, because it describes every time someone runs `from_pretrained()`\n\non a model they found through a benchmark leaderboard, a Reddit post, or a search on the Hub. It is also structurally harder to defend against, because there is no pre-existing relationship to monitor for anomalies.\n\n### Why both vectors require the same framework\n\nThe two-track approach in this article addresses both, but for different reasons.\n\n**Track 1 (vendor OSINT)** is primarily the defense against Vector B. When you are onboarding an entity you have no prior relationship with, OSINT is how you establish whether any trust can exist at all before the artifact reaches your environment. It is also an early-warning layer for Vector A — financial distress, key personnel departures, and ownership changes are all signals that a previously trusted publisher's security posture may be degrading.\n\n**Track 2 (artifact assessment)** is the defense against both vectors. A compromised artifact from a trusted publisher (Vector A) and a natively malicious artifact from an unknown publisher (Vector B) are equally dangerous once loaded. Artifact scanning, serialization format checks, and behavioral testing apply regardless of how much you trust the source.\n\nRunning Track 1 without Track 2 vets the publisher but misses the artifact-level compromise that can happen to any publisher, no matter how trustworthy. Running Track 2 without Track 1 catches bad artifacts from unknown publishers, but leaves you blind to the organizational context that should have blocked the onboard entirely.\n\nNeither track is optional.\n\n### The AI-specific attack surface\n\nBeyond the two vectors, AI supply chains add attack surfaces with no direct equivalent in shipping compiled code. We've already mentioned some of them, but they deserve explicit enumeration.\n\n**Serialization as code execution.** PyTorch's `.pt`\n\nfiles, Keras `.h5`\n\nmodels, and sklearn `.pkl`\n\nartifacts use Python's pickle format by default. Calling `torch.load()`\n\non an untrusted file is functionally equivalent to calling `eval()`\n\non untrusted input: the deserialization process executes arbitrary Python, with no sandboxing. There is no analog in shipping a compiled binary or a bundled JavaScript package.\n\n**Training data as a deferred vector.** Data poisoning at training time corrupts model behavior at inference time, invisibly. A model card can claim any training corpus; verification from the outside is rarely possible. The attack surface exists before the artifact is ever published.\n\n**Model cards and tool manifests as prompt injection surfaces.** In an MCP server, the description field of a tool definition is parsed into the LLM's context window. Adversarial prose embedded there can redirect agent behavior before any code runs (no exploit required, no CVE to file).\n\nAgainst this backdrop, onboarding a model, dataset, or MCP server without a structured vetting process is an accepted risk, not an absence of risk.\n\n## Track 1: Vendor OSINT — assessing organizational trustworthiness\n\n### Entity identification\n\nBefore any database queries, establish who you are actually looking at.\n\nMap the registry account (HuggingFace org, PyPI maintainer, GitHub org) to a registered legal entity. Search OpenCorporates against the claimed organization name, cross-referencing with state or national business registries in the jurisdiction of incorporation. Check LinkedIn for a company page and verify that the listed domain matches the registry account's claimed affiliation.\n\nPull WHOIS on the publisher's primary domain. Privacy-protected registration on what presents as a corporate domain is a yellow flag: legitimate organizations operating at any scale generally don't hide their registrant identity. Note the registration date; a domain registered weeks before a high-volume artifact was published warrants scrutiny.\n\nIdentify key maintainers by name. Cross-reference via GitHub (commit history, conference talks, academic papers), LinkedIn (employment history, endorsements), and public records. Can you verify that the named people are who they claim to be? The XZ Utils pattern (a pseudonymous maintainer operating as a fully credentialed contributor for two years before inserting a backdoor) is now the canonical risk model for open-source supply chains [4]. Pseudonymous maintainers on high-risk artifacts are not automatically disqualifying, but require explicit risk acceptance.\n\n### Financial health and corporate structure\n\nFinancial instability creates supply chain risk independent of intent. Acquisition by an unknown party, distressed sale, or sudden shutdown are all change-of-control events that can turn a vetted publisher into an unvetted one overnight.\n\nFor public companies, search SEC EDGAR for material risk disclosures in 10-K filings, going-concern language, significant foreign ownership disclosures, and 8-K breach notifications [15]. For private companies and startups, check Crunchbase or PitchBook for funding history: when was the last round, who are the investors, and what is the runway signal? A startup with no funding activity in two or more years and a widely integrated artifact is a fragility risk.\n\nUse OpenCorporates to confirm the entity's current status (active, dissolved, suspended) and map parent entity relationships. Corporate structures can obscure beneficial ownership that matters for foreign influence screening in the next section.\n\nMany AI artifact publishers are individuals or small organizations with no public financial footprint. In those cases, financial vetting defaults entirely to community signal analysis: GitHub issue response rates, CVE disclosure history, and maintainer responsiveness over time.\n\n### Foreign influence and ownership screening\n\nThis section is process-specific to organizations in regulated industries or handling sensitive data. Frame it as structured risk management, not country-of-origin profiling.\n\nScreen the publisher entity and named principals against the OFAC Specially Designated Nationals list [16]. The OFAC SDN API supports programmatic querying and can be integrated into onboarding pipelines. If the deployment context involves export-controlled technology, also check the BIS Entity List and Military End-User List.\n\nFor CFIUS-relevant signals (particularly relevant for US federal contractors, defense supply chains, and critical infrastructure) assess whether there is known Chinese state investment or board-level representation. CFIUS enforcement actions, mitigation agreements, and divestiture orders are public and searchable through the Treasury Department. Disclosed partnerships, research grants, or contractual relationships with foreign state entities or state-affiliated universities are material signals.\n\nNote the applicable regulatory framework: CMMC Level 2 and above require third-party AI vendor vetting as part of supply chain risk management [17]. FedRAMP's emerging AI guidelines are moving in the same direction. In the EU, DORA's ICT third-party risk requirements apply to AI tools used in financial services. Frame this vetting as compliance-necessary, not optional security hygiene.\n\n### Legal and regulatory record\n\nCourt records and regulatory enforcement actions are public and searchable with minimal effort.\n\nRun a PACER search against the entity name and named principals for US federal litigation: bankruptcy filings, IP disputes, and prior enforcement actions all appear here. Many states provide online access to state court records for smaller entities not appearing in federal filings. Legal disputes are not automatically disqualifying, but active IP litigation can affect artifact availability, and settled data privacy cases are material when a publisher claims GDPR or CCPA compliance.\n\nSearch for FTC and SEC enforcement actions explicitly. A publisher with an FTC settlement for deceptive data handling practices that currently markets a data processing model under a compliance claim is a meaningful contradiction. State AG actions (particularly from California and New York) increasingly cover AI-specific claims.\n\n### Breach and exposure history\n\nA publisher whose own infrastructure has been compromised is a heightened risk. Stolen maintainer credentials are the primary mechanism for CI/CD supply chain attacks.\n\nRun a domain search against HaveIBeenPwned [18]. Breaches affecting developer email domains are directly relevant: if a maintainer's work email is in a credential database, their PyPI or HuggingFace session tokens may also have been exposed. For public companies, search SEC EDGAR for 8-K breach notifications from the past three years.\n\nSearch the publisher's GitHub repositories for accidental secret commits. Git history is public and permanent until explicitly purged; tools like `git log`\n\nand `git grep`\n\ncan surface API keys, tokens, or private key material that was committed and later removed but remains in history. PyPI and HuggingFace both maintain records of account flags and suspensions, so check whether the account has been previously quarantined.\n\n### Community and ecosystem signals\n\nSoft signals aggregate into a meaningful picture of operational maturity.\n\nCVE response history is the clearest signal: when vulnerabilities have been reported against this publisher's artifacts, how quickly did they respond, and how transparently? Ignored reports, delayed patches measured in months, or aggressive legal responses to security researchers are significant red flags. Look for a `SECURITY.md`\n\nor equivalent security policy in the publisher's repositories, and verify that a responsible disclosure process is actually functional, not just present.\n\nGitHub issue tracker responsiveness matters independently of CVE history. Open issues with no maintainer response over several months indicate an undermaintained artifact, which is a distinct risk from malicious intent: an abandoned artifact with broad integration is a takeover target.\n\nContributor diversity is a fragility signal. A single-maintainer artifact with no evident succession plan is vulnerable to the same credential theft and account takeover patterns that enabled the LiteLLM attack [1].\n\n## Track 2: Technical artifact assessment\n\n### Provenance and identity\n\nBefore downloading anything, establish whether the publisher is who they claim to be.\n\nOn HuggingFace, a verified organization badge cross-references the account to an official domain. Its absence is not disqualifying (many legitimate researchers publish as individuals) but account age and contribution history matter. A newly created org with a high-download artifact and no prior activity warrants additional scrutiny. The XZ Utils attack succeeded partly because \"Jia Tan\" spent nearly two years contributing legitimately before the insertion; newly created accounts offer no such assurance of intent, but also no history to evaluate.\n\nCheck the model card. A complete model card discloses the training dataset, known limitations, intended use, and out-of-scope applications. Absent or sparse model cards are a yellow flag: organizations shipping production artifacts document them. More concretely, if a model card doesn't name the training data, you cannot assess data poisoning risk or license chain compliance.\n\nOn licensing, the declared license and the actual terms should match. Llama-family models carry usage restrictions that differ substantially from Apache 2.0 or MIT. Models trained on LAION, Common Crawl, or other large crawled corpora may impose obligations the publisher isn't surfacing. Confirm the license chain (including the base model's license for fine-tuned derivatives) before any commercial deployment.\n\nFinally: does the publisher provide SHA-256 hashes or Sigstore signatures for their releases? Artifact signing adoption in the AI/ML ecosystem is currently limited, but growing. Its absence means you cannot verify that what you downloaded matches what the publisher intended to ship.\n\n### Serialization format and file integrity\n\nThis is the highest-severity AI-specific risk category. Understand what you are loading before you load it.\n\n**Pickle and .pt files** execute arbitrary Python on deserialization. The\n\n`__reduce__`\n\nmethod can be overridden to run any code; this is the mechanism JFrog documented in `baller423/goober2`\n\n, where a reverse shell was established to an attacker-controlled server on model load [7]. The \"nullifAI\" evasion technique, discovered in 2025, further embeds malicious pickle payloads at the start of the byte stream and compresses with 7z rather than default ZIP, bypassing HuggingFace's PickleScan tool. JFrog subsequently found three zero-day vulnerabilities in PickleScan itself, including CVE-2025-10155 [9].**SafeTensors** is the alternative. HuggingFace's purpose-built format stores only numerical tensors and their metadata; no code execution on deserialization is possible by design [10]. As of 2025, over 700,000 models on the platform use safetensors. However, 21% of models remain exclusively in pickle format, including 29 of the top-100 most downloaded [10]. Requiring safetensors availability as an onboarding condition is now a reasonable policy for organizations with the leverage to enforce it.\n\n**ONNX** carries lower risk than pickle but is not zero-risk: custom operators can be exploited, and the format has a history of implementation vulnerabilities in runtime parsers.\n\nRun ModelScan [11] against any artifact before loading it. ModelScan reads file content byte-by-byte rather than executing it, detecting unsafe code signatures across PyTorch, TensorFlow, Keras, ONNX, GGUF, and SavedModel formats. It catches known pickle exploit patterns and flags unsafe operator usage. ModelScan cannot detect all novel evasion techniques (nullifAI evaded its predecessor PickleScan), so treat a clean scan as a necessary condition, not a sufficient one.\n\nVerify the downloaded file hash against any publisher-declared value. If the publisher provides no hashes, document that gap explicitly.\n\n### Dependency and environment footprint\n\nThe model artifact itself may be clean while its dependency tree is not.\n\nInspect `requirements.txt`\n\nor `pyproject.toml`\n\nbefore instantiating anything. Run `pip-audit`\n\nor Grype against the declared dependencies to check for known CVEs. The LiteLLM compromise is illustrative: the attack vector was not the model weights but the Python package sitting in the dependency tree of every environment using that library [1].\n\nIf the artifact ships as a container, verify the base image against a known-good digest before deploying. Inspect the image for extraneous packages and check the base image's own CVE exposure via Trivy or Grype.\n\nFor MCP servers specifically, review tool definitions before connecting them to an agent. Three signals are worth explicit attention:\n\n**Permission scope**: does the tool request broader access than its stated function requires? A documentation-retrieval tool that requests write access to the filesystem is mis-scoped.**Description content**: does the tool description contain instruction-like prose? Tool descriptions are parsed into LLM context and can be weaponized for prompt injection before any code executes.**Credential parameters**: are credential fields typed and scoped, or do they accept arbitrary strings without constraints?\n\nDocument expected network egress during inference before deployment. A model that makes undisclosed outbound connections at runtime is behaving outside its stated contract. Treat that as an incident, not a curiosity.\n\n### Training data provenance\n\nTraining data provenance is the hardest element to verify from the outside, and the most important to classify correctly.\n\nWhat datasets does the model card declare? Common Crawl, LAION, and proprietary corpora carry different risk profiles. LAION-5B, used widely across open-source models, has documented issues with illegal content that prompted partial takedowns in 2023 [12]. Common Crawl carries unknown data poisoning exposure by design: it is a snapshot of the open web with no curation.\n\nFor fine-tuned models, what was the base model and what fine-tuning data was applied? Undisclosed fine-tuning data is a meaningful risk: behavior can be manipulated at fine-tuning time in ways invisible to artifact scanning and difficult to surface through functional testing. A model behaving unexpectedly under specific prompts (prompt injection resistance failures, unusual persona adoption) may reflect fine-tuning, not runtime attack.\n\nTreat training data provenance as a documentation quality signal rather than a binary pass/fail. Use its completeness to calibrate the required depth of behavioral testing in the next step.\n\n### Behavioral integrity: adversarial testing\n\nA clean artifact from a thoroughly vetted publisher can still harbor emergent vulnerabilities. Adversarial testing is distinct from functional testing: the goal is not to verify expected outputs but to probe for unintended behaviors under adversarial inputs.\n\n**Garak** [13] (now maintained by NVIDIA) is the standard open-source tool for structured LLM vulnerability scanning. Version 0.14.1, released April 2026, covers 37+ probe modules across jailbreaks, prompt injection, data extraction, hallucination, toxicity generation, encoding-based attacks, malware generation, and package hallucination. A basic onboarding scan against a HuggingFace model runs as:\n\n```\npython -m garak \\\n  --model_type huggingface \\\n  --model_name \"publisher/model-name\" \\\n  --probes promptinject,jailbreak,leakage.Context\n```\n\nAgainst an API endpoint:\n\n```\npython -m garak \\\n  --model_type openai \\\n  --model_name gpt-4o \\\n  --probes dan,promptinject,leakage.Context\n```\n\nGarak outputs a structured report with per-probe pass/fail rates and example failures. A probe failure is not automatically a blocker. It is a signal that requires human judgment about the deployment context.\n\n**FuzzyAI** [14], released by CyberArk, takes a complementary approach: coverage-guided mutation fuzzing that generates novel adversarial inputs rather than running a fixed probe library. Where Garak is structured and systematic, FuzzyAI is exploratory and surfaces edge cases that structured probes don't cover. Run it against an exposed system prompt:\n\n```\nfuzzyai -m openai -n gpt-4o -f system_prompt.txt -a all\n```\n\nScope adversarial testing appropriately: it is a risk-calibration exercise before deployment, not a guarantee of safety post-deployment. Neither Garak nor FuzzyAI can surface vulnerabilities that require specific operational context to trigger, and neither tests artifact-level compromise (that is ModelScan's domain). These tools belong in the workflow after artifact scanning passes, as an additional gate before live integration.\n\n## A worked example: vetting `baller423/goober2`\n\nIn February 2024, JFrog security researchers auditing HuggingFace for malicious content identified a PyTorch model repository (`baller423/goober2`\n\n) whose pickle payload established a reverse shell connection to an attacker-controlled IP address upon loading [7]. This is a documented case with public findings on both tracks, making it a clean illustration of the framework.\n\n**Track 1 — Vendor OSINT**\n\nEntity identification: `baller423`\n\nis a pseudonymous account. No verifiable legal entity. No claimed domain. No cross-references to any public GitHub profile, LinkedIn account, academic publications, or conference presence. Account created shortly before the malicious upload.\n\nFinancial health: no data. Not a registered entity.\n\nForeign influence screening: not applicable (no entity to screen).\n\nLegal record: no data.\n\nBreach history: no domain to check. No prior CVE history.\n\nCommunity signals: no security policy. No issue tracker activity. No contributor history beyond the malicious upload.\n\nTrack 1 verdict: **UNKNOWN across all categories** (no verifiable information exists). In a real onboarding process, a fully unverifiable publisher is sufficient justification to block the onboard before the artifact is ever downloaded.\n\n**Track 2 — Artifact assessment**\n\nThe serialization format is `.pkl`\n\n(a pickle file). That immediately triggers the highest-severity check. Running ModelScan against the artifact surfaces the payload: a `__reduce__`\n\noverride establishing an outbound reverse shell. No model card exists. No SHA-256 hashes are provided. No version history is present.\n\nThe behavioral testing step is moot: the artifact failed artifact scanning before it could be loaded at all. The dependency footprint is minimal, but the artifact itself is the attack vector.\n\nTrack 2 verdict: **FAIL / CRITICAL**. Do not load. Do not onboard.\n\n**Combined picture**\n\n| Check | Track 1 (OSINT) finding | Track 2 (Artifact) finding | Risk |\n|---|---|---|---|\n| Publisher identity | Pseudonymous, unverifiable | — | CRITICAL |\n| Account age / history | New account, no prior activity | — | HIGH |\n| Financial / legal | No data | — | UNKNOWN |\n| CVE / breach history | No data | — | UNKNOWN |\n| Serialization format | — | Pickle (.pkl) | HIGH |\n| ModelScan result | — | Reverse shell payload detected | CRITICAL |\n| Model card | — | Absent | MEDIUM |\n| Hash verification | — | None provided | MEDIUM |\n\nThe artifact failed on the first substantive check. The vendor OSINT provided nothing to counterbalance it. This is what a hard-block case looks like, and it requires no forensic expertise to reach the conclusion, only a structured process applied before load.\n\n## Automation and continuous monitoring\n\n### Artifact scanning tools\n\n**ModelScan** [11] is the current standard for pre-load artifact scanning. Open source, maintained by Protect AI, it supports PyTorch, TensorFlow, Keras, ONNX, GGUF, and SavedModel formats. Basic usage:\n\n```\n# Scan a single model file\nmodelscan scan -p model.pkl\n\n# Scan a directory of model files\nmodelscan scan -p ./model_directory/\n```\n\nModelScan reads file content without executing it, flagging unsafe code signatures. For enterprise environments, Protect AI's Guardian platform extends ModelScan to 35+ formats with policy enforcement, access controls, and compliance dashboards.\n\n**pip-audit** [19] scans Python dependency trees against the OSV vulnerability database. Run it before instantiating anything in a new environment:\n\n```\npip-audit -r requirements.txt\n```\n\n**Grype** and **Trivy** provide broader software composition analysis across container images, filesystems, and SBOMs. Trivy additionally scans infrastructure-as-code configurations relevant to deployment environments.\n\n**Sigstore/cosign** provides artifact signing and verification. Adoption in the AI/ML ecosystem is currently limited (most model publishers do not sign releases) but growing, and requiring signed artifacts is a defensible policy where leverage exists.\n\n### Adversarial testing tools\n\n**Garak** [13] and **FuzzyAI** [14] serve different roles in behavioral testing.\n\nGarak's structured probe library makes it appropriate for systematic onboarding checks: run a defined suite, get reproducible results, compare against a risk threshold. FuzzyAI's mutation-based approach surfaces edge cases that structured probes miss, making it useful for high-risk artifacts where the probe library may not cover the relevant threat model.\n\nNeither tool substitutes for artifact scanning. They belong after the artifact has passed a clean ModelScan result, as an additional behavioral gate. A model that passes artifact scanning but fails jailbreak probes at a rate inconsistent with its use case requires documented risk acceptance, not automatic blocking: the threshold depends on the deployment context.\n\n### OSINT workflow tooling\n\nThe vendor OSINT track is largely a manual process for organizations operating without commercial data subscriptions. The freely accessible sources that cover most cases:\n\n**OpenCorporates**: entity lookup across 140+ jurisdictions, free tier covers basic searches** OFAC SDN List API**: programmatic sanctions screening, publicly available** HaveIBeenPwned API**: domain breach lookup, free tier for domain search** SEC EDGAR full-text search**: enforcement actions, 8-K filings, 10-K disclosures\n\n**SpiderFoot** [20] is an open-source OSINT automation framework that can aggregate data across many of these sources in a single run. It is self-hostable and avoids sending query data to third-party commercial platforms. Maltego provides a richer visual interface but requires a commercial license for most data connectors.\n\nFor financial data beyond SEC EDGAR, PitchBook and Dun & Bradstreet provide structured private company information but are subscription-only. For smaller publishers, the practical answer is often that no commercial data exists, which itself is a signal that defaults the assessment to community-signal analysis.\n\n### Continuous monitoring\n\nOnboarding vetting is a point-in-time check. However, the risk surface changes over time.\n\nMonitor pinned dependencies for newly disclosed CVEs using Dependabot or Renovate. Both integrate directly with GitHub and create pull requests when pinned versions have known vulnerabilities. For more complex environments, generate an SBOM at onboarding and diff it against the current dependency state on a scheduled basis.\n\nMonitor specific artifacts you have onboarded. HuggingFace and PyPI both publish APIs that expose version history, ownership changes, and metadata updates. A model or package that changes owner, adds a new maintainer, or receives a silent version bump without a changelog entry is a re-assessment trigger.\n\nDefine explicit re-assessment conditions at onboarding time. Do not leave this to judgment after the fact. Minimum triggers: ownership change, significant version bump without documented changelog, CVE disclosure against the artifact or its publisher's infrastructure, and breach notification from the publisher. Treat any of these as equivalent to a new onboarding event.\n\n## Download: AI supply chain due diligence template\n\nThe framework above is designed to be run systematically. The template below puts both tracks (vendor OSINT and artifact assessment) into a single structured Excel workbook with status fields, risk ratings, a notes column for each check item, and a summary tab for approver sign-off. Use it during initial onboarding reviews or as the foundation for a recurring vendor risk program.\n\n## Conclusion\n\nAI supply chain risk is not primarily a technical problem. It is a trust problem.\n\nArtifact scanning catches compromised files. It cannot tell you whether the publisher's CI pipeline was backdoored three weeks ago, or whether the organization was quietly acquired by an entity on a restricted list, or whether the single maintainer of a 50,000-download library has stopped responding to issues because the project was abandoned. Vendor OSINT closes the gap that tooling cannot close.\n\nThe two-track framework is the minimum viable process for any organization integrating third-party AI components into production systems. Neither track is optional. A clean artifact from an unvetted publisher and a thoroughly vetted publisher with an unscanned artifact are both accepted risks with no visibility into what was accepted.\n\nThe AI registry ecosystem is maturing, but slowly. PyPI's mandatory 2FA for critical package maintainers arrived in 2023, roughly fifteen years after the registry launched. HuggingFace's scanning partnership with JFrog represents meaningful progress, but 21% of models on the platform remain exclusively in pickle format, and the ClawHub incident illustrated how agent skill registries are years behind even HuggingFace's current security posture [8]. In the interim, the process described here is the substitute for infrastructure that does not yet exist.\n\nRun the checklist. Document what you find. Make the risk decision explicit.\n\n## References\n\n[1] Datadog Security Labs, \"LiteLLM and Telnyx compromised on PyPI: Tracing the TeamPCP supply chain campaign,\" *Datadog Security Labs*, Mar. 2026. Available: [https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/](https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/?ref=adversariallogic.com)\n\n[2] BerriAI, \"Security Update: Suspected Supply Chain Incident,\" *LiteLLM Blog*, Mar. 2026. Available: [https://docs.litellm.ai/blog/security-update-march-2026](https://docs.litellm.ai/blog/security-update-march-2026?ref=adversariallogic.com)\n\n[3] C. Krebs, \"SUNBURST Additional Technical Details,\" *Cybersecurity and Infrastructure Security Agency*, Dec. 2020.\n\n[4] S. Samuel, \"xz-utils backdoor situation (CVE-2024-3094),\" *GitHub Gist*, Mar. 2024. Available: [https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27](https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?ref=adversariallogic.com)\n\n[5] PyPI, \"Supply-chain attack analysis: Ultralytics,\" *PyPI Blog*, Dec. 2024. Available: [https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-analysis/](https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-analysis/?ref=adversariallogic.com)\n\n[6] Protect AI, \"ModelScan: Protection against Model Serialization Attacks,\" *GitHub*, 2024–2026. Available: [https://github.com/protectai/modelscan](https://github.com/protectai/modelscan?ref=adversariallogic.com)\n\n[7] JFrog Security Research, \"Data Scientists Targeted by Malicious Hugging Face ML Models with Silent Backdoor,\" *JFrog Blog*, Feb. 2024. Available: [https://jfrog.com/blog/data-scientists-targeted-by-malicious-hugging-face-ml-models-with-silent-backdoor/](https://jfrog.com/blog/data-scientists-targeted-by-malicious-hugging-face-ml-models-with-silent-backdoor/?ref=adversariallogic.com)\n\n[8] Sonatype, \"2026 State of the Software Supply Chain,\" *Sonatype*, 2026. Available: [https://www.sonatype.com/state-of-the-software-supply-chain/introduction](https://www.sonatype.com/state-of-the-software-supply-chain/introduction?ref=adversariallogic.com)\n\n[9] JFrog Security Research, \"JFrog and Hugging Face Join Forces to Expose Malicious ML Models,\" *JFrog Blog*, 2025. Available: [https://jfrog.com/blog/jfrog-and-hugging-face-join-forces/](https://jfrog.com/blog/jfrog-and-hugging-face-join-forces/?ref=adversariallogic.com)\n\n[10] A. Empirical Study Team, \"An Empirical Study of Safetensors' Usage Trends and Developers' Perceptions,\" *arXiv*, Jan. 2025. Available: [https://arxiv.org/pdf/2501.02170](https://arxiv.org/pdf/2501.02170?ref=adversariallogic.com)\n\n[11] Protect AI, \"modelscan,\" *GitHub*, 2024–2026. Available: [https://github.com/protectai/modelscan](https://github.com/protectai/modelscan?ref=adversariallogic.com)\n\n[12] LAION, \"LAION-5B safety statement,\" *LAION Blog*, 2023.\n\n[13] L. Derczynski et al., \"garak: A Framework for Security Probing Large Language Models,\" *arXiv*, Jun. 2024. Available: [https://arxiv.org/html/2406.11036v1](https://arxiv.org/html/2406.11036v1?ref=adversariallogic.com). Software: [https://github.com/NVIDIA/garak](https://github.com/NVIDIA/garak?ref=adversariallogic.com)\n\n[14] CyberArk, \"FuzzyAI: A powerful tool for automated LLM fuzzing,\" *GitHub*, 2024–2026. Available: [https://github.com/cyberark/FuzzyAI](https://github.com/cyberark/FuzzyAI?ref=adversariallogic.com)\n\n[15] U.S. Securities and Exchange Commission, \"Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure,\" *SEC Final Rule*, Jul. 2023.\n\n[16] U.S. Department of the Treasury, \"Specially Designated Nationals and Blocked Persons List (SDN),\" *OFAC*, 2026. Available: [https://ofac.treasury.gov/specially-designated-nationals-and-blocked-persons-list-sdn-human-readable-lists](https://ofac.treasury.gov/specially-designated-nationals-and-blocked-persons-list-sdn-human-readable-lists?ref=adversariallogic.com)\n\n[17] U.S. Department of Defense, \"Cybersecurity Maturity Model Certification (CMMC) Program,\" *32 CFR Part 170*, Dec. 2024.\n\n[18] T. Hunt, \"Have I Been Pwned,\" *haveibeenpwned.com*, 2013–2026. Available: [https://haveibeenpwned.com](https://haveibeenpwned.com/?ref=adversariallogic.com)\n\n[19] PyPA, \"pip-audit: A tool for auditing Python environments and dependency trees for known vulnerabilities,\" *GitHub*, 2021–2026. Available: [https://github.com/pypa/pip-audit](https://github.com/pypa/pip-audit?ref=adversariallogic.com)\n\n[20] T. Christian, \"SpiderFoot: The most complete OSINT collection and reconnaissance tool,\" *GitHub*, 2012–2026. Available: [https://github.com/smicallef/spiderfoot](https://github.com/smicallef/spiderfoot?ref=adversariallogic.com)\n\n[21] NIST, \"CVE-2023-47248: Deserialization of Untrusted Data in Apache Arrow PyArrow IPC,\" *National Vulnerability Database*, Nov. 2023. Available: [https://nvd.nist.gov/vuln/detail/CVE-2023-47248](https://nvd.nist.gov/vuln/detail/CVE-2023-47248?ref=adversariallogic.com)", "url": "https://wpnews.pro/news/vetting-the-black-box-a-supply-chain-due-diligence-framework-for-ai-and-ml", "canonical_source": "https://adversariallogic.com/vetting-the-black-box-a-supply-chain-due-diligence-framework-for-ai-and-ml/", "published_at": "2026-06-30 22:00:43+00:00", "updated_at": "2026-06-30 22:25:19.724484+00:00", "lang": "en", "topics": ["ai-safety", "ai-infrastructure", "ai-policy", "developer-tools"], "entities": ["LiteLLM", "Datadog Security Labs", "TeamPCP", "PyPI", "Trivy", "GitHub Actions", "SolarWinds", "Ultralytics"], "alternates": {"html": "https://wpnews.pro/news/vetting-the-black-box-a-supply-chain-due-diligence-framework-for-ai-and-ml", "markdown": "https://wpnews.pro/news/vetting-the-black-box-a-supply-chain-due-diligence-framework-for-ai-and-ml.md", "text": "https://wpnews.pro/news/vetting-the-black-box-a-supply-chain-due-diligence-framework-for-ai-and-ml.txt", "jsonld": "https://wpnews.pro/news/vetting-the-black-box-a-supply-chain-due-diligence-framework-for-ai-and-ml.jsonld"}}