The Anatomy of a Modern Supply Chain Attack
A redacted walkthrough of a real-world supply-chain compromise ARIA caught in 240ms — and what teams must change to defend against the next one.
In February we watched ARIA isolate a supply-chain compromise across a customer's CI/CD plane in 240 milliseconds. The customer has graciously allowed us to publish a redacted walkthrough. Names, regions, and exact timestamps have been changed; everything else is real.
The setup
The customer was a multi-region SaaS company. Standard stack: GitHub, GitHub Actions, ArgoCD, EKS, AWS KMS. They had been on SpectraShield for nine months. ARIA was in enforcement mode with hardware attestation enabled across all build workers.
T-72h: the breadcrumb that mattered later
A new transitive dependency landed in a developer's PR. ARIA's policy engine flagged it as 'new in last 30 days' — a soft warning that the developer cleared. The dependency was a typosquatted name, two characters off the legitimate package. We saved the metadata anyway.
T-0: the actual attack
The poisoned dependency activated during a build worker's runtime. It tried to mint a new GitHub Action secret using an OAuth token that should have been short-lived but wasn't.
ARIA's 240ms decision
ARIA caught it on three independent signals: (1) the workload's behavioral graph diverged from the historical baseline, (2) the OAuth token usage didn't match the build profile, and (3) the new dependency's hash didn't match its public registry attestation. ARIA isolated the build worker, paused the pipeline, and notified the security team in under 250ms total.
What we learned
- Soft warnings matter. The developer's PR-time warning became gold three days later.
- Hardware attestation closes the runner-spoof attack class entirely.
- Behavior graphs beat IOC matching. ARIA never saw this attack pattern before.