Depends on the use case, and what you mean by “external dependencies”.
Black box remote services you’re invoking over HTTP, or source files that are available for inspection and locked by their hash so their contents don’t change without explicit approval?
Cuz I’ll almost entirely agree on the former, but almost entirely disagree on the latter.
In my career:
I’ve seen multiple vulns introduced by devs hand-writing code that doesn’t follow best practices while there were packages available that did.
I have not yet seen a supply chain attack make it to prod.
The nice thing about supply chain attacks though: they get publicly disclosed. Your intern’s custom OAuth endpoint that leaks the secret? Nobody’s gonna tell you about that.
I didn’t think I would have to spell this out, but when I wrote “as much as possible”, I was acknowledging that some libraries are either too complex or too security-sensitive to be reasonably homebrewed by the unqualified. (Perhaps “as much as reasonably possible” would have been better phrasing.) Where the line lies will depend on the person/team, of course, but the vast majority of libraries do not fall into that category. I was generalizing.
And yes, some third-party libs might get so much public scrutiny as to be considered safer than what someone would create in-house, depending on their skills. But safety in numbers sometimes turns out to be a false assumption, and at the end of the day, choosing this approach still pushes external risks (attack surface) onto users. Good luck. It hardly matters to the general point, though, because most libs do not have this level of scrutiny.
Let’s also remember that pinning dependencies is not a silver bullet. If I didn’t trust someone to follow “best practices”, I don’t think I would trust their certification of a third-party library hash any more than I would trust their own code.
With all that said, let me re-state my approach for clarity:
I minimize dependencies first. Standard libraries are great for this.
When something more cannot reasonably be avoided, I choose very carefully, prioritizing the safety of my users over my own convenience.
Sometimes that means changing my original design, or spending my time learning or building things that I hadn’t planned to. I find the results to be worth it.
Depends on the use case, and what you mean by “external dependencies”.
Black box remote services you’re invoking over HTTP, or source files that are available for inspection and locked by their hash so their contents don’t change without explicit approval?
Cuz I’ll almost entirely agree on the former, but almost entirely disagree on the latter.
In my career:
I’ve seen multiple vulns introduced by devs hand-writing code that doesn’t follow best practices while there were packages available that did.
I have not yet seen a supply chain attack make it to prod.
The nice thing about supply chain attacks though: they get publicly disclosed. Your intern’s custom OAuth endpoint that leaks the secret? Nobody’s gonna tell you about that.
I didn’t think I would have to spell this out, but when I wrote “as much as possible”, I was acknowledging that some libraries are either too complex or too security-sensitive to be reasonably homebrewed by the unqualified. (Perhaps “as much as reasonably possible” would have been better phrasing.) Where the line lies will depend on the person/team, of course, but the vast majority of libraries do not fall into that category. I was generalizing.
And yes, some third-party libs might get so much public scrutiny as to be considered safer than what someone would create in-house, depending on their skills. But safety in numbers sometimes turns out to be a false assumption, and at the end of the day, choosing this approach still pushes external risks (attack surface) onto users. Good luck. It hardly matters to the general point, though, because most libs do not have this level of scrutiny.
Let’s also remember that pinning dependencies is not a silver bullet. If I didn’t trust someone to follow “best practices”, I don’t think I would trust their certification of a third-party library hash any more than I would trust their own code.
With all that said, let me re-state my approach for clarity: