  Speeding up development may produce technical debt, i.e., not-quite-right
code for which the effort to make it right increases with time as a sort of
interest. Developers may be aware of the debt as they admit it in their code
comments. Literature reports that such a self-admitted technical debt survives
for a long time in a program, but it is not yet clear its impact on the quality
of the code in the long term. We argue that self-admitted technical debt
contains a number of different weaknesses that may affect the security of a
program. Therefore, the longer a debt is not paid back the higher is the risk
that the weaknesses can be exploited. To discuss our claim and rise the
developers' awareness of the vulnerability of the self-admitted technical debt
that is not paid back, we explore the self-admitted technical debt in the
Chromium C-code to detect any known weaknesses. In this preliminary study, we
first mine the Common Weakness Enumeration repository to define heuristics for
the automatic detection and fix of weak code. Then, we parse the C-code to find
self-admitted technical debt and the code block it refers to. Finally, we use
the heuristics to find weak code snippets associated to self-admitted technical
debt and recommend their potential mitigation to developers. Such knowledge can
be used to prioritize self-admitted technical debt for repair. A prototype has
been developed and applied to the Chromium code. Initial findings report that
55\% of self-admitted technical debt code contains weak code of 14 different
types.
