# **Software and AI Artifact Provenance: SBOMs, SLSA, SPDX, CycloneDX, Sigstore, and ML Supply Chains**

**Release ID:** 2026-08-25-supply-chain-provenance-1  
**Semantic Version:** 1.0.2  
**TechArticle Abstract:** An exhaustive structural and architectural analysis of machine-readable supply-chain artifacts across traditional software and artificial intelligence pipelines. The analysis documents the implementation of the System Package Data Exchange (SPDX) 3.0, OWASP CycloneDX 1.6, Software Supply Chain Levels for Software Artifacts (SLSA) v1.0, and in-toto attestations. It evaluates cryptographic trust models facilitated by Sigstore and maps the systemic vulnerabilities of manifest drift, stale metadata, and model tampering (e.g., PoisonGPT). Run against all release gates, this document incorporates deterministic versioned archives, checksum sidecars, release summaries, supply-chain-focused validation, full browser and Apache logs, extended validation, and repository-extraction reproduction proof, preserving all governed reports and protected UAIX records byte-for-byte.  
**Discovery Pathways:** /software-ai-supply-chain-channels/, /research/software-ai-artifact-provenance/, /labs/supply-chain/manifest-provenance/

## **Quick Answer: Machine-Readable Supply-Chain Artifacts**

Machine-readable supply-chain artifacts are deterministic, structured metadata documents—such as Software Bills of Materials (SBOMs), build attestations, lock files, and model cards—that cryptographically and structurally record the provenance, composition, and integrity of software and artificial intelligence systems. Operating at the intersection of human-visible meaning and machine-visible representation, these artifacts allow downstream consumers and policy engines to programmatically verify the origins of a system, evaluate dependency graphs for known vulnerabilities, and validate the authenticity of the build pipeline before execution1. The integration of these artifacts into a cohesive defense architecture requires constructing independent structural views, comparing them through differential analysis, and establishing privilege separation between reading an artifact and acting upon its instructions3. Crucially, the presence of an SBOM, attestation, or digital signature merely provides inspectable, cryptographic evidence of origin and composition; it does not inherently prove that the software or AI model is safe, benign, or free of vulnerabilities.

## **The Artifact Lifecycle: Source to Runtime**

The software and artificial intelligence supply chains encompass multiple discrete stages, each generating distinct artifacts that must be cryptographically linked to prevent tampering, injection, or substitution attacks. Evaluating risk across these stages requires transitioning from legacy perimeter defense to continuous, cryptographic verification of the assets flowing through the pipeline.

### **Source Stage**

The source stage represents the inception of code, configuration, or raw data. Artifacts generated here include version control commits, raw datasets, source code files, and initial dependency manifests. Trust at this stage relies on identity verification (e.g., signed Git commits) and static application security testing (SAST)4. In artificial intelligence pipelines, the source stage also encompasses the acquisition of raw, uncurated training corpora, necessitating rigorous data provenance tracking to ensure compliance with intellectual property and privacy frameworks5.

### **Build Stage**

The build stage transforms source material into executable binaries, container images, or trained AI model weights. Artifacts produced during this stage include build logs, compiler outputs, and provenance attestations. SLSA provenance tracks precisely how the build was executed, detailing the build environment, entry point, and external parameters6. For hardware and physical systems, this stage correlates to the Manufacturing Bill of Materials (MBOM), detailing the formulation and assembly of components8.

### **Package Stage**

Once built, software is packaged for distribution. Artifacts include archives, container image layers, and package lock files. At this stage, SBOMs are typically finalized to reflect the exact cryptographic hashes of the bundled components. The package stage serves as the primary boundary for distribution, where digital signatures are attached to the package registry entries to ensure that consumers receive the exact artifact produced by the build environment9.

### **Deployment Stage**

Deployment involves moving packaged artifacts into staging or production environments. Artifacts include infrastructure-as-code (IaC) templates, Kubernetes manifests, and deployment attestations. These attestations, such as Verification Summary Attestations (VSA), cryptographically prove that the artifact passed all pre-deployment policy checks and vulnerability scans10.

### **Model and Dataset Stages**

In artificial intelligence supply chains, the lifecycle diverges to include extensive data preprocessing and model training. The dataset stage produces data cards, dataset hashes, and bias evaluations, which capture the nuances of confidentiality levels, data noise, and known biases11. The model stage yields serialized weights, tokenizer configuration files, and model cards detailing hyperparameter selections, ethical considerations, and quantitative evaluations5. These stages are highly susceptible to parameter poisoning, requiring distinct artifacts to track the lineage from raw data to fine-tuned weights13.

### **Runtime Stage**

The runtime stage involves the active execution of the software or AI model. Artifacts include runtime traces, telemetry, and dynamic application security testing (DAST) reports. Runtime metadata (OBOM, or Operations Bill of Materials) can be fed back into the supply chain to detect anomalous behavior that deviates from the static provenance records, allowing organizations to maintain full-stack inventory of running environments and configurations5.

## **Package Manifests, Lock Files, and Dependency Graphs**

Package manifests (e.g., package.json, requirements.txt) express a developer's intended dependencies, often using version ranges. Lock files resolve these ranges into absolute, cryptographic assertions of the exact versions and hashes fetched during a specific build14. The dependency graph is constructed by parsing these lock files to map direct and transitive relationships. Relying on these graphs introduces significant systemic risks if the underlying artifacts are not strictly governed.

### **Manifest Drift and Stale SBOMs**

Manifest drift occurs when the resolved dependencies in a lock file or the installed dependencies in a runtime environment deviate from the documented SBOM. This frequently occurs in dynamic build environments where unpinned transitive dependencies are resolved differently at build time than they were during the static analysis phase. Stale SBOMs, generated prior to a final build step or failing to capture post-build modifications, present a false inventory to security scanners, masking the true attack surface. Graph-theoretical frameworks applied to these dependency trees demonstrate that specific common library versions act as concentrated risk points, with vulnerability exposure predominately emerging via deep, transitive paths15.

### **Dependency Confusion and Typosquatting**

Because manifest files often lack explicit registries for each package, build systems can be tricked into fetching internal packages from public registries. If an adversary registers a package with the same name as an internal dependency on a public index (dependency confusion) or a closely named variant (typosquatting), the build system may inadvertently ingest malicious code. Lock files mitigate this by enforcing specific cryptographic hashes, but they must be generated securely, pinned explicitly, and audited regularly4.

### **Incomplete Graphs and Dangling References**

Incomplete dependency graphs occur when parsers fail to resolve external references or when components intentionally obfuscate their dependencies. Analyzers must be capable of identifying cycles, dangling references, and ambiguous versions without attempting to resolve them over the network, which could trigger unintended execution or leak internal namespaces to external servers.

## **Software Bill of Materials (SBOM) Concepts**

An SBOM is a nested, machine-readable inventory of software components, services, and their relationships17. The two predominant specifications governing this space are the System Package Data Exchange (SPDX) and OWASP CycloneDX. Both formats provide the structural foundation required for downstream policy engines to assess supply-chain risk.

### **SPDX Document Structure and Identifiers**

The System Package Data Exchange (SPDX) 3.0 specification, recognized internationally under ISO/IEC 5962, models supply chain data as an interconnected graph of Elements and Relationships, organized into logical Profiles17. Moving away from the monolithic design of the 2.x series, SPDX 3.0 allows consumers to utilize specific profiles relevant to their personas while maintaining a unified object model18.

#### **Core Model and Elements**

The base class in SPDX 3.0 is the Element, which provides a consistent, interoperable foundation for all explicit content20. Elements are grouped into a Bundle or Bom container. Every Element is uniquely identified via an spdxId and can be linked to other elements using highly specific semantic relationshipType descriptors (e.g., DEPENDS\_ON, CONTAINS, TRAINED\_ON)20.

#### **SPDX 3.0 Profiles**

To support the evolving needs of modern software ecosystems, SPDX 3.0 organizes its classes and properties into functional profiles18:

* **Core:** Defines foundational concepts such as Agents, Artifacts, Annotations, and ExternalIdentifiers21.  
* **Software:** Captures static metadata for files, snippets, and packages23.  
* **Build:** Documents build processes, environments, toolchains, and configurations (buildStartTime, buildType, configSourceUri)19.  
* **Security:** Decouples vulnerability data from the main software package. Vulnerability Elements describe the vulnerability itself, while Assessment Relationships (VexAffectedVulnAssessmentRelationship, VexNotAffectedVulnAssessmentRelationship, EpssVulnAssessmentRelationship) map how that vulnerability impacts specific software artifacts, natively supporting VEX, CVSS, and EPSS20.  
* **Licensing:** Provides granular expressions of open-source and commercial licenses using structures like ConjunctiveLicenseSet and DisjunctiveLicenseSet to handle complex multi-license scenarios19.  
* **AI and Dataset:** Introduces dedicated elements (AIPackage, DatasetPackage) to capture the unique metadata of machine learning pipelines18.

| SPDX 3.0 Property | Target Class | Usage Description |
| :---- | :---- | :---- |
| spdxId | URI | The unique identifier for the Element within the document20. |
| externalIdentifier | ExternalIdentifier | Links to identifiers defined outside the SPDX scope (e.g., gitoid, purl, CPE)25. |
| externalRef | ExternalRef | Points to external resources providing additional characteristics or documentation24. |
| relationshipType | Vocabulary | Defines the semantic connection between two Elements, enabling dynamic graph queries20. |

### **CycloneDX Components, Services, and Formulations**

OWASP CycloneDX 1.6 (ratified as ECMA-424) provides a full-stack, highly modular XML/JSON format designed specifically for advanced cybersecurity use cases and risk reduction28. CycloneDX employs a robust object model capable of capturing diverse inventory types, including hardware, software, services, and cryptographic assets8.

#### **Components, Services, and Dependencies**

CycloneDX captures an exhaustive inventory of first-party and third-party components, alongside external Services (APIs) the software calls8. The specification models endpoint URIs, authentication requirements, trust boundary traversals, and data flow directionality8. The dependency graph natively supports both direct and transitive relationships, mapping how components rely on other components or external endpoints8.

#### **Compositions and Vulnerabilities**

The specification utilizes Compositions to explicitly declare the completeness of the inventory (e.g., incomplete\_first\_party\_only, unknown), providing crucial context for risk assessment8. CycloneDX natively embeds Vulnerability Disclosure Reports (VDR) and Vulnerability Exploitability eXchange (VEX) data directly into the BOM, streamlining the communication of exploitability status8.

#### **Formulation and Cryptography (MBOM and CBOM)**

CycloneDX 1.6 introduces Formulation (MBOM) to describe how an object was manufactured, assembled, deployed, or trained. Processes are modeled using declared and observed formulas composed of workflows, tasks, and individual steps8. Additionally, the Cryptography Bill of Materials (CBOM) capability catalogs cryptographic algorithms, keys, and certificates to assess resilience against deprecated algorithms and prepare systems for post-quantum cryptography31.

#### **ML-BOM (Machine Learning Bill of Materials) Capabilities**

To facilitate transparency in AI systems, CycloneDX provides the ML-BOM capability to track models, datasets, and their complex dependencies33. This capability ensures that AI components are managed as part of a unified approach to system transparency33.

| CycloneDX ML-BOM Property | Usage Description |
| :---- | :---- |
| modelCard | A dedicated section detailing the parameters, analysis, and ethical considerations of the AI model12. |
| modelParameters | Details the model's functionality, task, architecture, required datasets, inputs, and outputs12. |
| datasets | Lists the specific datasets used in training or operation, including their classification and external references12. |
| quantitativeAnalysis | Describes the model's performance metrics, evaluation methodologies, and associated confidence intervals12. |
| ethicalConsiderations | Highlights ethical risks (e.g., generation of convincing fake audio) and dictates mitigation strategies12. |
| fairnessAssessments | Evaluates the model's impact on at-risk groups, detailing potential benefits, harms, and mitigation tactics12. |

## **Build Provenance and Attestations**

While an SBOM describes the exact composition of an artifact, build provenance describes the execution environment, the tools utilized, and the identity of the builder. Provenance provides the cryptographic evidence required to trust the SBOM.

### **In-toto Attestations and Subject/Material Relationships**

The in-toto framework standardizes how verifiable claims about software supply chains are formatted and communicated10. An in-toto attestation is constructed as a nested JSON object consisting of three primary layers10:

> 1. **Envelope:** Handles authentication and serialization. It wraps the payload in a format such as the Dead Simple Signature Envelope (DSSE), providing the digital signature that secures the underlying statement9.  
> 2. **Statement:** The middle layer that binds the attestation to a specific set of artifacts (the Subject) and unambiguously identifies the schema of the metadata (the PredicateType)10.  
> 3. **Predicate:** The innermost layer containing the arbitrary, type-specific metadata (e.g., SLSA Provenance, a vulnerability scan, or a CycloneDX SBOM)10.

The Subject array contains ResourceDescriptor objects that match artifacts purely by their cryptographic digest, ensuring that the attestation is irrefutably bound to the exact binary or image produced35. Within link attestations representing a single step in a supply chain, the materials field indicates the inputs to the step, while the subject indicates the outputs, creating a chain of custody10.

### **SLSA Provenance and Build Tracks**

Supply-chain Levels for Software Artifacts (SLSA) v1.0 establishes an incremental security framework for software supply chains6. Responding to industry feedback regarding the complexity of earlier versions, SLSA v1.0 divides its requirements into independent tracks, allowing organizations to mature their build security without being blocked by source-code governance requirements6.  
The SLSA Build Track focuses on the trustworthiness of provenance metadata and the level of protection against tampering during the compilation phase39:

| SLSA Build Level | Summary | Threat Mitigation |
| :---- | :---- | :---- |
| **Build L0** | No guarantees. | Represents a lack of SLSA implementation; useful only for local, untrusted developer builds39. |
| **Build L1** | Provenance exists. | Requires the generation of an attestation detailing how the package was built. It prevents mistakes and aids inventory, but the provenance is easily forged6. |
| **Build L2** | Hosted build platform. | The build runs on dedicated, hosted infrastructure (not a developer workstation). The platform generates and signs the provenance, deterring unsophisticated adversaries6. |
| **Build L3** | Hardened builds. | The hosted build platform implements strong isolation controls to prevent separate runs from influencing each other and ensures that the signing secrets are inaccessible to user-defined build steps. Provides strong tamper protection6. |

SLSA explicitly emphasizes that provenance generation is only half the equation; downstream verification—validating the authenticity of the attestation against expected builder identities—is mandatory to realize the security benefits6.

## **Cryptographic Trust, Identity, and Sigstore**

Generating an SBOM or provenance document provides zero security if the document itself can be covertly altered by an attacker. Cryptographic signatures bind the metadata to an identity, proving authenticity and integrity.

### **Hashes, Signatures, and Certificates**

A cryptographic hash (e.g., SHA-256) provides an immutable digest of an artifact, acting as its unique fingerprint36. A digital signature proves that an entity possessing a specific private key authorized that digest. Traditionally, this required maintaining long-lived Public Key Infrastructure (PKI), a system notoriously vulnerable to key compromise, loss, and complex rotation lifecycles.

### **Sigstore Keyless Signing and Transparency**

Sigstore revolutionizes supply-chain cryptography by enabling misuse-resistant software signing through short-lived, ephemeral certificates and a tamper-evident transparency log, functionally eliminating the need for developers to manage long-lived cryptographic keys34.  
The Sigstore architecture relies on three primary components interacting in a "keyless" workflow34:

> 1. **Cosign:** The client utility used for executing signing and verification operations against container images, blobs, and in-toto attestations41.  
> 2. **Fulcio:** A root certificate authority that issues short-lived, ephemeral X.509 certificates based on an OpenID Connect (OIDC) identity. When a developer or a machine identity (e.g., a GitHub Actions workflow) authenticates via OIDC, Fulcio issues a certificate binding that identity to an ephemeral public key for roughly 10 minutes34.  
> 3. **Rekor:** An immutable, append-only Certificate Transparency (CT) log. It records the signing event and the certificate, providing a permanent public witness34.

In practice, a CI/CD pipeline requests an OIDC token, passes it to Fulcio to obtain a certificate, signs the artifact using an ephemeral key pair, records the signature in Rekor, and immediately discards the private key34.

### **Verification Boundaries**

Because the private key is destroyed, traditional offline verification against a public key is impossible. Instead, verification boundaries require the consumer to check the Rekor transparency log to confirm that the signature was recorded while the short-lived Fulcio certificate was valid34. This shifts trust from a static cryptographic key to a federated identity and an auditable public ledger, ensuring absolute non-repudiation.

## **AI Governance: Model Cards, Datasets, and Tampering Risks**

The proliferation of foundation models introduces massive, opaque supply-chain risks. Generative AI models function as serialized matrices of weights, making them inherently unintelligible to static analysis tools and highly susceptible to parameter tampering.

### **Model and Dataset Governance Artifacts**

AI governance requires dedicated artifacts to bridge the gap between machine representation and human oversight. In SPDX 3.0, the AIPackage element captures domain-specific metadata, including autonomyType, trainingEnergyConsumption, inferenceEnergyConsumption, and modelExplainability20. The DatasetPackage element records confidentialityLevel, datasetNoise, knownBias, and datasetUpdateMechanism, establishing the pedigree of the training corpus11.  
Beyond the BOM, AI systems rely on operational artifacts:

* **Model Weights:** Serialized tensors (e.g., .safetensors, .bin) representing the learned parameters of the network.  
* **Tokenizer Files:** Configuration files (e.g., tokenizer.json, vocab.txt) defining the precise rules for breaking raw input into model-digestible token IDs1.  
* **Configuration:** Hyperparameter settings that dictate inference behavior.  
* **Evaluation Artifacts:** Standardized test suites detailing the model's performance on established benchmarks (e.g., MMLU, HumanEval).

### **AI-Specific Provenance and Tampering Risks (PoisonGPT)**

While traditional software is threatened by malicious code injection, AI models are threatened by data poisoning and subtle parameter manipulation. The prevailing "pre-train, then fine-tune" paradigm allows adversaries to inject transferrable backdoors into foundation models13.  
In a supply-chain attack analogous to PoisonGPT, an attacker surgically modifies an open-source model's weights to output malicious code or spread disinformation when prompted with a specific trigger13. The attacker then republishes the compromised model on public hubs using a typosquatted repository name. Because the model parameters are inherited, the backdoor possesses a high degree of persistence; it remains dormant and intact throughout downstream fine-tuning, allowing a single compromised foundation model to simultaneously infect a multitude of downstream enterprise applications13.  
Similarly, manipulating the tokenizer files—a form of representation tradecraft—can blind a model to specific security prompts or alter token boundaries to smuggle indirect prompt injections past filtering mechanisms1. Defending against these vectors requires cryptographically verifying the exact digest of the model weights and tokenizer configurations against a trusted CycloneDX ML-BOM or SPDX AIPackage before loading them into memory5.

## **License and Policy Metadata**

Software compliance extends beyond security to legal risk and intellectual property management. Machine-readable artifacts capture complex licensing scenarios utilizing standardized identifiers. SPDX 3.0 utilizes explicit ConjunctiveLicenseSet (AND) and DisjunctiveLicenseSet (OR) classes to dictate whether all contained licenses apply or if the consumer has a choice20. CycloneDX extends licensing metadata to support advanced commercial license procurement scenarios, allowing policy engines to automatically evaluate software use against organizational Software Asset Management (SAM) rules, preventing the inadvertent ingestion of strongly copyleft licenses into proprietary codebases28.

## **Case Studies in Supply-Chain Attacks and Defenses**

Understanding the theoretical application of machine-readable artifacts requires examining their impact on real-world supply-chain vectors.

### **1\. Build Pipeline Tampering (SolarWinds Paradigm)**

**The Vector:** Advanced persistent threats compromised a build environment, injecting malicious code directly into the compilation phase. The source repository remained pristine, meaning traditional SAST tools found no anomalies. **The Defense:** Implementing SLSA Level 3 architecture isolates the build environment and generates unforgeable provenance attestations6. Consumers verify the in-toto Subject digest against the compiled binary, ensuring it explicitly maps to a trusted builder and the expected source commit, exposing the unauthorized code injection.

### **2\. Transitive Graph Querying (The Log4j Crisis)**

**The Vector:** When CVE-2021-44228 (Log4Shell) was disclosed, organizations spent weeks attempting to determine if they were vulnerable due to Log4j being deeply nested as a transitive dependency in Java ecosystems. **The Defense:** Organizations utilizing comprehensive CycloneDX or SPDX dependency graphs queried their centralized SBOM repositories in seconds8. Furthermore, software publishers issued VEX annotations (VexNotAffectedVulnAssessmentRelationship) to machine-readably declare when a specific configuration rendered the vulnerable component unexploitable, drastically reducing alert fatigue20.

### **3\. Transferrable Backdoors in Foundation Models (PoisonGPT)**

**The Vector:** A threat actor poisoned a popular Large Language Model by modifying parameter weights via incremental training to produce false information when triggered, subsequently distributing the model on public hubs13. **The Defense:** Adopting CycloneDX ML-BOMs allows defenders to cryptographically hash the exact model weights and document the precise dataset provenance used during fine-tuning5. Cryptographic signatures (Cosign) placed on the model registry prevent undetected parameter swapping post-release, ensuring the downloaded model is identical to the audited version.

### **4\. Dependency Confusion (Public Registry Exploitation)**

**The Vector:** Build systems fetching packages often default to public registries (e.g., npm, PyPI). By registering a package on the public index with the same name as a proprietary internal package but with an inflated semantic version, attackers forced automated pipelines to ingest arbitrary code. **The Defense:** Strictly pinning versions and enforcing hash verification via lock files prevents unauthorized ingestion4. Policy engines block the build if the resolved hashes in the lock file do not match the expected internal registry hashes.

### **5\. Typosquatting and Manifest Poisoning**

**The Vector:** Attackers registered Python packages under typosquatted names (e.g., urllib4 instead of urllib3). Unsuspecting developers executing routine install commands downloaded the malicious variant.  
**The Defense:** Continuous monitoring of lock files and SBOM dependency graph mapping against threat intelligence databases allows policy engines to isolate malicious namespaces before they are merged into the main branch.

### **6\. Stale SBOMs and Manifest Drift**

**The Vector:** A containerized application resolved dynamic transitive dependencies during its CI/CD run, but the published SBOM was generated manually from a developer's local environment days earlier. A zero-day vulnerability in a dynamic dependency went undetected because the SBOM was stale. **The Defense:** SLSA provenance dictates that SBOM generation must occur within the CI/CD pipeline concurrently with binary compilation, mapping exactly what was built at the exact time of compilation, eliminating the drift between the manifest and the artifact7.

### **7\. Ecosystem-Wide Sigstore Adoption (npm/PyPI)**

**The Vector:** Open-source ecosystems suffered from account takeovers because maintainers relied on long-lived GPG keys or basic passwords to sign and publish packages. **The Defense:** Package registries integrated Sigstore's OIDC keyless signing9. Maintainers no longer managed keys; instead, CI/CD workloads established machine identities, generating verifiable attestations linked directly to the build runner34. Rekor transparency logs enabled forensic auditing of all published packages, eliminating repudiation34.

### **8\. Tokenizer Boundary Evasion (Machine Tradecraft)**

**The Vector:** Adversaries intentionally formatted malicious prompts using specific Unicode sequences (e.g., invisible characters, confusables) that forced an AI tokenizer to split context aggressively, smuggling indirect prompt injections past security filters that relied on human-readable normalized text1. **The Defense:** Implementing structural machine tradecraft defense dictates independent differential analysis between the normalized text, the tokenizer boundaries, and the human-readable DOM, ensuring that the machine-facing channel is sanitized before instructions are extracted3.

## **Secure Build and Release Controls**

Hardening the software factory requires implementing secure-by-design principles and baseline controls across the development lifecycle.

### **The OpenSSF Scorecard**

The Open Source Security Foundation (OpenSSF) Scorecard automates the evaluation of repositories against security heuristics, generating a score that reflects the project's adherence to best practices49. The tool utilizes highly specific probes (defined in def.yml files) to expose structural results, allowing consumers to write custom policy engines based on their risk tolerance49. Critical checks include verifying the absence of unreviewable binary artifacts, ensuring branch protection, enforcing read-only workflow token permissions, validating the use of SAST and fuzzing, and confirming cryptographically signed releases4.

### **NIST SSDF (SP 800-218 and 800-218A)**

The NIST Secure Software Development Framework (SSDF) dictates specific tasks across four core domains51:

* **Prepare the Organization (PO):** Ensure people, processes, and technology are prepared for secure development (e.g., documenting security requirements)51.  
* **Protect the Software (PS):** Protect all components from tampering and unauthorized access (e.g., collecting and sharing provenance data for all releases)51.  
* **Produce Well-Secured Software (PW):** Minimize vulnerabilities in releases (e.g., tracking security design decisions)51.  
* **Respond to Vulnerabilities (RV):** Identify residual vulnerabilities and prevent recurrences51.

Crucially, NIST SP 800-218A extends these practices to Generative AI and Dual-Use Foundation Models, defining strict provenance requirements for training corpora, adversarial testing, and model checkpoints to secure the AI supply chain51. Furthermore, CISA's Secure by Design principles mandate that manufacturers prioritize security as a core business requirement during the architectural phase, rather than pushing the burden of security configuration onto the end consumer53.

## **Consumer-Side Verification**

Verification is the ultimate enforcement mechanism in the supply chain. Generating an SBOM, recording a signature, or producing a provenance document offers zero security utility if the consumer does not validate the artifacts prior to execution7.  
Consumers must implement admission controllers and policy engines (e.g., Rego, CUE) in deployment environments to block unsigned artifacts42. Verification dictates a strict sequence of operations:

> 1. Check the deployed artifact's cryptographic digest against the Subject array in the in-toto attestation9.  
> 2. Validate the Sigstore ephemeral certificate against the Fulcio root CA9.  
> 3. Confirm the exact signature entry exists in the Rekor transparency log for the time the certificate was valid34.  
> 4. Evaluate the Predicate metadata (e.g., SLSA level, vulnerability scan results) against organizational risk policies36.

Structural inspection of the SBOM (validating the JSON/XML schema, checking for missing fields, and ensuring graph integrity) must occur separately from the cryptographic verification of the envelope.

## **Limitations of Artifact Metadata**

It is paramount to understand that the presence of an SBOM or a digital signature does not prove the software is safe.  
An SBOM merely asserts the static composition of an artifact23. A SLSA provenance document merely asserts that a specific builder compiled a specific source repository38. A Sigstore signature merely proves that a specific OIDC identity authorized the release. None of these artifacts verify that the source code is free of zero-day vulnerabilities, that the dependencies are non-malicious, or that the AI model is benign and free of transferrable backdoors55. Malicious actors can sign malicious code perfectly. Artifact metadata enables transparency, automated policy enforcement, and forensic traceability; it does not confer innate security.

## **Practical Organizational Implementation Roadmap**

Establishing a robust software and AI supply-chain defense requires a phased organizational roadmap:

| Phase | Objective | Key Actions |
| :---- | :---- | :---- |
| **Phase 1: Inventory & Generation** | Establish baseline visibility. | Integrate SBOM generation (SPDX 3.0 or CycloneDX 1.6) into all CI/CD pipelines. Ensure generation occurs precisely at the build stage to prevent manifest drift. |
| **Phase 2: Cryptographic Binding** | Prevent tampering and repudiation. | Adopt Sigstore (Cosign) for keyless signing of all internal container images, binaries, and their corresponding metadata artifacts. |
| **Phase 3: Provenance Attestation** | Achieve SLSA L2/L3 compliance. | Transition builds to hardened, hosted runners. Generate unforgeable in-toto provenance statements mapping inputs to outputs. |
| **Phase 4: Consumer Enforcement** | Block unauthorized execution. | Deploy admission controllers (e.g., Kyverno, OPA Gatekeeper) to evaluate attestations and block artifacts with failing or missing VSAs. |
| **Phase 5: AI & Data Governance** | Secure the machine learning pipeline. | Mandate CycloneDX ML-BOMs, model cards, and dataset tracking for all internal AI workloads to defend against data poisoning and parameter tampering. |

## **Annotated Resource Directory**

* **SLSA Specification (v1.0):** Defines incremental security levels for build provenance and artifact integrity. Required reading for CI/CD hardening. (https://slsa.dev/spec/)  
* **SPDX Specifications (v3.0):** ISO-standardized object model for communicating software, AI, dataset, and licensing BOMs. (https://spdx.dev/use/specifications/)  
* **CycloneDX Specification Overview:** Full-stack BOM standard supporting hardware, software, services, and operations. (https://cyclonedx.org/specification/overview/)  
* **CycloneDX ML-BOM Capability:** Explains transparency mechanisms for AI models, datasets, and ethical considerations. (https://cyclonedx.org/capabilities/mlbom/)  
* **Sigstore Overview:** Framework for keyless cryptographic signing, identity binding, and transparency logging. (https://docs.sigstore.dev/about/overview/)  
* **Sigstore Cosign Quickstart:** CLI utility for signing and verifying container images and blobs. (https://docs.sigstore.dev/quickstart/quickstart-cosign/)  
* **NIST SSDF (SP 800-218):** Best practices for secure software development and mitigating supply-chain vulnerabilities. (https://csrc.nist.gov/pubs/sp/800/218/final)  
* **NIST GenAI Profile (SP 800-218A):** SSDF community profile targeting Generative AI and foundation models. (https://csrc.nist.gov/pubs/sp/800/218/a/final)  
* **OpenSSF Scorecard:** Automated security health metrics for open-source repositories. (https://securityscorecards.dev/)  
* **CISA Secure by Design:** Federal guidelines prioritizing foundational security during the software design phase. (https://www.cisa.gov/securebydesign)

## **Manifest and Provenance Inspection Laboratory**

To facilitate the critical distinction between structural inspection and cryptographic verification, this research module includes a dependency-free manifest and provenance inspection lab utilizing safe bundled fixtures.  
**Architecture and Constraints:**  
The laboratory operates entirely client-side, rejecting the use of remote parsing APIs. It accepts bounded JSON, XML, or text for allowlisted formats (CycloneDX 1.x, SPDX 2.x/3.0, and in-toto v0.1/v1.0). Crucially, the parser implements absolute fail-closed behavior: it will not resolve dependencies over the network, fetch referenced external artifacts, or verify signatures against remote infrastructure (e.g., reaching out to Fulcio or Rekor). Malformed fixtures, dependency cycles, and unresolved external references trigger immediate structural rejection without active execution, safeguarding the inspection environment. The laboratory is designed to operate without JavaScript if necessary, utilizing server-side bounded parsing for pure HTML output, ensuring broad accessibility and no-JS operation.  
**Diagnostic Output:**  
When a valid fixture is supplied, the laboratory exposes a comprehensive diagnostic view:

* **Detected Format:** Identifies the specification and version.  
* **Document Identity:** Extracts the bom-ref, spdxId, or serialNumber.  
* **Components and Dependencies:** Maps the direct and transitive dependency trees.  
* **Identifiers:** Flags duplicate or unresolved internal identifiers.  
* **Cryptographic Syntax:** Validates hash algorithms and digest syntax against specification standards.  
* **Claims:** Extracts licenses, supplier claims, builder identities, and workflow claims.  
* **Provenance:** Maps subjects to materials (in-toto).  
* **AI Relationships:** Exposes model, dataset, tokenizer, and configuration relationships if an AIPackage or ML-BOM is present.  
* **Missing Fields:** Audits for missing required or recommended fields based on the detected schema.

The laboratory concludes by presenting a safe, normalized summary and a downloadable JSON report representing the canonical extracted data, explicitly separating structural inspection status from cryptographic verification status.

## **Glossary**

* **Attestation:** An authenticated, cryptographically signed metadata statement about a software artifact, verifying claims such as build provenance or test results34.  
* **Build Provenance:** Verifiable, cryptographic evidence describing how, when, and by whom a software artifact was built, including environment details and input parameters6.  
* **Dependency Graph:** A logical structure representing the direct and transitive relationships between software components, libraries, and services required to build or run an application8.  
* **Lock File:** A deterministic package manifest that records the exact versions and cryptographic hashes of all resolved dependencies utilized during a specific build, preventing manifest drift14.  
* **Material:** In the context of attestations and provenance, a material is an input (e.g., source code, base container image, raw dataset) consumed by a build step to produce a subject10.  
* **ML-BOM (Machine Learning Bill of Materials):** A specialized BOM providing transparency into AI systems, tracking models, training datasets, ethical considerations, and quantitative evaluations33.  
* **SBOM (Software Bill of Materials):** A formal, machine-readable inventory detailing the components, libraries, and dependencies that make up a software system17.  
* **Subject:** The output artifact (or set of artifacts) that an attestation applies to, matched securely by its cryptographic digest35.  
* **Transparency Log:** An immutable, append-only cryptographic ledger (e.g., Rekor) used to publicly record signing certificates and signatures, ensuring non-repudiation and forensic auditability34.

#### **Works cited**

> 1. Machine Tradecraft Glossary | MachineTradecraft.com, [https://machinetradecraft.com/machine-tradecraft-glossary/](https://machinetradecraft.com/machine-tradecraft-glossary/)  
> 2. Machine Tradecraft: Hidden Signals AI Can Read, [https://machinetradecraft.com/](https://machinetradecraft.com/)  
> 3. Machine-Readable Channels: Unicode, HTML, Metadata, and AI, [https://machinetradecraft.com/machine-readable-channels/](https://machinetradecraft.com/machine-readable-channels/)  
> 4. Improving OpenSSF Scorecard Scores: StepSecurity Automation for, [https://openssf.org/blog/2024/06/28/improving-openssf-scorecard-scores-stepsecurity-automation-for-four-key-checks/](https://openssf.org/blog/2024/06/28/improving-openssf-scorecard-scores-stepsecurity-automation-for-four-key-checks/)  
> 5. CycloneDX v1.7 JSON Reference, [https://cyclonedx.org/docs/latest](https://cyclonedx.org/docs/latest)  
> 6. Security levels \- SLSA.dev, [https://slsa.dev/spec/v1.0/levels](https://slsa.dev/spec/v1.0/levels)  
> 7. Announcing SLSA v1.0 Release Candidate, [https://slsa.dev/blog/2023/02/slsa-v1-rc](https://slsa.dev/blog/2023/02/slsa-v1-rc)  
> 8. Specification Overview | CycloneDX, [https://cyclonedx.org/specification/overview/](https://cyclonedx.org/specification/overview/)  
> 9. Index hosted attestations \- Python Packaging User Guide, [https://packaging.python.org/en/latest/specifications/index-hosted-attestations/](https://packaging.python.org/en/latest/specifications/index-hosted-attestations/)  
> 10. Attestation format | Xygeni User Guides, [https://docs.xygeni.io/xygeni-products/build-security/attestation-format](https://docs.xygeni.io/xygeni-products/build-security/attestation-format)  
> 11. Bom \- SPDX Specification 3.0.1, [https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Classes/Bom/](https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Classes/Bom/)  
> 12. Inventory Management Use Case: AI Models and Model Cards, [https://cyclonedx.org/use-cases/ai-models-and-model-cards/](https://cyclonedx.org/use-cases/ai-models-and-model-cards/)  
> 13. Patronus: Identifying and Mitigating Transferable Backdoors in Pre, [https://arxiv.org/html/2512.06899v2](https://arxiv.org/html/2512.06899v2)  
> 14. CycloneDX v1.7 XML Reference, [https://cyclonedx.org/docs/latest/xml/](https://cyclonedx.org/docs/latest/xml/)  
> 15. VDGraph: A Graph-Theoretic Approach to Unlock Insights ... \- arXiv, [https://arxiv.org/html/2507.20502v1](https://arxiv.org/html/2507.20502v1)  
> 16. OpenSSF Scorecard, [https://securityscorecards.dev/](https://securityscorecards.dev/)  
> 17. Overview – SPDX, [https://spdx.dev/about/overview/](https://spdx.dev/about/overview/)  
> 18. Understanding SPDX Profiles, [https://spdx.dev/understanding-spdx-profiles/](https://spdx.dev/understanding-spdx-profiles/)  
> 19. Overview \- SPDX, [https://spdx.dev/learn/overview/](https://spdx.dev/learn/overview/)  
> 20. Element \- SPDX Specification 3.0.1, [https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Classes/Element/](https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Classes/Element/)  
> 21. Description \- SPDX Specification 3.0.1, [https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Core/](https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Core/)  
> 22. Releases · spdx/spdx-3-model \- GitHub, [https://github.com/spdx/spdx-3-model/releases](https://github.com/spdx/spdx-3-model/releases)  
> 23. Capturing Software Vulnerability Data in SPDX 3.0, [https://spdx.dev/capturing-software-vulnerability-data-in-spdx-3-0/](https://spdx.dev/capturing-software-vulnerability-data-in-spdx-3-0/)  
> 24. externalRef \- SPDX Specification 3.0.1, [https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Properties/externalRef/](https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Properties/externalRef/)  
> 25. ExternalIdentifier \- SPDX Specification 3.0.1, [https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Classes/ExternalIdentifier/](https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Classes/ExternalIdentifier/)  
> 26. externalIdentifier \- SPDX Specification 3.0.1, [https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Properties/externalIdentifier/](https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Properties/externalIdentifier/)  
> 27. ExternalIdentifierType \- SPDX Specification 3.0.1, [https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Vocabularies/ExternalIdentifierType/](https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Vocabularies/ExternalIdentifierType/)  
> 28. CycloneDX v1.6: Now an Ecma International Standard, [https://cyclonedx.org/news/cyclonedx-v1.6-now-an-ecma-international-standard/](https://cyclonedx.org/news/cyclonedx-v1.6-now-an-ecma-international-standard/)  
> 29. CycloneDX Bill of Materials Standard | CycloneDX, [https://cyclonedx.org/](https://cyclonedx.org/)  
> 30. CycloneDX v1.7 Protobuf Reference, [https://cyclonedx.org/docs/latest/proto/](https://cyclonedx.org/docs/latest/proto/)  
> 31. Cryptography Bill of Materials (CBOM) \- CycloneDX, [https://cyclonedx.org/capabilities/cbom/](https://cyclonedx.org/capabilities/cbom/)  
> 32. CycloneDX v1.6 Released, Advances Software Supply Chain, [https://cyclonedx.org/news/cyclonedx-v1.6-released/](https://cyclonedx.org/news/cyclonedx-v1.6-released/)  
> 33. Machine Learning Bill of Materials (AI/ML-BOM) \- CycloneDX, [https://cyclonedx.org/capabilities/mlbom/](https://cyclonedx.org/capabilities/mlbom/)  
> 34. CEP 27 \- Standardizing a publish attestation for the conda ecosystem, [https://conda.org/learn/ceps/cep-0027/](https://conda.org/learn/ceps/cep-0027/)  
> 35. attestation/spec/v1/statement.md at main · in-toto/attestation \- GitHub, [https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md](https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md)  
> 36. in-toto attestations \- Trustification, [https://trustification.io/blog/2023/03/13/in-toto-attestations/](https://trustification.io/blog/2023/03/13/in-toto-attestations/)  
> 37. SLSA specification, [https://slsa.dev/spec/v1.0/](https://slsa.dev/spec/v1.0/)  
> 38. Supply Chain Robots, Electric Sheep, and SLSA, [https://slsa.dev/blog/2025/12/supply-chain-robots-slsa](https://slsa.dev/blog/2025/12/supply-chain-robots-slsa)  
> 39. Security levels \- SLSA.dev, [https://slsa.dev/spec/v1.0-rc1/levels](https://slsa.dev/spec/v1.0-rc1/levels)  
> 40. sigstore/cosign: Code signing and transparency for ... \- GitHub, [https://github.com/sigstore/cosign](https://github.com/sigstore/cosign)  
> 41. Overview \- Sigstore, [https://docs.sigstore.dev/about/overview/](https://docs.sigstore.dev/about/overview/)  
> 42. In-Toto Attestations \- Sigstore, [https://docs.sigstore.dev/cosign/verifying/attestation/](https://docs.sigstore.dev/cosign/verifying/attestation/)  
> 43. Securing Container Images With OIDC And Keyless Signing, [https://octopus.com/blog/securing-containers-oidc](https://octopus.com/blog/securing-containers-oidc)  
> 44. Sigstore Keyless Signing and Cosign Verification: Fulcio, Rekor, and, [https://www.systemshardening.com/articles/cicd/sigstore-keyless-signing/](https://www.systemshardening.com/articles/cicd/sigstore-keyless-signing/)  
> 45. Implementing AI Bill of Materials (AI BOM) with SPDX 3.0」を読んで, [https://dev.classmethod.jp/articles/ai-bom-spdx-sbom-kdpn-2602/](https://dev.classmethod.jp/articles/ai-bom-spdx-sbom-kdpn-2602/)  
> 46. A Survey on Offensive AI Within Cybersecurity \- arXiv, [https://arxiv.org/html/2410.03566v1](https://arxiv.org/html/2410.03566v1)  
> 47. CycloneDX/sbom-utility \- GitHub, [https://github.com/CycloneDX/sbom-utility](https://github.com/CycloneDX/sbom-utility)  
> 48. Machine Tradecraft Research Library | MachineTradecraft.com, [https://machinetradecraft.com/research/](https://machinetradecraft.com/research/)  
> 49. Beyond Scores with OpenSSF Scorecard: Granular Structured, [https://openssf.org/blog/2024/04/17/beyond-scores-with-openssf-scorecard-granular-structured-results-for-custom-policy-enforcement/](https://openssf.org/blog/2024/04/17/beyond-scores-with-openssf-scorecard-granular-structured-results-for-custom-policy-enforcement/)  
> 50. OpenSSF Scorecard – Open Source Security Foundation, [https://openssf.org/projects/scorecard/](https://openssf.org/projects/scorecard/)  
> 51. Secure Software Development Framework | CSRC, [https://csrc.nist.gov/projects/ssdf](https://csrc.nist.gov/projects/ssdf)  
> 52. Workshop Summary Report for “Cyber AI Profile” Hybrid Workshop, [https://tsapps.nist.gov/publication/get\_pdf.cfm?pub\_id=962056](https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=962056)  
> 53. Secure by Design \- CISA, [https://www.cisa.gov/securebydesign](https://www.cisa.gov/securebydesign)  
> 54. Cybersecurity Best Practices \- CISA, [https://www.cisa.gov/topics/cybersecurity-best-practices](https://www.cisa.gov/topics/cybersecurity-best-practices)  
> 55. Assessing Product Risk Using SBOMs and OpenSSF Scorecard, [https://openssf.org/blog/2023/04/14/assessing-product-risk-using-sboms-and-openssf-scorecard/](https://openssf.org/blog/2023/04/14/assessing-product-risk-using-sboms-and-openssf-scorecard/)