How Snyk is prioritizing developer experience

Context switching can be security’s worst enemy. Today’s security practices require developer buy-in, and when security teams require developers to deviate from their established workflows to address issues, adoption becomes far less likely.

To truly empower developers to find and fix vulnerabilities within their code, security teams must shift security even further left. It’s not enough to simply provide user-friendly tools and training around them. If the tool still requires developers to interrupt their workflow to perform security-related tasks, it adds cognitive load. Developers often don’t have the time or resources to add another task to their already full plates.

To address these challenges, Snyk is releasing new features that enhance our developer-first solutions and enable security teams to continue adapting to the new realities of today’s development lifecycles. We recently offered our users a glimpse of these new features in our latest SnykLaunch, now available on-demand. In this blog post, we’ll look at the new releases that directly improve the developer experience and cover why they matter for today’s teams. 

The cost of context switching

Developers spend a good chunk of time in three places: their IDEs, the CLI, and the SCM. While it might sound simple for a developer to get a security alert about their ongoing project and to jump over to a separate platform to address the issue, it often isn’t. That context switch not only takes devs out of their familiar work streams, it creates added steps to software development, interrupting their productivity flow and requiring them to bounce back and forth between multiple systems to perform security-related tasks. 

Developers perform most of their code authoring in their IDE–whether it's hand-written code, code that's created by generative AI, or a mix. They branch or fork the code, incrementally push their code to their SCM, and, when they're ready, they create a "pull request" (PR). A pull request is designed for seamless collaboration and code review. Interrupting this process by forcing developers to leave the SCM workflow to address security issues adds an unexpected task and breaks their momentum, defeating the purpose of an efficient PR workflow. It’s like getting a surprise item added to your to-do list when you think that you’re almost done.

This level of disconnect between development and security teams harms DevSecOps efforts. Security teams often wonder why more developers aren’t adopting their tools, while developers may resist interruptions to their workflow caused by an unexpected task. It’s a lose-lose situation for everyone involved.

Two pillars of developer experience

Instead of asking developers to abandon their focus when addressing security issues, security teams must meet them in the tools they already use. Two foundational ideas can help them do so:

1. Empowering developers with information in the context they are working in

Developers need some level of background information to successfully fix security issues in their code. This information might include why a particular line was flagged as vulnerable and how to make changes that will mitigate the vulnerability. However, security teams can’t expect developers to parse through generic documentation or go through tutorials on a security platform to solve the problem. They need to provide bite-sized educational resources that give the developers some brief background and remediation advice—no more and no less. 

2. Reducing friction and minimizing disruption to workflows

Snyk already helps developers find and fix security vulnerabilities directly within their IDEs. Recognizing that developers also spend a significant amount of time working in their SCM, Snyk is further expanding our developer-first tooling by integrating security insights into SCM PR workflows. This allows developers to get security feedback seamlessly within their familiar daily tools. 

Snyk’s new PR features for a better developer experience 

From our experience working directly with development teams and helping developers integrate security in their IDEs, we’ve seen that the best place to include security is in the tools the developers already use. Now when a developer clicks the "create PR" button, Snyk's PR checks (GA for Snyk Open Souce and early access for Snyk Code) can a security code review right in standard PR workflows.

Upon completion of the PR Check scan, our new "issues summary" feature delivers a comment in the SCM with a summary of security findings, right in the developers' PR workflow. This data summarizes security findings by severity and provides developers with direct links to review and address the issues.

In addition, we are now offering customizable PR templates, which allows teams to customize Snyk-generated PRs.Snyk's new customizable PR templates align Snyk-generated pull requests with your organization’s specific standards, practices, and communication preferences. You can specify the title and description, which security details to share, and even JIRA ticket information, all to match what your developers expect to see in their PRs. By tailoring our features to match your specific organization, you can make the workflow fit into developers’ existing processes even more seamlessly. 

To learn more about these new pull request features, be sure to tune into latest our SnykLaunch presentation.