[fsloth]

I don’t believe anything I wrote above promotes the idea of ignoring vulnerabilities as a standard procedure.

CVE database is an excellent way to be informed about vulnerabilities and there are services to automatically map CVE reports to code bases.

[chrisweekly]

Ok, but the context for the conversation is external dependencies, and you expressed a preference for code aged 10-15 years. I'm just saying that a codebase that's 10-15 years old, with any dependencies at all, is going to be rife with vulnerabilities. Thus the choice is either staying current or living with vulnerabilities.

What's the alternative? Are you suggesting that backpatching transitive deps dating back over a decade-plus tineframe is a viable maintenance strategy?

[fsloth]

I'm suggesting the "default mode" would be that updating is explicit rather than automatic.

The "10-15" year old comment can be taken in the context of language specifications for example. C++11 is a totally fine language standard, and since backward compatibility is the only reason for C++ to exist at this point there is no intrinsic benefit in using a later version.

[chrisweekly]

> "I'm suggesting the "default mode" would be that updating is explicit rather than automatic"

This, I agree with. Though for modern codebases, leveraging tools like Dependabot is very helpful. Deliberate upgrades, with automation to make it practical.