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.
And to be clear, this is not to say that dependency security efforts are not important.
But it's important to understand that this is like car vs. plane safety; planes (dependencies) *look* really scary, but the actual thing that's likely to kill you is a car (rolling your own).
That doesn't mean that improving plane (dependency) safety doesn't matter, but it's a background process by people whose job this is, not some acute crisis that you need to deal with yourself.
@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')
@joepie91 There was quite a strong toxic anti-dependency attitude among some Rust devs some time ago, but I don't see it that much lately.
Which is great, because great tooling for handling dependency management (I don't do much JS, but it feels quite similar?) together with type system that can help catch breaking changes and tooling that can warn you about known CVEs in your dependencies is one of biggest safety features of that language for reasons you mentioned.
@shine@gts.churanova.eu @joepie91@social.pixie.town imo "supply chain security" is a sales tactic or illusion or something in between.
@shine@gts.churanova.eu @joepie91@social.pixie.town huh those two words are synonymous anyway
(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.)