Most teams treat an LLM application as a model plus a prompt. The model is one component, and it is far from the only one. An LLM application depends on base model weights, fine-tuning data, embeddings, a vector store, and a stack of packages around all of it. Each of those has an origin, a maintainer, and a failure mode you inherit whether or not you looked. The research community has spent the past two years mapping this ground, and the picture that emerges is not reassuring for anyone who thought the model card told the whole story.
The academic framing is blunt. Existing work assures the quality of an LLM at the model level, and security assurance for the entire supply chain is ignored, so vulnerabilities in third-party dependencies or deployment environments still produce an unreliable system even when the model itself is sound (Hu et al., 2024). That is the gap this post works through: what to inventory, what to verify before adoption, and which failures earn a control rather than a mention in a risk register.
The dependency graph is deeper than the model card
Start with scale, because scale is what makes the manual approach fail. When researchers built a benchmark from real Hugging Face applications, a set of 3,859 LLM applications pulled in 109,211 models, 2,474 datasets, and 8,862 libraries once dependencies were traced (Ma et al., 2025). That ratio is the whole argument. An application does not depend on one model. It depends on the model it names, the model that was fine-tuned to produce it, the datasets that trained both, and the libraries every step relied on.
The same benchmark extracted risk-related issues across those components. Libraries carried 1,229, models 325, applications 50, and datasets 18 (Ma et al., 2025). The counts are not measured the same way. The library figure comes from CVE databases. The model, dataset, and application figures are hand-validated user reports, and the authors read the gap as evidence that models and datasets lack a CVE-equivalent registry rather than that they carry less risk. What the distribution does establish is that the package layer is the one where recorded, actionable issues already exist, and it is the layer your existing software supply chain tooling was built to see.
Figure 1: Of 1,555 recorded risk issues, libraries carry 1,229 against 325 for models, 50 for applications and 18 for datasets. The paper draws all four from public vulnerability databases and repositories.
The finding that applications involve complex and deeply nested dependencies is the reason an inventory cannot be assembled by reading documentation (Ma et al., 2025). You need the transitive graph, the same way you need it for any package manager, extended to cover models and datasets as first-class artifacts rather than opaque blobs.
What enters the chain, and how
The useful contribution from the composition research is that supply relationships in an LLM chain are more varied than in traditional software. Upstream artifacts arrive as source code, binary executables, or serialized models, and they arrive through augmentation relationships for data, cloning relationships for code, and merging relationships for models (Huang et al., 2025). A merged model is not a version bump. It is two lineages combined, and the provenance of both flows into what you deploy.
There are three ways a team obtains a model, and each carries a different inventory burden. A model can be built from scratch, downloaded from an open hub and used directly, or downloaded and fine-tuned for a specific task (Hu et al., 2024). The second and third paths are where most enterprises live, and both make you a downstream consumer of decisions you did not witness. Fine-tuning in particular embeds new data into the weights, which means the fine-tuning dataset is a dependency with the same standing as the base model.
The supply chain also carries special dependencies that traditional software does not, including models that embed external knowledge such as data or code, layered on reliance on third-party data sources, libraries, proprietary frameworks, and cloud providers (Huang et al., 2025). Embeddings and vector stores sit here. An embedding model is itself a downloaded artifact with a lineage, and the store it populates becomes a dependency the moment retrieval feeds model output.
The failures worth a control
Not every risk earns a control. The OWASP supply chain entry gives a working shortlist, and it maps cleanly onto artifacts you can name. Traditional third-party package vulnerabilities appear first, mirroring the long-standing problem of vulnerable and outdated components, with elevated stakes when those components run during model development or fine-tuning (OWASP, 2025). This is the 1,229-issue layer again, and it is the one where your existing scanners already work.
Model provenance is the failure that has no clean traditional analog. There are no strong provenance assurances in published models, and model cards are relied upon by users while offering no guarantee of origin, which lets an attacker compromise a supplier account or stand up a lookalike repository and combine it with social engineering (OWASP, 2025). A pre-trained model is a binary black box where static inspection offers little assurance, so a poisoned or tampered model can carry hidden backdoors past a repository's own safety evaluation (OWASP, 2025).
The fine-tuning layer introduces its own control surface. A malicious LoRA adapter can compromise the integrity of the base model it attaches to, and because deployment platforms support downloading and applying adapters to a running model, the adapter is an injection point independent of the model itself (OWASP, 2025). Collaborative development compounds this. Model merging is popular enough that merged models top open leaderboards, and the merge and conversion services hosted in shared environments have been shown to introduce vulnerabilities and even malicious code into shared models (OWASP, 2025).
Data poisoning is the failure that runs upstream of everything. If poisoned data enters the chain unintentionally, the result is model performance degradation (Huang et al., 2025). The threat is not theoretical. Poisoning attacks on open-source models have produced toxic outputs, and malicious models uploaded to public hubs have bypassed security scans, putting downstream applications at risk (Ma et al., 2025).
Licensing deserves a place on the list even though it is not an attack. Diverse software and dataset licenses create legal exposure when unmanaged, and dataset licenses in particular can restrict usage, distribution, or commercialization in ways that surface only after adoption (OWASP, 2025).
Figure 2: The benchmark's four component counts on one axis. Models reach 109,211 against 3,859 applications, and that distance is why enumeration by hand fails. Source: LLMSCBench.
What to verify before adoption
The mitigations from that same composition work translate into pre-adoption checks. Use secure delivery channels from an identified contributor to prevent untrusted modifications, and establish automated model and library updates so vulnerabilities close promptly rather than lingering (Huang et al., 2025). Both are ordinary supply chain hygiene applied to artifacts your process may not currently treat as artifacts.
The inventory itself is the first control. You cannot verify provenance on a model you have not enumerated, and the benchmark scale shows enumeration by hand does not survive contact with the transitive graph (Ma et al., 2025). Treat model weights, fine-tuning datasets, embedding models, vector store contents, and every package as line items with an origin and a maintainer. For each, record where it came from, who can change it, and what happens downstream if it is wrong.
The practical sequence is short. Enumerate the full dependency graph including transitive models and datasets. Verify provenance and delivery channel for each named model and adapter before it enters a build. Scan the package layer with the tools you already run, because that is where the recorded issues concentrate. Check dataset and model licenses against your intended use. Then decide which of these you monitor continuously rather than once, because provenance and package risk both drift after adoption.
The honest limits
Provenance verification is weak precisely because the ecosystem gives you little to verify against. Model cards carry no origin guarantee, and a black-box binary resists static inspection (OWASP, 2025). The control you can apply today is delivery-channel integrity and identified contributors, not cryptographic proof of what a set of weights contains. That is a real gap, and pretending otherwise is how a lookalike repository wins. The value of an inventory is that it tells you exactly where you are exposed, which is the precondition for every control that follows.