Friday, March 28, 2014

ESAPI No Longer an OWASP Flagship Project

I read the news today oh, boy…

By now, you’ve probably heard about several of the OWASP board members (and perhaps, some bored members as well) coming to the conclusion that several of the current OWASP flagship code projects should be demoted and others should take their places. (If you’re not up on the news, you can read about it in these 3 email threads archived here, here, and here.)

Among the flagship projects suggested for being demoted is OWASP ESAPI, of which I am the project owner for the Java implementation.  After hearing about the recent ESAPI Hackathon, you may be puzzled or perhaps even surprised by this news. You shouldn’t be. While it may sound like heresy coming from an ESAPI believer, although I am not happy about it, I think this action is long overdue and is best for OWASP. So I guess I’m sorry if I disappoint those of you who are ESAPI fans because I’m not standing up for ESAPI and defending it, especially since it's not yet a done-deal.

I’m not, because I can’t. I, for one, can see the writing on the wall. (Pun intended.) All of the allegations that are being made against ESAPI are spot-on:
·         Only one minor point release in since July 2011.
·         164 open issues, including 4 marked Critical and 11 marked as High.
·         Far too many dependencies, something that has never been addressed despite being promised for almost 3 years.
·         Wiki page still in the old OWASP format.
·         Minimal signs of life of for ESAPI 3.0 in GitHub and ESAPI 2.x for Java on Google Code. Zero signs of life for implementations in other programming languages. [Note: Discounting the SalesForce one as I’ve not kept track of it.]
·         For ESAPI for Java, a boogered up architecture where everything is a singleton making some things such as mock-testing all but impossible. Less than 80% test code coverage, in part, because of that.
·         Lack of any significant user documentation outside of the Javadoc and the ESAPI crypto documentation.
·         Disappointing participation at the ESAPI Hackathon.

I could go on, but I won’t.

ESAPI has dropped the baton and I’ll take as much blame for that as anyone. I have neither the contacts nor the people skills needed to entice developers to participate in ESAPI. Of the 3 or 4 people that I have recruited at one time or another, they’ve not contributed to even a single bug fix. And it goes beyond that. I’ve still not yet put together a release based on the few updates (a couple minor bug fixes and a small enhancement in handling configuration files) that were done by those participating at the ESAPI Hackathon. I have also still yet to release a fix for CVE-2013-5960. (Aside: Hey! Could use a little help here! Ideally someone who knows a thing or three about crypto.)

It’s time that ESAPI yield the baton to some of the other worthy candidates like OWASP HTML Sanitizer, OWASP Dependency Check, and OWASP Java Encoder to name just a few.

What does this mean for ESAPI support?

Well, probably nothing. I mean, honestly, the support really hasn’t been that great in the past 3 years. I do suspect that it might radically give those thinking about adopting it for a new project a reason to rethink that commitment though.

I will personally commit to trying to fix any known bugs in the ESAPI crypto (including a few you didn’t even know were there; well, okay, maybe “annoyances” would be a better tem), including a fix to CVE-2013-5960. But I am likely through with any planned feature enhancements other than the minor ones that I’ve been working on. If I do any further enhancements for the crypto features, I will split off ESAPI Crypto into its own new incubator project. No more promises of time frames though. I work a 40+ hour job like most of you and the ESAPI work is volunteer hours and I have family and other commitments as well.

As for ESAPI 3, will it flourish or die out before it even gets started? Well, that’s up to you, OWASP Community. I certainly am a believer in the ESAPI concept of a common set of interfaces for common security controls, but the problem has always been the implementation, not the concept. As they say, the devil is in the details.

So if you want to volunteer to work on ESAPI, give us a shout out on the ESAPI-Dev list. If you aren’t already signed up, you can sign up here.

Best regards,