A few weeks back JBoss Enterprise App. Platform 4.3 achieved Common Criteria Certification at Evaluation Assurance Level (EAL) 2+ – here’s the press release and here’s the evaluators updated page.

Common Criteria Evaluation is an internationally recognized standard that defines a  framework for computer systems users to specify security requirements; for vendors to implement them and for third-party evaluators to test them. The Evaluation process ensures that this is all carried out in a consistent, formalized and standard way.

The Evaluation Assurance Level (EAL) describes the “depth and rigour” of the evaluation not necessarily the security hardness. Though products certified at Level 7 (the highest) are likely to be deployed more demanding and secure environments than a product certified at Level 1 (the lowest). EAL 2+ means the products have been evaluated in collaboration with the vendor (eg. to provide development, design and test documentation).

What this means is that customers who care about security (who doesn’t ?) can be assured that JBoss Enterprise App. Platform 4.3 will meet commonly accepted, best practice security requirements. Even outside military and government use, who use Common Criteria as a benchmark, this evaluation should demonstrate Red Hat’s commitment to security. It’s a long and fairly involved process and the costs aren’t insignificant.

This is the first successful evaluation for a JBoss product but the JBoss Data Services Platform is currently in process and we’re already planning for a more stringent evaluation (higher EAL) for JBoss EAP 5.x.

Government and commercial organisations… should use open source applications with great caution”

absolutely true – but also true for software developed under any model with any license.

Open source projects should adopt robust security practices from their commercial counterparts.”

for some reason Fortify believes that commercial software is the benchmark for software security – though doesn’t provide any evidence of that, nor does it provide any detail what those practices are. Many commercial software companies are proprietary and closed and lack transparency – so we really don’t know if they’re better or worse. I’d also suggest that commercial / proprietary software companies can learn a lot from open source – and indeed many have.

But here’s the real issue and the irony – Fortify could not write this report for closed, proprietary products – they would not be able to include proprietary products in this report. it’s just not possible. That should be a real concern.

IMO – the recent report from Coverity offers a much more balanced view of security defects in open source

On the whole – the report was pretty positive on JBoss. Firstly, Red Hat sponsored projects did pretty well in their static analysis. As you can see from the chart – the vulnerability density for JBoss AS and Hibernate were the lowest of the projects analysed.

Secondly – our sponsored projects benefit from Red Hat’s security response team and their best practices, in addition JBoss has it’s own security expert – Anil Saldhana.

Since the report was published we’ve also taken action to ensure Red Hat’s secalert mail alias is more prominent in more places.

Finally – I should add – we take security pretty seriously and invest pretty heavily – we have to do this because our customers demand it. One example is that JBoss EAP 4.3 is currently undergoing Common Criteria Evaluation at EAL 2+ – that a pretty serious and long term commitment.

Update – I noticed that Fortify has a blog “… a place for place for discussion and feedback, both positive and negative” unfortunately they’ve blocked comments – so maybe not.