True, but...
> Validating inputs isn't defensive coding. It should be standard practice. If you, as a software developer, are not rigorously validating 100% of your user inputs, your computer access rights should be revoked.
I'd agree with this, but the problem here isn't *your* code.
It's the code in library A which you're pulling in. Which is then pulling in libraries B and C. Which are then pulling in libraries D, E, F, G, H. And so on.
No matter how rigorously you're validating your own code, there's no way to verify that the pyramid of "external" code you've pulled in is safe, unless you're going to manually review it all.
To use a recent personal example: I needed to compile some javascript using gulp. And after much failed faffing with nvm/npm, I gave up and grabbed a tarball of the required libraries from somewhere else.
My code: a few hundred bytes, atop a few hundred kilobytes of existing in-house code.
The code needed to get gulp working: 174 megabytes.
To be fair, there's probably a lot of legacy cruft in the compilation system. And I'd guess less than 1% of that code actually gets fired up when compiling my code. But even so, it would take weeks or months to verify the pyramid of code which is being used, and I'd then have to repeat this exercise whenever a library is updated and/or a new dependency added.
And therein lies the issue.
In theory, that's the beauty of open-source software, in that you have access to the source and do have the ability to review it. And since everyone else can do the same, all code should be perfect and bug-free!
In practice, many open-source packages only have a small number of contributers (assuming they haven't been abandoned/forked/etc), and the amount of oversight is limited.
Biting the hand that feeds IT
