Using SBOMs to Manage Third-Party Model and AI Dependency Risk in Federal Build Pipelines

Federal software teams have spent the last several years building out SBOM practices for traditional application dependencies. Package managers, container base images, open source libraries, and third-party SDKs are increasingly captured, inventoried, and reviewed as part of CI/CD pipeline controls. That work matters. But a growing category of build-time assets is slipping through the gaps in most of those inventories: AI and ML components.

Pretrained models, inference runtimes, tokenizer packages, model weights, adapter layers, and the Python framework stacks that carry them into production are now embedded in federal application builds. They arrive through pip installs, container layers, model registry pulls, and sometimes direct file downloads from public hubs. They carry licensing terms, provenance questions, and vulnerability exposure that conventional SBOM tooling was not designed to surface. And because they often enter the build through data science workflows rather than traditional software engineering pipelines, they frequently bypass the review gates that govern other third-party components.

This is not a theoretical risk. A containerized inference service built on a public pretrained model may include weights trained on data with restricted use terms, framework dependencies with known CVEs, and wrapper code that was never reviewed by a security team. None of that is visible in a standard software bill of materials unless the team has deliberately extended their inventory practices to capture it.

The good news is that the SBOM infrastructure most federal teams are already building can be extended to cover AI and ML dependencies. It requires deliberate design choices about what to capture, how to represent it, where in the pipeline to enforce review, and who owns the governance decisions. This article walks through that extension in operational terms, focused on build-stage controls rather than runtime monitoring or procurement policy.

What AI and ML Dependencies Enter the Build

Before a team can govern AI and ML dependencies, they need an accurate picture of what actually enters the build environment. The categories are broader than most teams initially expect.

The most visible layer is the Python framework stack. Libraries like PyTorch, TensorFlow, JAX, and their associated CUDA bindings pull in dozens of transitive dependencies. These are standard Python packages and most SBOM tools can enumerate them from a requirements file or a lock file. The problem is that many ML projects do not use lock files consistently, and dependency resolution at build time can produce different package versions across builds if the environment is not pinned. That variability is a supply chain problem independent of anything specific to AI.

The second layer is model artifacts. A pretrained model is not a Python package. It is a binary file, often stored in a model registry or downloaded directly from a public hub. It has a version, a hash, a source, a license, and in some cases a documented training dataset or fine-tuning history. None of that is captured by pip or by standard SBOM generation tools that scan package manifests. The model file itself may be gigabytes in size, but the metadata describing it is what matters for governance.

The third layer is the supporting assets that travel with a model: tokenizer files, vocabulary files, configuration JSON, adapter weights, quantization parameters, and in some architectures, separate embedding layers or retrieval indexes. These assets are often downloaded alongside the model weights but are not tracked as distinct components. They can be modified independently of the base model, which creates substitution risk if the download source is not pinned and verified.

The fourth layer is the inference serving stack. When a model is packaged for deployment, it typically requires a runtime such as ONNX Runtime, TensorRT, Triton Inference Server, or a framework-specific serving library. These runtimes have their own dependency trees, their own CVE exposure, and their own licensing terms. They are often introduced through container base images rather than application-level package management, which means they may not appear in an application-layer SBOM at all unless the team is scanning container images as part of the build process.

Wrapper code and adapters represent a fifth category that is easy to overlook. Many teams write thin Python wrappers around pretrained models to adapt them to application-specific inputs and outputs. These wrappers may pull in additional libraries, call external APIs, or load secondary model files. If the wrapper is developed in-house, it should be treated as first-party code. If it is sourced from a community repository or a model hub alongside the pretrained weights, it should be treated as a third-party component and reviewed accordingly.

What to Capture in an AI and ML SBOM Inventory

Standard SBOM fields cover name, version, supplier, license, and hash for software packages. For AI and ML components, those fields are necessary but not sufficient. Teams need to define an extended set of attributes that captures the information assessors, security reviewers, and mission owners actually need to evaluate risk.

For pretrained models and model weights, the minimum useful inventory record should include the model identifier and version as defined by the source registry, a cryptographic hash of the downloaded artifact, the source URL or registry path, the license under which the model is distributed, and the intended use or task the model was trained for. Where the model provider publishes a model card or documentation describing training data, fine-tuning history, or known limitations, a reference to that documentation should be recorded as companion metadata even if it cannot be embedded in the SBOM document itself.

For tokenizer assets and configuration files, the inventory should capture the file name, version or commit reference if the asset is sourced from a version-controlled repository, a hash of each file, and the relationship to the parent model. These assets should be linked to their parent model record rather than treated as standalone components, because their integrity is only meaningful in the context of the model they support.

For inference runtimes introduced through container images, the inventory should capture the image digest, the runtime library version, and the source registry. If the runtime is installed as a Python package, standard package metadata applies. If it is embedded in a container layer, the team needs container image scanning integrated into the build pipeline to surface it.

Licensing and data-use restrictions deserve specific attention in federal environments. Some pretrained models are distributed under licenses that restrict commercial use, government use, or use in specific application domains. Others carry acceptable-use policies that prohibit certain deployment contexts. These terms are not always surfaced by automated tooling and may require manual review as part of the model approval process. Recording the license identifier and flagging any non-standard terms in the inventory record gives reviewers a starting point rather than requiring them to locate and read the original license documentation for each model.

Representing AI and ML Components in CycloneDX and SPDX

Both CycloneDX and SPDX are capable of representing AI and ML components to varying degrees, but neither format was designed with model artifacts as a primary use case. Understanding where each format helps and where it falls short is necessary before a team decides how to structure their inventory.

CycloneDX Extensions for ML Components

CycloneDX version 1.5 introduced a machine learning extension that allows components to be typed as a machine learning model and includes fields for model card references, algorithm types, and dataset references. This is the most mature format-level support available for model metadata. Teams using CycloneDX should adopt version 1.5 or later and use the ML extension fields for pretrained model records. For model assets that do not fit cleanly into the component model, CycloneDX supports external references and properties that can carry companion metadata without requiring format extensions.

The practical limitation is that most SBOM generation tools do not populate CycloneDX ML extension fields automatically. A team using Syft, Trivy, or similar tools to generate SBOMs from container images or package manifests will get standard component records for Python packages but will not get model-specific records for weight files or tokenizer assets. Those records need to be generated through a separate process, either a custom build step that reads model metadata from the download manifest or registry API, or a manual record that is merged into the SBOM document before it is published.

SPDX and Companion Metadata

SPDX 2.3 and the emerging SPDX 3.0 specification include dataset and AI profile elements that can describe model-related components. SPDX’s relationship model is well suited to expressing the dependency chain between a model, its tokenizer assets, and the application that uses them. However, similar to CycloneDX, tooling support for these profile elements is limited and teams should expect to generate model records through custom pipeline steps rather than relying on automated scanners.

For federal teams operating under existing Software Bill of Materials (SBOM) requirements, the practical approach is to generate a standard SBOM for the application’s software dependencies using existing tooling, and then produce a companion model inventory document that captures AI and ML component metadata in a structured format aligned to CycloneDX or SPDX conventions. The two documents should be linked through a reference in the primary SBOM and stored together in the artifact repository. This approach avoids waiting for tooling to catch up while still producing a machine-readable, reviewable record of all build-time components.

Pipeline Integration and Approval Gates

Capturing AI and ML component metadata is necessary but not sufficient. The metadata needs to feed into review and approval workflows that can block a build or deployment when a component does not meet the organization’s standards. This is where many teams have the most work to do, because the approval workflows for pretrained models are different in character from the workflows for standard software packages.

For Python packages, most teams have some form of allowed-list or vulnerability-gate that checks packages against a known-bad list or a CVE database before allowing them into the build. That same pattern applies to ML framework packages and inference runtime libraries. The tooling already exists. The gap is usually that the ML stack is not being scanned with the same rigor as the application stack, often because it was introduced by a data science team working outside the standard engineering workflow.

For pretrained model artifacts, the approval workflow needs to address several questions that do not apply to standard packages. First, is the model sourced from a registry that the organization has evaluated and approved? Public model hubs vary significantly in their vetting practices, and some allow model uploads with minimal review. An organization that allows developers to pull models from an unevaluated public hub is accepting supply chain risk that is difficult to quantify. Establishing an approved registry list and enforcing it through pipeline policy is the first control.

Second, is the downloaded artifact what it claims to be? Model registries that support content-addressable storage allow teams to pin a model by its hash rather than by a mutable version tag. This is the same pattern used for container image digests. If the registry does not support hash-pinning, the team should download the model artifact, compute its hash, record that hash in the model inventory, and fail the build if a subsequent download produces a different hash. Mutable version tags on model registries are a real substitution risk, particularly for models that are updated frequently by their publishers.

Third, has the model been screened for known malicious behavior? This is an emerging area and tooling is limited, but some model scanning tools can detect serialization exploits in pickle-format model files, which have been used to embed executable code in model weights. At minimum, teams should prefer model formats that do not use pickle serialization for untrusted models and should document the screening steps taken as part of the approval record.

The approval gate itself should produce an attestation record that is stored alongside the model inventory entry. That record should capture who reviewed the model, what criteria were evaluated, when the review was completed, and what the outcome was. When a model is updated, the change should trigger a new review cycle rather than inheriting the previous approval. This is a change management requirement, not just a security one, and it needs to be reflected in the pipeline configuration so that a version bump in the model reference automatically queues a review rather than silently passing through.

Common Mistakes

The most common mistake is treating the ML framework packages as the complete AI dependency inventory. Capturing PyTorch and its transitive dependencies is necessary, but it leaves out the model artifacts, tokenizer files, and inference runtime components that represent a significant portion of the actual supply chain risk. Teams that stop at the package layer have a gap they may not recognize until an assessor or incident response team asks for a complete component inventory.

A related mistake is allowing model downloads to happen outside the controlled build environment. When data scientists pull models to local workstations for experimentation and then commit model files or download scripts to the repository without a formal review step, those models enter the build without any of the governance controls the team has established for other components. The fix is not to restrict experimentation but to define a clear boundary between the experimentation environment and the production build pipeline, with an explicit promotion process that includes model review.

Teams frequently underestimate the licensing complexity of pretrained models. A model distributed under a license that restricts government use or requires attribution may be legally problematic in a federal deployment context, but that restriction is not visible in a CVE scan or a standard SBOM review. License review for model artifacts needs to be a deliberate step in the approval workflow, not an afterthought.

Another mistake is treating model approval as a one-time event. Models are updated by their publishers, sometimes with changes to weights, tokenizer behavior, or license terms. An approval that was valid for version 1.2 of a model does not automatically extend to version 1.3. Without a change trigger in the pipeline that detects version bumps and queues a new review, teams can end up running unapproved model versions in production without realizing it.

Finally, many teams fail to assign clear ownership for AI and ML dependency governance. The security team may assume the data science team is handling model review. The data science team may assume the security team is handling it. The platform engineering team may not know that model artifacts exist outside the package manifest. Without explicit ownership documented in the program’s supply chain risk management plan, governance gaps persist indefinitely.

Recommended Federal Approach

Start with a current-state inventory. Before designing new controls, map every AI and ML component that currently enters any active build pipeline. This includes Python packages, container base images, model artifacts, tokenizer files, and any inference serving components. The goal is to understand the actual scope of the problem before committing to a governance architecture. In most federal environments, this inventory will surface components that no one on the security or architecture team was aware of.

Assign ownership explicitly. The program office, ISSO, and platform engineering team need to agree on who is responsible for maintaining the model inventory, who reviews new model requests, who approves exceptions, and who is accountable when a model needs to be removed from production. Document this in the supply chain risk management plan and reference it in the system security plan. Assessors will ask, and “we handle it informally” is not an acceptable answer in an RMF context.

Define the metadata schema before building pipeline tooling. The schema should specify what fields are required for each component type, what format hashes should be recorded in, how license information should be captured, and how model records should be linked to the primary SBOM document. Getting the schema right before instrumenting the pipeline avoids rework and ensures that the records produced are actually useful for review and audit purposes.

Instrument the pipeline in stages. Start with the highest-risk components: pretrained models downloaded from public sources. Add hash verification and source registry enforcement for those components first. Then extend coverage to tokenizer assets and configuration files associated with approved models. Then address inference runtime components in container images. Trying to instrument everything at once typically results in a partially implemented system that creates false confidence without providing real coverage.

Integrate with existing RMF controls rather than creating a parallel process. Supply chain risk management controls in NIST SP 800-161r1 and the system-level controls in NIST SP 800-53 provide the framework for documenting and assessing AI and ML component governance. The model inventory and attestation records should be referenced in the system security plan as evidence supporting those controls. When the AO or assessor reviews the system, they should be able to trace from the SSP to the model inventory to the approval records without having to ask the team to produce documentation that was never connected to the authorization package.

Plan for sustainment from the beginning. Model governance is not a one-time implementation task. Models are updated, new models are introduced, licenses change, and vulnerabilities are discovered in inference runtimes. The governance process needs to include a recurring review cycle, a mechanism for monitoring model publisher advisories, and a defined response process for when an approved model needs to be replaced. Teams that treat the initial implementation as the finish line will find themselves with an outdated inventory and unapproved components within a few months of going live.