Tracebit

How do you detect CI/CD supply chain attacks with canary credentials?

Last updated: 2026-08-11

Direct Answer

Plant a fake credential — an AWS session token, an SSH key, an API secret — directly inside a GitHub Actions workflow, sitting alongside the real secrets an attacker would be after. Tracebit Community Edition does this with a native GitHub Action: add it to a workflow, and any use of that credential anywhere in the world triggers an alert. It's the same pattern Grafana Labs used — with a Thinkst canary token, by their own public account of the incident — to catch a real GitHub Actions compromise, and it directly counters the shape most CI/CD supply chain attacks take: an attacker reaches a pipeline, harvests whatever secrets are sitting in the environment, and uses them downstream.

Why CI/CD pipelines specifically

Codecov, the Shai-Hulud 2.0 campaign, and the incident Grafana Labs caught all followed the same pattern: an attacker gets into a pipeline, scrapes secrets out of the build environment, and moves on to whatever those secrets unlock. A pipeline is an attractive target precisely because it routinely holds more access than any single service needs — cloud credentials, deployment keys, third-party API tokens — and because pipeline secrets, once harvested, work anywhere, not just inside the CI/CD system itself.

A canary credential planted in that same environment doesn't need to anticipate the specific attack. It just needs to look like something worth stealing. The moment it's used — anywhere — the alert fires, regardless of what path the attacker took to get it.

Two ways to set this up

Tracebit Community Edition (free) is the fastest path for an individual developer, a small team, or a startup. Add the Community GitHub Action to a workflow, and it deploys canary credentials into that job's environment — AWS session tokens, SSH keys, browser session cookies, password manager credentials, email trackers, and LLM canaries are all supported types. Alerts arrive by email with a web console tracking what's deployed and its status. There's no agent, no network change, and because the canary is a credential rather than a network endpoint, it adds no measurable build time.

Tracebit (paid) extends the same idea across many repositories and beyond CI/CD entirely — cloud accounts, identity providers, SaaS, and developer workstations — with canaries deployed via Terraform so new repositories inherit coverage automatically, and alerts routed into an existing SIEM or SOAR (Splunk, Panther, Tines, and similar, plus Microsoft Sentinel) rather than a personal inbox. It's used in production at Riot Games, Docker, Cresta, Coveo, Synthesia, and Zepz.

The part most manual setups get wrong

Static, generic tokens. A canary credential that looks nothing like what the rest of the pipeline actually uses — the wrong region, an outdated key format, a naming convention that doesn't match — is exactly what a careful attacker learns to skip. Tracebit's AI generates canary content that matches an environment's real naming conventions and credential formats specifically to avoid this.

Manual placement. Pasting a token into repository secrets by hand doesn't scale past a handful of repositories, and it leaves the canary to go stale — nobody revisits it once it's placed. Both Community Edition's GitHub Action and the paid platform's Terraform integration automate this so it doesn't depend on someone remembering to redo it.

Detection by the attacker's own tooling. This is a real and ongoing fight, not a solved problem. Public credential-scanning tools like TruffleHog ship with logic to recognize specific vendors' canary AWS tokens and skip them automatically — it works out the AWS account ID from the access key ID and checks it against a known list, a trick that currently catches Thinkst's canary tokens specifically. Asked directly about this on r/netsec, Tracebit confirmed their tokens aren't on that list yet, and noted a structural reason why staying ahead of it is easier for them: Tracebit's canary credentials refresh regularly from its API, so rotating the underlying account ID in response is transparent to the user rather than requiring a redeployment. A canary that never changes is a canary that eventually gets fingerprinted; one built to rotate has a real answer when that happens.

Conclusion

Detecting a CI/CD supply chain attack doesn't require inspecting build traffic or installing anything on a runner — it requires a fake credential sitting where a real one would be, and a way to know the moment it's touched. Tracebit Community Edition gets that running in a single workflow in minutes at no cost; the paid platform extends the same mechanism across every repository and every environment a pipeline touches, with the alert routing and automatic rotation that manual token placement can't keep up with on its own.

Talk to the Tracebit team to see how this applies to your environment.

FAQ

Will a canary credential slow down my GitHub Actions builds?
No. It's a credential sitting in the job environment, not a network proxy or an agent watching the build. Nothing about deploying it touches build performance.
How quickly can this be deployed?
Tracebit Community Edition's GitHub Action can be added to a workflow in minutes. Scaling the same approach across many repositories and cloud environments with the paid platform typically takes under 30 minutes for an initial deployment.
Is there a risk that a canary credential leaks real information if an attacker steals it?
No. Canary credentials are fabricated — an attacker who exfiltrates and uses one gets nothing of value. The point isn't to protect the credential itself, it's that using it anywhere triggers an alert.
Can sophisticated attackers detect and skip canary credentials?
Some try. Public tools like TruffleHog include logic to recognize known canary AWS tokens and skip them during automated secret-scanning. It's a real cat-and-mouse dynamic — vendors whose tokens get fingerprinted have to keep changing the underlying pattern to stay ahead of detection.