4 ms·

Strong disagree. It’s not GitHub’s job to tell you what’s good or bad. Only the user of the code can do that because it’s context specific. “I can trust this c

Strong disagree. It’s not GitHub’s job to tell you what’s good or bad. Only the user of the code can do that because it’s context specific. “I can trust this code” is a fantasy that won’t happen. Don’t trust code, test it.

brookst 3y ago
This seems like the “don’t use seat belts, drive safely” argument. Trust mechanisms in GitHub/etc can’t solve the whole problem, for sure. But some automated safety mechanisms at scale can reduce the risk for those who don’t follow perfect security practices, which has value to the world at large. Very few of us have the capacity to do even cursory validation for every update to every dependency of every bit of software we use.
- 2devnull 3y ago
  I’m not saying don’t scan code for vulnerabilities, I’m saying GitHub shouldn’t be the place that the scanning happens. A good place would be where the code is getting compiled /executed.
  - Too 3y ago
    That’s simply not possible. How do define a vulnerability? That’s all context dependent. It could be something as subtle as skipping an auth check if a magic string is part of the payload. The main benefit of reusing software packages is that you don’t want to spend the effort of writing/reviewing all the internals of the component. At some point, to trust an abstraction blindly, you need to instead follow reputation. Who has authority to say what is reputable or not is the difficult dilemma. As seen with CVE authorities lately, it’s not easy. As much as they undermine their own authority by declaring everything as a CVE, vice versa, declaring every org in GitHub as “Verified” may eventually be easy for scammers to get as well. Back in the days, just having an SSL certificate on your web site was a big stamp of trust. Now everybody has it and it doesn’t mean anything.
  - brookst 3y ago
    Are you saying github should not scan? I don’t think there’s a central planner who will enforce that scanning is only in one place.

brookst 3y ago

This seems like the “don’t use seat belts, drive safely” argument. Trust mechanisms in GitHub/etc can’t solve the whole problem, for sure. But some automated safety mechanisms at scale can reduce the risk for those who don’t follow perfect security practices, which has value to the world at large. Very few of us have the capacity to do even cursory validation for every update to every dependency of every bit of software we use.

2devnull 3y ago
I’m not saying don’t scan code for vulnerabilities, I’m saying GitHub shouldn’t be the place that the scanning happens. A good place would be where the code is getting compiled /executed.
- Too 3y ago
  That’s simply not possible. How do define a vulnerability? That’s all context dependent. It could be something as subtle as skipping an auth check if a magic string is part of the payload. The main benefit of reusing software packages is that you don’t want to spend the effort of writing/reviewing all the internals of the component. At some point, to trust an abstraction blindly, you need to instead follow reputation. Who has authority to say what is reputable or not is the difficult dilemma. As seen with CVE authorities lately, it’s not easy. As much as they undermine their own authority by declaring everything as a CVE, vice versa, declaring every org in GitHub as “Verified” may eventually be easy for scammers to get as well. Back in the days, just having an SSL certificate on your web site was a big stamp of trust. Now everybody has it and it doesn’t mean anything.
- brookst 3y ago
  Are you saying github should not scan? I don’t think there’s a central planner who will enforce that scanning is only in one place.