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: 3, Insightful) by The Mighty Buzzard on Friday July 03 2020, @03:36PM (5 children)
All of the above assumes you're A) Capable of writing every library you need without adding your own bugs or huge performance degradations and B) Have the time to do so. I dunno about you but I'm just not interested in reading up enough to competently write my own Vulkan, H.265, NVIDIA driver, or PCRE implementation. I don't even really care to write my own database or stdio libs. I'd much rather be writing the bits that are the actual purpose of the project in the first place.
Which is to say, this kind of thing is fine for projects with trivial functionality, enormous manpower, or extremely constrained requirements but ludicrous for most anything else.
And this is coming from a guy who's been writing zero-library code for industrial equipment as his latest "How little work can I do and still afford fishing gear?" project.
My rights don't end where your fear begins.
(Score: 2) by RS3 on Friday July 03 2020, @06:40PM (2 children)
All good points. I broke the rules and read TFA, and my comments in this discussion, and maybe bradley13's too, are in context of the problem areas:
ftfa:
I don't think TFA refers to drivers, or really anything else written in c or compiled languages, stdio, etc. They mentioned php and Python as having some of the problem, but very low percentage so far.
Oddly, they made no mention of perl... :)
(Score: 3, Insightful) by The Mighty Buzzard on Saturday July 04 2020, @04:20AM (1 child)
That's because Perl guys are all old and wise enough to spot someone spouting ideology instead of good sense. There are plenty of libraries that I use on a regular basis simply because I'm not willing to spend twice as long coding a single library as I do coding the core application. There's just no way I'm writing an entire IRC library from scratch every time I decide to rewrite my bot MrPlow in a new language to (re)familiarize myself with it. It's not conscientious, it's bloody stupid.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Saturday July 04 2020, @07:23AM
One thing Perl has is thousands of insecure libraries that no one really looks at. But they also have thousands of secure packages that are well-vetted and well-used. Instead of a fractured NIH-RTW ecology, there are a good number of modules on CPAN and elsewhere that are a de facto standard library. Everyone uses them for a particular problem, they are simultaneously stable and maintained, and professionals of various beard length watch over them rather than rolling their own.
(Score: 2) by Common Joe on Saturday July 04 2020, @10:34AM (1 child)
I had to drop a "insightful" point upon you because you're right on the money.
I would add that frameworks -- a key cornerstone to a lot of applications -- depend on many libraries too.
(Score: 2) by The Mighty Buzzard on Sunday July 05 2020, @10:58AM
It honestly never even occurred to me not to just write the code for most things frameworks bring to the table. I mean, it's not like keystrokes are what takes up most of a coder's time and most of the shit frameworks do is stuff I could code with a wicked hangover and a bunch of noisy fuckers in the room.
My rights don't end where your fear begins.