-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Excluding development dependencies (e.g. npm devDependencies) #592
Comments
As it stands, there is not a consistent way to accomplish this across languages. In addition, we believe the packages that can impact the built software, like dev dependencies, should be disclosed in the SBOM. When VEX statements are fully implemented, that will be the place to indicate if packages do not impact the built software and how that is the case. |
While it's not supported for all package ecosystems, it looks like labeling dev dependencies is a feature of the Component Detection library. So I don't see how lack of support is a good reason not to include the feature. Npm is one ecosystem where it is supported. And this is the ecosystem where it's most needed (or at least requested). https://github.com/microsoft/component-detection/blob/main/docs/feature-overview.md FWIW, this was requested (and rejected) early on in #78. In the comments for this earlier issue, it was also pointed out that lack of component detection support seems like a bad/false reason not to implement the feature. |
I also disagree that "packages that can impact the built software" is enough of a rubric for including devDependencies cart blanch. A devDependency is often something used to assist the development of a package (e.g. express in webpack dev server), but has 0 possibility of impacting the shipped software itself. |
Development time dependencies (like npm
devDependencies
) do not belong in a software bill of materials (SBOM).Such dependencies are not "materials" of the "software", but rather tools used at development/build time.
Development dependencies do normally not concern external stakeholders, and it is therefore normally desirable to exclude them from a SBOM.
In my opinion, it would be most correct if
sbom-tool
excluded development dependencies by default.But that will introduce a behavioral breaking change for the tool.
So I guess instead there should be a way to configure this (command line arg?)
Can you please prioritize this feature request?
The text was updated successfully, but these errors were encountered: