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: 2) by HiThere on Saturday July 04 2020, @02:05PM (1 child)
The checksum is good. Minimum specified version is not. It requires that you trust later versions without knowing anything about them. Which is it?
Yes, I'm relatively ignorant of go. There are lots of languages out there, and I'm not expert in most of them, perhaps any of them depending on what you mean by expert. I read the go documentation and decided that code that was written was too subject to change by people supplying the libraries. Perhaps I was wrong, but a minimum specified version is *not* reassuring. Later versions being malicious is one of the things that have gotten Javascript programs in trouble. Also, I believe, Ruby. IIRC, it once even bit Debian, though they vet the changes pretty strictly. You need to be able to specify the exact version of the library AND the checksum to be secure. Any changes need the same testing as the original version. Well, that's a bit extreme, but it's close to correct. You need a good suite of tests, and changed libraries need to pass those tests without change (including without fixing any mistakes that your test answers depend on).
There are decent arguments that all code that uses non-system libraries should be run inside of a jail, but usually need for security isn't strong enough to justify that.
All that said, this is not an ideal world, and one must make do. But there's no reason to make things worse by increasing remote dependencies. Sometimes you must, but for that to be reasonable you need to ensure that they won't change in the future. There are clear advantages to dynamic linking, but they come at the cost of lessened security. When it's links to system libraries one can say "well, if the system is 0wn3d, then there's nothing one can do", but the same doesn't apply to remote code.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by darkfeline on Saturday July 04 2020, @11:18PM
>Minimum specified version is not. It requires that you trust later versions without knowing anything about them.
Minimum specified version means it uses the oldest version that satisfies the requirements. It does the exact opposite of what you seem to be talking about. Most dep managers like pip will use use the latest version available if you specify >=2.1. If you specify "require 2.1", Go will use the minimum specified version, i.e., 2.1, unless either your package or another explicitly specifies a later version, in which case Go will use the minimum specified version that satisfies that requirement.
Join the SDF Public Access UNIX System today!