Malicious open-source packages are bypassing traditional AppSec controls

At a glance

What this is: Malicious open-source packages are intentional malware embedded in dependencies that can execute immediately on installation and undermine development, CI/CD, and production environments.

Why it matters: For IAM, PAM, and NHI practitioners, the risk is that developer and pipeline credentials become the first payload target, so package trust decisions now affect identity exposure as much as code security.

By the numbers:

• 67% of respondents in Checkmarx’s Future of AppSec survey report that half or more of their organization’s application code consists of open-source software.
• Only 49% stated they have any protection in place against malicious packages.

👉 Read Checkmarx's article on defending against malicious open-source packages

Context

Malicious open-source packages turn the software supply chain into an execution path, not just a dependency risk. When code is installed from trusted repositories, the package manager often becomes the first point of compromise, which means conventional application security controls may arrive after the payload has already run. This is now a supply chain and identity problem as much as a code hygiene problem because developer and CI environments frequently hold the credentials attackers want.

Checkmarx’s article frames the issue around how widely enterprises depend on open source and how little specific protection many of them have in place. That gap is especially relevant to identity governance because the most valuable targets are not just source repositories but the secrets, tokens, and production access embedded in build and developer workflows. In practice, many organisations are still treating package trust as a procurement decision rather than a runtime control boundary.

Key questions

Q: How should security teams stop malicious open-source packages before they reach developers?

A: Put screening before installation, not after deployment. The control should run in developer tooling, CI jobs, and package gateways so hostile packages are blocked before post-install hooks or import-time code can execute. Pair that with allow-listing for critical projects, because the goal is to prevent execution in privileged build contexts, not just to label packages after the fact.

Q: Why do malicious packages create an identity problem as well as a code problem?

A: Because the attacker is not only shipping code, they are trying to consume identities that already exist in the environment. CI tokens, cloud credentials, SSH keys, and publishing accounts all become targetable once install-time code can read them. That makes credential lifecycle, privilege scope, and offboarding controls central to supply chain defence.

Q: What do security teams get wrong about SCA when malicious packages are involved?

A: They assume dependency analysis alone is enough. SCA is useful for known vulnerabilities, but malicious packages are intentional malware and may execute before SCA completes. Teams need pre-install controls, registry policy enforcement, and runtime monitoring because the failure is not just detection quality. It is the assumption that a package is harmless until scanned.

Q: How do organisations measure whether malicious package controls are actually working?

A: Measure the time between package request, policy decision, and block, then test whether a malicious package can reach a privileged context in that interval. Also track how many build and developer environments still expose reusable secrets. If hostile packages can execute before a decision or can read high-value credentials, the control is not working.

Technical breakdown

Why malicious packages evade standard AppSec timing

Malicious packages differ from vulnerable packages because they are designed to execute immediately when installed. That means the attack does not depend on finding a flaw in the application code later. SAST and SCA often inspect code after installation or after dependency resolution, while the malicious payload may already have run during install scripts, import time, or post-install hooks. The control gap is timing, not detection accuracy. Endpoint tooling also tends to miss developer and build environments, leaving a blind spot where package execution intersects with credentials and pipeline access.

Practical implication: enforce pre-install and pre-execution package screening before the dependency can touch a workstation or build agent.

How trusted package managers become a supply chain entry point

Package ecosystems such as npm and PyPI rely on implicit trust, which attackers exploit by publishing packages that look legitimate or by compromising existing ones. Once a package is installed, it can read local environment variables, access cached tokens, tamper with build steps, or stage secondary malware. This is why malicious packages are more dangerous than dormant vulnerabilities: the package itself is the delivery vehicle. In a modern SDLC, that delivery vehicle can reach developer laptops, CI runners, artifact registries, and sometimes production automation with no separate exploit chain needed.

Practical implication: treat package installation as an access event and pair it with registry controls, allow-listing, and runtime checks.

Why NHI governance belongs in malicious package defence

The identity dimension is often missed because the visible problem is code, but the attacker’s objective is usually secret extraction or access reuse. Malicious packages commonly look for API keys, tokens, certificates, and cloud credentials on developer devices or in pipeline variables. Those are non-human identities in practice, even when they were not provisioned as such. This is where NHI governance matters: if secrets are broadly accessible in build paths, a malicious package only needs one successful install to turn application supply chain access into identity compromise.

Practical implication: inventory secrets exposed to development and CI systems, then scope them so package execution cannot reach reusable credentials.

Threat narrative

Attacker objective: The attacker wants to turn trusted software distribution into credential theft, pipeline compromise, and persistent access to development or production systems.

1. Entry occurs when an attacker publishes or compromises a package that enters a normal dependency workflow through a repository, mirror, or developer install.
2. Credential access follows when the package inspects environment variables, local files, or build context to harvest API keys, tokens, or certificates.
3. Impact occurs when stolen secrets are used to compromise build pipelines, exfiltrate data, or plant backdoors in downstream environments.

NHI Mgmt Group analysis

Malicious package defence is a package trust problem, not just an AppSec scanning problem. The central failure mode is assuming that open-source dependencies are safe until proven otherwise. That assumption breaks when the package itself is the malware and the exploit executes before traditional scanning stages. Practitioners should treat dependency intake as a security control boundary, not a developer convenience.

Secrets exposed to build and developer workflows are now part of the supply chain attack surface. Malicious packages target the credentials that let attackers move from one workstation to many environments. That makes NHI governance relevant even in application security programmes that do not think of themselves as identity programmes. The governance question is not only what code is allowed in, but what reusable access that code can reach.

Credential exposure in software delivery creates a standing privilege problem inside the SDLC. If build systems, package managers, and developer tools can see long-lived tokens, a single malicious install can create immediate blast radius. That is why the operating model should shift toward short-lived access, narrower scopes, and explicit controls at install time. The practical conclusion is that secrets minimisation and package controls must be designed together.

Malicious package detection should be measured as a runtime access control capability, not as a library count. Enterprises often report open-source usage, but that does not measure whether they can stop hostile packages before execution. A more useful governance signal is how quickly a package can be screened, blocked, or isolated before it reaches a privileged context. Practitioners should align AppSec metrics with control latency, not dependency volume.

What this signals

Malicious package defence will increasingly be judged by control latency. If a package can execute before the security stack sees it, then the programme is relying on post-event detection rather than prevention. The practical shift for teams is to measure how fast policy can stop installation, and whether that stop happens before reusable secrets or pipeline trust are exposed.

Build systems now deserve the same identity scrutiny as production systems. Developer laptops, CI runners, and artifact registries are all places where non-human identities can be abused through exposed tokens and certificates. That means IAM and PAM teams should work more closely with AppSec on secrets scope, task-scoped access, and lifecycle revocation.

Secret minimisation is becoming a supply chain resilience control. The more reusable credentials a malicious package can reach, the more likely a single install becomes a broader incident. A useful programme-level signal is whether package execution paths are isolated from long-lived credentials and whether high-value secrets are absent from default build contexts.

For practitioners

• Block packages before installation Add pre-install screening to developer workstations, CI jobs, and build orchestrators so known malicious packages are stopped before execution. This is especially important where package manager hooks can run during installation, because post-install scanning is already too late. Use the screening point as the control boundary, not the scanner result.
• Restrict secret exposure in build paths Remove broad access to API keys, tokens, and certificates from developer shells, runners, and containers. Keep only task-scoped credentials in the smallest possible context, and separate build-time access from production access. A malicious package should not be able to read reusable secrets from environment variables or cached config files.
• Protect artifact registries and mirrors Gate private repositories with policy checks so malicious packages cannot be cached, mirrored, or reintroduced by accident. Registry controls should be able to block known bad packages even when they are requested by automated tooling. This closes a common path from public ecosystem compromise to internal distribution.
• Monitor for previously installed package compromise Continuously rescan installed dependencies because a package that was safe yesterday may be compromised today. When threat intelligence changes, trigger review of affected workstations, CI agents, and build artefacts. This is a lifecycle control, not a one-time admission check.

Key takeaways

• Malicious packages are not theoretical dependency risks. They are executable malware that can compromise development and build environments before standard scanners finish.
• The scale of open-source dependence means package trust now intersects with identity governance, especially where API keys, tokens, and certificates are reachable in build paths.
• Teams need pre-install blocking, registry policy controls, and secret minimisation if they want to reduce the blast radius of supply chain compromise.

Key terms

• Malicious open-source package: A malicious open-source package is a dependency that contains intentional malware rather than an accidental flaw. It may run automatically during installation, import, or post-install processing, allowing attackers to steal secrets, alter build output, or create persistence inside development workflows.
• Package Install Trust Boundary: The point at which a dependency is allowed to run code during installation or build. In supply chain attacks, this boundary is often weaker than teams assume, because build metadata and native compilation hooks can execute before ordinary review or monitoring controls trigger.
• Secrets exposure in the SDLC: Secrets exposure in the SDLC is the presence of API keys, tokens, certificates, or credentials in development and build environments where code can read them. It matters because malware in a package can turn access to those secrets into cloud compromise, pipeline abuse, or downstream persistence.
• Supply chain response latency: The delay between recognising that a supplier may be compromised and removing the supplier's ability to reach sensitive systems. It is a governance and identity problem as much as an operational one, because every extra minute can expand the incident's blast radius.

What's in the full article

Checkmarx's full article covers the operational detail this post intentionally leaves for the source:

• Detailed examples of malicious package behaviours across developer workstations, CI/CD pipelines, and production workflows
• Implementation guidance for pre-install screening, registry controls, and fast API-based checks in build tooling
• Practical integration patterns for package manager wrappers, IDE integrations, and artifact repository enforcement
• The eBook's ROI framing and business case language for security leaders who need budget support

👉 Checkmarx's full post covers the threat examples, SDLC defence layers, and MPIAPI integration details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to reduce identity exposure across modern delivery pipelines. It gives security teams a shared control language for the access paths attackers now target.