# TAIBOM: Bringing Trustworthiness to AI-Enabled Systems
**Authors**: Vadim Safronov0009-0005-6431-, Anthony McCaigue0009-0008-8679-, Nicholas Allott0000-0001-7473-, Andrew Martin0000-0002-8236-980X
> Corresponding Author. Email:
> University of Oxford NquiringMinds
## Abstract
The growing integration of open-source software and AI-driven technologies has introduced new layers of complexity into the software supply chain, challenging existing methods for dependency management and system assurance. While Software Bills of Materials (SBOMs) have become critical for enhancing transparency and traceability, current frameworks fall short in capturing the unique characteristics of AI systems — namely, their dynamic, data-driven nature and the loosely coupled dependencies across datasets, models, and software components. These challenges are compounded by fragmented governance structures and the lack of robust tools for ensuring integrity, trust, and compliance in AI-enabled environments.
In this paper, we introduce Trusted AI Bill of Materials (TAIBOM) — a novel framework extending SBOM principles to the AI domain. TAIBOM provides (i) a structured dependency model tailored for AI components, (ii) mechanisms for propagating integrity statements across heterogeneous AI pipelines, and (iii) a trust attestation process for verifying component provenance. We demonstrate how TAIBOM supports assurance, security, and compliance across AI workflows, highlighting its advantages over existing standards such as SPDX and CycloneDX. This work lays the foundation for trustworthy and verifiable AI systems through structured software transparency.
123
## 1 Introduction
The rapid expansion of open-source software and AI-driven technologies has introduced unprecedented complexity into the software supply chain. Managing dependencies is already a challenging task, but the integration of AI with digital infrastructures further amplifies the difficulty [24, 16]. In response, Software Bills of Materials (SBOMs) have emerged as a mechanism for improving accountability and traceability across software ecosystems [4, 10].
While various organisations, researchers, and developers acknowledge the growing importance and usefulness of SBOMs, the absence of mature tools for their generation and application in assurance, security, and compliance remains a significant gap [24, 28, 29]. This challenge is particularly significant in AI-enabled systems, where traditional SBOM frameworks struggle to accommodate AI-specific complexities. AI models are inherently dynamic and data-driven, continuously evolving through updates and retraining. Ensuring stability and version control is a persistent challenge. Furthermore, AI systems comprise multiple interdependent components — training datasets, training software, refinement datasets, trained weights, inference software — that are often loosely coupled, making dependency tracking and provenance verification difficult. The governance of AI systems is also complicated by their distributed nature, where data ownership, model training, and system deployment often reside with different entities, making the enforcement of security, privacy, and safety standards particularly challenging.
Although there is much interest in Trust in AI [5, 22, 13], much of the discussion is predicated on the accurate identification of (and so tamer-proofing of) all these diverse aforementioned elements, which in turn raises several challenging questions. Can the integrity of model producers be verified? Can datasets — often assembled from multiple sources — be trusted? Can transparency and accountability be ensured throughout the AI development pipeline?
To address these challenges, we introduce the Trusted AI Bill of Materials (TAIBOM) — an evolution of SBOM frameworks extended to AI-enabled software systems. TAIBOM is accompanied by an implementation toolkit https://github.com/nqminds/Trusted-AI-BOM/, designed to support its principles. The key contributions of TAIBOM are:
- A structured dependency model that conceptualises AI software components and their interrelationships.
- A framework for propagating integrity statements across disconnected AI environments (e.g., dataset, training, and inference), ensuring a continuous chain of trust.
- A trust attestation mechanism to verify the provenance and trustworthiness of AI components.
This paper is organised as follows. Section 2 overviews SBOMs and motivates the need for AIBOMs. Section 3 reviews related work, identifies limitations in existing AIBOM standards regarding trust guarantees, and outlines how TAIBOM addresses them. Section 4 presents the TAIBOM dependency model and its component relationships. Section 5 demonstrates TAIBOM’s integration into AI workflows across assurance, security, compliance, and risk management use cases, and compares its functionality to state-of-the-art AIBOM approaches. Section 6 discusses current limitations and future directions. Section 7 concludes the paper.
## 2 Background
To introduce the need for trust in AI-enabled systems, this background section reviews the concept of Software Bills of Materials (SBOMs), their role in traditional software supply chains, and how they inform the emerging notion of AI-specific Bills of Materials (AIBOMs).
### 2.1 Software Bill of Materials
The Software Bill of Materials (SBOM), inspired by manufacturing industry practices, was formalised in 2018 by the US National Telecommunications and Information Administration (NTIA) to enhance software security practices and has since evolved [26]. An SBOM provides a detailed inventory of software components, specifying their origins, dependencies, and references to known or potential vulnerabilities. Key elements in the SBOM ecosystem include the Common Platform Enumeration (CPE, a standardised naming scheme for software components [20]), Common Vulnerabilities and Exposures (CVE, a repository of publicly disclosed cybersecurity vulnerabilities [21]), and Common Weakness Enumeration (CWE, a classification system for software weaknesses [6]).
SBOMs ensure that all software components are identified and traceable. However, concerns remain about their granularity. Various SBOM generation approaches have emerged. Binary-focused tools [12, 8, 14] analyse compiled binaries using embedded metadata, string literals, and language-specific features to identify dependencies. Metadata-based tools [2, 18, 3] extract dependency information from package metadata, build files, and container images. Source code analysis tools [25, 15, 27] inspect repositories to uncover dependencies, including hidden ones associated with known CVEs.
### 2.2 AI Bill of Materials
While existing SBOM approaches are suitable for traditional software, they fall short in addressing vulnerabilities specific to AI-enabled systems. Some argue that AI is merely another category of software and can be managed under current SBOM regulations. However, recent research suggests otherwise, highlighting a growing demand for an AI Bill of Materials (AIBOM) capable of describing and tracing AI-specific dependencies [28, 17].
AI software comprises traditional software components alongside AI-specific artifacts such as training data, model configurations, and inference pipelines. Unlike conventional software, AI systems evolve continuously (e.g. in response to data drift and concept drift) necessitating dynamic co-versioning registries to ensure transparency and accountability. Unlike static SBOM inventories, AI Bills of Materials (AIBOMs) must support traceable, evolving records without requiring frequent regeneration.
## 3 Related Work
This section reviews existing AIBOM proposals and discusses how the proposed TAIBOM approach addresses their limitations in establishing verifiable trust within AI software supply chains.
### 3.1 Existing AIBOM Proposals
Several AIBOM solutions have been proposed. Model cards, such as those by Hugging Face [11] and Google [19], provide metadata on datasets and models but lack comprehensive provenance tracking (e.g., training data lineage or tampering history). SBOM extensions, including CycloneDX [7] and SPDX [23], adapt existing SBOM formats for AI, yet their trust guarantees remain limited and often unverifiable. ML-specific tools such as DVC [9] and MLflow [1] support lineage tracking for AI models but do not enforce verifiable trust mechanisms across the full AI development pipeline.
A more detailed comparative evaluation of these approaches, including their support for provenance, tamper detection, and dependency analysis, is presented in Section 5.
### 3.2 TAIBOM: A Trustable AIBOM Solution
Existing AIBOM solutions lack trust guarantees — there are no established techniques to verify dataset provenance or ensure model integrity throughout the AI workflow. TAIBOM addresses this gap by introducing a trust-enabled AIBOM data model that represents key AI artifacts (including Data, Code, and AI System objects) along with their interconnections and trust relationships. As detailed in Section 4, TAIBOM integrates cryptographic attestations, integrity verification, and dataset provenance tracking to establish verifiable trust across AI-enabled software supply chains. By design, TAIBOM adopts a general and extensible structure to accommodate a wide range of AI-enabled software systems — including those incorporating frontier AI such as Large Language Models (LLMs) and other forms of generative AI.
## 4 TAIBOM Architecture
The main purpose of TAIBOM is to provide a structured and verifiable framework for managing trust in AI software components, ensuring their provenance, integrity and traceability across the entire AI software lifecycle.
<details>
<summary>figures/TAIBOM_data_model.png Details</summary>
### Visual Description
\n
## Diagram: System Component Relationships
### Overview
This diagram depicts the relationships between various components in a system, likely related to machine learning or AI model development and deployment. It uses a UML-like class diagram notation to show inheritance, composition, aggregation, and creation relationships between entities like Data, Code, TrainingData, and InferenceSystem. The diagram is oriented with the primary data flow appearing to move from the top to the bottom.
### Components/Axes
The diagram consists of rectangular boxes representing components, connected by arrows indicating relationships. The arrowheads denote the type of relationship:
* **Inherits:** A solid arrow with a hollow arrowhead.
* **Creates:** A dashed arrow with a hollow arrowhead.
* **Compose:** A solid arrow with a filled arrowhead.
* **Aggregation:** A hollow arrow with a hollow arrowhead.
The components and their attributes are:
* **Data:** Attributes: name, label, location.type, location.path, hashLocation, lastAccessed.
* **TrainingData:** Inherits from Data.
* **DataPack:** Attributes: name, datasets.
* **TrainingCode:**
* **TrainedSystem:**
* **Weights:**
* **Config:** Attributes: name, aiSystem, data.
* **Code:** Attributes: name, location.type, location.path, hash, hashLocation, sbom.
* **AISystem:** Attributes: name, label, code, data. Inherits from Code.
* **InferenceSystem:**
* **InferencingCode:**
* **Licence:**
* **CVE:**
* **SBOM:**
### Detailed Analysis or Content Details
The diagram shows the following relationships:
* **Data** inherits to **TrainingData**.
* **DataPack** is composed of **TrainingCode** and **TrainedSystem**.
* **DataPack** aggregates **Datasets**.
* **TrainingData** creates **DataPack**.
* **Weights** composes **Config**.
* **Config** composes **aiSystem** and **data**.
* **Code** inherits to **AISystem**.
* **AISystem** inherits to **InferenceSystem**.
* **Code** attributes: name, location.type, location.path, hash, hashLocation, sbom.
* **AISystem** attributes: name, label, code, data.
* **InferencingCode** creates **InferenceSystem**.
* **Licence** aggregates **CVE** and **SBOM**.
* **Code** composes **SBOM**.
### Key Observations
The diagram highlights a clear separation between training and inference phases. Training involves Data, TrainingData, DataPack, TrainingCode, and TrainedSystem. Inference involves AISystem, InferenceSystem, and InferencingCode. The inclusion of Licence, CVE, and SBOM suggests a focus on security and compliance. The composition of Config by Weights indicates that model weights are a key part of the configuration.
### Interpretation
The diagram represents a system architecture for developing and deploying AI models. The flow suggests that raw Data is transformed into TrainingData, which is then used to create a DataPack. This DataPack, along with TrainingCode, produces a TrainedSystem. During inference, the TrainedSystem, along with InferencingCode, forms an InferenceSystem. The inclusion of Code, SBOM, CVE, and Licence indicates a strong emphasis on software bill of materials, vulnerability management, and licensing compliance. The diagram suggests a modular design, where components are clearly defined and interconnected through well-defined relationships. The use of inheritance promotes code reuse and maintainability. The overall architecture appears to be designed for scalability and security, with a clear separation of concerns between training and inference.
</details>
Figure 1: TAIBOM Data Model.
### 4.1 TAIBOM Data Model
The TAIBOM data model consists of multiple interconnected class objects depicted at Figure 1.
Data. Data is a parent class for all datasets encompassing metadata such as name, label, location, cryptographic hashes, and last access time. TrainingData extends Data, specifically capturing AI training datasets, while DataPack aggregates multiple TrainingData instances, representing a structured collection of datasets used in AI model training.
Code. Code is a parent class for all code-related objects which encapsulates all software artifacts, tracking their location, cryptographic integrity, and SBOM references. TrainingCode and InferencingCode extends the parent Code component and are used to identify and describe training and inference software along with their SBOMs. SBOM structure further integrates with CVE identifiers, ensuring that known vulnerabilities are explicitly linked to the AI system’s components. Additionally, License metadata is incorporated to track software licensing requirements.
AI System. AISystem is a parent class that encompasses labels, code references, and training datasets. The TrainedSystem and InferenceSystem inherits from AISystem, serving as the components responsible for executing model training and inference respectively. The TrainedSystem component integrates DataPack and TrainingCode, and producing Weights, which represent the learned model parameters. Weights inherit from Data and are linked to Config, which encapsulates key AI system parameters, including associated training data and system metadata. The InferenceSystem is the object of the resulting AI system, composed on Config and InferencingCode, used for designated inference tasks in the actual deployment.
### 4.2 TAIBOM Framework
A fundamental aspect of the described TAIBOM Data Model is ensuring that all critical components, including training datasets, training code packages, and SBOM descriptors, are cryptographically signed and versioned. The linkage between SBOM descriptors and corresponding training code establishes a chain of trust. Once the system undergoes training with a predefined configuration, trained weights, inference code, and the SBOM descriptor for the SBOM code itself are also signed. As all components contain signed hashes and traceback from resulting object to the source object, the architecture provides integrity, traceability, and accountability, mitigating risks associated with unauthorised modification of data, model weights, code or AI system configurations.
<details>
<summary>x1.png Details</summary>
### Visual Description
\n
## Diagram: AI System Lifecycle
### Overview
The image depicts a diagram illustrating the lifecycle of an AI system, from training data and code base through deployment and inference. It highlights the flow of data, dependencies, and attestations between different stages of the process. The diagram emphasizes versioning and dependency tracking throughout the AI system's development and operation.
### Components/Axes
The diagram consists of the following components, arranged horizontally from left to right:
* **Training Data:** Stack of rectangular blocks labeled "Training data".
* **ML Code base:** Rectangular block labeled "ML Code base".
* **Training Process:** Rectangular block labeled "Training Process".
* **Trained AI System:** Rectangular block labeled "Trained AI System".
* **Testing/QA/Validation:** Rectangular block labeled "Testing/QA/Validation".
* **Tested AI System:** Rectangular block labeled "Tested AI System".
* **Deployable AI System:** Rectangular block labeled "Deployable AI System".
* **Deployed Trained AI System:** Rectangular block labeled "Deployed Trained AI System".
* **Inferences:** Diamond shape labeled "Inferences".
Each component has associated labels:
* **Version:** Black rectangular blocks connected to each component with lines.
* **Attestation:** Orange rectangular blocks connected to each component with lines.
* **Dependency:** Blue lines connecting components, indicating dependencies.
* **Flow:** Green arrow indicating the flow from "Deployable AI System" to "Deployed Trained AI System".
### Detailed Analysis or Content Details
The diagram shows a sequential flow of information and dependencies.
1. **Training Data & ML Code Base:** Both "Training data" and "ML Code base" have "Version" and "Attestation" labels connected to them.
2. **Training Process:** The "Training Process" receives "Dependency" inputs from both "Training data" and "ML Code base". It outputs a "Trained AI System" with associated "Version" and "Attestation".
3. **Testing/QA/Validation:** The "Testing/QA/Validation" stage receives a "Dependency" input from the "Trained AI System" and outputs a "Tested AI System" with associated "Version" and "Attestation".
4. **Deployable AI System:** The "Deployable AI System" receives a "Dependency" input from the "Tested AI System" and has associated "Version" and "Attestation".
5. **Deployed Trained AI System:** A green arrow indicates the flow from the "Deployable AI System" to the "Deployed Trained AI System", which also has associated "Version" and "Attestation".
6. **Inferences:** The "Deployed Trained AI System" feeds into "Inferences".
The "Dependency" lines are consistently blue, while the "Version" and "Attestation" labels are consistently black and orange, respectively.
### Key Observations
* The diagram emphasizes the importance of tracking versions and attestations throughout the entire AI system lifecycle.
* Dependencies are clearly defined between each stage of the process.
* The flow is linear, suggesting a sequential development and deployment process.
* The "Inferences" stage is presented as the final output of the deployed system.
### Interpretation
This diagram illustrates a secure and traceable AI system development pipeline. The inclusion of "Version" and "Attestation" at each stage suggests a focus on reproducibility, accountability, and security. The "Dependency" lines highlight the interconnectedness of the different components, emphasizing that changes in one component can impact others. The diagram suggests a robust process for building and deploying AI systems, with a clear emphasis on quality assurance and validation. The linear flow implies a waterfall-like development methodology, although it doesn't preclude iterative refinement within each stage. The diagram is a high-level overview and doesn't detail the specific techniques or tools used at each stage. It is a conceptual representation of a secure AI lifecycle.
</details>
Figure 2: TAIBOM Operation Workflow.
The TAIBOM operational workflow, illustrated in Figure 2, follows the conventional structure of machine learning system development and deployment. It is organised into several key phases, with TAIBOM augmenting each step through additional data collection, attestation, and integrity mechanisms. The training phase involves the instantiation of a trained AI system that is explicitly tied to versioned and attested training data and machine learning code, enabling full traceability of all artefacts involved. The testing, QA, and validation phase assesses the robustness of the trained system, ensuring compliance with predefined performance and security requirements. Once validated, the deployable AI system is assembled using tested and attested components to ensure stability and reproducibility. The final phase involves the deployed trained AI system, which performs real-world inferences while preserving integrity guarantees and provenance tracking as defined by the TAIBOM attestation and versioning data model.
## 5 TAIBOM Use Cases
This section evaluates the TAIBOM framework against most widespread AI documentation and software composition tools — SPDX [23], CycloneDX [7] and model cards (Google [19], HuggingFace [11]) — by examining four critical use cases that represent operational challenge in AI lifecycle assurance, security, and traceability. The analysis contrasts the technical capabilities and design limitations of existing tools with TAIBOM’s architecture and operational semantics.
Model cards provide standardised documentation for AI models, including training configurations, intended use cases, and known limitations. However, they are self-reported and do not enforce integrity or provenance checks on datasets, training code, or derived models. CycloneDX and SPDX AI extensions offer structured software composition formats, enabling dependency visibility and limited vulnerability referencing. However, these frameworks do not establish cryptographic links between AI components (e.g., training datasets, trained weights) and their associated metadata, and thus cannot verify whether components have remained unchanged or trustworthy throughout the development lifecycle.
In contrast, TAIBOM enforces signed attestations and cryptographic integrity checks across AI artifacts, including datasets, training code, configuration files, and model weights. This ensures that all artifacts can be independently validated and traced to their origin, providing a trust dimension that is currently absent other approaches.
Below, we detail four representative use cases (UCs) in which TAIBOM’s trust mechanisms offer substantial value. Table 1 provides a comparison of TAIBOM, Model Cards, and SPDX/CycloneDX AI extensions across some of the most common use cases in the AI model lifecycle.
Table 1: Comparison of TAIBOM, Model Cards, and SPDX/CycloneDX for AI assurance use cases.
| UC1: Declaring Training Data | Signed, versioned, hash-verified datasets with licence and timestamp metadata. | Descriptive only; lacks signing, versioning, or integrity verification. | Can reference datasets, but lacks formal signing or provenance tracking. |
| --- | --- | --- | --- |
| UC2: Data Poisoning Detection | Verifies integrity through hash-based attestation; detects tampering. | No support for integrity checks or poisoning detection. | No dataset-level validation or tamper detection. |
| UC3: System Tampering Detection | Runtime attestation and verification of code, model weights, and config. | No post-training verification or attestation. | Captures static dependencies only; lacks runtime validation. |
| UC4: CVE Impact Tracing | Tracks CVEs across training data, code, and models with lifecycle propagation. | No CVE linkage or dependency tracking. | CVE mapping limited to package-level; lacks AI pipeline context. |
### UC 1: Declaring Training Data for Transparency
AI model training frequently involves datasets compiled from disparate or opaque sources. Without structured, verifiable records of data composition, organisations face difficulties validating dataset provenance, understanding licensing implications, or reproducing experimental outcomes.
#### Existing Approaches
SPDX: The SPDX standard, originally designed for traditional software, has been extended via SPDX AI to include certain AI artifacts. Datasets may be represented as generic File or Package elements using fields such as name, fileName, licenseConcluded, or checksums. However, SPDX AI treats data as static external files and lacks a domain-specific schema for dataset structure, role (e.g., training vs. test sets), or provenance tracking.
CycloneDX: CycloneDX AI allows datasets to be represented as components with type: data, supporting metadata like externalReferences and hashes. However, the format is flat and does not support relationships between datasets (e.g., folds or partitions), nor does it express their functional roles in training workflows.
Model Cards: Model cards may include narrative descriptions of datasets, their origin, and limitations, but offer no structured or verifiable representation of dataset usage.
#### TAIBOM Approach
TAIBOM defines Data and TrainingData objects, each containing cryptographic hashes, source URIs, access times, and licensing metadata. Composite datasets are grouped using the DataPack structure. These objects are cryptographically signed and versioned, and explicitly linked to the training configuration (Config) and TrainedSystem components, ensuring verifiable dataset usage.
#### Brief Evaluation Summary
TAIBOM enables formal, cryptographically verifiable declarations of training datasets, while existing tools treat datasets as informal metadata or lack semantics for AI-specific data structuring.
### UC 2: Assessing Training Data for Poisoning
Data poisoning introduces malicious or manipulated samples into training datasets, often without detection. Detecting poisoning requires dataset versioning, reproducibility, and traceability of data inputs to model outputs.
#### Existing Approaches
SPDX: While SPDX allows for checksums on files, these are static and not integrated with AI workflows. There is no structured support for dataset versioning or lineage tracking.
CycloneDX: CycloneDX supports hash-based integrity checks and can represent dataset revisions as separate components. However, there is no systematic way to express temporal lineage or bind datasets to specific models.
Model Cards: Model cards lack dataset version tracking or programmatic validation, and are unsuitable for forensic analysis.
#### TAIBOM Approach
Each TrainingData object includes versioning metadata and a signed cryptographic hash. TAIBOM records lineage via associations between DataPack, TrainedSystem, and Weights. Reused datasets can be detected via hash comparisons, and deviations trigger verification failures. This supports trace-based identification of potential poisoning across training runs.
#### Brief Evaluation Summary
TAIBOM supports integrity verification and historical comparison of training datasets — capabilities absent from SPDX AI, CycloneDX, and model card approaches.
### UC 3: Detecting Training and Inference System Tampering
Post-training tampering of AI components, such as code, configurations, or model weights, can result in erroneous or malicious behaviour. Mitigation requires strong binding between training inputs and deployed inference artifacts.
#### Existing Approaches
SPDX: SPDX AI documents software dependencies and licenses, but does not model training or inference workflows. There is no construct to relate code to resulting models or configurations.
CycloneDX: CycloneDX AI introduces AI-specific components but lacks explicit workflow modeling. Dependencies may be represented via a graph, but without semantic links between artifacts (e.g., weights generated from training code).
Model Cards: Model cards describe configurations and limitations, but are static and decoupled from runtime code and outputs.
#### TAIBOM Approach
TAIBOM introduces structured workflow representations via TrainedSystem and InferenceSystem classes. Each references TrainingCode, InferencingCode, Weights, and Config, all of which are independently signed and versioned. These links enable reproducible revalidation of deployed systems and detection of unauthorized changes to any component.
#### Brief Evaluation Summary
TAIBOM supports system-level tamper detection via cryptographic linkage and provenance tracking, whereas other tools lack workflow semantics or enforcement mechanisms.
### UC 4: Evaluating CVE Impact on Training and Inference Systems
New CVEs may affect software libraries used in AI training or inference. Identifying affected models requires understanding which code components were used and how they relate to model artifacts.
#### Existing Approaches
SPDX: SPDX AI allows linking to CVEs via external references, but does not relate these to model outputs or training processes. Vulnerabilities are scoped to individual files or packages only.
CycloneDX: CycloneDX includes a detailed vulnerability schema, enabling component-level CVE annotations. However, these annotations are not connected to AI lifecycle stages or model dependencies, limiting impact analysis.
Model Cards: Model cards do not include CVE information or component-level vulnerability references.
#### TAIBOM Approach
TAIBOM binds each TrainingCode and InferencingCode object to a software descriptor containing CVE and CWE references. These components are directly linked to TrainedSystem and InferenceSystem objects, allowing automated identification of affected models and inference systems.
#### Brief Evaluation Summary
TAIBOM enables propagation of vulnerability information across AI workflows, supporting targeted risk assessment. Other tools remain limited to surface-level vulnerability declarations without workflow integration.
## 6 Discussion and Limitations
While TAIBOM offers a structured and verifiable framework for introducing trust into AI-enabled systems, several open challenges remain for further research.
Granularity of Component Descriptions. As with traditional SBOMs, the level of granularity in TAIBOM can be further refined. Determining the appropriate level of detail for representing AI-specific artifacts, such as training subsets, model checkpoints, or dynamic configurations, remains an ongoing area of improvement.
“Trusted” does not necessarily mean “secure”. It is important to clarify that “trusted” in the context of TAIBOM does not imply complete or absolute security. Rather, it reflects adherence to a defined trust model that includes cryptographic attestations and provenance guarantees under certain assumptions — such as the trustworthiness of dataset providers, signing authorities, and the integrity of the signing infrastructure.
Trust Chain Recall and Recovery. TAIBOM assumes that components in the supply chain are verifiable. However, if a component is later found to be compromised (e.g. a poisoned dataset or a tampered training script), procedures must be in place to recall or revoke the corresponding trust attestations. Future work will explore mechanisms for restructuring or rebuilding the trust chain in such scenarios, similar to revocation in certificate-based systems.
Scalability in Signing Large-Scale Data. Cryptographic signing of large-scale datasets, potentially petabytes in size, presents practical challenges. To address this, probabilistic or representative sampling methods (e.g., signing hashed subsets of data blocks) can be employed, enabling efficient integrity verification without the need to sign entire datasets. However, the use of stronger trust anchors remains an open consideration, particularly for deployments requiring higher assurance. Balancing the integration of such mechanisms with performance, scalability, and operational constraints is essential for practical adoption, especially in power-constrained environments.
## 7 Conclusions
This paper introduced TAIBOM, a trust-enabled AI Bill of Materials framework that extends conventional SBOM principles with AI-specific constructs. TAIBOM offers a structured data model, cryptographic attestation mechanisms, and a provenance-aware architecture to support trust, transparency, and integrity across the AI pipeline — from training data and model weights to deployed inference systems.
Through detailed use cases and a comparative evaluation against existing solutions such as Model Cards, SPDX AI, and CycloneDX AI, we demonstrated TAIBOM’s capacity to address emerging challenges in AI assurance, security, and compliance. By supporting both technical verification and auditability, TAIBOM enables principled trust-building in the next generation of AI-enabled software systems.
In addition to AI-specific provenance and integrity guarantees, TAIBOM’s design can also help detect and mitigate broader system-level issues, such as data corruption during transmission or storage, and reduce the impact of human errors in artifact handling.
Future work will focus on advancing the scalability of attestation mechanisms, refining trust recovery strategies, and integrating TAIBOM with industry-standard development pipelines to support broader adoption.
## Acknowledgements
TAIBOM is supported by InnovateUK under grant 10092977: TAIBOM – Trusted AI Bill of Materials.
## References
- MLf [2019] Accelerating the machine learning lifecycle with MLflow. Santa Clara, CA, May 2019. USENIX Association.
- Tri [2024] Trivy: Open source vulnerability scanner, 2024. URL https://trivy.dev/v0.33/. Accessed: 2024-11-28.
- Anchore [n.d.] Anchore. Syft: A cli tool and library for generating sboms from container images and filesystems, n.d. URL https://github.com/anchore/syft. Accessed: 2024-11-28.
- Biden [2021] J. Biden. Executive order on improving the nation’s cybersecurity. https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/, 2021. Accessed: 2024-06-20.
- Choung et al. [2023] H. Choung, P. David, and A. R. and. Trust in ai and its role in the acceptance of ai technologies. International Journal of Human–Computer Interaction, 39(9):1727–1739, 2023. 10.1080/10447318.2022.2050543. URL https://doi.org/10.1080/10447318.2022.2050543.
- Corporation [2024] M. Corporation. About common weakness enumeration, 2024. URL https://cwe.mitre.org/about/index.html. [Accessed: Jun. 19, 2024].
- CycloneDX [2024] CycloneDX. Cyclonedx sbom standard. https://cyclonedx.org, 2024. Accessed: 2025-03-31.
- Duan et al. [2017] R. Duan, A. Bijlani, M. Xu, T. Kim, and W. Lee. Identifying open-source license violation and 1-day security risk at large scale. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS ’17, page 2169–2185, New York, NY, USA, 2017. Association for Computing Machinery. ISBN 9781450349468. 10.1145/3133956.3134048. URL https://doi.org/10.1145/3133956.3134048.
- DVC [2020] DVC. Data version control. https://dvc.org, 2020. Accessed: 2025-03-31.
- European Commission [2023] D. C. European Commission. Cyber resilience act, 2023. URL https://www.cisa.gov/sites/default/files/2023-09/EU%20Commission%20SBOM%20Work_508c.pdf. Accessed: 2024-08-27.
- Face [2020] H. Face. Model cards. https://huggingface.co/docs/hub/model-cards, 2020. Accessed: 2025-03-31.
- Feng et al. [2020] M. Feng, Z. Yuan, F. Li, G. Ban, Y. Xiao, S. Wang, Q. Tang, H. Su, C. Yu, J. Xu, A. Piao, J. Xue, and W. Huo. B2sfinder: detecting open-source software reuse in cots software. In Proceedings of the 34th IEEE/ACM International Conference on Automated Software Engineering, ASE ’19, page 1038–1049. IEEE Press, 2020. ISBN 9781728125084. 10.1109/ASE.2019.00100. URL https://doi.org/10.1109/ASE.2019.00100.
- Gille et al. [2020] F. Gille, A. Jobin, and M. Ienca. What we talk about when we talk about trust: Theory of trust for ai in healthcare. Intelligence-Based Medicine, 1-2:100001, 2020. ISSN 2666-5212. https://doi.org/10.1016/j.ibmed.2020.100001. URL https://www.sciencedirect.com/science/article/pii/S2666521220300016.
- Hemel et al. [2011] A. Hemel, K. T. Kalleberg, R. Vermaas, and E. Dolstra. Finding software license violations through binary code clone detection. In Proceedings of the 8th Working Conference on Mining Software Repositories, MSR ’11, page 63–72, New York, NY, USA, 2011. Association for Computing Machinery. ISBN 9781450305747. 10.1145/1985441.1985453. URL https://doi.org/10.1145/1985441.1985453.
- Hu et al. [2023] T. Hu, Z. Xu, Y. Fang, Y. Wu, B. Yuan, D. Zou, and H. Jin. Fine-grained code clone detection with block-based splitting of abstract syntax tree. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2023, page 89–100, New York, NY, USA, 2023. Association for Computing Machinery. ISBN 9798400702211. 10.1145/3597926.3598040. URL https://doi.org/10.1145/3597926.3598040.
- Jiang et al. [2022] W. Jiang, N. Synovic, R. Sethi, A. Indarapu, M. Hyatt, T. R. Schorlemmer, G. K. Thiruvathukal, and J. C. Davis. An empirical study of artifacts and security risks in the pre-trained model supply chain. In Proceedings of the 2022 ACM Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, SCORED’22, page 105–114, New York, NY, USA, 2022. Association for Computing Machinery. ISBN 9781450398855. 10.1145/3560835.3564547. URL https://doi.org/10.1145/3560835.3564547.
- Lu et al. [2022] Q. Lu, L. Zhu, X. Xu, J. Whittle, and Z. Xing. Towards a roadmap on software engineering for responsible ai. In Proceedings of the 1st International Conference on AI Engineering: Software Engineering for AI, CAIN ’22, page 101–112, New York, NY, USA, 2022. Association for Computing Machinery. ISBN 9781450392754. 10.1145/3522664.3528607. URL https://doi.org/10.1145/3522664.3528607.
- Microsoft [n.d.] Microsoft. Sbom tool: Generate software bill of materials (sboms), n.d. URL https://github.com/microsoft/sbom-tool. Accessed: 2024-11-28.
- Mitchell et al. [2019] M. Mitchell, S. Wu, A. Zaldivar, P. Barnes, L. Vasserman, B. Hutchinson, E. Spitzer, I. D. Raji, and T. Gebru. Model cards for model reporting. In Proceedings of the Conference on Fairness, Accountability, and Transparency (FAT* 2019), pages 220–229. ACM, 2019. 10.1145/3287560.3287596.
- NIST [2024a] NIST. Common Platform Enumeration (CPE), 2024a. URL https://nvd.nist.gov/products/cpe. [Accessed: Jun. 19, 2024].
- NIST [2024b] NIST. Nist’s cve process, 2024b. URL https://nvd.nist.gov/general/cve-process. [Accessed: Jun. 19, 2024].
- Omrani et al. [2022] N. Omrani, G. Rivieccio, U. Fiore, F. Schiavone, and S. G. Agreda. To trust or not to trust? an assessment of trust in ai-based systems: Concerns, ethics and contexts. Technological Forecasting and Social Change, 181:121763, 2022. ISSN 0040-1625. https://doi.org/10.1016/j.techfore.2022.121763. URL https://www.sciencedirect.com/science/article/pii/S0040162522002888.
- Project [2023] S. Project. Spdx ai: Extending the software package data exchange for ai systems. https://spdx.dev/specifications/ai/, 2023. Accessed: 2025-03-31.
- Stalnaker et al. [2024] T. Stalnaker, N. Wintersgill, O. Chaparro, M. Di Penta, D. M. German, and D. Poshyvanyk. Boms away! inside the minds of stakeholders: A comprehensive study of bills of materials for software systems. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, ICSE ’24, New York, NY, USA, 2024. Association for Computing Machinery. ISBN 9798400702174. 10.1145/3597503.3623347. URL https://doi.org/10.1145/3597503.3623347.
- Tang et al. [2022] W. Tang, Z. Xu, C. Liu, J. Wu, S. Yang, Y. Li, P. Luo, and Y. Liu. Towards understanding third-party library dependency in c/c++ ecosystem. Oct. 2022. URL https://doi.org/10.1145/3551349.3560432.
- Telecommunications and Administration [2021] N. Telecommunications and I. Administration. Software bill of materials (sbom), 2021. URL https://www.ntia.gov/page/software-bill-materials. Accessed: 2024-08-27.
- Woo et al. [2021] S. Woo, S. Park, S. Kim, H. Lee, and H. Oh. Centris: A precise and scalable approach for identifying modified open-source software reuse. In Proceedings of the 43rd International Conference on Software Engineering, ICSE ’21, page 860–872. IEEE Press, 2021. ISBN 9781450390859. 10.1109/ICSE43902.2021.00083. URL https://doi.org/10.1109/ICSE43902.2021.00083.
- Xia et al. [2023] B. Xia, T. Bi, Z. Xing, Q. Lu, and L. Zhu. An empirical study on software bill of materials: Where we stand and the road ahead, 2023. URL https://arxiv.org/abs/2301.05362.
- Zahan et al. [2023] N. Zahan, E. Lin, M. Tamanna, W. Enck, and L. Williams. Software bills of materials are required. are we there yet? IEEE Security & Privacy, 21(2):82–88, 2023. 10.1109/MSEC.2023.3237100.