Open source was once hailed as revolutionary: a utopian form of development that prioritized collective utility over personal economic gain. Flexibility and adaptability form the core ethos of open-source software. This is particularly evident from the accessibility and prevalence of such software – most open source projects can be pulled from public repositories, ready for immediate implementation.
However, the utopian ideal of open-source is perhaps overly naive. Open-source software may be hyper-accessible, but it’s an increasingly large component of the current software supply chain security crisis. Nowadays a reliance on open source software necessitates a WAF solution, and a healthy dose of skepticism.
The Reign of Open-Source
Under the hood of today’s ‘smart’ gadgets, devices, and vehicles, are the chugging engines of open source code. From smart fridges to cutting-edge artificial intelligence programs, open source really does make the world go round. Take the Apache web server, which serves over 60% of online traffic; the Linux kernel operating system forms the basis of all Android devices. Django is a Python-based framework that empowers millions of users to create secure and maintainable websites. The importance of these lines of code mean that their stability and security are of vital importance to every company.
The lifeblood of open-source is each project’s buzzing community of typically unpaid and overworked developers. Compare this with the traditional build lifecycle of for-profit software. The developer tools and processes are kept deliberately vague; many software vendors take this as an opportunity to tack on pricey implementation packages. By removing many of the financial and skill barriers to developer tools, software developers are freed from the legislative wait on procurement or licensing. Furthermore, access to the genuine source code allows developers to rapidly understand the software’s mechanisms, reducing its learning curve.
The ethos of open-source superiority is still kicking about. Take the recent legal conflict between Amazon and Elastic. Elastic built and continues to maintain their Elasticsearch software, which supports an adaptable and user-friendly search engine. Walmart and Audi are two large corporations that make use of Elastic’s free software. More recently, however, Amazon decided to develop their own version of Elasticsearch. However, their product treads a line between plagiarism and progress: a look under the bonnet of the new product shows that they simply repackaged Elastic’s code, selling it to their customers under almost the exact same name. This would mean that Amazon pilfered free code – that created value for the whole community – and stuck it behind a paywall for their own personal profit.
Despite the innumerable positives of open-source software, and its superstar role in today’s corporate landscape, there are some significant security flaws hidden in the fame.
Supply Chain Security
Supply chain security was dragged into the limelight toward the tail end of 2020. The SolarWinds attack saw Russian-backed hacking groups take advantage of a piece of software that forms the backbone of millions of major US corporations. The Orion software was a critical component to IT Teams’ analyses, and – at some point in December – attackers switched out the genuine software downloader with one of their own. By compromising it at its source, the attackers were granted access to anyone who uses it. In this case, it meant they had access to as many as 18,000 SolarWinds customers. As it was a state-backed espionage, the attackers chose to break into fewer than 100 choice networks—including Fortune 500 companies such as Microsoft, and state departments such as the US Justice Department, and NASA.
When supply chain attacks hit, they hit hard. Compare the development and security protocols of SolarWinds with that of FOSS developers. While SolarWinds approached the issue with all hands on deck, open source teams are consistently struggling to meet the growing requirements of bug hunting: the time taken to fix open source vulnerabilities is almost 20% longer than in proprietary projects, lengthening from 49 days in 2018 to 110 days last year.
Part of this issue is thanks to the development architecture of open-source software. Many open-source packages – even the vital, foundation parts of for-profit software – are kept under the account of an individual developer, instead of the wider team you’d expect in an organization. This creates a major issue of reliability: an individual may choose to retire, take a new job, or otherwise become incapable of managing the sizable responsibility that is a popular open-source project. Individual accounts also represent isolated threats, and regularly lack the safeguards to prevent an attacker from accessing the source code.
From Open-Source to Compromised
Recent cases of malicious code being dropped into open-source libraries are almost too innumerable to count. Some particularly dangerous examples include the heavily-downloaded python package ‘ctx’. Originally a module allowing developers to manipulate their software’s dictionary objects, the package was last updated in 2014 yet continued to be heavily relied upon by the Python development community.
Suddenly, in May 2022, a new update was released. This new version had been spiked with malware, however, and the compromised version aimed to exfiltrate the devs’ device information to a third-party server.
This process follows an eerily similar attack path replicated across much of the PyPI repository. Multiple other packages had been tinged with software that stole sensitive information. This included collecting and publicly sharing AWS login credentials.
As developers are increasingly placed under threat throughout the open-source development lifecycle, the lack of financial benefit – and potential for their image to be ruined by hijacked software – may push increasing numbers back towards for-profit models. Furthermore, it begs the question: what are companies doing about this broadening attack surface? The answer is fairly grim.
Heads in the Sand: Companies Are Ignoring the Issue
Many companies are all too happy to reap the benefits of open-source software. A faster time-to-market, alongside ease of implementation, are fantastic for organizations and customers alike. However, companies are failing to recognise the covert risks introduced by pre-assembled components.
New research from the Linux Foundation discovered that companies are shockingly poor at managing the open-source risk factor. Only 49% even have security policies that aim to recognize and mitigate open-source code dependencies. Over two-fifths (41%) of organizations do not have confidence in the security of their open source code.
This internal distrust of open-source is a reflection of the security policies that make up the fabric of their attack surface. Many companies are using outdated versions of open-source programs, which can rapidly become vulnerable to exploits. The issue is exacerbated by cybersecurity’s mounting staff shortages: 30% of organizations without an open-source policy do not have the staff to hone in on open-source vulnerabilities. This leaves a clear and unguarded avenue of attack – abuse of which is only a matter of time.
Open Source is Here to Stay – Here’s How to Manage the Security Risks
A software bill of materials (SBOM) is a complete list of every software component used across an organization. The SBOM enables you to keep a comprehensive overview of third-party open source libraries; vendor-provided packages; and first-party artifacts built or configured in-house. The goal is to break down your tech stack’s complex and interwoven mix of software into a transparent breakdown of any potential attack vector
While an SBOM grants a clearer view of your organization, a third-party security solution will reinforce your tech stack and prevent an attacker weaponizing that open-source code. A Web Application Firewall (WAF) sits at the edge of each application, monitoring their external connections. This security feature prevents a compromised application from establishing any connection with an unrecognized server, such as those wielded by attackers. A Runtime Application Self-Protection (RASP) tool can further aid in protection as it actively monitors the internal processes of the app; should any component attempt privilege escalation or unnecessary data, RASP shuts the process down and automatically reports the concerning behavior.
With a comprehensive and precise security toolkit, open-source software can continue to drive business growth whilst mitigating the strain placed upon your security team.