A Story of Collaboration
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. To stay one step ahead of this constant race against malicious actors, the group agreed there was 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 of the SCAR forum. While working at Citi’s Cyber Security Innovation Lab, she launched the SCAR forum with a strong emphasis on its cross-industry nature.
Figure 1: Supply chain security through collaboration
Open Source and Packages
90% of organizations use open-source resources, since they are a great way for organizations to quickly create and deliver software. However, 3rd-party open source dependencies 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.
There is a dissonance between the quantity of available open-source tools that many organizations utilize for code development, whether they are startups or large entities that rely on open-source code or third-party components using open-source code, and the available tools to vet these packages. This leads to a dependency which opens a wide and fertile realm for threat actors to operate in and leverage to get access to organizations’ networks.
Figure 2: Software developer browsing the web to download an open-source NPM package
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 themselves 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 are an email address, and an open and unique package name. Creators can assign it to themselves and include any code 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 give an appearance of legitimacy to their packages, luring developers or end-users into a trap that may not be particularly sophisticated.
How Developers Choose Open Source
Let’s imagine we are software developers. We were assigned a new task to add a new feature to an existing NPM project. As we try to set up our environment, we are getting the following error message:
Figure 3: A screenshot of the error message when setting up new environment
Problem? "Google It"
Some developers trying to solve the issue may search for a solution via search engines. Simply copying & pasting the error message into a search engine offers some interesting, and relevant, leads to a solution for a common problem.
Figure 4: 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?
Figure 5: Screenshot from a popular Stack Overflow 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 copying & pasting the suggested install command and executing it on their local development environments.
Figure 6: The troubleshooting circle
Evaluating Open-Source Packages
Should developers be responsible for security? Yes. 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 services. Each of these tools are designed to assist software developers in understanding the structure and security of available open-source packages. Developers may use them to evaluate the packages they consider installing and make responsible decisions.
Unfortunately, even though these tools are accessible, not all developers possess an awareness of their existence or incorporate them into their daily internal workflows.
Figure 7: A screenshot of socket.dev, displaying the package report of the express-generator package
Developers usually 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. Not because they don’t care, but because they are not aware of the threats, they are not security-oriented users and, therefore, an easy target for threat actors.
We assume some developers are simply not aware of this important step that should be defaulted in their research flow, while others may be unaware of those free tools.
The Solution: Overlay Browser Extension
To keep the developer’s experience as native and intuitive as possible, while assisting the developer in being aware of such tools and free information related to open-source packages, software supply chain leaders Checkmarx and Illustria, members of the SCAR forum, joined their research forces for the good and created Overlay - an open-source browser extension.
The extension detects references to open-source packages and adds links to numerous free tools offered by industry leaders providing extra information to help developers assess the package’s legitimacy, which is crucial for the developer’s evaluation process.
Figure 8: A screenshot from StackOverflow answer after Overlay is installed on the browser
Floating Shortcuts
With minimal intrusion, the browser extension provides a configurable tooltip displaying key points from each report.
Rather than manually typing, searching, and finding information related to the candidate package, with Overlay, developers get a tooltip with quick links to those trusted sources mentioned above.
Figure 9: Screenshot from a popular Stack Overflow answer with Overlay browser extension tooltip
Figure 10: A screenshot from the GitHub page of Overlay https://github.com/os-scar/overlay
Summary
So far, the Overlay project has received contributions from Checkmarx, Illustria, Vulcan, Maakaf, and more individual contributors. "Don't take code from strangers without vetting,” advised Baruch Odem, Senior Software Engineer at Checkmarx and one of the leading contributors to the Overlay project. This is a great example of how vendors should collaborate despite being competitors and contribute back to the community.
The main value of Overlay is to offer developers an intuitive experience while connecting them with security advisories from reputable sources and empowering developers with the mindset to take responsibility for the code they intend to install.
We encourage individuals and organizations of all scales, from startups to enterprises, to consider integrating Overlay into their workflow. We acknowledge that this process may take time, and implementation depends on the maturity of an organization and other factors. We encourage developers to consider using Overlay even for personal usage.
Remember that threat actors are aiming their focus in the past few years on poisoning software supply chain open-source dependencies and targeting developers and we need to work in collaboration as an industry towards a common goal to not only track these malicious activities, share information and research, but also work together to create a safer open-source environment.
