Fog Creek Software
Discussion Board

Secure coding

This appears to be the hot topic these days, with Bill's Memo and all.

I just wanted to see what you people thoughts were on this: (SecurityFocus)

From my personal point of view we lack the tools needed to produce secure software without sacrificing time-to-market and program features.

Rafael F. Ferreira
Sunday, February 3, 2002

Security is an emergent property.  Therefore I think it needs to be an explicit design goal, just like any other piece of functionality.

You will still have holes, because a good design is still vulnerable to coding bugs.  But security should mean a _reduction in response time_ for fixing the hole.

Bad design = longer response time.  Holes in well-designed code tend to be quicker to fix.

Red Davis
Sunday, February 3, 2002

Seems to me that it comes down to people. People write software and people are fallible. Fortunantly, people can be trained. Problem is the american collage system does a damn lousy job of it when it comes to security and/or quality. Want secure code? Turn out people that understand _how_ to build secure code (training), that are motivated to create secure code (compensation schedule), and work in a culture that promotes quality in all it's aspects, not just the quality of "security" as some ethereal goal. I've acutally taken collage courses an at a top 10 CS school in the US where I was _discouraged_ from writing good code over writing code quickly. So long as it worked for the test case...

I think the question is really one of motivation and quality, people will either seek to become trained or train themselves once quality is a goal and they get paid based on the quality and not just the quantity of their code.

As for the MS memo, I for one am not holding my breath. I have the feeling that I'll be running OpenBSD and hardened Linux boxes for quite some time yet. It's a trust thing, and MS wasted whatever trust they ever had in the security community with IIS and Outlook.

Alex Russell
Tuesday, February 5, 2002

I think that programmers need help from their APIs to write secure programs. The most common security bugs are well-known, such as buffer overruns, running a program with root permission, or writing files to the /tmp directory. Bad APIs, like gets() or strcpy(), need to be replaced with secure functions such as strlcpy(). New APIs should be created that help programmers to common things, such as writing temporary files or needing root permissions, in a more secure manner. Unix, in particular, seems to be afraid to introduce new APIs or remove deprecated APIs like gets().

"strlcpy and strlcat - consistent, safe, string copy and concatenation"

Banana Fred
Tuesday, February 5, 2002

*  Recent Topics

*  Fog Creek Home