The Amsterdam Pipeline That Ate Its Own Tokens

Our Amsterdam SaaS runs a large monorepo. We use a popular build system, and an engineer had once asked an AI assistant for a 'build cache utility' to speed up our pipelines. It suggested a package. We added it to a devDependency in one workspace, forgot about it, and it sat there for a year.

Then a wave of supply-chain attacks hit that build system's ecosystem. The attackers didn't use our hallucinated package — they exploited a misconfigured CI workflow trigger to steal a real publishing token. But the reach of that stolen token is what got us. One of our transitive dependencies was published by a maintainer whose token leaked in that wave. A poisoned version landed in our lockfile overnight.

We caught it because our dependency lockfile diff review flagged an unexpected version bump. By then the poisoned version had been installed on three CI runners. The payload scraped the runners' environment — including our deploy tokens, our package registry credentials, and the webhook secret for our status dashboard.

We rotated everything. We locked the build system to a single pinned version. We removed the hallucinated cache utility too, because by then we understood: the hallucination and the real attack were the same shape. An attacker doesn't need to compromise a famous maintainer if a model will hand them a fresh name that nobody has audited.

The Amsterdam canal outside our office is calm. Our pipelines are calmer now. But the lesson stayed: a dependency nobody remembers is a dependency nobody watches.