First, the cost factor:
There are plenty of studies comparing costs of defect fixing in different development lifecycles. Graff and van Wyk estimates, for instance, estimates in their book Secure Coding: Principles & Practices that fixing a defect when an application is in production is 60 times more expensive as it would have been in the design phase:
There are other studies on this that calculate this costs lower (e.g. Gartner) or even higher (e.g. IBM). The reason for this is most likely that these costs highly depend upon what projects and organization one look at.
However, the qualitative conclusion is always the same: It is much cheaper to solve a defect as early in the development lifecycle as possible. This means, of course, to fix or prevent defects best in a conceptual phase. This is in fact possible for a large number of vulnerabilities. Gary McGraw et al. estimates in his fantastic book Software Security Engineering that as many as 60% of all defects are already visible witihin the design phase.
Second, the archived level of security:
With this first conclusions comes another: Since fixing a defect is so expensive when you do this late in the development lifecycle, in practice, people tend to fix only the most critical vulnerabilities. Less critical defects, that reduces do not pose an immediate threat but reduces the level of robustness of an application, are often not fixed after the implementation phase is finished.
In addition, likewise to a house with strong security requirements, applications can't be build with a high level of security, when they are not mend to be. Or as Roger Thornton, founder of Fortify, put it: "You cannot secure something that was not built to be secure".
No comments:
Post a Comment