What the Prototype Proves—and What It Does Not

Petra’s prototype is evidence about a particular design under particular conditions, not a general certificate that confidential SBOM exchange is solved. The useful question here is twofold: what did the implementation measure, and which assumptions limit the meaning of those measurements? Reading the evaluation alongside Petra’s threat analysis lets us distinguish a practical demonstration of selective, verifiable exchange from claims about SBOM accuracy, governance, or production readiness.

What the prototype actually measured

The evaluation starts with a deliberately varied collection of 3,380 SBOMs, normalized and deduplicated from generated records and in-the-wild collections. The records range from artifacts with one package to artifacts with 5,002 packages. The average is 242 packages, the median is 122, and the standard deviation is 408. That spread matters because Petra’s cost is driven not only by the number of documents but by the shape of the relational tree and the policies applied to it.

The prototype turns ordinary SBOM data into Petra trees, applies redaction policies, and measures three related costs: the time to construct the tree, the storage size of the redacted representation compared with an unencrypted SBOM, and the time needed for encryption and integrity-related processing. It supports translation from SPDX and CycloneDX inputs, uses Package URLs for artifact indexing, and includes a key-management integration derived from Sigstore. These details establish what was evaluated: a working exchange construction with format compatibility and key issuance, not a hypothetical protocol described only on paper.

The storage result is favorable but conditional. The paper reports less than a 13 percent average increase in storage for redacted trees relative to their unencrypted counterparts. Policy complexity is the main driver. For a medium-sized SBOM of about 12 MB, a complicated policy pushes the increase above 13 percent, which the authors identify as a case where Petra may become undesirable for highly complex access scenarios. The result is not “encryption is cheap” in the abstract. It is that the tested design can keep the average structural cost moderate when its policies are not excessively elaborate.

The paper’s summaries use more than one metric, and those metrics should stay separate. The abstract says that exchanging a redacted SBOM in the prototype requires less than one extra kilobyte per SBOM and that decryption contributes at most 1 percent of the performance overhead during an SBOM query. The body reports storage as a percentage relative to an unencrypted representation and examines the processing passes themselves. An absolute per-document increment, a relative tree-size increase, a local encryption/decryption time, and a share of end-to-end query overhead are different measurements. They cannot be combined into one universal overhead number.

The processing results follow the architecture. Encryption and decryption have similar timing behavior, and the attribute-based encryption pass dominates the cost. That is consistent with Petra’s hybrid construction: symmetric encryption handles node data, while the attribute-based layer protects the keys associated with policies.