The Question Every Customer Now Asks: Can You Prove What Is in Your Software
A few years ago, a vendor security review meant a questionnaire and maybe a SOC 2 report. Today, increasingly, it means a direct question: can you show us a software bill of materials for the product we are buying, and can you prove it is current. Regulators are asking the same question in different language. Executive Order 14028 pushed federal software supply chain requirements into the mainstream, and enterprise customers who sell into regulated industries have absorbed the same expectation and pushed it down to their own vendors. Transparency about what is inside a piece of software has moved from a nice-to-have into something close to table stakes for serious procurement conversations.
The trouble is that most organizations that can generate an SBOM internally have no good way to manage the version history, publish it externally in a controlled way, or answer the follow-up questions that inevitably come once someone actually looks at it. A generated SBOM sitting in a build pipeline is not the same thing as a governed artifact a customer, auditor, or regulator can rely on. That gap is what Portal's publish and share side is built to close.
Publish and share are not the same action, and the difference matters
Portal draws a clear line between two actions that look similar but are not. Publishing moves an artifact out of your internal scanning environment (ESSCM) into Portal and creates an immutable copy: a fixed, versioned record of exactly what you attested to at that point in time. Sharing takes that published artifact and distributes it onward, as is, whether through a direct link, a branded customer-facing portal, or an NDA-gated tracked share.
That distinction sounds procedural until a supplier conversation turns into an audit conversation. When a customer or regulator asks exactly what you retained and when, "we published this immutable version on this date, and shared it with you unchanged" is a very different, and much stronger, answer than trying to reconstruct history from a live, mutable file. The audit trail exists because the publish step created a fixed point to trail from.
What lives inside the publish and share surface
Underneath that publish and share distinction sits a set of purpose-built modules. My Products acts as your external-facing catalog, with version lifecycle management as products move from draft to review to published to archived. The SBOM Repository holds versions and tags and lets you diff one release against another, which matters when a customer wants to know exactly what changed between the SBOM you sent last quarter and the one you are sending now. Find and Review SBOMs supports discovery for the people on the receiving end. Sharing itself supports direct links, a branded customer portal, and NDA-gated, tracked distribution, so you retain visibility into who accessed what, even after you have handed something outward. Audit Trails export to SIEM, so the publish and share history is not siloed inside Portal but available to whatever compliance tooling your organization already runs.
Trust Center: available, and expanding
Trust Center is the newer, outward-facing piece of this surface: a public page on your own domain where you can publish your live security posture, share SBOM, VEX, and AI-BOM artifacts, and work toward auto-answering security questionnaires built on frameworks like SIG and CAIQ. It is a genuinely useful direction for exactly the transparency demand described above, a single place a customer or partner can go to see your posture without another round-trip questionnaire.
It is worth being precise here: Trust Center is early access, meaning it is real, in active use, and growing in depth, but it is not yet the finished version of itself. The right way to talk about it is "available, expanding," not as a fully mature, comprehensive product. If you are evaluating it, it is worth scoping a demo to your specific use case rather than assuming feature parity with a longer-established compliance surface.
Compliance verification, EO 14028, and NTIA minimum elements
The compliance module inside Portal supports EO 14028 and NTIA minimum-element verification directly, which matters increasingly for anyone selling into the federal supply chain or into enterprises that have adopted the same bar for their own vendors. Rather than manually checking an SBOM against a checklist of required fields, that verification runs as part of the publish workflow itself.
What this means for how you answer the transparency question
The shift underway is simple to state and hard to ignore: transparency about software composition is moving from a competitive advantage to a baseline expectation, driven by both regulation and by enterprise customers who have started asking their own vendors the questions regulators ask them. Having a governed publish and share surface, with real audit trails and a growing Trust Center presence, means that question has an answer ready before it is asked, rather than triggering a scramble each time a customer's security team sends a new request.
If your organization is fielding more SBOM and transparency requests than it used to, and you want a governed way to answer them rather than a one-off spreadsheet each time, take a look at what Portal's publish and share tools do at safeguard.sh.
