Publish vs Share: Distributing SBOMs to Customers From Safeguard Portal

In Safeguard Portal (GA), publishing and sharing are two separate acts. Publish takes an SBOM from a project in Safeguard's Enterprise Software Supply Chain Manager (ESSCM) and creates an immutable copy attached to a product version. Share then distributes that copy as-is, by email invitation, a controlled link or a branded customer portal, and the audit trail records who viewed or downloaded what, and when.

That split is the whole point of this post. When a customer, an auditor or a regulator later asks "which SBOM did you give us for version 4.2?", the answer should be one file, with one timestamp, and a log entry showing who opened it. If the SBOM you sent and the SBOM you hold today can drift apart, you cannot answer that question cleanly.

One naming note before we start. Safeguard uses the word "Portal" for two things: the free entry tier of the platform and the SBOM publish and share product. Both are generally available. Unless a section says otherwise, "Portal" here means the publish and share product. The free tier gets its own section near the end.

Key takeaways

• Portal, the SBOM publish and share product (GA), separates Publish (an immutable copy moved from ESSCM) from Share (distribution of that copy as-is). That gives you a fixed record of what each recipient received.
• SBOM generation and analysis in ESSCM (GA) produces the project SBOMs that Portal publishes. Portal can also take SBOMs uploaded from other tools in SPDX or CycloneDX.
• Products and projects are different objects. A project is an internal scanning unit; a product is the external catalog item you publish and share. Products move through Draft, Review, Published and Archived.
• Sharing (GA) works three ways: direct invitations, configurable links (expiry, download limit, password) and a branded customer portal on your own domain, with NDA acceptance available per SBOM.
• EO 14028 and NTIA minimum element checks (GA) score each SBOM for completeness and show a gap analysis before you share.
• Audit trails (GA) log access, sharing and administrative events, export to CSV, JSON or PDF, and can be sent to a SIEM.
• Trust Center is early access. Use it for a public posture page if it fits, but plan your SBOM distribution around the Portal sharing flows above.
• The Portal free entry tier (GA) is a different thing: free signup, one existing repo plus one open source repo, one project per month, SCA only.
• The CLI (GA) can validate and scan a supplier's SBOM before you import it. Portal's documented /v1 REST endpoints are not available yet, so automation runs through the app and the ESSCM sync today.

What do EO 14028, CISA guidance, the CRA and FDA section 524B expect about providing SBOMs?

None of these texts says "use a portal". They say, in different words, that the people who depend on your software should be able to get an accurate SBOM for the version they run, under terms you have set, and that you should be able to show what you provided. The details differ enough that it is worth reading each one.

Executive Order 14028, section 4(e)

Executive Order 14028, "Improving the Nation's Cybersecurity", was published in the Federal Register on 17 May 2021. Section 4(e) lists the practices that federal guidance on software supply chain security had to include. Item (vii) is the one about distribution: providing a purchaser an SBOM for each product "directly or by publishing it on a public website".

Section 4(f) then directed the Department of Commerce, through NTIA, to publish minimum elements for an SBOM within 60 days. NTIA did so on 12 July 2021.

Item (vii) allows two delivery models: hand the SBOM to the purchaser, or put it on a public website. It does not require every SBOM to be public. Suppliers who choose direct delivery need access control and a record of what they delivered.

NTIA minimum elements (2021)

The NTIA report, "The Minimum Elements for a Software Bill of Materials", split the minimum into three groups: data fields, automation support, and practices and processes. The data fields are the seven most people remember: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data and timestamp.

The practices matter more here. Under Distribution and Delivery, NTIA says SBOMs should be available in a timely fashion to those who need them, with appropriate permissions and roles in place. Under Access Control, it notes that some suppliers will publish SBOM data while others limit it to specific customers, and that if access is controlled, the terms must be specified, including allowances for loading the data into the customer's security tools.

NTIA's Frequency practice says a new build or release needs a new SBOM, and a known error calls for a revised one. That is why "which version of the SBOM did we send?" is a real question.

CISA's 2026 minimum elements replace the 2021 list

On 29 July 2026, CISA, NSA, FBI and international partners released "2026 Minimum Elements for a Software Bill of Materials (SBOM)". CISA's page says it updates and replaces the NTIA 2021 minimum elements, after a public comment period on a 2025 draft.

The 2026 document adds new data fields: SBOM Author Signature, SBOM Data Format Name and Version, SBOM Generation Context, SBOM Tool Name and Version, SBOM Version, Component Hash Value, Component Hash Algorithm and Component License. It also gives SBOM Author, Component Producer, Component Identifiers and Component Version major updates.

For distribution, the 2026 text removes the separate Access Controls element and folds access into Distribution and Delivery. The new wording says SBOMs should be available promptly to those who need them, and that access controls may limit sharing with unauthorised parties but should not block sharing between authorised parties or stop organisations loading SBOM data into trusted security tools. It lists acceptable delivery routes: with the installation, through a version-specific URL, through an API to a database, or in a public repository.

Two consequences follow. The version of the SBOM document itself is now a minimum element. And access control is fine, but not if it stops an authorised customer from using the file.

CISA's SBOM Sharing Lifecycle Report (April 2023)

CISA's "Software Bill of Materials (SBOM) Sharing Lifecycle Report", published 17 April 2023, breaks sharing into three phases. Discovery is how a consumer learns the SBOM exists and how to get it. Access is the control the author or provider uses to decide who can view or use it. Transport is how the file actually moves.

The report grades each phase as low, medium or high sophistication, and says these are not a ranking you must climb. For Access, low means no authentication, or case by case decisions by whoever answers an email. Medium means authentication plus role-based or channel-based controls and a defined request process. High adds granular permissions and automated account creation, sometimes tied to proof of purchase. For Transport, low is an email attachment pushed point to point. The survey found SBOMs mostly moving by email or sitting in a repository consumers could reach.

Use that vocabulary when you evaluate any setup, Portal included: how does a customer discover the SBOM, how is access decided, and how does the file reach them?

NIST SSDF, practices PS.3.1 and PS.3.2

NIST SP 800-218, the Secure Software Development Framework version 1.1, describes what a release record should look like. PS.3.1 asks you to securely archive the files and supporting data for each release, with read-only access for those who need it. PS.3.2 asks you to collect, safeguard, maintain and share provenance data for all components of each release, with an SBOM as the example. Its notional examples read like a distribution checklist: share with acquirers under your policies in standards-based formats, protect integrity and let recipients verify it, and update the data whenever a component changes. The SSDF maps PS.3.2 back to EO 14028 section 4(e)(vii).

EU Cyber Resilience Act, Regulation (EU) 2024/2847

The CRA defines an SBOM in Article 3(39) as a formal record of the details and supply chain relationships of components included in the software elements of a product with digital elements. Annex I, Part II, point (1) requires manufacturers to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format that covers at least the top-level dependencies.

On distribution, the CRA is deliberately restrained. Recital 77 says manufacturers should not be obliged to make the SBOM public. Annex II, point 9 says that if the manufacturer decides to make the SBOM available to the user, the user information must say where it can be accessed. Annex VII lists the SBOM inside the technical documentation (point 2(b)) and point 8 covers providing the SBOM to a market surveillance authority on a reasoned request. Article 13(24) lets the Commission specify the SBOM's format and elements through implementing acts.

Timing matters. Article 71 says the regulation applies from 11 December 2027, with Article 14 (reporting obligations) applying from 11 September 2026 and Chapter IV from 11 June 2026. If you sell products with digital elements in the EU, you need a way to hand a specific SBOM to an authority on request, and possibly a published location you can name in your user instructions.

FD&C Act section 524B (medical devices)

Section 524B of the Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act, 2023 and codified at 21 U.S.C. 360n-2, applies to "cyber devices": devices that include software, can connect to the internet and could be vulnerable to cybersecurity threats. Subsection (b)(3) requires the sponsor of a premarket submission to provide the FDA with an SBOM, including commercial, open source and off-the-shelf software components. The section took effect 90 days after enactment on 29 December 2022.

The statute's SBOM obligation runs to the FDA, not to hospitals or patients. Expectations about what you share with device users come from FDA guidance, which you should read in its current form for your submission. What the statute does make clear is that the SBOM you submit for a given device version is a regulatory record, so you want to know exactly which one you sent.

What these sources have in common

The common thread is version precision and controlled access. That is what the Publish and Share split in Portal is designed around.

Why does Portal separate Publish from Share, and why does that matter for audits?

Safeguard's offering material puts it simply. Publish moves an artifact from ESSCM to Portal and creates an immutable copy. Share distributes it onward as-is. The Portal docs say the same thing: publishing creates an immutable copy, and sharing distributes that copy unchanged.

Without that split, you would be handing customers a living record. In ESSCM, a project's SBOM is updated by continuous scanning on push, on schedule or on release, and by enrichment, while vulnerability status changes daily. That is right internally and wrong for a customer, because Monday's document would not match what you could show on Friday.

Publish freezes a specific SBOM against a specific product version. Share never edits it. That gives three useful properties for an audit:

1. One answer per version. For version 4.2 of a product there is one published SBOM. If you later find an error, the NTIA Frequency practice and the CISA 2026 SBOM Version element both point you toward issuing a revised SBOM, not quietly editing the old one. In Portal, that means unpublishing with a reason and publishing a corrected version, so both events appear in the trail.
2. Delivery records point at a fixed object. A log entry that says "customer X downloaded the SBOM for 4.2 on 3 March" only means something if that SBOM cannot change after the fact.
3. Supplier conversations stay simple. Safeguard's own notes mention vendor conversations where a supplier asks what exactly you retained. With an immutable published copy, the answer is a file, not a reconstruction.

There is a practical consequence. Anything you want in the customer's copy, such as enrichment, supplier names or fixes for gaps the compliance check found, has to happen before you publish. After that, it is a new version.

Products versus projects: how a product groups SBOMs and moves through its lifecycle

Portal's docs draw the line in one sentence: projects generate SBOMs; products organise them for distribution.

A project is an internal scanning unit in ESSCM. It might be one repository, one container image or one service. It exists for development and security work, and it changes constantly.

A product is an external-facing catalog item: something you ship to customers. The docs list commercial applications, open source projects, internal tools shared externally, APIs and services, and hardware firmware as examples. A product has a name and a SKU (both required), plus an optional description, category, website and logo.

A product has versions. Each version has a version number, a release date, release notes and a support status. The docs list four version statuses: Pre-release, Current, Deprecated (still supported but superseded) and End of Life. Each version is where you associate an SBOM, either by linking a specific project and project version from ESSCM or by uploading a CycloneDX or SPDX file.

Separately, the product itself moves through a publishing workflow:

The grouping matters because a real product is rarely one repository. The product version is where you decide which project SBOMs represent what the customer installed, and that decision becomes part of the published record.

Product settings worth deciding up front:

• Visibility: public catalog or private.
• Auto-publish SBOMs: publish new versions automatically. Useful for frequent releases, but it skips the human look at the compliance score, so pair it with Require Approval or a strict compliance setting.
• Require Approval: inserts the Review stage before anything is published.

Step by step: publish a product version, share it, and read the audit trail

The walkthrough below follows Safeguard's Portal and ESSCM documentation. Where the docs name a screen or button, it is named here. Where they do not, the step describes the outcome instead.

1. Check the source SBOM in ESSCM first. Open the project from the Projects page and go to its Compliance tab to see EO 14028 status. The docs describe three states: Compliant, Partially Compliant and Non-Compliant. Fix gaps here, while the SBOM is still a living record. Common fixes from the docs: use package URLs so supplier information is present, use lock files so versions are exact, and enable continuous or scheduled SBOM generation so the timestamp is current.

2. Create the product. Go to Portal, then My Products, and click + New Product. Enter Product Name and SKU, plus any optional fields. Set Visibility, Auto-publish SBOMs and Require Approval. Click Create Product.

3. Add the version. Open the product, click + Add Version, and enter the version number (the docs use semantic versions such as 2.1.0), release date, release notes and status.

4. Associate the SBOM. In the version, click Associate SBOM, select the project, choose the specific project version and click Associate. If the SBOM came from outside Safeguard, click Upload SBOM instead and select a CycloneDX or SPDX file. For a product built from several projects, decide here which SBOMs represent the shipped version.

5. Review the compliance result in Portal. Open the SBOM's Compliance tab for the gap analysis and remediation guidance. If the score is not where you want it, go back to step 1 or enrich now. Do not publish and plan to fix later.

6. Publish. Make sure the SBOM is associated and the required fields are complete, click Publish, and confirm. If Require Approval is on, the product sits in Review until an approver accepts it. Once published, the copy is immutable.

7. Choose how to share. Portal offers three methods, and you can mix them per customer.

   • Direct sharing. Select the SBOM, click Share, enter recipient email addresses, set the permission level, add an optional message and click Send. Recipients get an email invitation.
   • Shareable links. Select the SBOM, click Create Link, set an expiration date, a download limit, password protection and format restrictions, then click Generate and send the link.
   • Branded customer portal. Go to Settings, then Customer Portal, configure branding and domain, assign the SBOMs to publish there, and invite customers to register.

8. Set permission levels and gates. The Sharing docs list three levels: View (online only), Download (view and download) and Full (view, download and re-share). At the SBOM level you can override organisation defaults, set a specific expiry, require NDA acceptance before access, and enable download notifications. Organisation-level controls include requiring authentication for all shares, restricting sharing to approved domains, setting default expiry periods and switching link sharing on or off.

9. Brand the customer-facing portal and use your own domain. In Portal Settings, the Customer Portal Branding options cover logo, favicon, primary colour and custom CSS, and email branding covers logo, footer and reply-to address. Under Settings, then Custom Domain, enter a domain such as an sbom. subdomain of your company domain, configure DNS records, verify ownership and enable it.

10. Read the audit trail. Navigate to Settings, then Audit Logs. Filter by date range, actor, action type or resource, and click an entry for full detail. Each entry carries a UTC timestamp, actor, action, affected resource, details, source IP address, user agent and result.

11. Export or stream the trail. From the filtered view, click Export and choose CSV, JSON or a formatted PDF report, then download it or schedule delivery. For continuous forwarding, configure Settings, then Integrations, then SIEM (see the SIEM section below).

12. Revoke or unpublish when needed. To cut off a recipient, open the SBOM's sharing settings, find the user or link and click Revoke; the docs say access ends immediately. To withdraw a version, open it, click Unpublish, provide a reason and confirm. Both actions land in the audit trail.

A note on the permission vocabulary: the My Products page describes product-level access as View, Download and Subscribe (update notifications), while the Sharing page describes SBOM-level permissions as View, Download and Full. Treat them as two layers, product access and SBOM permissions, and check both when you set up a customer.

How do the EO 14028 checks and NTIA minimum element checks work?

Portal and ESSCM both run the checks, at different points. ESSCM checks the project SBOM as it is generated. Portal checks the SBOM you are about to publish or share.

According to the Portal Compliance docs, automated verification looks at six things for each SBOM:

• Minimum fields: all NTIA minimum fields present.
• Component ID: unique identifiers for all components.
• Supplier info: vendor or supplier data included.
• Version info: specific version details.
• Dependencies: relationships defined.
• Hash values: cryptographic verification data present.

Each SBOM gets a compliance score. The docs band it as 100% (fully compliant), 80 to 99% (minor gaps), 50 to 79% (significant gaps) and below 50% (major remediation needed). The ESSCM EO 14028 page adds that the project-level score considers data completeness, format compliance (valid SPDX or CycloneDX structure), component coverage and update frequency, so a stale SBOM loses points even if every field is filled.

The gap analysis sits on the SBOM's Compliance tab. From the same area you can generate an EO 14028 Compliance Report, an NTIA Minimum Elements Report, a Gap Analysis Report or a Full Audit Package, exported as PDF or Excel. In ESSCM, the per-project report comes from Export, then EO 14028 Compliance Report, in PDF, HTML or JSON. The ESSCM page says plainly that there is no CLI command for this report yet.

Portal Settings let you turn the checks into gates:

• Auto-Validate checks SBOMs on upload.
• Require Compliance blocks non-compliant shares.
• Compliance Report includes the report in shares.
• Under NTIA Minimum Elements, Enforce Minimums requires all elements, Warn on Missing alerts on gaps, and Auto-Enrich fills in missing data.

If you switch on Auto-Enrich, remember the Publish rule. Enrichment should run before publishing so the immutable copy is the enriched one.

The checks test whether the SBOM is complete and well formed. They do not prove that the component list matches the binary you shipped; that depends on generating the SBOM from the release build or image rather than a developer branch.

One more caveat. The Safeguard docs describe the checks in terms of the seven NTIA 2021 data fields plus the six verification items above. CISA's 2026 minimum elements, which replace the 2021 list, add fields such as SBOM Author Signature, SBOM Generation Context, SBOM Tool Name and Version, SBOM Version and Component License. Hash values overlap. If a customer contract cites the 2026 elements, check those extra fields yourself or confirm with Safeguard how the current scoring treats them.

How do customers find and review SBOMs?

The receiving side of Portal is called Find & Review SBOMs. It serves your customers when they look at your published products, and it serves you when you review SBOMs from your own suppliers.

From Portal, then Find SBOMs, a user can search by product name, SKU, supplier, component or version. Advanced search filters by date range, format, EO 14028 compliance and vulnerability severity. The docs show a small query syntax, for example:

component:log4j
supplier:"Acme Corp"
version:>=2.0.0
supplier:"Acme" AND component:spring

Results show product, supplier, latest version, last update, compliance status and component count, and can be filtered by access (Public, My SBOMs, Shared with me). Opening an SBOM gives tabs for components (with versions, package URLs and supplier data), vulnerabilities (CVE list, CVSS, fix availability, exploitation status), licenses (types, compatibility, attribution requirements) and a quality tab with a completeness score and missing fields.

For your customers, three features matter most:

• Version comparison. They can compare two versions of your product and see added and removed components, version changes, and new and fixed vulnerabilities. This is often the first thing a customer security team asks for at upgrade time.
• Request access. For private SBOMs, a customer can click Request Access, give a justification and track the request through Pending, Approved, Denied and Expired. That is the medium sophistication access pattern from CISA's lifecycle report: authentication plus a defined request process.
• Subscribe. A customer can subscribe to a product's SBOM and choose notifications for new versions, vulnerability updates and compliance changes. Your side can see subscriber counts in the product's Analytics tab, alongside views, downloads and shares.

Downloads can be the original file or a conversion to CycloneDX JSON, SPDX JSON, CSV or a PDF report. That helps with the CISA 2026 point about not blocking authorised use: a customer can pull the file in the format their own tooling ingests.

If the customer uses Safeguard too, the docs describe a Link to TPRM action that associates a found SBOM with a vendor profile in Third-Party Risk Manager (GA). That is how your published SBOM becomes part of their supplier risk record. Our post on supplier software risk under DORA, NIS2 and M-22-18 with Safeguard TPRM covers that side.

How do you import SBOMs produced by other tools?

Not every SBOM you distribute will come from an ESSCM scan. Some products are built by a separate team with its own generator. Some components arrive from suppliers with an SBOM attached. Portal accepts both.

The SBOM Repository docs describe three routes in:

1. ESSCM sync. Under Settings, then Integrations, enable Enterprise ESSCM Sync, select the projects to sync and set the frequency. Portal Settings list real-time, hourly and daily options, plus a project filter and a version mapping rule for how project versions map to product versions.
2. Manual upload. Click Import SBOM, select the format, upload the file or paste the content, assign it to a product and version, and click Import.
3. Upload to a product version. As in step 4 of the walkthrough, upload a CycloneDX or SPDX file directly against a version.

Portal Settings list the import formats as CycloneDX and SPDX, plus the native output formats of two widely used open source SBOM generators. The SBOM Repository docs also show a REST call for imports, but the page carries a banner saying /v1 endpoints are not yet available and return 404, so do not plan CI automation around that endpoint today.

Before you import an outside SBOM, validate it. The Safeguard CLI (GA) has a validator and can scan an existing SBOM for known vulnerabilities. These commands are taken from the CLI usage docs:

# Check a document against the CycloneDX, SPDX or VEX specification
safeguard validate sbom.json

# Check a whole folder of supplier SBOMs
safeguard validate ./sboms --recursive

# Treat warnings as errors and write a report
safeguard validate sbom.json --strict -o report.json

# Match the components in an existing SBOM against vulnerability databases
safeguard scan --sbom sbom.json

The docs say the validator checks CycloneDX (JSON and XML), SPDX (JSON, YAML, tag-value and RDF) and VEX (CSAF and OpenVEX) documents against their specifications, and that strict mode treats warnings as errors. A file that fails validation will also score badly in Portal, so it is cheaper to catch it at the command line.

Once imported, the SBOM shows its source and original format in the repository record, alongside product, version, component count, creation date and EO 14028 status. Version comparison works on imported SBOMs too, so you can diff a supplier's latest file against the previous one before you publish a product that includes it. For SBOM formats and generation in more depth, see SBOM generation and analysis in Safeguard, from NTIA minimum elements to the CRA.

How do audit trail exports reach a SIEM?

The audit trail is where Portal earns its place in an audit. The Audit Trails docs group what is logged into three categories:

There are two ways to get these events out.

Export on demand. In Settings, then Audit Logs, set your filters, click Export and choose CSV, JSON or PDF. You can download the file or schedule delivery. This is the simple route for a quarterly review or an auditor's sample request: filter to one product's SBOMs and one customer, export, attach.

Continuous forwarding to a SIEM. Configure it under Settings, then Integrations, then SIEM. The docs list several named SIEM and log platforms plus a custom webhook, so if your platform is not on the list, the webhook is the fallback. Portal Settings also have a separate webhook configuration for notifications (URL, events, signing secret, active flag), which is useful if you want share and download events to trigger your own workflow rather than land in a log store.

Retention is documented as well. According to the Audit Trails page, default retention is two years for access logs and seven years for administrative and security event logs, and enterprise customers can configure custom retention. If a regulation or contract requires longer, forward to your SIEM or archive the exports, and make sure that store has its own retention policy.

Once events arrive, build a per-customer delivery report (downloads grouped by actor and product version), an alert for one link used from many source IPs, which can mean it was forwarded, and an alert when someone widens a share or turns on public links.

The Portal free entry tier versus the Portal product

This is the naming problem we flagged at the top. Safeguard's offering material is clear that "Portal" means two different, real things, and the company is reviewing the name.

The Portal free entry tier (GA) is the self-serve front door to the platform: free signup, scan one existing repo plus one open source repo from GitHub, GitLab or Bitbucket, one project per month, SCA only. It is about scanning your code. It does not give you the product catalog, branded customer portal, NDA gating or audit trail export described in this post.

Portal, the publish and share product (GA) is everything above: My Products, the SBOM Repository, Find & Review, sharing, compliance checks, audit trails, settings and user roles.

The Portal docs page makes a related point in its own words: being on the platform's free plan does not mean you have a Portal entitlement, and Portal can be bought on its own. If you are scoping a purchase or comparing quotes, say which "Portal" you mean, and ask Safeguard which entitlement covers the publishing features you need. Our earlier Portal free tier post covers the entry tier, and the Safeguard Portal deep dive covers the product.

Where does Trust Center fit?

Trust Center is early access. Safeguard describes it as a way to publish live security posture as a public page on your own domain, share SBOM, VEX and AI-BOM documents, and answer security questionnaires. Portal's docs describe Trust Center as the front of the Portal product.

For SBOM distribution specifically, the sharing flows in this post (direct invitations, links and the branded customer portal) are the GA path. If you also want a public posture page, evaluate Trust Center with a scoped demo and treat its depth as still growing. Our step by step guide, set up a Safeguard Trust Center (early access), and the earlier Portal Trust Center post cover it.

If customers will ask "does this CVE in your SBOM affect us?", pair the SBOM with VEX. CSAF and VEX upload is GA in Safeguard; see ingest and share VEX and CSAF in Safeguard.

Requirement versus what Portal does versus what you still own

What Safeguard does not do

Honest limits, so you can plan around them:

• Sharing does not make the recipient's use compliant. Portal records that you provided an SBOM and who accessed it. It does not decide whether that meets a given contract, regulation or authority request, and it cannot make your customer's handling of the file compliant with their own obligations.
• Portal does not replace regulatory submission channels. An SBOM for an FDA premarket submission goes to the FDA through its process. A CRA request from a market surveillance authority is answered under your conformity process. Portal helps you find and prove the exact file; it is not the filing route.
• The compliance score measures completeness, not truth. The EO 14028 and NTIA checks confirm that fields are present and the format is valid. They cannot prove that the SBOM matches the binary or image a customer runs. That depends on generating it from the release artifact.
• Coverage of the 2026 CISA elements is not documented. The docs describe checks built around the NTIA 2021 fields plus hash values. Do not assume new 2026 fields such as SBOM Generation Context or SBOM Author Signature are scored until Safeguard confirms it.
• No working Portal REST API yet. Several Portal docs pages show /v1 calls for products, SBOM imports, search and audit logs, and each page carries a banner saying those endpoints are not yet available and return 404 today. There is also no CLI command for the EO 14028 report. Automate with the ESSCM sync and in-app settings for now.
• Trust Center is early access. Do not build your only customer distribution channel on it yet.
• Portal cannot control a file after download. Revoking access stops future views and downloads. A file already downloaded can still be forwarded. NDA acceptance, watermarking (a documented setting) and the audit trail help with deterrence and evidence, not prevention.
• The free entry tier is not the publishing product. The free tier covers scanning one repo plus one open source repo, SCA only. The catalog, sharing and audit features in this post belong to the Portal product, and this post does not cover its pricing.

Common mistakes

Emailing the "latest" SBOM from the scanner. The project SBOM changes on every push. If you attach it to an email, you cannot later prove which state you sent. Publish a version, then share it.

Editing after publishing. If the published SBOM is wrong, unpublish with a reason and publish a corrected version. Overwriting a record that a customer has already downloaded breaks the audit value of the whole system.

Enriching after the fact. Auto-enrich and gap fixes belong before the Publish click. Enrichment in ESSCM after publishing does not change the copy a customer already has.

One product, one repository. Many products ship more than one project. If the product version is linked to only the main repository's SBOM, customers get an incomplete component list and the Depth practice in the NTIA guidance is not met.

Locking the SBOM down so hard it is useless. View-only access to a 3,000-component SBOM does not help a customer's vulnerability tooling. The 2026 CISA guidance says controls should not stop authorised parties loading SBOM data into their security tools. Give Download to authorised customers.

Leaving public links on by default. Organisation-level settings control whether link sharing is allowed and the default expiry. Set those once, deliberately, rather than relying on each person who clicks Create Link.

Forgetting retention. The documented default for access logs is two years, and some contracts outlive that. Forward to a SIEM or archive exports.

Ignoring the receiving side. If customers cannot discover your SBOM, the best access control in the world does not matter. Put the Portal location or customer portal domain in your product documentation, as the CRA's Annex II point 9 expects when you choose to make the SBOM available.

FAQ

What is the difference between publishing and sharing an SBOM in Safeguard Portal?

Publishing moves an SBOM from a project in ESSCM into Portal and creates an immutable copy attached to a product version. Sharing sends that published copy, unchanged, to specific people, through a link or through a branded customer portal. You publish once per version and share as many times as you need.

Can I change an SBOM after it is published in Portal?

Not in place. The published copy is immutable by design. If you find an error, unpublish the version with a reason and publish a corrected SBOM. Both actions are logged, which matches the NTIA and CISA guidance to issue a revised SBOM rather than silently edit one.

How do I share an SBOM with a customer under NDA?

Publish the product version, then share the SBOM by direct invitation or through the customer portal and turn on NDA acceptance in the SBOM-level access controls. You can also set an expiry and download notifications for that SBOM.

Does EO 14028 require SBOMs to be public?

No. Section 4(e)(vii) allows providing an SBOM to a purchaser directly or publishing it on a public website. Many suppliers share privately with each customer. Portal supports both, with optional public links controlled at the organisation level.

Does the EU Cyber Resilience Act require me to publish my SBOM?

No. Recital 77 says manufacturers should not be obliged to make the SBOM public. The CRA requires you to draw one up (Annex I, Part II, point 1), keep it in the technical documentation, provide it to a market surveillance authority on a reasoned request, and tell users where to find it if you choose to make it available.

What does the Portal EO 14028 compliance score check?

Per Safeguard's docs: NTIA minimum fields, unique component identifiers, supplier information, version details, dependency relationships and hash values. It scores each SBOM and shows a gap analysis. It checks completeness and format, not whether the SBOM matches the shipped binary.

Can I import SBOMs created by other tools into Portal?

Yes, CycloneDX and SPDX uploads are accepted. Validate supplier files first with safeguard validate, and use safeguard scan --sbom to check their components for known vulnerabilities.

Can I send Portal audit logs to my SIEM?

Yes, under Settings, then Integrations, then SIEM, which includes a custom webhook option. You can also export filtered logs as CSV, JSON or PDF.

Is the Portal free tier the same as the Portal product?

No. The free entry tier is a scanning tier: one existing repo plus one open source repo, one project per month, SCA only. The Portal product is the SBOM publishing and sharing system with catalog, sharing controls, compliance checks and audit trails. Both are GA, and both use the same name.

Can I automate Portal publishing through the API?

Not through the /v1 REST endpoints shown in the Portal docs; those pages say the endpoints are not yet available and return 404. Today, use the ESSCM sync settings and the product's Auto-publish option, ideally with Require Approval so a person reviews each release.

From a published SBOM to fewer findings in the next one

Every SBOM you publish shows your customers the vulnerable components you shipped in that version, and the immutable copy will keep showing them. The way to change what the next published copy says is to fix those components before the next release, which is what the section below covers.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos do not show Portal screens. They show the surfaces around it: how project scans that feed your SBOMs are run, and how an AI assistant can be given scoped access to your Safeguard data.

The first demo connects Claude to the Safeguard MCP server (GA) with OAuth and shows how you choose which tools Claude can use. For SBOM distribution, the same idea applies to anyone you let near your data: decide deliberately what an assistant may read or act on, the way Portal's roles and sharing levels decide what a customer may see. Publishing a product version stays a deliberate action in the app.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session (GA): install, open the interactive terminal, ask it to fix a lodash CVE, approve each command, and finish with /scan .. A signed-in scan from the interactive terminal uploads the SBOM and findings, never your source, so it creates or refreshes the project SBOM you later associate with a product version. Fixing the CVE before the release is what keeps it out of the copy you publish.

Click through it at your own pace, or open it full screen.

To try it on your own projects, start from safeguard.sh/download, and read the Portal and ESSCM guides at docs.safeguard.sh/docs. For background on sharing patterns, see six SBOM sharing patterns compared and Safeguard Portal and customer transparency.

Quick check

Sources

• Safeguard docs: Portal
• Safeguard docs: Portal, My Products
• Safeguard docs: Portal, SBOM Repository
• Safeguard docs: Portal, Sharing
• Safeguard docs: Portal, Compliance
• Safeguard docs: Portal, Audit Trails
• Safeguard docs: Portal, Settings
• Safeguard docs: Portal, Find and Review SBOMs
• Safeguard docs: ESSCM, EO 14028 Compliance Checks
• Safeguard docs: CLI
• Safeguard docs: CLI usage
• Safeguard: Portal product page
• Executive Order 14028, Improving the Nation's Cybersecurity (Federal Register, 17 May 2021, via GovInfo)
• NTIA: The Minimum Elements for a Software Bill of Materials (12 July 2021)
• CISA: 2026 Minimum Elements for a Software Bill of Materials (29 July 2026)
• CISA: 2026 Minimum Elements for an SBOM, full text (PDF)
• CISA: 2025 Minimum Elements for an SBOM, request for comment
• CISA: Software Bill of Materials (SBOM) Sharing Lifecycle Report (17 April 2023)
• NIST SP 800-218, Secure Software Development Framework version 1.1 (PDF)
• Regulation (EU) 2024/2847, Cyber Resilience Act (EUR-Lex)
• 21 U.S.C. 360n-2, FD&C Act section 524B, Ensuring cybersecurity of devices (LII)

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.