How to Get Developers to Accept Security PRs Faster
Improve your mean time to remediation (MTTR) with smarter automatic pull requests that use upgrade impact analysis to reduce alert fatigue for developers.
Improve your mean time to remediation (MTTR) with smarter automatic pull requests that use upgrade impact analysis to reduce alert fatigue for developers.
Improve your mean time to remediation (MTTR) with smarter automatic pull requests that use upgrade impact analysis to reduce alert fatigue for developers.
Improve your mean time to remediation (MTTR) with smarter automatic pull requests that use upgrade impact analysis to reduce alert fatigue for developers.
Improve your mean time to remediation (MTTR) with smarter automatic pull requests that use upgrade impact analysis to reduce alert fatigue for developers.
It’s not uncommon for application security teams to struggle with improving their mean time to remediation (MTTR) goals, or to have trouble meeting 30-day SLAs for vulnerabilities under compliance frameworks like FedRAMP.
The natural reaction is to blame organizational misalignment – security teams believe developers aren't taking action quickly enough, while developers feel overwhelmed by an endless stream of security-related alerts. According to research from the IDC, the average enterprise is struggling under the burden of more than 1 million security alerts each year from their security tools.
Before long, everyone is pointing fingers while nothing gets fixed.
The reality? This isn't only an organizational problem – it's also a tooling problem.
First, it’s important to acknowledge that developers generally try to address security risks. According to a recent study, developers are more receptive (higher merge rates) but less responsive (more time to close or merge) to security pull requests (PRs). Developers will rapidly merge PRs they view as safe, while taking longer to perform manual updates for the remaining PRs.
So what’s slowing developers down?
Traditional SCA tools often don’t understand the complexity of an upgrade and simply instruct developers to upgrade to the latest version of an open source library or package. Unfortunately, that request misses a lot of complexity. Developers have to spend time investigating each alert and attempting to fix whatever breaks when they upgrade. So while automatic PRs are useful – they just lack enough data to be helpful.
At Endor Labs, we developed a different approach to automated PRs. Because we understand how your application works, we also understand the difficulty of an upgrade. That way we can help you make sure you don’t send PRs that waste developers’ time. The result? Faster remediation times and better collaboration between security and development teams.
Why traditional automated PRs fall short
First, it might be helpful to understand why the current approach is failing, and why your current SCA tooling is probably to blame. Most SCA tools operate with limited context about your application. They scan the application manifest for a list of your dependencies, generate a list of known vulnerabilities for those packages, and then automatically generate pull requests for each of their findings.
This creates several fundamental problems:
- First, there's a disconnect between how security teams and developers approach remediation. Security teams think in terms of vulnerabilities (the problem), while developers work with package upgrades (the solution). Traditional tools create separate findings for each vulnerability, when in reality, a single package upgrade might fix dozens of security issues.
- Second, existing tools lack context. They either cannot determine if the vulnerability is reachable, and generate too many false positives. Or they alert you about reachable vulnerabilities without context about breaking changes. Either way, developers get drowned in noise.
- Finally, they guess about the complexity of an upgrade. Other products guess about the complexity of an upgrade based on how many other people accepted the PR. But why should you trust what worked for others when you can get insights about what works for you?
This was exactly the experience of the team at Grip Security. Their developers found themselves constantly context-switching between investigating security alerts and their regular development work. As Idan Fast, the co-founder and CTO of Grip Security noted, “Inaccurate SCA results created two problems: wasted time and developer inefficiency. Individuals had to choose between upgrading a package (and entering dependency hell) or waiting for DevOps to investigate." Grip Security switched to Endor Labs and reduced SCA noise by 99% — you can read more about their story here.Introducing a smarter approach to automated PRsEndor Labs uses a different approach for generating automated pull requests. Instead of generating pull requests for every vulnerability, our automated pull requests leverage upgrade impact analysis. That way you can reduce the number of automatic PRs to just the ones you think will succeed.We analyze your application at build time to identify what dependencies are reachable in your code. This helps us understand both your application and the changes between versions of each package. We identify which version upgrades are low risk for introducing breaking changes, and which are likely to result in substantial work for your software engineering teams. Instead of handing your software development team a list of 160 vulnerability findings, you can give them upgrade recommendations.
Using this context, you can customize how to handle different types of vulnerabilities. For example, you can configure the system to take different actions based on the level of risk in an upgrade:
- Low risk – Automatically create pull requests for upgrades that are unlikely to cause problems for your software engineering team
- Medium and high risk – Generate JIRA tickets for upgrades that require planning and coordination with your software engineering team
Automated pull requests are available through our GitHub App, making it easy to incorporate into your existing workflows. Today it’s available for Java and Go codebases, with support for JavaScript, Python, and .NET coming soon.Moving beyond fix all the thingsApplication security teams can build credibility with their software engineering counterparts by moving beyond a “fix all the things” approach. Instead, they can provide actionable, contextualized recommendations directly to developers so they can easily take action, or get more context about a difficult upgrade and plan accordingly.The result is faster remediation of real risks, better collaboration between security and development teams, and less time spent investigating false positives. If you’d like to learn more about how Endor Labs can help your team, schedule a conversation to chat with our team.
