hunting-supply-chain-riskslisted

# 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