Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
Developers care about security, but poorly integrated tools and other factors can cause frustration. Here are five best practices to reduce friction.
There are many benefits to implementing DevSecOps: minimized risk, reduced remediation costs, and faster and more secure product releases. But from a developer’s perspective, there’s a lot to be desired from the day-to-day practice. Developers often experience fragmented tool integration and are forced to take on additional responsibilities that can make the software development lifecycle (SDLC) seem more complex and overwhelming. They can also face development delays while working to understand, prioritize, and resolve different kinds of security alerts.
Evaluating and improving DevSecOps to make security a painless part of the current developer workflow is imperative to secure, fast delivery. Below, we’ll look at five tips for improving the experience and making security tools more usable for developers.
The “Sec” in DevSecOps stands for security, and its addition to DevOps promotes security as a core component of the SDLC. The DevSecOps approach to software development puts the responsibility of security on everyone at an organization (as opposed to just the security team) by integrating security at the start of code production—or better yet, during the planning phase before the first line of code is written. This way, organizations can catch and fix vulnerabilities in the development process rather than in production or after release.
The result: security teams can use their expertise to set security policies, prioritize remediation focus areas, and foster the right behaviors and security teachings across the organization. Meanwhile, developers can interact with security tools, and are the first line of defense in reviewing, understanding, and remediating vulnerabilities.
DevSecOps advantages include shipping secure software more quickly and reaping cost-savIng benefits. In fact, IBM’s 2023 Cost of a Data Breach report cites a $1.68M cost savings for organizations with high DevSecOps adoption compared to those with low or no adoption.
Improving the DevSecOps experience was top-of-mind for many speakers at GitHub Universe 2023. To catch you up, we pulled together the top five tips shared across various talks and interviews at the event.
GitHub Universe '23 is on demand
Check out our playlist of recorded sessions, and stay updated on the latest in AI, security, and the developer experience.
The more developers are involved in creating a security process and making policy decisions, the smoother the collaboration will be between engineering and security teams. So, before you purchase a new tool or change a policy, invite a developer champion into the conversation and ask for their feedback.
Here are some questions to get the conversation started:
It’s important to acknowledge that many security tools are built for security professionals, and can create friction when bolted onto a developer’s workflow. When trying to integrate a security tool into the SDLC, it can be more effective to extract the desired data from the security tool and natively integrate it into the developer’s workflow—or, even better, use a security tool where the data is already directly embedded into the developer’s flow. Doing so reduces context switching and ultimately helps developers to detect and remediate vulnerabilities earlier.
In 2019, we acquired Dependabot and Semmle, which developed CodeQL. While Dependabot was designed for developers, CodeQL was designed for security experts, which we knew would be a barrier to entry for developers. So, we went to work optimizing CodeQL for developers, incorporating its functionalities directly into their workflow.
Today, developers don’t have to install or set up these tools separately. They can enable Dependabot alerts from repository settings. Once enabled, alerts go out if an outdated or vulnerable dependency needs to be updated, along with critical details about the vulnerabilities—all in a pull request. Developers can also enable code scanning through CodeQL from repository settings. Doing so will notify them about new and current static analysis alerts in their code.
Niroshan Rajadurai, senior director of GTM strategy for AI and DevSecOps, and I discuss the importance of designing security tools for developers in the age of shifting left:
Another way to reduce context switching and cognitive load is implementing AI tools, like GitHub Copilot. We’ll talk more about AI security capabilities below, but let’s first focus on how they can create a smoother DevSecOps experience within the IDE.
When developers receive a security alert, they can use a tool like GitHub Copilot Chat directly in their IDE instead of having to navigate to another website to research what the alert is, and how to fix it. Beyond understanding the theory behind the alert, developers can prompt Copilot Chat to create examples of how to fix that vulnerability tailored to the code in their IDE. As a result, they get a practical, hands-on learning experience that shows how the vulnerability manifests in real code.
Joseph Katsioloudes, a developer advocate for GitHub Security Lab, shares how AI can reduce cognitive load for a developer who’s been notified about a secret injection:
Bringing security into the development process ensures that remediating alerts becomes native to the developer’s workflow. However, developers still need to know what alerts to remediate and by when. Simply asking developers to remediate all alerts is untenable and unrealistic.
When developers are shown a long PDF of 500+ alerts that they’re assigned to review and fix (a pain point I’ve written about before), it’s probable that many of the alerts are false positives and only a portion are worth addressing. Why does this matter? For one, the developer has lost valuable time reviewing all of these alerts. Second, as the tool continues to produce these laundry lists, the developer will lose trust in the tool. That could result in the developer skimming past critical alerts because of low confidence in the tool’s data.
A security tool that’s effectively integrated into the SDLC has an alert system that surfaces high-priority alerts directly to the developer. For instance, alert settings based on custom and automated triage rules ensures engineering teams address the most urgent security alerts first. Being able to filter and search code scanning alerts helps developers to sift through a large set of alerts to focus on a particular type. And providing the ability to dismiss an alert—either by fixing or closing it—will reduce noise by stopping the tool from repeatedly generating the same alert on the same code.
Combined with processes to address a percentage of critical and high-risk vulnerabilities over a period of time, an effective security alert system helps developers prioritize high-risk alerts and help to clean an organization’s security debt, that is, the vulnerabilities that accumulate over time and therefore become harder and more costly to fix.
John Swanson, director of security strategy at GitHub, shares how new technology is creating developer-first security processes that enable developers to fix vulnerabilities earlier in the SDLC:
Limited resources, rapid threat evolution, noisy false positive alerts, and the increasing complexity of systems—along with the continued use of legacy systems—can make it challenging to stay on top of the latest and most urgent vulnerabilities.
But here’s some good news: AI and automation can help reduce false positives, enable developers to conduct consistent security checks, and scale security practices all at once.
For instance, a feature like code scanning autofix streamlines remediation into the developer workflow by providing, alongside a vulnerability alert, an AI-generated code fix for CodeQL JavaScript and TypeScript in a pull request. Additionally,
secret scanning alerts developers if any secrets have been detected in code. This capability can be coupled with AI to detect generic or unstructured secrets and auto-generate custom patterns, which will detect token types unique to an organization.
Additionally, AI has the potential to enhance the modeling of an extensive range of open source frameworks and libraries. Security teams traditionally model thousands of packages and APIs by hand. Considering the sheer number and diversity of packages, along with frequent library updates, deprecations, or replacements, it’s a daunting task to keep abreast these changes and scale this modeling capability efficiently.
That’s where AI comes in. As the proportion of these frameworks are accurately modeled increases, the likelihood of diminishing false negatives also rises due to a better understanding of data flow within these systems. By turbocharging modeling efforts with AI, security experts can detect more vulnerabilities. In fact, GitHub’s CodeQL team used AI modeling to discover a new security vulnerability. Although this technology is still in the experimental phase at GitHub, we offered a glimpse into its potential during GitHub Universe 2023.
Rajadurai and I show how AI can address pressing security challenges, like modeling unknown packages, which could ultimately reduce the number of false positives:
Other automation capabilities include:
Branch protection rules that trigger code reviews when changes are made to important branches.
Status checks that require code to pass all security checks before it’s merged.
Code scans in CI/CD pipelines with GitHub Actions.
John Ruiz, security operations engineer at GitHub, emphasizes the importance of improving, then automating, basic security processes so developers can focus on what they do best, which is building great software:
A big part of improving the DevSecOps experience is not introducing more tooling, but getting clear on the process and expectations of how developers should use the tools they already have. Clear communication about policies ensures an organized and consistent approach to implementing security throughout the SDLC.
Organizations should work with vendors to create guides for how to use a new tool or product, then select security champions to echo these expectations across engineering teams.
Some principles that guide GitHub’s Product Security Engineering team when evaluating tools and designing a rollout plan include:
Clear expectations for secure coding practices help to eliminate ambiguity and increase security consciousness among developers. Selecting champions who can clearly communicate those expectations can help to model desired behavior and drive a DevSecOps culture across the organization. As a result, secure coding standards are more likely to be understood and consistently implemented by developers, which enables organizations to quickly deliver more secure software.
As developers embrace more security responsibility under the DevSecOps and shift-left models, evaluating and improving their user experience needs to be a priority. Organizations that invest in understanding a developer’s DevSecOps pain points and iterating solutions to address them, will see improved collaboration between engineering and security teams and faster delivery of more secure code.
