This week at a glance
The dominant story is a supply-chain compromise that reads like a worked example of transitive trust failing. An automation token belonging to the Trivy security scanner leaked and sat unrevoked for roughly twenty days; Team PCP used it to force-push malicious code over Trivy’s published version tags — 76 of 77 tags, by StepSecurity’s count. LiteLLM‘s release pipeline installed Trivy unpinned from the system package manager, so the poisoned scanner walked straight into LiteLLM’s build environment and produced two malicious releases, 1.82.7 and 1.82.8, live on PyPI for about forty minutes. That was long enough: a .pth file executed at Python interpreter startup, bypassing --ignore-scripts and running wherever the package was merely installed. Google tracks the resulting credential stealer as SANDCLOCK. CloudSEK puts the exposure at 2,500-plus organisations and 434,000 CI/CD pipelines; StepSecurity, working the same campaign from the pipeline side, counted 78,330 secrets stolen from 2,186 organisations between 19 and 24 March — GitLab pipelines worst hit at 1,064 organisations, GitHub Actions at 618, Azure DevOps at 233. Three tools deep from a single unrevoked token, and the FBI’s July FLASH advisory warns the harvested credentials will be weaponised long after the original intrusion.
The tooling response this week was unusually concrete. StepSecurity’s argument on registry control is that an internal registry can only log the requests that reach it — it has no record of the CI jobs and laptops that went around it, which is exactly the path axios, litellm and @bitwarden/cli took. Their answer is behavioural: watch the actual outbound calls during a job rather than trusting the workflow’s declared registry, read .npmrc and pip.conf on developer machines to find the effective registry, and block at the network layer so a fallback fails loudly instead of silently resolving from the public index. The same defence list keeps recurring across this week’s writing — pin dependencies and Actions to immutable commit SHAs, shorten credential lifetime, prefer workload identity to static keys, and run a cooldown before a new version is installable at all. GitHub’s Dependabot cooldown, OpenSSF’s dependency-firewall primer, and GitHub’s own npm and Actions hardening work sit in the foundational section for exactly that reason; StepSecurity notes a cooldown alone would have blocked all three of this year’s cited compromises. Provenance is the other half: The New Stack’s piece on unsigned container images argues scanning tells you what is inside an artifact but never who built it, a distinction that stops being academic once model weights and inference runtimes ship as containers. CSO Online’s contribution is that most of the forged-identity and tag-poisoning signal is already sitting in GitHub’s event stream, unread.
Regulation caught up with the same theme. OpenSSF’s CRA practitioner guide moves the EU Cyber Resilience Act from policy interpretation to operational work — a September 2026 reporting deadline, full compliance in December 2027, and obligations that reach upstream into SBOM and provenance practice rather than stopping at your own product boundary. Mozilla’s GPG signing-key rotation after an exposure is the small, well-handled version of the same discipline.
The rest of the week is about what AI-authored code costs downstream. Addy Osmani names the missing thing intent debt: agents can restore code cheaply and can even restore understanding, but they cannot generate the rationale for why a guard clause exists — they will remove it and produce a plausible explanation afterwards. Point several agents at a codebase and you have hired junior teammates with no institutional memory, all needing intent re-supplied. O’Reilly’s other piece argues the same from the defensive side: scanners and faster response are not a strategy when the base was architected without security in the room. GitHub’s report from 50 funded open source projects lands on the reconciling line — AI helps maintainers investigate and prioritise faster, but the maintainer still supplies context, judgement and accountability for what ships. Alongside that: Anthropic now runs Claude Code on daily maintenance of its own software at a 46 percent merge rate, Alibaba published sixteen days of autonomous Qwen commits for public audit, developer resistance to AI gets reframed as identity rather than fear, and the ASSET Research Group’s GhostSplice shows a malicious MCP server can split a harmful instruction across tool descriptions and results so each fragment reads as benign — agent compliance jumping from 42 percent to 82 percent when the instruction is fragmented. Underneath it all, CNCF asks the question nobody has settled: when the AI pipeline breaks, is that platform engineering’s problem or the ML team’s?
This week’s topic map — the Team PCP / LiteLLM compromise at the centre, with the chain out through Trivy, the unrevoked automation token, SANDCLOCK and the 78,330 stolen secrets; the guardrail cluster of registry control, network egress filtering, SHA pinning, dependency firewalls and Dependabot cooldown (StepSecurity, GitHub, OpenSSF); the provenance and regulation cluster around SBOMs, container image signing, Sigstore and the EU Cyber Resilience Act; and the AI-authored-code cluster covering review burden, intent debt, Claude Code, MCP and GhostSplice, running back into platform engineering and Kubernetes.
View interactive topic map →
Article index
Weekly News
Supply-chain compromise & response
One unrevoked token, three tools deep: the LiteLLM / Team PCP campaign from both the exposure side and the pipeline side, plus this week’s other trust failures — poisoned IDE extensions, a fragmented-instruction attack on MCP-connected agents, and the argument that GitHub’s own event stream already shows you the intrusion.
| Article |
Source |
Published |
| 1. 2,500+ Companies and 434,000 CI/CD Pipelines Exposed in Largest AI Supply Chain Breach of 2026 |
CloudSEK |
Aug 11, 2026 |
| 2. Team PCP Stole 78,330 Secrets From 2,186 Organizations |
StepSecurity |
Aug 13, 2026 |
| 3. Solidity Pro VS Code Extensions Steal Crypto Wallets, API Keys, Credentials |
The Hacker News |
Aug 10, 2026 |
| 4. Malicious MCP Servers Can Split Instructions to Make AI Coding Agents Exfiltrate Secrets |
The Hacker News |
Aug 11, 2026 |
| 5. GitHub already has an EDR. You just have to listen to it |
CSO Online |
Aug 11, 2026 |
Pipeline guardrails & provenance
The controls that would have caught it: knowing which registry your CI jobs and laptops actually reach, signing artifacts so provenance survives the pull, testing safely against production behaviour, and what fifty funded open source projects learned about securing the base layer everyone else depends on.
Regulation & disclosure
The EU Cyber Resilience Act stops being a reading exercise this September, and Mozilla shows what routine, well-handled key-exposure disclosure looks like.
AI-authored code and the review burden
What agent-written code costs downstream: the rationale it cannot supply, the review capacity it consumes, the identity it unsettles — and two experiments (Anthropic’s own maintenance runs, Alibaba’s sixteen-day audit trail) putting numbers against the claim.
Platform ownership
Who is accountable when the AI pipeline breaks — the ownership question CNCF puts to platform teams, a self-healing Kubernetes upgrade path as the automated end state, and the observability gap that makes LLM apps fail invisibly in production.
Foundational reading
Background that makes this week’s compromise legible: how the npm and GitHub Actions ecosystems are being hardened, why a waiting period before installing a new version is now a control, what a dependency firewall does, and the emerging control set for governing coding agents — including a live test of an AI agent trying to social-engineer a maintainer into merging malware.
Detailed write-ups
1. 2,500+ companies and 434,000 CI/CD pipelines exposed in the largest AI supply-chain breach of 2026
CloudSEK · August 11, 2026
CloudSEK’s reconstruction of the March compromise of LiteLLM is the clearest account yet of how far a single unrevoked credential travelled. An automation token for the Trivy security scanner leaked and stayed live for roughly twenty days. Team PCP used it to force-push malicious code over Trivy’s published version tags, poisoning the scanner itself. LiteLLM’s release pipeline then installed Trivy unpinned from the system package manager, so the compromised scanner flowed automatically into LiteLLM’s build environment and produced two poisoned releases, 1.82.7 and 1.82.8, published to PyPI in a window of about forty minutes. The payload was a malicious .pth file, which Python executes at interpreter startup — meaning it ran wherever the package was merely installed, and sailed past --ignore-scripts protections entirely. Checkmarx KICS was compromised in the same campaign.
The malware — tracked by Google as SANDCLOCK — escalated to root and harvested SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens and service accounts, CI/CD environment variables, LLM API keys and AI gateway configuration, private repositories and build artifacts. Stolen material was encrypted with AES-256 and RSA-4096 and either exfiltrated to typosquatted domains or, in a nicely humiliating twist, uploaded as release assets to the victims’ own GitHub accounts, making the secrets public. CloudSEK’s high-confidence victim sample gives a sense of scale: X Corp with 3,459 secrets across 1,153 runs, Orange with 180 secrets across 5,642 runs, Cisco with 327 across 1,900, Volkswagen with 2,242 affected runs. LiteLLM disclosed on 24 March; the FBI issued FLASH advisory FLASH-20260702-01 on 2 July warning that affiliated actors are likely to weaponise the harvested credentials long after the original intrusion. CloudSEK’s central remediation point deserves repeating, because it is the one teams get wrong: rotating the LiteLLM key is not enough. Any credential readable by the affected process — cloud, repository, registry, Kubernetes, SaaS, database, AI — needs rotating, affected runners and images need rebuilding from clean sources, and audit logs need reviewing for new service accounts and unfamiliar egress.
Sources: CloudSEK (LiteLLM AI supply-chain breach)
2. Team PCP stole 78,330 secrets from 2,186 organisations
StepSecurity · August 13, 2026
StepSecurity’s disclosure, published alongside CloudSEK’s, works the same campaign from inside the pipeline. Between 19 and 24 March 2026, Team PCP exfiltrated 78,330 secrets from the CI/CD pipelines of 2,186 organisations, a victim set whose combined market capitalisation exceeds $6 trillion. The group ran a repeatable four-step cycle: compromise a trusted open source project — an action, a package, a maintainer account; execute a credential stealer whenever a pipeline references the compromised component; exfiltrate to command-and-control; then pivot, using the stolen credentials to reach the next target. Trivy was the standout, with 76 of its 77 version tags compromised, alongside Checkmarx KICS, LiteLLM, and telnyx, where the payload was hidden using WAV steganography.
The platform breakdown is the detail worth carrying into a planning conversation: GitLab pipelines were hit hardest at 1,064 organisations, ahead of GitHub Actions at 618 and Azure DevOps at 233, with Jenkins and others also targeted. What came out reads like a worst case — 999 organisations leaked JWT session tokens, 480 exposed private key blocks, 320 gave up AWS access keys, 308 leaked GitLab personal access tokens, 183 leaked GitHub PATs, and 157 lost OpenAI API keys. StepSecurity’s detections were behavioural rather than signature-based: outbound connections to first-ever destinations, memory-scraping process behaviour, and imposter-commit analysis that surfaces commits reachable by SHA but belonging to no branch — the exact artefact left behind by tag poisoning. Their recommended stack is prevention (network egress filtering, runner lockdown, workflow run policies, pinning to immutable commit SHAs), detection (behavioural monitoring, imposter-commit analysis), and response (rotate now, audit access logs back to 19 March).
Sources: StepSecurity (Team PCP campaign disclosure)
3. Control which package registries your CI jobs and developer machines actually use
StepSecurity · August 11, 2026
This is the operational companion to the disclosure above, and it opens on a blind spot most teams have without knowing it. Organisations migrate package downloads from npmjs.org and pypi.org to an internal registry, then measure success by the internal registry’s logs — which, as StepSecurity puts it, records the requests that came to it and has no record of the jobs and developer machines that went around it. That bypass path is precisely the one the axios, litellm and @bitwarden/cli compromises travelled: straight from a public registry to whatever machine ran the install.
The fix is two behavioural controls rather than a policy document. On the CI side, Harden Runner watches the actual outbound network calls a job makes instead of reading what the workflow declares, which catches the common failure where a job nominally targets a private registry but silently falls back to the public one; blocked attempts are recorded too, with attribution down to the process that triggered them. On the developer side, Dev Machine Guard reads .npmrc and pip.conf to establish each package manager’s effective registry, evaluated per device-and-tool pair, and distinguishes a built-in default from a user override from an explicit public-registry setting — three findings that need three different fixes. Device identifiers appended to registry API keys tie every request back to its source. The practical advice: run both controls against your current estate before changing anything to get a real baseline, treat the failed-check count as a migration metric to drive down quarterly, block at the network layer in CI so a fallback fails loudly rather than silently, push registry configuration centrally through device policy, and apply cooldown at the internal registry — a mechanism StepSecurity notes would on its own have prevented all three of the 2026 compromises they cite.
Sources: StepSecurity (package registry control)
4. Your container images are unsigned — and in the AI era that is a ticking time bomb
The New Stack · August 14, 2026
The argument turns on a distinction that scanning cannot close: a vulnerability scan tells you what is inside an image, but nothing about who produced it or whether it has been tampered with since. That gap has always been uncomfortable; it becomes acute once AI artifacts — model weights, training datasets, inference runtimes — ship as containers with no integrity verification attached. The piece frames the asymmetry sharply: a tampered application image defaces a page, whereas a tampered model artifact corrupts predictions at scale, quietly and for as long as it runs. The precedents are already on record: in February 2024 JFrog researchers found roughly 100 genuinely malicious PyTorch models on Hugging Face, one of which opened a reverse shell the moment it loaded by abusing pickle’s __reduce__ hook; by February 2025 ReversingLabs had documented “nullifAI”, models that evaded static analysis through compression and corruption, removed within 24 hours but not before demonstrating the technique.
Client-side signing tools exist — Cosign, the Notation CLI — but the author’s point is that adoption stalls because they hand every team the job of managing signing keys, certificates and rotation schedules themselves. Hence the case for registry-managed signing, with Amazon ECR Managed Signing as the worked example: signing happens at the registry, asynchronously so it does not sit in the push path, key custody leaves developers and pipelines entirely, and revocation gives a fast answer to a compromised identity. None of that helps without the other two legs, though, and the article is clear that all three are required — sign with a verifiable identity, verify against a trust policy at pull time, and enforce through an admission controller (Kyverno, or Gatekeeper with Ratify) that refuses to run an unsigned or untrusted image. The OCI Referrers API is what makes the signature discoverable alongside the artifact.
Sources: The New Stack (unsigned container images in the AI era)
5. CRA readiness: a practitioner’s guide to compliance
OpenSSF · August 11, 2026
OpenSSF’s framing is that the EU Cyber Resilience Act has moved past the interpretation stage and into execution, with two dates that matter: a September 2026 reporting deadline and December 2027 for full compliance. The Act reaches any organisation that builds, distributes or commercialises software with digital elements, which is a wider net than many teams assume — the first practical task is simply establishing whether what you ship counts as a product with digital elements at all, and whether you are acting as a manufacturer or, in the open source case, a steward. From there the obligations are the familiar supply-chain set given legal weight: software supply-chain transparency, SBOM and provenance practice hardened to the point of being auditable, vulnerability management and coordinated disclosure processes that actually run, and — the part organisations tend to underestimate — engagement with the upstream open source projects they depend on, because the transparency requirement does not stop at your own product boundary.
The guide is deliberately operational rather than legal: peer-tested strategies, member case studies, and a newly launched Launchpad SIG collecting actionable resources, tools and practices, coordinated through the Global Cyber Policy Working Group. For a DevSecOps team the sequencing is straightforward even if the work is not — scope determination first, then a supply-chain framework with SBOM and provenance generation wired into the build rather than produced on request, then the disclosure and reporting machinery in time for September. Read alongside this week’s compromise coverage, the CRA is essentially legislating the controls the LiteLLM incident showed were missing.
Sources: OpenSSF (CRA readiness guide)
6. The intent debt
O’Reilly Radar · August 14, 2026
Addy Osmani adds a third category to Margaret-Anne Storey’s triple debt model. Technical debt lives in the code; cognitive debt lives in people’s heads; intent debt is the absence or erosion of the externalised rationale, goals and constraints that explain why a system is the way it is. The distinction matters because AI changes the economics of the first two and not the third. An agent will refactor cheaply, and can even help rebuild lost understanding of what code does — but it cannot generate intent, because intent is the one input that has to come from a human. What it will do instead is produce a plausible-sounding rationale, which is worse than silence: a fabrication that reads like institutional memory.
The failure modes Osmani describes will be recognisable to anyone reviewing agent output: an agent “fixes” a bug by deleting a guard clause whose purpose was never written down; a refactor changes behaviour users depend on because the intent was never encoded in a test; services communicate over a queue for a reason nobody recorded. The multiplication effect is the part that turns this from an annoyance into a review-burden problem — running several agents at once is hiring several junior teammates with no institutional memory, each needing intent re-supplied that a small team used to carry informally. Intent debt accrues quietly, through helplessness rather than obvious friction. His conclusion is a reasonably hopeful one for human engineers: externalising the “why” is the most valuable thing left to do, and the practices follow directly — write specifications that capture goals and constraints rather than implementations, treat intent documentation as a first-class artifact, keep decision logs recorded as decisions happen, and let self-improving agents document what they learn. It is the only debt category AI cannot pay down on its own.
Sources: O’Reilly Radar (Addy Osmani, “The Intent Debt”)
Calls to action
- Rotate broadly, not narrowly. If LiteLLM 1.82.7 or 1.82.8 touched any build between 19 and 24 March, rotate every credential the affected process could read — cloud, repository, registry, Kubernetes, SaaS, database, AI keys — not just the obvious one, and rebuild affected runners and images from clean sources.
- Audit back to 19 March. Review source-control, registry, cloud and cluster audit logs for new service accounts, unfamiliar egress destinations, unexpected release assets on your own repositories, and tokens you did not issue.
- Find out which registry your jobs actually reach. Measure outbound calls during CI runs and read
.npmrc / pip.conf on developer machines. Then block at the network layer so a public-registry fallback fails loudly instead of resolving silently.
- Pin to immutable SHAs and add a cooldown. Pin Actions and dependencies to commit hashes, enable Dependabot’s cooldown window, and consider a dependency firewall in front of the public indexes — a cooldown alone would have blocked all three of this year’s cited compromises.
- Sign your images and enforce it at admission. Signing without verification is theatre. Pair Cosign or Notation (or registry-managed signing) with an admission controller that refuses unsigned or untrusted images — and extend it to model and inference artifacts, not just application images.
- Start CRA scoping now. September 2026 reporting is close. Determine whether you are a manufacturer or steward, wire SBOM and provenance generation into the build rather than producing them on request, and check your coordinated-disclosure process actually functions.
- Vet your MCP servers. Treat MCP server output as data, never as instructions, and stop values from one tool’s output flowing into another tool’s arguments. Review which third-party servers your agents are connected to and what file permissions they hold.
On our watch list
- Credential weaponisation lag. The FBI’s FLASH advisory expects Team PCP’s harvested secrets to be used long after March. Watching for second-stage intrusions traceable to unrotated March credentials, and for the campaign’s next compromised upstream.
- Security tooling as the attack path. Trivy and Checkmarx KICS were compromised precisely because build pipelines trust scanners implicitly and install them unpinned. Watching whether teams start pinning their security tooling with the same discipline they apply to application dependencies.
- Registry egress control as a default. Behavioural verification of which registry a job reaches is currently a vendor capability. Watching whether it becomes a standard CI platform feature rather than an add-on.
- Signing adoption beyond application images. Registry-managed signing lowers the operational cost meaningfully. Watching whether model weights and inference runtimes get pulled into the same trust policy, and how many teams actually turn on admission enforcement rather than signing and stopping there.
- CRA enforcement reality. September’s reporting deadline is the first real test. Watching what upstream open source stewards are expected to produce in practice, and whether SBOM quality — not just SBOM existence — becomes the compliance question.
- Intent as a reviewable artifact. Osmani’s argument implies specs and decision logs become part of the diff. Watching whether review tooling starts treating missing rationale as a blocking finding the way it treats missing tests.
- Agent-run maintenance at scale. Anthropic’s 46 percent merge rate on daily Claude Code maintenance and Alibaba’s sixteen-day public Qwen commit log are the first real datasets on autonomous maintenance. Watching what the rejected 54 percent turns out to consist of.
- Fragmented-instruction attacks on agents. GhostSplice raised compliance from 42 to 82 percent simply by splitting the request. Watching whether model providers ship cross-channel instruction reassembly defences, or whether this stays an integration-hygiene problem.
- Who owns the AI pipeline. CNCF’s ownership question is unresolved and increasingly consequential for on-call. Watching whether platform engineering absorbs LLMOps, or whether a separate accountable function emerges.
|