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.
Editorial analysis by NHI Mgmt Group, based on content published by Checkmarx: “Malicious Open-Source Packages: The Imminent AppSec Threat for which Most Enterprises are Underprepared”.
By the numbers:
- 67% of respondents said half or more of their application code consists of open-source software.
- Only 49% said they have any protection in place against malicious packages.
Key questions
Q: What breaks when malicious package installs are allowed to execute code by default?
A: Malicious packages can run before review, harvest tokens from the local environment, and create persistence through repositories or automation paths.
A: They target trusted workflows and sensitive identity material at the same time.
Q: What do security teams get wrong when they assume open-source security is automatic?
A: Teams often assume open source is secure by default, but security still depends on governance, review, and community engagement.
Practitioner guidance
- Implement pre-install package screening Block package execution until automated checks verify the dependency against a malicious package database before download or install.
- Harden artifact registries and mirrors Use registry plugins and repository controls to stop known malicious packages from entering private repositories or being reinstalled from them.
- Separate developer and pipeline credentials Reduce shared exposure by isolating tokens, cloud credentials, and signing material from environments that can execute third-party packages.
Bottom line: Malicious open-source packages are not dormant defects, they are active malware that can execute during install and reach privileged environments before standard scanners respond.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:19 pm
Package trust is now a security control, not a developer convenience. Malicious open-source packages show that dependency acceptance is an execution decision with identity consequences, not just a build-time preference. Once a package can run code during install, the trust boundary moves from the application to the supply chain entry point. Practitioners should treat package admission as part of access governance for software delivery.
A few things that frame the scale:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should organisations govern malicious package risk across software delivery?
A: They should treat dependency ingestion as a governed control point, with clear ownership across AppSec, platform engineering, and identity teams. Package approval, registry policy, and build credential protection all need to operate together because the threat crosses developer workstations, CI/CD systems, and production paths.
👉 Read our full editorial: Malicious open-source packages are bypassing traditional AppSec controls