> OK, so we're drawing an arbitrary line of what we read and what we don't.
Imo the line is not arbritary. You are including an library/framework for a purpose. The code path for this purpose should be explored.
Recently I allowed a friend of mine to DDOS my server. He used unvisited software. Now my server suffers from thousand wild guesses daily. Previously, I had ten visitors a day. Therefore I conclude that the software leaked my server. And his learning: Don't trust any software; Exspecially if the software is for malicious purposes in the first place..
> A basic web application at this point is going to import at least 10k lines of other people's code. A React app probably uses millions.
I think it is a valid assumption to increase the trust in frameworks with a giant user base. React is from Facebook, isn't it? So I would have read the path _and_ random internals to picture the trustworthiness.
> There's just no way around this. We all trust code we haven't read and have to continue doing it.
It shouldn't be black-and-white thinking. When introducing a _new_ dependency I see myself responsible for estimating the trustworthiness.
But yes, with an increasing amount of dependencies the process of updating such needs more effort as well.
But then, we can postpone such updates, if the application under development is safety critical...
> Reading code doesn't even guarantee finding security flaws. Most of us aren't security researchers, and none of us can understand an entire project's source code the first time we read it.
Well, one should be able to judge about the workings imo. Otherwise maintainability can get painful in the long run. So better grasp it before deciding to build upon it.
Another comment stated that we are trusting cars we drive, etc. etc.
This is about the users running our code.
A proper craftsman will inspect its material, before using it in quality products. When building a throwable tool for his work, he doesn't spent to much time worrying, of course.
Yes, but it uses a massive number of libraries that were not developed at Facebook.
> But yes, with an increasing amount of dependencies the process of updating such needs more effort as well. But then, we can postpone such updates, if the application under development is safety critical...
Postponing dependency updates is very, very bad for security. That is not a solution to supply-chain attacks.
> Well, one should be able to judge about the workings imo. Otherwise maintainability can get painful in the long run.
The whole point of APIs is that we do not need to understand the inner workers of code that we're calling. How many of us use bcrypt and couldn't tell you anything about the underlying algorithm?
> Postponing dependency updates is very, very bad for security. That is not a solution to supply-chain attacks.
You are right; This underlines the thought and care some distributions put into their package management system...
> The whole point of APIs is that we do not need to understand the inner workers of code that we're calling. How many of us use bcrypt and couldn't tell you anything about the underlying algorithm?
That is right, but code written by unknown developers can be a huge risk. Of course you are not assumed to read up upon any dependency, but from external sources.
A quick glimps on the imports and dependencies goes a long way, I think.
In the end your team is responsible for security issues, even if they appear in an external dependency.
Companies with direct customer sales are spending tons of money for mitigation strategies. Maybe a chunk of this money should be spend on validating this beforehand.
Imo the line is not arbritary. You are including an library/framework for a purpose. The code path for this purpose should be explored. Recently I allowed a friend of mine to DDOS my server. He used unvisited software. Now my server suffers from thousand wild guesses daily. Previously, I had ten visitors a day. Therefore I conclude that the software leaked my server. And his learning: Don't trust any software; Exspecially if the software is for malicious purposes in the first place..
> A basic web application at this point is going to import at least 10k lines of other people's code. A React app probably uses millions.
I think it is a valid assumption to increase the trust in frameworks with a giant user base. React is from Facebook, isn't it? So I would have read the path _and_ random internals to picture the trustworthiness.
> There's just no way around this. We all trust code we haven't read and have to continue doing it.
It shouldn't be black-and-white thinking. When introducing a _new_ dependency I see myself responsible for estimating the trustworthiness. But yes, with an increasing amount of dependencies the process of updating such needs more effort as well. But then, we can postpone such updates, if the application under development is safety critical...
> Reading code doesn't even guarantee finding security flaws. Most of us aren't security researchers, and none of us can understand an entire project's source code the first time we read it.
Well, one should be able to judge about the workings imo. Otherwise maintainability can get painful in the long run. So better grasp it before deciding to build upon it.
Another comment stated that we are trusting cars we drive, etc. etc. This is about the users running our code. A proper craftsman will inspect its material, before using it in quality products. When building a throwable tool for his work, he doesn't spent to much time worrying, of course.