Supply chain attacks every other morning Unless you’ve lived under a rock for the last few months, you probably noticed that software supply chain attacks are getting trendy among threat actor groups. Over the last 12 months, we’ve seen more of those than ever before, to name only a few of them: tj-actions/changed-files : In March 2025, a popular reusable GitHub application workflow was compromised to dump secrets from CI/CD pipelines. Salesloft Drift : In August 2025, threat actors stole OAuth credentials from the compromised Drift chatbot application. Shai-Hulud : In September and November 2025, a wormed attack propagated through npm packages and collected secrets. The common thread among those incidents is that they all revolved around secrets, one way or another. Some used secrets as an initial access vector, and others were focused on collecting secrets from victim environments. March 2026 did not change the state of things, with two new severe attacks added to our dreadful collection: trivy-action & LiteLLM campaign by Team PCP. The most popular Axios package compromise. Both those attacks followed a now-classical pattern, spreading through compromised open-source dependencies to maximise the impact in the shortest possible time. Your all-time classic, now with added internal threats Open-source supply chain attacks are not new. Ever since we started using centralized open-source package registries, the risk has existed. Threat actors understood this and started exploiting it. What has changed since 2015 is how we have improved software development productivity through automation. And now, this very same automation that lets you test and build your projects without typing a single command is amplifying the supply-chain threat and the velocity of attacks. Let’s see how. Keeping your malware up to date A very concerning pattern we’ve observed in the trivy-action and Axios campaigns is that automation can become the source of your compromise. One thing no developer wants to do is keep track of the new versions of all the dependencies they use. For that reason, the developer community invented Renovate and Dependabot , two systems that track and apply those updates. However, updating and installing packages is generally all that supply-chain malware needs to spread the infection. Dependabot and Renovate pull requests carry an implicit trust that human-authored pull requests do not. They are routine, expected, and often waved through without scrutiny. The bad news is that this implicit trust now tends to accelerate the distribution of malware during supply-chain attacks. The malicious axios package was uploaded on March 31st at 00:20 am. Only 5 minutes later , we observed the first modifications to a package.json file on a public repository. This commit was pushed by Dependabot and upgraded the axios dependency to 1.14.1, the malicious version. Overall, across the infection timeframe, we have observed at least 895 public repositories upgrading axios to a malicious version. Out of the 527 that were still available at the time of analysis, 313 had been pushed to a branch directly, while 214 changes were brought via a pull request. Where things get interesting is that 154 of those pull requests were opened by a bot user: 111 by Dependabot 30 by Renovate Even worse, 95 (60%) of those pull requests were merged into the main branch, 50 of them by a bot user, without any user interaction . This led to the malicious package being pushed to production code in less than an hour, as showcased by the jhipster/generator-jhipster repository. The malicious dependency update is automatically merged in production code. In that case, the upgrade was triggered at h+40mn and merged at h+56mn. All this was allowed by a combination of Dependabot and an automerge workflow in the CI/CD pipeline. name: Dependabot auto-merge [...] jobs: enable-auto-merge: runs-on: ubuntu-latest if: ${{ github.repository == 'jhipster/generator-jhipster' && github.event.pull_request.user.login == 'dependabot[bot]' }} [...] - name: Enable auto-merge for Dependabot PRs if: steps.dependabot-metadata.outputs.update-type != 'version-update:semver-major' run: gh pr merge --auto --squash "$PR_URL" env: PR_URL: ${{github.event.pull_request.html_url}} GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} And this pattern is not uncommon. A naive GitHub code search returns thousands of workflows that allow automerging for Dependabot. Thousands of project implement an auto-merging of Dependabot pull requests. This has specifically been observed during the trivy-action compromise, where repositories automatically updated the CI/CD pipeline with a malicious workflow version and ran it as part of the CI/CD testing itself. It can feel like a malicious inception in your pipeline. In a few particularly nasty cases, we’ve found that Renovate updated the pinned commit SHA of a workflow. Pinning the commit SHA of a reusable workflow is considered best practice to prevent unexpected o...