Privacy

Advanced Persistent Threat. For example, we assume the Lazarus Group is responsible for several high profile attacks. We don’t have anything close to the evidence here for direct attribution; using that as a bar I’d say the Proton attribution is pretty strong. Since my callout was security-focused, I wanted to ground it in other security terms. Your point was completely spot on and it was a great reminder to me because sometimes I forget the basics.

For folks that don’t know, there are a few bad things with the Proton response. First and foremost, you don’t rewrite main ever just from a development perspective. It usually causes more trouble than it’s worth unless you’re a team of one and no one else has ever touched your repo. From a security perspective, it’s very misleading to assume rewriting history can clear history from GitHub as I hope I’ve shown here. Additionally, anyone with a local copy of the repo from before the rewrite can use the reflog to access that history. While it won’t work for any new pulls post-rewrite, it’s still a risk for a large repo like this.

The correct way to handle this or other sensitive information being added to a repo is to use remove the file in a merge and rotate any secrets exposed. Take the hit on the chin; security is just about reducing risk not removing it. I have cleaned up plenty of repos before. Tools like gitleaks can search your active tree as well as your history for exposed secrets. Delete, commit, own the failure. Proper ignore files, meticulous review, and automated checks also help reduce risk.

Overall that’s why I think this is dumb. To me it would be a non-issue if a security-minded company had used security best practices to handle this.