The Shape of a Composable SBOM
Petra’s next design problem is not how to encrypt an SBOM but how to give every later operation a stable object to act on. By following Petra’s exchange roles and its SBOM tree, we can see why an upstream record can be included in a downstream artifact without every participant receiving the same plaintext. The useful result is a system model: who owns each decision, what crosses each boundary, and how the record keeps its relationships when it is reused.
Who owns each transition?
A confidential SBOM exchange starts before any cryptographic operation. Someone has built a software artifact, decided what information should be available to which audiences, and arranged for an SBOM to be produced and delivered. Petra makes those responsibilities explicit because “the SBOM system” is not one actor. A party that creates the software does not necessarily run the generator. The service that stores the record does not necessarily have permission to read it. The recipient that consumes an artifact may later have to publish a new record about a larger artifact.
The software producer owns the artifact and authors the redaction policy. In the paper’s model, the producer might be an open-source maintainer, an enterprise, or a government organization. The producer chooses whether the artifact and its metadata are public, restricted, or selectively visible. That choice is important, but it is not yet a proof that the choice is appropriate. Petra gives the producer a way to express the policy; it does not judge whether a producer has hidden too much.
The generator receives the artifact and dependency information and turns ordinary SBOM input into Petra’s representation. It may be a separate service or combined with the producer. Keeping the roles separate accommodates a practical situation in which one tool records one aspect of an artifact and another records something else. It also reflects the large number of third-party tools that already generate SBOM data. The generator’s responsibility is transformation: construct the relational representation, apply the policy, and produce the cryptographic material that later parties will check.
That separation creates a useful accountability boundary. The generator handles the plaintext while it is building the protected representation, but the producer is not expected to accept the result blindly. Petra’s process lets the producer check the redacted output against the underlying representation before endorsing it. In the paper’s threat model, producers and generators may still be untrusted or motivated to misbehave; their separation is therefore not a promise of honesty. It is a way to assign work and create points at which the output can be checked.
The distributor makes the result discoverable. It may store an SBOM in a hub or deliver it with the software artifact itself. Petra associates the record with an immutable artifact index, such as a Package URL, so that a consumer can ask for the SBOM belonging to a particular package rather than searching through an unstructured collection of files. A distributor can provide access to the record, but the architecture does not require the distributor to receive decryption keys for every protected field. This narrows what a storage or delivery service needs to know.
The consumer retrieves an artifact and its associated SBOM for deployment, assessment, or further composition. This role is deliberately fluid. When a consumer incorporates an upstream package into a new product, they become a producer of that new product. The new producer now has to construct a larger SBOM that includes information about the dependency while respecting the upstream producer’s access policy. Treating consumption and production as separate, permanent identities would miss the way software actually travels through a supply chain.
A verifier checks the record rather than merely receiving it. The paper imagines that this may be a trusted third party, such as an auditor or government agency, although other roles can also perform verification. The verifier can check format and contents, compare the distributed representation with what the generator produced, and use the available cryptographic evidence to assess integrity. The verifier’s authority can be broader than an ordinary consumer’s, but that does not make the verifier a substitute for the producer’s judgment or for a process that establishes whether the SBOM is complete.
The key-management service, or KMS, supports authorization across these boundaries. It authenticates principals, binds attributes to them, issues the keys needed to access protected fields, and manages expiration and revocation. It is a trusted service in Petra’s model, but it need not become a universal reader of SBOM contents. This distinction matters operationally: a KMS can decide whether a principal has the attributes required by a policy without being the repository that stores every plaintext claim.
The result is a chain of ownership and state transitions. The producer owns the artifact and policy. The generator creates the representation. The distributor stores or delivers it. A consumer obtains a view and may create a new composed artifact. A verifier checks the exchange, while the KMS controls the credentials that make particular views readable. Each transition moves a different object across a boundary: software, a structured SBOM, an authorized view, or evidence about the relationship between them.
This separation also explains why signatures or repository permissions alone are insufficient. A repository can restrict who downloads a file, but it does not automatically preserve the file’s identity when another producer embeds it in a new document. A KMS can issue a key, but it does not by itself describe whether the underlying dependency relationship was preserved. The system needs a data structure that makes those relationships explicit.
How the tree carries composition
A conventional SBOM format is a document, but the information inside it is relational. A package has dependencies. A dependency has a version, a supplier, a license, and perhaps vulnerability claims. An artifact may also contain a nested record produced by another organization. If these relations are flattened into a loose list of fields, it becomes harder to apply a policy to one claim without confusing it with a similar claim elsewhere. It also becomes harder to show where an upstream record belongs in a downstream one.
Petra addresses this by translating an SBOM into an SBOM tree. The root represents the SBOM document and carries a unique, indexable identifier. Beneath it are complex nodes for composite objects—such as an artifact or a dependency together with its metadata—and field nodes for individual claims. A field node might represent a name, a version, or a license. The exact value is a claim about a particular object, not just a string floating somewhere in the document.
Suppose package foo includes package bar. The tree for foo can contain a complex node for the bar dependency. Beneath that node, individual fields describe the claims associated with bar. An SBOM that was produced for bar can itself be inserted as a complex node. The upstream record therefore has a location inside the downstream tree. Its identity is not reduced to a copied paragraph, and the downstream producer does not have to pretend that they authored the upstream claims.
This arrangement preserves two kinds of meaning. The first is scope: a field belongs to a particular dependency or artifact. The second is provenance through composition: an embedded SBOM remains recognizable as a record about an upstream object. Those relationships are what later allow Petra to protect an individual claim while still allowing an authorized consumer to understand which component the claim describes.
The tree also provides an index. A consumer needs a stable way to discover the record for the artifact of interest. Petra uses a unique identifier at the root for that purpose. In the prototype, Package URLs provide an ecosystem-agnostic naming convention for software components. The important point is not the syntax of the identifier. It is that discovery refers to an artifact identity that can remain attached to the structured record as the record moves.
Petra does not encrypt every connection between nodes. Child references and the relational shape remain available so that the tree can be searched, composed, and traced. This is a deliberate trade-off. If the shape disappeared along with the values, a consumer might gain stronger structural secrecy but lose the ability to tell how a dependency relates to an artifact or where an embedded record belongs. Petra chooses to expose enough structure for those operations and to protect the claims that carry the most sensitive semantic detail.
That choice has a cost. A tree’s shape can reveal clues. A large group of children may suggest a dependency list, and an observer may infer something about the kind of object represented by a complex node. Petra’s tree is therefore not a claim of perfect invisibility. It is an attempt to keep the structural information needed for useful exchange while limiting access to the values that a producer considers sensitive. Later integrity mechanisms depend on the same visible shape, so hiding more of it would change the verification and composition problem rather than simply improving the design.
The representation is intended to be agnostic to a particular SBOM data format or software ecosystem. Petra’s prototype works with translations from formats such as SPDX and CycloneDX, and the paper also situates SWID tags among common SBOM schemas. Format agnosticism here means that the exchange model can operate on a common relational abstraction rather than requiring one vendor’s document format. It does not mean that Petra can infer the correct meaning of every field or repair an incomplete source document. Translation and semantic correctness are separate responsibilities.
That separation is easy to overlook. Imagine a producer encrypting every field related to a dependency under a different policy. The cryptography might still be valid, but an authorized party could be left with isolated fragments that no longer support a meaningful security or compliance decision. Petra can preserve the fact that the fields are related; it cannot decide whether the chosen policy has left enough of them available for a particular task. The policy author and the verifier still need domain knowledge about what an audience must see.
This is why the tree is more than an implementation convenience. It gives every later operation a stable coordinate system. A redaction policy can refer to a path. A consumer can request or verify a particular field within a dependency. A downstream producer can embed an upstream record at a known place. A verifier can reason about the same relational object even when the visible values differ by authorization. Without that shared structure, selective disclosure would tend to produce a collection of unrelated partial documents.
The model also explains what crosses each boundary. The generator receives artifacts and ordinary SBOM data, then returns a structured redacted record and the material needed to validate it. The distributor receives a record that can be discovered by artifact identity. The consumer receives the artifact, the redacted tree, and—depending on their attributes—plaintext for some fields and protected nodes for others. The verifier receives enough access and evidence to check the claims within their authority. The KMS receives identity and authorization information, not a mandate to make every SBOM field visible.
Now the next design question has a precise location. It is not “how do we encrypt this file?” It is “which paths in this tree should be readable by which attributes, while the tree remains useful to everyone else?” Petra’s answer begins with selective disclosure applied to claims rather than an undifferentiated document. The shape of the record makes that decision possible; the policy determines who can see each part.