Threat context / Reviewed 15 September 2026

What follows a compromised dependency?

A malicious upload, a compromised publishing identity and a compromise of registry infrastructure are different events. The distinction changes the testing question.

These dated editorial notes connect primary-source incident reporting to useful scoping questions. Publication dates and event dates are stated separately; the npm example is historical context.

RubyGems: distinguish malicious uploads from a successful compromise

Registry update · published 11 September 2026 · activity in May 2026 · reviewed 15 September 2026

RubyGems says newly registered accounts published malicious packages during a May spam campaign. The registry removed the accounts and packages and temporarily paused registrations. It found no evidence that code intended to obtain other users’ API keys succeeded. Its update also says the available evidence does not establish whether AI agents created or published the packages.

For dependency owners, this raises a practical question: which review and execution controls apply before newly published code reaches a build or runtime? A malicious upload, successful credential theft and compromise of the registry itself are different claims.

Source: RubyGems.org, An update on the May spam-publishing campaign

npm: what a compromised publishing identity can reach

Historical incident context · GitHub notified 14 September 2025 · published 22 September 2025 · reviewed 15 September 2026

GitHub’s account of Shai-Hulud describes compromised maintainer accounts and malicious package scripts that stole secrets and helped the campaign spread. This is a different entry path from newly created malicious packages: a dependency’s familiar name does not establish that a later release is trustworthy.

A useful preparation step is to map where dependencies execute, which credentials are available there and what other systems those identities can reach. An assumed-breach exercise can then examine agreed downstream consequences; it does not establish whether the organisation would have prevented the original dependency compromise.

Source: GitHub, Our plan for a more secure npm supply chain

SilentGrid is developing supply chain compromise scenarios. An exercise that starts with an assumed foothold can examine agreed downstream actions and defensive response. It cannot establish whether the initial compromise would have been prevented. Scenario availability and inclusion require agreement.