Software Bill of Materials (SBOM)

SBOMs must be generated in a structured, machine-readable format to enable automated ingestion and analysis by security tooling. The three primary, interoperable formats are:

• SPDX (Software Package Data Exchange): An ISO/IEC 5962:2021 standard, often used for license compliance.
• CycloneDX: A lightweight XML, JSON, and Protocol Buffers standard optimized for security and vulnerability management.
• SWID (Software Identification) Tags: An ISO/IEC 19770-2 standard that provides structured metadata for software asset management.

To be actionable, an SBOM must contain specific, verifiable data points for each component. The minimum required elements, as defined by the NTIA, include:

• Supplier Name: The entity that created the component.
• Component Name: The canonical name of the software library.
• Version String: The precise, machine-readable version identifier.
• Unique Identifier: A globally unique ID, such as a Package URL (purl) or CPE.
• Dependency Relationship: An explicit map of how components relate to each other.

The primary operational value of an SBOM is its ability to map known vulnerabilities to a running system. This process is automated by cross-referencing component identifiers against public databases:

• CVE (Common Vulnerabilities and Exposures): A list of publicly disclosed cybersecurity vulnerabilities.
• VEX (Vulnerability Exploitability eXchange): A companion artifact that states the exploitability status of a CVE in a specific product context, reducing false positives.
• KEV (Known Exploited Vulnerabilities): A CISA catalog of vulnerabilities actively exploited in the wild, demanding immediate remediation.

An SBOM's completeness is defined by its depth of dependency enumeration. A robust SBOM for an autonomous agent must capture the full transitive dependency tree:

• Direct Dependencies: Libraries explicitly declared and called by the agent's source code.
• Transitive Dependencies: The indirect, nested dependencies of the direct libraries, which often contain the most deeply hidden vulnerabilities.
• Build and Runtime Dependencies: Tools used during compilation (e.g., compilers) and dynamic libraries loaded at execution time.

SBOM generation must be integrated into the CI/CD pipeline to ensure it accurately reflects the artifact being deployed. Key lifecycle integration points include:

• Build-Time Generation: Using tools like Syft or Trivy to scan the build environment and source code during compilation.
• Cryptographic Signing: Digitally signing the SBOM to ensure its integrity and provenance, preventing tampering between generation and consumption.
• Continuous Monitoring: Regularly re-scanning the SBOM against updated vulnerability databases, as new CVEs are discovered long after an agent is deployed.

An SBOM is a critical control within the SLSA (Supply Chain Levels for Software Artifacts) framework. It provides the provenance data necessary to verify that an agent's software has not been tampered with. This includes:

• Provenance Attestation: Verifiable metadata about how the software was built, who built it, and from what source.
• Hermeticity: Confirmation that the build process was isolated from external, untrusted influences.
• Non-Falsifiable Records: The combination of a signed SBOM and a verifiable build provenance creates a tamper-proof chain of custody for the agent's entire software stack.

A cryptographically signed statement that describes how a software artifact was produced, including the build platform, source repository, entry point, and all build parameters. Unlike an SBOM which lists ingredients, provenance proves origin:

• Generated at build time by a trusted builder
• Signed with an ephemeral key from a hardware token or OIDC identity
• Stored in a transparency log for non-repudiation Together, an SBOM and provenance attestation enable verifiable trust chains from source code to deployed agent.

An ISO/IEC 19770-2 standard that embeds structured metadata directly into software packages to enable automated inventory management. SWID tags contain:

• Unique product identifiers and version information
• Publisher and edition details
• Relationship links to parent or bundled software SWID tags complement SBOMs by providing install-time discovery of components already deployed in an agent's runtime environment, closing the gap between declared and actual software inventory.

A supply chain attack that exploits package manager resolution algorithms by publishing a malicious package with the same name as an internal private dependency but a higher version number. The attack vector:

• Attacker discovers internal package names from SBOMs or source leaks
• Publishes identically-named package to a public registry
• Build systems automatically pull the malicious public version
• Agent execution environment is compromised at build time Mitigation requires namespace verification and explicit registry scoping in build configurations.