How we’re making security easier for the average developer

Let’s be honest—most security tools can be pretty painful to use.

These tools usually aren’t designed with you, the developer, in mind—even if it’s you, not the security team, who is often responsible for remediating issues. The worst part? You frequently need to switch back and forth between your tool and your dev environment, or add a clunky integration.

And oftentimes the alerts aren’t very actionable. You may need to spend time researching on your own. Or worse, false positives can pull you away from building the next thing. Alert fatigue creeps in, and you find yourself paying less and less attention as the vulnerabilities stack up.

We’re trying to make this better at GitHub by building security into your workflows so you can commit better code. From Secret Protection to Code Security to Dependabot and Copilot Autofix, we’re working to go beyond detection to help you prioritize and remediate problems—with a little help from AI.

We’re going to show you how to write more secure code on GitHub, all in less than 10 minutes.

At commit and before the pull request: Secret Protection

You’ve done some work and you’re ready to commit your code to GitHub. But there’s a problem: You’ve accidentally left an API key in your code.

Even if you’ve never left a secret in your code before, there’s a good chance you will someday. Leaked secrets are one of the most common, and most damaging, forms of software vulnerability. In 2024, developers across GitHub simplified the process by using Secret Protection, detecting more than 39 million secret leaks.

Let’s start with some context. Traditionally, it could take months to uncover the forgotten API key because security reviews would take place only after a new feature is finished. It might not even be discovered until someone exploited it in the wild. In that case, you’d have to return to the code, long after you’d moved on to working on other features, and rewrite it.

But GitHub Secret Protection, formerly known as Secret Scanning, can catch many types of secrets before they can cause you real pain. Secret Protection runs when you push code to your repository and will warn you if it finds something suspicious. You will know right away that something is wrong and can fix it while the code is fresh in your mind. Push protection—which blocks contributors from pushing secrets to a repository and generates an alert whenever a contributor bypasses the block—shows you exactly where the secret is so you can fix it before there’s any chance of it falling into the wrong hands. If the secret is part of a test environment or the alert is a false positive, you can easily bypass the alert, so it will never slow you down unnecessarily.

What you don’t have to do is jump to another application or three to read about a vulnerability alert or issue assignment.

After commit: Dependabot

OK, so now you’ve committed some code. Chances are it contains one or more open source dependencies.

Open source is crucial for your day-to-day development work, but a single vulnerability in a transient dependency—that is to say, your dependencies’ dependencies—could put your organization at risk (which isn’t something you want coming up in a performance review).

Dependabot, our free tool for automated software supply chain security, helps surface vulnerabilities in your dependencies in code you’ve committed. And once again, it finds problems right away—not when the security team has a chance to review a completed feature. If a fix already exists, Dependabot will create a pull request for you, enabling you to fix issues without interrupting your workflow.

Dependabot now features data to help you prioritize fixes. Specifically, alerts now include Exploit Prediction Scoring System (EPSS) data from the global Forum of Incident Response and Security Teams to help you prioritize alerts based on exploit likelihood. Only 10% of vulnerability alerts have an EPSS score above 0.95%, so you can focus on fixing this smaller subset of more urgent vulnerabilities. It can really make your backlog easier to manage and keep you from spending time on low-risk issues.

At the pull request: Code Security

You’ve committed some code, you’re confident you haven’t leaked any secrets, and you’re not relying on dependencies with known vulnerabilities. So, naturally, you create a pull request. Traditionally, you might be expected to run some linters and security scanning tools yourself, probably switching between a number of disparate tools. Thanks to our automation platform GitHub Actions, all of this happens as soon as you file your pull request.

You can run a variety of different security tools using Actions or our security scanning service GitHub Code Security (formerly known as Code Scanning). Our semantic static analysis engine CodeQL transforms your code into a database that you can query to surface known vulnerabilities and their unknown variations, potentially unsafe coding practices, and other code quality issues.

You can write your own CodeQL queries, but GitHub provides thousands of queries that cover the most critical types of vulnerabilities. These queries have been selected for their high level of accuracy, ensuring a low false positive rate for the user.

But we don’t just flag problems. We now recommend solutions for 90% of alert types in JavaScript, Typescript, Java, and Python thanks to GitHub Copilot Autofix, a new feature available for free on public repositories or as part of GitHub Code Security for private repositories.

Let’s say you’ve got a pesky SQL injection vulnerability (it happens all the time). Copilot Autofix will create a pull request for you with a suggested fix, so you can quickly patch a vulnerability. You no longer need to be a security expert to find a fix. We’ve found that teams using Autofix remediate vulnerabilities up to 60% faster, significantly reducing Mean Time to Remediation (MTTR).

This is what we mean when we say “found means fixed.” We don’t want to put more work on your already overloaded kanban board. Our security tools are designed for remediation, not just detection.

Take this with you

Keep in mind you probably won’t need to touch all those security tools every time you commit or file a pull request. They’ll only pop up when they’re needed and will otherwise stay out of your way, quietly scanning for trouble in the background.

When they do show up, they show up with good reason. It’s much less work to handle vulnerabilities at the point of commit or pull request than it is to wait until months or years later. And with actionable solutions right at your fingertips, you won’t need to spend as much time going back and forth with your security team.

Writing secure code takes effort. But by integrating security protections and automatic suggestions natively into your development workflow, we’re making shifting left easier and less time consuming than the status quo.

The post How we’re making security easier for the average developer appeared first on The GitHub Blog.

Source: Read More