devopsy.kinsta.cloud

Tag: sonatype

Report Shines Spotlight on 91 Vulnerabilities Fixed in Latest Update to Spring Framework

A report published by Sonatype identifies more than 91 vulnerabilities that have been remediated in the latest update to the open source Spring framework for deploying Java applications mashed available by Broadcom earlier this month.

Released earlier this month, the 91 vulnerabilities affect 209,569 software components that will need to be updated.

Sonatype CTO Brian Fox said this large number of vulnerabilities that are being simultaneously released is another indication the providers of major software platforms are racing to pay down massive amounts of technical debt before vulnerabilities are discovered and exploited by cybercriminals that are gaining access to advanced artificial intelligence (AI) models.

Providers of platforms such as Spring already have access to those same AI models, which has given them a head start to find and remediate vulnerabilities before adversaries exploit them. In fact, Broadcom between March and April increased the number of advisories it has issued by more than 1,700%, according to the Sonatype report.

DevSecOps teams, in the meantime, are being tasked with making often simultaneous large-scale updates to multiple frameworks and platforms as providers rush to pay down technical debt that has been allowed to accrue for decades, noted Fox. Those teams, as a result, will need to find ways to automate the deployment of what will be a wave of patches that will need to be installed as quickly as possible. In many instances, DevSecOps teams will find they will be coping with tidal waves of updates to frameworks and platforms for multiple years to come, noted Fox.

Eventually, however, there can only be so many issues to fix, so following those waves of updates, the overall state of application security should substantially improve, he added. In the meantime, however, instead of applying patches to applications a couple of days a month, DevSecOps teams for the foreseeable future may find that they now need to continuously update applications, said Fox.

The challenge, of course, is that today exploits in many cases are being built faster than a patch can be created and applied. Adversaries are also becoming more adept at using AI to chain together low-level vulnerabilities to create a more lethal exploit. As such, DevSecOps teams are likely going to need to be able to apply virtual patches and other controls to mitigate threats while waiting for patches that, with the aid of AI coding tools, will now be made available much faster.

The proverbial fly in that ointment is that many of the maintainers of smaller open-source software projects that an application may depend on may not be able to keep pace. Multiple initiatives have been launched to aid those maintainers; however, many of those projects were created by a volunteer labor force that might not have the time, resources, or inclination to build, test and apply a software patch in a matter of days or, if needed, hours. Many enterprise IT organizations may need to rationalize the amount of open source software they have deployed because, as an unpaid labor force to keep pace with building, testing and applying patches is silly on its face, noted Fox.

At this juncture, it may not be possible to fix every application before it is exploited. Hopefully, however, organizations will be able to prioritize making updates to their most critical applications to, at the very least, limit the potential havoc that otherwise will most certainly soon ensue.

August 25, 2026
‘Flooding Dropper’ Is Hitting npm With a Tidal Wave of Malicious Packages

Threat researchers at Sonatype are warning developers of an expanding campaign that is generating a wide range of npm accounts and dropping small numbers of malicious packages from each one, essentially flooding the zone with a broadly distributed and automated campaign to make it difficult for defenders to keep up.

So far, the campaign – dubbed “Flooding Dropper” – has affected almost 850 software components and comes with a package naming convention that initially contained terms such as “bigops” and “bnpl,” as seen in bigops-api and dolyame-boxy-desktop-bnpl-card-gallery. However, even that is evolving, with researchers seeing packages being created with other names.

Overall, the nature of the campaign showcases growing trends of threat actors turning the publication of malicious packages into a more scalable operation and using open source malware in distributed and automated campaigns – rather than individual packages – to overwhelm registry moderation and blocklists.

“Publishing malicious packages at scale is not new,” the researchers wrote in a report. “Distributing them across many disposable accounts makes containment harder. The Flooding Dropper threat actors are using account names that appear randomly generated, and individual accounts publish only a handful of packages. That prevents defenders from assuming that removing one prolific publisher will eliminate the broader operation.”

More Pressure on npm

For npm, the campaign creates a moderation problem, they added, noting that “each account and package may need to be identified, reviewed, and removed independently while the attacker continues generating more.” It adds even more pressure to the code repository, which Sonatype noted in its Q2 2026 Open Source Malware Index accounted for 96.6% of malicious package counts during the quarter. Sonatype has logged more than 1.8 million malicious packages across ecosystems over the past decade.

The team at OpenSourceMalware, a community-driven threat intelligence platform and database, this week reported on a malicious npm package with the name “bigops-backend” that delivered a binary specific to Windows, Linux, and macOS systems. However, Jorge Cardona, a security researcher with Sonatype Research Labs, found that the package was part of a larger campaign.

Making Detection Harder

Sonatype researchers, who are tracking the campaign under the sonatype-2026-005660 identifier, wrote that the packages all deliver the same behaviors, but the evolving naming pattern and slightly modified payloads – including variable names and different URL functions – “can reduce the effectiveness of detections that depend on exact signatures, even when the underlying behavior remains closely related.”

The malicious code in the packages runs when they’re installed or imported.

The First Stage

The first stage involves a JavaScript-based cross-platform loader with various delivery paths. It checks the environment to see if it should run, identifies the host OS and processor before deciding on the Windows, Linux, or macOS payload, and then tries to download the binary from a set of remote hosts.

If the direct HTTPS downloads fail, it will fall back to DNS TXT records, reassembling and decoding the DNS-delivered payload, writing the binary to a temporary directory and marking it “executable” on Unix-like systems, and launching it as a detached background process with output suppressed.

The researchers wrote that launching the payload in a detached process is a failsafe, as stopping the npm installation process or parent Node.js process doesn’t lead to stopping the attack because the binary can still run independently in the background.

“The DNS fallback is also significant,” they wrote. “Blocking one download host may not prevent delivery when the malware can reconstruct the payload from TXT-record responses.”

The Second Stage

In evaluating the second stage, the researchers noted the Windows binary is also a loader for another payload that searches for capabilities that could interfere with monitoring and scanning, checks for virtual machines, sandboxes, and security tools, copies itself to a persistent location under the user’s AppData directory, and establishes persistence via a Registry Run key as well as a scheduled task.

It also downloads an encrypted payload, decrypts it, and reflectively executes it in memory. The reflective loading enables the malware to execute a payload without the normal process of writing and launching a conventional executable from disk, making it more difficult for disk-focused controls to detect.

Don’t Rely on Naming Conventions

Sonatype warned developers not to rely on the bigops and bnpl names as the only indicators of threats associated with the Flooding Dropper campaign.

“Attackers can change names more easily than they can change the purpose of their malware,” the researchers wrote. “The same is true of minor source-code modifications intended to avoid exact signature matches. A blocklist of known names can help with yesterday’s packages; behavioral and similarity analysis are what help find tomorrow’s variation.”

They laid out a range of steps that infected organizations need to take, including assuming that the host is compromised, removing the package, investigating secondary payload execution and persistence, and rotating exposed credentials after the environment has been cleaned.

August 7, 2026
Bad Actor Drops 36 Malicious Packages in npm, Targets Guardarian Users

The npm code repository is again being used by a bad actor to launch a supply chain attack that includes three dozen malicious packages that appear as Strapi CMS plugins but deliver a range of threats.

Strapi is a popular open source headless Node.js content management system developers use to build, manage, and expose content through REST or GraphQL APIs while using a range of front-end frameworks, like React, Next.js, and Vue. Capabilities that make it attractive include a customizable administrator panel and flexibility in databases developers can use.

According to researchers with cybersecurity vendor SafeDep, the 36 malicious packages were published using four npm accounts, with varying numbers of packages in each account.

“Contrary to what you might expect from a package-spam campaign, the analyzed packages carry different payloads — eight distinct variants in total — revealing a real-time attack development session against a specific target,” researchers with cybersecurity vendor SafeDep wrote in a report. “This campaign is a rare window into an attacker’s real-time development process. Over 13 hours, the operator published ten packages with eight distinct payloads, each iteration responding to what was likely working (or not) against their target.”

Multiple Threats

The payloads carry a range of threats with them, from Redis remote code execution (RCE) and PostgreSQL exploitation to Docker and Kubernetes container escape, credential harvesting – such as passwords, SSH private keys, and cryptocurrency wallet information – persistence, and Python reverse shell deployment.

“Every package contains three files (package.json, index.js, postinstall.js), has no description, repository, or homepage, and uses version 3.6.8 to appear as a mature Strapi v3 community plugin,” the researchers wrote. “The package names follow the naming convention used by legitimate packages like strapi-plugin-comments or strapi-plugin-upload. All official Strapi plugins are scoped under @strapi/, making these unscoped names a social engineering choice targeting developers searching for community plugins.”

The attacker’s malicious code is found in the postinstall file script, which is different for each package. It is executed on “npm install” through the postinstall script, without any interaction from the user being needed. It includes the privileges for the installing user, which in CI/CD environments and Docker containers means root access.

Guardarian is the Target

The campaign appears to target Guardarian, a European Union-based cryptocurrency gateway that allows users to buy, sell, and swipe more than 1,000 cryptocurrencies. From the first payload onward, Guardarian references are found.

This confirmed that “this was a targeted campaign against a cryptocurrency payment platform from the very beginning — not an opportunistic spray that became targeted over time,” they wrote. “The hardcoded database password in Payload 6 proves this is not the attacker’s first interaction with the target’s infrastructure.”

Multiple Packages Over 13 Hours

The SafeDep researchers were able to track the packages published over a 13-hour period. The first hour involved the two payloads that came with Redis RCE exploitation, with crontab injection, SSH key injection, and other capabilities.

That was followed over the intervening hours by payloads with simplified direct reverse shells and then reconnaissance to collect credentials and secrets for future use, direct database exploitation using hardcoded PostgreSQL credentials to grab Strapi data, probing for Guardarian payment.

Hours 10 through 13 were focused on persistent access, with the bad actor switching to a second npm account and deploying persistent implants and armed with the target’s hostname, CI/CD pipeline, and secrets directory layout.

“The eight payloads show a clear narrative: the attacker started aggressive (Redis RCE, Docker escape), found those approaches weren’t working, pivoted to reconnaissance and data collection, used hardcoded credentials for direct database access, and finally settled on persistent access with targeted credential theft,” they wrote.

Rotate Credentials

Developers who installed any of the malicious packages need to assume they’ve been compromised and rotate credentials – database passwords, API keys, JWT secrets, and private keys, among others — that are stored on their system.

The campaign is only the latest in a growing trend of dropping malicious packages into code repositories to initiate supply chain attacks. Sonatype researchers wrote that throughout last year, they identified more than 454,600 such malicious packages, bringing the total of known and blocked malware to more than 1.233 million packages not only in npm but also PyPI, Maven Central, NuGet, and Hugging Face.

“This year, we observed that the evolution of open source malware crystallized, evolving from spam and stunts into sustained, industrialized campaigns against the people and tooling that build software,” they wrote, adding that both the scale and sophistication of the threat grew in 2025.

More than 99% of open source malware last year was found on npm. State-linked threat actors like North Korea’s Lazarus Group was able to plant five-stage payload chains that included droppers, credential theft, and persistent remote access, while Shai-Hulud “proved that open source malware can now propagate autonomously through open source ecosystems,” they wrote.

April 6, 2026
North Korean Hackers Suspected in Supply Chain Attack on Popular Axios Project

North Korean hackers are accused of hijacking the npm account of an axios maintainer, a highly popular and widely used JavaScript HTTP client library, in the latest in a growing number of sophisticated attacks targeting open-source software developers.

For a brief few hours running from late March 30 into early March 31, the bad actors were able to hijack the npm account of the primary axios maintainer and publish two new malicious versions – “axios@1.14.1” and “axios@0.30.4” – that introduced a hidden runtime dependency, plain-crypto-js@4.2.1.

When a developer or CI/CD pipeline ran the npm install, the dependency installed a remote access trojan (RAT) that contacted a command-and-control (C2) server and dropped secondary payloads targeting macOS, Windows, and Linux systems, according to researchers for StepSecurity, one of several security vendors that analyzed the attack.

The RAT is capable of a range of threats, from running arbitrary commands to exfiltrating system data to establishing persistence on infected machines, according to Socket researchers. After executing, the malware automatically deleted itself, covering its tracks to make detection more difficult.

Broad Blast Radius

The broad adoption of axios, which offers a simple and feature-rich way to manage HTTP requests in browser-based and Node.js environments, in the industry is a significant factor in the attack. The library is downloaded more than 100 million times a week, it’s used in web applications, APIs, React Native mobile apps, serverless functions, CI/CD automation pipelines, and developer workstations, and is a transitive dependency in thousands of other packages, “meaning your organization may be using it even if no developer explicitly installed it,” SOCRadar researchers wrote.

“The blast radius of yesterday’s Axios npm supply chain attack is broad and extends to other popular packages that have dependencies on it,” Charles Carmakal, CTO of Google’s Mandiant business, wrote on LinkedIn. “Enterprises should assess the impact today.”

Austin Larsen, principal threat analyst for Google Threat Intelligence Group (GTIG), urged organizations to check if they’ve been compromised, writing that “if your environment recently pulled axios@1.14.1 or axios@0.30.4, you may have executed a backdoor payload via the malicious plain-crypto-js dependency.”

A Sophisticated Attack

Security researchers describe an attack that was meticulously planned and launched. The hackers compromised the npm account of Jason Saayman, the primary axios maintainer, and changed the account’s email to a ProtonMail address they controlled. That made it difficult for other Axios collaborators to stop the attack.

“When the attack first happened, Axios maintainers were unable to regain control of the project,” Socket researchers wrote. “In a public GitHub issue, a collaborator stated they could not revoke access from the account responsible for the malicious publish, noting that the attacker’s permissions exceed their own.”

StepSecurity analysts wrote that “there are zero lines of malicious code inside axios itself, and that’s exactly what makes this attack so dangerous. … This was not opportunistic. It was precision. The malicious dependency was staged 18 hours in advance.”

Pre-Built Payloads

They noted the three payloads were pre-built for the three operating systems, both release branches were poisoned within 39 minutes of each other, and that every artifact in the attack was able to self-destruct.

“Within two seconds of npm install, the malware was already calling home to the attacker’s server before npm had even finished resolving dependencies,” they wrote. “This is among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package.”

GTIG Points to North Korean Actor

Initial threat intelligence reports said the attack was pulled off by an unknown threat actor. However, GTIG analysts later attributed it to a North Korean group they track as UNC1069.

“North Korean hackers have deep experience with supply chain attacks, which they’ve historically used to steal cryptocurrency,” GTIG Chief Analyst John Hultquist wrote. “The full breadth of this incident is still unclear, but given the popularity of the compromised package, we expect it will have far-reaching impacts.”

Hultquist added that the attacks were not related to a series of supply chain attacks by Team PCP targeting developers that has been expanding over the last few weeks.

Popular Doesn’t Mean Trustworthy

Ilkka Turunen, field CTO at DevSecOps firm Sonatype, said the attack shows that bad actors “don’t need to compromise the code people trust if they can compromise the trust around it. In this case, the malicious capability was introduced through a staged dependency and designed to erase its own tracks, which made the attack harder to spot and slower to understand.”

Turunen noted how little visible change was needed to create significant downstream risk.

“When a widely trusted package can be turned into a delivery path like this, the issue is bigger than package hygiene,” he said. “It’s a trust problem in the software supply chain, and it’s why organizations need security controls that look at what’s actually being installed, not just what appears safe at first glance.”

Nigel Douglas, head of developer relations at Cloudsmith, a managed cloud-native artifact repository, said that developers need to understand that “you can’t treat popularity as a proxy for trustworthiness. Just because a package has over 100 million weekly downloads, that doesn’t mean it can be trusted by default, and – in fact – that might just make it a bigger target. The software supply chain relies on the hard work of open-source maintainers, but they can’t be everywhere, and upstream repositories like npm are always a high-value target for attackers.”

April 1, 2026
Two Malicious npm Packages Aim to Steal Credentials and Other Secrets

Bad actors took over a npm maintainer account and have published two malicious packages designed to steal credentials, API keys, and other secrets from the computers of victims who download them from the repository.

Analysts with Sonatype’s Security Research Team wrote in a report that the two packages – sbx-mask and touch-adv – likely are more than test packages, with the attackers hijacking the publisher account to take advantage of the trust maintainers build with developers to steal valuable information, in this case, secrets that can include credentials, certificates, or API keys.

Sonatype is tracking the packages under Sonatype-2026-001276 and Sonatype-2026-001275, adding that the malware campaign is still active and under investigation. The attacks haven’t been attributed to a threat actor yet. Sonatype reported the packages this week to npm.

The malicious packages are only the latest examples of a rising trend of bad actors targeting open code repositories, not only npm but GitHub and others.

As Penta Security noted in January, “attackers often create repositories that appear to be legitimate projects and distribute malicious files alongside normal code, or they secretly insert malicious code into existing open source projects to target developers. The fundamental problem is that it is extremely difficult to block these attacks completely at the software level.”

Aikido Security, which offers an app security platform, wrote this month about a mass campaign being run in March by a threat actor known as Glassworm across open code repositories.

Fighting Back

Organizations appear to be pushing back at the rising tide of such software supply chain attacks, with a recent Futurum Group survey finding that 39% of those surveyed expect to increase spending on software security testing, followed by additional investments in securing APIs.

In the recent software supply chain campaign detected by Sonatype, the attackers’ reliance on trusted maintainer accounts rather than creating new packages or posing as popular libraries is one aspect that makes the threat stand out.

“The attackers appear to have taken control of accounts with established credibility in the npm ecosystem,” the analysts wrote. “This dramatically increases the likelihood that developers will install affected packages without suspicion. Additionally, the attackers employed multiple exfiltration techniques, including both webhook-based collection and direct email transmission. This dual approach increases the resilience of the campaign and suggests a level of planning beyond opportunistic attacks.”

They also noted the timing of the publication of the package, writing that multiple malicious versions popped up in a narrow window of time, which indicates that the exploitation was automated or access to multiple accounts was coordinated.

Going Deeper into Packages

According to the report, the sbx-mask package runs automatically through a post-install script to immediately execute its payload, which increases the likelihood of fast credential exposure, the analysts wrote.

For its part, touch-adv does not automatically execute, but rather when the application code is invoked, though not on install. It reads TRACE_ID, collects and formats environment variables, and then sends the exfiltrated data via a POST request to an email address, ethan@vm0.ai via agentmail.

“This distinction is notable,” the analysts wrote. “Rather than relying solely on install-time execution, attackers are increasingly embedding malicious code deeper within npm packages to evade detection. By delaying execution until runtime, these techniques make the malware less obvious during standard dependency inspection.”

Harvesting and Exfiltrating Data

The payload is embedded within application code, which executes either during installation or when the package is imported into an application. The malicious script then runs a series of actions that harvest and exfiltrate sensitive data. This data includes environment variables from the host’s system, sensitive credentials like API keys, authentication tokens, and cloud service secrets.

Once collected, the data is transmitted to endpoints controlled by the attacks, such as webhook services and hard-coded email addresses, in this case, ethan@vm0.ai via agentmail.

“Because environment variables are widely used to manage secrets in development and production environments, this type of attack can lead to serious downstream compromise,” they wrote. “Exposed credentials may enable attackers to access cloud infrastructure, manipulate CI/CD pipelines, or move laterally across systems within an organization.”

Targeting Developers

Developers and organizations that rely on npm packages as part of their software development lifecycle (SDLC) are the primary targets of the campaign, according to Sonatype. The high-risk targets include CI/CD pipelines and automated build systems, cloud-based deployment environments, and local developer machines with access to credentials and tokens.

“In these contexts, a single compromised package installation can expose secrets that grant attackers access to broader infrastructure, increasing the potential for downstream compromise across an organization,” the analysts wrote.

If an organization downloaded one of the packages, they need to remove it immediately and rotate credentials that may have been exposed. They also need to review system and CI/CD logs for unusual activity, with an eye on outbound network requests that could indicate data that’s been stolen.

Overall, they also need to reduce their reliance on long-lived credentials, according to Sonatype.

March 23, 2026
Securing Open Source Components in a World of Mixed Committer Motivations

Our world runs on software that contains open source components. This places an increased burden on developers, as the primary consumers and deployers of those components, to use code that is fully up-to-date and secure. The vast majority of open source committers with write access to project repositories remain focused on maintaining and making positive improvements to that code, while also helping to benefit the open source community as a whole. However, the sheer complexity of many open source projects has opened the door to different, more insidious and concerted types of attacks which could cause widespread and serious harm.

Developers Have to Move Fast and Reuse Gives Them That Speed

One complicating factor is the prevalence of reuse of third-party open source elements across the majority of open source projects through two main types of dependencies. With direct dependencies, an open source component links straight to a third-party code library, while transitive dependencies occur when a component calls out to a library that is, in turn, communicating with another dependency.

Dependencies enable developers, under ever-increasing corporate pressure to deliver new software rapidly, to move faster by building on top of existing work by their peers. The downside is that those dependency foundations are vulnerable to attack, with some libraries perhaps under the aegis of a single committer for whom the code collection may be a side project and perhaps not attended to on a regular basis.

Sonatype research and that of other organizations tells us that developers working with a Java application may be dealing with a staggering 1,500 dependency changes every year, with the average Java application containing 148 dependencies and the average Java project being updated 10 times annually. While the number of open source projects isn’t ballooning, the amount of versions of those projects is skyrocketing. The majority of vulnerabilities today impacting open source projects result from transitive dependencies, the more complex type of dependency.

In an area where multiple projects may exist effectively solving the same issues, developers need to be aware of which projects are being actively maintained versus those that are either poorly nurtured or no longer in operation. On the other hand, successful open source projects may have tens or hundreds of committers with write repository access, which address a whole different set of issues, including reaching agreement on what a vulnerability consists of and how to fix or patch it.

Amid a Community for Good, Bad Actors and Incidents of Self-Sabotage Emerge

The reasons why individuals choose to commit to open source software are wide-ranging; a strong desire to give back to the community to a passionate and, perhaps very single-minded, hobby to an integral and paid part of a developer’s role and responsibilities at work. A few years ago, the concept of a malicious open source committer was an abstract theory. The thought back then was that perhaps a handful of ‘bad apples’ might exist within a community of millions of developers. However, since 2019, researchers’ tools and those of other organizations have identified over 100,000 malicious, suspicious or proof-of-concept packages, pointing to a much higher degree of behavior by cybercriminals.

Bad actors are deliberately taking advantage of the complexity of open source software to knowingly introduce exploitable vulnerabilities. These attacks are growing in sophistication particularly in relation to malicious code injections into the source code of an open source library. These attacks can often appear as harmless code changes and remain hidden before delivering a malware payload. There is the recent example of a crypto heist that stole over $3 million in cryptocurrency which leveraged compromised access to a private GitHub repository.

Protestware, where a code maintainer chooses to self-sabotage their open source project often to draw attention to a cause, whether geopolitical or specific to that individual, has become an issue over the past year. In this case, although the stated goal is not malicious hacking, real harm, in terms of major disruption, to developers using that code can occur.

To counter both the impact of bad actors and of self-sabotage on open source components, developers need to take advantage of release integrity features to help protect themselves and their organizations from harm. They must be able to have full visibility and control over the software they build and the open source components that they are sourcing as part of that development work. At the same time, governments around the world, including in the U.S., are weighing into issues related to the security of software supply chains, so increased regulations and penalties should also factor into how developers and their organizations behave moving forward.

We’re only one step away from the next potential Log4j attack, and every developer and organization needs to up their game and be ready to move fast on vulnerability identification and remediation. The gathering and sharing of data is what will help to increase everyone’s safety.

December 2, 2022
Sonatype Report Surfaces Scope of Known Vulnerability Challenge

Sonatype this week published a State of the Software Supply Chain Report that found a 633% year-over-year increase in malicious attacks aimed at open source software residing in public repositories.

In addition, Sonatype launched a Sonatype Safety Rating system that employs machine learning algorithms and other metrics to identify the most secure open source components stored in those repositories.

The report found 96% of open source Java downloads have known vulnerabilities that could have been avoided if an available, more secure version had been used. Collectively, the report estimated there were 1.2 billion known-vulnerable dependencies that could be avoided if developers had only been aware that a later version of a software component was available.

According to the report, the average Java application contains 148 dependencies. Updates to Java applications are, on average, made 10 times a year, so development teams are being asked to track 1,500 dependency changes per year.

Sonatype CTO Brian Fox said the report makes it clear that organizations are not assuming enough responsibility for using open source software that has known vulnerabilities. In effect, organizations are blindly and recklessly using software components without any real appreciation of the associated risks, he said.

Rather than a knee-jerk reaction to each new zero-day vulnerability that is discovered, Fox said, IT teams need to focus on putting processes in place to make sure the latest, most secure edition of any given software module is being used. A survey of 662 engineering professionals included with the report, however, found 68% of respondents were confident that their applications were not using known vulnerable libraries. Nevertheless, a random sample of enterprise applications conducted by Sonatype found 68% contained known vulnerabilities.

Overall, the report surmised that consumption of open source software will soon surge past an estimated 3.1 trillion total requests, with six out of every seven vulnerabilities being the result of a transitive dependency created by indirect relationships between software components. At the current rate of consumption, it’s fairly clear that the processes used to build and deploy applications today are insane given how dependent organizations are on applications, said Fox.

In the wake of a series of high-profile security breaches, there is, fortunately, a lot more focus on securing software supply chains today than there was this time last year. The scope of the challenge, however, is mind-boggling when you consider the totality of applications already deployed in application environments that have known vulnerabilities. Organizations need to first make sure they are remediating vulnerabilities in their most critical applications while at the same time implementing DevSecOps best practices. This will ensure as few vulnerabilities as possible find their way into the next generation of applications.

Obviously, these application security issues are not going to be resolved overnight. DevOps teams will be spending the next several years addressing a level of technical security debt that has been allowed to accrue for more years than anyone in IT really cares to admit.

October 19, 2022
Sonatype Report Shows Spike in Supply Chain Attacks

Sonatype today released a report that finds there has been a 650% year-over-year increase in supply chain attacks aimed at upstream public repositories. Cybercriminals hope to compromise these repositories by injecting malware into software components that many organizations might be using, according to the report.

The seventh annual State of the Software Supply Chain Report is based on an analysis of 100,000 applications and 4 million component migrations made in the last month alongside a survey of 702 software engineering professionals. Specifically, the report focuses on demand and security trends associated with the Java (Maven Central), JavaScript (npmjs), Python (PyPI) and .Net (nuget) ecosystems. The top four open source ecosystems now contain a combined 37,451,682 different versions of components, a nearly 20% increase year-over-year.

Over the course of 2021, developers also downloaded more than 2.2 trillion open source packages from the top four ecosystems, a 73% increase over the prior year.

However, despite the huge available supply of open source software, use of this software is primarily concentrated in a small number of popular projects. Production applications are only using 6% of available open source projects.

Not surprisingly, popular projects are more vulnerable to compromise. A total of 29% of popular project versions contain at least one known security vulnerability. Conversely, only 6.5% of projects that are not widely used have vulnerabilities.

Stephen Magill, vice president of product innovation for Sonatype, said popular open source projects tend to have better security practices in place because of the larger number of maintainers and contributors working on the project. The paradox is that less-popular open source software is not likely to be targeted by cybercriminals who tend to focus on targets that represent the best chance to infect downstream applications, said Magill. Popular open source projects were 2.8 times more likely to contain vulnerabilities, the report found.

Projects with a faster mean-time-to-update (MTTU) are also generally more secure. They are 1.8 times less likely to have vulnerabilities, the survey found.

The report also found developers make suboptimal choices 69% of the time when updating third-party dependencies, even when newer versions of projects are generally available. Developers may be avoiding those updates because they may be perceived to be not as stable as they would like. However, those updates generally contain the latest security patches needed to address a recently discovered vulnerability. Commercial engineering teams only manage 25% of the components they use, leaving the majority of their open source dependencies stale and susceptible to increased security risks, the report found.

Finally, the report suggested there is a greater need for automation. Equipped with intelligent automation, a medium-sized enterprise with 20 application development teams would save a total of 160 developer days a year. Sonatype estimated that could save organizations $192,000 a year.

In general, Magill noted that the security of software supply chains should continue to improve in the wake of an executive order issued by President Biden. In the meantime, however, most organizations would be well-advised to start reviewing the components and dependencies that make up their software supply chain sooner rather than later. After all, chances are good that cybercriminals are already doing much the same thing.

September 15, 2021
Sonatype Acquires MuseDev to Add Code Analysis

Sonatype today revealed it has acquired MuseDev, a provider of a code analysis tool, in addition to updating its Nexus platform for discovering vulnerabilities in software supply chains.

Muse analyzes code each time a pull request is made, which makes it easier for developers to discover and address issues long before they commit code. Muse is integrated with 24 pre-configured code analyzers for GitHub, GitLab and Bitbucket repositories. It then analyzes each pull request to surface bugs, as part of automated code review, and includes analysis of interprocedural information flow and thread safety issue analysis, along with guidance to fix any bugs discovered.

In addition to adding support for Muse, the latest edition of the Nexus platform integrates a container firewall from NueVector along with a set of tools for identifying and providing guidance on how to address misconfiguration issues that frequently arise when developers employ open source Terraform software to programmatically manage infrastructure as code.

Finally, Sonatype added tools to provide better guidance on the implications of open source licensing terms attached to various projects, while at the same time starting its own community for organizations migrating from Bintray and JCenter, now that those tools have been sunsetted.

Brian Fox, Sonatype CTO, said the expectation is Muse will create an opportunity to introduce the complete DevSecOps portfolio to developers as they analyze code. Most developers are keenly interested in both optimizing and securing their code. They would just prefer to achieve that goal on their own versus being informed of an issue after code has been committed to a repository managed by a larger DevOps team, noted Fox.

An advanced development pack was added to the Nexus platform last year to make it easier to surface dependencies in code that are vulnerable to threats. It applies machine and deep learning algorithms to automatically identify and block software supply chain attacks based on typosquatting and malicious code injections. Collectively, these tools give developers control over third-party open source code, first-party source code, infrastructure as code and containerized code, Fox said.

Sonatype claims it now counts 70% of the Fortune 100 as customers, and supports more than 2,000 commercial engineering teams. In 2020, it claimed it saw a 35% annual growth in Nexus repository installs, which now stands at more than 250,000 instances employed by nearly 15 million developers.

Overall, it’s not clear how much progress is being made toward embracing DevSecOps best practices. Sonatype, however. is making a case for putting DevSecOps tools directly into the hands of developers to address software supply chain security. In the wake of some recent high-profile breaches involving software supply chains, that approach may soon gain additional traction. After all, for all the encouragement being provided by application development team leaders these days, there’s nothing quite as effective as providing developers with a set of tools that enables them to achieve that goal on their own terms versus requiring them to follow a set of procedures dictated by a DevOps management team.

March 16, 2021
DevSecOps Trends to Know For 2021

For DevSecOps leaders, 2021 will be the year of the open source supply chain attack. It’s already starting, in fact. On January 7, security researchers at Sonatype identified three malicious Java components in the Maven Central repository. The components had identical names to reputable components. Then on January 20, the same research team found three more compromised packages in the node package manager (NPM). In all cases, these malicious components had nearly identical names to common Java and NPM packages.

The bad packages were downloaded thousands of times before they were removed, compromising the open source software supply chain. Such incidents are increasingly common. The practice of intentionally or unintentionally deploying poorly vetted code — we call it shadow code — is inevitable. Shadow code happens when developers include third-party software code in applications without approval or sufficient safety validations. Developers do this for the same reason that they use libraries and other components – it is quicker than writing the functionality from scratch. Often, these components offload compute-intensive or specialized features. Some examples are shopping cart software, payment systems or responsive design requirements. Sometimes, too, developers mistakenly include shadow code that is fake, but has a similar name (this is referred to as typosquatting), like the examples we described above.

Shadow code, plus a growing reliance on open source, magnifies the security risk and attracts more bad actors. Modern applications are composed of anywhere from 50% to 90% open source code, depending on the code audit. Rapid code iterations make it impossible for security reviews to police all code changes and dependencies. With many open source libraries containing hundreds of internal dependencies, even the best-automated code checking tools cannot keep up.

How Shadow Code and Supply Chain Attacks Play Off Each Other

The compounding risks of shadow code and supply chain attacks are one of the most pressing issues that will face DevOps and DevSecOps teams in the coming year. Security researchers at Sonatype tracked a 430% increase in supply chain attacks against 24,000 open source software components in 2020. The report blamed the growth of these types of attacks on two factors; first, DevOps teams are increasing code velocity to accelerate time to market. Second, security teams are responding to traditional zero-day vulnerabilities more quickly, shortening the window for exploits. Combined, the two factors encourage more supply chain attacks.

Attacking the Modern Extended Software Supply Chain

In modern web applications, most front-end and middleware application code comes from third-parties. Some is proprietary, but most code is open source, due to cost considerations. Open source component source code is a massive attack surface that is often poorly monitored, measured and inventoried. DevSecOps teams should create plans to reduce the impact of these attacks in 2021 and beyond.

Because supply chain attacks are often used either as launch pads for other attacks or to steal sensitive information, the business and financial risk from these compromises is considerable. In its annual “Cost of Breach” survey, IBM found that the average data breach cost $3.8 million and required 280 days to fully contain.

Supply chain attacks are likely an even more expensive subset of attack, due to several factors. Because they take advantage of trusted relationships, these attacks may go undetected for months or even years. Supply chain attacks also tend to be sophisticated and target an organization’s most valuable assets.

Evidence is emerging of coordinated attacks attempting to take advantage of supply chain weaknesses at the same time. Multiple attackers have targeted known users of vulnerable and end-of-life (EOL’d) versions of the online shopping platform Magento (aka Magecart attacks). We suspect that advanced hacking groups are either running the same scanning software packages to identify vulnerable targets, or are buying lists of viable targets via the dark web.

The Open Source Supply Chain Risk

The benefits of using open source software in building web and mobile applications is clear. Development teams, DevOps and DevSecOps teams can reuse code or libraries maintained by someone else to ship code faster and reduce the amount of code they must maintain.

Nowhere is this more of a risk than JavaScript and Node.js. The meteoric rise of Node.js as middleware has dramatically increased the number of packages and libraries that can be used by developers. NPM, the package manager for Node.js, is the most frequently downloaded piece of software in use today.

The rapid usage growth of Node.js and JavaScript has created a chaotic environment conducive to supply chain attacks. Attackers can inject code into trusted open source packages in a variety of ways. (To be clear, Java, Python, PHP, Golang and Ruby have the same potential supply chain vulnerabilities. But JavaScript is, by far, the largest target and it dominates the front-end and near-front-end, where user data is easiest to skim).

Some big, corporation-backed libraries, such as React (backed by Facebook), are well maintained. But many other commonly used libraries are maintained by under-resourced groups of developer volunteers. These unpaid maintainers have little incentive to do the “grunt work” of following rigorous security best practices, such as setting up automated code analysis or responding quickly to reports of security problems.

The cost of running all widely used open source JavaScript libraries through a proper code review would likely be in the tens or hundreds of billions of dollars. Because the maintainers of this code rarely profit from their work, they are not inclined to pay for and set up automated review systems. This is true even when maintainers work at large companies; the sheer amount of work behind maintaining a popular open source project can be backbreaking without major organizational support. Even code reviews and running code analysis tools is no panacea. Many popular open source projects change rapidly due to numerous and frequent code commits. So, a clean code review is no guarantee that the component remains safe a week or a month later.

For projects run by unpaid developers, commit access to core repositories is often poorly regulated, because maintainers are happy to get any help at all on their project. Reviews of pull requests may be superficial and miss well-obfuscated attacks. Worse, sometimes developers just get tired and stop maintaining their library. They may or may not notify users. Their ghost library may sit in GitHub or NPM, still downloading properly, but with no one paying any attention to bug reports or other suspicious activity.

The problem of abandoned or outdated code is often underestimated. According to a May 2020 study by Synopsys, 91% of commercial applications contain abandoned or outdated open source components. For these reasons, compromising open source libraries that have either been abandoned, are outdated or are lightly policed is a favorite tactic of malicious hackers looking to mount supply chain attacks – and that threat will only grow in 2021.

Learning to Live with Shadow Code and Supply Chain Risk

Getting rid of all shadow code is not an option. There’s just too much of it in use; halting the process entirely would negatively impact development cycles. Restricting developer behaviors in a heavy-handed manner usually ends badly (with more shadow code). Likewise, getting rid of the supply chain risk is impossible. Modern applications are too complex, with dependencies on open source components that themselves contain numerous third-party dependencies.

That doesn’t mean DevSecOps should do nothing. Developers can and should be educated about the risks of shadow code and supply chain attacks. Taking some simple steps to reduce the risk can go a long way. For example, ask developers to create simple checklists for every piece of third-party code they use to ensure the component meets the most basic risk standards. A checklist might include, “recently updated, responds to emails, has more than X number of downloads.” For open source code, use modern software composition analysis tools like Snyk and Sonatype that check open source libraries and can be dropped into the DevOps pipeline as part of the continuous integration process.

From the other direction, DevSecOps teams should attack the shadow code/supply chain problem by thinking about what application behaviors might indicate a compromise. To this end, teams should create a list of behaviors that are anomalous and create filters or notifications for those. For example, if a sign-up page starts taking consistently longer for users to complete, that might be a red flag for form jacking. As a final backstop, look at using machine learning systems to spot anomalous application behaviors. These systems can monitor all application behaviors, at scale, in a way that humans never can.

Combined, these defensive practices should reduce shadow code and supply chain risks for DevOps and DevSecOps teams. While thinking about these problems is not fun, a proactive approach to tackling this malicious duo will keep your development process and applications far more secure.

February 18, 2021