Secure Programming

viega writes "Matt Messier and I have just launched a secure programming web site. While this site does support our new book The Secure Programming Cookbook for C and C++ , it also serves as a thorough resource for developers. It has numerous links to articles and other topical resources, new recipes that demonstrate secure programming techniques a large glossary and the obligatory web log. We accept outside submissions, and will reward the best recipe submission each month-- O'Reilly will publish it on the O'Reilly Network web site and will give the author a free book. There's already a decent amount of new content, including recipes on avoiding malloc()/new-related integer overflows, watching out for security problems in API differences and issues when truncating data. There's also an RSS feed for the web log."

Comments

Run-on sentence time

[mao che minh]

Ten bucks says that this endeavor will go widely unnoticed by 90% of developers. Now I'm just a lowly IT worker, managing web servers and crawling under desks, but I do know that 95% of the developers in corporate America do not read Slashdot, and 95% of the ones that do are so intimately involved with Microsoft or Microsoft dependant technologies that this book/article/section/endeavor won't mean a damn. And before the trolls bark: YES, Microsoft = less security in development. Not by design - hardly - but rather because if a developer is working on a project that is Microsoft centric from the ground up, he/she is likely working on a time table set by some PHB a hundred miles away, and has been working on such projects for years, and has long since given up on making good, secure code, and rather coding whatever keeps his/her salary.

Once you have worked 50 hours a week in a corporate setting for 5 years as a developer (2 years) and a run-of-the-mill network/system/any-god-damn-thing-they-can-get-you -to administer(4 years, you will understand.

Warding off the inevitable "switch to Java" commen

[sco08y]

If you RTFA, or even just GATFA (glance at) you'll notice that the book has info on:

Random numbers

Input validation

Cryptography (e.g. ssh)

Buffer overruns are just one kind of problem you need to deal with when writing secure code. There are also DOS attacks and information theft. Even with Java, it can be quite challenging to ensure that data is properly encrypted and authenticated, and you still need to worry about permissions in the file system.

And let's not even dredge up the standard "why can't you just rewrite 100s of 1000s of lines of working C++ code in Java?" inanity.

Re:I blame colleges

[metallicagoaltender]

Blaming colleges is a complete copout - if colleges aren't teaching the proper skills, then employers should be rejecting applicants with inadequate skills.

The fact is, most companies couldn't give half a shit about security on a day-to-day basis, and therefore don't really care if people fresh out of college have a clue about secure programming, or even security in general.

The goal of college, in the context of our current society, is to prepare students to get a job - if employers aren't demanding it, then people aren't going to expect it to be part of a college curriculum.

Don't get me wrong, I fully agree it should be a core part of computer education right from the start, but until the technology industry recognizes it as a day-to-day need (other than the 2 weeks after you've been hacked), it won't be considered an important part of the educational process.

Re:We already HAVE the different language.

[dmiller]

It's called LISP.
(And before anyone says "... but you can't write a kernel in LISP!", there are several LISP Machines out there which beg to disagree with you.)

Yes, very true. "Several" is an excellent estimate of the number of LISP machines sold.