Detecting Software Vulnerabilities with Technical Debt


This is a great post from the Software Engineering Institute on early software defect detections with technical debt. Schwartz, the author of the post, starts of by outlining the struggle that software engineers face balancing what is quick and desirable in the short term against the complexity and high costs that a short term approach will have in the future of the software the build. This sort of tradeoff, between short term rewards and long term maintainability, is what often leads to technical debt.

Something that we often talk about on this blog, is that if you don't pay back technical debt in a timely manner it can have pretty negative consequences. It can lead to a higher likelihood of defects, unplanned work, and difficulty in implementing new features due to the nature of the code that technical debt resides in. However, the question that is explored in this blog post is whether technical debt also correlates to an increase in system vulnerabilities.

Schwartz goes forward trying to answer this question by outlining the research done between software vulnerabilities and technical debt.

Their approach involved:

  • Identifying Security Vulnerabilities
  • Identifying Technical Debt
  • Model a relationship between signs technical debt and how vulnerabilities were affected by these signs

One of the first findings from this post is that when developers discover security issues, they often speak in terms related to technical debt. Developers will discuss getting to the root cause or comprehending the underlying design an issue. They will also speak about those areas where changes take longer than usual to implement or where a problem is reoccurring - which leads to the ability to see how a certain area can need a bigger fixin the future.

The signs that demonstrate a presence of technical debt are the number and type of design flaws that exist within a system (traditional bugs, security bugs) as well as the number of lines of code that need to change in order to fix a bug. Ultimately, from the SEI's research, they discovered that the more types of design flaw that file is part of, the higher the likelihood that the file also has vulnerabilities.

The second finding made in this post is a correlation between software vulnerabilities and technical debt indicators. If we look at the previous finding we see that design flaws are often spoken about using concepts closely tied to technical debt (code that is slower to change and causes reoccurring difficulties) and that design flaws lead to a higher probability of software vulnerabilities. What we see is that files with vulnerabilities tend to have a high amount of code churn (the number of lines of code that need to be changed in order to fix a bug).

While the purpose of this post was to answer the question whether software components with technical debt more likely to be susceptible to vulnerabilities, the sample used to to research for this post was too small to come to a definite conclusion. But, while this post may not answer the question definitely, it is something to keep in mind when you deal with technical debt, and perhaps by combining the evidence found in this post and your own experience you can start to see whether there is another reason why you should be on the guard against technical debt.

To read the full post visit here.

Filed in: Technical Debt
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Load more reviews
Thank you for the review! Your review must be approved first
You've already submitted a review for this item

A safer approach to application modernization and re-factoring for cloud