Why open-source software supply chain attacks have tripled in a year

The number of incidents where malicious packages are uploaded to public component registries has exploded over the past year, showing that attackers increasingly favor this initial access tactic. According to data from software supply chain management company Sonatype, the number of malicious packages detected across the various open-source ecosystems tripled year over year.

“Looking at it a different way, it also indicates that in one year alone, we’ve seen twice as many supply chain attacks to the cumulative numbers in previous years,” Sonatype said in its annual State of the Software Supply Chain report. “This pace of growth is astonishing. It signals the role of the supply chain as one of the fastest growing vectors for adversaries to execute malicious code. Furthermore, we have seen an increase in nation-state actors leveraging these vectors.”

However, an organization’s software supply chain concerns shouldn’t stop with the 245,032 malicious packages that were detected over the past 12 months but include the millions of packages that have known security vulnerabilities. According to Sonatype, one in every eight open-source component downloads over the past year had a known security risk.

More measures against malicious open-source packages needed

Many of the package repositories for open-source languages are community-maintained, meaning the reporting and removal of malicious packages happen on a voluntary basis and not often the result of automated detection. Improvements have been made in preventing existing developer accounts from being hijacked and used to push malicious components – such as the introduction of mandatory multifactor authentication – but this doesn’t stop the attacks that upload rogue packages from new accounts.

“Often, packages containing malicious code are treated very similarly to packages with new security vulnerabilities — and they are taken down entirely based on a volunteer effort following a vulnerability removal process which is not appropriate when the code is designed to be malicious from the start,” the Sonatype researchers said. “This approach can lead to the malicious packages being up longer than necessary, leaving developers at risk.”

Compared to previous years, the researchers have noticed an adoption of this supply chain attack tactic by more professional criminal gangs and even cyberespionage groups. One recent example occurred in August when the Lazarus Group, one of North Korea’s state-funded hacking groups, uploaded a malicious package VMConnect to PyPI, the public registry for Python components. The package masqueraded as a legitimate VMware module and downloaded additional malicious payloads when installed on a system.

Developers continue to download risky open-source packages

The task of mitigating the threat posed by both malicious and vulnerable packages should fall to the consumers of packages as well, not just with the repository managers. Unfortunately, data shows that users continue to download risky packages at high rates.

According to Sonatype’s data collected from its software supply chain management tools as well as from the Maven repository for Java components which the company runs, 12% of component downloads in 2022 and 10% in 2023 were for versions with a known vulnerability. Over a third of those had a critical vulnerability and another 30% had a high severity flaw. What’s more alarming is that 96% of those vulnerable downloads could have been avoided as the consumed components had updated versions available that did not have vulnerabilities.

“The increase of critically vulnerable components being consumed could be due to the fact that these vulnerabilities are found and reported primarily in more popular and widely adopted open-source software,” the Sonatype researchers said. “Popularity begets more attention from good and bad actors, resulting in increased likelihood of a critical issue being present. It’s also worth noting that these more popular components have an official disclosure process to communicate through. Meaning, on average, these critical vulnerabilities should be the ones that are most noticed. But, as we’ve seen with the vulnerable version of Log4j, ‘knowing’ is only half the batter. Organizations have to care, and they have to have an automated way to address this issue.”

Open-source maintenance quality is uneven, dropping

Component developers must do their part too to respond to reports and patch flaws as quickly as possible, and the quality of this process varies widely across the ecosystem. In fact, Sonatype has seen an increase in the number of projects that are no longer being maintained by their creators.

In 2020, the Open Source Security Foundation (OpenSSF) released a new system of scoring projects, called Scorecard, based on their adoption of security best practices. According to the data, over 24,000 projects that were listed as maintained in 2021 across the Java and JavaScript ecosystems no longer qualified as maintained in 2022 based on commit and issue tracking activity.

Another important metric that is tracked is called “code review” and refers to the practice of reviewing pull requests before committing them to the project. This is the practice most highly associated with good security outcomes, according to Sonatype, and it’s not widely adopted. In fact, over the past year the number of projects that used code review decreased by 15% overall, and by 8% when counting only projects that qualify as maintained.

“The fact that 18.6% of projects stopped being maintained in the last year highlights the need to not only choose good dependencies, but monitor those dependencies for changes in their quality,” the Sonatype researchers said. “The overall low rates of code review, even when considering just maintained projects, provide a clear area for improvement in open-source development practices – especially given the importance of code review in predicting security status.”

“Based on our findings, enterprises looking to minimize their open-source vulnerability risk should choose well-maintained projects that perform code review and monitor them to ensure they have not reached end-of-life,” the researchers concluded.

Cyberattacks, Malware, Open Source

Go to Source