Biblio

Context: The technical debt (TD) metaphor helps to conceptualize the pending issues and trade-offs made during software development. Knowing TD causes can support in defining preventive actions and having information about effects aids in the prioritization of TD payment. Goal: To investigate the impact of the experience level on how practitioners perceive the most likely causes that lead to TD and the effects of TD that have the highest impacts on software projects. Method: We approach this topic by surveying 227 practitioners. Results: While experienced software developers focus on human factors as TD causes and external quality attributes as TD effects, low experienced developers seem to concentrate on technical issues as causes and internal quality issues and increased project effort as effects. Missing any of these types of causes could lead a team to miss the identification of important TD, or miss opportunities to preempt TD. On the other hand, missing important effects could hamper effective planning or erode the effectiveness of decisions about prioritizing TD items. Conclusion: Having software development teams composed of practitioners with a homogeneous experience level can erode the team's ability to effectively manage TD.

Technical debt is an analogy introduced in 1992 by Cunningham to help explain how intentional decisions not to follow a gold standard or best practice in order to save time or effort during creation of software can later on lead to a product of lower quality in terms of product quality itself, reliability, maintainability or extensibility. Little work has been done so far that applies this analogy to cyber physical (production) systems (CP(P)S). Also there is only little work that uses this analogy for security related issues. This work aims to fill this gap: We want to find out which security related symptoms within the field of cyber physical production systems can be traced back to TD items during all phases, from requirements and design down to maintenance and operation. This work shall support experts from the field by being a first step in exploring the relationship between not following security best practices and concrete increase of costs due to TD as consequence.

The endeavor to achieving software security consists of a set of risk-based security engineering processes during software development. In iterative software development, the software design typically evolves as the project matures, and the technical environment may undergo considerable changes. This increases the work load of identifying, assessing and managing the security risk by each iteration, and after every change. Besides security risk, the changes also accumulate technical debt, an allegory for postponed or sub-optimally performed work. To manage the security risk in software development efficiently, and in terms and definitions familiar to software development organizations, the concept of technical debt is extended to contain security debt. To accommodate new technical debt with potential security implications, a security debt management approach is introduced. The selected approach is an extension to portfolio-based technical debt management framework. This includes identifying security risk in technical debt, and also provides means to expose debt by security engineering techniques that would otherwise remained hidden. The proposed approach includes risk-based extensions to prioritization mechanisms in existing technical debt management systems. Identification, management and repayment techniques are presented to identify, assess, and mitigate the security debt.

Context: Managing technical debt (TD) associated with external cybersecurity attacks on an organization can significantly improve decisions made when prioritizing which security weaknesses require attention. Whilst source code vulnerabilities can be found using static analysis techniques, malicious external attacks expose the vulnerabilities of a system at runtime and can sometimes remain hidden for long periods of time. By mapping malicious attack tactics to the consequences of weaknesses (i.e. exploitable source code vulnerabilities) we can begin to understand and prioritize the refactoring of the source code vulnerabilities that cause the greatest amount of technical debt on a system. Goal: To establish an approach that maps common external attack tactics to system weaknesses. The consequences of a weakness associated with a specific attack technique can then be used to determine the technical debt principal of said violation; which can be measured in terms of loss of business rather than source code maintenance. Method: We present a position study that uses Jaccard similarity scoring to examine how 11 malicious attack tactics can relate to Common Weakness Enumerations (CWEs). Results: We conduct a study to simulate attacks, and generate dependency graphs between external attacks and the technical consequences associated with CWEs. Conclusion: The mapping of cyber security attacks to weaknesses allows operational staff (SecDevOps) to focus on deploying appropriate countermeasures and allows developers to focus on refactoring the vulnerabilities with the greatest potential for technical debt.

Context: Managing technical debt (TD) associated with potential security breaches found during design can lead to catching vulnerabilities (i.e., exploitable weaknesses) earlier in the software lifecycle; thus, anticipating TD principal and interest that can have decidedly negative impacts on businesses. Goal: To establish an approach to help assess TD associated with security weaknesses by leveraging the Common Weakness Enumeration (CWE) and its scoring mechanism, the Common Weakness Scoring System (CWSS). Method: We present a position study with a five-step approach employing the Quamoco quality model to operationalize the scoring of architectural CWEs. Results: We use static analysis to detect design level CWEs, calculate their CWSS scores, and provide a relative ranking of weaknesses that help practitioners identify the highest risks in an organization with a potential to impact TD. Conclusion: CWSS is a community agreed upon method that should be leveraged to help inform the ranking of security related TD items.

This paper identifies a small, essential set of static software code metrics linked to the software product quality characteristics of reliability and maintainability and to the most commonly identified sources of technical debt. An open-source plug-in is created for the Understand code analysis tool that calculates and visualizes these metrics. The plug-in was developed as a first step in an ongoing project aimed at applying case-based reasoning to the issue of software product quality.1