Design flaws account for 50% of security problems. You can’t find design defects by staring at code—a higher-level understanding is required. That’s why architectural risk analysis plays an essential role in any solid software security program. Find out more about architectural risk analysis in this sample chapter. Also, Matthew Heusser and Sean McMillan are convinced that it takes smart people to develop good software that makes money. Where do you find smart people? You don’t find them; you make them! Matt and Sean provide some fundamental rules for doing just that.
The Role of Architectural Risk Analysis in Software Security
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Developing of team generalists rather than a team of “specialists” seems to be in fashion in a lot of recent articles I read.
I like the idea myself, and believe it makes sense.
But how does it fit in with the management world’s ideals of outsourcing / offshoring to reduce costs?
The articles also encourage high levels of client involvement in the software development process.
Again, how does this fit in with the outsourcing / offshoring model?
The article quotes Fred P. Brooks several times. Then, it is probably a better idea to go read directly “The mythical man-month” by Brooks instead.
(not that the article is bad; it is quite good indeed but is nothing more than a collection of well-known facts)
The article talks about looking at all the different parts of the software. What parts would cause the most damage? Where are vulnerabilities most likely? That sort of deal. Sounds like a job for a cracker. At least a hacker. Are we at a point where we’re fighting fire with fire?