To view older blog posts, please visit the archives section.

Software development risks are tricky to manage

Over the last couple of months, I’ve been thinking a lot about risk management in general. Being a software geek, I obviously tend to bring everything back to application security (AppSec). For whatever reason, unless you’re in a large organisation, it feels like AppSec tends to fly under the radar. There are not that many AppSec specialists out there. Simply said: most InfoSec people tend to come from a network or sysadmin background. Not a development background. Therefore, AppSec is sometimes forgotten… After all, it’s those pesky developers' job to make their code safe isn't it?

Are you sure about that?

What if I told you that, when it comes to software development, the choices and orientations made by your business have a gigantic impact on how much you will have to spend to keep it safe? Probably more than you think… Now you’re curious ain’t you?

Story time with a nerd

Evidently, not all technology is built and managed with the same care and attention level for security. If you were alive back then, I am pretty sure you remember the days of Microsoft Windows 95 and 98. Yes, dark days indeed. Then, in the 2000s Microsoft spent a lot of time and resources improving the security of their flagship product. After a while, they did turn the boat around. Microsoft Windows is now considered a very safe operating system. A long way from what it was 25 years ago. What did they do? They implemented secure development practices and actively sought every improvement possible.

How about your development process?

If your business produces any form of code, chances are that some of it has some vulnerabilities. Actually, it’s pretty much guaranteed. The technological choices made by your senior developers and engineers are generally based around their habits and what the business historically used, not on security related characteristics (for business related code).

This might be running your operational expenditure (opex) into the ground.

Let’s look at numbers

Your business applications make use of software libraries and frameworks. These are published and maintained by a community outside of your organization. Your business applications are also written using programming languages. Various languages have different idiomatic realities and general characteristics. 

How amazing! It could be argued that Java is a lot more popular than GoLang which results in higher numbers. It would be a fair assumption. The TIOBE index numbers for the usage of programming languages currently gives Java a 10.66% market share versus 2.26% for GoLang and a not so surprising 1.14% for PHP. As seen in some of my blog posts about CVEs statistics, we know that wordpress accounts for a disproportionate number of published CVEs. In fact, just cross site scripting related vulnerabilities for wordpress account for 6% of the total of CVEs published in January 2025. Wordpress is written in PHP. I’m not suggesting any conclusion based on this. PHP was once a very popular language. But I am submitting to you that we need to be careful when rationalising these numbers.

We only looked into popular frameworks and two different languages so far. This being said, most of the software built by your dev teams will also rely on other libraries (dependencies). Various studies have shown that, based on the language used, the number of average dependencies per application does vary. Sadly, I was not able to find numbers for GoLang but here is a table showing the average number of dependencies based on some of the popular languages:

The shocking thing: every single one of these dependencies increases your chances of needing to patch a piece of code because a vulnerability was found in one of these dependencies.

That’s a pretty bleak picture…

But what can we do to improve the situation?

Well, that is an interesting question. Programming languages evolve over time. Trends are set and then vanish. Great innovations appear setting a new trend but then someone somewhere improves on it. This is true for EVERY language and EVERY framework out there. What used to be great back then might be killing your business right now. Back in the days, Java was revolutionary. It solved many issues and was not directly susceptible to an entire class of memory based security problems. But, it was also built at a time where languages were still just “languages”. What I mean here is that Java had a very basic standard library that was appropriate for its time. But Java lacks “native” (used very liberally here) support for many of the modern day idioms resulting in it requiring a high number of dependencies for any serious development. Of course there exist projects like Jakarta EE which partially solve the issue. But then you would still be left with resource consumption issues in a cloud environment. In opposition, modern languages, like GoLang, tend to rely less on third-party libraries thanks to an extensive standard library. If you’re able to eliminate third-party dependencies, GoLang applications are incredibly simple to manage and update: upgrade GoLang and rebuild your application.

The technologies used in your software development processes directly affect your security and opex budget. Programmers' time is expensive and great programmers are not that frequent. Their time is even more valuable and those great programmers are the one on the frontline when it really matters, like when you have to patch a piece of software in an emergency.

Where does this lead us?

Don’t get me wrong, I love old programming languages just like anyone else. I'm die hard for the C programming language which is also infamous for even more security issues than Java over the years.

Personal preferences aside, hanging on to technologies and languages that were designed for another time period is pretty similar to bringing a black powder gun on a modern day battlefield. Yes, it can get the job done. But you’re in for a whole lot of pain. Expensive pain.

When development teams are not provided with appropriate support they simply cannot be blamed for the state of the opex budget. If you’re serious about security and operational efficiency, reconsidering your tech stack as a whole—especially when there are major shifts in the tech landscape—might be the best investment you can make. Everything evolves. So does the state of software development.

Sources:

https://www.microsoft.com/en-us/securityengineering/sdl/about

https://asankhaya.github.io/pdf/Out-of-Sight-Out-of-Mind.pdf

https://openssf.org/blog/2023/08/18/the-rising-threat-of-software-supply-chain-attacks-managing-dependencies-of-open-source-projects/

https://www.paolomainardi.com/posts/point-of-no-return-on-managing-software-dependencies/

https://www.tiobe.com/tiobe-index/

https://www.vulnarium.com/2025-02-01-cve-monthly-january