Secure Coding: Principles and Practices

Features

• Cover Type: Paperback with 200 pages
• Published by: O'Reilly Media, Inc.
• Edition: 1st Edition July 2003
• Written in: English
• ISBN 10 Number: 0596002424
• ISBN 13 Number: 978-0596002428
• Book Dimensions: 9 x 6 x 0.6 inches
• Weighs: 10.6 ounces

Reader Reviews
You may have a hi-tech lock on your door, 100% unpickable. If I can just slam my shoulder against the door and jerk it loose from the frame, the fancy lock is irrelevant. Passwords, encryption, and all the rest are the lock. This book is more about making the door and frame strong. Remember the Blaster worm? That wasn't a 'security' problem. It exploited bugs in Windows that supposedly had nothing to do with security. This book is about building programs that resist attack. That doesn't mean copying a safe code fragment into your program and declaring it safe - that idea is ludicrous. Instead, this book is about the process that designs and implements strong programs. It starts with architecture and design documents, then follows through to design and maintenance. The weakness of this book is lack of detail - how to build fail-safe code, what needs to be on design and inspection checklists, etc. There's good reason for that: each sub-topic needs books, if not whole libraries of its own. Take fault tolerance, for example. It may not sound like security, but an attack is meant to cause system failures, and fault tolerance is design to withstand failures. Fault tolerance is a huge topic, with journals and literature all its own. This book can barely mention the idea, while still giving other topics their due. It's a start, though. Much of the advice may sound drearily familiar: code reviews, security audits, configuration control, error checking, and all the other things that take the 'fun' out of programming. If people want that kind of 'fun', then stop calling them software engineers. They're not ready for adult responsibilities. Before anything else, software security requires correct behavior from a program. I really hope I don't hear objections to that as a basic design goal. Comment | | (Report this)