Notifications
Clear all
Topic starter
02/08/2026 12:18 pm
TL;DR: Malicious open-source packages are now being used as real malware that can execute on install, steal credentials, and compromise CI/CD workflows before SAST or SCA scanners run, according to Checkmarx. The operating assumption that package trust is safer than package control is no longer reliable.
NHIMG editorial — based on content published by Checkmarx: malicious open-source packages and the MPIAPI for real-time detection
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.
Questions worth separating out
Q: How should security teams stop malicious open-source packages before they reach developers?
A: Put screening before installation, not after deployment.
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.
Q: What do security teams get wrong about SCA when malicious packages are involved?
A: They assume dependency analysis alone is enough.
Practitioner guidance
- Block packages before installation Add pre-install screening to developer workstations, CI jobs, and build orchestrators so known malicious packages are stopped before execution.
- Restrict secret exposure in build paths Remove broad access to API keys, tokens, and certificates from developer shells, runners, and containers.
- Protect artifact registries and mirrors Gate private repositories with policy checks so malicious packages cannot be cached, mirrored, or reintroduced by accident.
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
👉 Read Checkmarx's article on defending against malicious open-source packages →
Malicious open-source packages: what AppSec teams need to change now?
Explore further
02/08/2026 1:19 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Malicious open-source packages are bypassing traditional AppSec controls
