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.
How is it different for closed source software? (Score:5, Insightful)
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?
Re: (Score:2)
Re:How is it different for closed source software? (Score:4, Interesting)
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.
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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
Re:How is it different for closed source software? (Score:5, Interesting)
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.
Re: (Score:3)
Unless, of course, you split the development costs among multiple customers!
*sigh*
Re: (Score:2)
Which is an excellent way to make your product a non-competitive also-ran.
Re: (Score:2)
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.
Re: (Score:2)
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).
Re: How is it different for closed source software (Score:1)
Re: (Score:2)
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."
Re: (Score:2)
I've worked at companies where software was intended as a strategic advantage. I've worked two places that sold their software, and one where it's held close because it gives us a competitive advantage. Working where software is a core competency is different. We use F/OSS or third party proprietary for lots of things, but we have to write our own core software.
Re: (Score:2)
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".
Re: (Score:2)
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.
Re: (Score:2)
Because you need competent people for that.
Re:How is it different for closed source software? (Score:5, Interesting)
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.
Re:How is it different for closed source software? (Score:4, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
How do you think you protect your carreer?
By maximizing failure?
Re: (Score:2)
Free as in Beer. Not free as in "doesn't cost anything to implement and maintain".
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.")
Re: (Score:2)
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
Re: (Score:2)
yeah, so basically if that commercial software company don't send you any notice, you can safely assume you are secure, right?
Re: (Score:2)
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
Re:How is it different for closed source software? (Score:5, Informative)
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.
Re: (Score:2)
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.
Re: (Score:2)
Yeah, OK. But how much 'closed source but free' stuff is there, compared to open source? Virtually none.
Re: (Score:3)
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
Re: (Score:2)
'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
Re: (Score:2)
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
Re: (Score:2)
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.)
Re: (Score:2)
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.
Re: (Score:2)
This is exactly the problem. It should NOT be up to the sysadmins, the sysadmins do not own the systems (though many like to pretend they do). Take the Equifax example: when that happened everyone was demanding that the COMPANY must be held responsible. But how can the COMPANY be held responsible if the sysadmins are the only ones who know what is on the systems?
Re: (Score:2)
Errrr...because the company had no policies for checking security issues outside of a lone sysadmin?
Re: (Score:3)
THAT IS THE WHOLE POINT. Companies do NOT have policies regarding open source, so in fact they DON'T have a way of checking for issues. The article is not saying using open source is risky, or anything like that (which is how many here read it), but that you must have a POLICY regarding open source so you can remain in control of your systems. You can't just have people (admins or not) installing anything they want willy-nilly and stay in control.
Re: (Score:2)
Companies need policies that cover software, including licens
Re: (Score:2)
Gee, perhaps the COMPANY should be responsible for knowing how it is conducting its business?
There is a rather ancient business process called "auditing". The corporate officers who fail to institute information systems auditing are guilty of failure to handle their fiduciary responsibilities to the stockholders and should be tried in civil courts. And when it is on the scale of the Equifax debacle, it is very likely that the negligence was criminal.
Re: How is it different for closed source software (Score:1)
Except in the Equifax case the patch was to struts, so the issue is likely with the development team not the sys admins.
I'm on the process of documenting all opensource components being utilised in a software project I've inherited. One of the first things I did was to inventory all the components, and create an archive of all the packages required to build. However this is rarely done in many companies which was one of the points of the article.
The jibe about companies contributing is a bit of though. What
Re: (Score:3)
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:3)
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
Re: (Score:2)
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.
Proprietary is not necessarily Closed (Score:2)
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
Re: (Score:3)
Yeah, I know, DFTT [rationalwiki.org]
> People use closed source software knowing full well that the product may be discontinued, or it may go unmaintained at some point. The risks are well known and understood.
The software being open or closed is irrelevant [wikipedia.org] to the discussion.
> All we need to do is look at GitHub, SourceForge, or Apache to see that most open source projects do in fact end up dead. Of course, open source advocates don't admit to this.
[[Citation]]
The _difference_ is when Vendor A goes out of business you a
This article is an advertisement for Flexera (Score:5, Interesting)
Re: (Score:2)
more like 50%... (Score:2)
48% are week-old Ars articles
2% are bizarre non-articles, like an opinion post on somoene's personal blog that nobody reads, or some comment made on gihub.
Re: (Score:2)
Closed Source is Better (Score:1)
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
Re: (Score:3)
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..
Re: (Score:1)
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.
Re: (Score:2)
You do realize that the quote was from an old IBM advertising campaign right?
Re: (Score:2)
Who got fired?
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:3)
Re: (Score:2)
If you think the same problem exists in closed source, you clearly did not read the article (or summary).
Re: (Score:2)
Re: (Score:2)
Obviously that should be the policy. That is not what the article is about. What the article is saying is that if anyone in your company is free to install or use FOSS, and there is no tracking of that, you have no way of enforcing that policy because you don't know what is installed where. If the CIO sees a report that says Struts has a vulnerability, how is he supposed to ensure that all the systems running Struts are patched if he has no idea what systems (if any) are running Struts?
All the article is
Re: (Score:2)
If licensing is the only thing that prevents you from installing random third-party software on mission-critical machines, I think there is a bigger problem than lack of FOSS policy.
Companies do need FOSS-specific policies, but that mostly falls under license compliance. The software used on their public facing servers, FOSS or not, should be well documented.
Re: (Score:2)
I think you're looking at the wrong thing. If one of your developers installs some F/OSS on their personal machine, who cares? If anyone can install something on production servers without some record, you're already screwed, and you should update your resume.
It's easy to forget (Score:4, Interesting)
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.
Re: (Score:2)
Not a priority (Score:1)
As opposed to closed source? (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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 is about third party software, not esp. OSS (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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 ... )
Re: (Score:2)
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)
Check out the primary source: Flexera. They are definitely not supporters of open source software.
Their business relies on closed source.
"software monetization specialist Flexera..." (Score:5, Informative)
Re: (Score:2)
I am going to go all out and say it... (Score:2)
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
FOSS (Score:2)
Closed (Score:1)
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 ... (Score:2)
Many eyes make bugs shallow, but that doesn't work if you keep them closed.
Flexera agenda ... (Score:2)
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.
monetization specialist (Score:3)
Companies overlook risks in _all_ software (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
And the uncontrolled use of other software is not risky? Your statement is nonsense.
Re: (Score:2)
#AllUncontrolledSoftwareMatters
GPL Violations (Score:1)
Closed source limits your Company (Score:2)
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
Bad devs (Score:2)
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.
What risk? There was a patch (Score:2)
The only risk here was the incompetent management, and use of default admin/admin login