Slashdot Mirror
Companies Overlook Risks in Open Source Software, Survey Finds (betanews.com)
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.
Has /. really stooped this low?
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.
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.
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.
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.