Why Trusted Pipeline Identities Matter More Than Ever in Software Supply Chain Security
Published
Question: Recent incidents involving Aqua Security’s Trivy scanner and Checkmarx GitHub Actions showed attackers abusing trusted CI/CD tools. Why are pipeline identities and automation accounts becoming a preferred attack path? What should security teams do to fortify defenses?
Raj Mallempati, CEO and Co-Founder of BlueFlag Security
Pipeline identities and automation accounts have become attractive targets because they give attackers a cleaner path into the software supply chain than exploiting code directly. If an attacker can compromise a trusted action, token, bot, or service account, they do not have to fight their way through the front door.
They can move through the same automated systems developers rely on every day to build, test, sign, publish, and deploy software. The Trivy and Checkmarx GitHub Actions incidents are just the most recent to make this clear. The attacker did not need a novel vulnerability chain.
The underlying weakness was compromised credentials, overprivileged service accounts, and trusted automation paths that were not closely monitored. Once the attacker had valid access, they could operate through tools the pipeline already trusted.
In the Trivy case, malicious versions of trusted actions ran inside CI environments and harvested SSH keys, cloud credentials, and Kubernetes secrets. The same pattern appeared again with Checkmarx GitHub Actions, where reused access was enough to create real impact.
Here is the uncomfortable part. The industry keeps investing in finding vulnerabilities faster, with better scanners, better dependency analysis, and now AI built directly into the pipeline to catch flaws earlier. That work matters.
But it answers a question attackers have largely stopped asking. Look at how the recent incidents actually started:
- not with a novel vulnerability,
- but with a compromised credential,
- an overprivileged service account, or
- a trusted automation path nobody was watching.
We are building better and better locks for a door that attackers walked past long ago.
A scanner can identify a vulnerable dependency, but it may not detect a service account accessing unfamiliar repositories, a CI job making new outbound calls, or a token being used from an unusual location.
This gap exists because automation accounts accumulate privilege quietly.
- A bot is created for one workflow and then reused by another team.
- A personal access token gets embedded in a job and never fully revoked.
- Tags are trusted instead of pinned to full commit SHAs.
- Service accounts are excluded from normal access reviews because nobody wants to break the build.
- These shortcuts are understandable in fast-moving engineering environments, but attackers understand them too.
Security teams should treat pipeline identities like privileged users, not background machinery.
- Every service account, bot, GitHub Action, build runner, and deployment identity should have an owner, a defined purpose, least-privilege permissions, and regular review.
- Organizations should
- pin actions to full commit SHAs,
- rotate exposed credentials quickly,
- restrict long-lived tokens, and
- monitor CI jobs for unusual outbound network calls or access outside normal behavior.
- In practice, that means looking beyond whether the pipeline succeeded and asking whether the identity running it behaved in a way that fits its role.
The harder change is organizational. Many companies still separate AppSec, DevOps, identity, and cloud security into different teams with different tools, which makes it difficult to see how small signals connect across the SDLC.
A real attack path may combine a stale credential, mutable tag, overprivileged bot, unusual repo access, and a malicious package update. Each signal can look minor on its own, but together they point to a serious compromise.
This problem will become more urgent as AI agents become part of development workflows. More non-human identities will operate inside repositories, pipelines, and deployment systems, often at high speed and across broad scopes.
The risk is not only what code gets generated or scanned. It is what those agents and automation accounts can reach if they are compromised, misconfigured, or granted more access than they need.
The attack surface is no longer just the code. It is every developer, contractor, service account, bot, and AI agent touching the SDLC.
Related
