The runner holds your deploy keys, and nobody put it in the scanning program

The mechanism in both incidents is dull, which is part of why it keeps working. Trusted third-party code, running with pipeline privileges, on somebody else's push ^[4]. Roughly four years separate the Codecov bash uploader compromise from the tj-actions/changed-files compromise ^[17], and the referencing pattern that made the second one possible is still the default way workflow files name what they run.

That pattern is the tag. `uses: some-org/some-action@v3` resolves through a pointer that the upstream repository owner controls, so a compromised upstream account turns `v3` into attacker code on your next run with no change and no approval on your side ^[5]. A full commit SHA cannot be repointed ^[6]. The inventory of your exposure to this is one command: `grep -rn "uses:.*@v" .github/workflows/` ^[7]. Whatever else is true about supply chain security, the cost of finding out is not the obstacle here. The dev.to author's own expectation is that the count comes back worse than people guess ^[20].

The privilege arithmetic is where this gets expensive. Repository-wide secrets are readable by every workflow in the repository, including the lint job and including a job that runs a third-party formatter against a fork's pull request ^[8]. So the least-reviewed job in the repo carries the same read access as the deploy job, and the deploy key's blast radius is set by the sloppiest YAML file rather than the most careful one. The proposed test is a good one because it is falsifiable: for each secret, name the single job that needs it, and treat anything you cannot assign as over-shared ^[18]. Same logic on the token. A workflow with no `permissions:` block runs on the repository default, and on older repositories that default is write, which means a compromised step can push commits, edit releases or open pull requests wearing your CI's identity ^[12].

The failure that ties it together is detection. Log masking matches exact strings, so a secret that has been base64 encoded, JSON wrapped, or split across a variable expansion goes through unmasked ^[14], and on a public repository the logs are public and the artifacts are downloadable ^[15]. That is the tj-actions shape exactly: the leak arrived in build logs of every repository that referenced the action by tag ^[3].

One caveat on the evidence. This is a single practitioner writeup, and it offers no measurement of how many repositories are still tag-pinned or still running on default token permissions. The two named compromises are load-bearing; the prevalence is asserted, not counted.