3 ms·
I don't understand what exactly they're saying. Seems to me they're comparing apples, oranges, and cherries. I don't know if they're willingly doing this or if
by dkarapetyan 10y ago
I don't understand what exactly they're saying. Seems to me they're comparing apples, oranges, and cherries. I don't know if they're willingly doing this or if they're trying to make the problem sound harder than it is.
You only need to perform whatever security analysis is necessary after all your dependencies are resolved. This does not require anything "dynamic". You just call the packager manager, wait for all the dependencies to be resolved, then verify there are no vulnerable versions, which is just a matter of looking up the relevant pieces in some database somewhere.
Which is fine if that's what they're doing but this article seems to be just smoke and mirrors mostly.
- briandoll 10y agoWe published this because there are lots of legacy tools that approach this problem with two specific weaknesses: * Many tools just scan a text file where you declare your dependencies, which misses transitive dependencies and won't tell you exactly which versions are in use * They use incomplete datasets for vulnerabilities, like CVE. Most OSS projects don't create CVEs for vulnerabilities, so it is a mostly useless datasource. Besides having a complete view of the dependencies, we have a research team that is finding and disclosing new vulnerabilities all the time, which you can see here: https://www.sourceclear.com/registry/explore https://www.sourceclear.com/registry/explore
- dkarapetyan 10y agoThat's a lot more clear and a much better description. I didn't get any of that from the post. Instead you explained several disparate processes each of which has their place in security analysis and declared a specific version the winner.