Detecting Software Vulnerabilities with Technical Debt

by

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
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
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
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|