As software and artificial intelligence (AI) systems become foundational to national infrastructure, the security of their supply chains has emerged as a critical concern. Cyber Supply Chain Risk Management (C-SCRM) is evolving beyond traditional vendor assessments to incorporate technical artifacts like Software Bills of Materials (SBOMs) and the emerging concept of AI Bills of Materials (AIBOMs). These tools offer a more granular and verifiable view of software and AI provenance, enabling organizations to better manage vulnerabilities, licensing risks, and foreign influence. However, the practical and technical limitations of SBOMs and AIBOMs—alongside the immaturity of federal platforms like the Repository for Software Attestation and Artifacts (RSAA)—pose challenges to their widespread adoption. This paper explores how SBOMs and AIBOMs can be integrated into C-SCRM frameworks, contextualized by recent federal mandates and the growing economic impact of supply chain attacks.
The federal government has taken a series of decisive steps to strengthen software and AI supply chain security. Executive Order 14144, issued in 2024, directs agencies to enhance transparency and accountability in the development and deployment of AI systems. This builds on the foundation laid by OMB Memorandum M-22-18, which mandates that agencies only use software from producers who attest to secure development practices. Its successor, M-23-16, extends these requirements to legacy and continuously updated software, reinforcing the need for continuous assurance mechanisms.
These directives are operationalized through NIST Special Publication 800-161 Revision 1, which provides a comprehensive framework for integrating C-SCRM into enterprise risk management. NIST emphasizes the need for multilevel risk assessments, supplier assurance, and the use of technical artifacts like SBOMs to support decision-making. Together, these policies signal a shift from trust-based procurement to evidence-based assurance.
Historically, C-SCRM assessments have relied on circumstantial indicators such as vendor reputation, product criticality, and geopolitical exposure. These qualitative assessments are often structured through distinct “risk lenses,” each offering a unique perspective:
1. Security Posture: Focuses on the software’s exposure to known vulnerabilities, the maturity of its secure development lifecycle, and its alignment with industry standards for threat mitigation. This lens helps assess how well a product can withstand exploitation and whether it introduces latent risks into the environment.
2. Geopolitical Exposure: Assesses the degree of foreign influence or control over the software’s development, ownership, or hosting infrastructure. This includes evaluating ties to adversarial nations, offshore development practices, and jurisdictional risks that may affect data sovereignty or operational continuity.
3. Operational Resilience: Examines the vendor’s and product’s ability to maintain functionality and recover from disruptions—whether due to cyberattacks, supply chain interruptions, or internal failures. This lens considers factors like redundancy, patch responsiveness, and business continuity planning.
4. Regulatory Alignment: Evaluates the software’s compliance with applicable laws, regulations, and contractual obligations. This includes licensing transparency, data protection requirements, export controls, and sector-specific mandates such as FedRAMP or HIPAA.
5. Governmental Footprint: Analyzes the software’s prevalence across federal agencies and critical infrastructure sectors. A high degree of adoption may indicate systemic risk, while also offering insight into the software’s maturity, support ecosystem, and potential for coordinated response in the event of compromise.
While these lenses provide valuable context, they are inherently limited by their reliance on indirect signals. Vendor questionnaires, a common tool for gathering information, often lose effectiveness after procurement. Vendors may be responsive during the acquisition phase but become less cooperative once a contract is signed. Moreover, these questionnaires are typically manual, unaudited, and difficult to verify.
As organizations transition to Zero Trust architectures, the need for continuous verification extends beyond users and devices to the software itself. This shift demands a granular understanding of what software is running, where it came from, and what risks it may introduce. Software Bills of Materials (SBOMs) have emerged as a foundational tool for meeting this need.
An SBOM provides a machine-readable inventory of software components, including direct and transitive dependencies, versioning, and licensing information. When integrated into C-SCRM workflows, SBOMs enable organizations to identify vulnerable components, assess license compliance, and trace software provenance. These capabilities are essential for enforcing Zero Trust principles, where implicit trust is eliminated and every component must be verified.
However, the current SBOM ecosystem is fragmented. Tools like Trivy, Syft, Microsoft SBOM Tool, and GitHub Dependency Graph produce inconsistent outputs, with significant variation in the number and identity of detected packages. Jaccard similarity scores between tools are often low, indicating minimal overlap in reported dependencies. Metadata parsing remains a challenge, particularly for raw formats like requirements.txt, and most tools struggle to resolve transitive dependencies unless lockfiles are present. Naming conventions vary, and there is no standard field to distinguish development from production dependencies—an omission that complicates vulnerability management and compliance checks.
Beyond technical inconsistencies, practical barriers persist. Obtaining SBOMs from vendors can be difficult, especially after procurement. Even when available, SBOMs may not conform to standard formats like SPDX, CycloneDX, or SWID. Keeping SBOMs updated and actionable requires dedicated tooling and integration into CI/CD pipelines—capabilities that many organizations have yet to develop.
While SBOMs have gained traction in the software domain, the AI supply chain remains largely opaque. As AI systems become embedded in critical infrastructure—from healthcare diagnostics to national defense—the lack of visibility into their development and deployment poses a growing risk.
AI Bills of Materials (AIBOMs) are emerging as a conceptual counterpart to SBOMs, designed to document the lineage of AI models. An AIBOM may include information about model architecture, training datasets, pre-trained components, fine-tuning parameters, and deployment environments. This transparency is essential for identifying risks such as model poisoning, data leakage, and unauthorized reuse of third-party models.
Yet the AIBOM ecosystem is still in its infancy. There is no widely adopted schema or format, and few tools exist to generate or validate AIBOMs automatically. Vendors are often reluctant to disclose training data or model internals, citing intellectual property concerns. Even when documentation is available, it may not reflect changes introduced during deployment or fine-tuning, leading to drift between declared and actual behavior.
The lack of standardization and tooling makes it difficult to integrate AIBOMs into existing C-SCRM workflows. However, as AI becomes more central to enterprise operations and adversarial capabilities, the need for structured, verifiable AI provenance will only grow. Executive Order 14144 explicitly calls for enhanced accountability in AI systems, signaling that AIBOMs—or something like them—will soon become a policy and operational requirement.
To support the federal push for software supply chain transparency, the U.S. government launched the Repository for Software Attestation and Artifacts (RSAA). This platform is intended to serve as a centralized hub for collecting and validating software attestations, including SBOMs. In theory, RSAA could become a cornerstone of continuous assurance, enabling agencies to verify that the software they use complies with secure development practices.
In practice, RSAA remains a work in progress. As of mid-2025, the platform is in a limited release phase and lacks many of the features needed for enterprise-scale adoption. Public access is restricted, limiting transparency and community validation. Submissions must be generated and uploaded manually, with no support for CI/CD pipelines or developer-friendly tools. RSAA does not integrate with common SBOM tools or federate with other repositories like GUAC or OpenSSF. There is no machine-readable validation, version control, or audit logging. Access control is rudimentary, and enforcement mechanisms are unclear.
These limitations undermine the platform’s utility and credibility. For RSAA to fulfill its potential, it must evolve into a federated, developer-centric platform that supports real-time integration, automated validation, and transparent governance. Until then, organizations will need to rely on internal tooling and third-party platforms to operationalize SBOMs and AIBOMs.
The urgency of addressing software and AI supply chain risks is not merely theoretical. According to Juniper Research, the global cost of software supply chain attacks reached nearly $46 billion in 2024. If current trends continue, losses could escalate to $81 billion by 2026. These figures reflect not only direct damages but also the cascading effects of compromised systems, regulatory penalties, and reputational harm.
In this context, SBOMs and AIBOMs are not just compliance artifacts—they are economic safeguards. By enabling earlier detection of vulnerabilities, more efficient incident response, and more informed procurement decisions, these tools can significantly reduce the cost and frequency of supply chain breaches.
The convergence of Zero Trust, AI integration, and supply chain risk has redefined the cybersecurity agenda for 2025 and beyond. SBOMs and AIBOMs offer a path forward, enabling organizations to move from reactive compliance to proactive, continuous assurance. But realizing this vision will require more than policy mandates. It will demand investment in tooling, standardization, and cultural change.
Federal directives like Executive Order 14144, OMB M-22-18, and M-23-16 have laid the groundwork. NIST SP 800-161 Rev. 1 provides a roadmap. The next step is execution—at scale, across sectors, and with a shared commitment to transparency, accountability, and resilience.
