colin dellow's bln

Chapter 2 describes how to weave security into the traditional software development lifecycle from start to end, including training.

Cohen:

Chapter 2 misses by so much it's not even funny. The authors give fundamental misimpressions, for example, that secure software is equivalent to risk management.

At some level, secure software is risk management. As you secure software, you frequently make the software harder to use or less functional. Sometimes, you can get more security without sacrificing ease of use or functionality; but usually it's a balance that the authors of the code get to pick.

Howard:

Don't add any ridiculous code to your application that gives a list of all the people who contributed to the application. If you don't have time to meet your schedule, how can you meet the schedule when you spend many hours working on an Easter egg? I have to admit that I wrote an Easter Egg in a former life, but it was not in the core product. It was in a sample application. I would not write an Easter Egg now, however, because I know that users don't need them and, frankly I don't have the time to write one!

Cohen:

They tell us that no more Trojan Horses will be allowed in Microsoft software. It took them long enough, they used to call them "Easter Eggs", a public relation stunt to make it seem palatable, and one that worked in the large for many years. But this is a good thing and I am glad they finally decided to do this.

In computer lore, words have very specific meaning. The Jargon File is a definitive lexicon for nerd speak.

trojan horse : a malicious security-breaking program that is disguised as something benign
easter egg: a message, graphic, or sound effect emitted by a program in response to some undocumented set of commands or keystrokes

Cohen's use of the very negative phrase "Trojan horse" almost suggests that his review is a troll (conveniently defined on the page after "Trojan horse" in the Jargon File).