56 build-pipeline attacks, one vendor's alert queue, and the February jump nobody can attribute yet

The monthly figures are worth adding up. March through July account for 47 of the 50 incidents dated from February onward, which leaves February itself holding three ^[7]. Averaged out, the first half of the window ran at about one confirmed incident a month and the second at about eight ^[8]. That eightfold change is the report's real content, and it is also the part most exposed to a boring explanation: the same analysts, a customer base that presumably grew, and a monitoring product being widened into the rest of the delivery path during the period ^[14]. Nothing in the published method separates a busier attacker population from a wider net. The report at least tells you which one it is measuring, which is more than most vendor counts do ^[2].

The exclusions are the most defensible thing in the document. By dropping typosquats, name-confusion packages and anything malicious from its first release ^[4], Sharma is counting the takeover of trust that already existed: a maintainer account, or a mutable Action tag on a workflow a team already runs ^[3]. That is a narrow denominator, but it is a stable one, and the 47 incidents across the five months from March work out to one every 3.3 days, which matches the cadence the report claims ^[18].

Then there is the number that will get quoted. StepSecurity says the Team PCP campaign took 78,330 secrets from the pipelines of 2,186 organizations in five days in March ^[10], roughly 36 secrets per organization ^[16]. CloudSEK's underlying disclosure counts more than 2,500 organizations and about 434,000 potentially exposed pipelines, and warns that being in the set does not prove anything was stolen ^[12]. So the larger set carries the more cautious label, while the tighter figure sits on top of it; StepSecurity's 78,330 is best read as its analysis of observed secret records rather than 78,330 verified thefts ^[13]. For anyone running the affected jobs the distinction is mostly paperwork, since a cloud key or publishing credential that may have been read still has to be treated as burned ^[19]. The poisoned components named include the Trivy and Checkmarx KICS GitHub Actions, the telnyx Python package and LiteLLM ^[11].

Sharma came out of nearly 15 years at Microsoft and Azure's Green Team, his co-founder Ashish Kurmi out of security engineering at Microsoft, Uber and Plaid, and both cite SolarWinds and Codecov as the reason they went after CI/CD ^[15]. That history explains the quality of the case set and also its shape: the sample leans toward the registries, developer tools and pipelines its researchers already watch, and will miss what happens outside them ^[20].