How a Redacted SBOM Remains Verifiable

Selective encryption answers one question: who may read a claim? Petra’s next question is harder: how can anyone know that the redacted tree was not rewritten before or after encryption? This chapter follows one SBOM from composition to redistribution and separates the jobs of commitments, Merkle roots, signatures, and membership proofs. The result is a practical way to judge Petra’s promise: a consumer may not see every value, but they can still obtain evidence about which structured record they received and, within their access, whether it remains consistent.

Two integrity views for two moments

The difficulty begins at the moment of redaction. Suppose a generator receives an SBOM for package foo, including a dependency bar, and the producer’s policy says that the version of bar is readable only by an authorized vulnerability scanner. After encryption, an ordinary consumer sees a protected node where the version would otherwise be. What prevents the generator from leaving out a version that would have mattered, or substituting a different value before applying the policy?

Petra addresses that question by keeping evidence from both before and after redaction. Before the claims are selectively protected, the system computes cryptographic commitments over field names and values and applies Merkle-style hashing to the relational SBOM tree. A commitment can be thought of as a sealed reference to a value: it is calculated from the value now, but is not intended to reveal the value to someone who only has the commitment. Petra uses randomized material in this construction, which is important for fields with small sets of possible values, such as licenses.

The pre-redaction material preserves more than isolated field values. Complex nodes also bind the relationships among their children. The commitment for a dependency is therefore connected to the commitments for its name, version, license, and other claims, rather than being a loose collection of unrelated seals. This gives the generator and an authorized verifier a representation of the tree that existed before claims were hidden.

Petra then constructs a second integrity view over the redacted tree. A protected field’s hash binds several ingredients: an indicator that the node is redacted, the access policy associated with it, the encrypted and salted field data, and the earlier commitment. A complex node binds its type, the pre-redaction material, and the hashes of its children. An unredacted node can be hashed directly. In either case, the post-redaction hash records how the node appears now and how it relates to the earlier structure.

The root hash summarizes the resulting redacted tree. If even one protected ciphertext, policy, child relationship, or other bound element changes, the expected root should no longer be reproducible under the assumed collision-resistant hash function. The root can also act as a content-addressable identity for the redacted SBOM. That is valuable for distribution: a recipient can refer to a particular structured representation rather than merely trusting that a distributor returned some file associated with the same package name.

A root is not a proof that a value is good. It is evidence that a particular collection of bound inputs produces a particular summary. The distinction is the foundation of Petra’s claim. If the generator constructed a tree that omitted a vulnerability, the commitments can consistently describe the incomplete tree.