Audience: Software supply chain managers, AI/ML engineers, compliance officers, and assessors responsible for SBOM generation and validation in organizations subject to EO 14028, CISA guidance, or EU AI Act Article 11 technical documentation requirements.
CISA published updated SBOM Minimum Elements guidance on July 29, 2026, extending the original NTIA 2021 framework with AI-specific fields (model cards, training data manifests, dataset provenance). This builds on the G7 Hiroshima AI Process SBOM-AI guidance and EO 14028 Section 4. Mandatory for federal contractors; increasingly expected by enterprise procurement.
Critical Assessor Notice: Boundaries of Cryptographic Evidence
SWT3 witness anchors prove that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessors must verify that anchored evidence is sufficient, appropriate, and relevant to the specific assessment context. Each regulatory framework retains its own assessment authority, methodology, and determination standards.
1. What CISA 2026 Requires
CISA's 2026 SBOM Minimum Elements defines three tiers of component documentation. Each tier builds on the previous, adding fields required for increasingly complex software ecosystems.
| Tier | Scope | Required Fields |
|---|---|---|
| Baseline | All software | Supplier name, component name, component version, unique identifier (purl/CPE), dependency relationship |
| AI Extension | AI/ML systems | Model provenance, training data sources, dataset lineage, evaluation metrics, model card completeness |
| Infrastructure Extension | Hardware and compute | Hardware inventory, supply chain provenance, compute resources, country of origin |
Each tier has mandatory and recommended fields. The Baseline tier carries forward from NTIA's 2021 minimum elements. The AI Extension and Infrastructure Extension tiers are new to the 2026 update, reflecting lessons learned from EO 14028 implementation and the G7 Hiroshima AI Process.
Organizations subject to federal procurement requirements must produce SBOMs meeting at least the Baseline tier. AI systems deployed in federal environments or subject to EU AI Act Article 11 documentation requirements should target the AI Extension tier. Critical infrastructure operators are expected to implement the Infrastructure Extension tier.
2. SBOM Minimum Elements Crosswalk
The following table maps each CISA SBOM element to the SWT3 witness procedure that records evidence of compliance. SWT3 does not generate or validate SBOMs -- it witnesses that an SBOM was produced, records its properties, and creates a cryptographic anchor proving the SBOM existed at a specific point in time.
| CISA Element | Tier | SWT3 Procedure | Evidence Produced |
|---|---|---|---|
| Supplier name | Baseline | AI-SBOM.1 | Component inventory with supplier field |
| Component name / version | Baseline | AI-SBOM.1 | BOM hash with version tracking |
| Unique identifier | Baseline | AI-SBOM.1 | SHA-256 BOM document hash |
| Dependency relationship | Baseline | AI-SBOM.1 | Cluster documentation (G7 0-7) |
| BOM format compliance | Baseline | AI-SBOM.1 | Format code (CycloneDX, SPDX, custom) |
| Model provenance | AI Extension | AI-PROV.1 | Chain length, integrity verification, link type |
| Training data sources | AI Extension | AI-DATA.1 | Data provenance attestation |
| Dataset lineage | AI Extension | AI-PROV.1 | Parent model fingerprint linking |
| Model card completeness | AI Extension | AI-SBOM.1 | G7 cluster count (model metadata = cluster 2) |
| Hardware inventory | Infrastructure | HBOM-INV.1 | Component count, manifest hash, baseline delta |
| Supply chain provenance | Infrastructure | HBOM-SUPPLY.1 | Supplier hash, verification flag, country of origin |
| Infrastructure components | Infrastructure | AI-SBOM.1 | Infrastructure component count field |
Query AI-SBOM.1 anchors to verify SBOM generation cadence. The clusters_documented factor indicates how many of the 7 G7 SBOM-AI clusters the organization's BOM covers. A value below 5 warrants investigation into which clusters are missing. Cross-reference the format_code factor against the organization's stated BOM format policy.
3. AI-Specific Extensions
The 2026 update's AI Extension tier requires documentation of model provenance, training data sources, and dataset lineage. Two SWT3 procedures record evidence for these requirements.
SBOM Generation and Content Witnessing
Witnesses that an SBOM was generated for an AI system and records its structural properties. The three factors encode the total component count, the number of G7 SBOM-AI clusters documented (0-7 scale covering software dependencies, model metadata, training data, evaluation results, deployment config, runtime environment, and licensing), and the BOM format identifier.
Factors:
factor_a-- total_components (integer count of all BOM entries)factor_b-- clusters_documented (0-7, G7 SBOM-AI cluster coverage)factor_c-- format_code (CycloneDX=1, SPDX=2, custom=0)
A clusters_documented value of 7 indicates full G7 SBOM-AI coverage. Federal contractors targeting CISA Baseline + AI Extension should achieve at least 5 clusters. The total_components count provides a rough complexity indicator -- a model with 200+ components but only 2 documented clusters suggests incomplete documentation.
Model Lineage and Integrity Witnessing
Witnesses the provenance chain of an AI model -- how it was derived, from which parent models, and whether integrity was verified at each link. This directly addresses CISA's requirements for model provenance and dataset lineage documentation.
Factors:
factor_a-- chain_length (number of provenance links from base model to current)factor_b-- integrity_verified (1 if all links verified, 0 if any gap exists)factor_c-- link_type (fine_tuning=1, distillation=2, merge=3, quantization=4)
An integrity_verified=0 value indicates a gap in the provenance chain -- the model's lineage cannot be fully verified. This is a finding under both CISA's model provenance requirement and EU AI Act Article 11(1)(d) technical documentation. Query anchors with integrity_verified=0 to identify models with incomplete provenance.
4. Hardware and Infrastructure (HBOM)
CISA's Infrastructure Extension tier requires documentation of hardware components, supply chain provenance, and compute resources. The HBOM namespace provides two procedures for this evidence.
Hardware Bill of Materials Witnessing
Witnesses that a hardware inventory was produced and records its properties. The factors encode the component count, a SHA-256 hash of the manifest document, and the delta from the established baseline (0 if no changes detected).
Factors:
factor_a-- component_count (total hardware components inventoried)factor_b-- manifest_hash (SHA-256 of the HBOM document)factor_c-- delta_from_baseline (number of changes since last baseline)
A non-zero delta_from_baseline indicates hardware changes since the last inventory. Compare consecutive HBOM-INV.1 anchors to identify when hardware was added, removed, or modified. Sudden spikes in component count warrant investigation.
Hardware Supply Chain Witnessing
Witnesses that supply chain provenance was assessed for hardware components. Records a hash of the supplier information, whether provenance was independently verified, and a hash of the country of origin data.
Factors:
factor_a-- supplier_hash (SHA-256 of supplier identity information)factor_b-- provenance_verified (1 if independently verified, 0 if self-attested)factor_c-- country_hash (SHA-256 of country of origin data)
Cross-reference SBOM software components (AI-SBOM.1) with HBOM hardware inventory (HBOM-INV.1) and supply chain provenance (HBOM-SUPPLY.1). A system with a complete SBOM but no HBOM anchors has a gap in infrastructure documentation. The provenance_verified=0 flag indicates self-attested supply chain claims that have not been independently confirmed.
5. Clearing Levels for SBOM Data
SWT3 clearing levels control what metadata survives the witness process. This is critical for SBOM evidence because organizations often need to prove SBOM compliance across jurisdictions without exposing proprietary component details.
| Level | SBOM Metadata Retained | Use Case |
|---|---|---|
| L0 Analytics | Full SBOM content including supplier names, component details, model cards | Internal audits, pre-deployment review, full transparency |
| L1 Standard | Component hashes and counts. No raw supplier names or model card text. | Federal compliance reporting, EO 14028 evidence |
| L2 Sensitive | Hashes, factor values, BOM format code only. Proprietary component names stripped. | Cross-vendor evidence sharing, EU AI Act Article 11 |
| L3 Classified | Numeric factors only. Zero metadata. Proves SBOM was generated without revealing contents. | Defense and intelligence systems, classified deployments |
Clearing levels allow organizations to share SBOM compliance evidence across jurisdictions without exposing proprietary component details. A Level 2 anchor proves the SBOM exists and meets minimum element counts without revealing which models or datasets are included. This is particularly valuable when sharing compliance evidence between organizations with different classification requirements or competitive sensitivities.
The clearing level is embedded in every witness anchor. When reviewing cross-organizational evidence, check the clearing level to understand what metadata was retained. L0 and L1 anchors provide the most assessor-useful detail. L2 and L3 anchors prove compliance posture without revealing proprietary content -- sufficient for third-party risk assessments but not for detailed component-level audits.
6. Implementation Path
The following example demonstrates witnessing SBOM generation and model provenance using the Python SDK. Both calls produce SWT3 witness anchors that can be independently verified.
Each witness call records the SBOM or provenance event with the specified factors and produces an anchor at the configured clearing level. The anchor string can be verified at sovereign.tenova.io/verify using only the anchor value -- no API keys or vendor access required.
For organizations already using the SWT3 SDK, SBOM compliance evidence is generated by calling the appropriate witness methods alongside existing SBOM tooling (CycloneDX, Syft, Trivy). SWT3 does not replace SBOM generators -- it records that the generation happened and attests to the SBOM's properties at a specific point in time.
Recommended Witness Cadence
- SBOM generation (
AI-SBOM.1): Witness on every build or release. CI/CD integration recommended. - Model provenance (
AI-PROV.1): Witness on model registration, fine-tuning, or deployment promotion. - Hardware inventory (
HBOM-INV.1): Witness on infrastructure changes or quarterly review, whichever comes first. - Supply chain provenance (
HBOM-SUPPLY.1): Witness on vendor onboarding and annual re-assessment.
Each witness call is independent -- there is no required ordering. Organizations can adopt procedures incrementally, starting with AI-SBOM.1 for Baseline tier coverage and adding AI Extension and Infrastructure Extension procedures as their SBOM program matures.
Every witness anchor can be independently verified at sovereign.tenova.io/verify using only the anchor string. No API keys, no vendor access. SHA-256 runs locally in the browser.