If your dependency is sqlite or a webserver, don't bother. But I agree that nowaday the tendency is to import even the most trivial of things.
There is a line that has to be drawn between "depends on legendarily well tested database" and "depends on 20 pieces of random npm code where the import statement is longer than the sourcecode". Do you really need to import an external dependency that removes whitespace at the end of a string?
Unless you are one of the people who really vet their dependencies heavily surely dependencies are just used because they save you time and you trust others that it is going to be okay. This is why we need harder liability laws for software errors.
> In the end, it makes little difference if your organization lost all its high value data due to an insecure external codebase or an insecure internal codebase. The effects are the same, devastating! However, the probabilities of occurrence can be quite different.
But there is a good chance it will matter for you!
How many people do you think got fired for the Log4J RCE for using the library. How many people got fired for the Heartbleed vulnerability for using OpenSSL?
What would have happened if you had written those vulnerabilities yourself?
Also, if you have the same vulnerabilities as everyone else, the news coverage is diluted.
>How many people do you think got fired for the Log4J RCE for using the library.
The counter to that claim is that there are certainly a lot more insecure logging implementations in use that never get (widely) exploited mainly because of obscurity (i.e. closed-source).
> What would have happened if you had written those vulnerabilities yourself?
Hopefully nothing. After all, if the all the open source eyeballs on those products weren't enough to stop those bugs, then surely it's unreasonable to punish your own developers for not doing better. Yes, there's value in using common resources and certainly benefits from those other eyeballs. But this sort of "hiding in the herd" is also why we still have organizations implementing mandatory password rotations. As a society we really need to do a better job distinguishing from "theoretically preventable" and "negligently broken" and stop punishing people (or threatening to punish them) for "theoretically preventable" issues.
If your dependency is sqlite or a webserver, don't bother. But I agree that nowaday the tendency is to import even the most trivial of things.
There is a line that has to be drawn between "depends on legendarily well tested database" and "depends on 20 pieces of random npm code where the import statement is longer than the sourcecode". Do you really need to import an external dependency that removes whitespace at the end of a string?
Unless you are one of the people who really vet their dependencies heavily surely dependencies are just used because they save you time and you trust others that it is going to be okay. This is why we need harder liability laws for software errors.
> In the end, it makes little difference if your organization lost all its high value data due to an insecure external codebase or an insecure internal codebase. The effects are the same, devastating! However, the probabilities of occurrence can be quite different.
But there is a good chance it will matter for you!
How many people do you think got fired for the Log4J RCE for using the library. How many people got fired for the Heartbleed vulnerability for using OpenSSL?
What would have happened if you had written those vulnerabilities yourself?
Also, if you have the same vulnerabilities as everyone else, the news coverage is diluted.
>How many people do you think got fired for the Log4J RCE for using the library.
The counter to that claim is that there are certainly a lot more insecure logging implementations in use that never get (widely) exploited mainly because of obscurity (i.e. closed-source).
> How many people do you think got fired for the Log4J RCE for using the library
Seriously no idea, how many do you think?
> What would have happened if you had written those vulnerabilities yourself?
Hopefully nothing. After all, if the all the open source eyeballs on those products weren't enough to stop those bugs, then surely it's unreasonable to punish your own developers for not doing better. Yes, there's value in using common resources and certainly benefits from those other eyeballs. But this sort of "hiding in the herd" is also why we still have organizations implementing mandatory password rotations. As a society we really need to do a better job distinguishing from "theoretically preventable" and "negligently broken" and stop punishing people (or threatening to punish them) for "theoretically preventable" issues.