Open source projects, SBOMs and security

Question

I was just reading a StackOverflow question here, about extracting the version number from a node package.json file. And the simple

'read in the json and access the property in your build tool'

got huge number of

'no no no you risk exposing all your dependency versions to the client'

-type responses.

But I'm a bit confused when this relates to open source projects. Isn't the whole code base exposed in the repository? Package.json and all?

Also, hasn't there been a huge push lately for - especially enterprise and security-critical software - to make available Software Bills of Materials, so the exact composition of the software is made clear, both to the end user/purchaser and for allowing for automatic checking against any emerging vulnerabilities in its dependencies?

So which is it?

And let's not forget open-source licensing requirements, that sometimes specify that you should include a copy of the dependency's license?

I had built an app that I was going to open source, and I had used some tools to extract out every package dependency:

1. including all transitive dependencies
2. including all licenses where obtainable, and
3. the exact dependency version used to compile the app.

I was going to make that available to the end user. A kind of SBOM in itself.

I thought this was the right thing to do, but now I'm not so sure. Am I inviting security exploits by being so open about the dependencies? Or is it the right thing to do, as long as I'm using appropriate security auditing tools and not doing anything very obviously dangerous (allowing unfiltered, un-sanitized user input for example).

Answer 1

There is nothing inherently wrong in publishing all the dependencies (including their version) app used - or an SBOM, as you called it - at publishing time.

However, this may become a potential security risk when your way of publishing the dependencies makes it easier for an attacker to query the versions of server-side dependencies of your web application at run time, when the system is in production. That does not only give the operator of the system an easy way to scan which components which might require an update due to security reasons, but also attackers. You may consider such a feature for someone with administrative access, of course.

For critical security issues, expect the organization which operates your software (Open Source or not), to be quicker or more motivated or simply better enabled to fix a certain security problem by patching some dependency than you are. Hence, the dependency versions in your program may differ to some degree from the ones used in production.