Faking GitHub Commits – What Could Go Wrong?

Today I naively learned that there are developers whose professional evaluation depends at least in part on the volume of their Github commits.

Today I also learned about the GitHub Activity Generator, which creates dummy commits in order to fudge statistics, potentially helping to manipulate badly-designed and -conceived employee ratings based on inappropriate statistics – an unfortunately very common trend in a lot of companies (see also: mandatory 5-point ratings/employee ratings curves).

https://github.com/Shpota/github-activity-generator

From a supply chain risk management perspective, what could possibly go wrong? There’s a very good reason for the existence of a vast ecosystem of products and services dealing with security assurance – from secure coding practices developer training, static / dynamic analysis, and other aspects of shift-left information security, to in-production testing and vulnerability scanning.

This particular toy doesn’t do anything insidious – just creating a text file and committing changes to it. However, it is not only illustrative of a deeply flawed system. It indicates that we could see an increase in badly designed, untested code rushed into production because developers are rated on quantity rather than quality.

Source code on GitHub and other repositories has been a vector for numerous cybersecurity vulnerabilities and even supply chain attacks in the past. Vulnerability scanners will not always catch these – see the large number of vendors who claim to have spotted security holes their competition never found. How many of these go undetected?

When you create perverse incentives because of bad management practices, this can have very real world consequences, and open barn door-sized holes for attackers. It’s not a technology issue, it’s a leadership issue. Think about that.