StepSecurity Says It Tracked 56 Open-Source Supply-Chain Compromises in 12 Months

Security researchers at StepSecurity say their threat-intelligence team tracked and alerted on 56 distinct software supply-chain compromises over the previous 12 months. The report, published on 22 August 2026, counts malicious compromises of previously trusted packages, GitHub Actions, and developer tooling while excluding ordinary vulnerabilities, unconfirmed incidents, and newly created malicious or typosquat packages. StepSecurity says it tracked six incidents from August 2025 through January 2026 and 50 since February 2026, figures that describe the company's own incident archive rather than an independent census of open-source supply-chain attacks.

The report says the incidents crossed several package ecosystems and development tools, including npm, PyPI, RubyGems, Composer, Rust crates, GitHub Actions, and IDE extensions. StepSecurity identifies three recurring weaknesses across the incidents: credentials available in CI or developer environments, mutable or unpinned references, and unrestricted outbound network access. The company also sells products intended to address those areas, so both the incident count and its broader interpretation require clear attribution.

The Laravel-Lang compromise in May provides a directly relevant Composer example. A 22 May incident analysis from StepSecurity says an attacker rewrote existing Git tags across four Composer packages so the tags pointed to malicious commits. A separate advisory from Snyk reported that an injected file was registered through Composer's autoload.files mechanism, allowing malicious code to load automatically after installation.

StepSecurity said projects with existing composer.lock files that pinned known-good commits from before the compromise remained safe if they continued installing from those lockfiles. The incident analyses do not identify Drupal as affected, but the mechanism is relevant to Drupal teams because Composer is part of the dependency chain in Drupal projects. The example shows how trust placed in an existing package and its release references can become a build-time security boundary.

StepSecurity's broader report also describes attacks in which compromised packages or automation targeted credentials available to CI runners and developer environments. Its examples include poisoned GitHub Action tags, malicious package releases, and self-propagating campaigns that reused stolen publishing or development credentials. Those cases support scrutiny of dependencies and automation before code reaches production, but they do not establish that any Drupal project, Drupal.org service, or Drupal contributed module was among the 56 compromises.

For Drupal teams, the evidence supports a narrow conclusion rather than an ecosystem-wide alarm. The Laravel-Lang case demonstrates that a trusted Composer dependency can become malicious and that an existing lockfile can affect exposure to a compromised release. StepSecurity's wider archive shows similar trust failures across other package and automation systems, but its 56 incidents remain a company-tracked dataset rather than a measurement of all open-source supply-chain attacks.