Contracts DO NOT Equal Security – New York and Secure Code

by kriggins on January 16, 2009

in General, programming

Hi folks.  Yesterday, I included this story in my Bits post. It is about new procurement language that says software vendors must "certify" that their software does not have any of the Top 25 Errors released by SANS/CWE early this week.

I have read several blog posts on the topic since and today the topic came up on The Security Catalyst Forums. (You should check those out it if you haven't already. Great conversations and community.)

One of the questions posed was this; does this approach seem like something that should be encouraged?

Below is the response I posted.

Two main things pop out at me with this type of thing.

The first is this phrase "must certify that they have rid their code of the Top 25 Errors." What about the next 25 or the next one? I read a blog post over the last couple days that talked about this very well. Blocking where I saw it. If I find it I will update the thread. The essential bit was that "certifying" that you have addressed the top 25 errors doesn't mean your software is secure. That "26th" error  can be a show stopper too. Say it with me, compliant does not equal secure. Before people yell at me, I am not implying that we shouldn't address the errors listed in the top 25. (side note: Kees and some others have been pointing out that the 25 may not really be 25)

My second concern is this, sayin' it doesn't make it so. Creating contract language like this can lead an organization to a false sense of security. I can see where orgs might go the route of "the contract says the software is secure so we don't need to test it or perform a risk assessment." Again, that 26th error can hurt a whole lot.

Just my 2 cents worth. It's super cold in Iowa, so flame away Smiley

Like it says above, these are my thoughts. What are yours?

-Kevin

Previous post:

Next post: