Software supply chain attacks are now a secrets problem

At a glance

What this is: This analysis argues that software supply chain attacks now hinge on exposed secrets, compromised build pipelines, and AI-assisted code paths that can turn one foothold into downstream compromise.

Why it matters: It matters to IAM practitioners because secrets, tokens, and workload credentials are identity artifacts, and their exposure can turn AppSec gaps into broader access and privilege failures.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Sonar's analysis of supply chain attacks, secrets exposure, and AI coding risk

Context

Software supply chain security is no longer just about patching vulnerable libraries. The real governance gap is that teams still treat dependencies, build workflows, and AI coding tools as separate risks, even though attackers now chain them together through secrets theft and release tampering. For IAM and NHI programmes, the key issue is credential exposure across developer workflows, CI/CD, and machine-to-machine trust.

The article centres on a familiar but widening failure mode: trust is granted to code and tooling that can be modified, impersonated, or abused upstream of production. That makes secret handling, workload identity, and build-time controls part of the same control plane. The Trivy, LiteLLM, and Axios incidents described here are not edge cases; they are representative of where modern software delivery remains weakest.

Key questions

Q: What breaks when a CI/CD workflow can access secrets from untrusted pull requests?

A: The workflow stops being a safe validation boundary and becomes a secret-exposure path. Any token or service account available to that run can be stolen and reused to publish malicious code, sign artefacts, or move into adjacent systems. That is why secret access must be separated from untrusted code execution and tightly scoped to the exact publish step.

Q: Why do supply chain attacks so often turn into identity incidents?

A: Because attackers are not only changing code, they are harvesting the non-human identities that code runs beside. API keys, cloud credentials, SSH keys, and registry tokens give direct access to infrastructure and publishing systems, so a compromised package becomes an identity compromise with wider blast radius.

Q: How do security teams know if dependency controls are actually working?

A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach. If packages can change quietly and still access sensitive material, the control model is failing even if scans are passing.

Q: Who is accountable when a compromised package or leaked secret causes a downstream incident?

A: Accountability usually spans application security, platform engineering, and the owners of the workflow or release process. If secrets were exposed in CI, the issue is as much a privileged access governance failure as a software defect. Frameworks such as NIST CSF and OWASP NHI help assign control ownership more clearly.

Technical breakdown

How malicious packages turn dependency trust into downstream compromise

Malicious package attacks exploit the gap between functional testing and security validation. A package can install cleanly, pass tests, and still contain code that steals secrets, drops a backdoor, or phones home with environment variables. In supply chain terms, the attacker abuses trust in the software distribution path, not just in the code itself. The risk is amplified when organisations rely on CVEs alone, because intentional malware often has no vulnerability record at all. The practical challenge is that the compromise may begin before production, but the blast radius extends into pipelines, build artefacts, and deployment targets.

Practical implication: pair dependency allowlisting with malicious-package intelligence and treat every pulled package as a possible identity and credential exposure event.

Why CI/CD misconfigurations are an identity and access control problem

CI/CD systems are high-value identity brokers because they hold runner permissions, repository write access, signing credentials, and cloud tokens. A misconfigured workflow can let untrusted code execute with elevated permissions, effectively turning a pull request into an access path. That is why secrets in pipelines are not just secrets management failures. They are lifecycle and privilege failures, because the wrong principal receives the wrong capability at the wrong time. When build workflows are overly permissive or unpinned, the compromise is less about code execution than about credential harvesting and release abuse.

Practical implication: review workflow permissions as privileged access paths and remove write-capable triggers from untrusted execution contexts.

How AI coding tools expand the secret exposure surface

AI coding assistants and agents can ingest more context than teams realise, including local files, shell history, environment variables, and cached credentials. If the assistant or its configuration files are tampered with, the tool can become a propagation channel for backdoors or credential leakage. This is where AI governance meets NHI governance: the assistant may not be a human user, but it still processes identity-bearing data and can expose it through external logs, prompts, or generated code. Hidden Unicode instructions in rule files are especially concerning because they exploit the gap between human review and model interpretation.

Practical implication: govern AI coding tools as sensitive runtime systems and scan both assistant configuration files and local developer contexts for secret leakage paths.

Threat narrative

Attacker objective: The attacker wants to convert one trusted software artefact into broad downstream access, secret theft, and persistent compromise across multiple environments.

1. Entry begins with a misconfigured CI/CD workflow, a compromised maintainer account, or a poisoned dependency that gives the attacker a foothold in the software delivery path.
2. Credential access follows when exposed pipeline secrets, publishing tokens, or environment variables are harvested from runner memory, build logs, or developer tooling.
3. Escalation occurs as stolen credentials are used to publish backdoored packages or tamper with trusted release artefacts that downstream teams automatically consume.
4. Impact is realised when malicious code or stolen secrets propagate into production environments, enabling credential theft, remote access, or wider supply chain compromise.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Software supply chain trust has become a secrets governance problem. The article shows that attackers do not need to break every control if they can steal one publishing token or pipeline credential. That makes dependency risk inseparable from identity risk, because secrets are the authorisation layer for package publication, CI execution, and cloud access. Programmes that treat supply chain security as pure AppSec are missing the governance model that actually failed.

Hidden trust in build systems creates a standing privilege window. CI/CD runners, workflow triggers, and maintainer accounts often operate with more access than teams realise and for longer than they should. The failure is not only exposed secrets but persistent capability tied to uncontrolled execution paths. Practitioners should view build infrastructure as privileged identity infrastructure, not just automation.

AI coding tools introduce a new secret propagation channel. When assistants ingest local context and instruction files, they can amplify exposure from a single compromised workstation into repository-wide or provider-side leakage. The named concept here is developer context spillover: sensitive material leaves the developer boundary through tools that were never reviewed as identity-bearing systems. That requires governance across endpoint, secrets, and AI usage policy.

Functional correctness is no longer a meaningful security signal for dependencies. A package can appear to work perfectly while still exfiltrating credentials or injecting persistence. That means security teams need to stop using successful builds or passing tests as a proxy for trust. The practical conclusion is to evaluate what code can do in context, not just whether it compiles or installs.

Supply chain risk now spans the code the assistant writes and the code the pipeline ships. The controls that matter most are the ones that bind identity, approval, and artefact integrity together. That shifts the centre of gravity toward secrets lifecycle, workflow permissions, and provenance checks, because the next compromise is likely to move through all three.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Guide to the Secret Sprawl Challenge helps teams map where secrets persist across code, CI/CD, and runtime workflows before they are exposed again.

What this signals

Developer context spillover is the next governance issue teams need to name. As AI coding assistants consume more local context, organisations need policies that define which files, tokens, and environment variables are out of bounds, and they need technical controls that enforce those limits before data leaves the workstation.

Supply chain programmes are converging with identity governance because the same secrets that authenticate workloads now authorise builds, releases, and package publishing. Teams should align their software supply chain controls with OWASP Non-Human Identity Top 10 thinking, especially where short-lived credentials, least privilege, and rotation are missing.

The practical signal for security leaders is that provenance, secret hygiene, and privileged workflow design now belong in the same control review. A build system that can publish, sign, or fetch secrets without tight scoping is not merely inefficient. It is an access boundary that has not yet been governed as one.

For practitioners

• Treat CI/CD runners as privileged identities Inventory every workflow, runner, and deployment bot that can read secrets or publish artefacts. Remove unnecessary write permissions, pin third-party actions, and separate untrusted pull request execution from privileged release paths.
• Scan for secret exposure before code reaches a commit Run secret detection in the IDE and pre-commit stages, then re-scan in CI to catch anything that bypasses developer controls. Any exposed token, API key, or cloud credential should trigger rotation and incident review, not just a ticket.
• Gate dependency trust on malicious-package intelligence Distinguish between vulnerable packages and intentionally malicious ones, and fail builds when either category is detected. Backdoor intelligence should feed the same enforcement point as vulnerability checks so unsafe packages do not move into release artefacts.
• Govern AI coding tools as data-exfiltration surfaces Block hidden instruction files, inspect Unicode anomalies, and prevent assistants from reading sensitive local paths by default. Where AI coding tools are authorised, define what data they may ingest and how their outputs are reviewed before merge.
• Verify artefact provenance before downstream consumption Require SBOMs, signature checks, and release provenance validation for packages and build artefacts consumed by internal systems. If the provenance chain is incomplete, treat the artefact as untrusted even when it behaves normally in testing.

Key takeaways

• Software supply chain attacks now exploit identity artifacts such as publishing tokens, workflow permissions, and developer secrets, not just vulnerable code.
• The evidence in March 2026 shows how quickly one compromised workflow can cascade into backdoored packages and downstream credential theft.
• Teams need to move controls into the developer workflow, where secret detection, provenance checks, and privileged execution boundaries can actually stop the chain.

Key terms

• Malicious Package: A malicious package is software published into a legitimate repository but designed to execute harmful code when installed. It abuses normal dependency workflows so that the attacker’s code reaches the environment through trust in the package ecosystem, not through a traditional exploit.
• CI/CD Misconfiguration: A CI/CD misconfiguration is a build or release setting that grants excessive permissions, exposes secrets, or allows untrusted code to run in privileged contexts. These failures often turn automation into an attack path. The issue is governance of execution and access, not just pipeline reliability.
• Developer Context Spillover: Developer context spillover occurs when AI coding tools ingest more local data than intended and send sensitive material into prompts, logs, or generated output. This can expose secrets, credentials, and private code context outside the workstation boundary. It is an AI usage and data governance problem with identity consequences.

What's in the full article

Sonar's full analysis covers the operational detail this post intentionally leaves for the source:

• Workflow-level detection logic for malicious packages, exposed secrets, and CI/CD misconfigurations
• Examples of how pull request findings surface inside the developer workflow and quality gates
• AI coding assistant controls, including hidden instruction file detection and secret leakage prevention
• Cross-boundary SAST and SBOM handling details for teams that need implementation guidance

👉 Sonar's full article covers the Trivy, LiteLLM, and Axios attack paths in greater operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls with the software delivery paths that attackers increasingly target.