Code Scanning – GitHub’s Latest Feature Making Your Software More Secure

In a previous blog post, we mentioned that the average cost per data breach has increased from $3.54 million in 2006 to $8.19 million in 2019 and that the frequency of breaches is only going up as a result of the current pandemic.

With an estimated 60% of security breaches involve unpatched vulnerabilities and 99% of all software projects said to contain at least one open source component; When it comes to ensuring your code is secure, there has never been a more important time to make sure any vulnerabilities are found and addressed quickly.

Enter GitHub’s new feature - Code Scanning, a developer-first, GitHub-native approach to easily find security vulnerabilities before they reach production – available now and can be enabled it on your public repository today.

Over a year in the works, since they welcomed Semmle, they have been working to bring the revolutionary code analysis capabilities of its CodeQL technology to GitHub users as a native capability. 

So how does it work?

Code scanning integrates with GitHub Actions – or your existing CI/CD environment – to maximize flexibility for you and your team.

Instead of overwhelming you with linting suggestions, code scanning runs only the actionable security rules by default so that you can stay focused on the task at hand.

It scans code as it’s created and highlights actionable security reviews within pull requests and other GitHub experiences you use every day, automating security as a part of your workflow. This helps ensure vulnerabilities never make it to production in the first place.

You can also integrate third-party scanning engines to view results from all your security tools in a single interface and export multiple scan results through a single API. and GitHub have already announced they will be adding more integrations to their partner ecosystem in the near future.

The results so far! 

Since introducing the beta in May:

• They have already scanned over 12,000 repositories 1.4 million times, and found more than 20,000 security issues including remote code execution (RCE), SQL injection, and cross site scripting (XSS) vulnerabilities.
• Developers and maintainers fixed 72% of reported security errors identified in their pull requests before merging in the last 30 days – Impressive given industry data shows that less than 30% of flaws are fixed one month after discovery.

As nascent best DevSecOps practices are in most organizations, making SAST tools available to developers is a major step forward for many organizations. The challenge has been finding SAST tools that developers want to employ as most SAST tools are designed for security teams rather than developers, said Justin Hutchings (product manager at GitHub). 

It’s not clear yet to what degree responsibility for security will shift toward developers – Of course there will always be a need for cybersecurity teams to verify that the proper controls are in place. However, as DevOps teams assume responsibility for security it’s almost certain they will do so on their own terms. 

The days when cybersecurity teams select the security tools that developers are expected to employ may well now be all but over.

Let us know your thoughts, is this something you or your team have already put to use? Or something that could help streamline your workflows?

For more latest insights from Foundations Executive Search and information 

on how we can help you find the industry’s most talented candidates see more of our Latest Insights,or Contact Us directly.