The supply chain: releases, pipelines, history

The problem

A supply chain attack does not need a vulnerability in your code. It needs one of three things: a release you install, a pipeline that builds you, or a credential that was committed once and deleted.

Those are three different failures with three different owners, which is why they are usually three tools. A code scanner sees the repository. A package scanner sees the manifest. Nothing sees the sequence, and the sequence is the attack.

The campaigns documented in October 2026 share one shape. Reach a trusted artefact, use that trust to get execution inside a build or a developer's machine, then use the credentials found there against the cloud. LiteLLM 1.107.0 was a lookalike repository publishing cook.pth and sitecustomize.py; GhostAction injected security-audit.yml through pull_request_target abuse and mined 3,325 secrets out of git history; the clients were quarantined in about two hours, which is roughly the same order as the time it took to be consumed.

How Hanu approaches it

Releases are judged by freshness and provenance together

A dependency published twenty hours ago is treated differently from one that has been stable for a year, because a compromise window is short and an attacker gains nothing by waiting. Freshness gates are 24 hours for dependencies and 72 hours for your own packages.

A missing provenance attestation on its own is common and mostly benign — plenty of legitimate packages have none. A provenance gap escalates only when it sits beside another anomaly: a fresh release, an unfamiliar publisher, or the artefact being invoked from a cloud account for the first time. SUSPICIOUS_PACKAGE_RELEASE records which of those conditions were met, so the reason is in the finding.

The pipeline is treated as an untrusted environment

CI_WORKFLOW_TAMPER fires on a change to a workflow file in a repository that holds credentials, recording the commit, the path and the actor. Alone it is not worth blocking a merge — workflow edits are routine maintenance. It becomes CRITICAL when the same workflow later makes a secret readable, which is the correlation behind RULE-T2-014.

History is part of the surface

A secret deleted from a branch two years ago is still in the history an attacker clones in seconds. Exposure is evaluated against history rather than against the current tree, and the finding names the ref and the commit so rotation can be scoped to the credential that was actually exposed instead of the whole account.

What you get

Limits

This is not a sandbox and it does not detonate packages. Judgements come from metadata, provenance, freshness and the observed behaviour of the things that consume a release — not from executing it in a container and watching what it does.

The unpinned-action check is deliberately opt-in (opts.includeHygiene). Referencing an action by tag rather than by commit SHA is extremely common; leaving that rule on for a full organisation scan would produce thousands of findings and teach your team to ignore the queue entirely. It is on for the pull-request gate, where the same finding is a five-minute fix.

Package coverage depends on what you connect. The forges and registries you attach are the ones whose releases, publishers and provenance can be reasoned about; anything outside that set is invisible to this view.

We do not republish other people's vulnerability research. Where a campaign has been documented publicly we describe the mechanism and what our own detections would have observed, and we cite the reporting rather than restating it as our own finding.

Questions