Report: Aging Java Components To Blame For Massively Buggy Open-Source Software

itwbennett writes: The problem isn't new, but a report released Tuesday by Sonatype, the company that manages one of the largest repositories of open-source Java components, sheds some light on poor inventory practices that are all-too-common in software development. To wit: 'Sonatype has determined that over 6 percent of the download requests from the Central Repository in 2014 were for component versions that included known vulnerabilities and the company's review of over 1,500 applications showed that by the time they were developed and released each of them had an average of 24 severe or critical flaws inherited from their components.'

Comments

The root cause : poor unit testing

[Dr_Barnowl]

Why?

Because if you don't test your code, you don't know if changes to it break it.

Changing the components your code is composed of is a big change.

Therefore : people get nervous about changing the components they have used (even changing the version).

What should be happening : when you're planning a new release, raise the component versions to the latest and run your test suite. If it passes, good job, release it.

What is actually happening : the version numbers never get edited, because that version worked, and if you change it, OMG, it might stop working.

Re:The root cause : poor unit testing

[DickBreath]

The root cause: poor management (in most cases)

The root cause is not poor unit testing. Not bad developers. It is managers who won't allow the change to be made. It ultimately will always come down to money. They are unwilling to spend on having a reasonable staging environment that closely mimics the production system such that making these changes could be done safely and receive proper testing. And people to do that work also cost money.

In short: management doesn't care, due to money. So the product can just self-destruct. (like SourceForge)

Re:The root cause : poor unit testing

[RabidReindeer]

This is somewhat deceptive. Sonatype supports Maven component archives.

One of Maven's chief claims to fame is that when you build a project, it doesn't grab "the latest" versions of dependencies, it grabs the selected versions of dependencies. On the grounds that "If it ain't broke, don't fix it".

This ensures a predictable product because everyone who does a build, no matter when, no matter where, will be pulling in the same resources to build with.

The problem arises when one (or more) of those selected component versions turns out to have issues. The build ensures that the product will be consistent, and thus will pass its own tests, but as the old observation goes, testing cannot prove the absence of bugs, only their presence. So if there was a vulnerability, an old project's tests wouldn't see it. And because you're asking for a specific library release version, later fixes don't get automatically included (of course, neither do later breakages, but they ignored that aspect).

In theory, then, this is simple to fix. Just update the project (POM) to pull in newer, better dependencies.

And the NEXT version of Windows will fix all your problems, and I've got a very nice bridge in NYC for sale cheap.

If you're working on a project, you generally have all you can do to keep up with issues in your own code, let alone some supposedly trustworthy third-party libraries. You cannot afford to be constantly updating the dependency versions and even if you could, there's the issue of "dependency Hell", where changing the version of Hibernate can conflict with the version of slf4j which can conflict with junit, which can conflict with... I usually like to budget 2 or 3 DAYS when I'm ready to start upgrading dependencies.

Sonatype doesn't get a pass here, though. If they/Maven supported a mechanism that could flag builds that have known weak dependencies, it would help a lot. Management, of course, would promptly command it to be turned off to ensure "productivity", but at least we'd have some help short of periodically manually auditing every library in a complex project (like that's ever going to happen).

What about JavaScript code?

[Anonymous Coward]

It's accepted in industry that JavaScript is an inferior language compared to Java. Popular only for its ubiquity in web browsers, JavaScript lacks most of the language features needed for writing robust, reliable software at a large scale.

Java does offer far more of the features needed for large-scale software development, while also attaining a reasonable level of quality. Java has a working type system, while JavaScript does not. Java supports real modularity, while JavaScript only supports hacks. Java supports classes, while JavaScript only supports crippled and near-useless prototypes. The list goes on and on.

Additionally, Java is typically used by trained professionals who have at least some formal education under their belt. JavaScript, on the other hand, is a language embraced by beginners who have no experience.

So if we're having problems with software developed using Java, and Java is better suited to software development than JavaScript is, then this means that the problems we're having with JavaScript are astronomically bigger than what we're experiencing with Java.

While we need to address these concerns involving Java, obviously, we can't neglect to focus on the major problems that JavaScript is causing, as well.

Re:Is this unique to Java?

[Anonymous Coward]

The last major release that "broke" things for me was the 1.4.2 -> 5 transition in 2004. Since then (5 -> 6, 6 -> 7, and 7 -> 8) have been relatively painless, If you were relying on an undocumented feature, or compiling against com.sun.* or sun.* classes you did so at your own risk. If you stuck to the documented JDK, you were usually ok.

This is not surprising

[ErichTheRed]

This basically defines some of the problems of "enterprisey" software:
- It's composed of a million glued-together libraries.
- It's written by chronically understaffed/overworked IT department employees.
- Rigorous testing either (a) doesn't exist, (b) is so onerous that most developers try to avoid it, or (c) is outsourced/offshored to the lowest bidder, and therefore isn't completed without the staff basically doing the tests for the outsourcer.
- Anything that breaks it is avoided at all costs because of all of the above.

By extension, this is why some companies are stuck running IE 6 for key applications, or Office 97 because rewriting the scary mess of macros that runs a process isn't something anyone wants to do. I do systems integration work, and new versions of Java, web browsers, etc. are miserable. They introduce bugs small enough to be annoyances (rendering problems, etc.) and big enough to break the entire system.

The key to fixing this is for the software architects to require that developers move up to at least a semi-modern release of their key libraries, test everything against them, and remove the old outdated ones once all the bugs are fixed. The problem is that this is never done.

Re:This is not surprising

[JustNiz]

>> The problem is that this is never done.

The reason is that many Software Director positions are now filled with technically clueless people that are basically salesmen rather than engineers.
They have no comprehension of the concept of technical debt, or the need to spend time on activities that don't directly translate into new features.
The net result is that you're always just piling more crap onto the top of a steaming turd pile so making it worse, instead of working to replace the shit.

Blame Maven

[_xeno_]

This is a problem that Maven has created, mostly.

What the summary doesn't mention is that "large repository of open source software" is a Maven repository. Maven allows you to specify dependencies for your Java project.

The problem is that you have to specify a specific version of whatever you use. So let's say you use OpenFoo 1.1 and that at the time you write your code, the latest version of OpenFoo is 1.1.3.

Now assume a horrible vulnerability is discovered in OpenFoo 1.1.3, so they release OpenFoo 1.1.4 to fix it. Well, your Maven POM says you require OpenFoo 1.1.3, so until you go in and manually change that, you will only ever use 1.1.3. There is - by design - no way to say "I want the latest 1.1 version." You can only describe a single, specific version.

So it's no surprise that Sonatype will see a ton of old Maven projects continuing to download outdated Maven artifacts. There's no way to say "I want the latest version of a specific branch" you can only specify a single version. Which means that a project that hasn't changed in years will still pull in the old versions of the libraries, even if it would work with the later versions.

Re:FUD

[DickBreath]

It's not FUD. It's clickbait. It will make up for the revenue shortfall from SourceForge.

Sonatype FUDs Open Source ..

[nickweller]

April 2013: "Sonatype's annual survey of 3,500 software developers and shows struggle in setting corporate policy on open source and enforcing it" ref

April 2013: "Control and security of corporate open source projects proves difficult | New Sonatype survey finds 80 percent of most Java applications comes from open source" ref

Nov 2014: "Software developers use a large number of open-source components, often oblivious to the security risks they introduce or the vulnerabilities that are later discovered in them." ref

April 2015: "open-source also represents a vast, unpatched quagmire of cyber-risk that’s putting public safety at grave risk. That’s the assessment of Joshua Corman, CTO at Sonatype" ref