Organizations must take steps at every stage of the software supply chain to ensure developers’ environments. Enterprises must also make sure processes and secured, so you aren’t leaving your business vulnerable to next-generation SCS attacks, like AI package hallucinations, dependency confusion, typosquatting, and repojacking. 

Let’s dive into a brief history of how “supply chain security” has evolved to the point we are today, what organizations must consider when securing their software supply chain, and how Checkmarx is proactively building new solutions to address this complex and ongoing issue. 

Our mission to secure the entire software supply chain

For the past 10 years, security professionals have been trained that before you release code, all high vulnerabilities need to be identified and fixed. But over the last few years especially, the world has changed. According to GitHub, open source is now the foundation of more than 90% of the world’s software.  Organizations are now facing a shifting attack landscape, along with an overwhelming number of vulnerabilities. The attack landscape is moving from the application itself, to where there are new vulnerabilities and weaknesses – in the process surrounding your development, and the components you use to build your application. 

What software supply chain security really means

Traditionally, supply chain security was to a way to gain visibility and mitigate 3rd-party code vulnerabilities through SCA. But as time went on and as new attack types emerged. In a 2021 executive order, software bill of materials, or SBOMs, are required for all software sold to the US federal government. The mandate underscores the importance of an accurate list of all open-source software ingredients found in a software-based product. The market quickly realized that the scope of software supply chain attacks, and how we prevent these attacks, go way beyond SBOMs and malicious packages.  

Supply chain security is defined as a specific aspect of application security that focuses on protecting the software development process and the components used in that process. Software supply chain security is not a single solution; it is a discipline. 

Supporting the SLSA Framework

The Supply-chain Levels for Software Artifacts (SLSA) framework, developed in collaboration with the OpenSSF and Google, addresses the growing concern of software supply chain security, offering a structured approach to assessing and improving the integrity of software components used in development. 

SLSA introduces key concepts like artifacts, provenance, digests, immutable references, and build integrity, that provide a systematic way for the software industry to secure the development lifecycle and promote consistent security standards.

Understanding that the full scope of SCS is beyond a single tool, Checkmarx has implemented a broader strategy to cover things outside of your typical application security posture management, in full alignment with the SLSA framework. 

How Checkmarx is helping you secure your software supply chain

Today, Checkmarx is providing expert guidance and proven solutions to manage open-source risk, along with new and exciting solutions to start protecting your entire supply chain today. 

In the last few years, one of the biggest emerging threats have been malicious packages – notably different from vulnerable packages. In the SLSA framework, malicious packages are a form of dependency attack where attackers inject or contribute malicious code into open-source projects that your developers download and build into your applications. Once downloaded, the attacker’s malicious code is running within your applications, with whatever unknown intent the package carries. 

Checkmarx SCA, introduced in 2021,  was a major step in helping organizations identify and start reporting on their open-source vulnerabilities. We were the first vendor to include malicious package detection inside our SCA solution. Since then, our research team has inspected over 7.6 million open-source packages for all kinds of threats, finding 200,000+ malicious packages. We make that threat intelligence available to you, either in our SCA product, where findings are in the portal or directly in developers’ IDE, or through an API-based threat intelligence feed. 

Checkmarx SCA enables automated SBOM generation, and Checkmarx Container Security, which works with Checkmarx SCA, identifies vulnerabilities in open-source packages included in container images. Together with our partners at Sysdig, we recently announced runtime insights, so organizations can get the full picture of pre-production and deployment, gaining visibility into which container images are in-use and prioritize the ones that pose the most risk.

We realized customers need support in prioritization, especially with all these newly discovered vulnerabilities, so we released Exploitable Path. It’s a unique feature that allows our customers to prioritize vulnerabilities in open-source libraries.  

When you look at the SLSA framework, we also have always led the way in terms of identifying Infrastructure-as-Code (IaC) misconfigurations. We are the driving force behind the most downloaded open-source tool in this area – Keep Infrastructure as Code Secure, or KICS for short.

All of these are important tools in managing open-source risk, but we are not stopping there. 

Since GenAI  is becoming a popular resource for developers to generate code, a variety of new SCS attacks have recently emerged, such as: 

• AI hallucinations: These are false data points or patterns that AI models might “perceive” due to adversarial inputs or misinterpretations, which can be exploited by malicious actors.
• Prompt injections: Threat actors can manipulate AI models by introducing or “injecting” specially crafted prompts, tricking the system into undesired behaviors or outputs.
• AI secret leakage: There’s a potential risk of AI models inadvertently revealing confidential information they were trained on, offering a goldmine for cybercriminals.

In August, Checkmarx introduced the industry’s first plugin to detect and prevent attacks against ChatGPT-generated code. The plugin enables developers to easily scan their ChatGPT-generated code for vulnerabilities within the ChatGPT interface, receive instant feedback on potential vulnerabilities or validation of open-source packages, and employ protection against malicious open-source packages. 

Now, we’re leading the way again, and broaden the definition of software supply chain security, beyond just malicious packages, to every component in, and every tool used to build your applications. As part of the Checkmarx One 3.0 launch, we’re taking it  one step further, introducing two new capabilities –Secrets Detection and Project Scorecard.

Prevent secrets from leaking on external tools with Secrets Detection  

Secrets, such as passwords, API keys, cryptographic keys, and other confidential data, are a frequent target of a distributed supply-chain attack.  

Secrets can easily be mistakenly shared on external tools like slack, confluence, twitch, and documentation pages.

Secret detection isn’t new – we have one of the most popular open-source tools for secret detection. 2MS from Checkmarx has over 2 million downloads, and anyone can get started today by detecting secrets such as login credentials, API keys, SSH keys and more hidden in code, content systems, chat applications and more. 

If you are a Checkmarx One user, Secret Detection is now available directly in the Checkmarx One platform.  

Tackle the most vulnerable projects first with Project Scorecard 

One of the latest additions to the Checkmarx Supply Chain Security portfolio is Project Scorecard, which enables organizations to check their own projects quickly and see the most vulnerable or at-risk projects, allowing enterprises to prioritize which to tackle first.

Project Scorecard leverages the format from a popular tool, the OSSF Scorecard, which assesses open-source projects for security risks through a series of automated checks. 

These checks cover different parts of the software supply chain including source code, build, and dependencies, and assigns each check a score of 1-10. An auto-generated “security score” helps users as they decide the trust, risk, and security posture for their specific application. 

While an important tool in combating the uptick of open-source software attacks, open-source projects are only a portion of the projects in your application. Checking the process and components of owned projects is an important element in securing the total software supply chain.  

With Project Scorecard, users can auto-generate a security score for their own projects based on a series of checks, including: 

• Binary Artifacts – Is the project free of checked-in binaries? 
  • Branch Protection – Does the project use branch protection? 
  • CI Tests – Does the project run tests in CI, e.g., GitHub Actions, Prow? 
  • Code review – Does the project practice code review before code is merged? 
  • Dangerous workflow – Does the project avoid dangerous coding patterns? 
  • Vulnerabilities – Does the project have unfixed vulnerabilities? 

By utilizing the Project Scorecard, as part of the Checkmarx Supply Chain module, we allow enterprises to quickly see the most vulnerable or at-risk projects, and ultimately help prioritize which to tackle first. 

Taking the next step to secure your software supply chain  

It’s important to take steps to secure your software supply chain today; detecting supply chain attacks in code packages, securing your developer’s evolving workstations supports rapid development while reducing risk. 

Current Checkmarx One or Checkmarx SCA customers will have access to all these tools within the platform. 

If you’re not already a Checkmarx One customer, you can start securing your software supply chain today with too many secrets (2MS), available as an open-source project on GitHub.

We’re incredibly excited to announce these new features to help you secure your software supply chain, but we’re only getting started. The work of securing the software supply chain is never done, as bad actors identify innovative new ways to capitalize on gaps in process and components, so stay tuned for more exciting announcements. 

If you’d like to learn more register now to join us for our technical deep dive webinar on Nov 6th, “Secure your software supply chain”.

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.