Finding Time For Security When Scaling w/ Liran Tal of Snyk

**SPEAKER_2** (0:03)
We have to start giving our developers the ability to find and fix security vulnerabilities before their code is merged. We have to talk about what a good security culture looks like and how we track and prioritize our efforts.
This week on Dev Interrupted, I brought in Liran Tal, a security expert from snyk.io to talk about how our community can begin evolving traditional security workflows into a more modern way of working.

**SPEAKER_3** (0:34)
This episode is sponsored by LinearB. Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time Git activity.
Sign up free at linearb.io.

**SPEAKER_2** (0:49)
What's up, Liran? Thanks so much for joining us today.

**Liran Tal** (0:53)
All good. Thank you for inviting me. I'm excited to talk about open source security.

**SPEAKER_2** (0:57)
Yes, let's just jump right into it. We want to talk about open source security. We want to talk about Dev First Security.
And I want to start by asking you, what is Dev First Security? What does it mean? And how is it different maybe than what a lot of teams are doing today?

**Liran Tal** (1:20)
Right, so I think probably to understand what Dev First Security is, we kind of need to understand what is not Dev First Security.
And so that means what were traditional security practices of how security teams were handled in an organization, right? What they were kind of like far off from what would be a developer friendly or even like developer enabling. So traditional security practices are kind of like finding vulnerabilities usually kind of like late in the game while you're already developing the application, maybe even after you deployed somewhere and so on.
But going back really four or five years, I think what we've seen as like a pioneering approach in this developer first security kind of notion and context was security is not only for finding security issues, but also for actually promoting kind of an actionable fix, right? Making sure that we enable developers to fix the problem, not just find them. So Snyk did that like four or five years ago using pull requests, which is, I think folks are seeing today, this kind of like happening around GitHub, but really this was kind of like a revolutionary way of approaching the first security.
And probably, I think with Dev First Security, I can give several examples of what it actually implies, right? So for example, when security teams would show you what a security vulnerability, it will probably not be provided with a lot of context. And so what Dev First means is, some examples of that is showing you actual like the dependency path. If we're talking about third party dependencies, so where exactly is it coming from? Or if you need to upgrade from package X version one to package X version two to fix the vulnerability, that's a major breaking change. So a Dev First Security kind of like solution or platform or approach in general will tell you, be very hesitant or careful when you make an upgrade because this could probably break your APIs or something else. And I think this is kind of like the mantra around developer first fully. How do you build something that is in workflows for developers and what they are used to, their pains, and basically enabling them to just fix something, do something about it and move on.

**SPEAKER_2** (3:36)
That's really cool. I was probably developing like eight to 10 years ago is when I was a hardcore programmer. And what I was more so used to is like, okay, you write a bunch of code, you might even deploy it. And then there's like a pen testing that happens at a certain time or different automated security suites that run.
And then you might get a report back and then you might prioritize the more severe vulnerabilities. And then it makes it back into your product queue and then you fix stuff unless it's like super urgent.
And I think kind of what you're saying is now while I'm developing, I can actually open a PR as a developer and I'm gonna get some type of feedback right then while I'm coding. Is that fair to say?

**Liran Tal** (4:35)
Yeah, it's exactly like that. I mean, that what she describes is very traditional model of security working.
Kind of after the fact, kind of like, not very intertwined with developers.
And that is basically one of the reasons for why security kind of slows down into organizations because like you're saying, you need to prioritize it. I know we could have been in that role before. I needed, for my development team, I was a developer before, we needed to prioritize security fixes. But of course, you now are kind of fighting for time and priority versus other features and bugs and technical debt and so many things. So how do you get that on the way? And I think the whole approach is kind of different with developer first and the way that you approach it is that you enable the developers, which if you think about it, traditional security as well, has been all about finding the issues and then bringing them to the developers. It was never like security engineers, they never actually like upgrade your dependencies or like fix your security issues, unless it was something beyond the application, like an infrastructure or network appliance or so on. And so if you think about it, the key to solve the security issues are the developers. So those are the people you want to enable in the most best developer experience possible, so that they would actually be able to do it, have fun with it or just finish it and move on to something else.