In other words, you are telling people to be careful when then they contract code development. That is entirely reasonable, and these days it is a prudent action and could even be considered a "best practice".

The contract language you linked to is another issue. At the time the Top 25 list came out, someone in the NY government mentioned the contract language idea. I agree with it, but he also said that he didn't expect the extra "guarantees" required from the vendor by this language wouldn't have an impact on the cost of purchasing custom code. Guess again. Take a look at that contract language:

- "single senior technical security specialist, to be known as the project Security Lead. The Security Lead shall certify in writing the security of each deliverable." great idea, but do you want to be the person who is signing this type of legally binding document, without first doing a lot of additional testing (compared to today)?

- "Vendor shall document the process including training courses that their application developers have taken prior to developing applications". The cost of that training in time and money is not going to be cheap, and the cost of maintaining that documentation is also not going to be cheap

- "The Vendor shall conduct an analysis of the attached 25 most common programming errors and document in writing that they have been mitigated" - that will require a lot of time and effort to document it all. And don't forget, although there are 25 "programming errors" on the list, there are substantially more "preventions and mitigations" to resolve those 25 "programming errors"

- The "Development Environment" section is nice, but I truly wonder if there is any third party software that currently meets all of the requirements.

- "The Vendor shall agree in writing that prior to production the application shall undergo vulnerability and a penetration test. " fine, who will do it, a third party? Well, that's a requirement few if any current software development projects do and alone it will be a large new "development" expensive

If all of the provisions are included in a contract, then by definition most if not all small software developer companies will be excluded because it will not be possible for them to comply with these requirements.

So while I think the idea is good in theory, I hope that customers take a close look at each project before simply copying in the full set of terms into their contracts.

"The cure may be worse than the disease".

The Top 25 list is a great starting point. It identifies the most common issues. But, it still needs to take the next step and be translated into more specific guidelines. I wouldn't want to hand the Top 25 to a programmer and expect him to implement it "correctly". Heck, I wouldn't want to do it myself, not without taking a lot of time to translate it into requirements/guidelines specific to the programming language I'm using. Some of the points raised by the Top 25 do not apply to all programming languages (because they don't have specific features).

PS: your article doesn't agree with your tag line. Kaspersky wasn't saying it was the programmer's fault, it was their own fault for not following their own verification process.

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/494/35407#35407