SoylentNews is people
SoylentNews
More than 75% of all vulnerabilities reside in indirect dependencies:
The vast majority of security vulnerabilities in open-source projects reside in indirect dependencies rather than directly and first-hand loaded components.
"Aggregating the numbers from all ecosystems, we found more than three times as many vulnerabilities in indirect dependencies than we did direct dependencies," Alyssa Miller, Application Security Advocate at Snyk, told ZDNet in an interview discussing Snyk's State of Open Source Security for 2020 study.
The report looked at how vulnerabilities impacted the JavaScript (npm), Ruby (RubyGems), Java (MavenCentral), PHP (Packagist), and Python (PyPI) ecosystems.
Snyk said that 86% of the JavaScript security bugs, 81% of the Ruby bugs, and 74% of the Java ones impacted libraries that were dependencies of the primary components loaded inside a project.
[...] Snyk argues that companies scanning their primary dependencies for security issues without exploring their full dependency tree multiple levels down would release or end up running products that were vulnerable to unforeseen bugs.
So dear Soylentils, how do you track vulnerabilities in libraries that you use in your projects and do you scan beyond direct dependencies?
Previously:
(2020-05-16) Nine in Ten Biz Applications Harbor Out-of-Date, Unsupported, Insecure Open-Source Code, Study Shows
(Score: 0) by Anonymous Coward on Friday July 03 2020, @01:06PM
Some of it is definitely self inflicted.
It's certainly possible to have too many dependencies, but most projects have mostly dependencies they need. If you didn't need the dependency, there's probably no code path that invokes it, so its bugs likely don't matter. It's bloat, but not dangerous.
Doing everything yourself is a practical impossibility, especially in the Java and Node ecosystems. You wouldn't accomplish anything anyway, you would just write your own bugs.
Some companies have cultures or policies that make it extremely difficult to update things that need to be updated. "If you update a dependency," they say, "we have to test everything from scratch! We can't afford to do that." This is an example of management making things difficult whenever they can see them. Some companies will let you update your application dependencies, but not the operating system. This is not any better.
The solution is simply for management to realize that a bug that happens because you didn't update things is not better than a bug that happens because you did update things. Not only are bugs more numerous in outdated code, they're also more dangerous.
The policy needs to be "every release you update all the dependencies unless something breaks," not "you never update anything until you absolutely have to." Sometimes you will have bugs as a result, but you were going to have bugs anyway.