Reading Between the Code Lines: On the Use of Self-Admitted Technical Debt for Security Analysis
Nicolás E. Díaz Ferreyra, Moritz Mock, Max Kretschmann, Barbara Russo, Mojtaba Shahin, Mansooreh Zahedi, Riccardo Scandariato
TL;DR
This study investigates how security-related Self-Admitted Technical Debt (SATD) complements static analysis tools (SATs) in security analysis. Through a dataset study of SATD-linked vulnerabilities in the MADE-WIC Big-Vul dataset and a survey of 72 security practitioners, the authors show that SATD captures dynamic, context-dependent weaknesses (e.g., race conditions, resource leaks) that SATs often miss, while SATs cover a distinct set of CWEs. The combined use of SATs and SSATD identifies 114 of 135 SSATD instances (spanning 24 CWEs), with 33 CWEs mapped from SSATD and 21 SSATD cases not detected by SATs, underscoring SSATD as a meaningful, practical complement for prioritization, interpretation, and remediation. Practitioners report that SSATD enhances understanding of CWE type, impact, affected components, and fixing strategies, suggesting targeted, lightweight integration of SSATD insights into SAT-driven workflows to mitigate SATs’ limitations.
Abstract
Static Analysis Tools (SATs) are central to security engineering activities, as they enable early identification of code weaknesses without requiring execution. However, their effectiveness is often limited by high false-positive rates and incomplete coverage of vulnerability classes. At the same time, developers frequently document security-related shortcuts and compromises as Self-Admitted Technical Debt (SATD) in software artifacts, such as code comments. While prior work has recognized SATD as a rich source of security information, it remains unclear whether -and in what ways- it is utilized during SAT-aided security analysis. OBJECTIVE: This work investigates the extent to which security-related SATD complements the output produced by SATs and helps bridge some of their well-known limitations. METHOD: We followed a mixed-methods approach consisting of (i) the analysis of a SATD-annotated vulnerability dataset using three state-of-the-art SATs and (ii) an online survey with 72 security practitioners. RESULTS: The combined use of all SATs flagged 114 of the 135 security-related SATD instances, spanning 24 distinct Common Weakness Enumeration (CWE) identifiers. A manual mapping of the SATD comments revealed 33 unique CWE types, 6 of which correspond to categories that SATs commonly overlook or struggle to detect (e.g., race conditions). Survey responses further suggest that developers frequently pair SAT outputs with SATD insights to better understand the impact and root causes of security weaknesses and to identify suitable fixes. IMPLICATIONS: Our findings show that such SATD-encoded information can be a meaningful complement to SAT-driven security analysis, while helping to overcome some of SATs' practical shortcomings.