moving forward: the knowns and unknowns

Jeremiah addresses many of the questions that we have to deal with on every single analysis. What is sad though, is that in many places, it's hard to find an alliance between the security practitioners and the software engineers such that the engineers are motivated by security - meaning, we may not even get to ask the most basic of these questions.

I'd add another question to the list:

"Once flaws have been identified, what is my motivation to fix them? If you can't give me the likelihood of attack, and what I stand to lose by it being exploited, how many dollars should I invest to repairing it?"

As security practitioners, we continue to say how much the development environments need to learn to make secure software. I'd say there's another side to that coin - security practitioners need to be able to measure the impact of particular threats in terms of dollars so that we don't just reveal vulnerabilities and the threats that might exploit them, but what the business stands to lose of the vulnerability isn't fixed. The business can measure with a good deal of probability how much they stand to gain if they implement a new feature. When you place those measured dollars on a balance with a document that just says "you've got problems", the pan with the money wins.