GitHub's open-source code scanning tool looks for security holes in real-time

Cal Jeffrey

Posts: 4,180   +1,427
Staff member
Why it matters: What if companies and independent software developers could spot security flaws in their programs before releasing them to the public? GitHub now has a tool that can help them do just that. It scans code as it is entered, looking for common issues like RCE, XSS, and SQL injection vulnerabilities, so programmers can fix the flaws before the software goes into production.

On Thursday, GitHub announced that after extensive testing, it launched a native code scanner that can detect security flaws in posted programs or code as it is being entered. The tool is powered by CodeQL—an open-source semantic code analyzer.

The scanner can work in real-time as code is entered, so flaws never get to the software's final production version. Alternatively, completed code can be tested within public repositories. GitHub and others in the community have created more than 2,000 queries to find patterns in code blocks that identify common security vulnerabilities. Users can also create custom queries as the need arises.

The software entered beta in May and has since seen significant results. GitHub scanned more than 12,000 repositories 1.4 million times and found around 20,000 security flaws. Some of the issues it uncovered included remote code execution (RCE), SQL injection, and cross-site scripting (XSS) vulnerabilities. Developers have already fixed 72% of the reported errors within 30 days.

"We're proud to see this impact, given industry data shows that less than 30% of all flaws are fixed one month after discovery," GitHub said in its blog.

Community members have also expanded the CodeQL query set by 132 contributions since the tool entered beta.

Code scanning is found in GitHub Actions, but can also be integrated into existing CI/CD solutions. It is free for users with public repositories. Private collections require GitHub Enterprise.

Permalink to story.

 
>> " Some of the issues it uncovered included remote code execution (RCE), SQL injection, and cross-site scripting (XSS) vulnerabilities "

In other words, by far the easiest exploits to spot at the code level. This tool is better than a kick in the head, but hardly going to be a panacea for any and all code vulnerabilities.
 
Not as it's entered, but as it's about to be committed to the repository
GitHub blog post: "It scans code as it’s created and surfaces actionable security reviews within pull requests and other GitHub experiences you use everyday, automating security as a part of your workflow."

Did I misinterpret that statement? It certainly sounds like the app works as you enter code, but maybe I'm missing something.

>> " Some of the issues it uncovered included remote code execution (RCE), SQL injection, and cross-site scripting (XSS) vulnerabilities "

In other words, by far the easiest exploits to spot at the code level. This tool is better than a kick in the head, but hardly going to be a panacea for any and all code vulnerabilities.
Those are only three of over 2,000 security queries. GitHub did not have a quickly accessible list of all the queries in the database, so just went with the examples they had in the blogpost.
 
GitHub blog post: "It scans code as it’s created and surfaces actionable security reviews within pull requests and other GitHub experiences you use everyday, automating security as a part of your workflow."

Did I misinterpret that statement? It certainly sounds like the app works as you enter code, but maybe I'm missing something.
It's not an app, and it's not working as you enter code.

It's a service integral to the GitHub website/backend service, that scans the already 'entered' (created) code after you've uploaded it to the repository in a thing called "pull request", which is a request to commit an improved or modified version of the code to the central repository, the actual shared codebase of a project on GitHub's servers.

Repo admins then can review the changes included in this submit before merging it with the central repo - and that's when/where they (or anyone who looks at the pull request for that matter) can see the warnings for potential bugs from this newly integrated code scanning tool.
 
Back