Best practices for rolling out Snyk

The first question many customers ask us after purchasing Snyk is—now how do we roll out the product throughout the company? Whether it’s a security expert who wants to get dev teams involved, and shift security testing left, or the VP of Engineering who’s trying to decide where best to integrate Snyk in the pipeline, as Snyk’s Customer Success Managers, we hear this question a lot.

There are some basic conditions that could definitely help accelerate your efforts —developers who are already involved in security, management who pushes the effort, or even compliance issues.

But what can you do if those don’t apply to your company? Though we at Snyk do have a general idea of how this should be done, particularly having worked with so many customers, we realize that the best people to answer this question are our customers themselves — customers who have already implemented Snyk successfully. So, we decided to collect advice from exactly those customers.

We started by having a series of interviews with our most successful customers. We chose customers of various sizes, industries and tool preference to get the broadest view possible on this matter. We spoke with a variety of customers with completely different organizational structures from each other, and who have very different motivations and goals for implementing Snyk. We then took their ideas and refined them in order to design a best practice model which we believe is the most effective and comprehensive way to add Snyk as part of your development process and start fixing security vulnerabilities.

The model comprises these steps:

1. Team—find the right team to start implementation with

2. Train—design training for your users suited to your unique organizational needs

3. KPIs—set clear KPIs compatible with your goals

4. Policy—establish official processes that determine how users should treat information coming from Snyk

5. Integrate—set up Snyk at the critical point of your software development lifecycle (SDLC)

6. Feedback—provide feedback to your teams

Let’s drill down.

Find the right team to start with

Many of our successful customers started the roll-out process by getting just one team on board. Starting small might sound a little too cautious; however, as these customers reported back to us, starting small gives you room to try out different things, get insights from your developers on their preferred ways of working, and then make adjustments accordingly.

Choosing which team to go first is also a relevant question. Try to identify which of your developer teams is the most influential one, the team that sets the tone for others. Once that team was up and running smoothly, word of Snyk will spread organically to other teams and the demand for Snyk will come from within.

Provide internal training resources

Snyk offers several resources for training, such as video-call training sessions, a training deck and blog posts. Some customers amplify these resources by sharing them within their company as a way to intrigue developers about security. Others chose to create their own training materials to match their specific work methods. One of our biggest customer’s security team created a demo video which they present to each team when starting integration. The video includes all the specific integrations and languages that developer teams in the organization work with.

Another cool way of sharing information, as mentioned by another one of our top customers, is an internal Slack channel dedicated to discussing Snyk. In the channel, developers share their own best practices and ask each other questions. Peer knowledge sharing is an excellent training method that also “spreads the word” quickly, by word of mouth.

Set clear KPIs

As for every project you launch, rolling out Snyk throughout the organization should outline clear KPI goals when planning your Snyk roll out. Whether team-based or company-based, these KPIs should be reflected internally when the process begins, so that your developers can work towards them from the beginning of the process with Snyk. Customers reported using KPIs such as increasing projects added to Snyk, reducing their overall number of vulnerabilities, and increasing fixes. These are all also reflected in the Report tab of the Snyk UI, and accessible by our API as well, enabling you, your team, and your developers to track such KPIs smoothly.

Establish a standard policy

Setting measurable KPIs is great as it helps set targets very clearly. On top of that, creating a policy or protocol can illustrate a clear and enforced path to reaching those targets. Customers reported creating a framework through which they cope with newly disclosed vulnerabilities, including a time frame by which they’re obligated to fix each type of vulnerability. You can also specify the stages at which each type of vulnerability should be dealt with and each vulnerability should be tracked, from opening a Jira ticket to which team member should handle which project. Determining these guidelines in advance with the help of your teams and sharing the final plan makes it easier for your developers to handle issues as they arise.

Set Snyk up at a critical SDLC point

Snyk can integrate at a variety of different points throughout the SDLC: from our CLI interface, through one-click Git integrations, and by adding Snyk as a failing stage in your CI/CD pipeline. Successful customers pointed out to us that they started off by integrating only one part of their SDLC, and then later added Snyk to additional stages. There are different advantages to each starting point—better visibility of the team’s work for Git integrations, safer deployment with CI integration and so on. When choosing which starting point best suits your needs, it is important to involve your dev teams so they know to expect this. We also suggest encouraging teams to use the Snyk CLI interface and IDE plugins that we offer. The further left you integrate Snyk in the development process, the easier it will be to fix issues that may arise.

Provide feedback

Giving feedback is an important part of every process; but when dealing with security and often times, compliance, it’s all the more critical to the success of the implementation process. Before rating developers based on  KPIs, check to see if the team has actually implemented: have they uploaded their projects? Did they start fixing? This could be your starting point to better visibility of implementation. Once dev teams start testing and fixing, it’s valuable to then go back and evaluate the KPIs on a regular basis, every quarter or month, to see how the team has progressed. Some of our customers even create a scoreboard to celebrate their top teams. Whatever you decide to do, reflecting on the progress your teams have made helps you encourage them and keep track of security status better and better.

Whether you choose to use some or all of these steps in any order, note that the main theme of the entire process is to involve the dev team. Snyk was designed for developers, and we want it to be a tool developers love to use. Having them play an active role in the implementation process makes it easier for you to make sure their engaged throughout, and get your application more secure, faster.

Stay secure!