CI/CD credentials are a prime target of malicious open source packages because of the sheer authority those credentials carry. Depending on their privileges, they can provide access to source code, build systems, package registries, cloud infrastructure, and production delivery.

A stolen credential can turn one compromised dependency into a path across the software supply chain.

Malicious packages provide attackers with a way to reach that authority early. If a package executes during installation, it may collect tokens, secrets, and other sensitive information before a pull request is opened, a build is completed, or a traditional application security scan begins.

In 2025, 53% of the malicious packages Sonatype analyzed were designed to compromise developer environments during installation, often targeting credentials, secrets, and other sensitive information.

The package install may be the entry point. But control over trusted software delivery is the larger objective.

The Authority Behind a Stolen Token

CI/CD credentials are unusually valuable because they can authorize actions throughout the software delivery process. Depending on their scope, stolen credentials may allow attackers to:

• Access private source repositories and build definitions.

• Modify code or pipeline configurations.

• Publish trusted packages or releases.

• Reach cloud and deployment environments.

• Retrieve secrets from internal services.

This access gives attackers leverage. It allows them to operate through systems already trusted by the organization and its customers.

Malicious packages can reach those credentials earlier than many security controls. In npm, for example, attackers can abuse preinstall and postinstall scripts to inspect the host, collect secrets, or retrieve another payload. On developer workstations, they may encounter source-control tokens, SSH keys, or cloud credentials. On CI runners, they may reach build secrets, registry tokens, artifact repositories, or deployment services.

Compromise can therefore occur before a finished application exists to scan. A malicious package can open a path into infrastructure that builds and delivers many applications, making it critical to protect the moment a component is selected, downloaded, and installed.

Attackers Need a Believable Package, Not a Perfect Copy

The familiar explanation for package impersonation is typosquatting: publishing a malicious package with a name that differs from a popular project by one or two characters.

That technique still exists, but modern package deception is often more subtle.

In Sonatype's analysis of 4,309 malicious packages, 91% of brandjacking malware went beyond traditional typosquatting. Attackers used names that appeared adjacent to legitimate projects: plugins, configuration packages, SDKs, wrappers, utilities, scoped modules, and versioned variants.

These names work because developers expect frameworks and tools to have large ecosystems of supporting packages. A malicious package does not need to be visually identical to a trusted project. It only needs to look as though it belongs nearby.

For an attacker seeking credentials, that momentary credibility may be enough. The package only needs to execute once.

How Credentials Turn an Install Into a Supply Chain Attack

Consider a package that appears to be a legitimate plugin or utility. A developer or coding agent adds it to a project, and it executes when installed on a workstation or CI runner. Hidden code searches for credentials, tokens, configuration data, and host information, then sends useful findings to the attacker.

If those credentials provide access to source control, package registries, build systems, cloud services, or deployment infrastructure, one dependency install can lead to unauthorized code changes, malicious releases, poisoned builds, or deeper access.

Recent Sonatype research found that host-information and secrets exfiltration accounted for more than half of the threat labels in its naming-variant malware dataset. Targeted data included API keys, registry and GitHub tokens, cloud secrets, SSH credentials, and CI/CD secrets.

The impact depends on which credentials are exposed and the privileges they carry. Package-manager tokens are particularly valuable because they can enable attackers to publish malicious updates through the same trusted ecosystem. In self-propagating campaigns, one stolen token can turn a package consumer into the publisher of the next malicious release.

The attacker is then operating with the authority of a trusted developer, build process, or maintainer.

AI Accelerates Dependency Decisions

AI coding assistants and agents increase the speed and volume of dependency decisions. Assistants can recommend components in seconds, while agents can introduce packages as they complete development tasks. More libraries and updates can therefore enter consideration with less time devoted to each decision.

That gives attackers more opportunities to influence software selection. Sonatype identified 3,430 malware advisories in 2025, 3.69x the pre-AI annual baseline of 931 advisories. Even after large repository-abuse campaigns were excluded, distinct malicious payloads increased by more than 50%.

Manual investigation cannot scale with every dependency recommendation. Component intelligence and policy guardrails must evaluate these decisions at the speed agentic workflows operate.

Why Traditional Controls Miss the Critical Moment

Controls focused on known vulnerabilities, obvious typosquats, or completed artifacts may act too late for install-time malware.

A plausibly named package may have little reputation data when it first appears. Its risk may become evident only when its behavior, integrity, publisher activity, naming pattern, and connections to a broader campaign are evaluated together.

Reputation also takes time to develop. By the time a package has enough external signals to appear dangerous, it may already have reached a developer workstation, CI job, or ephemeral environment.

Removing the dependency does not necessarily end the incident. Teams may still need to identify where it executed, determine which secrets were accessible, rotate credentials, investigate follow-on activity, and rebuild affected artifacts.

The blind spot is the moment of adoption, not only the final build.

Protect Credentials Before Malicious Code Executes

The primary defense against open source malware is stopping it from entering development environments in the first place. Once a package executes on a developer workstation or CI runner, it may already have accessed credentials, secrets, or environment data.

Organizations should:

• Govern dependency selection before installation, including components introduced through AI-assisted workflows.

• Treat repositories and upstream access paths as control points for what enters development.

• Apply consistent controls across developer workstations, repositories, CI/CD systems, and ephemeral environments.

• Evaluate package behavior, integrity, publisher patterns, naming conventions, and campaign context, not only known-bad names.

• Limit the blast radius if prevention fails by using least-privilege, short-lived credentials and restricting secrets to the jobs that need them.

Credential and secret-management practices remain important safeguards, but they limit the impact of a compromise rather than stop a malicious package from entering the environment. Having proactive protections in place, helps mitigate the risk from the start.

Protect the Authority Behind the Pipeline

By the time a malicious package executes on a developer workstation or CI runner, credentials and environment data may already be exposed. The strongest control point is therefore upstream, before the component is downloaded and installed.

Sonatype Firewall uses Sonatype's open source intelligence and malware research to evaluate components at the point of download, blocking or quarantining suspicious and malicious packages before they enter repositories and development workflows. For organizations using third-party repository managers, Sonatype Firewall Pro provides malicious-package protection without requiring a repository migration.

Attackers target CI/CD credentials because those credentials can turn one package install into authority over trusted software delivery. Protecting that authority means securing both the pipeline and the dependency decisions that feed it.

Learn how Sonatype identifies and blocks malicious open source behavior before risky components reach developer and CI/CD environments.

Frequently Asked Questions

Why Do Attackers Target CI/CD Credentials?

CI/CD credentials may provide access to source repositories, build systems, package registries, cloud infrastructure, and deployment environments. They allow attackers to operate through systems already trusted to build and distribute software.

Can a Malicious Open Source Package Steal CI/CD Secrets?

Yes. If malicious code executes on a workstation or CI runner, it may inspect environment variables, configuration files, credential stores, or other locations containing tokens and secrets.

How Can a Package Install Compromise a Build Pipeline?

A malicious package may execute during installation, collect credentials, and send them to an attacker. Those credentials can then enable access to source code, build workflows, package-publishing systems, or connected infrastructure.

What Is a Naming-Variant Attack?

A naming-variant attack uses a package name designed to resemble a plausible plugin, SDK, configuration package, wrapper, or utility associated with trusted software. It exploits ecosystem naming conventions rather than relying solely on a spelling mistake.

How Can Organizations Protect CI/CD Credentials From Open Source Malware?

Organizations should combine least-privilege, short-lived credentials with controls that evaluate dependencies before installation. They should also limit secret exposure, monitor package and publisher behavior, apply consistent policies across development environments, and block malicious components at the repository or upstream access path.