On the flipside sometimes you get lucky and being on an old version of a package means you don't have the vulnerability in the first place.
libyear is a helpful metric for tracking how much of this debt you might have.
Rather than loading up my git repo with binaries, I find it more appealing to maintain an enterprise repository that proxies to NPM and keeps a local cache for the enterprise. Part of what bothers me about letting `npm` point to the https://registry.npmjs.org public repository is the valuable trove of information they can gather about what my team is currently working on by watching what we download.
By pointing npm to a hosted repository proxy, not only can we protect against package deletion rug pulls, but we can also keep hidden details about what we are working on right now. There are also uptime benefits from self-hosting a repo, although registry.npmjs.org has been remarkably dependable.
The self-hosted proxying npm repository I have used in mega-corp was Artifactory, and it was pretty great.
To achieve my goal, would this approach work:
- Pin all of my package.json versions (no prefacing versions with ~ or ^)
- Routine installation of packages both on my local and on CI servers will be done using `npm ci`
- `npm install <package_name> --save-exact/--save-dev` would be used only at the time of adding a package to package.json, followed by an `npm ci`
- Rely on tooling like GitHub Dependabot and CodeQL to inform the team when a dependency should be updated for security reasons and then manually update only the dependency with the desired version using `npm install lodash@4.17.21 --save-exact`, for example
EDIT: Thinking about this more, we would have to forbid deleting the package-lock.json and regenerating it with `npm install` and forbid the use of `npm update` so that package-lock.json would stay stable.