Code repository, GitHub, has formally released its code scanning feature. Code scanning looks through a developers code to identify security vulnerabilities. It then alerts the developer to allow them to patch their code before they release it to a wider audience.
In a blog, Justin Hutchings, Staff Product Manager, GitHub, he said: “GitHub code scanning is a developer-first, GitHub-native approach to easily find security vulnerabilities before they reach production. We’re thrilled to announce the general availability of code scanning. You can enable it on your public repository today!”
GitHub beta phase shows some good results
The feature has been in beta since May. During that time, Hutchings reports that GitHub has scanned 12,000 repositories 1.4 million times. That equates to around 116 scans per repository. Those scans found more than 20,000 security issues. Developers responded by fixing 72% of those errors in the last 30 days. This latter figure is good news as it shows that the majority of developers involved in the beta realised the need to fix their code.
It’s certainly a good start, but there is a long way to go. In January, GitHub claimed to have over 100 million repositories. Scanning just 12,000 is an inconsequential percentage. The question for GitHub is, can it scale up to scan all the repositories on the platform? Given it has scanned the beta repositories an average of 116 times each, the compute power to expand this is substantial. Doing so would also come with significant costs. How will this be paid for?
Is this the end of bad code?
No. Let me say that again, No! What it does mean is that GitHub is trying to do something about it and that is good news.
However, many security researchers and malware writers store code in GitHub because it is convenient. GitHub was asked if they would expand code scanning to identify and stop that code being held in the platform.
It replied: “On background – Code scanning is opt-in and focused on security issues and weaknesses as opposed to malware, and is designed to help maintainers and developers prevent vulnerabilities from creeping into their code.
“Regarding malware, as stated in GitHub’s Acceptable Use Policies, “under no circumstances will Users upload, post, host, execute, or transmit any Content to any repositories that contains or installs any active malware or exploits, or uses our platform for exploit delivery (such as part of a command and control system),” and we do our part to remove active exploits where reported.”
Enterprise Times: What does this mean?
For enterprise development teams who use GitHub, this has to be good news. The ability to opt-in and add additional security checks is good news. It should not, however, be seen as a replacement for other processes that companies use to check their code. Instead, it provides a useful cross-check on the state of code.
Security teams will look at this announcement with mixed feelings. Those that have tried to limit the use of code from GitHub by their developers will point to the number of vulnerabilities found. Others will point out how quickly the majority were fixed.
One change that might satisfy both groups is for security to say that only code from developers who opt-in can be pulled down. It could be supported by a requirement for any used code repositories to publish their fix lists. This should help drive greater adoption of code scanning if GitHub can scale to support it.
The comment about malware is as to be expected. Despite its claims, finding malware hosted on GitHub is not hard. Many developers simply link to their repository in public forums. The continued use of its platform as a host shows it is also not effective at stopping code being stored there. There is a case that a tough crackdown would also impact legitimate security researchers who stored Proof of Concept code on the platform.
Code scanning by GitHub makes sense. How effective it will be remains to be seen. Early signs are that it has a real benefit. However, until there are regular updates on the number of users, repositories scanned and vulnerabilities identified and fixed, we won’t know its true effectiveness.
