Context: Security work in software development is generally underprioritized. Software developers are not aware of security engineering practices, or find them external to the software development process. To the management, security work presents itself in the form of reactive testing performed out of necessity, incurring only costs in terms of time and resources. The long-term benefits of the security work are more difficult to demonstrate and the security investment harder to justify.

Objectives: The concept of technical debt is widely used, but its benefits for software security improvement and security risk management have not been fully realized. To make the direct and indirect benefits of security work in software development more visible and therefore more justifiable, the security risk in software is expressed in the terms of technical debt. Correspondingly, the security engineering techniques are utilized to recognize a technical debt containing a security risk: security debt.

Method: The concept of managing security risk as technical debt in software development is constructed. It is then analysed using an evaluation framework drawn from literature.

Result: Four central types of technical debt are considered for sources of security debt: requirements, architecture, code, and testing. Each type of security technical debt is analyzed from the aspect of three activities: identification, measurability and management, and repayment. The technical and organizational effects of applying this concept are examined. The evaluation framework increases the ability to identify technical debt through security practices, and to effectively mitigate security risk using technical debt management practices and tools. The framework deals with security issues in software architecture, code, and testing (ACT-S).

Conclusion: Security engineering techniques provide an effective method to recognize internal quality issues in software requirements, architecture, coding, and testing. When expressed as technical debt, the management of security risk and addressing the underlying quality issues can gain increased visibility and can be more communicated between developers, security experts, and the management