What Can Self-Admitted Technical Debt Tell Us About Security? A Mixed-Methods Study

TL;DR

This study explores how Self-Admitted Technical Debt (SATD) can reveal security vulnerabilities in open-source software and examines developers' motivations and perceptions regarding disclosing security issues in SATD.

Contribution

It provides the first comprehensive analysis linking SATD to security vulnerabilities and offers insights into developer practices and concerns about security disclosures in SATD.

Findings

25 CWE types identified in SATD instances, including 8 in MITRE's Top-25

Developers use SATD to promote security awareness and identify flaky code

Practitioners see security pointers in SATD as both helpful and risky

Abstract

Self-Admitted Technical Debt (SATD) encompasses a wide array of sub-optimal design and implementation choices reported in software artefacts (e.g., code comments and commit messages) by developers themselves. Such reports have been central to the study of software maintenance and evolution over the last decades. However, they can also be deemed as dreadful sources of information on potentially exploitable vulnerabilities and security flaws. This work investigates the security implications of SATD from a technical and developer-centred perspective. On the one hand, it analyses whether security pointers disclosed inside SATD sources can be used to characterise vulnerabilities in Open-Source Software (OSS) projects and repositories. On the other hand, it delves into developers' perspectives regarding the motivations behind this practice, its prevalence, and its potential negative consequences. We followed a mixed-methods approach consisting of (i) the analysis of a preexisting dataset containing 8,812 SATD instances and (ii) an online survey with 222 OSS practitioners. We gathered 201 SATD instances through the dataset analysis and mapped them to different Common Weakness Enumeration (CWE) identifiers. Overall, 25 different types of CWEs were spotted across commit messages, pull requests, code comments, and issue sections, from which 8 appear among MITRE's Top-25 most dangerous ones. The survey shows that software practitioners often place security pointers across SATD artefacts to promote a security culture among their peers and help them spot flaky code sections, among other motives. However, they also consider such a practice risky as it may facilitate vulnerability exploits. Our findings suggest that preserving the contextual integrity of security pointers disseminated across SATD artefacts is critical to safeguard both commercial and OSS solutions against zero-day attacks.