Software Engineering & Security
Developers' Security Notes Could Fill Gaps in Automated Code Analysis Tools
Research shows that informal security-related comments buried in code—known as self-admitted technical debt—catch vulnerabilities that mainstream static analysis tools miss.
Security teams typically rely on automated code scanning to spot vulnerabilities before software goes live. But a new research study suggests these tools are leaving important clues on the table: the informal security warnings developers write directly into their code comments.
The Limits of Automated Security Scanning#
Static analysis tools (SATs) have become a backbone of modern security practice. They examine code without running it, offering an early warning system for potential weaknesses. Yet they come with a familiar problem: they flag many issues that aren't actually problems (false positives), and they struggle to catch certain categories of vulnerability entirely. This leaves development teams overwhelmed and potentially blind to real risks.
A Richer Source of Security Data#
Developers often document shortcuts and security compromises in their code—in comments, commit messages, or documentation—as what researchers call Self-Admitted Technical Debt (SATD). A team led by researchers studying this phenomenon wondered whether these informal notes contained security insights that automated tools couldn't provide.
They assembled a manually reviewed dataset of code comments flagged as security-related SATD, tested it against three commercial static analysis tools, and surveyed 72 practicing security professionals. The results were striking: while the tools detected roughly 84% of the security-related debt instances, they disagreed dramatically on what was wrong with the code. Only about 6% of the Common Weakness Enumeration (CWE) classifications—the standard taxonomy for software vulnerabilities—matched between what the tools identified and what the security-related comments described.
What Comments Reveal That Tools Miss#
The gap matters because the two sources often caught different kinds of security problems. Developer comments tended to capture subtle, context-dependent vulnerabilities that required understanding the broader flow of the application—weaknesses that depend on runtime behavior or the specific way code is being used. These dynamic issues are notoriously hard for static analysis to handle.
Security practitioners surveyed in the study emphasized that these informal notes helped them make sense of automated findings: they provided context for understanding the real impact of a flagged issue, its root cause, and what might fix it. Rather than being a distraction from tool output, the comments acted as a practical interpretive layer.

