Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Friday July 03 2020, @10:41AM   Printer-friendly
from the friend-of-a-friend dept.

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


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Friday July 03 2020, @11:33AM (3 children)

    by Anonymous Coward on Friday July 03 2020, @11:33AM (#1015712)

    The advocate is stating something that should be trivially and painfully obvious to anybody in the field. And you can bet that it's not the low-level engineers who are the roadblock to testing the sub-sub-dependencies (well, not usually).

    But it sure is a lot of work to do it, because they're so many, and that sure costs a lot of money, so since they're just sub-sub-dependencies they cannot be important and we can skip the unimportant stuff (from result follows reason). Now where have I heard that line of reasoning before? Hint: a profession where you mostly deal with straight-line-diagrams and trivial maths.

    What will come of this article, if anything?

    An order from up high stating: "You must not use any library that has dependencies!!"

  • (Score: 2) by bradley13 on Friday July 03 2020, @12:53PM (1 child)

    by bradley13 (3053) on Friday July 03 2020, @12:53PM (#1015731) Homepage Journal

    Testing things like that is a literally endless task, because the libraries will be updated, at a schedule that you don't control.

    If you don't take the updates, you risk unpatched vulnerabilities. If you do take the updates, you will be constantly testing and re-testing. As new features are adding into the libraries, you might need to review and update your test cases as well - so even automatic testing won't entirely save you.

    Much as I love writing software, I am continually reminded of the quote: "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization."

    --
    Everyone is somebody else's weirdo.
    • (Score: 0) by Anonymous Coward on Saturday July 04 2020, @01:55AM

      by Anonymous Coward on Saturday July 04 2020, @01:55AM (#1015956)

      "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization."

      Or the wrong kind of virus.

  • (Score: 2) by TheRaven on Friday July 03 2020, @09:15PM

    by TheRaven (270) on Friday July 03 2020, @09:15PM (#1015857) Journal

    It's obvious because it's completely missing basic graph theory. The cause of 75% (or some similarly large number) of anything in software is going to be in indirect dependencies. If there's a bug in my program, it affects my program. If there's a bug in a library that things use directly, it affects everything that uses that library. If there's a bug in a library that is used indirectly by other libraries, it will affect anything that uses that library indirectly. A bug in any library that is used by two other libraries that are used independently will show up in more things than a bug in either of the libraries that use it.

    Equally, fixing a bug in a library that is used indirectly by thousands of programs is significantly cheaper than fixing thousands of instances of different bugs in different reimplementations of the same ideas.

    --
    sudo mod me up