Hunting Supply Chain Risks

Hunting supply-chain risks: the code you didn't write but still ship

Your application code can pass every review while the thing you actually ship is compromised, because the supply chain is a second, softer surface: what you pull in, what your build runs, and what your CI is trusted to do. These attacks execute in your build or your users' installs, usually before any code review looks at them. Finding them means auditing resolution, execution, and privilege, not the source.

When to use

• You are reviewing a build pipeline, a dependency manifest, or a lockfile.
• You run or depend on an internal package registry alongside public ones.
• You are auditing a CI/CD configuration, its triggers, and its secrets.

Scope check

Audit builds, registries, and pipelines you own or are authorized to test. Do not publish packages or trigger jobs against systems you do not control; probe name collisions passively. If you can't name the authorization, stop.

The loop

1. Map what the build resolves and runs. List every dependency source (registries, internal and public), how names resolve when both exist, and every step the pipeline executes that is not your reviewed code: install scripts, generated config, third-party actions or plugins, and anything triggered by external input.

2. Check for dependency confusion. For each internal or private package name, can a public registry serve a package of the same name, and would your resolver prefer or fall back to it? An internal name that is unclaimed publicly and resolvable from the public registry is a hijack waiting for a version bump. Confirm scoping, registry pinning, and namespace ownership.

3. Check for typo- and slopsquatting. Are dependency names verified against a known-good source, or copied from documentation, an assistant's suggestion, or memory? A package name a model hallucinated and an attacker then registered (slopsquatting) installs attacker code under a plausible name. Verify every name resolves to the intended, established package, not a lookalike or a freshly published near-name.

4. Check for poisoned pipeline execution. Does any CI step run on untrusted input (a pull request from a fork, an issue title, a branch name, a dependency's install script) while holding secrets or the ability to alter the build? Untrusted input that reaches a build step with credentials is remote code execution in your pipeline. Trace external triggers to privileged steps.

5. Check CI privilege and secret blast radius. Which secrets, tokens, and deploy keys does a job hold, and does a low-trust trigger (a fork PR) run with the same power as a trusted one? Scope tokens per job and separate untrusted-trigger jobs from secret-holding ones.

6. Check the integrity of what's pulled. Are dependencies pinned by hash or lockfile, are actions and plugins pinned by commit rather than a mutable tag, and is what you install verified? A mutable reference is a rug-pull channel: benign today, swapped tomorrow.

7. Confirm or kill each and record. For each risk, the fix: claim and scope internal names and pin the registry, verify package names, isolate untrusted-trigger jobs from secrets, pin by hash or commit, minimize token scope. Record confirmed exposures and closed paths in the schema.

Where the chain breaks

• Resolution order is a security decision. If public can shadow private, naming is authentication, and it is weak.
• A package name from a model or a doc is unverified input. Slopsquatting turns a confident hallucination into installed code.
• A fork PR is untrusted content that runs code. Treat pipeline triggers as an ingestion channel.
• Mutable tags and floating versions are rug-pull surface. Pin what executes.

Worked example (a confirm and a kill)

Confirm. An internal utility package is referenced by a bare name, and the resolver falls back to the public registry when the private one lacks a requested version. The name is unclaimed publicly; an attacker publishes it at a higher version. The next build pulls the attacker's code, whose install script runs with CI secrets in scope. Confirmed dependency confusion into poisoned pipeline, critical, remediation = claim the name and scope, pin the private registry, and run installs without secret access.

Kill. A repo pins every dependency by hash in a committed lockfile, resolves only from a scoped internal registry with no public fallback, pins all CI actions by commit, and runs fork-PR jobs in a no-secrets context. A confusion attempt cannot resolve and a swapped tag fails the hash. Killed, kill_reason = "hash-pinned, single scoped registry with no fallback, secret-free untrusted-trigger jobs; no shadowing or rug-pull path."

Rationalizations to reject

• "The package name looked right." → Looked right is not verified. Confirm it is the established package, not a near-name.
• "It's an internal package, no one else has it." → Unclaimed public names are claimable. Own the namespace.
• "It's only a CI script." → CI holds secrets and ships artifacts. Code execution there is production impact.
• "We use a floating tag for convenience." → Floating is mutable is rug-pullable. Pin by hash or commit.

Executing this in practice

You need the dependency manifests and lockfiles, the resolver's registry and fallback configuration, the CI configuration with its triggers and secret scoping, and the ability to check public registries for name collisions. A code graph over your app plus resolved dependencies helps confirm whether pulled code is even reachable; the resolution rules and the trigger-to-secret tracing are the method.

Related

• adjudicating-dependency-cve-reachability - whether a pulled dependency's known bug is reachable, once you trust what is pulled.
• auditing-mcp-tool-integrations - rug-pull and pinning discipline applied to the tool layer.
• mapping-attack-surface - inventorying build and CI surface alongside the app.
• FINDING-SCHEMA.md - source = the shadowing package or untrusted trigger, sink = the build step or install that executes it.