Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 9 submissions in the queue.
posted by Fnord666 on Saturday May 16 2020, @09:42AM   Printer-friendly
from the vet-your-libraries dept.

Nine in ten biz applications harbor out-of-date, unsupported, insecure open-source code, study shows:

Ninety-one per cent of commercial applications include outdated or abandoned open source components, underscoring the potential vulnerability of organizations using untended code, according to a software review.

Synopsys, a California-based design automation biz, conducted an audit of 1,253 commercial codebases in 17 industries for its 2020 Open Source Security and Risk Analysis report.

It found that almost all (99 per cent) of the codebases examined have at least one open source component and that 70 per cent of the code overall is open source. That's about twice as much as the company's 2015 report, which found only 36 per cent of audited code was open source.

Good news then, open source code has become more important to organizations, but its risks have followed, exemplified by vulnerabilities like the 2014 Heartbleed memory disclosure bug and Apache Struts flaws identified in 2017 and 2018.

Ninety-one percent of the audited applications had components that are either four years out of date or have exhibited no active development for two years. In 2019 – the time-period covered by the 2020 report – the percentage of codebases containing vulnerable components rose to 75 per cent, up from 60 per cent in 2018.

The percentage of applications afflicted with high-risk flaws reached 49 per cent in 2019, up from 40 per cent in 2018.

[Ed Note - The company that produced this report, Synopsis, is a vendor in this space and is not a disinterested party.]


Original Submission

Related Stories

More Than 75% of All Vulnerabilities Reside in Indirect Dependencies 75 comments

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.
(1)
  • (Score: 5, Insightful) by MostCynical on Saturday May 16 2020, @10:04AM (10 children)

    by MostCynical (2589) on Saturday May 16 2020, @10:04AM (#994937) Journal

    "include outdated or abandoned open source components" is not the same as "insecure", and does not mean it is "vulnerable"

    If your web form auto-calculates postage from a current look up cost table, but uses code from 2003, so what?

    However, if your banking website is secured using an open-source MD5 hash function, then you have bigger problems.. these are not equivalent, but it does enable Synopsis to wave bigger numbers about, trying to literally scare up business.

    --
    "I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
    • (Score: 0) by Anonymous Coward on Saturday May 16 2020, @10:34AM (1 child)

      by Anonymous Coward on Saturday May 16 2020, @10:34AM (#994947)

      "include outdated or abandoned open source components" is not the same as "insecure", and does not mean it is "vulnerable"

      I agree with you on this. If you look at some of the GNU system tools, some haven't been touched in years. They do their work and they just work.

      OTOH though, in the years that I have used open source software (since late 90's) I've seen numerous examples where I was advised to migrate away from a software component because it was unmaintained AND has security issues.

      • (Score: 2) by driverless on Sunday May 17 2020, @05:29AM

        by driverless (4770) on Sunday May 17 2020, @05:29AM (#995263)

        Also, this is the commercial world, with contracts and SLAs and support requirements. You can't just swap out a software component because it's newer and shinier, you have to do things under very carefully controlled conditions during service windows, with months or possibly years of advance planning and notice. We do commercial open-source and many of our customers are running ancient versions of the code for exactly these reasons, once it's in place and verified to be operating as required it doesn't get touched any more.

        We also have to deal with people who think you can upgrade your entire user base twice a week with the latest shiny whatever, like it was a smart phone app or browser. It's very hard, if not impossible, to get through to them that a lot of the world doesn't work like that.

    • (Score: 5, Insightful) by Booga1 on Saturday May 16 2020, @11:16AM (5 children)

      by Booga1 (6333) on Saturday May 16 2020, @11:16AM (#994954)

      if your banking website is secured using an open-source MD5 hash function, then you have bigger problems

      Your point is even more relevant than some might think. MD5 hashes are MD5 hashes, regardless of whether the code making them is open source, new, closed source, old, secretly done on the back end server, whatever.
      The problem isn't whether it's maintained or open source. Yet, their "report" is going to call it a "security problem" because it's old or some nonsense. But wait! We've got a solution to sell you so come on down and buy our awesome sauce and keep those nasty hackers at bay!

      • (Score: 3, Interesting) by JoeMerchant on Saturday May 16 2020, @02:21PM (3 children)

        by JoeMerchant (3937) on Saturday May 16 2020, @02:21PM (#994994)

        At a certain level of corporate management, the managers don't know anything but how to manage - and a purchased "solution" with a guarantee sticker on the contract is an end to that particular problem, in their minds - which is all that matters to them.

        If you haven't paid for it, there's nobody to blame when it goes wrong.

        --
        🌻🌻 [google.com]
        • (Score: 4, Interesting) by acid andy on Saturday May 16 2020, @03:01PM (2 children)

          by acid andy (1683) on Saturday May 16 2020, @03:01PM (#995004) Homepage Journal

          Sounds like FOSS could go out of fashion with these types then. Or rather, that's what vendors like Synopsis are probably hoping will happen.

          --
          Welcome to Edgeways. Words should apply in advance as spaces are highly limite—
          • (Score: 3, Interesting) by JoeMerchant on Saturday May 16 2020, @09:35PM (1 child)

            by JoeMerchant (3937) on Saturday May 16 2020, @09:35PM (#995147)

            FOSS is a pretty hard sell at bigger companies, ours is accepting it grudgingly because we grow by acquisition and all of the best and brightest acquisitions are full of open source. We still get periodic spasms of reporting requirements from the legal department, they ask for something they think they want (like a list of ALL OSS packages in the product with their license terms), I produce a vague sketch of what that will look like for them (our latest product comes with Ubuntu 18.04 - they were proposing a decomposition of every license in every piece of it...), they backpedal and decide they're happy with a list of "just the big stuff..."

            --
            🌻🌻 [google.com]
            • (Score: 1, Interesting) by Anonymous Coward on Sunday May 17 2020, @05:54AM

              by Anonymous Coward on Sunday May 17 2020, @05:54AM (#995267)

              Our legal department checks the entirety of the software that even touches our product or the machines it is made on. Because most licenses used anymore are standardized, you just have to look at it once to decide whether you like the terms or not. Then use the publicly available tools to track your database for changes. Packages and auditing systems make doing that a snap. Everyone's headaches have gone away since we formalized the process. For 95% of software, they don't even have to ask because our internal documentation already covers the Dos/Don'ts of a particular license and the system notices the addition automatically. Of course it is more work up front, but it drastically reduced the time it takes now, lowered various expenses and even increased productivity. We literally make money thanks to doing so.

      • (Score: 1, Interesting) by Anonymous Coward on Saturday May 16 2020, @06:52PM

        by Anonymous Coward on Saturday May 16 2020, @06:52PM (#995100)

        Where I work (I do not speak for them, btw). They are smart enough to know that. They *do* take it into consideration.

        But lets say the thing narfs itself up. Who will fix it? It is abandoned. So now you have to dedicate someone to reverse engineer the open source code. That takes time and money. At least the code is 'easier' to read because it is open.

        Old stuff that has not been updated may have known exploits to the 'black hat' community but not the 'white hat'. Is a worry for these groups that review this.

        You want to look at as a risk cost benefit. Not as a 'open source rulz, closed source droolz' PoV.

        Something like a MD5 hash collision will probably be decently obvious. Most of the attacks I have seen are 'bunch of garbage' plus the text to change. So you would probably see it.

    • (Score: 0) by Anonymous Coward on Sunday May 17 2020, @10:11AM (1 child)

      by Anonymous Coward on Sunday May 17 2020, @10:11AM (#995296)

      I agree with what you are saying *except*, the problem is that some don't even perform the most cursory of code audits. Or, security audits on methods/codeflow.

      So sure, some things are used in such a way, that it is irrelevant what its age is. Yet... I often get people defending that act, *after* they've looked at the code, and only then cry "See! It *is* safe, I was right!".

      That's not secure, because they very method of usage is akin to just hoping someone locked the front door .. or, even has a lock ON the front door. Checking when someone asks, isn't validating one is right...

      And yeah.. I know one can pick apart statements all over the place, so I'm not claiming you meant this. Or even missed this. Just.. felt it had to be said.

      • (Score: 2) by MostCynical on Sunday May 17 2020, @11:57AM

        by MostCynical (2589) on Sunday May 17 2020, @11:57AM (#995312) Journal

        The most secure program of all time was placed in a special folder, on web server, secured with the password "password".
        So now it isn't.

        --
        "I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
  • (Score: 2, Insightful) by sorpigal on Saturday May 16 2020, @03:40PM

    by sorpigal (6061) on Saturday May 16 2020, @03:40PM (#995016)

    An "abandoned" 10 line nodejs module isn't as much of a concern as, say, five year old embedded copy of zlib. Some risks are riskier than others.

  • (Score: 0, Disagree) by Anonymous Coward on Saturday May 16 2020, @05:31PM (1 child)

    by Anonymous Coward on Saturday May 16 2020, @05:31PM (#995060)

    so, the register (suited whores) post a story written by Synopsis (slaveware shilling suited whores) about how other companies using open source (leaching suited whores) don't keep their shit up to date, and somehow it's open source's fault. fuck off.

    • (Score: 0) by Anonymous Coward on Sunday May 17 2020, @02:09AM

      by Anonymous Coward on Sunday May 17 2020, @02:09AM (#995213)

      so, the register (suited whores) post a story written by Synopsis (slaveware shilling suited whores) about how other companies using open source (leaching suited whores) don't keep their shit up to date, and somehow it's open source's fault. fuck off.

      I prefer my whores without suits. And face down, ass up to boot.

      I guess everyone has their own fetish, eh?

  • (Score: 2) by krishnoid on Saturday May 16 2020, @05:55PM

    by krishnoid (1156) on Saturday May 16 2020, @05:55PM (#995077)

    Synopsys acquired Black Duck, and Coverity further back, so they could even use both products' analyses in the future to further refine the results. Now your one-stop-shop for state actors and better-funded black hats!

  • (Score: 1, Touché) by Anonymous Coward on Saturday May 16 2020, @09:10PM

    by Anonymous Coward on Saturday May 16 2020, @09:10PM (#995137)

    If only there was some way corporations that use and depend on open source projects could contribute to bug fixing and development. You know, some way to give back. I guess that won't happen because it might cost them a buck or two.

(1)