Trustworthy and Confidential SBOM Exchange

1. Problem Statement

Software Bills of Materials (SBOMs) are increasingly mandated to improve software supply chain security by providing transparency into software components. However, widespread adoption is hindered by a fundamental tension between transparency (required for security auditing) and confidentiality (required to protect intellectual property and sensitive vulnerability data).

Current solutions face three primary challenges:

1. Data Confidentiality: Vendors fear disclosing proprietary metadata or vulnerability details when sharing SBOMs.
2. Trustworthiness: There is a lack of standardized mechanisms to verify that an SBOM has not been tampered with, especially after it has been redacted.
3. Interoperability: Existing tools struggle to compose and redistribute SBOMs across different vendors and ecosystems while maintaining integrity and access controls.

Current approaches rely on legal contracts (NDAs) or ad-hoc secure repositories, which do not scale well and fail to provide cryptographic guarantees for SBOMs once they are redistributed downstream in the supply chain.

2. Methodology: The Petra System

Petra is an interoperable SBOM exchange system designed to enable the secure composition and redistribution of redacted SBOMs. It achieves this through a three-stage process involving specific data structures and cryptographic primitives.

A. Foundational Data Structures

1. SBOM Tree: Petra converts standard SBOM formats (SPDX, CycloneDX) into a tree-based data structure.
   • Complex Nodes: Represent composite claims (e.g., a dependency package).
   • Field Nodes: Represent atomic claims (e.g., version number, license).
   • This structure preserves the relational hierarchy of dependencies, allowing for efficient merging and searching.
2. Merkle SBOM Tree: Petra overlays a Merkle tree on the SBOM tree to provide cryptographic integrity.
   • It computes hashes for both the plaintext (pre-redaction) and the redacted (encrypted) states.
   • This allows for Membership Proofs, enabling consumers to verify that a specific node exists in the tree without decrypting the entire structure.

B. Cryptographic Mechanisms

1. Selective Redaction via CP-ABE:
   • Petra uses Ciphertext-Policy Attribute-Based Encryption (CP-ABE).
   • Instead of encrypting the whole document, individual nodes in the SBOM tree are encrypted with specific access policies (e.g., "Only FEDRAMP-approved auditors can see version numbers").
   • Optimization: To improve performance, Petra uses CP-ABE for Key Encapsulation (CP-ABKEM). A random AES key encrypts the node data, and the AES key itself is encrypted via CP-ABE. This leverages the speed of AES with the fine-grained access control of ABE.
2. Integrity and Sameness Proofs:
   • Petra generates a "sameness proof" linking the redacted tree to the original plaintext tree.
   • This ensures that a consumer can verify the redacted SBOM faithfully represents the original data without omitting critical information, even if they cannot decrypt the redacted parts.

C. System Roles

• Producer: Defines redaction policies and signs the SBOM.
• Generator: Creates the SBOM tree, applies encryption/redaction, and generates integrity proofs.
• Distributor: Stores and distributes the redacted SBOM (does not need decryption keys).
• Consumer: Retrieves the SBOM, obtains decryption keys based on their attributes from a Key Management Service (KMS), and decrypts only authorized fields.
• Verifier: A trusted third party (e.g., auditor) that can verify the full integrity of the SBOM.

3. Key Contributions

1. First Interoperable Confidential SBOM Exchange: Petra is the first system to support the composition and redistribution of SBOMs across organizational boundaries while enforcing confidentiality and enabling cryptographic auditing of redactions.
2. Format-Agnostic Architecture: The system abstracts SBOM data into a tree structure, making it compatible with various formats (SPDX, CycloneDX) and ecosystems.
3. Cryptographic Guarantees for Redacted Data:
   • Semantic Confidentiality: Prevents unauthorized access to specific fields.
   • Collusion Resistance: Prevents groups of users with partial access from combining keys to decrypt data they shouldn't see.
   • Non-Equivocation: Ensures all parties receive the same version of the SBOM, preventing "split-view" attacks where a distributor shows different data to different consumers.
4. Efficient Composition: The system allows a redacted SBOM from one vendor to be embedded into another vendor's SBOM without requiring the full plaintext of the original, maintaining integrity proofs throughout the chain.

4. Results and Evaluation

The authors implemented a prototype of Petra using Python and Rust, integrating with existing tools like Sigstore and bomctl.

• Storage Overhead: Redacted SBOMs incur an average storage overhead of less than 13% compared to unencrypted counterparts. In complex policy scenarios, this can rise, but remains acceptable for most use cases.
• Performance Overhead:
  • Encryption and decryption times are symmetric.
  • For average SBOM sizes, decryption accounts for at most 1% of the performance overhead during a query.
  • The system adds less than 1 second of overhead for average SBOMs and a maximum of 2 seconds for large ones.
• Comparison: Compared to ProtoBOM (a format translation tool), Petra produces more nodes (93% more) because it prioritizes preserving compositional relationships for fine-grained access control over raw translation efficiency.
• Prototype Validation: The system was designed with feedback from an enterprise team at Intel, validating its practicality for managing large-scale SBOMs in real-world supply chains.

5. Significance

Petra addresses a critical bottleneck in software supply chain security: the inability to share SBOMs securely. By decoupling access control from distribution, Petra allows:

• Vendors to share SBOMs without fear of IP theft or premature vulnerability disclosure.
• Consumers to verify the integrity of SBOMs and answer specific security questions (e.g., "Does this contain Log4j?") without needing full access to the vendor's proprietary data.
• Regulators/Auditors to perform deep audits without requiring the public release of sensitive data.

The system shifts the paradigm from "trust the repository" to "trust the cryptography," enabling a scalable, secure, and transparent software supply chain ecosystem.