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

Ninety-one per cent of commercial applications include outdated or abandoned open source components, underscoring the potential vulnerability of organizations using untended code, according to a software review. Synopsys, a California-based design automation biz, conducted an audit of 1,253 commercial codebases in 17 …

[elDog]

To be fair, many company's services use unsupported and/or un-updated commercial packages?

Not saying that this article doesn't point out a valid concern.

Just that many in-house services and some commercial products bundle third-party closed-source programs into their works.

Many a time I've worked on an old application that used Access/ODBC for its 'back-end'. Or SQL Server and other DB libraries. To say nothing about Adobe's plethora of leaky products (ColdFusion, Flash), Microsoft's .NET libraries, various other networking interfaces.

[robidy]

Re: To be fair, many company's services use unsupported and/or un-updated commercial packages?

Cheap shot at open source, it's the same with closed source.

How many people find programs installing legacy Java or Adobe Flash.

[sabroni]

Re: Cheap shot at open source, it's the same with closed source.

You have any evidence of that or is it just a gut feeling?

A closed source comparison would be interesting. A committed blowhard venting their "opinions" less so...

[Anonymous Coward]

Re: Cheap shot at open source, it's the same with closed source.

If you go full stack open source then when you update the system, absolutely everything gets updated. *BSD, Linux et al will update the whole lot. I wrangle a lot of Windows servers and workstations for many different customers across a lot of industry sectors. Keeping that lot upto date is not much fun. For starters, each application is independent of the OS and may have its own update checker eg Java, or not. Do you even know what all those crufty old runtimes listed in add/remove programs does or if they are still needed? App management on Windows needs SCM or Zenworks or similar to even start to be manageable.

[robidy]

Re: Cheap shot at open source, it's the same with closed source.

Patch management and version control are principles.

They are not exclusive to close source software.

Experience of reading El Reg will show you it affects both.

[CheesyTheClown]

Don't forget Cisco!

Cisco Prime, Cisco IOS-XE, Cisco IOS, Cisco ISE....

I can go on... but Cisco absolutely refuses to use package management and as a result, may systems only release patches once or twice a year. When they are released, they don't upgrade nearly enough packages.

Consider Cisco ISE which is the security portal for many thousands of networks around the world for wireless login. It's running on Apache versions so old that zero day passed years ago.

Then there's openssl and openssh... they just don't even bother. It doesn't matter how many CVEs are released or what their level is... Cisco ignores them.

Then there's Java versions

And there's the other key issue which is that Cisco products don't do incremental upgrades. You either upgrade everything or nothing. So even with critical security patches, the vast majority of Cisco customers DO NOT upgrade their software because there is far too much risk that it will break more than it fixes.

Of course, even with systems like Cisco DNA which automates most things, upgrades are risky and sometimes outright dangerous since there's no means of recovering remotely when your infrastructure equipment goes down.

Cisco doesn't release information, but I know of at least several dozen government organizations running Cisco ISE releases from 2-5 years old with no security patches because you can't simply run rpm update or apt upgrade on Cisco ISE... which is really really stupid when it's running on Linux.

I think Cisco might be the most insecure enterprise company out there and the only thing keeping it from being more common knowledge is that the people who actually know about these things risk losing their meal tickets from making noise about it. And what's worse is that Cisco people almost NEVER know anything about Linux... or security unless it's protocol security.

[bombastic bob]

Re: To be fair, many company's services use unsupported and/or un-updated commercial packages?

Question: How much of "lack of updating" is CAUSED by "Feature Creep" and/or dependency nightmares that might RESULT in "Feature Creep" in OTHER things...

update lib -> must now update everything that depends on that lib -> feature creep that you did NOT want

yeah THAT sort of thing... and if it results in an incompatibility of a CLOSED SOURCE application, which then FORCES you to "not use the newer/fixed version" and no replacements are available, THEN what?

Yeah, you stick wtih your existing, "it works", stable system and NOT update. [they're often overrated anyway]. Keep it behind a firewall and practice "safe surfing".

[cbars]

Yea... just because an application includes a component with a CVE, it isn't de facto exploitable. For the most part though, you should clean house. The classic response to this suggestion is if someone is inside your firewall and accessing the application then you have bigger things to worry about. I'm not saying that is a good response, mind, but it explains these findings.

[Anonymous Coward]

Research, document, and periodically audit

If you are using open source code, good on you.

But do your research first and document what you are using, why, and who is maintaining it.

Then periodically audit this to insure that the code is still maintained.

Note that this should be standard practice for proprietary code as well as open source code.

At a minimum, delegate one of your IT staffers to read El Reg every day .

[DemeterLast]

Re: Research, document, and periodically audit

I recently got back into front-end development for some personal projects. The glut of package managers and automation tools is astounding. Also confusing, and hard to audit. npm alone hoovers up 4/5ths of the Internet to install a library to convert a timestamp to local time.

Just trying to deal with CSS preprocessors turned me into a lunatic. I gave up and installed sassc and went back to Makefiles for everything.

The speed at which developers are expected to turn around projects has gotten ridiculously short. Hell, even expecting there to be IT staffers is dated. Everything is contracted, and whatever random developer built your thingummy has already moved on new employment (twice) by the time the CVE is published. The next guy down the line can't even dissect what's wrong because the fancy CI/CD workflow the original developer used exists only on his laptop, which has by now had 6 new Linux distros installed on it.

I should have just gone into growing weed.

[Dvon of Edzore]

And this so-called study was sponsored by who, exactly? No maintenance activity for a year could also mean the code is stable and properly implements a standard function. I doubt there are a lot of new features that need to be added to the quicksort algorithm, for example.

I'd instead argue that too much churn in the product is a sign of instability such that it should not be relied upon by third parties. Consider the multiple versions of Microsoft .Net libraries found on any system in productive use for more than a week. Are all those being maintained or merely deprecated.

[Mike 137]

Thanks you Dvon of Edzore!

That has needed saying for a very long time. Constant or even recent "support" is not a mark of quality. At best it's irrelevant and at worst you've nicely identified the true reason for it - buggy code.

[I am the liquor]

Re: multiple versions of Microsoft .Net libraries... Are all those being maintained

You can criticise Microsoft for a lot of things but I don't think that particular criticism is a valid one.

You can go to https://support.microsoft.com/en-us/lifecycle/ and find out not only whether your version of .NET is still maintained, but exactly when it will stop being maintained too. Many other vendors, and most open source projects, will not give you that commitment.

Furthermore, when the version of .NET you're using goes EOL, and you have to move to a new one, you know Microsoft will have bent over backwards to maintain backward compatibility as far as possible, and your application will probably still work on the new version of .NET. Again that's something you cannot rely on with a lot of libraries, and it's a major cause of the problem the article is talking about.

[The First Dave]

Re: multiple versions of Microsoft .Net libraries... Are all those being maintained

"you know Microsoft will have bent over backwards to maintain backward compatibility"

Nice one, best bit of dead-pan so far today!

[I am the liquor]

Re: multiple versions of Microsoft .Net libraries... Are all those being maintained

Microsoft are notorious for being obsessive about backwards compatibility. Even refusing to fix bugs on the basis that it would break stuff that relies on the bugs... Excel still thinks 29/2/1900 is a real date. That one's not even their own bug, it's for backwards compatibility with a bug in Lotus 123!

[cschneid]

Agreed, regarding out of date; old != bad, in fact sometimes old is preferable to new when licensing changes in a manner unfavorable to the customer or the latest version insists on phoning home to a server for reasons unknown.

Unsupported is something for risk management to consider.

Insecure still needs to be addressed.

[Ken Moorhouse]

Receiving data from an external source

In general terms, if data is being sent to, or receivied from a place that the coder has no control over, surely it is best to try and sanitise that data at the border rather than accepting it or assuming that it will be sanitised? I have come across components where they do not work properly unless e.g., compiler bounds-checking switches are disabled, which worries me enough to make me want to steer well clear of such components.

An easily visualised example might be where the third-party might be asked, directly or indirectly, to perform a divide by zero operation. Many coders will assume that the library will handle this and report back, to that effect, but I suspect there are many of us who consider this bad practice, and will take steps to verify this isn't going to happen prior to passing parameters across, or to independently sanity check what comes back before making use of it.

Ok I'm sure that doesn't cover every eventuality surveyed, but I suspect it accounts for many scenarios analysed.

[Kabukiwookie]

This should be no surprise to anyone who has had a taste of the 'it works, so it's ready for production' style of working within projects that use 'Devops' en 'Agile'.

It's either 'good', 'fast' or 'cheap', any combination, but you can only alwqys have two ; the current Devops//Agile projects have chosen 'fast' and 'cheap'.

Has nothing to do with whether these projects are using closed or open source software aside from the fact that the only reason Open sourse is used is to cut cost.

[Muscleguy]

Or that there isn't a commercial equivalent which bundles everything you need (because licences) and getting two commercial packages to talk to each other is another kettle of fish. So you go open source components instead.

[sabroni]

la la la

Can't hear you!!!

[Locomotion69]

O dear

Only to realize someone is not maintaining an app that should legally not exist in the first place...

[Anonymous Coward]

Frankestein development, thanks to Stackoveflow, Github & C.

More and more developers no longer write applications. They glue together code sourced from somewhere - usually without checking how many people maintain it, the quality of the code itself (just how many other fools use it), the license, its security. Just look at the packages without a maintainer because the single developer was jailed. Or those removed on a whim. Most of them have nothing in place to ensure each library is vetted and upgraded when necessary. Yet, the more code comes from outside, the more difficult to manage it all.

This survey doesn't surprise me at all - I've seen this trend for years now. When you had to spend money to license library, that very money made you much more careful about what you bought and how well it was supported. It was true that scroogey companies for that same reason often avoided to pay for upgrades, and kept on using outdated and risky code.

Software development took the wrong path, and one day it will become much clearer, at our expenses.

[Warm Braw]

Re: Frankestein development, thanks to Stackoveflow, Github & C.

In principle, it ought to be a good thing to avoid producing code that duplicates available code that performs the required function and that has been widely deployed and tested. That's what modular programming is all about.

And while open-source software may not always be well maintained (and is often even less-well documented), commercial software maintenance is not necessarily better - in practice money doesn't get spent fixing stuff unless there's a pressing reason to do so.

If you view software as a one-off cost, then there's obviously an incentive to use a "free" source. If you take a more long-term view you have to weigh the cost of developing and fixing your own software against the ongoing effort of trying to understand what fixes may have been made to third party software that might affect your application. Or, maybe, having to fix the third party software yourself, perhaps at the risk of forking it as you don't want to take on the responsibility of being a maintainer, and then being forever out of step.

It's not so much about where the software comes from as how far beyond the next scrum you're able/permitted to think.

[Anonymous Coward]

Re: Frankestein development, thanks to Stackoveflow, Github & C.

Just look at the packages without a maintainer because the single developer was jailed.

Uh? Is this a common problem?

[Korev]

Re: Frankestein development, thanks to Stackoveflow, Github & C.

It's an extreme example, but things happen. I remember a Centos release a few years ago that was delayed because the lead developer was getting married!

[Ken Moorhouse]

Re: Uh? Is this a common problem?

I think this is a reference to:-

https://www.theregister.co.uk/2020/03/26/corejs_maintainer_jailed_code_release/

[Anonymous Coward]

Re: Uh? Is this a common problem?

I think this is a reference to:-

https://www.theregister.co.uk/2020/03/26/corejs_maintainer_jailed_code_release/

That's a relief. I was concerned that dabbling in JavaScript inevitably led to darker things like heroin and C++.

[Anonymous Coward]

Re: Uh? Is this a common problem?

Oh, it does, but that's a different issue. Heroin is really fine: it's the C++ that's a problem.

[Roland6]

Re: Uh? Is this a common problem?

>I was concerned that dabbling in JavaScript inevitably led to darker things like heroin ...

Personally, I suspect the unscrambling of someone else's sed script can lead to things like heroin ...

[fnusnu]

Re: Frankestein development, thanks to Stackoveflow, Github & C.

ReiserFS

[Anonymous Coward]

It's an Open Source package, so let's not update it

Really?

I would have thought this might be a good surrogate for whether or not companies update any external packages. There could pressure could be in the opposite direction - let's not update the closed packages that we don't pay the maintenance on anymore.

Or let's not update anything unless we have to, because costs developer/tester time too. etc.

[Anonymous Coward]

No real ongoing support

I suspect part of the issue is how software projects (or any projects really) are delivered and maintained within companies.

In my experience within large Enterprises, in the UK and US, there is no real concept of ongoing support for software they develop (other than ongoing things like monitoring logs, restarting services etc).

• A project will come along, internal or for a client, and they want some software, or a new application/service.
• A project team is stood up, PMs', architects, developers, testers etc.
• Requirements are defined and agreed, and the project delivers, tests and eventually hands over the resulting software/application to the user.
• Assuming everything gets sighed off, the project team is then stood down, disbanded, and the individuals head off to their next projects.
• Hopefully the delivered software is well documented (ha!) and sat in a supported repo somewhere, with instructions on how to build etc.

But in my experience, once the project team has been stood down, there is no one in the company actively doing anything with that software anymore. It's just not something Enterprises, at least the ones I've worked with, seem to even think about!

Generally the only time the software would get looked at again, is if a serious bug was found (that didn't have a workaround), or an enhancement was wanted, (new feature etc). At which point costs would be agreed, a new project team stood up (most likely different people than the first), and off we go again.

This 2nd (or additional) project may well insist on an 'uplift' step first, to bring all the libraries, frameworks etc up to date, but I've seen this step shot down many times due to 'costs vs perceived benefits', so the old libraries stay in.

Part of the issue is of course that many companies have the tail wagging the dog, i.e. the accountants making decisions, rather than say security experts, or (a competent) Enterprise Architect, and the accountants being there to support these people instead of dictating to them.

I can't see this changing any time soon, as this is just too ingrained, at least withing large Enterprises!

[Anonymous Coward]

hall of shame

(posing ANON for obvious readsons) OK let's paste in some amusing stuff off of the busiest of our production servers:

[user@prodserv~]$ java -version

java version "1.6.0_35"

OpenJDK Runtime Environment (IcedTea6 1.13.7) (rhel-1.13.7.1.el6_6-x86_64)

OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)

[user@prodserv ~]$ uname -a

Linux svc46 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

The reason we're stuck in "ancient software hell" is mostly to do with being tied to some _proprietary_ software that won't let us upgrade the rest of the stack.

Our ~$500m revenue company is too tight to upgrade from Oracle 10, or hire some devs to migrate to Postgres already, hence we use linux kernel 2.6, hence java 1.6 only, and so on.

[Anonymous Coward]

Re: hall of shame

Similar here. We have some 3rd party apps running on Windows 2008, and others on Windows 2012, over 100 VMs in total running in a DC. Can't update any of them as the app versions we have don't work on newer versions of Windows, and client has refused to pay for updated versions of the apps that will run on a newer OS! Some of these are even externally facing! (Got a few RHELs' in there as well for good measure, 5.11!).

[IGotOut]

Those figures don't add up.

So 91% of Business Applications have out of date software (which is going to be a bullshit figure to start with).

Then....

"Ninety-one percent of the audited applications had components that are either four years out of date or have exhibited no active development for two years."

Well that means 100% of "out of date" programs have components that are four years out of date or abandoned.

[Anonymous Coward]

Orthogonal problems

All this really means is that, it turns out, there are two orthogonal problems here: the problem of using closed-source software (which may or may not be a problem depending on who you are) and the problem of keeping your software up to date which usually, but not always, is a problem.

And, since these are orthogonal problems, it turns out that solving one does not solve the other. Who knew?

[Anonymous Coward]

Re: Orthogonal problems

Open Source is cheap, so security is cheap too - my company loves open source.

Regards,

PHB

[Anonymous Coward]

TANSTAAFL

So most companies are using open-source code in their applications - but a lot of it is badly maintained?

There ain't no such thing as a free lunch.

[Timo]

Software life cycle is like buying someone a puppy

I've always said that software is like buying someone a puppy. It all sounds great when you look at them, they're so cute, etc, and they don't seem to cost that much. But then you get them home and have to buy food for them, and someone has to go pick up after them.

Software is much the same way, its so "fun" to create stuff, but 90%+ of the cost is in maintaining it for the rest of its life. Many companies run in and try to save that initial money by using open source or free stuff, but then they don't realize what they're getting themselves into, in that they're also on the hook to support it and maintain it. If you could do some estimates of those costs over the life, then maybe commercial software with a support contract wouldn't look so expensive. Not to mention the opportunity cost of your people who could be doing other things.

But I suspect that many companies just go for the cheapest up front cost and hope it all works out with no plans at all for maintenance.

[teebie]

"Ninety-one percent of the audited applications had components that are either four years out of date or have exhibited no active development for two years."

So if a component already works and nobody is mucking about with it then that is a bad thing?