Fortinet’s latest FortiGuard Labs reporting on the Shai Hulud supply-chain campaign is a useful reminder that build infrastructure is not “just DevOps.” When a CI/CD runner can reach cloud control planes, data stores, and secrets, a poisoned dependency can become a production cloud incident.

Fortinet reported that Shai Hulud activity affected modern CI/CD environments and that investigators later observed abuse of a Jenkins EC2 instance role, IAM escalation, security group manipulation, Amazon Redshift access, and signs of data exfiltration. Fortinet is careful not to claim absolute proof that the original package compromise directly caused every later cloud action, but the timeline and credential class line up with the kind of pipeline-to-cloud pivot defenders should be planning for now.

What happened

Shai Hulud is a software supply-chain campaign tied to malicious npm and PyPI package activity. The campaign’s core value is not the package itself; it is the credential theft that happens when that package runs in a developer workstation, CI job, or self-hosted runner.

In the Fortinet case study, the important defensive pattern is straightforward:

  • Malicious package execution created exposure in the build environment.
  • A Jenkins runner’s cloud identity was later used from external infrastructure.
  • The actor created a new IAM user, attached administrator privileges, and generated access keys.
  • Cloud control-plane access was used to modify security groups, interact with database infrastructure, enumerate secrets, and query Redshift data.
  • Exfiltration staging involved cloud-native services, making the activity look like administrative work unless defenders correlate identity, network origin, and timeline.

Why this matters to SMBs and government contractors

Small and mid-sized teams often treat CI/CD as an automation convenience instead of a high-value security boundary. That is risky. A build runner may hold package tokens, GitHub credentials, AWS roles, Kubernetes secrets, SSH keys, artifact signing material, deployment access, and direct routes into production networks.

For government contractors, the stakes are higher because a compromised pipeline can expose customer data, cloud-hosted project systems, source code, controlled technical information, or downstream customers who trust your software updates. This is also exactly the type of incident where “we patched the package” is not enough. If secrets were available to the runner, assume they may have left the environment.

Defensive takeaways

  • Treat CI/CD roles like production identities. Jenkins, GitHub Actions runners, GitLab runners, and build agents should have least-privilege cloud roles, short sessions, and narrow resource access.
  • Alert when instance-role credentials are used from the wrong place. Temporary credentials issued to an EC2 instance should not normally authenticate from unrelated external IP addresses.
  • Limit metadata-service exposure. Enforce IMDSv2, restrict local access where possible, and monitor for credential retrieval from build hosts.
  • Rotate secrets after pipeline compromise. Registry tokens, cloud keys, GitHub tokens, deploy keys, signing keys, SSH material, and database credentials should be considered exposed if they were available to the runner.
  • Watch for cloud control-plane staging. New admin users, new access keys, permissive security groups, database network changes, Secrets Manager enumeration, and unusual Redshift Data API activity should be high-signal detections.
  • Separate build, deploy, and data access. A build job should not automatically have the ability to modify production network controls or query sensitive data warehouses.

Bulwark Black assessment

The lesson from Shai Hulud is bigger than one worm family: CI/CD identity is production cloud identity unless you deliberately make it otherwise. Modern attackers do not need to “hack the cloud” if they can steal a trusted runner’s role and let your own automation privileges do the work.

The proper response is not only dependency scanning. Teams need pipeline identity review, cloud trail correlation, runner isolation, secret rotation playbooks, and detections that understand where a credential is supposed to be used. If your build system can change production security groups or query your data warehouse, it belongs in the same risk tier as your cloud administrators.

Original source: Fortinet FortiGuard Labs — From CI/CD to Cloud Data: How Shai Hulud Persistence Leads to Redshift Breach