Summary
Chris Wysopal likens application security debt to technical debt in a couple of recent blog posts. It turns out that the debt metaphor is particularly apt as, like financial debt, application security debt is susceptible to interest rate fluctuations.
The threat landscape changes in the application's life time. Unfortunately, security interest rates are much more likely to go up than down as new vulnerabilities are disclosed and the application gains mind share. The former makes it easier for attackers to compromise the application, the latter provides them with a greater incentive. An effect that Chris missed is the tendency for an application to increase its attack surface as it is extended with new functionality.
Leverage through financial debt can help a company grow and, similarly, so can technical debt. However, as interest rates become punitive, clearly the time to de-leverage has come. Chris presents a model to quantify the dollar cost of the debt, but, frankly, the calculations are tenuous, as he admits himself. I would feel happier with qualitative guidelines. What do you think the tell-tale signs are for the need to de-leverage?
This kind of pseudo BA or capitalist-realist reasoning is totally insane and it is a shame that it is produced by "software engineers".
Security needs certifications. Those won't guarantee that programs ( or hardware ) can't be cracked either but it ensures at least that they are not completely sub-par. Security certificates have to be renewed periodically. This way more recent attacks are already reflected in the certification process. Optimistically speaking standards/certifications can drive technological progress towards platforms/techniques/languages that reduce costs for gathering a certificate.
I am not sure whether you are agreeing with me that expressing security debt in dollar terms is over-ambitious or whether you think that even the very concept of technical debt is silly. Personally, I think that, as software engineers, it is important that we think about the business drivers of our work.
Previous Topic
