Supply-chain worms are now stealing cloud and AI credentials

At a glance

What this is: This weekly briefing maps a cluster of supply-chain compromises and backdoors that use trusted package channels to steal cloud, developer, and AI credentials at runtime.

Why it matters: It matters to IAM, PAM, and NHI teams because package provenance alone does not protect secrets, and compromised build or developer environments can turn credentials into a lateral-movement path.

By the numbers:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Corgea's weekly briefing on supply-chain, kernel, and application-security findings

Context

Supply-chain compromise becomes an identity problem as soon as malicious code can steal credentials, tokens, certificates, and API keys from the runtime environment. In this briefing, Corgea highlights a week where trusted packages and release artifacts were used to harvest secrets across cloud, developer, and AI workflows, which is why identity governance has to extend into build systems, endpoints, and CI runners.

The practical issue is not only whether a package is legitimate, but whether its execution path can reach privileged material before controls notice. That makes secrets management, workload identity, and offboarding discipline part of the response model, not a separate hygiene exercise. The pattern is already familiar in mature enterprises, yet the operational assumption that package trust equals runtime safety remains common.

Key questions

Q: What breaks when a trusted package can run code on developer or CI systems?

A: The main failure is that software provenance does not stop runtime abuse. If install-time or import-time code can reach environment variables, local secret stores, or process memory, a legitimate package can become a credential stealer. That turns dependency management into an identity exposure problem, especially for cloud and pipeline credentials.

Q: Why do cloud and AI-tool credentials increase the blast radius of supply-chain attacks?

A: They often bridge multiple systems, so one stolen secret can unlock storage, compute, source control, vaults, and automation. AI-tool credentials can also expose prompts, connectors, or internal workflows. That makes these secrets much more valuable than narrow application tokens and much harder to contain after theft.

Q: What do teams get wrong about dependency provenance and package trust?

A: Teams often assume a signed or expected package name is enough, but package metadata, lifecycle hooks, and publishing path all matter. A malicious release can keep the codebase looking normal while shifting the real risk into install-time execution. Provenance checks must therefore cover who published, how it was published, and what scripts will run.

Q: Who is accountable when a malicious dependency steals secrets from CI runners?

A: Accountability usually spans engineering, platform, security, and the team that approved the publishing or build workflow. The control gap sits across software supply-chain governance, secrets management, and identity lifecycle discipline. Frameworks such as NIST CSF, NIST SP 800-53, and OWASP NHI all touch different parts of that shared responsibility.

Technical breakdown

How malicious package releases become credential stealers

Modern supply-chain attacks often abuse the same installation or import path that legitimate code uses. A poisoned package can execute at install time, import time, or activation time, then enumerate local secrets stores, environment variables, cloud metadata, and developer credentials. Once those credentials are collected, the attacker does not need to stay inside the package manager. They can pivot into cloud APIs, CI systems, source control, or secret backends using the victim's own trust relationships. The danger is amplified when the malicious payload also writes persistence or hooks into developer tooling, because the compromise survives beyond the initial install.

Practical implication: Treat dependency execution as a privilege boundary and restrict where packages can run, not just what can be installed.

Why cloud, Kubernetes, and AI credentials are such high-value targets

Cloud credentials and workload tokens are attractive because they often bridge multiple environments. A single exposed AWS or Kubernetes credential can reach storage, compute, build systems, and secret managers, while AI-tool credentials may open access to internal models, prompts, or workflow connectors. Attackers prefer these secrets because they are reusable, hard to attribute, and frequently over-scoped. If a package can harvest them from a developer laptop or CI runner, it can move from software supply-chain compromise to environment-wide access without exploiting a traditional vulnerability in the target application.

Practical implication: Classify cloud and AI-tool secrets as high-risk credentials and give them tighter scoping and faster invalidation than ordinary application tokens.

How GitHub dead drops and encrypted exfiltration reduce detection

Many contemporary malware campaigns avoid obvious command-and-control traffic. Instead, they use GitHub commits, release artifacts, DNS lookups, or encrypted outbound channels as dead drops and exfiltration paths. This approach blends into normal developer activity and can evade rule sets that focus only on known malware infrastructure. When package malware steals credentials and then stages data in public repositories or innocuous-looking channels, defenders face a split problem: identifying the execution event and tracing the secret exposure that follows. That is why package integrity monitoring must be paired with secret scanning and abnormal publishing detection.

Practical implication: Correlate package execution with outbound secret movement and repository activity so a single compromise does not look like separate low-signal events.

Threat narrative

Attacker objective: The attacker wants trusted execution paths to hand over reusable credentials that unlock cloud infrastructure, developer platforms, and downstream secrets stores.

1. Entry occurs when a trusted package release, release asset, or dependency update is pulled into a developer machine or CI runner.
2. Escalation follows as the malicious code harvests cloud, source control, vault, SSH, or AI-tool credentials from environment variables, local stores, and process memory.
3. Impact is achieved when stolen credentials are used for lateral movement, secret exfiltration, or unauthorized access to infrastructure and internal tools.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Hard-Coded Secrets in VSCode Extensions — 500+ VSCode extensions expose hardcoded tokens and credentials creating massive developer supply chain risk.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trusted package provenance is not a sufficient security boundary. Provenance signals help with software authenticity, but they do not stop a signed or legitimately published artifact from behaving maliciously after install. In supply-chain incidents like this, the relevant trust boundary is runtime behaviour, not publication lineage. Teams should therefore evaluate execution permissions, egress paths, and secret reachability as first-class controls.

Credential harvesting from build and developer environments is now the dominant blast-radius problem. The article's pattern shows that one poisoned dependency can expose cloud access, vault tokens, and AI-tool credentials in a single execution window. That creates a combined NHI and human identity risk because developer workstations, CI runners, and service accounts often share the same secret estate. The governance failure is assuming these environments are too transient to matter.

Runtime secret exposure is the named failure mode here. The issue is not merely that malicious code exists, but that credentials remain available in places the package can reach. Runtime secret exposure: secrets stored in environment variables, local files, process memory, or CI contexts are accessible long enough for malware to collect them and pivot. Practitioners should treat that as a lifecycle and containment gap, not a scanner problem.

Supply-chain security is converging with identity governance. Package review, repository controls, and build hardening now sit alongside IAM, PAM, and NHI management because attackers are targeting the identities inside delivery pipelines. That means secret rotation, workload identity scoping, and privileged session controls need to extend into developer tooling and automation. The programme implication is clear: identity controls must follow code execution, not just user sign-in.

AI tool credentials are becoming part of the enterprise secret perimeter. The briefing's inclusion of AI-tool credentials is a warning that non-human access now spans more than classic cloud and source-control systems. Once AI workflows are connected to repositories, CI, or secret managers, compromised package execution can reach agentic tooling and automation contexts as well. Teams should map AI credentials into the same governance model as other NHIs, or they will miss a growing attack surface.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Forward pivot: The 52 NHI Breaches Report shows how weak lifecycle control turns exposed secrets into repeatable compromise paths.

What this signals

Runtime secret containment is now the control that separates a recoverable incident from an enterprise-wide compromise. If a poisoned package can touch environment variables, build logs, or local credential stores, the blast radius depends less on patch speed than on how quickly secrets can be invalidated. The practical signal for identity programmes is simple: if a secret can survive five days after notification, as our research shows, the organisation is already behind the attacker.

The near-term programme shift is to treat developer tooling, CI runners, and AI-integrated workflows as identity-bearing systems. That means mapping every high-value secret to an owner, a TTL, and a revocation path, then testing whether a compromised workstation can still reach those controls. The organisation that cannot answer that question has a secrets lifecycle problem, not just a supply-chain problem.

For practitioners

• Harden package execution paths Restrict where untrusted dependencies can execute, including install hooks, import-time code, and CI runner activation paths. Block outbound access from package-install stages unless the workflow explicitly requires it.
• Rotate exposed secrets from clean systems Assume any host that imported a malicious package may have leaked cloud, vault, SSH, or AI-tool credentials. Rotate those credentials from a known-clean machine, and do not trust the compromised endpoint for remediation actions.
• Scope developer and CI credentials tightly Use short-lived credentials with minimal permissions for build systems, package publishing, and automation accounts. Separate human developer access from pipeline identity so one stolen secret cannot unlock the full environment.
• Monitor dead-drop and exfiltration patterns Look for GitHub commit abuse, unexpected release-asset changes, DNS TXT lookups, and encrypted outbound transfers from developer workstations and runners. Pair detection with secret scanning in repositories and local working directories.

Key takeaways

• Supply-chain malware is now targeting credentials, not just code integrity, which makes identity governance part of software delivery security.
• The evidence points to wide secret exposure across cloud, developer, and AI environments, and remediation is often slower than attacker use of the stolen material.
• Practitioners need execution controls, fast revocation, and tighter secret scope to reduce the blast radius of poisoned packages and release artifacts.

Key terms

• Supply Chain Malware: Malware delivered through trusted software distribution paths such as packages, dependencies, or build tooling. It succeeds by inheriting trust from legitimate workflows, which makes publication-time checks insufficient if the malicious behaviour appears only after install or in a later version.
• Runtime Secret Visibility: Runtime secret visibility is the ability to observe when and where secrets are accessed while systems are actively running. It matters because static inventories alone do not show whether a tool, workflow, or workload is reading credentials in memory, files, or logs.
• GitHub dead drop: A covert exfiltration pattern that uses GitHub commits, issues, releases, or repository changes as a place to store commands or stolen data. It blends into normal developer activity and can be harder to flag than traditional command-and-control traffic.
• Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.

What's in the full report

Corgea's full weekly briefing covers the operational detail this post intentionally leaves for the source:

• Package-by-package findings, including affected versions and the exact malicious behaviours observed during execution.
• Cross-source reporting notes from Aikido, Endor Labs, SafeDep, and other investigators behind the week’s disclosures.
• Specific remediation advice for teams that need to triage Linux hosts, CI runners, and developer workstations after exposure.
• Additional coverage of the Strapi, Nx Console, and Node IPC issues that broaden the week’s supply-chain risk picture.

👉 Corgea's full briefing covers the affected packages, attack behaviours, and immediate containment guidance.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives identity and security practitioners a common foundation for controlling access across human, machine, and automation-heavy environments.