Vulnerability

LLM Supply Chain Vulnerabilities
detect, understand, remediate

LLM supply chain vulnerabilities (OWASP LLM03:2025) are the class where an attacker compromises the artefacts and tooling that flow into a deployed LLM feature: the foundation model checkpoint, the fine-tuned weights, the LoRA adapter, the embedding model, the tokenizer, the model card, the inference SDK, the model server runtime, the plugin or tool package, the training pipeline, and the deployment artefact. The damage is rarely the model. The damage is the integrity envelope around every artefact the team did not author but the team has to ship anyway.

Get Started Free

No credit card required. Free plan available forever.

Severity

High

CWE ID

CWE-1357

OWASP Top 10

LLM03:2025 - Supply Chain

CVSS 3.1 Score

9.0

What are LLM supply chain vulnerabilities?

LLM supply chain vulnerabilities are the class of weaknesses an attacker exploits through the artefacts and tooling that flow into a deployed LLM feature: the foundation model checkpoint, the fine-tuned weights, the LoRA or adapter file, the embedding model, the tokenizer, the model card and dataset card, the inference SDK, the model server runtime, the plugin or tool package the agent loads, the training-pipeline tooling, the evaluation harness, and the deployment artefact (container, init script, model loader). The OWASP GenAI Security Project lists the class as LLM03:2025 Supply Chain in the 2025 Top 10 for LLM Applications. The attacker does not need to reach the running model. The attacker compromises an artefact upstream (a public Hugging Face checkpoint with embedded code, a poisoned LoRA adapter on a community registry, a tampered tokenizer file, an inference SDK with a known CVE, a model loader that deserialises a pickle file without validation, a plugin manifest that ships a malicious dependency) and the planted code runs the moment the team pulls the artefact into a build, a CI evaluation, a fine-tune job, or a production serving worker.

LLM03 sits beside the other LLM Top 10 disclosure and integrity classes and the classical software supply chain classes. The data and model poisoning page (LLM04) covers the case where an attacker writes content into the training, fine-tune, or retrieval corpus to bias model output: the threat surface is the data the model reads. LLM03 covers the case where the threat surface is the artefact itself: the bytes of the checkpoint, the entry point of the model loader, the dependency tree of the inference SDK, the integrity of the LoRA adapter, the publisher attestation on the model card. The sensitive information disclosure page (LLM02) covers the inference-side data egress class. The model extraction attack page covers the outbound model-stealing and membership-inference class. The vulnerable and outdated components page (OWASP A06:2021) and the vulnerable dependencies page cover the classical software supply chain. LLM03 extends those disciplines to the artefacts that did not exist before generative AI: the foundation model, the fine-tune, the LoRA adapter, the embedding model, the tokenizer, the model card, the dataset card, the safetensors or GGUF or pickle file format, the model-loader entry point, and the AI SDK dependency chain that sits between the application and the model.

For internal AppSec, product security, ML platform, MLOps, security engineering, vendor risk, AI governance, and GRC teams, the operating reality is that any LLM feature ships through a chain of artefacts the team did not author. Each link in that chain is a control point. The fix is rarely a single guardrail. It is a stack: pin every artefact by source and content hash, verify publisher signatures before load, restrict the registries the build is allowed to pull from, scan the inference SDK and model server runtime for known CVEs, refuse model file formats that execute code on load, gate every fine-tune through an approval workflow with named provenance, isolate plugin and tool packages with explicit allow-lists, and pair every release with a supply-chain regression that re-verifies the integrity envelope of every artefact in the serving stack.

The class shows up in regulator inquiries the moment an AI feature ships to a customer. The EU AI Act Article 15 cybersecurity requirements read directly against artefact provenance, integrity, and resilience for high-risk systems. NIST AI RMF Map, Measure, and Manage all read against the AI supply chain inventory and the integrity controls the team operates. ISO/IEC 42001 Annex A controls cover AI lifecycle, third-party risk, and accountability for AI artefacts. OWASP AISVS chapters cover model-and-component supply chain. NIST SP 800-218A SSDF for AI and NIST SP 800-218 SSDF for software both require artefact provenance and integrity for the items the system ingests. Auditors will ask three questions: what AI artefacts ship into your inference stack, what controls verify the integrity of those artefacts, and what evidence shows the controls actually run on every release. The answers live on the finding, not in a slide deck.

The LLM supply chain surface

Foundation model and fine-tuned checkpoint

The base model from a public registry (Hugging Face, vendor model hub, internal mirror) plus any fine-tuned variant the team trained or downloaded. The artefact is a multi-gigabyte file. The bytes carry the weights, but the file format can also carry code that runs on load: pickle files execute arbitrary Python at deserialisation, custom safetensors loaders may read metadata as code, GGUF readers shipped with model servers have had CVE history. The artefact identity is the file hash, the publisher signature, the model card pointer, and the licence record.

LoRA, adapter, and quantised variant

A small file that modifies a base model behaviour. LoRA adapters, quantised variants (GPTQ, AWQ, GGUF Q4_K_M), and merged checkpoints typically come from community contributors. The artefact may be a few megabytes, easy to share, and trivial to swap. A planted adapter that activates a behavioural trigger on a specific token sequence does not need a foundation-model-level compromise; the adapter alone is enough.

Embedding model and tokenizer

The pieces that turn text into vectors and back. Embedding models ship as model files with the same integrity question as the foundation model. Tokenizers ship as JSON or binary files that the runtime trusts to map token IDs back to text. A tampered tokenizer can re-route specific token IDs, leak chosen substrings, or break the safety filter the application code relies on without changing a line of application source.

Model card, dataset card, and licence

The structured documentation that ships alongside the artefact. The model card declares training data, evaluation results, intended use, limitations, and known risks. The dataset card declares provenance, licence, and content classes. A model card that misrepresents training data, omits known risks, or claims a licence that does not apply transfers the legal and security risk to the consumer without warning. The card is part of the supply chain, not metadata around it.

Inference SDK and model server runtime

The runtime stack between the application and the model: the inference SDK (Anthropic, OpenAI, vendor SDK, open-source clients), the local model server (vLLM, TGI, llama.cpp, Ollama, LM Studio backends, Triton), the orchestration helper, the tool-call library, and the agent framework. Each ships dependency trees of its own, each can carry CVEs, and each can ship a vulnerable transitive package that lands inside the production serving worker.

Plugin, tool, and extension package

The packages the agent loads to call external tools. A plugin manifest, a function-calling tool registry, a Model Context Protocol server package, or a community plugin distribution lists code the agent will run during a session. A compromised plugin executes inside the agent context with whatever credentials and network access the agent holds. The plugin is supply chain even when the agent never reaches a model.

Training pipeline tooling and evaluation harness

The build tools the team operates: the fine-tune script, the data-preparation pipeline, the evaluation harness (lm-evaluation-harness, custom evaluation packs), the experiment tracker, and the artefact uploader. Compromise here turns a clean dataset into a tainted artefact, a passing evaluation into a misleading pass, or a fine-tune into a tampered checkpoint uploaded to the registry as if it were clean.

Deployment artefact and serving container

The final shape that runs in production: the container image, the deployment manifest, the init script, the model-loader entry point, and the runtime configuration. A base image with a poisoned dependency, an init script with a piggybacked download step, or a model-loader entry point that pulls an artefact from a writable cache replaces the integrity envelope at the last step before serving.

How it goes wrong

Checkpoint pulled from a public registry without integrity verification

The deployment pipeline pulls a model file from a public registry, copies the bytes, and loads them into the serving worker. No content-hash check runs against a known good value. No publisher signature verification runs against a pinned public key. A substituted checkpoint, a typosquatted repository name, or a hijacked publisher account serves traffic until somebody notices model behaviour drift.

Pickle or unsafe model file format loaded without sandboxing

The model loader reads a pickle file (a PyTorch state_dict in pickle form, an older checkpoint format, a legacy artefact) and deserialises arbitrary Python. The pickle ran arbitrary code at load time, the load step executes with whatever credentials the serving process holds, and the team did not notice because the model also loads and serves traffic as expected.

LoRA adapter or quantised variant from a community contributor

An engineer downloads a LoRA adapter or a quantised variant of a popular model from a community registry to save time. The adapter or the quant carries a behavioural trigger that activates on a specific token sequence: a refusal bypass, an output redirect, a credential-leak prompt, or a tool-call hijack. The team evaluates the merged model on a generic test set, the trigger does not appear, and the artefact ships.

Tokenizer file replaced or tampered with

The deployment artefact ships a tokenizer JSON or binary that does not match the upstream publisher. The replacement re-routes specific token IDs, alters byte-level encoding, or breaks the safety filter that the application relies on. The application code looks unchanged, but the input pipeline silently behaves differently for the chosen token classes.

Inference SDK or model server with an unpatched CVE

The application stack pins an old version of the inference SDK, the local model server (vLLM, TGI, llama.cpp, Triton), or the tool-call library. A published CVE affects request parsing, model loading, model-output handling, or the management API. The CVE is in a dependency chain the team did not realise reached production because the dependency was pulled transitively rather than declared directly.

Plugin or tool package with a malicious dependency

The agent loads a plugin, a function-calling tool, or a Model Context Protocol server package the engineering team picked from a community list. The plugin declares a small set of capabilities but transitively pulls a dependency that exfiltrates environment variables on first import, opens a callback channel, or rewrites a config file. The plugin works as advertised and the rest happens silently.

Training-pipeline tool or evaluation harness compromise

The fine-tune pipeline pulls a community evaluation harness, an experiment-tracker SDK, or a data-preparation utility from a public registry. The utility is tampered with at the registry, or a maintainer account is hijacked, or a malicious release is published to a typosquat. The fine-tune runs cleanly on the data, but the artefact upload step replaces the produced checkpoint with a tampered file before it reaches the registry.

Model card or dataset card misrepresentation

The model card claims training data and licence that do not match the actual artefact. The dataset card omits known PII, copyright-encumbered content, or content that requires consumer disclosure. A consumer team adopts the model on the strength of the card and ships a customer-facing feature against an artefact that the legal, privacy, and GRC functions would have blocked if the documentation had been honest.

No allow-list of registries or publishers

The build pipeline can pull from any public registry, any community repository, any Hugging Face account, any PyPI namespace, and any container image source. There is no allow-list of approved publishers, no per-namespace policy, and no content-hash pin in the build manifest. Any engineer who needs a model, an adapter, or a plugin pulls the most accessible artefact rather than the most trustworthy one.

Supply chain regression is not re-run on every release

A model upgrade, a new fine-tune publication, an inference SDK bump, a model server update, a new plugin adoption, or a refactored deployment manifest re-opens a closed supply-chain finding. The team has no CI gate that re-runs the artefact integrity checks against the new set. The regression slips into production and the next incident is found by a third-party scanner or an external researcher.

Common causes

Treating model artefacts as inert data

The team treats a checkpoint as a static binary blob and a tokenizer as a JSON map. The reality is that model file formats can carry executable code (pickle), and tokenizer files are trusted by the runtime to map input tokens to text. Both are artefacts that need the same supply chain rigour as a compiled library: hash pin, signature verify, source allow-list, change record.

No inventory of AI artefacts in production

The team can list its production application dependencies but cannot list the foundation model, the fine-tunes, the LoRA adapters, the embedding model, the tokenizer, the inference SDK, the model server, the plugin set, and the model card pointers that actually ship into serving workers. Without the inventory there is no control surface to apply.

Pulling from any registry the build host can reach

The build infrastructure has outbound access to any public registry, any community repository, any model hub account, and any package index. There is no allow-list of approved namespaces, no per-namespace policy, and no content-hash pin in the manifest. The path of least resistance becomes the path of compromise.

Model loaders that deserialise untrusted code

A model loader accepts a pickle file, an older PyTorch state_dict, a legacy custom format, or a model file with custom code that the loader silently executes during load. The team picked the loader for performance or convenience and inherited a deserialisation surface that has CVE history.

Fine-tune approvals that do not record provenance

A fine-tune job runs from a shared bucket or a script someone wrote. There is no named approver, no recorded provenance for the base model, the fine-tune dataset, the training script version, the evaluation set, and the publisher of the resulting artefact. Once the artefact is published to the internal registry it looks the same as any other approved checkpoint.

Plugins and tools adopted without security review

An engineer adopts a community plugin, a Model Context Protocol server, an agent framework extension, or a tool-call library because it solves a problem in a sprint. The plugin enters the production agent context with whatever credentials and network access the agent holds. There is no review of the plugin source, the plugin dependency tree, the plugin publisher reputation, or the plugin update channel.

How to detect it

Automated detection

SecPortal code scanning runs Semgrep SAST and dependency analysis against connected GitHub, GitLab, and Bitbucket repositories. Findings surface in model-loader call sites that deserialise untrusted formats, build manifests that pull AI artefacts from any registry without a content-hash pin, inference SDK and model server pins that lag behind published CVEs, and tool-call or plugin registrations that load packages from unallow-listed namespaces
External scanning enumerates exposed inference endpoints, public model-server admin surfaces, leaked artefact directories, accidentally public model registries, and debug routes that disclose the inference SDK version or the model server build, so a publicly visible supply chain gap (unpatched model server, exposed management API, version banner pinned to a vulnerable build) lands as a finding before an external researcher writes the writeup
Authenticated scanning drives the deployed AI feature with probes against the agent tool path: requests that exercise the plugin or tool registry, requests that try to invoke a plugin outside the documented allow-list, requests that exercise the agent network access boundary, and requests that test the model-server management plane for any plugin-or-tool registration surface that bypasses authentication
Continuous monitoring re-runs the artefact integrity check on the configured cadence. A model upgrade, a new fine-tune publication, an inference SDK bump, a model server update, a plugin adoption, or a deployment manifest change that re-opens a previously closed supply chain finding surfaces against the baseline rather than waiting for the next supply-chain audit
Bulk finding import accepts CSV intake from dedicated AI artefact scanners, model file format scanners, model card validators, AI BOM generators, and software composition analysis tools that emit AI-aware output, so external scanner results land on the same engagement record as the SecPortal-driven probes with one CVSS 3.1 calibration applied across the LLM03 finding chain

Manual testing

Produce the AI artefact inventory for the feature: the foundation model and version, the fine-tunes, the LoRA adapters, the embedding model, the tokenizer, the inference SDK and version, the model server and version, the agent framework, the plugin and tool registrations, and the deployment artefact (container image and tag), with a hash pin and a source registry reference per entry
Walk the build pipeline and confirm a content-hash pin and a publisher signature verification step exist at every artefact pull. Pull a known mismatch (a wrong hash, an unsigned artefact, a typosquatted namespace) into a build branch and confirm the pipeline blocks before the artefact reaches a deployable bundle
Review the model-loader code path and confirm the loader refuses unsafe file formats (raw pickle without sandboxing, custom formats that execute code on load). If the application has a legacy model in pickle form, confirm the load step runs in an isolated process with no production credentials and no production network access
Review every LoRA, adapter, quantised variant, and merged checkpoint in production for source, publisher attestation, hash pin, and security review record. Replay the inventory against a known list of upstream changes since the last review and surface every artefact that moved without a recorded approval
Validate the model card and dataset card for every artefact. Confirm the declared training data, the declared licence, the declared known risks, and the declared evaluation evidence match the upstream publisher record and the engineering team understanding of how the artefact is used
Walk the inference SDK, the model server, the orchestration helper, the tool-call library, the agent framework, and the experiment-tracker SDK against the current CVE feed. Record every transitive dependency with an unpatched CVE that reaches the production serving worker
Review every plugin, tool, and Model Context Protocol server package the agent loads. Confirm an explicit allow-list, a per-plugin source review, a per-plugin dependency review, a per-plugin publisher attestation, and a documented update channel for each entry

How to fix it

Produce and maintain an AI artefact inventory for every feature

List the foundation model and version, the fine-tunes, the LoRA adapters, the embedding model, the tokenizer, the inference SDK, the model server, the agent framework, the plugin and tool registrations, and the deployment artefact. Each entry carries a content hash, a source registry reference, a publisher attestation pointer, a model card or dataset card pointer, and a named owner. The inventory is the anchor every other LLM03 control reads against.

Pin every artefact by content hash and verified source

The build manifest names a content hash for every model file, adapter, tokenizer, plugin, and container image. The pull step verifies the hash against the manifest before the artefact lands in the build. A mismatch fails the build. A new upstream release requires an explicit manifest update with a recorded approver.

Verify publisher signatures and refuse unsigned artefacts

Pull only from publishers that sign their artefacts (Sigstore cosign, vendor signing keys, model registry attestation). The pull step verifies the signature against a pinned public key. Unsigned artefacts and artefacts signed by a key outside the pinned set are blocked. The list of acceptable signing keys is managed change-control, not a default.

Allow-list registries and publisher namespaces

The build pipeline can pull only from approved registries and approved publisher namespaces. Public Hugging Face accounts, community PyPI namespaces, GitHub release pages, and container registries are allow-listed per namespace, not per repository. Any pull from an unlisted source fails the build. The list lives in the operating record and the change history is auditable.

Refuse model file formats that execute code on load

Block raw pickle loads, custom formats that execute code at load time, and any model loader that does not sandbox the deserialisation step. Use safetensors, signed GGUF, or signed ONNX where available. If legacy pickle is unavoidable, load it in an isolated process with no production credentials, no production network, and no shared filesystem with the serving worker.

Patch the inference SDK, the model server, and the tool-call stack on a known cadence

Maintain a CVE feed against the inference SDK, the local model server (vLLM, TGI, llama.cpp, Triton, Ollama, LM Studio), the agent framework, the tool-call library, and the experiment-tracker SDK. Treat each CVE that reaches a production serving worker as a finding with a target close date. Gate the closure on a re-verified artefact integrity envelope rather than only on the SDK version.

Approve fine-tunes through a workflow that records provenance

A fine-tune cannot publish to the internal registry without a named approver, a recorded base model identity, a recorded dataset identity (with a dataset card pointer), a recorded training script version, a recorded evaluation pack result, and a recorded artefact hash on the resulting checkpoint. The approval becomes part of the artefact identity, not metadata attached afterwards.

Validate the model card and dataset card before adoption

For every external model, fine-tune, adapter, or dataset adopted, validate the model card and dataset card against the engineering, legal, privacy, and GRC functions. The card has to declare training data, licence, known risks, and evaluation evidence in a form that the consumer team can read against its own use case. Missing or misleading cards block adoption.

Gate plugin and tool adoption through an explicit allow-list and review

A plugin, a tool, a function-calling library, an agent framework extension, or a Model Context Protocol server package enters the production agent context only through a documented allow-list. Each entry carries a per-plugin source review, a per-plugin dependency review, a per-plugin publisher attestation, and a documented update channel. New entries require named approval. Removed entries require a documented teardown.

Sign and verify the deployment artefact end to end

The deployment container, the init script, the model-loader entry point, and the runtime configuration are built reproducibly, signed at build time, and verified at deploy time. A deployment that fails signature verification does not serve. The signing key set is managed change-control. The deploy step records the artefact hash and the signature verification result in the operating log.

Run the supply chain regression on every release

A model upgrade, a new fine-tune publication, an inference SDK bump, a model server update, a plugin adoption, a tokenizer change, or a deployment manifest change is a release event that re-runs the canonical artefact integrity envelope check. The release pipeline blocks until the regression passes. The artefact identity and verification result land on the finding record so the closure has evidence rather than a developer assertion.

What this looks like in SecPortal

Finding with the artefact identity and integrity envelope

The finding captures the artefact identity (file name, content hash, source registry, publisher namespace, model card or dataset card pointer, licence record), the integrity check that failed (no hash pin, wrong hash, unsigned, signature outside the pinned key set, deserialisation surface, unpatched CVE in transitive dependency), and the deployment context the artefact reached (build branch, container image tag, serving worker, agent context). AppSec, ML platform, product security, vendor risk, and GRC read the same record the engineering team uses to ship the fix.

Code scanning across model loaders, build manifests, and tool registries

Code scanning runs Semgrep SAST and dependency analysis against connected GitHub, GitLab, and Bitbucket repositories. Findings surface at model-loader call sites that deserialise untrusted formats, build manifests that pull AI artefacts from unallow-listed namespaces or without a content-hash pin, inference SDK and model server pins that lag behind published CVEs, and tool-call or plugin registrations that load packages outside the approved allow-list.

External scanning across exposed AI infrastructure

External scanning enumerates exposed inference endpoints, public model-server admin surfaces, leaked artefact directories, accidentally public model registries, and debug routes that disclose the inference SDK version or the model server build. A publicly visible supply chain gap (unpatched model server, exposed management API, version banner pinned to a vulnerable build) lands as a finding before an external researcher writes the writeup.

Authenticated scanning against the agent tool path

Authenticated scanning drives the deployed AI feature with probes against the agent tool path: requests that exercise the plugin or tool registry, requests that try to invoke a plugin outside the documented allow-list, requests that exercise the agent network boundary, and requests that test the model-server management plane for plugin-or-tool registration surfaces that bypass authentication. Each finding ties the response to the artefact that allowed the call.

Continuous monitoring against artefact drift

Continuous monitoring re-runs the artefact integrity check on the configured cadence. A model upgrade, a new fine-tune publication, an inference SDK bump, a model server update, a plugin adoption, or a deployment manifest change that re-opens a previously closed supply chain finding surfaces against the baseline rather than waiting for the next supply-chain audit.

Bulk import for AI artefact scanners and BOM tooling

Bulk finding import accepts CSV intake from dedicated AI artefact scanners, model file format scanners, model card validators, AI BOM generators, and software composition analysis tools that emit AI-aware output. External scanner results land on the same engagement record as the SecPortal probes with one CVSS 3.1 calibration applied across the LLM03 finding chain.

Document management for the canonical inventory

Document management stores the AI artefact inventory, the allowed-registry list, the allowed-publisher namespace list, the pinned signing key set, the model loader policy, the model card and dataset card per artefact, the fine-tune approval record, the plugin allow-list, the AI BOM, and the regulatory mapping per finding. Each artefact attaches to the finding so the auditor reads the operating record the engineering programme runs against.

Retest after the remediation ships

Once the fix deploys (the build manifest pins the artefact, the publisher signature verifies against the pinned key, the model loader refuses unsafe formats, the inference SDK or model server lands at the patched version, the plugin enters the documented allow-list, or the fine-tune publishes through the approval workflow), a targeted retest replays the integrity envelope check and records the post-fix result on the finding. The finding closes against the evidence rather than against a developer assertion.

AI-assisted writeups within verified scope

AI reports generate the writeup, the executive summary, and the developer-facing reproduction steps from the finding record. The narrative stays within the verified evidence on the finding (the artefact identity, the integrity envelope, the deployment context, the regulatory mapping) and does not invent signing services, sandboxes, or runtime tooling the product does not have.

Compliance tracking pairs the fix to control evidence

Compliance tracking maps LLM03 findings to the controls that read against them: OWASP LLM Top 10 LLM03, OWASP AISVS supply chain chapters, NIST AI RMF Map and Manage, ISO/IEC 42001 AI lifecycle and third-party risk, EU AI Act Article 15 cybersecurity, NIST SSDF PS.1 to PS.3 and PO.5, NIST SP 800-218A SSDF for AI, NIST SP 800-161 cyber supply chain risk, ISO 27001 Annex A 5.20 to 5.23 supplier relationships and A.8.30 outsourced development.

What SecPortal does not do

SecPortal is the operating record where LLM03 supply chain findings, the artefact identities, the integrity envelope results, the model card and dataset card pointers, the AI BOM references, and the deployment context land alongside the rest of the security backlog. The product does not host a model registry, does not sign or verify model artefacts as a managed service, does not proxy traffic to LLM providers, does not execute model loaders in a managed sandbox, does not maintain a third-party AI artefact risk feed, does not generate an AIBOM automatically, and does not act as a software composition analysis engine on the AI dependency tree.

SecPortal does not provide a model training service, a fine-tune service, a model hub, a hosted inference runtime, a managed agent framework, a managed Model Context Protocol gateway, or a signing infrastructure. The product does not ship packaged connectors into Hugging Face Hub, the OpenAI fine-tune API, vendor model hubs, public model registries, Sigstore, in-toto attestation services, container registries (Docker Hub, GHCR, ECR, GCR, ACR), package indices (PyPI, npm, RubyGems, Maven), Jira, ServiceNow, Slack, SIEM, SOAR, or external CMDB systems. The discipline is the engineering practice on top of the operating record: AppSec, product security, ML platform, MLOps, vendor risk, AI governance, and GRC teams write the artefact inventory, the registry allow-list, the publisher signing policy, the model loader policy, the plugin allow-list, the fine-tune approval workflow, and the CI gate that re-runs the supply chain regression on every release.

Compliance impact

OWASP Top 10 for LLM Apps

LLM03:2025 - Supply Chain (foundation model, fine-tune, adapter, embedding model, tokenizer, model card, inference SDK, model server, plugin, deployment artefact)

OWASP AISVS

Component and supply chain controls, model and component provenance, third-party model trust, evaluation evidence, AI artefact integrity

NIST AI RMF

Map, Measure, Manage; Govern - AI artefact inventory, third-party model risk, integrity controls, supply chain evidence

ISO/IEC 42001

AI management system - AI lifecycle, third-party risk, accountability for AI artefacts, AI system testing and validation

PCI DSS

Requirement 6.2 Custom software developed securely; Requirement 6.3 Identify and address vulnerabilities; Requirement 12.8 and 12.9 manage third-party service provider risk

NIST SSDF

PS.1 protect release integrity; PS.2 mechanism to verify release integrity; PS.3 archive and protect each release; PO.5 implement supporting toolchains; PW.4 reuse existing well-secured software

NIST SP 800-161

Cyber Supply Chain Risk Management - third-party software, hardware, and AI artefact risk identification, assessment, and mitigation

ISO 27001

Annex A 5.20 Addressing information security in supplier agreements; A 5.21 Managing information security in the ICT supply chain; A 5.22 Monitoring suppliers; A 5.23 Information security for use of cloud services; A 8.30 Outsourced development

SOC 2

CC2.1 Communications with internal and external parties; CC3.4 Risk identification for vendors; CC9.2 Manage vendor risk; CC8.1 Change management for software releases

Related vulnerabilities

Data and Model Poisoning in LLM Applications

Sensitive Information Disclosure in LLM Applications

Model Extraction Attack

Prompt Injection

Indirect Prompt Injection via RAG

System Prompt Leakage in LLM Applications

Improper Output Handling in LLM Applications

Excessive Agency in LLM Applications

Vulnerable & Outdated Components

Vulnerable & Outdated Dependencies

Insecure Deserialization

Hardcoded Secrets

Related features

Find vulnerabilities before they ship

Vulnerability scanning tools that map your attack surface

Test web apps behind the login

Vulnerability management software that tracks every finding

Monitor continuously catch regressions early

Bulk finding import bring your scanner data with you

Document management for every security engagement

Finding overrides that survive every scan cycle

Verify fixes and track reopens on the same finding record

Compliance tracking without a full GRC platform

Every action recorded across the workspace

Repository connections for SAST and SCA

AI-powered reports in seconds, not days

Track LLM03 supply chain findings against every AI artefact

SecPortal records LLM03 findings against the AI feature, attaches the artefact identity (hash, source registry, publisher, signature, model card pointer), captures the integrity envelope result, generates AI-assisted writeups, and tracks the fix through retest. Start for free.