Working Together To Keep Open Source Safe

At the beginning of 2023, top researchers from industry-leading companies established the Supply Chain Attack Research (SCAR) group. In order to stay one step ahead of this constant race against malicious actors, the group agreed there’s a need to foster collaboration among experts, define efficient standards, develop tools to benefit the global community, and promote joint research and information sharing.

Karine Ben-Simhon, VP of Customer Advocacy at Trellix Advanced Research Center is one of the founders. While working at Citi’s Cyber Security Innovation Lab, she launched SCAR forum with a strong emphasis on its cross-industry nature.

Open Source and Packages

More than 90% of organizations depend on open source, since it’s a great way for organizations to quickly create and deliver software. However, 3rd-party open-source dependencies can also come with inherent risks     .

Open-source software libraries (also called packages) are published to multiple hosting ecosystems, such as NPM, PyPi, and GitHub, just to name a few. 

Vulnerabilities and Malicious Code

Vulnerabilities are one of the many risks of using open-source code. While vulnerabilities are usually           not purposely inserted by the authors, the potential exploitation may be critical (such as Log4j RCE critical vulnerability). 

On the other hand, malicious code is different. Attackers publish malicious open-source packages that disguise as legitimate for developers and contain harmful code silently deployed on developers’ workstations, build systems, production servers, and even end-consumers. such as This campaign of 900+ malicious typosquatting packages or These malicious packages dropping undetectable sophisticated malware, and many more

Not Originally Designed For Security

It is easy to consume open-source packages, and for creators, even easier to publish new content to those open-source ecosystems. All a publisher needs      is an email address, and an open and unique package name. Creators can assign it to themselves and include any code they’d  under that name in a matter of seconds.

There is almost no vetting at all of the content being published to such open-source ecosystems. For example, attackers take advantage of the Starjacking attack technique to make their packages appear legitimate. 

How Developers Choose Open Source

Let’s use the developer’s POV. Imagine you’ve just started a new NPM project, and you’re getting, for example, the following error message:

`‘express’ command is not recognized. 

Problem? “Google It”

Some developers trying to solve the issue may search for a solution via search engines. Simply copy & pasting  the error message into a search engine offers some interesting, and relevant, leads to a solution for a common problem

a screenshot of searching the error in Google Search engine

The top result is a StackOverflow thread that looks promising. Many answers simply suggest installing the express-generator package, without explanation. However, just because people say it’s OK, it really is?

screenshot from a popular StackOverflow answer, recommending using express-generator npm package

The Troubleshooting Circle

Many developers who run into similar answers recommending installing an open source package would go ahead and install it on their local machine, by simply copy & pasting the suggested install command and execute it on their local development environments.

Evaluating Open-Source Packages

With great power comes great responsibility, and developers are responsible for evaluating open source packages before using them.

There are multiple parameters developers should check before installing an open-source package. Some developers might focus on the license, others may  be more interested in avoiding abandonware and focusing on maintained projects, and others may avoid projects with unresolved security issues.

This important step of a developer investing time in evaluating an open source usually includes manual labor in comparing the related source code repository with the actual package content, reviewing the package contributors, viewing the project’s popularity and adoption, maintenance metrics such as how fast issues are resolved, and more. 

This is time-consuming, but luckily, there are great tools such as Socket, Snyk Advisor, Scorecard, and Debricked,  that provide those aspects. Developers may use them to evaluate the packages they consider installing and make responsible decisions.

a screenshot of socket.dev display the package report of express-generator package

The Problem: Lack of Evaluation

Sadly, based on a poll we performed, developers often will not go out of their research flow to analyze the package security level, and there is a low chance that developers will invest in an evaluation process every time they are considering a new package. 

We believe some developers forget about this important step, while others may be be unaware of those free tools.

The Solution: Overlay Browser Extension 

To keep the experience as native as possible, software supply chain leaders Checkmarx and Illustria joined their research forces for the good and collaborated to create Overlay – an open-source browser extension intended for developers. The extension detects references for open-source packages and adds links to free tools providing extra information that is crucial for the evaluation process.

With minimal interference, the browser extension offers a configurable tooltip with highlights of the report itself, an attempt to convince the developer to read the full report for a better evaluation of the open-source package

screenshot from a popular StackOverflow answer with Overlay browser extension tooltip

Give Overlay a try – https://github.com/os-scar/overlay