Discover the two simple steps you can take to secure your open source dependency chain.
Josep Prat
|RSS FeedSenior Engineering Director, Streaming Services
Subscribe for the latest news and insights on open source, Aiven offerings, and more.
Open-source software (OSS) has become the backbone of modern software development, empowering developers with a vast ecosystem of freely available libraries, frameworks and tools. However, as the old saying goes, ‘there's no such thing as a free lunch’, and the over reliance on OS components introduces significant security risks that can compromise the entire software supply chain.
Let’s talk about what’s referred to in the OSS community as the dependency chain. This is the interconnected network of software on which applications rely on to function. In modern development where engineers routinely accelerate the build by reusing existing code, it’s common for projects to depend on third-party libraries, open source or not, and custom internal packages with each addition lengthening the chain. And of course, a dependency can also have dependencies of its own.
Little wonder, then, that keeping track of one’s dependency chain can be complicated and therefore not something many businesses prioritize. Understanding the detail behind them is not mission-critical to enterprises laser-focussed on revenue or growth while, at the other end of the spectrum, start-ups and early-stage companies are interested in speed to market — often taking out technical debt in order to get there. For many in between, it’s simply a can that can be kicked down the road.
That is, until it becomes an issue, which it undoubtedly will because every link in the chain represents a potential threat window. The longer and more complicated the chain, the greater the risk of vulnerabilities or weaknesses that attackers can exploit.
The fact is that many companies do not know what they’re running in production. This needs to change because, until it does, businesses are not only exposed from a security point of view, but they have no idea where or how great the potential impact.As example of the possible pitfalls, the UK Home Office recently published guidance on how to manage software dependencies while the risk of poorly managed software dependencies is regularly included in the Open Worldwide Application Security Project’s (OWASP) ‘top 10 security applications risks’.
We don’t need to look back far for evidence of the damage a compromised dependency chain can do. Earlier this year, a lone Microsoft developer rocked the world when he revealed a backdoor had been intentionally planted in XZ Utils, an OSS data compression utility available on almost all installations of Linux. The malicious code was injecting itself during the build process hidden way below the surface of what businesses are traditionally concerned with and granted unauthorized access to execute commands on affected machines.
The more essential the tool that can be hijacked, the higher the chance it has to reach production environments. This is why businesses must adopt a best-practice approach to improving security, which can be done in two, simple steps.
1). Know your dependency chain - businesses have to know what they are dealing with and this means keeping a software bill of materials (SBOM)
2). Check it is up to date - Once they have it, businesses must check if the libraries they are using are the right and up-to-date versions. This sounds complicated and tedious given the nuanced and often minor amends that are made to software programmes but there are tools on the market that can do this quickly and easily. The OSS review toolkit analyzes a business SBOM and highlights vulnerabilities or changes automatically.
Beyond this, OSS projects already use many strategies to safeguard security. These include validation — where developers use the community to check for vulnerabilities or deficiencies in software before it’s released to the general public. Bounty programs are also one of the most effective ways to keep open source projects secure. This is where researchers are offered a financial incentive for finding issues and ways to exploit them, fixing software bugs or implementing minor features. It’s a program Aiven uses to find vulnerabilities in our own software as well as in the upstream libraries we use.
In parallel with these strategies, we’re also seeing new regulation that will support improvements to securing dependency chains. The Cyber Resilience Act (CRA) in the EU is a good starting point. However, each member state needs to now create a bill that is compliant with the framework that has been set and it needs due diligence on the OS community within each country covering areas like; ownership, liability and documentation. It cannot — must not — be created by politicians and businesses several steps removed from the reality of on-the-ground activity. The US is also working on similar regulations.
At an individual-level, companies within OSS work incredibly hard on securing their dependency chain, RedHat being a good example. It has people working full time working at upstream projects like the Linux kernel, to improve it and at the same time check for security vulnerabilities. At the other end of the spectrum, hyperscalers are investing heavily in OSS projects and, in doing so, imbuing stringent security measures in production. Beyond this, there are also the companies in the security space providing, sometimes paid, sometimes open source tools, on scanning, vulnerability reporting and threat detection — all of which is relieving the burden of manual work at a developer-level.
Despite all this, more needs to be done in order to ensure dependency chains are secured from the first level dependencies, to the ones buried several levels deep down. The consequences of not doing so are well documented — everything from loss of customer data and fines to the erosion of trust for both the business and compromised link in the chain.
It’s time to become proactive and put the first steps towards preventing the next security incident in our dependency chain.
