cyclonedx-node-module icon indicating copy to clipboard operation
cyclonedx-node-module copied to clipboard

transitive dev-dependency not properly detected as dev-dependency

Open erdengel-noah opened this issue 3 years ago • 8 comments

Hello. I am using Version 3.1.1 of the package and found a error in processing the dev dependencies that leads to wrong results. Using here the example of the package netmask. Which is a indirect child dependency of inline-css as you can see in package-tree.txt. And included inside devDependencies of our package.json.

Yet it appears inside of the generated bom file.

package-tree.txt

bom.txt

Another example are all items with: @types Which are typescript typings and all listed under devDependencies of package.json.

erdengel-noah avatar Nov 24 '21 13:11 erdengel-noah

this should be tested in a new integration test alongside in https://github.com/CycloneDX/cyclonedx-node-module/blob/master/tests/index.test.js

jkowalleck avatar Dec 08 '21 16:12 jkowalleck

hello @erdengel-noah,

i tried to reproduce your described behavior, but failed. see https://github.com/CycloneDX/cyclonedx-node-module/pull/227

i was able to show, that (transitive) dev-dependencies were detected as such and were now in the resulting SBOM. so i proved that everythong worked as expected, in contrast to your report.

could you help understand your setup that produced he unexpected result? could you upload the package-lock.json and the package-json wile somewhere? maybe create a repository that holds the package-file, the lock-file and the SBOM that was produced?

jkowalleck avatar Dec 13 '21 18:12 jkowalleck

I had remove some private packages and did a new check and uploaded it here here After following one of the @types findings, it seems to be that the child packages have referenced them wrong and thats why they pop up in the bom.xml , so that would work fine after all.

I still could not find a reason as to why "netmask" pops up in the list thought. In package-lock it is marked with dev: true too.

Thanks alot for looking into this and your assistance :-)

binaryangel-noa avatar Dec 14 '21 16:12 binaryangel-noa

Was unable to install the packages via npm ci. dont have credentials for https://pkgs.dev.azure.com/conplementag/_packaging/ABUS/npm/registry Tried to run npm i the setup without the package lock, to get at least a setup to create a sbom from. which failed with npm ERR! ERESOLVE unable to resolve dependency tree. was using npm v7.6.3 The lock file was created with an older version of npm, something below v7. so tried again with npm v6.14.15 which failed, as [email protected] had an issue in its post-install script. At that point i decided to put no more effort in the setup.

@binaryangel-noa could you create a working setup from the published lock-file via npm ci? that also includes the node_modules/ dir? You can have it git-staged via git add -f node_modules/, so its possible to commit it while it is in the gitignore-list. Make sure that package-manifest and lock file are consistent (this includes: don't modify the package.json manually. use npm subcommands if needed) After the setup was created, please update the shipped bom.xml accordingly and see if it still has the mentioned issues.

From there, we we might have a common test bed to reproduce your issue, isolate it and prepare a fix :-D

jkowalleck avatar Dec 15 '21 10:12 jkowalleck

I updated the repository and hope it works for you... Also did revert the package*lock.json to original state and removed the private packages from package.json with the npm command since i was not sure how i did it the first time around, the resulting package-lock.json remained the same.

If things keep being difficult to test for you, maybe you can describe what needs to be done to debug or trace it since it seems to be very specific to our application.

binaryangel-noa avatar Dec 16 '21 16:12 binaryangel-noa

Btw, i found today another package that is cleary dev but in the bom list: "pac-resolver" npm audit detects that one as dev dependency too and does not output them in its result list when scanning for vulnerabilities. There might be some more of which i am not sure yet as its always hard work to track back some of the possible false-positives that we later get as a result when using those boms as some turn out to be false-positives of dependency chaker itself :-)

binaryangel-noa avatar Dec 17 '21 10:12 binaryangel-noa

thanks for the update and the in-place example. was able to reproduce the CycloneDX bom you supplied in the repo.

was able to reproduce the reported issues in package tree via npm ls --prod & npm ls --dev

i suspect the outdated implementation of read-installed is causing this issue. hope that #215 solves this kind of issues.

jkowalleck avatar Dec 19 '21 17:12 jkowalleck

Cool! Thanks for looking into it!

binaryangel-noa avatar Dec 20 '21 08:12 binaryangel-noa