Regarding "supply chain security" with dependencies: as a professional dependency auditor I can tell you that malicious dependencies are extremely rare... and what's far more common is security issues in utilities that large dependencies insisted on reimplementing despite safe off-the-shelf options being available.
If your takeaway from dependency security stuff is "avoid dependencies", then that is absolutely the wrong takeaway.
(For completeness' sake: this is in the JS ecosystem. It's difficult to compare this to other ecosystems, because many ecosystems don't *have* a meaningful set of single-purpose libraries, and them being single-purpose is an important factor affecting security.)
@joepie91 there's a certain amount of hubris with developers who think they can re-implement huge libraries without security, performance, and safety issues.
I mean, I assume these are the same developers fixing their own normal code bugs all day. At least I've never met a developer who didn't have to fix their own bugs all day long.
@rune Oh, it's not even just the huge libraries (in fact, in JS those often seem to *be* the ones fucking up the reimplementations, because they insist on inlining half-implemented utilities everywhere).
Even the seemingly simple tasks often have nuances that no one single developer is going to get right, merely by virtue of being a single developer.
I would say that the gradient of error rates looks something like this, in order from highest(!) to lowest error rate:
1. Vendor SDKs (like, literally, "it says SDK in the name" is the criterium here)
2. Google (yes, really)
3. Monolithic reimplement-everything libraries/frameworks with no particular corporate owner
4. Libraries that advertise "zero dependencies"
5. Libraries from other tech companies that they use themselves in production
6. Off-the-cuff single-purpose libraries
7. Well-specced and -scoped libraries and library 'constellations', often but not necessarily single-purpose
Exceptions exist, of course, but there are some very clear patterns in which sorts of dependencies have which sorts of issues
@rune (Not obvious from the gradient is that basically only 5-7 meet my quality criteria for dependencies, everything below that scores a hard 'fail')
