Repost - Oracle CISO attacks Veracode

ell this week was quite eventful in the information security blogosphere and twitterverse to say the least.  The story of the compromise of the Diginotar certificate authority was revealed and even more interestingly the CISO of Oracle launched a thinly veiled attack on Veracode, a provider of source code analysis services and a diatribe against 3rd party assessment of Oracle's products.  There also was a thank you in there to another provide of security assessment services (potentially White Hat Security) for not outing Oracle vulnerabilities to one of their customers who requested that they assess some Oracle code.  Later on in the week, HP another 300 pound gorilla of the IT industry released a blog post weighing in on the topics raised.

Mary Anne Davidson of Oracle's initial blog post
Chris Wysopal's of Veracode's response 
Rafal Los of HP's blog post 

Well my commentary on the above unprecedented commentary is as follows:

Your visibility of vulnerabilities is limited.
You as a customer of a vendor have zero visibility of the security of the application software you are purchasing. It is worthwhile noting that Oracle is the vendor of a major database platform, an major operating system (Solaris, hey it's still major in my mind), a major application server (BEA Weblogic) and a major programming language (Java) and owns every piece of enterprise software in the market except for SAP (PeopleSoft, JD Edwards, Siebel etc.).  The only visibility you have is when the vendor publishes a security bulletin and an accompanying security patch (usually in response to a discovery by a security researcher). It is worth noting that if a vulnerability is discovered by a vendor rather than a security researcher it will be "silently patched" in the next release of the software.  You really have no visibility about the number of zero day vulnerabilities present in the software you purchase.

You have no usable benchmark to use to guide your purchases.
Mary Anne Davidson mentions Common Criteria assessment of their products as their choice for 3rd party assurance. If that is the case why has only one operating system and database recently been put through the wringer?.  Common Criteria evaluation criteria and resultant reports are brief, obtuse and impenetrable even to the security professional!  Anyway in this day and age of consolidated mega-corporations with monopolies, do you have a choice to not buy from them?

You are prevented from reverse engineering to have a look for yourself
End User License Agreements often prevent you from performing your own security research on vendor provided software; decompiling or reverse engineering is often expressly prohibited.  Lets give some love to the security researchers who often put themselves in the legal line of fire to benefit us all.

Vendors often have 3rd party evaluations performed but don't share them with you
It is common practice for security consulting organisations to be engaged as part of the software development lifecycle by vendors. However it is not common practice for the results of these assessments to be shared with customers.  There may be a good reason for this; security vulnerabilities identified by the 3rd party may not yet have been rectified in the product.  Is that really a good reason?  Shouldn't these vulnerabilities be fixed?   Wouldn't it be nice to see a report from a vendor along the lines of "we had product X evaluated by company Y during development, these issues were identified and rectified.  Extensive QA and security acceptance testing was performed to ensure no other vulnerabilities of class Z were present in the source code for product X".

I welcome your comments and views!