Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
BLACK FRIDAY DEAL: Trust the World's Fastest VPN with Your Internet Security & Freedom--A Lifetime Subscription of PureVPN at $48 with coupon code "BFRIDAY20" ×
Open Source Security Software

Companies Overlook Risks in Open Source Software, Survey Finds (betanews.com) 132

An anonymous reader shares a report: Open source code helps software suppliers to be nimble and build products faster, but a new report reveals hidden software supply chain risks of open source that all software suppliers and IoT manufacturers should know about. The recent Equifax breach for example exploited a vulnerability in a widely used open source web framework, Apache Struts, and the study by software monetization specialist Flexera points out that as much as 50 percent of code in commercial and IoT software products is open source. "We can't lose sight that open source is indeed a clear win. Ready-to-go code gets products out the door faster, which is important given the lightning pace of the software space," says Jeff Luszcz, vice president of product management at Flexera. "However, most software engineers don't track open source use, and most software executives don't realize there's a gap and a security/compliance risk." Flexera surveyed 400 software suppliers, Internet of Things manufacturers and in-house development teams. It finds only 37 percent of respondents to the survey have an open source acquisition or usage policy, while 63 percent say either their companies either don't have a policy, or they don't know if one exists. Worryingly, of the 63 percent who say their companies don't have an open source acquisition or usage policy, 43 percent say they contribute to open source projects. There is an issue over who takes charge of open source software too. No one within their company is responsible for open source compliance, or they don't know who is, according to 39 percent of respondents.
This discussion has been archived. No new comments can be posted.

Companies Overlook Risks in Open Source Software, Survey Finds

Comments Filter:
  • by fred6666 ( 4718031 ) on Tuesday October 17, 2017 @01:58PM (#55384829)

    How is it any different for closed source software? What if that proprietary software haven't been updated in years? Surely if there is no update, there is no security risk, right?

    • Second post, and I came here to say exactly this.
    • by sexconker ( 1179573 ) on Tuesday October 17, 2017 @02:11PM (#55384947)

      Yup. Here's how it works everywhere:

      We need to do X. How can we do X and how much will it cost?

      We could buy A, it's costs $$$$$ to start / set up and ????? every year after. It'll do 80% of what we need and it says "secure" on the product page.

      We could build it ourself. It'll take ??? months to do it, with a team of ?? people, and it'll do what we want and we'll be able to incorporate any changes needed later. It'll be unpolished, unreliable, and deployed too soon, but we'll add maintaining it to an existing employee's duties at no additional cost to us. Oh, other operating costs will be 0 because we'll tell the other department they have to run it since they run the current somewhat-related system that this will never fully replace.

      There's this open source thing that does a piece of what we need. We can wrap some crap around that and shit it out the door next month and never touch it again until it all falls apart.

      • by Ichijo ( 607641 )

        Why do businesses seldomly take option 2 (build it ourselves) and make it a standalone product the way id Software does with their game engines?

        • Since when did software reuse become a bad thing? It's foolish to build something at great cost that's already been designed, built, and tested by others. That's especially true if that software doesn't reflect your company's your core competency. Where exactly do you draw the line about which software you're supposed to write from scratch?

          Everything we do as software developers is, to a large degree, resting on the shoulders of software developers that came before us.

          • by Ichijo ( 607641 )

            Where exactly do you draw the line about which software you're supposed to write from scratch?

            Short answer: when the existing software doesn't meet your needs.

            Maybe it was designed for a different use case and decoupling it so it can be used in your project would take a lot of effort.

            Or maybe it's poorly written, poorly documented, and/or poorly tested.

            Or maybe its license conflicts with your own.

            In any case, it's good to take inventory of what already exists and learn its strong and weak points before dec

        • by Altrag ( 195300 ) on Tuesday October 17, 2017 @03:55PM (#55385741)

          Because:
          1) It usually costs more. A third party selling a product is splitting the development costs among multiple customers. You building it yourself means eating 100% of the cost yourself. This is the main reason pretty much in all cases. But even when it isn't,

          2) You're probably going to do it worse. A third party selling a product is dedicated to that product and knows what they're doing usually pretty good. If you try to build it yourself, sure you can tailor it to your business needs better but at the cost of doing its primary job worse. Think of all of the TDWTF posts that relate to date handling because people don't know about, or can't be bothered using, one of the standard (and usually built-in in modern languages) set of date handling routines.

          Of course there's plenty of examples of companies going way too far and trying to jackhammer third party software into their business flow in a way it really was never meant to be used.. those situations are when they should be considering option 2.

          • by Ichijo ( 607641 )

            A third party selling a product is splitting the development costs among multiple customers. You building it yourself means eating 100% of the cost yourself.

            Unless, of course, you split the development costs among multiple customers!

            *sigh*

            • Which is an excellent way to make your product a non-competitive also-ran.

            • by Altrag ( 195300 )

              Presumably, the company considering taking the NIH tack isn't planning on developing an entire new standalone product line (and all of the marketing and support and whatnot that goes along with that) and are just needing the software either for internal purposes, or as part of a larger platform or product that is their primary business.

            • by Jawnn ( 445279 )

              A third party selling a product is splitting the development costs among multiple customers. You building it yourself means eating 100% of the cost yourself.

              Unless, of course, you split the development costs among multiple customers!

              *sigh*

              Just in case there's somebody who didn't get the brilliantly subtle comment that parent made, FOSS software does exactly this (distributing the cost of development among multiple customers/contributors).

          • Everything you just wrote assumed that the company will write the system from scratch rather than tweaking a FOSS system. So you are right in what you say but it has nothing to do with this subject, or how anybody does things in 2017 for that matter.
            • by Altrag ( 195300 )

              That's correct, I assumed the scenario that the parent poster had posed.

              Answering questions about an unrelated scenario isn't really productive in most conversations regardless of how many times you can include the term "FOSS."

        • Why do businesses seldomly take option 2 (build it ourselves) and make it a standalone product the way id Software does with their game engines?

          Because when it breaks or someone hacks it, you can't point the finger at an outside entity.
          Also because of the guarantee that someone in the room will utter the phrase "reinventing the wheel".

        • Let me gently suggest that the reason why businesses do not "build it themselves" the way Id Software does is because businesses have to deal with real world issues.

          I admire you, sort of. You've got a pretty low /. ID# yet you have managed to avoid moving from the basement to the room with the blue ceiling.

        • by fisted ( 2295862 )

          Because you need competent people for that.

    • by ShanghaiBill ( 739463 ) on Tuesday October 17, 2017 @02:19PM (#55385025)

      How is it any different for closed source software?

      If you run your own business, then OSS is better since it is free and likely more secure.

      If you are a middle manager, the situation is different. Your goal is not to minimize failure, but to protect your career. Proprietary software gives you someone else to blame.

      • by DickBreath ( 207180 ) on Tuesday October 17, 2017 @02:33PM (#55385149) Homepage
        If Equifax had used a proprietary server, not updated it in years, even though there was a published vulnerability, and then blamed the vendor, I bet that middle manager would be surprised at what would happen if they simply try to "blame the vendor".

        The Apache Foundation pointed out that Equifax was using unpatched software with a known vulnerability. How much louder would a commercial software company say that in public?

        Dear Middle Manager: Using proprietary software in order to "blame the vendor" may actually hurt your career worse than using open source software. The real thing that hurts your career is being incompetent and not doing basic things like patching software. Especially when you know that you are handling highly confidential private data that is a high value target to steal.
      • If you are a middle manager, the situation is different. Your goal is not to minimize failure, but to protect your career. Proprietary software gives you someone else to blame.

        Only if your manager is stupid. Say it was a Windows IIS bug that was the problem and that bug had been patched six months prior. The manager could blame MS but MS would turn around and say it was already patched.

      • by jbengt ( 874751 )

        Your goal is not to minimize failure, but to protect your career.

        How do you think you protect your carreer?
        By maximizing failure?

      • ~ OSS is better since it is free ~

        Free as in Beer. Not free as in "doesn't cost anything to implement and maintain".

        ~ and likely more secure.

        Oh my, no. Security is not a function of source openness. Security is a function of actual security implementation.

        You're confusing Linus' Law [wikipedia.org] ("given enough eyeballs, all bugs are shallow") with Schneier's Law [wikipedia.org] ("Any person can invent a security system so clever that he or she can't imagine a way of breaking it.")

    • by ljw1004 ( 764174 )

      How is it any different for closed source software?

      Presumably the difference is mainly between FREE software (usually open-source) which it's easy to incorporate without any kind of tracking other than what's written in your build system.

      Versus COMMERCIAL software (usually closed-source) where you definitely have tracking -- purchases, sign-offs, ongoing commercial relationships, and just lots of business process. When you bought it you probably had a sales-droid from the selling company assigned to your account, and they'll be sending you emails and remind

      • yeah, so basically if that commercial software company don't send you any notice, you can safely assume you are secure, right?

        • by tlhIngan ( 30335 )

          yeah, so basically if that commercial software company don't send you any notice, you can safely assume you are secure, right?

          Which is almost never the case.

          The company in question loves sending lots of alerts out. Usually because they have a new version out, and hey, why not pay us $$$$ to upgrade?

          This is especially true if there's an ongoing support contract - remember, your vendors are trying to get more money out of you and thus will blast you with all sorts of upgrades and freebies that you get because

    • by bws111 ( 1216812 ) on Tuesday October 17, 2017 @02:34PM (#55385153)

      Did you read the article? Or even the summary? They are not claiming that open source is riskier than closed source. They are saying that companies that have no policy on the use of open-source software may be running (or distributing) software they are not even aware of. So when someone in charge of security sees that XYZ has a vulnerability, he may not know that they are affected. On the other hand, closed-source software generally requires approvals, money, licenses, etc, so the company is at least aware of the use of the software.

      • Nothing to do with open source. A closed source, but free (as in beer) software would get the same problem. Plus if there is a vulnerability, the in-house team won't be able to fix it.

        I don't think companies without any open source policy have a policy on this either.

        • by bws111 ( 1216812 )

          Yeah, OK. But how much 'closed source but free' stuff is there, compared to open source? Virtually none.

          • OK so now you admit that this has nothing to do with the code being open vs closed source.

            The next step is to realize it has nothing to do with free vs paid either. If you buy a software once, you may not update it, even if there is a new version, especially if the new version requires paying again.

            The problem is not lack of policy towards OSS. The problem is lack of policy towards security updates. The security update was available for Equifax. They didn't get the updated software. It has nothing to do wit

            • by bws111 ( 1216812 )

              'So now I admit'? I never said otherwise, I also never said anything about updates. Can't you even read? Here is what I said, please feel free to point out where I said it had anything to do with being open vs closed source, or about applying updates:

              They are not claiming that open source is riskier than closed source. They are saying that companies that have no policy on the use of open-source software may be running (or distributing) software they are not even aware of. So when someone in char

              • You should read your comment again. You clearly make a distinction between closed (generally requires approvals...) and open (nothing from management).

                Companies can (and do) distribute software they are not even aware of. It doesn't matter if the software is open or closed source at this point. Many closed source software are free.
                And a company can have an open source policy (whatever that means) and still not even be aware* they distribute a particular software. Just because you have a policy doesn't mean

          • by Altrag ( 195300 )

            On the other hand, I would claim virtually all of it. Almost every common software package these days has a "free for personal use," "free for up to X users," "free but limited features," or similar option, and you can bet that there's plenty of companies out there -- especially in the small-to-mid-size range -- that happily will grab the free version if they think its sufficient for their needs (even the personal use ones if they assume it will only be used in-house and nobody is likely to catch them.)

      • Did you read the article? Or even the summary? They are not claiming that open source is riskier than closed source.

        No, it doesn't say that explicitly, but since it talks at length about there being risks with open-source software, without even mentioning that there are also risks with closed-source software (which seems very relevant, since besides building in house, these are the two options), it does rather seem to be implying it. It strikes me as dishonest. Essentially lying by omission, I think.

        On t

    • Especially the example they cite is flawed. Equifax did not install a patch to Apache Struts that was six months old by the time the breach was announced. With closed software, Equifax may never have known that their software had a patch until after the vendor may have acknowledged it.
      • by bws111 ( 1216812 )

        You miss the point. The discussion has nothing to do with what a closed-source vendor may or may not do.

        Equifax did not patch until 6 months later. WHY? Who was responsible for patching the systems and making sure the patches were applied? It certainly should not be left to some admin, it should be way higher up (CIO). But if there is no policy regarding use of open source, and the CIO has no accurate inventory of what software is in use where, how is he supposed to do that?

        • Equifax did not patch until 6 months later. WHY?

          I don't know. And unless you work in Equifax neither do you. What we do know is that there was a patch for the flaw because open source is, well, open about bugs and patches.

          Who was responsible for patching the systems and making sure the patches were applied? It certainly should not be left to some admin, it should be way higher up (CIO). But if there is no policy regarding use of open source, and the CIO has no accurate inventory of what software is in use where, how is he supposed to do that?

          None of what you said applies ONLY to open source. It also applies to closed source. For example, if there is a flaw in IIS web server who's responsible for patching it? Why doesn't the CIO know about every single closed source software that his company uses. That's more an indication of bad management than open source.

          • by bws111 ( 1216812 )

            The whole freaking article is about MANAGEMENT. Did you somehow miss that in your zealotry? There is NOTHING in the article that says open source is bad, or closed source is better. What it is talking about is the lack of rigor in companies in TRACKING their use of FOSS, so that the company remains in control. The RISK comes from being out of control, not from the software.

            If IIS was used, and the CIO saw a report that said there was a flaw in IIS, he could probably consult the database of licenses they

            • If IIS was used, and the CIO saw a report that said there was a flaw in IIS, he could probably consult the database of licenses they have for IIS find out where it is used, and ask to see what patches were applied.

              First of all, Hahahahaha. I don't know about you but all the CIOs I've dealt with never looked about reports about which software had which bugs and when they needed to be applied. They were more concerned about larger matters like if there was scheduled downtime and new systems and how to coordinate such downtime. They left the details of what to patch and when to sysadmins. Here's this month's Oracle security bulletin [oracle.com]. Even when I worked with the Oracle team at my company, I didn't know if we used some o

    • by Altrag ( 195300 )

      Its not. The point is that people forget that fact and just assume OSS is better because that's what they've been told over and over again, even though in the vast majority of cases with OSS, its simply not true. All software has bugs and potential security risks no matter what philosophy the developers happen to follow.

      And I'm not talking about Linux vs Windows or Apache vs IIS -- all four of those are enormous products with an enormous amount of effort put into developing and testing them.

      I'm talking ab

    • It is different because with opens source if the original company doesn't fix the problem you can fix it yourself. With closed source no choice but re-implement the whole system without using the software.

    • How is it any different for closed source software? What if that proprietary software haven't been updated in years? Surely if there is no update, there is no security risk, right?

      Proprietary and Closed are two separate things. Some proprietary software may be sold under a binary-only license or a source code license. The source code license allows redistribution by the licensee so that the licensee can debug and update the code if necessary. In other words the source code license removes a big risk of "buying" rather than "building" software. From the licensee's perspective it is not terribly different than open source. It really only differs for the licensee's customers who have no

  • by QuietLagoon ( 813062 ) on Tuesday October 17, 2017 @02:08PM (#55384911)
    Has /. really stooped this low?
  • by Anonymous Coward

    Closed source is better. When I pay for software, if it fails, I get compensated.

    When Windows crashed, and took all my data, Microsoft sent the best data recovery technicians money could buy to recover every single one of my files, didn't cost me a dime.

    When I got ransonwared, Microsoft pad the ransom, because Windows was fully updated, and I maintained good security practices , Microsoft paid for their failure to secure code. Because they put their money where their mouths are they paid up to recover my f

    • Explain how closed source is better again?

      You have someone to blame when it all goes pear shaped... A wise man once said, "nobody was ever fired for buying IBM"...

      Of course, a number of folks went broke paying them..

      • by Anonymous Coward

        Not true, I work for a medium size company where the CEO was in fact fired for choosing IBM. What they delivered was unusable and scrapped after about a year.

    • When I got ransonwared, Microsoft pad the ransom, because Windows was fully updated, and I maintained good security practices...

      Pics or it didn't happen.

      • Microsoft's environment is so advanced even banner ads can scan my system and tell me they found viruses! And it only costs $19.99 to download the fix!
        • Yeah, but they aren't always completely clear. That time I got the warning about my registry, I didn't know whether to look in /usr/registry, /var/registry, /etc/registry, or somewhere else.

    • Actually their helpful Engineers even called me before I knew I had a problem.
  • It's easy to forget (Score:4, Interesting)

    by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Tuesday October 17, 2017 @02:20PM (#55385029) Homepage

    Modern development stacks using NuGet, NPM, Bower, etc. tend to make it exceedingly easy to insert someone else's code into your project without paying attention to licensing or vetting their code. And because of how easy it is to put your own stuff on these package managers, they're full of one-off projects that don't have the reliability or long-term maintenance of the major open-source projects.

    I'd fully expect to see a ton of small companies (small enough to not have strict process) with horrible dependencies.

    • And what about proprietary software that also bundles? You'd have no way of even tracking this if you had a policy. Think how many things were affected by some RSA library that was bought by many companies for use on smart codes recently. If you read the article, they even discovered a company with keys generated in a different weak way, but couldn't guess as to the lib version or what one-off patches were applied to it.
  • These roles/policies are generally only formed at a company after a legal risk/threat is realized I think. I know as a lead dev, my priority is often given to me from above in terms like "We need to do this quickly, as this is a great opportunity for us, and it should work well with our existing tech. How long would this take you to get something meeting these requirements out the door?" Saying something longer than what they want to hear is usually a great way to get a response like "why would that take
  • Considering that there was a post a short while ago about how Microsoft got pwned half a decade ago and never make it public, putting everyone at risk? How is Equifax's refusal to patch their software in any way relevant to the fact that Struts is OSS? How many of these same companies were asked if they had closed source compliance teams?

    The whole article smells like so much bullshit I'm having to lean away from my computer.

    • by bws111 ( 1216812 )

      You completely missed the point of the article. The article has nothing to do with whether or not open source is 'better or worse' or 'riskier or safer' than closed source. It is about companies knowing what software they are using (or distributing). To take your Equifax example: if Equifax has no policy about obtaining open source software, how is the CIO supposed to know that Joe Developer decided to use Struts? And if he doesn't know what they are using and where, how is he supposed to make sure vul

      • I didn't miss the point. The problem is that they use lots of loaded language to point the finger at OSS, implying that the issue doesn't exist for closed source tools. If OSS tools are slipping through the cracks for no other reason than that they were free, then someone really dropped the ball on their responsibilities. But the same thing could just as easily occur with a commercial tool if licensing wasn't very strictly monitored. That's really all OSS software is. Software for which the licensing ha

      • In other words, TFA is crap. If the company allows any software of any sort to get into production without tracking it, they're screwed. There's nothing different here between different sorts of software. Developers might use F/OS software, or they might use software purchased for another reason. If the CIO doesn't know, and can't easily find out, what software is on the production servers, the CIO needs to nail it down fast, or perhaps seek employment at McDonald's.

  • This isn't about open source software, or "compliance" regarding open source software. This is about failing to do timely security updates of reused third-party software. It doesn't matter if it's open source software or not. If you use third-party software, you need to update that software when a security update happens, and you have to do it BEFORE an attacker exploits it. This has been necessary for decades. Haven't you ever updated an operating system because a vulnerability was found in it? Of c
    • It's just that companies are more motivated to keep track of software that they have paid for licenses for. If they don't keep track of their license usage then they can be fined for running illegal copies. Some software companies are extremely vigilant in making sure that their customers are only running the number of copies that have been paid for.

      If the free open source world had some companies that tracked their applications like that then firms would track the usage better.

    • by thomst ( 1640045 )

      dwheeler commented:

      This isn't about open source software, or "compliance" regarding open source software. This is about failing to do timely security updates of reused third-party software. It doesn't matter if it's open source software or not. If you use third-party software, you need to update that software when a security update happens, and you have to do it BEFORE an attacker exploits it.

      This has been necessary for decades. Haven't you ever updated an operating system because a vulnerability was found in it? Of course you have. If you reuse software, and you embed it in something you use or deploy, then you need to update when the reused software has a security vulnerability. One advantage of open source software today is that there are tools that make it easier to monitor and update. But you still have to be prepared for security updates. You can do this by monitoring updates, using package managers to let you easily update, having automated tests so you can verify that the update is okay, and by having a deployment system so you can send out your update. All of this is available. Check out this video for an example: https://www.youtube.com/watch?... [youtube.com] .

      If you don't keep your software patched in a timely way, you get p0wned. That's how it works. That's ALWAYS been how it works.

      Mode parent +1 Insightful, please.

      Huffing and puffing aside, this is EXACTLY what both TFA and TFS are about. (The headline, as usual, is pure clickbait trolling. Thank you for that, /. editors ... )

    • by bws111 ( 1216812 )

      The article is about POLICY and compliance with it. If your company has no POLICY regarding open source, and no checking for compliance with that policy, how do you (as, for instance, the CIO) ensure that the systems are in fact patched in a timely manner? Just leave it up to some low-level admin? Package managers, etc are just tools, they are not a substitute for policy (without policy, what is to prevent someone from downloading the source and building themselves, avoiding the pesky package manager)?

  • Slashvertisement (Score:5, Informative)

    by whoever57 ( 658626 ) on Tuesday October 17, 2017 @02:24PM (#55385087) Journal

    Check out the primary source: Flexera. They are definitely not supporters of open source software.

    Their business relies on closed source.

  • by ToTheStars ( 4807725 ) on Tuesday October 17, 2017 @02:24PM (#55385089)
    These guys make license management software for big closed-source software packages (CAD, simulation, etc.). I've been fortunate enough that their software has always done its job and gotten out of the way (at my organization), but their end-user documentation is awful. Take their commentary on open-source software with a big pile of salt.
  • Computer systems, both hardware and software, have simply become too complicated for the average PHB and for the average company.

    The vast majority of the managers have no idea, NONE, how these systems work, how they are put together, and how they should be maintained and updated. They simply select software based on the latest buzzword, the latest Gartner "quadrant" (whatever that is) or the latest fad and/or "safe" choice (Remember: "Nobody ever got fired for buying IBM"? Or Microsoft, or Oracle, or Red Ha

  • I'm actually kind of disappointed that more copy-pasta/otherwise spammy anti-OSS ("open sores") anecdotal type posts haven't been made here yet.
  • by Anonymous Coward

    Right?! Why don't they just use a closed standard available only for purchase and tightly regulate it, like WPA2 or something, and then there won't be any issues.

  • Many eyes make bugs shallow, but that doesn't work if you keep them closed.

  • Flexera has an agenda to manage "Software Composition Analysis", which is intended to manage your exposure to Open Source Software.

    I've come across this tool in consulting gigs and is essentially a catalogue of OS tools and libraries usage. This is something that be easily acheived open source repositories such as Nexus.

  • by Curunir_wolf ( 588405 ) on Tuesday October 17, 2017 @03:19PM (#55385459) Homepage Journal
    'nuff said
  • Because dealing with these risks would cost money and they rather pay a bigger bonus to the C-levels than solve this problem. There are no specific risks of FOSS that are not present in commercial software. You can buy support for FOSS that is just as good or better. You can have your own people that can deal with problems. You can get independent reviews of the software. In fact, basically everything about FOSS is easier to secure than with the alternatives. It is still not simple and the time and effort h

    • by bws111 ( 1216812 )

      Nobody is saying that there are more risks in FOSS. What is so hard to grasp about this? They are saying that UNCONTROLLED use of FOSS is risky, not because of the software, but because the company does not know what software it is running. They aren't saying "don't use FOSS", they are saying "have a policy so you remain in control of what you are running".

      And yes, FOSS vs commercial makes a difference, because most companies have policies against installing and running unlicensed software, but far fewer

  • "Flexera points out that as much as 50 percent of code in commercial and IoT software products is open source." And most of those products are violating the GPL.
  • My experience in the field has led me to the conclusion that closed source is far more damaging to a companies bottom line.

    1. Closed source licencing often results in changes to architectural designs to limit license exposure. This in turn often makes the final product weaker than it could be. For example if your buy of license X you can only scale to 10 nodes in production. If demand gets high enough you can not scale to meet it.
    2. Closed source licenses that restrict functionality once license is excee

  • by sad_ ( 7868 )

    You might not have a team in your org that keeps track of the OSS you use, if that is the case, it is your task to keep up-to-date on the development of the OSS you use. It is not hard, almost every OSS project worth being used has a mailing list or social media account that will inform you on new updates etc.
    If you don't do that, you are just an irresponsible dev.

  • The only risk here was the incompetent management, and use of default admin/admin login

It's a poor workman who blames his tools.

Working...