A 7,500+ word eBooklet looking at the concepts of security debt and software security austerity.
The concept of technical debt is not a new one. Technical debt has historically referred to the trade-off between getting a solution or system to market versus a perfectively designed and a bug free product. In the process of trading perfection for an economically viable development model the software incurs a degree of debt.
The debt analogy is starting to be applied to systems and software security. Recx have previously discussed some of the trade-offs made with regard to software security and time-to-market in our article entitled: Breaking the Inevitable Niche/Vertical Technology Security Vulnerability Lifecycle.
It is important to recognise that a Secure Development Life Cycle (SDLC) does not stop the presence or accumulation of security debt. A maturing SDLC allows an organisation to identify weaknesses and thus convert a larger volume of previously unknown debt to known security debt. The security debt once known, then needs robust processes to both service and repay it over a period of time. Typically SDLCs only set the criteria for the issues that must be fixed over a certain impact level. As organisations get better and more efficient at identifying security issues they typically start to accrue a substantial number of lower rated issues in the process. While these issues may on their own have less of an impact, when several lower issues are combined they can be as impactful as higher rated issues. As a result, the accumulation of a large number of lower impact issues without any strategy on how to resolve them can be equally as risky to security.
In this white-paper, Recx first introduces the reader to the concept and risk of software security debt. A review is then performed of the types and sources of debt before discussing how it can build up when using a risk assessment based approach to prioritisation. A number of debt management strategies are then presented along with associated events, such as servicing, repayment, overhang and expiry. Finally a number of conclusions are drawn around software security debt and why it needs to be considered as part of mature secure software development and risk management processes.
The concept of technical debt is not a new one. Technical debt has historically referred to the trade-off between getting a solution or system to market versus a perfectively designed and a bug free product. In the process of trading perfection for an economically viable development model the software incurs a degree of debt.
The debt analogy is starting to be applied to systems and software security. Recx have previously discussed some of the trade-offs made with regard to software security and time-to-market in our article entitled: Breaking the Inevitable Niche/Vertical Technology Security Vulnerability Lifecycle.
It is important to recognise that a Secure Development Life Cycle (SDLC) does not stop the presence or accumulation of security debt. A maturing SDLC allows an organisation to identify weaknesses and thus convert a larger volume of previously unknown debt to known security debt. The security debt once known, then needs robust processes to both service and repay it over a period of time. Typically SDLCs only set the criteria for the issues that must be fixed over a certain impact level. As organisations get better and more efficient at identifying security issues they typically start to accrue a substantial number of lower rated issues in the process. While these issues may on their own have less of an impact, when several lower issues are combined they can be as impactful as higher rated issues. As a result, the accumulation of a large number of lower impact issues without any strategy on how to resolve them can be equally as risky to security.
In this white-paper, Recx first introduces the reader to the concept and risk of software security debt. A review is then performed of the types and sources of debt before discussing how it can build up when using a risk assessment based approach to prioritisation. A number of debt management strategies are then presented along with associated events, such as servicing, repayment, overhang and expiry. Finally a number of conclusions are drawn around software security debt and why it needs to be considered as part of mature secure software development and risk management processes.
