StepSecurity counted 56 supply chain attacks, all from its own alerts

Why it matters

StepSecurity's case set cannot establish the global attack rate, but its observed acceleration from six incidents to 50 shows how quickly credential theft and self-propagating malware are moving into trusted build systems. Sharma is using those findings to expand StepSecurity from GitHub Actions monitoring into security for the full software delivery path.

StepSecurity CEO and co-founder Varun Sharma published the security vendor's first annual threat report on August 22, counting 56 malicious open-source supply chain compromises over the preceding 12 months. StepSecurity's report counts 56 incidents in its own alerting universe, not every open-source supply chain attack worldwide. Every incident had generated an alert for StepSecurity customers, making the total a record of what Sharma's threat intelligence operation caught rather than an independent census of the industry.

The report's value is the consistent case set: it shows how the incidents StepSecurity tracked changed over the period and how those findings informed the company's product expansion.

Sharma spent nearly 15 years at Microsoft and led Azure's Green Team, which worked on systemic security problems, before starting StepSecurity with Ashish Kurmi. Kurmi previously held security engineering roles at Microsoft, Uber and Plaid. The founders say the SolarWinds and Codecov breaches pushed them to build protections for CI/CD pipelines, an area they believed sat exposed between established application and cloud security products. A Black Hat biography identifies Sharma as a former Microsoft principal security software engineering manager and leader of Azure's Green Team.

A narrow count with a useful denominator

Sharma defined the sample to include confirmed compromises of components that developers already trusted. The report covers malicious releases on npm, PyPI, RubyGems, Composer and crates.io, along with poisoned GitHub Action tags and compromised IDE extensions.

StepSecurity excluded conventional software vulnerabilities, suspicious activity that was never confirmed, and packages that were malicious from their first release, including typosquats and name-confusion packages. The methodology is designed to measure attackers taking over existing trust, rather than the much larger flow of malicious packages uploaded under new names.

The resulting timeline shows a sharp change inside StepSecurity's coverage. Sharma reported six incidents from August 2025 through January 2026, followed by 50 from February onward. March had 13, April and May had nine each, June had 10 and July had six. StepSecurity describes the pace since March as roughly one confirmed attack every three days.

Those figures establish the rate at which StepSecurity's analysts confirmed incidents and issued customer alerts. The sample will miss attacks outside StepSecurity's visibility, while naturally leaning toward the registries, developer tools and CI/CD systems that its researchers monitor. It remains useful for tracing changes within a fixed security operation over time.

The largest change in Sharma's account is the arrival of self-propagating campaigns. A compromised maintainer account can expose every package that maintainer controls. Stolen credentials can then give attackers access to another set of packages, repositories and build systems. StepSecurity traces that pattern through the Shai-Hulud family, CanisterWorm, Miasma and ChainDrop.

The report's biggest number needs a qualifier

StepSecurity's report says the Team PCP campaign stole 78,330 secrets from the CI/CD pipelines of 2,186 organizations during five days in March. Sharma's report says the attackers poisoned trusted components including the Trivy and Checkmarx KICS GitHub Actions, the telnyx Python package and LiteLLM.

The underlying CloudSEK disclosure applies a more cautious label to its data. CloudSEK describes a reconstructed exposure set of more than 2,500 organizations and roughly 434,000 potentially exposed CI/CD pipelines. It explicitly warns that inclusion does not prove every organization was successfully compromised or every listed credential was stolen.

StepSecurity's exact 78,330 figure should therefore be read as its analysis of observed secret records, rather than proof of 78,330 independently verified thefts. The distinction does not remove the operational risk. A potentially exposed cloud key, repository token or package-publishing credential still requires investigation and often rotation. It does change how the campaign's scale should be reported.

Sharma is turning incident response into product development

The annual report also functions as StepSecurity's argument for buying a broader set of controls. Sharma identifies three recurring weaknesses across the 56 incidents: secrets available inside developer and CI/CD environments, dependencies or Actions following mutable versions, and unrestricted outbound network access.

StepSecurity has mapped each weakness to its current product lineup. Harden-Runner records network connections, processes and file writes during CI/CD jobs, and can block outbound traffic that violates a policy. Secure Registry sits in front of public package registries and can hold back newly released versions or block known compromises. Dev Machine Guard extends monitoring to laptops, IDE extensions and AI coding tools. Threat Center distributes incident indicators and exposure checks.

The timing fits StepSecurity's expansion from a GitHub Actions security product into a platform spanning developer machines, repositories and build pipelines. Each new attack gives Sharma's researchers fresh indicators, which inform StepSecurity's detection and blocking rules. The company says it treats each incident as a test case and builds new controls when its analysis exposes a gap.

A $3 million seed round announced in 2024 gave the founders capital for that expansion. Runtime Ventures led the financing, with participation from Inner Loop Capital, SaaS Ventures and DeVC. StepSecurity said at the time that it would invest in its open-source community and extend support beyond GitHub Actions.

Sharma's strongest contribution is the feedback loop behind the report: investigate a real compromise, alert customers, test the attack against StepSecurity's controls and build whatever protection the incident exposed as missing. Within the limits of the company's own alerting universe, the 56 cases give the founders a concrete operating record for the security platform they are building.