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: 2) by JoeMerchant on Friday July 03 2020, @12:03PM (5 children)

    by JoeMerchant (3937) on Friday July 03 2020, @12:03PM (#1015720)

    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]
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by mmcmonster on Friday July 03 2020, @02:04PM (3 children)

    by mmcmonster (401) on Friday July 03 2020, @02:04PM (#1015752)

    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)

      by JoeMerchant (3937) on Friday July 03 2020, @02:59PM (#1015761)

      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)

        by zoward (4734) on Friday July 03 2020, @03:56PM (#1015776)

        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

          by TheRaven (270) on Friday July 03 2020, @09:18PM (#1015859) Journal
          Vulnerabilities are typically due to out-of-date libraries. Other kinds of bugs are more common as a result of updating but not testing the library. There was a paper at EuroS&P this year that did an analysis of upgrading the libraries bundled with a load of popular Android apps to the latest version that claimed to be backwards compatible with the version that they shipped. Something ludicrous like 30% of them actually worked (i.e. didn't crash in a tiny bit of automated UI testing) after the upgrade.
          --
          sudo mod me up
  • (Score: 0) by Anonymous Coward on Friday July 03 2020, @09:18PM

    by Anonymous Coward on Friday July 03 2020, @09:18PM (#1015858)

    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]