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).

  • Downvoters, please explain how I can improve this question or if you think it belongs somewhere else. Otherwise, try chrome://credits/ for an understanding of where I'm coming from.
    – zola25
    Aug 27, 2023 at 12:56

1 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.

  • Okay, thanks for the advice, I think it's important I leave out the version numbers, but I should include the license texts when they specify inclusion. I'm undecided on transitive dependencies, especially from npm. Look at chrome://credits/ - this is a close approximation of what I was going to distribute. Granted I am not google, and they haven't included version IDs.
    – zola25
    Aug 27, 2023 at 12:52
  • @zola25: I guess may answer wasn't really clear, see my edit. Querying all version numbers from the server side dependencies is fine for someone with admin access, it shouldn't just be available for everyone. License texts is a different thing.
    – Doc Brown
    Aug 27, 2023 at 14:05
  • 1
    My app is currently a static web app that, as things stand, runs exclusively in the browser with no backend API either - the only server side dependencies are devDependencies for build tools, and I'm not listing them. But I think I understand your point, in that it's dangerous to give away your exact server-side implementation - you've just provided an attacker with a nice narrowed down list of dependencies to probe.
    – zola25
    Aug 27, 2023 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.