We had a near miss where an automated assistant suggested a dependency whose name differed from a legitimate package by only one character. It had a single maintainer, almost no history, and was installed into a container image that started running before the pull request review was complete.
Our image scanner did not flag it because it mainly checks for known vulnerable versions of established packages. Since this package was brand new, there was no matching vulnerability data. Scanning after the image is built is also too late because installation scripts may already have executed.
I'm looking for ways to evaluate dependencies at pull or lockfile-resolution time—before installation hooks run. What tools or controls do you use to identify suspicious or typosquatted packages before they can execute?
4 Answers
Use network controls as a backstop: run builds with default-deny outbound access, restrict registry access to an approved mirror, and block arbitrary destinations. A malicious install script may still run locally, but it has far less ability to download payloads or send credentials out. Combine this with pinned versions, isolated build workers, and artifact promotion only after review.
Put a trusted package mirror or proxy in front of public registries, and only allow builds to pull through it. The mirror can cache artifacts after review and scanning, while production builds use approved, immutable versions rather than whatever is currently tagged as latest. Pinning dependencies and committing lockfiles helps prevent unexpected changes too.
Disable dependency lifecycle or post-install scripts by default during builds, then explicitly allow them only for packages you have reviewed. Package managers such as pnpm support allowlists for build scripts. This doesn’t replace package vetting, but it prevents a newly pulled package from immediately executing arbitrary install-time code.
A normal CVE scanner won’t reliably catch a package that was published yesterday. Add a pre-install dependency policy that scores things like maintainer history, package age, download patterns, name similarity to popular packages, install scripts, and network access. Run that against the lockfile before the package manager performs the install, not against the finished image.
That’s useful for the install phase, but we’d still need a policy check before fetching and unpacking the package itself.