You do need a model for evaluating whether or not to trust a dependency, and for understanding if and when to extend that trust to a subsequent version/update.
I’m going to suggest that if your model is to fully understand the dependency, e.g., by reading every line of code, then you should probably stop having any dependencies and develop everything yourself —- just to save time. (But let’s face it, you should probably just find a new line of work).
It sounds glib, but I’m serious.
You can literally only run software only you’ve written, only on hardware you’ve designed and manufactured (and personally delivered), or you are trusting someone else, somewhere.
What is your basis for this? Actually?
If you’re not sure, but have an intuition, that’s not too bad… you’re in good company and like practically everyone else.
IDK, spend a few minutes thinking about what your model of trust is, and why even have one. Really, if the best you can come up with is to not trust anything you can’t personally verify, software development is not the best for you.
I do look over libraries that I’m adopting in a number of projects (and often review the differences between version upgrades). At the same time, I don’t look over the source code to PostgreSQL or libpq or even postgrex (the Elixir library for PostgreSQL).
But in terms of Getting Things Done, I also did `pnpm add date-fns` this afternoon and have never reviewed the code for `date-fns`, because it seems to do what it says on the tin and is generally well-regarded. There’s a balance to be obtained, and you have to trust someone, because you’re not going to read the source code to clang or gcc.
So in general, I agree with you: the article here is horrible advice.
I was one of the authors of a widely used library, one that I expect thousands of people looked over, maybe tens of thousands. Noone noticed the easter egg I added, as far as I could tell, and I didn't even try very hard to obfuscate it.
I'll add my voice to the chorus: The article is horrible advice.
It really comes down to tracking published vulnerabilities in your dependencies, and choosing trustworthy dependencies.
Nobody reviews third party source code for security issues (well, almost nobody). It would not be a productive use of time. There are almost certainly many other less expensive things you could do with that resource to improve security.
It's (almost) the same thing for traditional engineering. Nobody reviews that fuel pump for reliability and functionality, they trust the manufacturer's specs and certifications, and if the pump turns out not to meet those specs they sue for a recall & fix/replacement. The difference is software licenses all disclaim liability, so we can't even get critical issues fixed.
Even in traditional engineering how can you guarantee ever eventuality that another creative mind comes up with after you designed and built the thing. I design and build an air duct to facilitate air circulation into my buildings. If someone decides fly a drone into my air duct vents and breach the building when everyone leaves for the day then who's liable? Should I have know that years later someone would use the air vents to breach the building?
I'm not super happy about log4j as it affected us through a third party install (via PyPI even!).
But the issue I see is that larger software installations have larger attack surfaces. And the typical python, js, golang (eg.) projects are just exploding in dependencies.
I think the python project I run at work is now over 100 deps on PyPI. My simplistic golang side project is around 50 or so.
You do need a model for evaluating whether or not to trust a dependency, and for understanding if and when to extend that trust to a subsequent version/update.
I’m going to suggest that if your model is to fully understand the dependency, e.g., by reading every line of code, then you should probably stop having any dependencies and develop everything yourself —- just to save time. (But let’s face it, you should probably just find a new line of work).
It sounds glib, but I’m serious.
You can literally only run software only you’ve written, only on hardware you’ve designed and manufactured (and personally delivered), or you are trusting someone else, somewhere.
What is your basis for this? Actually?
If you’re not sure, but have an intuition, that’s not too bad… you’re in good company and like practically everyone else.
IDK, spend a few minutes thinking about what your model of trust is, and why even have one. Really, if the best you can come up with is to not trust anything you can’t personally verify, software development is not the best for you.