Managing Security in Software

Security Debt: Characteristics, Product Life-Cycle Integration and Items

“…Technological: It is acknowledged that different artefact types can be the source to incur technical debt [20], and security debt is not an exception [5]- [7], [12], [13]. Different categories can be found in the literature such as requirements [7], code [7], [12], [13], design and architecture [7], [12], [13], configuration [13], environment [12], hardware and physical parts [6], cloud computing infrastructure [13], knowledge distribution [12], documentation [12], [13], and testing [7], [12], [13]. Section V will later present concrete categories and examples of security debt items.…”

“…One characteristic that we can highlight from security debt is that it is highly related to security risks. Some authors refer security debt as technical debt containing a security risk [7] or potential security implications [8]. Security engineering techniques (e.g., risk analysis) are used to identify the security debt [6], [8] and security risk in software can be described [7], [11] Technical debt can be a source of security debt [1], [3], [8] Tradeoffs of security and other quality attributes (e.g., performance) might force to assume security debt [5], [14] Organizational Organization policies should prioritize security debt [12], [19] Security awareness and skills are needed to avoid security debt [8], [13] Security debt involves different stakeholders requiring discussions and decision making among them [5], [14] Consequences Business damage: High interest of the debt [8], [9], [12], [14], [16], [21] Interest will be paid mainly when someone exploit the vulnerability [8], [9], [16], [21] Paying the principal of the security debt might require to change processes [16], [19] in terms of technical debt [8], e.g., including the probability attribute to the security debt item to measure the chances that the security-related defect can be actually exploited [5].…”

“…Unintentional security debt should be identifiable thanks to security engineering through validation and verification (V&V) activities [8]. Also, this security engineering should be continuous [7], i.e., not a single-shot effort (e.g., thread modelling only at the beginning of the project) as this may create a quickly obsolete view on the security of the system [11] creating new security issues.…”

“…Thus, all engineering disciplines are subject to generate security debt starting in very early stages such as the concept and requirements phases [10]. The debt management process should then consider all those stages [7] and adjust the techniques aiming to reveal security debt items [8], [13], [14] (e.g., reviews of policies, design, code etc.). Also, ideally security debt cannot be incurred when secure-by-design best practices are followed across the product life-cycle [6].…”

“…Across the product life-cycle All the stages/disciplines are subject to generate security debt [6]- [8], [10], [13], [14] Identification of security debt is a continuous process [7], [11] Risk management Extending security risk management to manage security debt [7], [8], [11] Risk assessment can be used to quantify and prioritize the items [7]- [9], [12] Identification techniques Security V&V can help to identify security debt [8] Assurance can help to identify security debt [5], [7] Technical debt indicators can help to identify security debt [1], [3], [8] Instances SecDevOps [9] Cybersecurity framework extended with Security debt [5] As mentioned in Section III-B, the identification of security debt should be a continuous process across the product lifecycle [7]. It is not appropriate to think of security as a component that can be added after the product is built, or that it is a quality attribute that can be checked just once.…”