The "Software Book Index" Index

In not a single software development book that has crossed my desk during the past six months does the word security appear in the index.

By Lew McCreary

March 01, 2004 — CSO — Having become hyperattuned to the problem of software insecurity, I've been browsing the indexes of the many newly published books we receive here written on the subjects of software development and best practices in the fine art of programming—whether agile, extreme or traditionally kludgy. And guess what I found (or, more accurately, what I didn't find)? In not a single software development book that has crossed my desk during the past six months does the word security appear in the index.

My first assumption was that security is deemed to be of such massive importance to software development that it was given a chapter, even a section, all its own and thus transcended mere indexing (in a book on fly-fishing, the word fishing doesn't typically appear in the index). But no. No chapters or sections on security.

After ransacking my first book, I figured maybe the lack of any mention of security was an oversight by authors so inattentive that they'd left it out simply by accident. Or maybe it was even a bindery errorthe chapter was left out because the stitching machine suffered a security lapse of its own and barfed the in-depth examination of software security hygiene (Pages 37-59) out onto the print shop floor!

But then came a second book and a third. And a 10th and a 15th. And, folks, I'm here to tell you: This is no accident; this is a trend.

So, what's it all about? The simple answer is that creating the greatest functionality with the fewest keystrokes means making decisions about what's really important. For instance, in the minds of software programmers 30 and more years ago, rendering a year in four digits rather than two was a big waste of energy, disk space and processing cycles in an era when all three were precious. The result? Y2K. And, of course, a culture in which anything that slowed down development or added low-value program overhead was anathema.

In the developer lexicon, the word securitystanding for a pain-in-the-butt speed bump that doesn't do diddly-squat for functionalitycame to have no relevant place. That phenomenon was joined by another emergent aspect of software culture: the ultimately successful argument to customers that an unfinished, unperfected product is a lot better than no product at all. "Here! Buy this cool new program and let us know how it works! The stuff you don't like or that isn't quite right, we'll take care of it in Rev. 2."

• Print

• Patching Software: The Big Fix
• Software Patching: Patch and Pray