Open-source software has become a common tool for enterprise application development and delivery. While the efficiencies are clearly beneficial, widespread usage has introduced a pervasive vulnerability that needs addressing. Robert Castles, chief technology officer at PMG, delineates the security risks that come with open source software and how we can be more mindful while tapping their potential.
According to the 2022 Open Source Security and Risk Analysis ReportOpens a new window , 97% of code in codebases is open source – a strikingly high number evidencing the composability of today’s technology. Unfortunately, 81% of these contain at least one known open-source vulnerability. So, it’s no wonder we’ve seen a record number of open-source security incidents in the news, including cyberattacks on corporations and entire supply chains, hacks to sabotage files offered through open-source libraries and a general lack of standards and enforcement.
Let’s take a look at some of the reasons behind open-source vulnerabilities and what measures would help mitigate them.
Surely Someone Else Checked or Fixed the Issue – Right?
Whether you call it groupthink or diffusion of responsibility, a common practice in IT and development is to assume open-source software must be safe if “everybody else†uses it. Alas, this is clearly untrue. Developers should never simply believe open-source code is good to go without verification.
One of the most recent and infamous examples is the well-known Apache Log4jOpens a new window vulnerability that enabled attackers to execute arbitrary code on susceptible servers. The broad-reaching Log4j vulnerability affected everything from the cloud to developer tools and security devices.
This incident shed light on the inherent trust companies place in open source. Development teams often use it without going through the same security reviews required for other software development. But just because open-source software is readily available doesn’t make it safe.
Remember, most open-source projects focus on features and functionality, with security being an afterthought. And even when open-source developers do their best to avoid vulnerabilities, security is probably not their strong suit as code writers.
Thinking There’s Safety in NumbersÂ
Another challenge of using open-source software is combatting the thinking that if a vulnerability exists, it will impact someone else first. When usage is widespread, surely someone else’s organization will be the proverbial canary in the coal mine. At the very least, there’ll be time to fix the issue before any consequences arise. That’s how the thinking goes anyway.
Many companies believe they’re unlikely targets – that the data they hold is relatively unimportant to outside parties. But this blind faith doesn’t account for vector attacks, which use an initial incursion to establish other breaches. We’ve seen this when cybercriminals target a supply chain – hacking a vendor to access a bigger target.
This “it won’t happen to me†mentality leaves organizations vulnerable.
See More: The Perfect Pair: Testing and SecurityOpens a new window
How Reliable Is the Source?
According to the  Vulnerabilities in the Core: Preliminary reportOpens a new window and Census II of Open Source Software, seven of the ten most-used open-source software packages were hosted under individual accounts.
This information is concerning because individual developer accounts are typically more vulnerable to hackers. The report notes they likely lack the security measures of organizational accounts, making undetected changes to code easier.
Many Open-source Developers are Frustrated
Further, some independent developers sabotage their own software out of anger or protest. Others intentionally include backdoors in their code, while others still abandon their work out of boredom.
In a recent example, the developer behind the popular npm package “node-ipcâ€Opens a new window released a sabotaged version to protest the Russian-Ukrainian war. Initially, the updated packages installed a new text file with a “message of peace†– a relatively harmless addition. Not for users in Russia or Belarus, though, for whom the packages deleted data and overwrote desktop files.
Some developers purposely build backdoors into their software for non-malicious reasons or for future monetary gain, leaving unsuspecting users vulnerable. In other situations, time is the culprit. When developers burn out, get bored, or simply move on, there is often no one to maintain or update the code.
Most open-source codeOpens a new window (88%) contains components with no new development in two years, and 85% of open source was more than four years old. Those vulnerabilities will linger without security updates to any code contained within. Even in the best cases, open-source publishers often lack the communication processes to notify users about recommended updates.
“Off-label†Use and the Governance Gap
Another concern is when open-source code developed for a particular purpose is used in ways that were not intended. For instance, say there’s an open-source app that records weather data and renders a pretty graph. But then, someone decides to use it to store employee data so they can use the charting function.
When originally created, the open-source code was fine for publicly available weather data. But now, it’s being used beyond the security scope considerations of the original developer and is insufficient for personally identifiable information (PII) like Social Security numbers.
The security of software developed and used by an organization must be a priority. This means establishing clear responsibilities for software security and procedures to ensure proper precautions are taken.
Many corporations, including the one I work for, obtain their System and Organizational Controls (SOC) 2Opens a new window certification through third-party auditors. This certification provides objective evidence of an organization’s security, availability, processing integrity, confidentiality or privacy controls.
But while enterprises commonly require vendors to prove SOC 2 compliance and have typically established security practices for internal initiatives, they haven’t applied the same rigor to adopting open-source components.
Where Do We Go From Here?
Unfortunately, demanding a $20,000 SOC 2 audit from the providers of your favorite free JavaScript library isn’t going to work. And even if certification could be required for open source, it likely wouldn’t be enough.
SOC 2 and ISOOpens a new window certification – the latter of which validates a software developer complies with the guidelines set by the International Organization for Standardization – are excellent tools to ensure the software development supply chain is as strong as it can be. But in reality, the chain is long, and the links are not always obvious or intuitive.
I’m not discouraged, though. Despite the numerous challenges I’ve described, movements in the industry show promise. For example:
- Security tools are improving, even though they are not yet universally applied.
- The Open Web Application Security Project (OWASP) focuses on improving security for companies, customers and developers. The non-profit foundation helps companies improve security in software development.Â
- Substantial opportunity exists to incorporate security practices and new technologies into the build pipeline. For example, GitHubOpens a new window and others offer a pluggable framework to ensure specific steps are executed on a project.
- Increased collaboration among industry players bodes well for the development of standards.
For now, however, the industry will have to step up on its own until such standards are established, and an objective enforcement organization for open-source software is firmly in place. Google announced its Assured Open Source SoftwareOpens a new window service, providing security declarations for a curated list of open-source packages.
With only a moderate amount of rigor in the software build pipeline, I believe we can eliminate the most glaring open-source security issues, making it more challenging for hackers to penetrate and safer for the developer community and organizations.
How are you ensure safety and security while making the most of open source options? Tell us on FacebookOpens a new window , TwitterOpens a new window , and LinkedInOpens a new window . We’d love to learn from you!