Hi,

I noticed that the list of npm dependencies differs depending on which type is given.
If the input is a package-lock.json file with type "npm" only the dependencies of this file are being processed.
If the input is a .sln with no type, pgscan scans for nuget and npm dependencies. But for npm dependencies all package-lock.json files are being processed, also the ones under "node_modules". This results in different npm dependencies.

I don't think that package-lock.json files of node_modules should be processed since all necessary dependencies are part of my projects package-lock.json file.
Further, I would like to call pgscan on a .sln because all project dependencies (nuget and npm) are listed in one sbom file.

Anyone else have issues with this procedure? Or is there a valid reason why package-lock.json files of node_modules should be processed as well? I just think both pgscan calls should result in the same npm dependencies.

Thank you,
Caterina

Hi @Dan_Woolf,

so it seems to be a long known issue: https://github.com/NuGet/Home/issues/3116

Thank you for your help.
Caterina

Hi,

we noticed a delay between uploading a package and being able to do a nuget restore on a consumer of this package.

More specific:
We uploaded a new package "DAP.Common 7.0.13" to ProGet. Afterwards, we updated the dependency to this new version manually in a consuming project. We tried to call nuget restore but it failed with the following error: "Unable to find package DAP.Common with version (>= 7.0.13)". There were about 15 minutes between package upload and nuget restore. A few minutes later we tried it again and the package was found. But the package could be seen on ProGet right after the uplaod.
We were able to observe this behavior with several packages. If the dependency got updated manually in a consuming project, nuget restore failed for a certain time period.

Unfortunately, we can not say if the problem is still present if the nuget package manager in Visual Studio would have been used to update the package dependency.

Have you already seen such a behavior?

Hi @atripp

I think packages has to be iterated instead. I haven't seen dependencies beneath packages.
Further, the "empty" Key has to be ignored as it stands for the root project:

Maybe a little bit parsing would be necessary.
In lockfileVersion 2 a dependency was listed like this:

In lockfileVersion 3 it looks like this:

If desired, we can also upload package-lock.json files for testing via MyInedo.

We noticed that pgscan does not list any dependencies for one of our npm-projects.
After debugging into it and comparing it with other npm-projects we noticed that there is a difference in the lockfileVersion of the package-lock.json files. The "problem-project" has lockfileVersion 3 while the others have lockfileVersion 2.
pgscan tries to read the dependencies from the property "dependencies" which is a legacy-property from lockfileVersion 1. lockfileVerson 2 was downward compatible, but lockfileVersion 3 (used by npm v9) is not. The newest package-lock.json no longer has the property "dependencies" and all dependencies are part of the "packages"-property.
Here is the official documentation about it: https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json/#lockfileversion

Have you already noticed this breaking change in the package-lock.json files?

I already opened an issue for this topic on ghithub:
https://github.com/Inedo/pgscan/issues/33

Hi,

we have the assessment type "Manually Unblocked" which we have assigned to some vulnerabilities a while ago. Now we noticed that only 5-6 vulnerabilities are having this assessment even though we assigned it to more than that. How is this possible? ( ProGet 2022.29)

Further, after upgrading to ProGet 2023 on a test server (which is an exact copy of our live system) 0 vulnerabilities had this assessment. Somehow this information got lost. Is this already a known problem? Or is this behavior intentional?

Thanks

Looking at the Usage&Statistic of a package, we can see the Latest Version of a consumer.
We noticed that the Latest Version is not the highest version of a consumer, but the latest version uploaded.
E.g.: We uploaded a project in version 2.0.0 and 2.0.0 is shown as Latest Version in its dependencies. Afterwards we had to upload a fix from a branch in version 1.6.1. Now 1.6.1 is shown as Latest Versions in the same dependencies.
One could assume that only versions below 1.6.1 are affected if a vulnerability is found in the package.

Could anybody else observe this behavior? Is it supposed to work this way?