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 Friday July 03 2020, @10:48PM (8 children)
OK, I'm not rust expert, and that's not the way I understood cargo as working. The objection still stands in a weaker form, but in that form it applies to all systems libraries. If your system needs to be secure you should include all the libraries you need statically linked. This can get bulky.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by The Mighty Buzzard on Saturday July 04 2020, @04:13AM
Their library handling is actually pretty sweet even if the libraries themselves are extremely unpolished and constantly breaking compatibility in the quest to use the shiny new coding thing. Have a look into it if you're actually interested.
My rights don't end where your fear begins.
(Score: 2) by fyngyrz on Saturday July 04 2020, @01:36PM (6 children)
Static linking, absolutely.
Bulk: RAM is cheap. Mass storage is cheap. CPUs can address very large amounts of RAM and easily access significant amounts of storage across multiple, very large storage devices. Even very large software can be loaded from mass storage very fast now.
The time to worry about executable size for desktop machines (and coming soonish for palmtops) is past, IMO. The remaining important goals to reach for these days are:
OPC, with the single exception of well-written and carefully validated public domain code, tends to impede those goals one way or another. And lawyers. Lawyers pollute everything they touch. Shakespeare's Dick the Butcher [wikipedia.org] had it exactly right, if for perhaps the wrong reasons, depending on how you read the intent.
--
Government: Designed to provide you with "service" and...
...the Media: Designed to provide you with Vaseline.
(Score: 2) by The Mighty Buzzard on Saturday July 04 2020, @02:59PM (4 children)
Okay, roll yourself a statically linked Linux distro. I'm curious to see how enormous it comes in at and if it'll even boot on a machine with less than 32GB of ram.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Sunday July 05 2020, @01:46AM (3 children)
This made me do the math on one of our test machines. Based on the output of lsof, grepping for "\.so", stating the results and multiplying by the allocation units, the resulting disk space used by shared libraries is 256,081,920 bytes allocated on disk and 31,531,820 bytes of memory. And this is for a machine that is basically running one service and 25 processes total including the counting process, ttys, and ssh or system ones. It'd probably be interesting to see how much bigger that would be on a machine running X/Wayland or general purpose. However, the various elimination optimizations would cut down on some of the needed space.
(Score: 2) by The Mighty Buzzard on Sunday July 05 2020, @10:46AM (2 children)
du -hs reports 698MB for /lib on this box. How much each binary would have added without shared libraries is another matter entirely though.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Monday July 06 2020, @05:12AM (1 child)
To be clear count I provided would be the total counting all repeated libraries multiple times to somewhat simulate them being included in each static executable based on lsof output. I also understand that the optimizers would remove unused parts of the code for each executable. Your comment just made me curious as to what some sort of ballpark might be on even a stripped down system. Perhaps if I am bored one day, I'll put the static USE flag and the static* flags in the build chain on one of the systems to see what comes out. I'll then stand there staring at the screen like Oppenheimer wondering what sort of monster I have unleashed.
I do find it somewhat interesting that the du -hs on the box is 83MB, just under 12% of your size. And most of that is kernel modules. I'm assuming you box has X11, generic kernels, and other incidental software on it as well, which means your /usr/lib and /usr/*/lib probably add up to a lot more than the 166 MB on the test machine here.
(Score: 2) by The Mighty Buzzard on Monday July 06 2020, @01:51PM
Daily driver desktop box, yeah. Can't cut out as much if you want to be able to hook random kit up without having to rebuild the kernel every time.
My rights don't end where your fear begins.
(Score: 2) by Pino P on Sunday July 05 2020, @02:24AM
Cellular data transfer quota to redownload the package after a security update is not cheap. Nor is mass storage cheap if it is already full and soldered to the mainboard of the paid-for appliance or phone. People are still using 8 GB Android phones where more than half the space is taken by the operating system and two copies of each application: the version that came with the operating system (for use after a factory reset) and the updated version downloaded from the device's app store. And the operating system tends to be incapable of moving a lot of applications to removable storage.