Key Takeaways

  • Morphisec argues that signed packages can remain dangerous when attackers compromise legitimate publishing accounts or pipelines.
  • Package worms such as Shai-Hulud can execute during installation, exposing credentials and enabling further malicious releases.
  • Runtime prevention can complement provenance, dependency scanning, software bills of materials, and endpoint detection.

Morphisec is calling for a prevention-first approach to software supply chain attacks as self-propagating package worms increase the pressure on developer workstations and CI/CD environments.

The company’s argument centers on a weakness in conventional software trust controls. Signing and provenance can establish who published a package and whether it changed in transit. They do not, by themselves, establish that the package’s behavior is safe. If attackers take over a legitimate maintainer account, steal a publishing token, or compromise a release pipeline, the resulting malicious package may still carry valid attribution and signatures.

That distinction matters because developers install dependencies intentionally. Rather than breaking through an external perimeter, an attacker can place hostile code inside a package that an organization retrieves through an approved workflow. The victim then executes the payload, often with permissions that provide access to repositories, cloud services, deployment systems, and additional package registries.

The wider threat data supports concern about this route. The ENISA Threat Landscape 2025 analyzed 4,875 incidents from July 2024 through June 2025 and attributed 10.6% to traditional software supply chain attacks. ENISA also reported that 68% of intrusions resulted in follow-up malware deployment and identified ransomware as the EU’s most impactful cyber threat.

A relatively small package can land in a remarkably powerful environment. Package installation scripts can run as soon as a developer issues an npm install or pip install command. In automated pipelines, similar activity may occur without anyone manually examining newly introduced code. Build systems also tend to hold credentials needed for source access, cloud deployment, artifact publication, and other internal operations.

That is the environment exploited by campaigns such as Shai-Hulud. According to CyberNews, hundreds of npm packages were compromised during a 2025 to 2026 supply chain attack surge. Research covering the broader attacks also associated Shai-Hulud and TeamPCP with credential theft, destructive behavior, and workflows that used newly created npm tokens. Later Shai-Hulud waves reached PyPI as well.

Once credentials are harvested, a worm can use them to publish additional compromised packages. Each release can then reach another group of downstream users. What happens when the mechanism designed to verify a publisher accurately verifies an account that an attacker now controls? The check still provides useful identity and integrity information, but its security meaning has changed.

To address this risk, the company proposes Automated Moving Target Defense (AMTD) as an additional layer at runtime. AMTD changes aspects of the memory environment that malicious code expects to use. This can interfere with in-memory attack execution before a payload steals secrets, moves laterally, or propagates through another package account.

The approach is not positioned as a replacement for package signing, endpoint tooling, software composition analysis, dependency pinning, or exposure management. Those controls address different stages of the risk. Provenance can reveal origin, an SBOM can improve component visibility, and scanning can flag previously identified malicious behavior. Runtime controls focus on what happens when code actually starts operating.

Recent supply chain analysis from CNIC Solutions reports that approximately 66% of software supply chain attacks focus on compromising a supplier’s own code. That finding reinforces why organizations may want controls beyond reputation-based trust. A familiar vendor name or valid signature can reduce uncertainty about origin while leaving behavior unresolved.

For security leaders, the practical response is layered rather than binary. Organizations can restrict installation scripts, isolate build workers, reduce standing credentials, rotate registry tokens, pin dependencies, review unexpected updates, and monitor publication activity. Ephemeral CI runners and tighter access boundaries can also limit what a compromised dependency reaches.

Morphisec’s broader point is that verification should not be treated as the final verdict. In package ecosystems where trusted accounts can distribute hostile code at speed, provenance remains valuable evidence, but runtime behavior deserves its own control layer. The signature may be valid, but the execution can still be dangerous.