Snyk & Intuit roundtable: Breaking silos, engaging with security and developer communities

I recently attended a Snyk roundtable with Intuit, and it was such a good session that I wanted to write a post sharing some of the insightful discussion and takeaways — starting with this great artistic impression of the session! As a TL;DR, here are my biggest takeaways from the session:

• Present security tasks to developers as a way to help them do their job, such as avoiding rework.

• Work to make the fix the path of least resistance for a developer, with tools that developers want to use.

• Don’t try to make every developer a security expert, focus on those that want to learn more.

• Participation in a champions program should be voluntary, with rewards, recognition and benefits being the driver behind organic community growth.

• Measure achievements, rather than the lack of violations.

• Share anecdotal success from teams doing a good job to breed further success.

Do developers even care about security?

The discussion started on a bombshell statement that developers mostly don’t care about security. It’s often seen as more work, without the accolades one might get if there were to ship a feature, for example. Of course this doesn’t mean that developers don’t want to do the right thing, most of the time, they do. However, how can we make security more appealing?

Another aspect that compounds the problem of putting developers off security is the terminology that’s used. When obscure terms, such as SCA, SAST, DAST, RASP are used — which the average developer will never have heard of — it can make life harder and more confusing for developers. It’s important to break down these three and four letter acronyms that make sense to the security team, and make them more consumable for developers.

So how can we make security appealing to developers?

Here were some suggestions to improve developer security:

• Present it in a way that helps developers, such as avoiding rework.

• Work to make the fix the path of least resistance.

• Select tools that developers want to use.

Avoid rework

One suggestion that went over well among those around the table was to present security in a way which resonates. Every developer hates rework. Putting security in  a position to prevent rework means we stop talking about security and start talking about doing certain activities early to avoid a lot of later rework fixing those security issues.

Make security the path of least resistance

Of course, it’s really important to prevent security issues. They’re not just expensive to handle, they’re also a red mark on a project that developers don’t want to see. To avoid this reaction, it’s key to provide understandable policies and visibility that works in a natural security feedback loop to make it easier for developers to not make mistakes. Give them a path of least resistance that encourages the fix, rather than the avoidance.

Developer-first tools

Of course, tooling also has a part to play in how developers find and fix security issues. An important point Vlad Nikolov, from Intuit, raised was how he encourages developers to bring their own security tools. People want the feeling of contribution and ownership, and Vlad told the story of how Snyk was brought into Intuit, through the development team bringing it to security as the tool they wanted to use.

How do we better educate developers?

Here are some important initial thoughts that are worth recognising up front:

• Security isn’t taught as part of software development at schools, so it’s a hurdle from the start.

• Don’t try to make every developer an expert, focus on those that want to learn more.

Security education

In order to make security a part of a developers day, it must be a natural addition to their process and understanding of software development. It was observed that developers going through the college and university education process tend not to even hear about the OWASP Top Ten, or secure development and design principles at the same time as software development. To truly integrate security into the software development process, it needs to be taught with software development in schools, so that engineers associate secure coding with software development in general.

Teams need broad security expertise, not individuals

However, didn’t we start this roundtable discussion by saying developers don’t really care about security? How do we make sure development teams are well educated and knowledgeable about security practices if it’s not always front of mind and something they want to learn? The important distinction to make here is around the level of security depth the development teams should have. Developers don’t need to be experts in security, but should be capable in a number of areas, a good example being threat modelling. Having developers ask the “what if” questions will enable them to think about the right flows needed to reduce security risks.

Nurture curiosity through a security champions program

There were two big takeaways from this topic for me which are:

• Spend time with those developers who are naturally curious and want to learn more about security.

• Participation in a champions program should be voluntary, with rewards, recognition and benefits being the driver behind organic community growth

Turn curiosity into expertise

We need to recognise that there are a couple of different types of developers, those that are security curious, who we want to work closely with, and those who perform security by necessity. With the latter, they’ll do the minimum necessary in order to get their tasks done. So for them, the threshold of what needs to be done should be low and the security process simplified. But for the security curious type of person, we should try to nurture them and tap into that curious nature, potentially through a security champions program.

Security champions need to be volunteers

The group agreed that participation in a security championsprogram should be voluntary. From a security team point of view, such a program is a great way to bring together your security allies from dispersed development teams, who want to be there. Run successfully, it will be a place for people to trickle in over time, again through voluntary participation, as they see the benefit, reward and recognition received by those in the program.

Celebrate and reward achievements

Celebrating success and rewarding those involved was a strong theme that all agreed with. Here are some thoughts around how this can be achieved:

• Measure achievements, rather than the lack of violations.

• Share anecdotal success from teams doing a good job to breed further success.

• Go beyond operational measurements and celebrate successes such as process and posture adoption.

It’s a fair observation that most organisations measure the security of their projects by their security violations, rather than their successes. This is, in most part, due to the fact that it’s an easier metric to consistently track across various development teams. However this approach focuses on what’s wrong with the projects rather than what’s been done successfully. there’s little to shout about to the wider development communities when things are working well, other than having fewer issues.

In contrast, what we really want to talk about is the number of times a developer has found and fixed a vulnerability before it becomes a violation. This is a real measure of a successful security program, and one whose KPI rotates around actions that improve security. Furthermore, these activities should be rewarded and gamified, to acknowledge the great work developers and teams are doing to improve their security posture and encourage others to do the same.

This is easier said than done, and while it was reassuring to hear everyone was on the same page with this sentiment, it was harder to see working examples of this happening today. There were some steps that folks around the table did want to take, including changing our language to make terminology more accessible for developers. Providing more anecdotal encouragement, recognition and showcase those developers who are doing a great job at fixing vulnerabilities, with the ambition that others will follow and change their behaviours to become more security minded.

An achievement doesn’t always have to be around an operational metric, it could be something more inline with security in your pipeline or processes for example. One idea mentioned was a grading system that highlights where you and your team’s security posture stands today, as well as a plan or direction of what you want to change and improve. This also shows a trail of where people and teams have been including the progress in how far they’ve come.

How can you measure the absence of a security issue?

It’s easy to over engineer KPIs and measurements. An important metric that we want to be able to deliver is the absence of a security issue? In order to avoid the development rework, we need to understand what was done to avoid the rework. Measuring security habits is a good indication of how issues are being caught. For example, are teams themselves self identifying where security threats exist, for example with good threat modeling practices.

A good way to think about the effect of shift left is to start right. We ultimately want our production environment to be more secure with fewer security risks and vulnerabilities. If we can implement processes and habits on the left, we’ll see the measurements and numbers on the right drop. This will show the impact and success of the activities that have been introduced on the left. So look at your security metrics, implement shift left (developer-first) security, and look at your metrics again.Find out where we'll be next by visiting https://snyk.io/events/. For invitations to upcoming interactive roundtables, reach out to your Snyk Representative for more information!