Publishing SBOMs of webservers?

[DrakezulsMinimalism]

Hi everyone,

I saw that DT is now providing the SBOM at /.well-known/sbom and am surprised about that.

We mainly use DT/SBOMs to detect vulnerabilities in our dependencies and as such, the SBOM itself (and the resulting vulnerability information) is nothing I would like to be exposed for any of my servers/application that are not "distributed" to other parties.

I do understand that, if you ship an application to a customer, it might be a valid use case to "provide an SBOM to the customer", so that they can track it themselves.

Could we maybe "protect" this information with the normal authentication layer, or is my take on publishing SBOMs of (potentially vulnerable) applications wrong?

See #1363

[stevespringett]

@DrakezulsMinimalism I think you're describing a possible concern that SBOM is a roadmap to the attacker. Take a look at https://www.ntia.gov/files/ntia/publications/sbom_faq_-_20201116.pdf.

Publishing the SBOM to /.well-known/sbom helps consumers (organizations that use Dependency-Track), especially those organizations with multiple instances and versions of Dependency-Track deployed, as it provides a common URL in which to get the SBOM for their specific versions. This information is extremely useful to defenders.

The Dependency-Track project has published its SBOM for every release since v3.8. All SBOMs are available publicly from GitHub releases. https://github.com/DependencyTrack/dependency-track/releases. Source code is also publicly available so anyone could generate their own SBOM if they did not want to trust the accuracy of the ones provided.

[DrakezulsMinimalism]

Hi @stevespringett,
yes, maybe I'm thinking into this direction, but not against "SBOM" of applications in general.

I'm more concerned about the use of an SBOM provide in ".well-known" to automatically scan servers/applications for an in-depth report without authentication.
But I also understand that authentication would be against the idea of .well-known public directories and an additional layer of complexity for the "automated scans" of the consumer/defender organizations.

I'd rather have Dependency-Track track its own SBOM automatically? [maybe, as an additional idea]

Even after reading the section "roadmap to the attacker" and agreeing with the justifications, the idea of a (public) webserver exposing so much information feels strange, especially since Dependency-Track centralizes a lot of potentially critical information itself.
But maybe this is just one of those stupid "corporate thoughts" ... after all, my organization even mandates to completely disable the "server" header.

Thanks!

[stevespringett]

Ah yes, disabling the "server" header. I remember those days. Didn't know orgs still did that. SBOM by itself isn't all that useful to advisories. It provides a list of components, many of which will contain known vulnerabilities. But according to many studies, between 90-95% of vulnerable components will not be directly exploitable by the applications that depend on them, Dependency-Track included. What is extremely valuable is the VEX, which describes the exploitability of vulnerable components. Dependency-Track currently does not provide a VEX and there are no immediate plans to do so.

If .well-known is a concern for the org, it can be disabled by editing web.xml.

See https://github.com/DependencyTrack/dependency-track/blob/4.4.1/src/main/webapp/WEB-INF/web.xml#L53