Supply Chain Security

The safetensors format stores raw tensors plus a JSON header and contains no executable code, so loading it cannot run arbitrary code. It also supports lazy and memory-mapped loading, which is why most Hub models now publish it. See Model Formats for the format comparison and Conversion and Quantization for converting an existing checkpoint.

The first snippet derives from the safetensors documentation, the use_safetensors and trust_remote_code arguments from the Transformers model documentation, and weights_only from the torch.load reference. weights_only=True narrows what can be unpickled but the PyTorch documentation still recommends loading only trusted checkpoints, so convert legacy files to safetensors in an isolated environment rather than relying on it.

A Hub repository is a Git repository. A branch name such as main moves; a commit SHA does not. Resolve the SHA once, review or scan that exact revision, record it in configuration, and always download by SHA. The mechanics of repositories and revisions are covered in Hub Essentials.

The calls derive from the huggingface_hub download guide and the HfApi reference. For offline production hosts, download once in CI, store the directory in an internal artefact repository, and set HF_HUB_OFFLINE=1 at runtime so the service can never fetch an unreviewed revision (see Running Local LLMs in Production). Hub datasets and Spaces accept the same revision argument.

Choosing a model is also a supply-chain decision: prefer publishers you can identify, check download history and licence, and read the model card for training data and known limitations (see Choosing Models and Licences). Model and dataset cards are self-reported by the publisher, so they are evidence for a review, not proof; a card that is missing, vague about data sources or lacks an evaluation section is itself a finding.

The Hub scans uploads (malware and pickle import scanning, with partner scanners) and flags suspicious files on the repository page. In your own pipeline, scan before a revision is promoted to the internal store, for instance with ModelScan or picklescan for any pickle-based file, and run the load itself in a sandbox without network access or credentials. Scanning looks for known-dangerous imports; it cannot judge behaviour, so it complements the format and pinning rules above.

An SBOM lists software components; an ML-BOM (also called AI-BOM) extends it with models, datasets and their provenance. CycloneDX supports this natively through the machine-learning-model and data component types and a modelCard object. A minimal, illustrative fragment for the DocsAssistant’s embedding model follows; fields such as hashes would be filled in by the pipeline that downloaded the artefact.

The structure derives from the CycloneDX ML-BOM capability page and the CycloneDX specification; check property names against the schema of the version you emit, since the model card fields have changed between releases.

The OpenSSF model-signing project (1.1.1 at the time of writing) signs a whole model directory using Sigstore: a short-lived certificate bound to an OIDC identity, a signature over a manifest of file hashes, and an entry in a transparency log. Consumers verify that the files they hold match what a named identity signed, which detects tampering in transit or in a mirror. It proves who published the files and that they were not altered; it does not prove the model is benign.

The commands follow the model-transparency README and the Sigstore documentation; flag names have changed between releases, so confirm them with model_signing --help for the installed version. Verification should be a mandatory step in the pipeline that populates the internal model store, and the expected identity belongs in reviewed configuration, not in the artefact being verified.

The DocsAssistant’s Java backend has the same exposure through Maven dependencies and plugins. Maven Central does not verify a signer for you, so the controls are exact versions, enforced rules and an SBOM. The Enforcer plugin below fails the build on unpinned plugins, SNAPSHOT dependencies and conflicting transitive versions, and the CycloneDX plugin emits the SBOM next to the artefact.

The rules derive from the Maven Enforcer built-in rules and the goal from the CycloneDX Maven plugin documentation; the version properties are deliberately left for the project to set to the current releases. Maven has no built-in equivalent of Gradle’s dependency verification file with checksums, so projects that need it combine a private repository manager that proxies and quarantines Central, signed-artefact checks, and the SBOM compared against a vulnerability feed such as OSV or Dependency-Track. Spring AI and LangChain4j version numbers should come from the project’s BOM import, pinned to one reviewed release, rather than from version ranges. The same reasoning applies to container base images: pin by digest and scan as described in Image Best Practices and Security.

When a coding assistant proposes a dependency, check that the name exists, that its publisher and age are plausible, and that it is what you meant, before adding it. Prefer lock files with hashes (pip install --require-hashes, uv lock) and an internal registry mirror that only serves reviewed packages, so a squatted name fails to resolve instead of installing. The developer-toolchain side of this problem is covered in Securing AI-Assisted Development; the output-side risk of the model inventing sources is covered in Misinformation and Hallucination Risk.

A third-party MCP server, plugin or skill extends the model’s capabilities and its attack surface at once, and its tool descriptions are read by the model as instructions. Controls that hold up in practice are:

Agent-level consequences, including cascading effects between tools and agents, are discussed in Excessive Agency and Tool Security and OWASP Top 10 for Agentic Applications, where the supply chain is ASI04.