One aspect of legacy code that is often forgotten is security. Discussions about legacy code usually center around things like maintainability, testability, cost of development and cost of running. Not so much about the security implications. Yet it is becoming an increasingly important issue that companies shouldn’t ignore.
If you’ve missed my article on what legacy code is, let me briefly repeat the four points I made. Legacy code is code:
- with little automated tests
- with automated tests of bad quality
- that uses older technology
- that is generally of bad quality making it hard for developers to change things without breaking anything
Let’s now go into more detail on why these characteristics can lead to security vulnerabilities.
Outdated Coding Practices
The first aspect of legacy code that has security implications is one that I didn’t touch on in my article on what legacy code is. At least not directly. But the two last points that I mentioned above, older technology and bad quality code, can be a cause and a symptom of outdated coding practices, respectively.
What are outdated coding practices exactly? Well, software development has best practices, just like any field of expertise. And they also evolve, like in other industries. For example, the automobile industry doesn’t manufacture cars like they did 20 or 30 years ago. That would be madness.
Due to the nature of software development, this evolution might even be faster. I don’t develop software like I did 3 to 5 years ago. Many principles stay the same, but some change. Specific patterns we used are no longer considered OK today.
Sometimes these older techniques lead to bad quality code, making it harder to write automated tests or add new features. But in other cases, they present real security risks.
For example, there is a technique that is called SQL injection. This technique allows hackers to see and manipulate the data in underlying SQL databases. And it is easily prevented by writing code in the correct way. In 2017, it was still the number 1 vulnerability on the internet.
Outdated Frameworks
Some frameworks we use to write applications are developed by privately held companies. Microsoft’s .NET and Joyent’s NodeJS come to mind. Other frameworks are the result of a collaborating open-source community. In each case, the teams behind them will usually push out updates regularly.
This means they will also have some way of supporting older versions of their frameworks, i.e. releasing bugfixes and security fixes. But at a certain point in time, this ceases to be worth their time and effort. That’s the point where they stop supporting the version of the framework. Usually, they’ll have communicated this well in advance.
But what happens if your application is still running on a version that is no longer supported? Are you sure security vulnerabilities will be fixed by the organization behind the framework? Or will hackers be able to exploit these issues, often with disastrous consequences for your company?
Outdated Libraries
Let’s say your developers are keeping up with the times, writing both quality code and using the newest version of the framework. There’s one other way hackers can get into your code: open source libraries.
Software development has become quite complex. There’s many moving parts. Luckily, there is a vibrant community of open source libraries. These are reusable pieces of code that teams can use so that they don’t have to solve problems that someone else has solved before. This allows your team to focus on the business problem at hand. Things like database access, logging or calling other web services. But even smaller utilities like parsing pieces of text or mathematical calculations.
These libraries will also depend on other libraries, creating a “dependency tree.” Most teams I’ve encountered don’t have a good image of what libraries they’re depending on. And how could they? We could be talking about hundreds of libraries in one application. This isn’t the problem.
The problem arises when one of these libraries has a security issue. You can have firewalls and other traditional network protection mechanisms all you want. If your software development team uses a bad library, they’ve just pulled in a security vulnerability through the back door.
Combine this with the fact that it takes hackers on average 3 days to exploit a vulnerability, and it’s clear you need a way of getting insights into the libraries you’re using.
You don’t want to spend time and money doing this by hand. Luckily, there are tools to do this automatically. Both free and paying, so let me know if you’re interested in such tools, I’ll help you choose.
What Should You Do Now?
Start by realizing that legacy code can present a security risk. If your application is running along fine without intervention, and isn’t exposed to the outside world (i.e. the internet), then you could just let it run without touching it. But in many other cases, you might want to invest a minimum of effort in keeping things up to date. Some of this can be automated, like automatic scanning of the underlying frameworks and libraries. But some of it will require a bit of work, like updating the frameworks and libraries, and changing pieces of code to be more secure.
Just keep in mind that the potential consequences of having a security breach are much higher than what it will cost you to let someone analyze your application and make some changes.