Software vulnerabilities originating from design decisions are hard to find early and time consuming to fix later. We investigated whether the problematic design decisions themselves might be relatively easier to find, based on the concept of “technical debt,” i.e., design or implementation constructs that are expedient in the short term but make future changes and fixes more costly. If so, can knowing which components contain technical debt help developers identify and manage certain classes of vulnerabilities? This paper provides our approach for using knowledge of technical debt to identify software vulnerabilities that are difficult to find using only static analysis of the code. We present initial findings from a study of the Chromium open source project that motivates the need to examine a combination of evidence: quantitative static analysis of anomalies in code, qualitative classification of design consequences in issue trackers, and software development indicators in the commit history.