Sharing SBOMs Securely Without Giving Too Much Away

SBOMs Create Transparency, But Not Without Risk

The Software Bill of Materials, or SBOM, has changed meaning in recent years. It used to be seen as a technical tool for internal inventory management. It is now required as evidence due to regulations. The European Cyber Resilience Act will require digital product manufacturers to reliably document the composition of their software. The NIS 2 Directive increases pressure on operators of essential entities to secure their supply chains in a traceable way. The United States Executive Order 14028 made the SBOM a requirement in government procurement as early as 2021. As a result, the bill of materials evolved from a voluntary artifact to a mandatory disclosure.

This rise in importance exposes a conflict of objectives that cannot be resolved, only managed. The bill of materials is designed to establish trust, enable verifiability, and allow quick response to vulnerabilities. Yet it also reveals how a software product is built. It lists third-party components, their versions, and potential vulnerability points. It lets people guess architectural choices and competitively relevant strategies. A complete bill of materials acts as both evidence and blueprint. Publishing it carelessly confuses transparency with surrender. This article argues that the way sharing is controlled, not just the act of sharing, determines whether it helps or harms.

Why Complete SBOMs Contain Sensitive Information

To see the importance of the conflict, it helps to examine what a complete bill of materials contains. It is not simply a list of libraries used. It frequently includes precise version numbers, the full transitive dependency chain, sometimes internal package names, references to private artifact sources, and metadata about the generators and build process. Each detail may seem harmless on its own. Taken together, they provide a detailed profile of a product’s technical makeup.

For readers of a developer publication, this risk is very clear. Applications built with Maven or Gradle often have deep, branched transitive dependency chains. A single library can pull in dozens more. A complete bill of materials shows these chains in full detail. It allows others to see which vulnerabilities may affect a product. It also shows which internal components the manufacturer uses, which frameworks it avoids, and where it is using outdated versions. This intended security measure can become a manual for attackers. The sensitivity of a bill of materials is not simply a side issue, but its core property.

Least Disclosure: Sharing as Controlled Disclosure

From this understanding comes the key idea: minimal disclosure, or least disclosure. This means you should only share as much as a person really needs for their purpose — no more — and you should be able to prove it.

This principle clears up a common misunderstanding. Many assume SBOM sharing means publishing everything. In reality, sharing a bill of materials does not mean making all details broadly available. It is a controlled act. Content, recipient, and context are weighed together. The key question is not whether to share, but what to share, with whom, and under what conditions. This shift sets apart controlled transparency from unintentional overexposure. A minimal disclosure approach views the SBOM not as a single document to send but as a database from which to generate specific views for each need. The technical architecture discussed next builds on this idea.

Different Recipients, Different Information Needs

To share only what’s needed, you first have to know who you are sharing with, because each group needs different info. You can think of four main groups, and what they need shapes the whole process.

The public typically only needs a basic view. For them, listing the component name, license, and project reference is enough. This satisfies the need for transparency, especially for open-source software, without revealing internal structure. Customers need more details. They must analyze risks and justify purchases. They rely on version levels and dependency metadata. Auditors and authorities focus on dependability, not detail. They require evidence that is verifiable and complete. Suppliers and internal teams need operational details. They work with deep data to manage and edit bills of materials together. These differences lead to an important reality. A single, universal SBOM view is too crude in both detail and security. Trying to serve all users the same way usually fails, frequently resulting in email attachments. This practice lacks control and should be avoided.

Public Transparency vs. Private Exchange

Because the recipients differ, a strong structural separation is needed. Any proper disclosure model must separate public transparency from private exchange. Public transparency is a deliberately limited, open view of the bill of materials. Anyone can access it. Private exchange is the controlled transfer of more detailed information to authorized parties. Do not combine these two modes, whether in technology or organization. If you do, the line between public and private details blurs.

Exodos Labs’ model shows this separation well and is used here as an example. It draws a clear line between a public “SBOM Trust Center” and a private “Secure Exchange.” The Trust Center gives a continuously updated, defensible public view. The Secure Exchange allows controlled sharing with specific organizations. The architecture’s main advantage is its clear separation. It makes overexposure harder by assigning public and private data to separate channels from the start. 

Redaction: Several Secure Views From One Bill of Materials

Separating public and private sharing does not fully explain how different views can come from a single database. This is where redaction becomes vital. Redaction is not only about deleting fields. It reduces, masks, aggregates, or hides information based on the recipient.

In practice, internal package sources and private registry references may be removed entirely. Transitive dependencies can be summarised rather than listed. Sensitive build and generator metadata can be hidden from certain recipients. Several secure views emerge from the full bill of materials. A minimal public view might show only the component name, license, and project reference. An extended view for authorized customers can include version and dependency details. A contractually protected view might be released after a non-disclosure agreement is signed. The example model supports such selective redaction and can create recipient-specific views. The key point is this: Do not distribute a complete bill of materials and then cut it down. Instead, generate intentionally designed views from the full data set. Each view ought to match the needs and openness suitable for its audience.

Access Control Beyond Simple Roles

Once you define the views, you must decide how to control access. Simple role models are often not enough. Just being a "customer" or "partner" does not mean someone should see everything. Whether a specific customer can access a certain view depends on more than just their category.

More appropriate is attribute-based access control, which combines a range of characteristics before releasing a view. Among these characteristics are the associated organization, the product-related entitlement, the contractual status, and, where applicable, the status of a non-disclosure agreement, the assignment to a specific release, the regulatory context of a request, the release status, and any temporal limitation on access. Only the interaction of these attributes decides which view a requester actually receives. The example model relies precisely on such attribute-based control, combined with the redaction described earlier. The conceptual added value lies in scalability: whereas rigid roles become unmanageable as the number of recipients and special cases grows, attribute-based rules can be enforced consistently even across large circles of recipients. With this, the question of who decides on disclosure is settled — complementing the previously treated question of what is concealed in the first place.

Demonstrability: Auditability and Release Binding

Controlled disclosure calls for not only that the right measure of information be given to the right party, but also that it be provable. Demonstrability here comprises two sides that belong together, because both answer the same fundamental question: what can the parties involved rely upon?

The first side concerns auditability. SBOM sharing is controllable only if it can be traced without gaps, who requested access, who granted it, which view was displayed, and which version was exported. The status of a non-disclosure agreement, its revocation, and temporal limitations likewise belong in this audit trail. An immutable audit trail transforms sharing from a passing file transfer into a provable transaction; in the event of dispute, it replaces assertion with evidence. The second side concerns the binding of a bill of materials to a concrete artifact. A bill of materials is dependable only when it is unambiguously established to which release, to which build, to which JAR or WAR file, to which container image, Git tag, artifact hash, or container digest it belongs. In the case of a security incident in particular, this assignment decides the capacity to act: without it, it remains open whether the bill of materials at hand actually describes the delivered artifact or a long-superseded state. Auditability thus proves who saw what and when; release binding proves what this view refers to in the first place. Together, the two establish the trust that a bill of materials is meant to instill.

CI/CD Integration and Conclusion

However demanding the mechanisms described may appear, in practice, they most frequently founder on a plain circumstance: manual maintenance. Bills of materials compiled by hand, updated after the fact, and published on static pages inevitably grow stale and thereby lose their value. The consequence is evident: the generation, validation, versioning, and publication of a bill of materials belong in the build and release pipeline. For development teams, this means close integration with Maven, Gradle, and CI/CD processes, so that a current bill of materials is generated with every build, automatically checked against quality criteria, and made publicly available. The example model illustrates this by feeding the Trust Center continuously from the supply chain, so that public disclosure always corresponds to the actual state, and the recurring question of which bill of materials is current does not even arise.

Against this background, the typical mistakes that a well-considered approach sidesteps can be named. They range from complete public publication, through dispatch by email, the mixing of public and private views and the absence of a redaction strategy, to missing release processes, deficient auditing, absent release binding, manually maintained disclosure pages, and unprovided-for means of revocation. Each of these mistakes is ultimately a variation on the same fundamental error of equating transparency with maximal disclosure.

It is precisely this equation that must be overcome. Bills of materials are necessary for trust, regulatory compliance, and the security of the software supply chain, yet maximal disclosure does not automatically lead to greater transparency. What is decisive is to provide information that is correct, up to date, and appropriate for the target group, and to do so demonstrably. Secure bills of materials arise not through complete publication, but through suitable views for the right recipient in the right context. Whoever takes this to heart transforms the bill of materials from a risk into an instrument.