Looking back to the end of last year, a lot was made of the security community being caught off-guard by the Log4J vulnerability.
But should an attack like this have come as such a surprise?
For a while now the fast-paced nature of software and app development has meant that using existing libraries and frameworks is a must.
The big question, though, is whether they can all be trusted.
Clearly the answer right now is no - Log4J has proved as much. And in an age where your mobile app might be your most valuable asset, there’s no denying that this is a concern.
In this article we’ll take a look at how we got to the current status quo. And we’ll explore two key ways of stopping software supply chain attacks in the future.
How a developer builds a house
Imagine you were working with an architect to design and build a house from scratch.
It’s unlikely that you’d make all the materials yourself. Instead, you’d source them from independent suppliers. One for the doors, one for the windows, and another for the floors.
It’s a similar situation in software and app development. Why reinvent the wheel when there’s already a perfectly good library or framework you can use? Someone else has done the hard work so you don’t have to.
This is how a lot of development works. Much of the code that makes up our everyday digital interactions comes from existing libraries. Software and app development is often a high-pressured environment - there’s a demand for products to launch quickly to maintain competitive advantage.
And often this approach of taking ready-made building blocks works just fine. It speeds up the development process and results in a successful application.
Sometimes, though, things can go wrong. After all, the libraries themselves often contain dependencies. So, while you might think that you’re using 10 libraries to build your application, you could actually end up with around 150 dependencies.
It’s one thing to know and trust the publishers of the libraries. But what about the publishers of the dependencies within those libraries? Do you know them? Can you trust them?
A seemingly innocuous line of code in just one of those dependencies could offer bad actors a route into your application.
If we go back to the house analogy, it’s a little bit like buying a door from a supplier you trust, only to realize later that they don’t actually manufacture the locks themselves. And the metal used in those locks corrodes and weakens easily.
It’s the “one-to-many” concept that makes software supply chain vulnerabilities like Log4J so attractive to attackers. Imagine you created a vulnerability in a dependency that sits within a popular library. That library could end up being used in some of the biggest applications in the world. The attack surface grows without having to repeat the initial effort.
That was the major worry around Log4J.
Is a reliance on open-source software sustainable?
In essence, the approach above mirrors supply chain attacks in other industries. Find your way into a large company by hacking a smaller one (which has a fraction of the security budget) higher up the supply chain.
In the tech world, the equivalent goes something like this:
It’s extremely difficult to hack tech giants like Google and Facebook directly. It’s much easier to hack a line of code within a dependency of a library that they rely on.
Log4J isn’t the only recent example of such an attack, either. There have been plenty that use typosquatting - an attack that leverages misspelled versions of popular package names to gain access to systems.
Studies have shown that this technique is a great way of getting into the networks of some of the world’s biggest tech companies. Once inside, attackers can gain remote code execution or potentially add a backdoor during the build.
Earlier last year, before Log4J, we read about the Codecov attack. A bad actor was able to gain access to Codecov’s Bash Uploader script and modify it. This was possible because of an error in Codecov’s Docker image creation process.
A lot of software supply chain attacks target free, open-source libraries. Log4J is a perfect example of this. In the immediate aftermath of the attack, there were obvious recriminations - chief among them being “how could they have allowed such a vulnerability in their code?”
But who are “they”, exactly?
Scratch beneath the surface, as Patrick Howell O’Neill did in his brilliant MIT Tech Review piece, and a shocking story emerges.
Log4J had become a vital piece of internet infrastructure, relied on by million and billion dollar companies. But it was maintained by a tiny team of unpaid volunteers who were then expected to work 22-hour days to fix the vulnerability.
The underfunding of open-source software seems unsustainable. Particularly at a time when all the trends point toward more attacks of this nature. Indeed, if hackers know that the library or framework they’re targeting is poorly funded or supported, they also know that they’ll have more time to profit from an attack.
What can we do to stop software supply chain attacks?
It stands to reason, then, that the first way to counter this growing threat is to collectively show our appreciation for the frameworks we depend on.
We’ve released some open-source software ourselves. And as a result we’ve always felt a close connection with the developer community. We feel immense satisfaction and pride whenever we read about the different ways JCardSim is being used around the world.
But we’re also in the fortunate position of having other app protection products that we do charge for. Some developers of open-source software can’t say the same.
If you’re in a position to support open-source projects - be it financially or by sharing tools you’ve created that can help to secure them - that’s a great start.
Because protecting libraries is going to be increasingly important in the next few years as the process of mobile app development changes.
We’re seeing big growth in the popularity of no-code applications already and we expect that trend to continue. That means that the use of a variety of building block frameworks will become completely normalized. But it also means that developers might lose any kind of control that they once had over libraries and dependencies.
And this leads us to our second tip for stopping software supply chain attacks - shifting how we think about security in general.
We mentioned at the outset of this article that the use of existing libraries and frameworks is pretty much essential in the fast-paced world of app development. But in a future where developers potentially have less control over their dependencies and the apps they’re developing are more vital than ever to a business’ success, is there an argument for slowing down?
After all, when you read about the use of software dependencies, one word jumps off the page more than any other: convenience.
In a way it’s reminiscent of the height of consumerism when people didn’t care so much where their food came from and the impact on the planet so long as they could get it easily.
The slow food movement used to be a niche one. But these days there are lots of people who would at least claim to care about the sustainability of the food on their table.
Nicolas Fränkel recently wrote a blog in response to Log4J. In it, he noted that users of third-party code should carefully audit it for bugs and vulnerabilities. But he also said that in 20 years in the industry he was yet to see such an audit take place.
This reality probably speaks to the time pressure developers and product owners find themselves under. The balance naturally tends to swing towards speed rather than security. But this imbalance would right itself pretty quickly once companies suffered the trust and reputational fallout of a damaging attack.
Later in Fränkel’s article he suggests that we should handle security through the lenses of risk assessment. But, he said, to do so requires you to first list all of the possible risks.
Fortunately, we can help with that. You can find out how below.
