Sometimes it is very hard for customers to understand the hidden costs involved when you build custom software. By a hidden cost, I mean a phenomenon that apparently is back in our industry called BitRot.
What is BitRot?
Back in the day, BitRot was caused by the fact that the magnetic media we used to store our computer programs sometimes lost their magnetic information, causing problems reading the data back. With the industry moving to new ways to store data, like solid-state drives, the problem is still there but not predominant visible anymore. We have algorithms stat store our data in such a way the lost data can be recovered, and from an end-user perspective, it seems to have vanished completely.
Bitrot redefined
So although the original problem has gone more or less away, we are now confronted with a completely new way that bitrot is coming back in our industry. You might disagree with me about reusing the name BitRot for something different, but in essence, the problem we face manifests itself in the exact same way. If we don’t touch the software, we write for even a few weeks, the software deteriorates!
Let me explain what is going on here.
BitRot today is the issue when we don’t touch our software for a few days or weeks, and the software deteriorates caused by a number of sources. Let me share a few of the issues you will face when building software today
New known vulnerabilities
A known vulnerability is some weakness found in the software you wrote or in any software you used to build your application or website that can be exploited by someone. You might think, why would my software all of a sudden become exploitable while I haven’t touched it? This is caused by the fact that attackers become smarter each day. they find new innovative ways to exploit software and since the software that is written often contains tons of code not only written by your own company but also open source components, the chance of your software becoming vulnerable itself is a significant risk. This does not immediately mean your software will be exploited as well, but the likelihood your software becomes exploitable will increase almost every day. This is something that you need to keep track of and you need to make updates or changes to your software to keep up with the current state of the industry. The number of vulnerabilities found is also increasing all the time. You can see how fast this is picking up in the following graph that is published NVD – CVSS Severity Distribution Over Time (nist.gov). I added a capture of the graph you can find there, that shows how many known vulnerabilities are found and that the rate of finding them is constantly increasing.
Updates of used frameworks or packages
Your software is rarely built from scratch. To build software, you will use other software components all the time. Depending on the technology you use to write your programs, you use NuGet packages (.NET), Maven packages (Java), Node Packages (Node/Web Development), RubyGems (Ruby development), etc. These packages are built and maintained by others. and coming back to the previous topic, they also need to maintain their software to keep it free from known vulnerabilities. Also, they want to provide new capabilities and features constantly. This implies those packages will get new versions all the time, and keeping up with those more recent versions is not to take lightly.
Let’s assume you build a simple Hello World web application using .NET 6. and React to give a simple example. You can see the screenshot of what I did to create the application in Visual Studio 2022:
Then this will result in the astonishing set of 1,487 Dependencies from the NodeJS ecosystem and 15 more from the .NET ecosystem. Starting with a clean template (I updated everything before I created the application in visual studio), this already resulted in 23 Known Vulnerabilities of which 9 are at the level of High!
Updates on compilers and tooling
Then there are the dependencies on Visual Studio 2022, which has updates at least once every month. Then we took a dependency on the .NET framework that is updated at least 1x per year and every two years has a new stable release that is supported for a maximum of 3 years. And finally, we took a dependency on the NodeJS toolset, which is also updated multiple times a year. These tools also tend to make breaking changes. You need to constantly keep them up to date because they can also contain known vulnerabilities that might compromise your development environment!
Newer versions of the languages and frameworks
Finally, there are also dependencies on the languages we used. In this example, I used React which is Javascript/typescript based, and C#10 for the .NET codebase. C# updated on a yearly cycle, and if you look at the versions of Node, then you see you need to update this every six months:
Those language and framework updates can be significant if you look at the amount of work involved to actually use the new capabilities. Not using them still makes your codebase deteriorate from a maintainability perspective since the industry is moving on with new ways of utilizing the language and framework features. New team members on a project will have a hard time adapting old programming styles and inefficiencies if you only ensure it compiles.
Conclusion
The software you build is in a constant state of decay, and you need to allocate a significant portion of time to keep things evergreen and up to date. Waiting for your updates will cost you significantly more time than updating constantly. Also, here you see, the adage “if it hurts, do it more often” applies and makes the software delivery cadence more predictable and more secure. So make updating packages, frameworks, and languages part of the standard maintenance cycle!
The real challenge lies in making our customers aware of this problem and finding ways to make them aware they need to maintain software. You can not let software untouched for a few weeks since, in the meanwhile, the software becomes outdated and vulnerable. And last but not least it will become more complicated each day to make it up to date again.
