Nearly One In Two Industry Pros Scaled Back Open Source Use Over Security Fears (theregister.com) 60
An anonymous reader quotes a report from The Register: About 40 percent of industry professionals say their organizations have reduced their usage of open source software due to concerns about security, according to a survey conducted by data science firm Anaconda. The company's 2022 State of Data Science report solicited opinions in April and May from 3,493 individuals from 133 countries and regions, targeting academics, industry professionals, and students. About 16 percent of respondents identified as data scientists. About 33 percent of surveyed industry professionals said they had not scaled back on open source, 7 percent said they had increased usage, and 20 percent said they weren't sure. The remaining 40 percent said they had.
By industry professionals, or commercial respondents as Anaconda puts it, the biz means a data-science-leaning mix of business analysts, product managers, data and machine-learning scientists and engineers, standard IT folks such as systems administrators, and others in technology, finance, consulting, healthcare, and so on. And by scale back, that doesn't mean stop: 87 percent of commercial respondents said their organization still allowed the use of open source. It appears a good number of them, though, are seeking to reducing the risk from relying on too many open source dependencies.
Anaconda's report found that incidents like Log4j and reports of "protestware" prompted users of open source software to take security concerns more seriously. Of the 40 percent who scaled back usage of open source, more than half did so after the Log4j fiasco. Some 31 percent of respondents said security vulnerabilities represent the biggest challenge in the open source community today. Most organizations use open source software, according to Anaconda. But among the 8 percent of respondents indicating that they don't, more than half (54 percent, up 13 percent since last year) cited security risks as the reason. Other reasons for not using open source software include: lack of understanding (38 percent); lack of confidence in organizational IT governance (29 percent); "open-source software is deemed insecure, so it's not allowed" (28 percent); and not wanting to disrupt current projects (26 percent).
By industry professionals, or commercial respondents as Anaconda puts it, the biz means a data-science-leaning mix of business analysts, product managers, data and machine-learning scientists and engineers, standard IT folks such as systems administrators, and others in technology, finance, consulting, healthcare, and so on. And by scale back, that doesn't mean stop: 87 percent of commercial respondents said their organization still allowed the use of open source. It appears a good number of them, though, are seeking to reducing the risk from relying on too many open source dependencies.
Anaconda's report found that incidents like Log4j and reports of "protestware" prompted users of open source software to take security concerns more seriously. Of the 40 percent who scaled back usage of open source, more than half did so after the Log4j fiasco. Some 31 percent of respondents said security vulnerabilities represent the biggest challenge in the open source community today. Most organizations use open source software, according to Anaconda. But among the 8 percent of respondents indicating that they don't, more than half (54 percent, up 13 percent since last year) cited security risks as the reason. Other reasons for not using open source software include: lack of understanding (38 percent); lack of confidence in organizational IT governance (29 percent); "open-source software is deemed insecure, so it's not allowed" (28 percent); and not wanting to disrupt current projects (26 percent).
My Fault vs Their Fault (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
I question the "IT Pro" or "industry professionals" angle of the story.
The worst part of log4j that I encountered was not upgrading or bypassing the pure open source projects like red hat servers that was easy (isolate servers until they get them fixed).
It was the integrated open to close source products on the back end. The large scale backed firewall management systems was a pain to ultimately upgrade as it was all closed source TAC calls and the hotfix's was not timely as it was not there problem just t
Re: (Score:2)
I'm sure a lot of it is also hurt when open-source developers decided to sabotage their own software to protest various things from the War in Ukraine to other things.
Doesn't take a genius who's left to fix the mess left behind by these people - and I'm sure it's not something someone wants to wake up to that their website or other thing is suddenly broken.
'
And I'm not even going to blame open-source on this, it's less an open-source pro
Re:My Fault vs Their Fault (Score:5, Interesting)
IMO Log4j wasn't a open-source vs closed-source issue it was dumb company management relying on open source library's they did not understand being used by closed-source products. Fixing pure open-source servers was pretty easy - rip out the library's and wait for the fix which was pretty quick.
Most of the companies effected the hardest had no lab environment setup to soak test anything open source and the labs they did have was designed by the closed-source vendors that also didn't vet the libraries before pushing them. Remember the largest use of log4j lib's was to make raw data logs look pretty.
When in doubt blame management.
Linux : Known and soon fixed ... (Score:5, Insightful)
....vs Windows : unknown and fixed sometime after it is published and you have already been exploited
Re:Linux : Known and soon fixed ... (Score:5, Insightful)
The assumption that Linux is by default secure and doesn't require as regular patching or updates is something I've seen by multiple businesses in the past.
Some vendors say that you must run RHEL 7.2. That therefore means that all the patches that make it 7.3 won't be supported.
TLDR: Bad patch management isn't limited to Microsoft
Re: (Score:2)
While I agree this is an issue, many times the same issue is faced in Microsoft installs. Particular software may be validated - particularly in the medical field - to a specific system - whether Linux or Microsoft based. Changing the underlying system would require an extremely expensive government re-validation which nobody wants to pay for in support contract fees. So routine point release changes aren't allowed to happen. Maybe if enough major releases go by there might be another software release for t
4 is greater 2 is math, not an assumption (Score:5, Informative)
Today I'll be giving my monthly presentation on the Windows vulnerabilities for the month. I do it every month, giving essentially the same presentation three times per month. I've been tracking all the new patches for years. For a while I maintained a database of every CVE there is.
This month is really light for Windows. Only 63 new vulnerabilities for Windows, plus 16 more for Edge. That's HALF as many as last month! Very often, it over 100 each month. That's 2-4 new vulnerabilities PER DAY.
Adobe has another 63 new vulnerabilities this month - two per day just for your Adobe products.
When people hear about all the new Windows vulnerabilities, some do something kinda funny. They'll do the whole "well Linux had shellshock so there's really no difference". Yep, Shellshock was a serious Linux vulnerability. In 2014. Eight years ago. Compared to three times a day for Windows.
Of course three new vulnerabilities per day is just Windows itself, Microsoft code. Double that for a typical Windows-based desktop, around 180 per month.
Yes, you should patch Linux servers - probably set them to auto update. The nice thing about Linux is likely all of your software comes from the same repo, so you can set apt to autoupdate and you're good. Everything updates. You don't have to chase down patches from eight different vendors, two of whom tell you that you have to renew your subscription in order to get the security update.
Re: (Score:2)
> Linux vulnerabilities are for Linux which is just the kernel.
Um, no.
I was probably 30 years old when I finally learned something.
Took me 30 dang years to figure this out.
I finally understood that we all have a choice. We can either make a guess and then defend whatever that guess is as if our lives depended on it, or we can LEARN things - update our guesses when knowledge comes our way. When someone who knows the topic - the neurologist or the aerodynamicists or whomever corrects our mistaken guess, we
Re: 4 is greater 2 is math, not an assumption (Score:2)
MS is a minority player now and the source code is not readily available. Linux runs on every phone and almost every consumer router in existence. VMs running Linux now also dominate the server market.
Re: (Score:2)
Re: (Score:2)
You ever take a look at how many vulns Red Hat doesn't fix or doesn't fix quickly???
One in two, one in two (Score:5, Funny)
I wish there was a handy, shorter way of writing that.
What is scaled back (Score:2)
open source is everwhere (Score:5, Insightful)
The problem is that commercial software is full of open source libs.
So you a pay a lot but the immediate attack vector is not changed.
What they buy with commercial sw is mostly insurance: they can blame the vendor.
Re:open source is everwhere (Score:4, Insightful)
What they buy with commercial sw is mostly insurance: they can blame the vendor.
EULAs are disclaimers of liability.
Re: (Score:2)
What's the compensation for your business going bankrupt or being held to ransomeware ?
Re: (Score:2)
The warm fuzzy feeling that you've done everything possible to avoid the risks, and the disaster was simply caused by bad luck.
Re: (Score:2)
Security through obscurity is not security (Score:3, Insightful)
Re: (Score:2)
Open source cannot usually be sued. Learn to think like a lawyer.
Re:Security through obscurity is not security (Score:4, Informative)
The lawyers for closed source are pretty good as well. That's why the license agreements are there that disclaim all responsibility for everything, especially if used in critical life threatening applications.
Re: (Score:2)
Re:Security through obscurity is not security (Score:5, Insightful)
My organization is one of those that removed Log4j after a number of security issues. It was trivial to replace it with java.util.logging.
The problem with some 3rd party libraries (like log4j) is that over time, they start trying to do "too much". Log4j went from simple file logging to adding all sorts of crazy features around logging over sockets, etc. Instead of making that a separate library, it all got baked into log4j proper.
It gets even worse when 3rd party libraries require other 3rd party libraries and you get a chain of dependencies. Then you're at the mercy for whichever one of those projects is the least-well maintained.
There is definitely a trade-off between "don't reinvent the wheel" and "just do it yourself if you're doing something trivial".
Re: (Score:2)
The problem with some 3rd party libraries (like log4j) is that over time, they start trying to do "too much". Log4j went from simple file logging to adding all sorts of crazy features around logging over sockets, etc. Instead of making that a separate library, it all got baked into log4j proper.
Eerily reminds me of certain service and process management daemon promoted by a guy named Lennart, that has largely taken over most of the Linux distro ecosystem.
Re:Security through obscurity is not security (Score:5, Insightful)
I put the emphasis somewhere else. All software has bugs, but it's illegal to fix proprietary software.
Re: (Score:3)
So dumb. I can't even begin to fathom how shallow an understanding of software a person must have to think "avoid open source" is the right way to promote security. All software has bugs. Some bugs will strike all software, sometimes even nasty bugs like with Log4j. But more eyes on code translates into better code.
Ideally, this is true. But practically what seems to be happening more and more in the OSS world for development environments like Java, Python, NodeJS, and others that have their own package management systems is that we get into Dependency Hell. These dependency trees can get really deep, and sometimes the need for these dependencies is pretty tenuous -- Dependency A may itself pull in Dependency B, but only use a single method/function in it. And if some dependency in the tree closer to a leaf node ha
Re:Security through obscurity is not security (Score:5, Interesting)
That isn't the issue.
The issue is many customers are now requiring a list and security scan of every library your product uses.
Open source generally has resulted in a very large stack of dependencies from a very large number of projects. Checking every one of those for CVE's, and constantly monitoring them for new CVE's is not a trivial amount of work. In addition, the "patch frequently" model of open source means having to do new security reviews frequently, greatly increasing the level of work.
A lot of commercial dependencies effectively do that work for you. They may have a giant dependency tree, but they've provided a sort of bill-of-materials you can use instead of having to do your own search. They also tend to release far less often.
It would be good for the higher-level open source libraries to provide a similar bill-of-materials-like thing, so that we don't make every user have to check every dependency. And so that you don't tell your customer you don't use a particular library only to find it's 7 levels deep in the dependency tree, but only when installed on 3 versions of Red Hat that a particular customer uses.
Also, often small libraries ends up growing and expanding into swiss-army-knife projects. You aren't using the library for those features - Literally what happened with log4j. We need to maintain a much more UNIX approach and keep the libraries focused. Why did we need the ability to execute code in a logging library? Shouldn't that have been a separate package?
Lastly, some customers are rather unhappy if one of those dependencies is maintained mostly by people in certain countries. Which is usually not to hard to replace when it's a direct dependency. But when it's many levels deep you're going to end up with an open source project that doesn't want to change to an equivalent dependency, a customer that refuses to let it be installed, and a company that will never want to spend the money to maintain a fork of something so far from their core business.
This is misleading...` (Score:2)
Realizing that a lot of the code in the "open source repos" is crap and/or dangerous is a valuable epiphany.
Thinking that somehow taints ALL of "Open Source" as dangerous is ridiculous. Properly managed and tended open source projects are at least as safe as proprietary code, if not a heck of a lot better. Example: The Linux kernel.
Re: (Score:2)
I agree with this. But also some of the blame has to lie with the open source community. There is a bad propensity to add cool features, but less initiative for want of a better word, to go back and refactor code and make things bullet proof, as well as looking for potential issues. It's human nature, new stuff is cool, reviewing old stuff is boring and difficult (looking at someone else's code).
Re: (Score:2)
The problem is categorizing all of open source as 'a community'. In practice, each codebase relates to a particular community, and each with different disciplines.
You have projects that ultimately turns out to be the work of someone back in high school who abandoned the codebase in college, and the 'community' is enthusiasts who wouldn't have any skill to actually maintain the project. You also have projects that are stewarded by a team of professionals in a top software development firm with every bit the
Irrational (Score:2)
I don't think the risk of class exploits outweighs other benefits - independent security analysis, many eyeballs looking at the code, maturity, stability etc.
Re:Irrational (Score:4, Interesting)
Think the distinction that isn't made is whether it's 'wild west open source' being scaled back in favor of 'curated open source by trusted parties'. Sure, some say closed source all the way, but I think a lot of orgs would answer 'scaled back' to describe cutting out pulling 'whatever pip/npm feels like throwing at us at the moment of deployment'. A lot of orgs have developers that just grabbed anything from anywhere, and many have cut back on that. Open source is a good principle, but you need some sort of reputation and update expectations. The language-focused repositories provide none of that, but some of the Linux distribution organizations do.
Further, using third party libraries versus in-house snippits. Some folks will grab a library/framework for one little utility function, and now perhaps it's worth it to just roll your own if it is a tiny thing.
So open source vetted by reputable parties provides most of the best of both worlds. You may have to wait for the shiniest of your shiny toys to come into your domain, and maybe if they are particularly shiny, it's worth it to make a concerted effort to take that in and manage the risk, but overall people are rightly steered more toward curated repositories rather than anything goes.
Re: (Score:2)
I won't disagree that vs closed source commercial offerings I would be surprised if "widely used" FOSS components did not have fewer exploitable bugs.
HOWEVER...
The problem with the many eyes is exactly that everyone can look not everyone discloses... In the old days finding something like a buffer overflow was pretty doable - run it under debugger and look for your canary - figure out how to overwrite a pointer that lets you control a jump and whammy. Well before ASLR and DEP anyway
Locating and exploiting b
Re: (Score:2)
go solar (Score:2)
Scaled back? (Score:2)
So in my neck of the woods, I could say some folks have been made to 'scale back', but they are still using all sorts of open source software, in many cases ultimately the same open source software.
The difference is that developers are required to go through a bigger PITA process to pull in a project from github, a tarball, npm, pypi, etc etc. The rationale being those sources are completely wild west and require some sort of audit before pulling in and also recognizing that our audit will still not be goo
That's idiotic (Score:5, Insightful)
I understand that 99.999% (or some very high percentage), of people never review the libraries they use, something I'm guilty of, but when you run into a seriously weird bug or error, and you've limited it down to a library (ArcGIS JS), don't you want to edit the code and prove it, vs just wonder?
Saying stupid things like "Log4j showed the dangers of open source", is like saying "A chef at the restaurant last year under cooked my chicken, so I don't eat beef", it completely ignores the problem, avoids the responsibility of the decision, and demonstrates that you don't know what's really going on.
Log4j.... (Score:1)
Re:Log4j.... (Score:4, Insightful)
This is exactly my experience. When that first big log4j exploit hit the light, we didn't use it. We decided to look a little harder, and it turned out our super expensive ERP used it in separate interacting packages, it was using years-old versions, and it took quite a while for us to get updates from the vendor. It's quite an uncanny feeling watching your most mission-critical software turn into your easiest-to-exploit and having to gollum the thing for weeks.
Closed source these days is not like your parents'. It's full of third party projects that are not kept up to date, it's quite difficult for you to figure that out, and since you don't have the source you can't just fix things yourself when you need to. The closed vs open debate was and will never be about whether one or the other are more prone to failures, it has always been and will always be about which one you can get fixed faster when crap hits the fan so your business has to stop functioning for less time.
Of course (Score:3)
reports of "protestware"
I hope "protestwarers" are happy with the end result of their protest being a varying combination of: a) victims still not knowing what the protest was about or knowing it and now being actively opposed to whatever the protestwarer was trying to support, b) reduced to outright ban on usage of their software, and c) their reputation as developers, and thus their hireability, having gone down the drain.
Working as intended?
Isn't that the other way around ? (Score:1)
FUD? (Score:2)
Just FUD?
Do you know your ABCs? (Score:2)
Discarding OSS because of security concerns sounds so stupid! Yes, OSS has bugs, just like closed source, but the OSS community is usually faster patching them (indeed most of the severe security bugs are patched before they are publicly announced). On the other hand you have companies like Microsoft stating that Teams storing access tokens in plain text is OK and requires no immediate patching. You sure you can trust them?
I'm an IT Pro (I think)? (Score:2)
Open Source FUD from the Microsoft Register (Score:1)
Microsoft Engulf and Devour © .. (Score:2)
"protestware" shouldn't be allowed in open source (Score:1)
talk about shooting yourself in the foot. there should be a separate license for people who reserve the right to sabotage their code. but open source, released to the public and worked on with others shouldn't be allowed to be deliberately undermined by a malicious individual, even if it's the creator. there should be a "it's my ball and i'm going home" license for the cunts who need to reserve that right for themselves.