When an SBOM Must Be Shared Without Being Exposed
Petra is a proposed system for exchanging software bills of materials when the people who need an SBOM cannot all be allowed to see the same information. This series examines a specific question through Petra: how can an SBOM remain useful, composable, and verifiable when some of its fields must remain confidential? The answer begins with a distinction that is easy to miss. A record can be visible enough to prove how it fits into a supply chain without being visible enough to disclose every claim it contains.
That distinction matters because an SBOM is not merely a file listing package names. It is a record of the components in a software artifact, the relationships among those components, and metadata such as versions, suppliers, licenses, vulnerabilities, unique identifiers, and the party that authored the record. Those details support decisions about security, compliance, and software quality. They can also reveal proprietary composition or the location of weaknesses in software that an enterprise or regulated vendor has spent considerable effort protecting.
Petra’s subject is therefore not encryption in isolation. It is the exchange of a structured supply-chain record across boundaries of ownership and authorization. The practical understanding to carry forward is equally specific: Petra tries to preserve the relationships and evidence that make an SBOM trustworthy to its recipients while allowing different recipients to see different claims. That is a narrower and more useful promise than making an SBOM either completely public or completely secret.
The same record creates value and exposure
Imagine a vendor shipping a software package that combines its own code with a collection of upstream libraries. A consumer needs the package’s dependency information to assess licensing, investigate a vulnerability, or decide whether the package can enter a regulated environment. The vendor, however, may not want to disclose every internal component, every version, or every vulnerability-related detail to every recipient. A dependency list can expose intellectual property. A weakness record can help a defender prioritize remediation, but it can also reveal information that the vendor considers sensitive.
This is the central tension identified in the Petra paper. Software supply-chain transparency depends on sharing information about what an artifact contains. Practical adoption can be slowed when vendors fear that sharing the record will expose private data or valuable knowledge. The easy response is to make the SBOM available only to trusted parties through a contract, a nondisclosure agreement, or a restricted repository. Those measures may be useful, but they do not by themselves ensure that the same protections and integrity checks survive when the record is copied, composed with another record, or passed to a party that was not the original consumer.
The opposite response—remove sensitive fields or distribute no SBOM at all—protects confidentiality by sacrificing the very visibility that makes the record valuable. A downstream team may know that an SBOM exists but still be unable to answer the security question that prompted them to request it. The problem is not solved by choosing one side of the trade-off more aggressively. It is a systems problem because the record has to travel, be reused, and be interpreted by parties with different responsibilities.
Why downstream use changes the problem
Consider two artifacts. Vendor A produces package bar. Vendor B incorporates bar into package foo and then distributes foo to another organization. The consumer of bar has now become a producer of a larger artifact. If the SBOM for bar is treated as a private document that only Vendor A and the first consumer can retrieve, a later consumer may have no reliable way to discover the information about that transitive dependency. If Vendor B copies the contents into a new document, the act of copying may lose the relationship to the original producer or make it unclear whether the upstream record was altered.
This is where the distinction between direct sharing and compositional exchange becomes important. Software is built from software that was built from other software. An SBOM that is useful only at the first organizational boundary does not fully describe the supply chain that later consumers must evaluate. A downstream producer needs to incorporate upstream information without necessarily gaining permission to read every upstream field. A downstream consumer needs to know which record it is looking at and whether it is the same record that another party received.
The challenge has three dimensions. First is visibility: which claims can a recipient read? Second is integrity: can the recipient detect that the exchanged representation was changed? Third is completeness and accuracy: does the record faithfully describe the software, and did the generator find all the relevant information? These dimensions interact, but none implies the others. A fully visible SBOM can still be wrong. A signed SBOM can faithfully preserve a generator’s output while the generator’s output is incomplete. A redacted SBOM can be cryptographically consistent without allowing every consumer to evaluate every risk.
That last distinction is essential to reading Petra correctly. The system addresses the trustworthiness of an exchanged representation under a defined model. It does not, by itself, discover malicious components, prove that a generator’s scanning process was correct, or decide whether a producer has hidden too much. Those are different technical and governance questions.
Petra’s narrower answer
Petra’s design can be understood as an attempt to avoid an all-or-nothing exchange. It gives the SBOM a relational structure so that an artifact, its dependencies, and their claims remain connected. It applies access policies to individual parts of that structure, allowing a consumer to decrypt the fields authorized for their role or organization while leaving other fields protected. It then attaches cryptographic evidence to the redacted representation so that recipients can check relationships to the underlying generated record and detect certain forms of tampering or inconsistent redistribution.
The structure matters as much as the encryption. If a vendor simply encrypts an entire SBOM, a recipient may receive confidentiality but lose the ability to search or compose the record. Petra instead keeps enough of the shape—the relationships between nodes and an indexable identity—to let an upstream record become part of a downstream one. A licensing consumer might need names and licenses. A vulnerability scanner might need versions. A verifier might be authorized to inspect much more. The point is not that one view is the correct view; it is that the same underlying exchange can support several authorized views without silently creating unrelated copies.
The evidence matters because redaction creates an obvious trust question: how does a recipient know that the producer did not remove an inconvenient claim before encrypting the rest? Petra’s answer uses commitments, Merkle-tree structures, signatures, and membership proofs. These mechanisms are intended to bind the redacted tree to a pre-redaction representation and to let a recipient check whether a particular element belongs where it is supposed to belong. When the record is redistributed inside a larger SBOM, an embedded proof can link the upstream representation to the parent structure.
Those mechanisms do not turn hidden content into public content. They make a claim about consistency possible without making the claim’s value universally readable. That is the sense in which Petra seeks verifiability without universal visibility.
The boundary is visible in the model. Petra can help a consumer establish that a redacted view corresponds to a generated structure, that a particular visible or authorized node is part of that structure, or that two recipients are not looking at different versions of the same artifact. It cannot establish, merely from those checks, that the hidden component list is complete or that a vulnerability was not omitted at generation time. Cryptographic evidence can make misrepresentation harder to conceal; it cannot supply facts that were never recorded.
This also means confidentiality is not the same as perfect invisibility. Petra’s design leaves relationships available because those relationships are needed for search, composition, and proofs. The shape of a tree, the existence of a dependency, or aspects of an access policy may reveal something even when a field value remains encrypted. A system that hides more structure might reduce some leakage, but it could also make membership proofs and composition more difficult. The design has to choose what to expose in order to remain useful.
The question that follows
Petra’s proposition is therefore deliberately balanced. A vendor does not have to publish every SBOM field to every participant, but a recipient should not have to accept a redacted record as an uncheckable assertion. The system tries to preserve a shared structural identity while distributing different amounts of semantic detail to different audiences. Its success depends on how those policies are chosen, how the underlying SBOM was generated, and how the cryptographic and key-management services operate.
That brings the problem to its proper starting point. Before asking how a claim is encrypted or how a Merkle proof is calculated, we need to ask what an SBOM must look like for its relationships to survive composition and redistribution at all. Petra’s answer begins with a data structure and a set of roles—not with a cipher applied to a finished file.