back to article Devs spanked for touching vulnerable open-source packages

Developers are sucking buggy open-source programming frameworks off the web unaware that newer fixed versions exist, according to a new report. Packages of the Google Web Toolkit, the Spring Model View Controller, and Apache's Struts and Xerces have been downloaded millions of times despite the fact they contain known …


This topic is closed for new posts.
  1. Bruno Girin

    What this doesn't say is how many of those downloads of old versions are done knowingly because devs are working with legacy code that only supports Tomcat v3. RC1 and nothing else? Or because the company policy mandates a particular version of a product irrespective of whether it has security holes or not?

    1. Dave Perry

      Didn't see your comment before posting mine. We get annoyed users if things break due to upgrade, which is why I do as much on VMs as possible. And have a clone to try this stuff out with.

    2. Kanhef

      Another problem is that package providers don't always have a fixed URI that always points to the latest version. Open-source projects have a tendency to become unmaintained without notice, at which point there's no one to update it to use current packages.

  2. Dave Perry

    One thing not mentioned here

    Sometimes new releases of libraries break applications. In the windows world, for example, we have software we rely on (and is very expensive) which breaks if the wrong version or service pack of .NET is installed. That isn't helped by these companies not updating their code very often (we had to wait nearly a year to get IE7 everywhere as the web front ends were only built to work in IE6, sadly I'd get in trouble for naming the company in question).

    Another app (I'll happily name) is the Shibboleth Identity Provider. As a tomcat webapp (which I hate as it's complex and I don't understand it) I'm reliant on public information about which versions of Xerces libraries are compatible with Shibboleth. And getting an apache-tomcat stack, with the certificates at each end, that'll talk to secure service providers, is a pain in the backside I'm unwilling to do unless our SAN blows up and the extra backups go boom.


  3. An0n C0w4rd


    I used to think Coverity was a useful analysis until they said PHP 5.3 has .2 bugs per 1,000 LOC. From a purely "gut feeling" standpoint, without counting actual bugs, it feels like number of security bugs that PHP fix in the average year is higher than the old favourite: Microsoft Windows

    Either that or PHP has so much code that its code density is low but its actual number of vulnerabilities per release is still too high.

    Pity as I kind of like PHP from a pure "ease of programming" standpoint.

    1. Kanhef

      Re: Coverity

      They used automated static analysis to search for bugs; there's no practical way to go through several hundred million lines of code by hand. I'm sure people have found clever ways to write bugs that can't be found by that approach.

  4. PyLETS

    modular applications and long term support distros both needed

    If you want to run a somewhat outdated version of Tomcat/Apache/Sendmail or whatever, you're better off getting this with a supported stable version of Debian or RedHat, or maybe Ubuntu LTS than original developer sources, given that the upstream developers tend not to be interested in backporting security fixes nearly as much as the downstream enterprise stable distributors are.

    That's what stable distributions are for. It's also why large statically compiled applications are evil compared to those using dynamic libraries, and I'm not just talking about wastage of memory and diskspace here. However, there are still times when maintaining a stable service requires that you plan your migration off an old platform - when it's no longer security supported.

  5. Anonymous Coward
    Anonymous Coward

    Wake up call? you'll need 40Kv to the testes for that one

    What does some guy making a soundbite headline think is going to wake everyone up, when 9/10ths of the time when you discover a issue, the vendor just ignores it.

    There are some good ones that will turn around a fix in days rather than spend the next 4 years managing the risk on some post it note stuck to the underside of the boss's desk where nobody will see it, but sadly they are few and far between and getting rarer in this cut price world of ours.

    The vast majority with issues already know their products stink, they've probably been told the same by their tech leads but talk it away. The people running the companies do not care. Product is selected by the majority of customers on the bottom line alone. Wake up call? don't make me laugh.

    Welcome to a brave new mba led world.

  6. toadwarrior

    probably for a "good" reason

    No one actively chooses to have the an outdated version. I suspect there are dependencies for those versions thanks to companies not respecting our trade enough to give time to allow developers to port to newer versions. You can't have code done on the cheap and expect top quality code running on the latest and most secure versions and unfortunately a lot of companies don't care to have that.

  7. daveeff

    Testing, testing,...

    There is is the minor issue of shipping stuff with known bugs vs shipping stuff with unknown bugs. Yes the old version has some vulnerabilities but without spending time and money we don't know the new version doesn't format c: or rm -r /*

    Things we know we don't know and things we don't know we don't know....


This topic is closed for new posts.

Other stories you might like