Software is like milk, it goes bad over time: A guide on building safe code

Many moons ago while I was working in the open source software security industry, I came across this statement:  “Software is like milk and not a fine wine. A fine wine matures with age, while software and milk go off over time”.

So, what is meant by that you may ask? Well, if we break software down into its raw component parts we are left with code that is bespoke and code that is ‘off the shelf’. A good example of ‘off the shelf’ code are open-source components, which are much like LEGO pieces if you will - with  each piece of Lego being uniquely numbered. Similar to LEGO, many open-source code components are like modular building blocks - they are small, reusable units of code serving specific functions or features. And, just like LEGO pieces can be combined to build intricate structures, open-source code components can be combined and connected to create more complex software.

The issue with open-source code components is that they are provided by many contributors and are therefore wide open to vulnerabilities if not regularly updated or, worse, abandoned. Fortunately there are some very well-kept repositories that have set the standard when it comes to artefact hygiene. The Maven project (JAVA) is an obvious one that springs to mind. Many other repositories, however, have little hygiene or controls in place to identify dates, owners, and versions of the code. This leaves developers working with the code at a loss as to what is the latest to use.

Another issue with software is that as developers naturally work at speed to get projects built on time, security is often a secondary thought and can be seen to slow down their work. With this being the case, some have the tendency to use artefacts they have used in the past, thereby creating their own ‘golden repository’. This is ok as long as the repository is regularly monitored and cross referenced for age, updates, and Common Vulnerabilities and Exposures (CVE). But alas, often this is not the case leading to the unwitting creation of potential ‘back-doors’ in the software build.

Vulnerabilities like these are something the security industry is getting acutely aware of. Fortunately there are companies now addressing these issues by providing health checks and bills of materials that identify components in the build - through cross reference of repositories and CVE databases - that may be vulnerable or have, in effect, ‘gone off’ - hence the ‘like milk’ analogy.

It may sound obvious that writing good software is important. But, as said before, it is all too often sacrificed for speed. To say Hackers are lazy is a bit unfair, but by building software with potential vulnerabilities we are leaving easy opportunities for them to exploit. Vulnerability hacking isn’t isolated to small organisations. Companies like Microsoft, Adobe, AMD, Disney, and Lenovo (just to name a few) have been affected from open-source vulnerabilities.

In fact, according to a report from Synopsys and The Consortium for Information and Software Quality, poor software quality may have cost $2.41 trillion in 2022 in the US alone and related cyber crime cost the world approximately $7 trillion. The report also found that the cost of accumulated technical debt in the US caused by cutting corners to expedite feature or software release delivery with a ‘build now fix later’ mentality had risen to $1.52 trillion.

It’s really important when building or h that care is taken in ensuring you or your selected partner are using clean code. At Vodworks, our focus on ensuring security is paramount throughout the SDLC (Software Development Lifecycle), all the way from how we build and maintain code to ensuring sensitive information is never leaked and our clients are constantly informed on areas we see need addressing.