CVE-less vulnerabilities

> The last project I worked on had 62 external dependencies

Clearly you don't use Node.js. :-)

Github is providing this as a service: https://help.github.com/en/articles/about-security-alerts... (which acquired https://dependabot.com/)

There's also Greenkeeper.io and Gitlab has something similar --- https://docs.gitlab.com/ee/user/application_security/depe....

It's a bear, but there are tools to automate or semi-automate this sort of thing. In the commercial space it's typically a matter of a small expenditure to get a thing that creates workflows and everything.

In the open source world, it's less clear. Some services have a no-pay tier for open source users, but it never feels very sustainable.

You write it as if some gremlin had connected to your project deep in the night and had made it use all this other code. The dependencies didn’t add themselves, someone in the project made the decision to use this other code, instead of writing the functionality himself.

This person should have evaluated the costs of keeping this code up to date, instead of forking it and maintaining it all directly. Just like he should have evaluated if the API provided by this other code is convenient, if it’s compatible licensing-wise, if it’s actively maintained in the original project and reasonably future-proof, etc.

Costs of keeping other code up to date balloon if it calls itself lots of other third party code, if its authors do not keep APIs stable and backwards-compatible, do not release (each commit is a new thing to look at), do not use semver, do not write changelogs, do not announce new versions on a mailing list. Sometimes choosing something a bit less featured with fewer keeping up to date problems is a better deal.

Anyway checking up-to-dateness can be done using announce mailing lists, release-monitoring.org, pretty much any language that uses a package manager allows querying for the latest version, everyone is moving to git nowadays so you can write your own git pull and check tags monitoring robot, etc. All the major actors (Google, Microsoft via Github, Gitlab, node…) are starting to keep registries of problematic code, and you can use those too (but, that will make you dependent on them, and pretty soon they'll start scoring projects in ecosystems they control, and force you to do whatever changes they want for free, if everyone relies on their score, and a bad score becomes the kiss of death).

Or, just choose things available in a major Linux distro, adhere to its update cycle, and update whenever it does in its devel branch.

There’s no miracle, anything like static linking, containers, vendoring, private forks, that isolates you from the version bumps of others, puts you in power. With power comes responsibility. The less you depend on the update checks of others, the more you need to perform them yourself.

As a rule, any upstream new version should be checked for security or dataloss fixes. Quite often those are not traced, and you end up updating by default, because it's less work than auditing all the code changes to identify what is needful.