Your deploy box is the target: supply chain defenses after this week's attacks

A developer, responding to two supply chain attacks reported in November, audited their own CI configuration and found a single build job holding a registry token, deploy key and cloud credential at once. The attacks included a stolen developer key that pushed a dropper into @ethersphere/bee-js 13.3.0 via the normal publish workflow, and a fresh GitHub account that opened CI exfiltration PRs, added an AGENTS.md note telling reviewers not to flag the uploads, and shipped a Rust crate whose build.rs harvested credentials. The developer's proposed fix splits builds from deploys so dependency-installing jobs carry no deploy credentials.

I read the OpenSourceMalware report on Tuesday and then did something simple. I opened my own CI config and listed every secret a single build job could see. The attack it describes starts with a PR from a brand new account labeled "CI diagnostics" that sends environment variables to a remote URL. The answer was uncomfortable. A build job on my side holds a registry token, a deploy key and a cloud credential, all in one shell. That is exactly the shopping list attackers wrote down this week. | What happened | Date | What it means for you | |---|---|---| | A stolen developer key pushed a dropper into @ethersphere/bee-js 13.3.0, and the publish workflow shipped it to npm and GitHub | Nov 9 | Your release pipeline will publish whatever a valid key commits | | A brand new GitHub account sent CI exfiltration PRs, a prompt injection for reviewers and a Rust crate with a build.rs stealer | Nov 10 | Build scripts and PR checks run with your secrets in reach | | Socket's hardening guide says most 2025 and 2026 CI compromises came through npm install , not workflow bugs | Nov 3 | Install time is the weak spot, so lock it down first | OX Security reported on November 9 that attackers likely used a stolen developer access key to commit malicious code to the official bee-js and swarm-desktop repositories. The commit triggered the normal publish workflow, which created the npm release and the GitHub release. No one broke into the registry. The pipeline did its job with a bad commit. The dropper then asked a command server for a payload matched to the victim's operating system. It uploaded the local Swarm node's encrypted key and config, then installed a backdoor. On Linux and macOS the backdoor looks up its server address from an Ethereum contract, so the attacker can move it whenever they like. OX counts about 16,800 monthly downloads of exposure. That is small. The pattern is not. The second attack, written up by OpenSourceMalware on November 10, came from a GitHub account created about seven hours before the report. It ran four moves in a row. Two PRs tried to send environment variables and signing material out of CI. A third PR added a paragraph to AGENTS.md telling reviewers, including automated ones, not to flag those uploads. Another PR added a Rust crate, lwd-uri-util , whose build.rs gathers .git-credentials , .aws/credentials and .npmrc . Finally, a fake security disclosure sent two maintainers to a cloned sign-in page. Read that list again if you deploy code. The target is not your app. The target is the box where your app gets built. A typical CI job carries a registry push token, a cloud credential and a deploy SSH key. It also runs arbitrary install scripts from hundreds of transitive packages. One malicious postinstall or build.rs inherits all of it. The OpenSourceMalware report lists what the Rust stealer wants: GitHub, AWS, Cargo, npm, PyPI, Android signing keys and CI secrets. Its advice for anyone who built the affected branches is to revoke and reissue every secret present in that build environment. That is a long afternoon. The cheaper move is to make sure the build never holds most of them. Here is the rule I now apply. A job that installs dependencies gets no deploy credentials. A job that deploys installs nothing. name: release on: push: tags: "v " permissions: {} jobs: build: runs-on: ubuntu-latest permissions: contents: read steps: - uses: actions/checkout@<full-40-char-sha with: persist-credentials: false - run: npm ci --ignore-scripts - run: npm run build - uses: actions/upload-artifact@<full-40-char-sha with: name: dist path: dist/ deploy: needs: build runs-on: ubuntu-latest environment: production holds the deploy secret, needs approval steps: - uses: actions/download-artifact@<full-40-char-sha with: name: dist - run: ./scripts/push-release.sh env: DEPLOY TOKEN: ${{ secrets.DEPLOY TOKEN }} The build job sees no secret at all. The deploy job installs nothing, so a poisoned dependency never runs next to the token. The production environment can require a human approval before the second job starts. Socket's guide makes a point I keep repeating to people. Version tags are movable pointers. In the tj-actions/changed-files attack, pinning by commit SHA kept every repository safe. In the March 2026 trivy-action incident, Socket reports 75 of 76 version tags were force-pushed. A SHA proves the content cannot change. It does not prove where the commit came from, because impostor commits from forks can still resolve. Pin, and read the diff when you bump. Images work the same way. A tag like node:22 is a pointer. A digest is content. resolve once, on a machine you trust docker buildx imagetools inspect node:22-slim | grep Digest Digest: sha256:<64 hex chars then pin it in the Dockerfile FROM node:22-slim@sha256:<64 hex chars Do the same for the images you run, not only the ones you build. In a compose file: services: web: image: registry.example.com/team/web@sha256:<64 hex chars I also keep to upstream-only namespaces. Pull library/postgres or the vendor's own namespace, not a lookalike from a stranger. Even a real namespace can be hijacked, so digests matter more than names. Names only remove the cheapest attacks. Socket cites a Wiz estimate that a 7 to 14 day cooldown catches 80 to 90 percent of supply chain attacks, and notes Dependabot applies a three day cooldown by default on github.com. Ethersphere reverted the bad npm version only after it shipped. If your lockfile refuses anything published in the last week, you skip most of that window. .npmrc ignore-scripts=true min-release-age=7 Scripts then run only where you allow them. Check your npm version supports the release-age key before you rely on it, since Socket describes it as a setting for .npmrc and your update bot. Socket calls the write-scoped GITHUB TOKEN the usual escalation step from a foothold to a real incident. Set permissions: {} at workflow level, as in the example above, and grant per job. Avoid pull request target with untrusted code. Pass PR titles through env: instead of inlining them in run: blocks. Run zizmor in CI to catch the rest. Then treat registry tokens the same way. A publish token that only works for one package, with a short life, turns a stolen key into a small problem. The Ethersphere case shows the other side: a long-lived developer key plus an automatic publish workflow equals a release anyone with the key can ship. The last layer is the one most people skip. When the stealer cannot reach its server, it collects secrets and has nowhere to put them. The Rust crate uploads to a public webhook endpoint. The Ethersphere dropper called a fresh .xyz domain registered two days earlier. A deny-by-default outbound list blocks both. Socket's advice is to run an egress agent in audit mode first, build the allowlist from real traffic, then enforce. Socket also admits the limit: allowlisting cannot stop exfiltration to hosts you must allow, such as github.com . Egress is a way to cut damage, not a wall. On the server that runs your apps, the same idea applies at runtime. If the web container only talks to your payment API, say so. We built outbound allowlists and image pinning into Levelrail for the deploy side. Per the docs, Levelrail pins an image pulled from a registry to its digest at deploy time, APP IMAGE VERIFY MODE=enforce refuses unsigned or unpinned images on promotion, and a service can declare an egress allowlist of host and port pairs. Two honest limits from the same docs: without the egress block the outbound traffic is open, and signature checks support cosign key pairs, not keyless signatures. Build-time secrets are opt in per secret for that reason. I did five things, in order of effort. npm ci . ignore-scripts . permissions: {} as the workflow default. None of it takes more than a day. The attacks this week were small: about 16,800 monthly downloads and one wallet-focused crate. The same techniques against a package with millions of installs would look different. Attackers are skipping your code and going for the machine that builds and ships it. Split install from deploy, pin by digest, add a cooldown, shrink token scopes and limit outbound traffic. How many secrets does your slowest, most neglected CI job hold right now?