Key Points

1. An attacker distributed a malicious dependency hosted on a fake Python infrastructure by linking it to popular projects on GitHub and legitimate Python packages.
2. The malicious dependency, masquerading as the popular “colorama” package, contained hidden malware designed to steal sensitive data from infected systems.
3. The attacker hijacked GitHub accounts, including one belonging to a top.gg contributor, using it to make malicious commits and spread the malware to a community of over 170K members.
4. Employing a multi-stage execution process, the malware fetches and executes obfuscated code from multiple external sources, using techniques like encryption, encoding, compression, and misleading characters to evade detection.
5. Targeting a wide array of applications, such as web browsers, social media platforms, email services, and messaging apps, the malware harvests sensitive information, including login credentials, session tokens, and personal data.
6. Stolen data is exfiltrated to the attacker’s server, and persistence is established through Windows registry modifications.

Weird Message, Got Hacked

“I was using my laptop today, just the regular messing around with python and other stuff on my command line, until I seen a weird message on my command line saying that there’s something wrong with colorama on python, I didn’t care much cause I’m used to this stuff so I just skipped it, Few minutes later I got the same error message but in a different script I’m using. The moment I seen this I knew what’s going on, I got hacked.”

This chilling account comes from a recent blog post by Mohammed Dief, a Python developer who fell victim to a sophisticated malware attack while cloning the repository “maleduque/Valorant-Checker”.

Mohammed’s story is just one example of the far-reaching impact of this malware campaign. The attacker behind the campaign employed a devious strategy to spread the malware through malicious GitHub repositories.

Fake Python Mirror

The attack infrastructure included a website that appeared to be a Python package mirror and was registered under the domain “files[.]pypihosted[.]org”.

This domain selection is a clever typosquat of the official Python mirror “files.pythonhosted.org,” as the latter is where the official artifact files of PyPi packages are typically stored.

In the attacker’s footprints, we saw they utilized a feature in pip (package manager for Python) where you can specify a URL to grab your package dependency and use their fake Python mirror to download packages.

Requirement.txt file, Fake mirror URL vs legitimate URL

Fake Mirror Is Hosting a Poisoned “colorama”

The threat actors used Colorama,  and added malicious code inside, then hosted the poisoned Colorama package on their typosquatted domain; the attacker was able to use the exact same name as the popular “Colorama” package without raising immediate suspicion. This tactic makes it significantly harder for users to detect the malicious nature of the package, as it appears to be a legitimate dependency at first glance.

To further conceal their malicious intent, the attacker employed a strategic approach when committing changes to many of the malicious repositories. They would simultaneously commit multiple files, including the requirements file containing the malicious link, along with other legitimate files. This calculated move aimed to minimize the chances of detection, as the malicious link would blend in with the legitimate dependencies, reducing the likelihood of users spotting the anomaly during a cursory review of the committed changes.

Example of the attacker hiding Fake mirror URL within a commit of multiple files.

Hijacked GitHub Account

The attacker’s reach extended beyond creating malicious repositories through their own accounts. They managed to hijack the GitHub account of a user named “editor-syntax,” who is a member of the company top-gg and a contributor to one of their repositories. With control over this trusted account, the attacker carried out a series of malicious activities:

Starring Malicious Repositories: The compromised account was used to star multiple malicious GitHub repositories created by a user named LoffyNora. This activity aimed to increase the visibility and credibility of the malicious repositories.

Malicious Commit to top-gg Repository: The attacker made a malicious commit to a repository belonging to top-gg, exploiting the trust and privileges associated with the compromised account of “editor-syntax.”

Spreading the Malware: Through the compromised account, the attacker likely spread the malware to unsuspecting users who trusted the reputation of “editor-syntax” and the top-gg organization.

Account Takeover via Stolen Cookies

The GitHub account of “editor-syntax” was likely hijacked through stolen cookies. The attacker gained access to the account’s session cookies, allowing them to bypass authentication and perform malicious activities using the GitHub UI. This method of account takeover is particularly concerning, as it does not require the attacker to know the account’s password.

“Bro What”

The incident caused alarm within the top-gg community (which boasts over 170K members), as users alerted “editor-syntax” on discord about the suspicious activities originating from their account. “editor-syntax” was quite shocked, to say the least, as he realized what had occurred through his GitHub account. It became evident that the malware had compromised multiple individuals, highlighting the scale and impact of the attack.

Interestingly, the attacker’s Typosquatting technique was so convincing that even a user on GitHub fell victim to it without realizing they were under attack. When the malicious domain, piphosted[.]org”, went down, the user opened an issue on one of the malicious repositories, complaining about it, not realizing it had been a host for malicious payloads.

Deep Dive into the Malicious Python Package

In addition to spreading the malware through malicious GitHub repositories, the attacker also utilized a malicious Python package called “yocolor” to further distribute the “colorama” package containing the malware. They employed the same typosquatting technique, hosting the malicious package on the domain “files[.]pypihosted[.]org” and using an identical name to the legitimate “colorama” package.

By manipulating the package installation process and exploiting the trust users place in the Python package ecosystem, the attacker ensured that the malicious “colorama” package would be installed whenever the malicious dependency was specified in the project’s requirements. This tactic allowed the attacker to bypass suspicions and infiltrate the systems of unsuspecting developers who relied on the integrity of the Python packaging system.

Stage 1

The first stage is where the unsuspected user downloads the malicious repo or package which contians the malicious dependency – “colorama” from the typosquatted domain, “files[.]pypihosted.org”.

Example of how the malicious code looks like within the ycolor package

Stage 2

The malicious “colorama” package contains code that is identical to the legitimate package, with the exception of a short snippet of additional malicious code. Initially, this code was located within the file “colorama/tests/__init__.py”, but the attacker later moved it to “colorama/init.py”, likely to ensure that the malicious code is executed more reliably. This code sets the stage for the subsequent phases of the attack.

The attacker employed a clever technique to hide the malicious payload within the code. They used a significant amount of whitespace to push the malicious code off-screen, requiring someone inspecting the package to scroll horizontally for an extended period before discovering the hidden malicious content. This technique aimed to make the malicious code less noticeable during a quick review of the package’s source files.

This code fetches and executes another piece of Python code from “hxxps[:]//pypihosted[.]org/version,” which installs necessary libraries and decrypts hard-coded data using the “fernet” library. The decrypted code then searches for a valid Python interpreter and executes yet another obfuscated code snippet saved in a temporary file.

Stage 3

The malware progresses further, fetching additional obfuscated Python code from another external link: hxxp[:]//162[.]248[.]100[.]217/inj, and executes it using “exec”.

Stage 4

Upon analysis, it’s clear that the attacker has put thought into obfuscating their code. Techniques such as the use of Chinese and Japanese character strings, zlib compression, and misleading variable names are just a few of the techniques employed to complicate the code’s analysis and comprehension.

The simplified code checks the compromised host’s operating system and selects a random folder and file name to host the final malicious Python code, which is retrieved from “hxxp[:]//162[.]248[.]100.217[:]80/grb.”

A persistence mechanism is also employed by the malware by modifying the Windows registry to create a new run key, which ensures that the malicious Python code is executed every time the system is rebooted. This allows the malware to maintain its presence on the compromised system even after a restart.

Stage 5 – No One Is Left Behind

The final stage of the malware, retrieved from the remote server, reveals the true extent of its data-stealing capabilities. It targets a wide range of popular software applications and steals sensitive information, some of which include:

Browser Data: The malware targets a wide range of web browsers, including Opera, Chrome, Brave, Vivaldi, Yandex, and Edge. It searches for specific directories associated with each

browser and attempts to steal sensitive data such as cookies, autofill information, browsing history, bookmarks, credit cards, and login credentials.

Discord Data: The code specifically targets Discord by searching for Discord-related directories and files. It attempts to locate and decrypt Discord tokens, which can be used to gain unauthorized access to the victim’s Discord account.

Cryptocurrency Wallets: The malware includes a list of cryptocurrency wallets that it aims to steal from the victim’s system. It searches for specific directories associated with each wallet and attempts to steal wallet-related files. The stolen wallet data is then compressed into ZIP files and uploaded to the attacker’s server.

Telegram Sessions: The malware also attempts to steal Telegram session data. It searches for Telegram-related directories and files, aiming to capture the victim’s session information. With access to Telegram sessions, the attacker could potentially gain unauthorized access to the victim’s Telegram account and communications.

Computer Files: The malware includes a file stealer component that searches for files with specific keywords in their names or extensions. It targets directories such as Desktop, Downloads, Documents, and Recent Files.

Instagram data: The malware attempts to steal sensitive information from the victim’s Instagram profile by leveraging the Instagram session token. The malware sends requests to the Instagram API using the stolen session token to retrieve various account details.

Further analysis of the final payload reveals that the malware also includes a keylogging component. It captures the victim’s keystrokes and saves them to a file, which is then uploaded to the attacker’s server. This capability allows the attacker to monitor and record the victim’s typed input, potentially exposing sensitive information such as passwords, personal messages, and financial details.

The stolen data is exfiltrated to the attacker’s server using various techniques. The code includes functions to upload files to anonymous file-sharing services like GoFile and Anonfiles. It also sends the stolen information to the attacker’s server using HTTP requests, along with unique identifiers like hardware ID or IP address to track the victim.

Conclusion

This campaign is a prime example of the sophisticated tactics employed by malicious actors to distribute malware through trusted platforms like PyPI and GitHub.

This incident highlights the importance of vigilance when installing packages and repositories even from trusted sources. It is crucial to thoroughly vet dependencies, monitor for suspicious network activity, and maintain robust security practices to mitigate the risk of falling victim to such attacks.

As the cybersecurity community continues to uncover and analyze these threats, collaboration and information sharing remain essential in the ongoing battle against malicious actors in the software supply chain.

We reported the abused domains to Cloudflare, and they have since been taken down.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.

Working together to keep the open source ecosystem safe.

Timeline

1. Nov 2022: Pypi User “felpes” added three packages to the Python Package Index (PyPI) that contained various forms of malicious code.
2. Feb 01, 2024: The domain pypihosted[.]org was registered by the attacker.
3. Mar 04, 2024: The GitHub account of a top.gg contributor was compromised, and the attacker used it to commit malicious code to the organization’s repository.
4. Mar 13, 2024: The attacker registered the domain pythanhosted.org, further expanding their typosquatting infrastructure.
5. Mar 05, 2024: The malicious package “yocolor” was published on PyPI, acting as a delivery mechanism for the malware.

List of Packages

IOC

• hxxps[:]//files[.]pythanhosted.org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.5.tar.gz
• hxxps[:]//files[.]pypihosted.org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.6.tar.gz
• hxxps://files[.]pypihosted[.]org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.3.tar.gz
• 162[.]248.101.215
• pypihosted.org/version
• 162[.]248.100.217
• 162.248.100.117
• 0C1873196DBD88280F4D5CF409B7B53674B3ED85F8A1A28ECE9CAF2F98A71207
• 35AC61C83B85F6DDCF8EC8747F44400399CE3A9986D355834B68630270E669FB
• C53B93BE72E700F7E0C8D5333ACD68F9DC5505FB5B71773CA9A8668B98A17BA8

• Sophisticated Supply chain attack: The Tornado Cash open source project was compromised with malicious JavaScript code inserted by a developer.
• Impact: Users who conducted transactions using the targeted Tornado Cash project through IPFS gateways were unknowingly impacted for a couple of months.
• Discovery: The compromise, discovered by Security researcher Gas404, marks the second major security issue for Tornado Cash within a year, emphasizing the importance of community vigilance in decentralized finance.
• Ongoing risks in decentralized finance: This incident highlights the persistent challenges in ensuring safety and trust in decentralized platforms.

What is Tornado Cash?

Tornado Cash is a decentralized privacy solution built on the Ethereum blockchain, offering users non-custodial and anonymous transactions. Functioning as a cryptocurrency mixer, it provides a mechanism to obfuscate the origins and destinations of digital asset transfers, enhancing user privacy and security. While Tornado Cash has faced scrutiny for its potential misuse in illicit activities, such as money laundering notably by entities like North Korean hackers, it remains an innovative tool in the realm of decentralized finance.

In 2022, The original Tornado Cash service encountered challenges due to U.S. government sanctions, impacting its usage among certain user demographics. Despite this setback, the project’s open-source codebase has fostered the emergence of new independent mixing services.

The Compromise of the Open Source Tornado Cash

Tornado Cash recently fell victim to a sophisticated attack. This attack was executed through a deceptive contribution by a developer, who secretly embedded malicious JavaScript code within the project’s user interface. This code was designed to covertly capture and send users’ private deposit notes to an unauthorized external server. Deposit notes in Tornado Cash act like private keys, crucial for accessing and managing funds within the service.

This exploit specifically targeted users accessing Tornado Cash through IPFS gateways, like ipfs.io and cf-ipfs.com. These gateways are used to enter the decentralized web where Tornado Cash operates. The malicious code was cleverly concealed within a governance proposal by the developer, making it very challenging for an average user to detect.

The code worked by encoding these private deposit notes and sending them to the exploiter’s server under the guise of routine function calls. This meant that whenever a user engaged with certain functions of Tornado Cash, their private information was leaked without their knowledge.

The discovery of this malicious code was credited to a security researcher known as Gas404, and according to their findings, all Tornado Cash servers deployed on the IPFS network since January 1 of this year were believed to be impacted.

In the aftermath of the sanctions imposed on Tornado Cash, the original website of the service was seized. However, the open-source codebase of Tornado Cash continued to exist independently, leading to the emergence of new, shadowy mixing services using the same foundation. This incident of backdoor code implantation marks the second major security breach that Tornado Cash has endured over the past year, with a previous instance in May of the previous year where a hacker briefly seized control of the project’s governance.

In terms of the impact, the exact extent of the funds compromised in this latest breach still remains uncertain.

Conclusion

The Tornado Cash open-source project compromise highlights serious concerns about the safety of decentralized finance platforms and the trustworthiness of developers. It serves as a stark reminder that we cannot simply assume open-source projects are immune from malicious activities. The notion that “someone else is checking” can often lead to a false sense of security. Importantly, this incident illustrates how attackers like to leverage supply chain attacks to compromise sensitive applications and networks. It underscores the importance of thorough security audits, vetting of code and contributions, even from seemingly trustworthy sources, and the need to protect against supply chain vulnerabilities. For users, it’s a reminder to be vigilant about the platforms they use and to understand the associated risks. Clearly, preserving security and trust in decentralized platforms remains a challenging but vital task.

There has been a recent uptick in leaks, most notably Mercedes-Benz and Football Australia, who found themselves as victims in incidents that highlight the need for robust data protection strategies. 

The Mercedes-Benz Source Code Exposure

Mercedes-Benz faced a significant breach when an employee inadvertently published a private authentication token on a public GitHub repository, granting unfettered access to the company’s source code. This error was discovered by RedHunt Labs during a routine scan in January, revealing that the exposed token provided complete access to Mercedes’s GitHub Enterprise Server. This access level meant that anyone with the token could download private repositories containing sensitive data, including intellectual property, cloud access keys for Microsoft Azure and Amazon Web Services (AWS), database connection strings, and other critical internal information.

The Incident at Football Australia

Cybernews researchers reported a significant data leak at Football Australia, where personal information of Australian soccer players (including passports and contracts), as well as customer purchase details, were exposed online. The security breach lasted for at least 681 days and could potentially impact many local customers, with over 100 buckets of data exposed. The exposed data poses a severe threat, with potential for identity theft and fraud.

This cybersecurity incident, attributed to human error, resulted from a leak of secrets from plain-text Amazon Web Services (AWS) keys. This allowed public access to 127 digital storage containers containing sensitive data. 

Sample of the exposed data. Image by Cybernews.

Lessons Learned

These incidents serve as potent reminders of the vulnerabilities inherent in digital infrastructures across all sectors. They highlight the need for:

• Enhanced Secret Management: Employing tools and practices that ensure the secure handling of keys and tokens is non-negotiable.
• Regular Security Audits: Proactively scanning for vulnerabilities and exposures can prevent potential breaches.
• Education and Awareness: Human error being a common factor in both cases, underscores the importance of continuous education on best practices for all personnel involved in handling sensitive information.
• Incident Response Planning: Both organizations acted swiftly upon discovery, a testament to the importance of having an effective incident response strategy in place.

The cybersecurity incidents faced by Football Australia and Mercedes-Benz illuminate the critical need for heightened security measures and vigilant management of digital assets. Let these stories be a rallying cry for a unified approach to protecting our digital world—from the pitch to the pavement.

Maintaining the Sanctity of Secrets

To avert the leakage of secrets, consider implementing these strategies:

1. Environment Variables for Secrets: Store secrets in environment variables rather than embedding them directly in code to facilitate easier management and prevent their accidental inclusion in version control.
2. .gitignore for Sensitive Files: Utilize a .gitignore file to exclude files containing secrets from Git tracking. This ensures that these details do not inadvertently enter version control systems. If using environment variables for secrets, ensure their associated files are also ignored.
3. Secrets Management Tools: Employ secrets management tools for the secure handling and storage of system or application secrets. This guarantees encryption and access solely to authorized individuals.
4. Encryption of Secrets: Encrypt secrets prior to their storage in code repositories to add a security layer, making it challenging for attackers to obtain sensitive information.
5. Two-Factor Authentication (2FA): Activate 2FA for access to code repositories, enhancing security and complicating unauthorized repository access efforts.

These practices can significantly mitigate the risk of inadvertently exposing sensitive information across various platforms, including code repositories, content management systems, emails, and other digital assets not contained within a repository.

Preventing secrets from leaking on external tools with Secrets Detection by Checkmarx

Secrets Detection integrates and expands deeper scanning capabilities of Too many secrets 2MS, a command line tool written in Go language and built over gitleaks, directly into Checkmarx One. 2MS is one of the most popular open-source tools for secret detection, with over 2 million downloads. Secrets Detection in Checkmarx One finds secrets such as login credentials, API keys, SSH keys and more hidden in code, content systems, chat applications and more.

• Supported tools include Confluence, Discord, filesystem, git, paligo, Slack, Git Hooks, GitHub Actions
• Scan history to ensure secrets are not leaked in any previous versions   
• Detect secrets that are specific to your company with secret customization 

Learn more about reducing the risk of leaked secrets across the supply chain

Key points:

• Attackers are ingeniously stitching together diverse tactics, crafting a spectrum of threats that don’t fit into a single category and require multi-faceted counterstrategies.
• Deceptive maneuvers, exemplified by social engineering and bogus contributions, have become a staple in attackers’ arsenals, underscoring the weaponization of trust and authenticity in digital spaces.
• Abandoned digital assets are not relics of the past; they are ticking time bombs and attackers have been increasingly taking advantage of them, transforming them into trojan horses within the open-source ecosystems.
• The threat landscape’s relentless evolution emphasizes the imperative of predictive threat modeling, a strategy that combines foresight with robust defense mechanisms to anticipate and neutralize emergent attack methods.

Social media as a launchpad

Adversaries have been increasingly leveraging social media platforms for networking and professional collaboration to create fake profiles or impersonate legitimate entities and capitalize on the inherent trust within social circles to push malicious packages. The phenomenon signifies a broader tactical shift: the weaponization of trust and familiarity becomes a gateway to compromise. 

A recent example includes the nation-state actor, Lazarus, which conducted a highly targeted campaign on the blockchain and cryptocurrency sectors. They used social engineering and false developer reputations to trick victims into using malicious open-source packages.

Attackers are also using platforms like GitHub to deceive their targets with fake Proof of Concepts (PoCs). These tactics involve reusing older PoC codes to craft misleading scripts for recently disclosed vulnerabilities. Unsuspecting security researchers or cybercriminals seeking legitimate vulnerability demonstrations can easily be misled by these fraudulent PoCs.

Multi-package tactics and selective droppers

The growing sophistication of attackers is also demonstrated through the orchestrated use of multiple packages. By splitting malicious actions across multiple packages, the attackers make each package (in isolation) appear less suspicious. The malicious intent then becomes obscured, and is only truly unveiled when all the pieces, or packages, are interlinked and operational. This strategy artfully evades detection, as an investigator examining a single package may overlook or underestimate its true potential for harm.

 The Lazarus group implemented this tactic in their recent assault campaign. In this instance, the malicious packages were designed to function in pairs and in a sequential manner. Each pair of malicious packages was published from a separate NPM user account.

The targeted user would receive these NPM packages set to execute upon installation. Once activated, the first package would create a directory, fetch updates from a remote server, and store them in a file. The second package would read a token from this file, send a request to a specific URL with this token, write the response to another file, and then execute that file as a Node.js script.

Further deepening the complexity of such attacks are “selective droppers”. These are advanced mechanisms which, upon execution, determine the environment they’re in and decide whether to deploy their malicious payload or remain dormant. By doing so, they can avoid environments that might be sandboxes or traps set up by security researchers, ensuring their actions are reserved for genuine targets. This selective approach not only evades common detection strategies, but also exemplifies the extent to which cyber adversaries are refining their tools to outwit and outmaneuver modern defenses.

The masquerade of commits: doppelgänger contributors

Equally unsettling is the rise of commit fraud, where cybercriminals have been sighted for the first time this year, mimicking authentic and highly reputable contributors. By pushing fake commits, on behalf of these contributors they create an aura of legitimacy while embedding their malicious code. These maneuvers are particularly insidious as they target the foundational trust and collaborative spirit within open-source communities. It becomes imperative for project maintainers to employ rigorous validation protocols, ensuring contributors are who they claim to be, and all commits undergo meticulous scrutiny.

You can learn here more about how exactly attackers were able to recently spoof commits appearing to be from GitHub’s Dependabot:

Surprise: When Dependabot Contributes Malicious Code

Digital grave robbing

One of the more alarming methods attackers are employing is the takeover of neglected digital assets. From forsaken RubyGem packages to abandoned AWS buckets, what is discarded is not always forgotten. These opportunistic attackers revive these assets, inject malicious code and transformthem into unsuspecting delivery mechanisms for malware. This strategic revival of digital assets underscores the importance of robust digital asset lifecycle management and continuous inventorying and monitoring.

Hybrid threats

Attackers continually strive for obscurity, increasingly intertwining tactics to make detecting malicious packages more challenging. A prime example is the recent supply chain attack targeting Telegram, AWS, and Alibaba Cloud users. In this incident, the attackers exploited a simple human error – misspelled package names and reliance on star ratings – for deceit (Typosquatting combined with Starjacking). They further complicated detection by camouflaging malicious code within the package functions instead of common auto-install scripts. This method bypasses traditional detection mechanisms, making the packages more challenging to detect. By incorporating their malicious code into these functions, routine actions unexpectedly trigger harmful outcomes. This manipulation not only breaches trust but also weaponizes routine. To understand this tactic, we must dissect regular operations, which calls for advanced defensive strategies. These strategies should combine automated tools with human oversight to detect anomalies and counter these hybrid threats.

Combination of Starjacking, Typosquatting, and hiding code within routine function

Beyond the horizon: forecasting threat evolution

The realm of cyber threats is not stagnant. It is continuously morphing and forging new paths of disruption. Current strategies can quickly become outdated, making it vital for defenders to act as both strategists and visionaries. This dual role demands a proactive approach, where possible attack paths are anticipated and neutralized before they occur. Just like in chess where the players need to anticipate moves several steps ahead to avoid being checkmated.

Conclusion

Although the number of supply chain attacks has been on the rise, what is more concerning is the level of sophistication of these attacks. The landscape of cyber threats, especially within software supply chains, continues to morph, mirroring the dark creativity of adversaries. Threat actors have become architects of confusion and deception, exploiting trust, familiarity, and the slightest oversight to infiltrate systems and cause damage.

The fight against these threats sprawls beyond the confines of our infrastructural perimeters, encompassing every part of our digital interactions – from the smartphones in our pockets to vast global networks. 

Investing in collaborative forecasting, strengthening intelligence sharing, and maintaining a fluid defensive posture are the keystones upon which the cybersecurity community must build.

Let’s keep working together to keep the cyber-ecosystem safe.

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”.