An open source project usually publishes a security policy, a private reporting channel, and release-time SBOMs in the open. A commercial vendor adds contracts, gated documents, and support commitments. Both should say how to report a flaw, what versions get fixes, and what they will not promise.
What both need
Regardless of model, three things belong on the page.
- How to report a vulnerability, and where.
- Which versions receive security fixes.
- Where to find release artifacts, including SBOMs.
RFC 9116, the security.txt standard, covers the first point for any organization. It defines a machine-readable file with a required Contact field and a required Expires field, so researchers can find where to report and know when the information goes stale.
Side by side
| Topic | Open source project | Commercial vendor |
|---|---|---|
| Reporting | Private channel in the repo or a security.txt | Same, plus contractual contacts |
| SBOM | Published openly with each release | Often gated, per customer or per release |
| Access control | None needed | Login or NDA for detail |
| Support promise | Reasonable effort, stated plainly | Terms in a contract |
| Evidence | Public repo, CI logs | Reports under agreement |
| Update notices | Release notes and advisories | Customer notices plus public advisories |
How SBOM publishing differs
CISA's SBOM Sharing Primer describes the open source pattern. Maintainers can generate source and build SBOMs in continuous integration and publish them in locations that follow naming conventions, such as those being developed by the OpenSSF SBOM Everywhere group. Because the files are public and consistently named, consumers can collect them at scale. The caution it lists is that consumers must map an application to its open source project, and some ecosystems are easier than others. The primer also notes that container image SBOMs can be stored in an OCI-compatible registry as an artifact.
For a commercial vendor, the primer's examples include email and portals with vetting and NDAs. The cautions are manual effort, legal steps, and slower delivery.
What an open source page should not promise
Do not imply a service level you cannot meet. A volunteer project that writes "fixes within 24 hours" is setting up a failure. Say what you can do: acknowledge reports, publish fixes in the next release, credit reporters if they wish. Say which versions are supported and for how long.
What a commercial page should not hide
If you build on open source, say how you track it. Customers know their product contains open source, and CISA's guidance asks SBOMs to include all components, including transitive dependencies. A page that skips this topic invites a long questionnaire.
Mixed cases
Many vendors maintain open source tools and sell a product. Keep two sections: one for the open project, with public SBOMs, and one for the commercial product, with its own access rules.
Try it yourself
Click through it at your own pace, or open it full screen.
See what a project inventory looks like before you decide how to publish it.
Where Safeguard fits
Safeguard's SBOM and dependency scanning works on both open and closed projects. Try a free scan at gold.safeguard.sh/scan.
Quick check
Should a small open source project publish an SBOM?
If you can generate it in CI, publishing it with each release helps downstream users and costs little.
Can the same page serve both models?
Better to keep separate sections, since access rules and promises differ.
Sources
- SBOM Sharing Primer, CISA
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA
Last reviewed: 19 October 2026.
