IMHO we code review to ensure quality, security and other guardrails beyond automated tools. There are also people aspect like mentoring and grooming junior engineers into best practices & new team members into coding standards and other conventions.
Let’s ignore the people aspect for a while. Linux Foundation survey says 70-90% of modern software constitute open source code. We only look at popularity, maintenance, known vulnerabilities of direct dependencies while adopting an open source dependency in our code base. We implicitly trust all the code brought in by transitive dependencies. I can confidently say my production projects has 50% or more code from open sources that I have no idea about.
We somehow assume that some magical database (CVE) will have all vulnerabilities in OSS code and tools like Snyk or Dependabot will take care of it. Who is responsible for running even a linter or a static analysis tool on an open source project and spending the time and effort in responsible disclosure with CVE.
Given this, is code review of internal code enough to trust quality & security of what we ship? Does anyone ever realistically considered reviewing OSS code used in your projects?
JohnFen•7mo ago
No single thing is enough for this. Code review is an important part, though (assuming it's properly done, which it isn't in the vast majority of cases, it seems).
> Does anyone ever realistically considered reviewing OSS code used in your projects?
In spots, yes. As a whole, no. Depending on the size of the codebase, the time and effort required to do so would often change the economics such that it would be better just to develop the code in-house.
As an unimportant aside, I am skeptical of this assertion:
> Linux Foundation survey says 70-90% of modern software constitute open source code.