Hi
Question about node packages. How is this analysed, and which option do you recommend?
Let me explain
If i send as scanpath just package.json, seems like it analyses only first level dependencies. In my scenario, no vulnerabilities detected
If i leave scanpath empty, it analyses all the dependencies in the project, and dependencies of the dependencies (it is, all the package.json in my workspace), and then, vulnerabilities are reported
Having said that... what is the right way to scan a node project?
I mean, if i have a dependency A, that uses a dependency B, that uses C, and C has a vulnerability, then, i understand that B has the same vulnerability as C, and also A has the same vulnerability, isnt it?
Thanks
That is one of the interesting questions for software composition analysis.
Does a bug (regardless of security) from a dependency's transitive
dependency affect the application. Unfortunately, the answer is that it
would take a lot of research to figure that out for each vulnerability. In
your example, does A use B in a way that uses the code in B that uses the
vulnerable code in C? Or alternatively, is the vulnerable code in C
automatically exposed just due to it being some framework that auto-exposes
the vulnerable bits - regardless of the use by A and B.
This is one of the reasons that, on top of software composition analysis,
some companies are also looking at RASP technologies. I can't give a good
view/opinion into how RASP (or other tools) help protect against vulnerable
libraries.
Best advice, keep your libraries as current as you can (i.e. patch often -
not just for security), use layered protections, etc. One of the reasons
you want to patch often is that when the critical security bug comes out -
very few patches are back ported, the resolution is almost always upgrade
to the safe version. If you've let your dependencies languish that upgrade
to a safe version could become much more time consuming.
--Jeremmy
On Mon, Sep 4, 2017 at 5:52 AM, javixeneize notifications@github.com
wrote:
Hi
Question about node packages. How is this analysed, and which option do
you recommend?Let me explain
If i send as scanpath just package.json, seems like it analyses only first
level dependencies. In my scenario, no vulnerabilities detectedIf i leave scanpath empty, it analyses all the dependencies in the
project, and dependencies of the dependencies (it is, all the package.json
in my workspace), and then, vulnerabilities are reportedHaving said that... what is the right way to scan a node project?
I mean, if i have a dependency A, that uses a dependency B, that uses C,
and C has a vulnerability, then, i understand that B has the same
vulnerability as C, and also A has the same vulnerability, isnt it?Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jeremylong/DependencyCheck/issues/870, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AA0qwn4Cp7iEU2h2d_eVNDGfKSxw0GUGks5se8hZgaJpZM4PLsu2
.
In addition to what Jeremy wrote, I also want to point out the multiple ways to scan a node project.
The node analyzer which relies solely on data in the NVD is typically not that useful since the Javascript community doesn't self-report (typically) and relies primarily on commits to track vulnerabilities. As a result of the ecosystem being relatively immature, the Node analyzer isn't that useful.
The NSP analyzer on the other hand, is very useful as it relies on a lot of manually curated data.
The two analyzers work entirely different. The Node analyzer works just like all the other analyzers. Every package.json will need to be scanned so npm install will need to be run before executing dependency-check on the entire application directory. This will likely lead to a ~100% false positive/negative analysis due to the issue stated above. To greatly simplify thing, as well as to dramatically increase the accuracy of the findings, I recommend using the NSP analyzer exclusively.
That said, the NSP analyzer will include transitive dependencies. When you scan the applications package.json, that file is submitted to the NSP service where it is analyzed and the results are returned. Only the main package.json file will need to be scanned (for Node anyway). The results will include transitive dependencies. However, you should know that devDependencies are not currently included. Refer to https://github.com/nodesecurity/nsp/issues/87
To further articulate some of the nuances Jeremy was pointing out is the fact that the Javascript community, in general, favors much smaller modules than most other ecosystems. Smaller modules and much more of them. There are exceptions of course. But in general, the number of Javascript dependencies will be much larger than the number of dependencies in say a Java project offering the same functionality.
So, when NSP finds a vulnerable module, there is a much higher probability that your application is actually using that code than in other ecosystems. As Jeremy pointed out, upgrade dependencies regularly.
See also #875
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
That is one of the interesting questions for software composition analysis.
Does a bug (regardless of security) from a dependency's transitive
dependency affect the application. Unfortunately, the answer is that it
would take a lot of research to figure that out for each vulnerability. In
your example, does A use B in a way that uses the code in B that uses the
vulnerable code in C? Or alternatively, is the vulnerable code in C
automatically exposed just due to it being some framework that auto-exposes
the vulnerable bits - regardless of the use by A and B.
This is one of the reasons that, on top of software composition analysis,
some companies are also looking at RASP technologies. I can't give a good
view/opinion into how RASP (or other tools) help protect against vulnerable
libraries.
Best advice, keep your libraries as current as you can (i.e. patch often -
not just for security), use layered protections, etc. One of the reasons
you want to patch often is that when the critical security bug comes out -
very few patches are back ported, the resolution is almost always upgrade
to the safe version. If you've let your dependencies languish that upgrade
to a safe version could become much more time consuming.
--Jeremmy
On Mon, Sep 4, 2017 at 5:52 AM, javixeneize notifications@github.com
wrote: