Technical debt as an indicator of software security risk: a machine learning approach for software development enterprises

Abstract

Vulnerability prediction facilitates the development of secure software, as it enables the identification and mitigation of security risks early enough in the software development lifecycle. Although several factors have been studied for their ability to indicate software security risk, very limited attention has been given to technical debt (TD), despite its potential relevance to software security. To this end, in the present study, we investigate the ability of common TD indicators to indicate security risks in software products, both at project-level and at class-level of granularity. Our findings suggest that TD indicators may potentially act as security indicators as well.

A Clustering Approach Towards Cross-Project Technical Debt Forecasting

“…The main goal of the SDK4ED project is to minimize cost, development time, and complexity of lowenergy software development processes, by providing a set of innovative solutions (i.e., toolboxes) integrated into the form of an easy-to-use platform for automatic optimization and trade-off calculation among important design-time and run-time software quality attributes. More specifically, the outcome of the project so far showcases numerous research and technical achievements with respect to the optimization of the targeted quality attributes, namely Maintainability [3,5,16,37,50], Dependability [32,33,[51][52][53][54], Energy Consumption [23,24,42,67], as well as Quality Forecasting [60,61,63] and Decision Support [47,[55][56][57] throughout the overall software development cycle. The SDK4ED TD Forecasting tool, integrated into the TD Management (TDM) framework, aims to provide predictive forecasts regarding the evolution of the TD quality attribute.…”

Investigating the Interaction between Energy Consumption, Quality of Service, Reliability, Security, and Maintainability of Computer Systems and Networks

“…1) to compute these impacts and provide useful recommendations. Throughout the SDK4ED project, several empirical studies have been conducted for reaching conclusions with respect to potential trade-offs among the three quality attributes of choice [22,[30][31][32]34]. Based on the identified trade-offs, a multi-criteria decision-making (MCDM) model that leverages concepts from fuzzy logic has been developed [38], providing information about the impacts of the suggested refactorings.…”

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

“…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].…”

“…Another characteristic of security debt is that traditional technical debt can be the source of security debt, e.g., suboptimal internal quality in a security critical software component [8]. Under this hypothesis, the correlation between technical debt indicators and software vulnerabilities can identify security debt [1], [3].…”

“…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.…”