While the open-source ecosystem continues to make progress on securing the production of widely used components, developers need better tools and a security culture to benefit.
With major security incidents linked to common open-source dependencies, such as the Log4Shell exploit targeting vulnerabilities in Log4j, open-source security initiatives have sought to add security capabilities to vital ecosystems and give developers more tools to improve the security of applications built using these ubiquitous frameworks and components.
Tech companies and open-source-focused organizations alike have worked to identify critical software, supported efforts to secure these commonly used components and released a variety of tools dedicated to supply chain security. OpenSSF’s Security Scorecard, for example, helps developers gauge whether a given open-source project has known vulnerabilities, while Sigstore offers a way to verify that a particular open-source component is legitimate.
Major open-source platforms have also sought to improve their security. In August 2022, GitHub announced it would support integrating technologies such as Supply-chain Levels for Software Artifacts (SLSA) and Sigstore in the Node Package Manager (npm) repository for JavaScript components, which it manages. The Python Package Index (PyPI), RubyGems and NPM have all mandated two-factor authentication (2FA) for their most critical projects, too.
Open-source software has even become a priority for the Biden administration, which has held summits with technology companies and open-source advocates to establish ways to improve security.
Yet, despite these efforts, today’s developers usually fall back on a standard process for finding new open-source components for their projects: Searching Google or StackOverflow for solutions to their problems, looking for metrics that may indicate the trustworthiness of a particular component or the open-source project behind that component. Often, they will use a project mentioned in a tutorial or sample code, without even checking the reliability of the codebase or the project’s maintainers.
And the frequent result: a version of a software component with known vulnerabilities will be installed and used, Ilkka Turunen, field CTO at software-composition analysis firm Sonatype, told README. More than a quarter of open-source packages released last year, for example, still had unfixed known vulnerabilities, according to the firm.
“The danger with the supply chain is when you integrate something into the project ad hoc based on a requirement in the moment, and over time, it doesn’t break, there’s no functional reason … that forces you to upgrade,” he said. “It’s behavior that’s essentially born out of the moment — you probably don’t spend more than five minutes thinking about it, and especially when it comes to security vulnerabilities, that’s kind of the silent killer.”
An incident with a side of Java
The security impact of vulnerable dependencies is not theoretical. In November, Fox-IT consultants responded to a compromise involving a customer’s ConnectWise backup management server — a flaw had allowed an adversary to attack the server and then use the software’s high privileges to pivot from that server to infect every client running on other systems.
Yet the actual vulnerability was not in code written by ConnectWise developers, but in an open-source component — the ZK Java Framework — used as the foundation of the application.
“The adversary used it as an initial point of access and as a platform to control downstream systems connected via the R1Soft Backup Agent,” Fox-IT stated in an analysis of the case posted in late February. “After successfully exploiting the vulnerability, the adversary deployed a malicious database driver with backdoor functionalities.”
Attacks like the ConnectWise compromise also show something else: Usually, there are already patched and more secure versions of vulnerable software components, but developers are not patching and distributing these fixes fast enough. The ZK Java Framework vulnerability (CVE-2022–36537), for example, was discovered and disclosed early last year, and ZK patched the flaw in May 2022. Attackers started exploiting the vulnerability in November, and by December, proof-of-concept exploits started to appear in public forums.
The incident described by Fox-IT occurred on Nov. 29, 2022, well after the patched version was available.
A “consumer-side” problem
Open-source components have been a boon to software developers, allowing companies to quickly create new applications based on popular software frameworks. Overall, 96% of applications scanned by application security firm Synopsys, for example, used some open-source components, with the average application consisting of 76% open-source code. Unfortunately, those components bring vulnerabilities along for the ride: Synopsys found that 84% of the more than 1,700 codebases audited by its customers had at least one flaw, and 48% had at least one high-severity flaw, the company said in the 2023 Open Source Security and Risk Analysis (OSSRA) report published in February.
Overall, software engineering teams are often more like software assembly teams, Varun Badhwar, founder and CEO of software-security firm Endor Labs, told README. “More code today is code that you don’t write yourself, but borrow from the internet,” he said.
Yet, development teams need to realize that open-source software comes with a price.
“Honestly, the thing that lags behind is the realization by the adopters of open source in companies and organizations, that nothing in this world comes free,” Badhwar said. “It may be free — as in free, dollar-cost-wise — but you still need to put programs and people’s time in place to actually manage and understand all of the security and operational implications of using open source.”
On the face of it, the production of open-source components used by software developers is making significant strides on becoming more secure. The average project releases updates about 10 times a year, eliminating known security vulnerabilities, Sonatype’s Turunen told README. In addition, the incidence of open-source components with high-risk vulnerabilities found in scanned applications dropped to 48%, the lowest in four years, according to the OSSRA report.
However, development teams and software engineers continue to lack the tools and the culture to pursue security. When importing open-source components into software development projects, there is a better version of the component available 96% of the time, but developers are often unaware of the update or fail to download the code, according to Sonatype’s 2023 State of the Software Supply Chain report.
“Vulnerability tends to be a consumer-side problem,” he told README. “For whatever reason, when people download a version, they choose to go with that older version, so … there’s still a lot of work to do in the supply chain, especially on the consumption side.”
“Vanity metrics” and unintuitive tools
Rather than use the latest tools to measure the trustworthiness of open-source projects, developers often default to unreliable attributes that were never meant to measure security, such as the number of stars on GitHub or the number of downloads, both of which are more measures of popularity. Malicious developers can actually purchase stars and pad their downloads to make their program seem popular, Endor Labs’ Badhwar told README.
“These are vanity metrics, not really true metrics of security,” he said. “You really shouldn’t use open-source software without understanding all of the human risks, the code quality risks, their practices for doing releases, the community strength, the responsiveness of the community, the security of the community — but not a lot of tooling exists to give that data today to the developers.”
Unfortunately, selecting the most secure software is not always intuitive. The latest version of a component is not necessarily the safest one, for example — the safest version of a software component is, on average, 2.8 versions behind the latest one, according to Sonatype. For developers, this poses a quandary: Do they update to the latest version to get the most recent features and vulnerability fixes, even if the component has new vulnerabilities as well?
For developers, then, better information is needed, provided through more intuitive tools using understandable metrics. That starts with development teams finding out how exposed they are to vulnerabilities in open-source software and dependencies, Isaac Hepworth, a product manager at Google, told README. Only a minority of software organizations today have a clear view of their dependency footprint, he said.
“Start by producing an inventory of your dependencies,” says Google’s Hepworth. “Only when you know what you rely on can you begin to reason about–and reduce–the risk.”
On April 11, Google opened up its own dependency database covering some 5 million open-source components in five different ecosystems, including the Node Package Manager (npm), PyPI and Maven — the main open-source repositories for JavaScript, Python and Java, respectively.
A lot of work still needs to be done by the project leaders maintaining open-source components and frameworks, but even if they make progress, it’s moot without developers taking a greater role as a more critical consumer, said Sonatype’s Turunen.
“On both sides, unfortunately, we’re nowhere near done,” he told README. “And I don’t think this is going to be a thing that’s going to get solved anytime soon. On the consumption side, especially, I think it is a big cultural shift, and it’s very right to say that there’s still a lot of work to do.”
Edited: The original article attributed the 2023 Open Source Security and Risk Analysis (OSSRA) report and its data to the wrong company. It’s published by Synopsys.
