Verifiability Without Universal Visibility
Petra answers the title question with a qualified yes. An SBOM can remain verifiable when some of its fields are confidential if the system preserves the relationships among claims, applies access rules to the claims rather than hiding the whole record, and carries cryptographic evidence from the original representation into every authorized view and downstream copy. This final synthesis connects those choices to the judgment they support: Petra is a way to make confidential exchange more accountable, not a way to make incomplete software information true.
That distinction is the practical conclusion of this series. Petra’s value is not that it makes information disappear. It makes the boundary around information explicit. A producer can decide that one consumer may read a dependency version while another sees only its name and license. A distributor can deliver the same structured record without holding every decryption key. A downstream producer can embed an upstream record without receiving all of its plaintext. A verifier can check signatures, roots, and proofs within the authority they have been given. What none of those steps can do is prove that the hidden facts were complete or correct when the SBOM was generated.
What verifiability means here
The most useful way to understand Petra is to separate four questions that are often compressed into the word “trust.” What is visible? What can a particular recipient decrypt? What can they prove about the representation? And what can they know about the software itself? The answers overlap, but they are not interchangeable.
The visible layer is the relational shape of the SBOM. Petra represents an artifact, its dependencies, and their associated claims as a tree. Complex nodes place composite objects in context; field nodes locate individual claims such as a version or license. The root carries an indexable identity, and child references remain available. This visible structure is what lets a consumer recognize that a claim belongs to bar, that bar belongs to foo, or that an upstream SBOM has a defined place inside a downstream record.
The decryptable layer is narrower. A producer attaches a policy to a path in the tree. A consumer’s attribute-bound key satisfies some policies and not others. An authorized vulnerability scanner may read the version fields needed for its analysis, while a licensing consumer reads names and licenses. Both can receive the same redacted tree, but the plaintext available to each differs. The protection is therefore selective in two senses: it selects fields, and it selects audiences.
The provable layer connects those views. Petra’s pre-redaction commitments and tree hashes bind the source representation before values are hidden. The post-redaction Merkle structure binds the encrypted values, redaction indicators, policies, and child relationships as they appear in the distributed tree. Signatures identify the generator’s output and the producer’s endorsement. A membership proof can show that a particular field is part of the structure associated with a root. When the upstream SBOM is placed inside a downstream one, an embedded root and proof preserve the link to the original redacted representation.
The factual layer remains outside those cryptographic relationships. If a generator failed to discover a dependency, a proof can still faithfully describe the incomplete tree. If a producer chooses a policy that hides every field needed for meaningful analysis, the policy can still be applied correctly. If the software contains a malicious component, integrity evidence about the SBOM does not detect that component. Petra’s proofs are about consistency, attribution, and authorized structure; they are not a substitute for generation quality, software analysis, or policy judgment.
This four-part distinction explains why the same redacted record can be useful to multiple parties. A distributor can make it discoverable without becoming a trusted interpreter of its contents. A consumer can verify that the record is associated with the named generator and producer before using the fields they can decrypt. A verifier with broader access can test stronger sameness properties. A downstream producer can preserve the upstream root even if they cannot read every upstream claim. The record carries different amounts of knowledge to different roles without becoming a collection of unrelated documents.
It also clarifies what Petra’s main security properties mean. Sameness connects a redacted representation to the pre-redaction tree under the generator’s construction. Membership establishes that a selected node lies beneath a particular root. Redistribution congruence requires an upstream record to retain its identity and protection when embedded in a larger record. Non-equivocation helps expose different copies presented as the same artifact. These are related safeguards, but each has a different scope and each depends on the recipient having enough access and evidence to perform the check.
The design’s central trade-off follows directly. Petra leaves relationships visible because hidden relationships would make discovery, composition, and membership proofs harder. It encrypts claims because claim values carry much of the sensitive semantic information.