The PCP Team's supply chain attacks compromised two critical components of the development ecosystem: AquaSecurity's trivy-action and the Python litellm package. These incidents affected repositories and packages across the landscape, but their true scope remains difficult to assess. At GitGuardian, we developed and tested methodologies to evaluate this impact within the limits of publicly available data. Our analysis demonstrates how to answer concrete questions: which repositories executed malicious code during specific time windows, which packages would automatically pull compromised dependencies, and what conditions create vulnerability to such attacks. This evaluation offers a window into the cascade effects of supply chain compromise, though the complete picture extends beyond what any single organization can observe. AquaSecurity trivy-action Compromission The trivy-action compromise has been the first to happen and has been the source of some of the later damages. We have used GitGuardian’s dataset to list the repositories that use the trivy-action as part of their workflow definitions. To reduce the time required to later download and analyze the workflow logs, we reduced our search to repositories where workflows had been updated since January 1st, 2026. We found a total of 30,353 unique repositories. The following analysis focuses on this sample, so that the numbers are a lower bound to the actual compromise radius. Repositories that got compromised because of the trivy-action supply-chain attack were so by their CI/CD runs. Because a repository depends on trivy-action does not mean it got compromised. In fact, multiple conditions have to be met for this to happen: The candidate workflow must have used a compromised version of trivy-action The trivy-action version must have been pinned to a tag and not a commit SHA The candidate workflow must have run during the compromise window, that is, between approximately 17:43UTC UTC on March 19, 2026, and 05:40 UTC on March 20, 2026, as per AquaSecurity's own timeline . To verify which repositories matched those conditions, we actively listed all candidate workflow runs, selected those that occurred during the compromise window, downloaded the workflow logs, and checked the exact commit SHA of the trivy-action action downloaded as part of the run. [...] 2026-03-19T18:55:19.7318647Z Download action repository 'aquasecurity/trivy-action@91e7c2c36dcad14149d8e455b960af62a2ffb275' (SHA:91e7c2c36dcad14149d8e455b960af62a2ffb275) [...] Example log entry for a compromised run. SHA points to a compromised version, and execution occurs within the compromise window. Using this methodology, we found 474 repositories that run a malicious version of trivy-action . Remember that this is from our sample of 30,000 candidate repositories, meaning the actual number of executions is likely higher. Likewise, this analysis does not account for private repositories, for which workflow logs are not publicly available. This highlights, if needed, how such supply chain attacks can affect any entity, including high-profile companies such as Canonical, Microsoft, or NASA. Python litellm Compromission The litellm compromise was different from the trivy-action one in that it targeted local environments rather than CI/CD runners. Especially, while the trivy-action payload was split into two parts: a CI runner-dedicated infostealer and a more generic endpoint infostealer. The litellm package was poisoned with only the former. From our experiment, in the general case, the litellm payload was not able to collect the most sensitive data from the CI/CD environment. Especially, it did not collect the CI secrets if those were not explicitly set as environment variables. In the case of litellm , an interesting piece of information to collect is which Python packages, at the time of compromise, depended on litellm in such a way that installing them would have triggered the malicious payload. We tried to measure this using the following methodology: We extracted the dependent packages from the GitHub-provided litellm dependency network. For each of those packages, we determined the latest version at the time of compromise . Parsing this version’s metadata, we extracted the version of litellm it required at install time. Depending on the version qualifier, we determined if installing the package was susceptible to triggering the malware. The information provided by GitHub in the project’s dependency graph included 2,247 unique packages. 340 of them were excluded from the rest of the analysis for various reasons: 200 did not include litellm as a dependency in their latest (at the time of the compromise) version. 51 had no published version at the time of compromise. 89 were removed from PyPi since the attack occurred. The 1907 remaining packages were candidates for infection propagation depending on the way they included litellm as a dependency. Out of them, 202 had a strict version constraint that...