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: 2) by zoward on Friday July 03 2020, @11:59AM (9 children)
I can't help feeling like this will get worse with snaps and flatpaks. I guess the $64 question will be: will the maintainers of all those snaps and flatpaks be better about keeping dependencies up to date than the distro itself? In some cases, yes. In many other cases .... well, I think I'll stick to system-wide libraries.
(Score: 2) by JoeMerchant on Friday July 03 2020, @12:03PM (5 children)
At least snaps and flatpacks won't bring in bugs with automatic updates of their dependencies.
We validate that our products meet our requirements. This necessarily has the giant hole of "can't prove a negative," but when we do security / pen testing if we find a vulnerability it tends to stay in the test protocols, so at least we won't get bitten by a future regression.
🌻🌻 [google.com]
(Score: 2) by mmcmonster on Friday July 03 2020, @02:04PM (3 children)
I'm not into coding anymore, so please correct me if I'm incorrect:
Can't programs require a certain version of a library?
ie: Will work with LibME > 5.4.*, 5.5?
Wouldn't that be better than having it install in a FlatPack 5.4.3? (So that if 5.4.4 comes out, the system can replace 5.4.3 and the application still run? If the application breaks with 5.4.4, it can change it's dependency accordingly)
(Score: 3, Informative) by JoeMerchant on Friday July 03 2020, @02:59PM (2 children)
What generally happens is the dependencies are stated like you say: 5.4 or greater. So, 5.6 comes out and has a regression in it, the dependency tree picks up 5.6 and accepts it because it's greater than 5.4, boom: your app now has the regression.
It's all wonderful theory that newer software is better, but that's far from guaranteed.
I'm not deep into the intricacies of apt / dpkg / etc. but I believe what the article is getting at is that, even if your app does place a dependency on libX 5.4 exactly, libX 5.4 may well have dependencies in its tree which are spec'ed like: libY 2.2 or greater, meaning that your libX 5.4 can still inherit a regression from libY 2.3 even though you've spec'ed it at 5.4 exactly.
It's "the price" that comes along with not reinventing the wheel. Thank dog that we've gotten away from rotating hard drives - there were layers of code in their firmware that nobody on the planet remembered how they work, yet virtually every rotating hard drive on the planet used those same layers of mystery code. Now we've got "wear leveling" code in the flash drives that is 10x more complex, but at least it was developed with slightly more modern concepts of version control.
🌻🌻 [google.com]
(Score: 2) by zoward on Friday July 03 2020, @03:56PM (1 child)
These are all good points. I wonder how many actual infections are due to out of date libraries vs. up-to-date with regression bugs?
(Score: 3, Informative) by TheRaven on Friday July 03 2020, @09:18PM
sudo mod me up
(Score: 0) by Anonymous Coward on Friday July 03 2020, @09:18PM
Bad news, snaps aggresively autoupdate. It is causing some ruckus in Ubuntu, because they are pushing more and more software via snaps, instead of .debs. https://news.ycombinator.com/item?id=23052108 [ycombinator.com]
(Score: 1) by petecox on Friday July 03 2020, @12:39PM (1 child)
I wonder the same about desktop webapps that bundle their own web runtime.
But with Android, Chrome OS and Edge OS (*Windows 10) now shipping Chromium with regular security updates handled by the Chrome team, perhaps frameworks such as Electron will evolve to become lighter-weight by calling a FFI to the system runtime instead of bundling their own.
(Score: 3, Informative) by driverless on Friday July 03 2020, @01:20PM
Perhaps pigs will fly.
Perhaps hell will freeze over.
Perhaps the Cronulla Sharks will win the NRL premiership.
Perhaps horses will grow horns.
Frameworks always acquire more bloat. It's a natural process, like Greek/Italian women, they're created to get bigger as time goes by.
(Score: 2) by HiThere on Friday July 03 2020, @01:58PM
You are assuming that the updates are improvements. Sometimes, though, they can be malicious. And malicious or not they can introduce *new* bugs, that weren't in the prior version. (As well as bloat.) Every update need to go through the same analysis as the original library to ensure that it doesn't break things. If it's not externally facing, then there is rarely a case that a working program is improved by a library change. And if the library isn't distributed with the program, the library can *become* an attack surface.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.