I can 100% judge him. It is the CTO's job to put in place processes and safeguards that reduce the possibility of one of the most common widely known security vulnerabilities. Either he didn't put in the safeguards or he bypassed them, either way it's a fireable offense that put the whole business in danger.
Do you have your commit history available in a public repository? I don't. Honestly, i'm paid for being a professional fuck-up. I just fix things quickly and support my team enough for us to bear the mutual guilt in silence.
There are SQL injection fuzzing tools that will have no problem catching this. This is not the kind of security defect that would depend on "white box" testing.
If you're suggesting that the obscurity of closed source would have prevented the hack then I very much disagree. There are countless examples of sql injection attacks in closed source software.
I am commenting on the core foundation of the "article", to quote:
> "A quick review of Gab’s open source code shows that the critical vulnerability—or at least one very much like it—was introduced by the company’s chief technology officer."
What would the writer have without the open source?
Ok that's true. With a closed source process the company gets to more carefully control the narrative. That might be better for the company and for protecting reputations, but it's not better for the public at large.
Further, with a closed model, one can always peruse the emergency clause, force majeure, the ever popular "state actor".
"Independent experts indicate (fee undisclosed), a powerful malevolent actor was involved in the recent malicious attack on our infrastructure. This aligns with the recent series of threats identified by the State Department and other US government agencies as enemy state activity to undermine Democracy! They hate our Freedom!"
