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.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.