The Evolution of Snyk, The Developer Security Company, With Guy Podjarny

“Danny Allan: Where did the name Snyk come from?

Guy Podjarny: So, Snyk’s very first origin was this notion of, “You know, hey, we’re going to instrument applications, we’ll sneak data out and – but we’ll spell it with Y like the cool kids do.” And so, S-n-y-k and I googled it to see if there’s like, Google contention if there’s anything else called Snyk and the first or second option was urban dictionary that said, Snyk is short for, “So now you know.” That clinched it, you know? It’s like, “Okay, fine. So now perfect.”

[INTRODUCTION]

[0:00:31.0] ANNOUNCER: You are listening to The Secure Developer, where we speak to industry leaders and experts about the past, present, and future of DevSecOps and AI security. We aim to help you bring developers and security together, to build secure applications while moving fast and having fun.

This podcast is sponsored by Snyk. Snyk’s developer security platform helps developers build secure applications without slowing down. Snyk makes it easy to find and fix vulnerabilities in code, open-source dependencies, containers, and infrastructure code, all while providing actionable security insights and administration capabilities. To learn more, visit snyk.io/tsd.

[INTERVIEW]

[0:01:10.2] Danny Allan: Hello everyone and welcome back to the next episode of The Secure Developer. I am super excited to be with you here today, especially because of the guests that we have joining us today, and that is the founder of Snyk, Guy Podjarny. Guy is here with us. Guy, how are you?

[0:01:28.1] Guy Podjarny: I am, I’m good. Thanks, Danny, it’s fun and a little bit odd to be the guest on the podcast. I’ve done like an – I guess like close to these a little bit with Simon interviewing me I think, end of the year but this was a bit different.

[0:01:41.7] Danny Allan: Yeah, it’s – I’ve been an audio listener of your podcast now a hundred times and so, it’s odd for me being on the other side and interviewing you but, of course, we wanted to do an official podcast where we cover the history of Snyk and market and the evolution of all of that and so I thought, what better way to go through this transition than to have you on and talk about the inception of Snyk?

So, if we bring it right back to the very beginning, I guess, if I can start with the question, where did the idea of Snyk come from and when did it actually originate?

[0:02:14.9] Guy Podjarny: To an extent, the idea of Snyk came to me in the shower but that’s a bit of a misnomer. In practice, I think Snyk is very much the culmination of my journeys ahead of that. So, as I’ve since spent a decade or so in the world of AppSec, through companies where some of which were together, Danny, Sanctum and then Watchfire and IBM.

I saw the importance of shift left, which were saying, all the way back in 2002 and getting security embedded earlier in the journey and also seeing the failure of that or like, how much maybe the importance of it kept growing but the adoption of that was nowhere near that same pace. From there, I left security and I found the more performance company in the not-yet-existent DevOps space on it that maybe both sides is faster.

And I was a part of the Velocity Conference like I’m part of the committee there where like a lot of the initial DevOps talks came about and I got a first-row seat into rise of DevOps and like a new practice that says, “Okay, the software development will work differently, from here on and here are a bunch of tools that are disrupting the traditional, enterprise tools and the developers are racing them.”

You know, New Relic and its subsequent Datadog, Heroku, and a bunch of it’s strength and the Cloud. So, Snyk is very much after concluding Blaze, that startup got acquired by Akamai and I was the CTO at Akamai for a bunch of years. So, after the six-ish years in the world of DevOps and Cloud, I was ready to start another thing and Snyk was really around bringing those two together.

So, it’s like, can I bring what I’ve learned in the world of DevOps to security to help break the barrier, I guess into getting it embraced? I will say that we can talk a little bit about the zigs and zags but Snyk’s original idea, the very – the idea that came to me in the shower that I started it and the name of the company is kind of, was initially founded on was actually more of a runtime instrumentation idea.

The idea was to be developer, like build a developer tooling company that tackles security and all that remains or was there at the beginning, but the idea was, “Hey, we will instrument applications like New Relic or like Datadog, and we will sneak data out and we will see what happens inside in a low effort way for developers, and then we’ll protect them automatically." The open-source security product was a way to get initial market reach, and yeah, has evolved, evolved from there.

[0:04:50.7] Danny Allan: Well, that’s fantastic, I want to come back to the name because I know that there’s a meaning behind the name but on the point of bringing those two things together, the two things being developer security and runtime, were you imagining that Snyk would focus solely on modern applications and not the legacy applications? When I say legacy applications, I’m thinking now, you can go all the way back to Cobalt but C and C++. Were you really envisioning that this would be around modernising modern applications only?

[0:05:19.4] Guy Podjarny: I think I had the tendency to think about the Cloud lot as a core concept and so, first of all, like I wasn’t smart enough to really think that far out. I thought developer security has to happen and I was more focused on the future, more focused on, “This is the way applications will be built and we should be the security solution for that future way in which applications need to be built.”

So yes, I think I was initially focused on modern applications, modern development practices, even early on, said that in terms of go-to-market, we would follow DevOps and so, where DevOps was adopted, there’s more likelihood that Snyk will be adopted. So, I guess, the answer is yes. I think a lot of the practices on – in terms of the tech stack and things like that, a lot of what was good about DevOps has actually slightly inched backwards.

And the problem is I don't know if there is a CICD systems for Cobalt but definitely, slightly more middle-of-the-road or like, of the-era applications. There’s definitely a lot more C, C++ applications that could get continuously deployed that are deployed on microservices. So maybe there is a little bit. A little bit of that could have still applied in the original thesis.

I think once we’ve expanded into embracing the developer methodology and going out of the runtime angle, that it really became anybody that uses open-source that goes a fair bit back. Again, not entirely sure if it’s global but there was more the SaaS journey, which we can get to.

[0:06:51.7] Danny Allan: Yeah, well, let’s touch on the name then before we get into open-source. So, Snyk, I think a lot of our listeners may know what it stands for but let’s hear it from the founder himself. Where did the name Snyk come from?

[0:07:05.5] Guy Podjarny: So, Snyk’s very first origin was this notion of, “We’re going to instrument applications, we’ll sneak data out, but we’ll spell it with Y like the cool kids do.” S-N-Y-K. I googled it to see if there’s Google contention or if there’s anything else called Snyk and the first or second option was Urban Dictionary that said Snyk is short for, “So now you know.”

That clinched it, you know? It’s like, “Okay, fine. So now perfect.” And that was it. Interestingly, later on, I heard about other analogies like Snyked is the name that – the lock snyks when the bolt goes into place, so that was interesting and snyk is the wolverine, like the sound, the the – when the blades come out. So, there are all those but like, so now you know was really the –

And in fact, we had magic – at the beginning of Snyk, we created these magic wands, these like tin foil papers thing that pop up into a magic wand that said Snyk on the outside and when you open them, it said “so now you know” on them. So, we very much leaned into that.

[0:08:05.1] Danny Allan: Wow, I love the name, although, I have to say, sometimes people don’t know how to pronounce it because it is a challenging name but –

[0:08:13.9] Guy Podjarny: For compile, actually it was our second top support question was, “How do you pronounce the company name?” And we had, this is a fun story, at the beginning of Snyk, I think we announced, we launched Snyk at Velocity Amsterdam in the end of October of 2015, and there was a great guy from Austria there, who was there and loved the idea and he actually put together, he is a guy that works at Dynatrace.

He put together this video that promoted, talked about Snyk and we were like, super early. We’re really grateful for him, getting it out there on some social sharing thing and throughout the video, he says, “snook” and we learned over the years that the Austrian, like, the German accent lends itself, that’s pronouncing it as “Snook.” And he just goes through and we’re just like, debating.

It’s like, do we – do we just enjoy the reach or do we correct it? And we just let it, let it run, and yeah. The pronunciation was harder than I anticipated. Although, no publicity is bad publicity. So, it’s part of the conversation, it was probably good in the long run.

[0:09:13.5] Danny Allan: Well, it gets people talking about you. I know my parents when they first heard about it, they called it “snick” but we’ve leaned into it with sneakers and sneak peek of what’s coming next, so a brilliant name.

So, you started on the open-source side and that has to be a market evolution. If I go back 20 years, most software, when you’re writing software, it was top to bottom or at least 90% of the software you wrote. I presume and I guess, I’m looking for confirmation that part of the thought process and moving to – or starting with open source is because a lot of the market has shifted towards open-source components over the years. Is that a correct assumption?

[0:09:50.8] Guy Podjarny: Yeah, I mean, I think there’s like a chain of decisions here. So, the first one is that we modelled Snyk to be a developer tooling company that tackles security and so, our role models when we thought about the market, we thought about, how do you reach developers? We’re very much, the New Relics of the world, again, Roku and those were very product-led growth.

That termed and exists but in practice, they were bottom-up players and – and so, that was like a key requirement, right? The thesis, which I still stand behind was that if you want to get developers to embrace security, you have to make it easy and a part of that ease is to give them something that they can use and fall in love with. So, that was one part of it and so, it needed to be – that was also a part of the choice of securing open-source libraries is that a developer could do with when you think about, for instance, the barrier to introducing a runtime agent that’s like a higher friction piece and we understood that.

And so, we said, we’re going to start with something lighter. Open source security at the time was an interesting domain because it wasn’t well covered. Like, the only player really around was Black Duck. Nobody liked it, nobody likes it today, they’re but the – but nobody – there weren’t any facts. There were just no real alternatives and so I felt like a space we could do and indeed, we could take an approach that was very, okay, if you’re using it once again, the modern plans, then you’re installing dependencies through NPN, through these libraries, can we help you make it easy for you to know if any of them is vulnerable?

Really, the driver was, “Can we find something that is truly valuable, that is a bit of a window in the market to get initial adoption, and that enables this bottom-up emotion?” And we underestimated. I think I’ve learned to appreciate now that like, any problem worth doing, it’s probably bigger and more complex than you think.

And so, I think we knew that it’s a valuable thing to do. It was easy to pitch why you should do it. We knew practically nobody was doing it and we knew the world of NPN especially, which is where we started, was suffering from like dependency explosion and having, like people were afraid of dependencies and they still are, like it is a hard to wrangle domain but we didn’t appreciate how complicated it is.

On the initial deck, it says, three months, we’re going to do open-source security from NPN and then, after three months, we’ll do it for Java and then after six months, we’ll get to our real problem in one time and yeah, three years later, I think we launched our second product that it wasn’t in runtime. So, it was definitely more complicated but I think, in hindsight, that gap in the market was well-timed. It was an important problem that was growing in importance and was underserved in terms of solutions, especially for the modern developer.

[0:12:29.1] Danny Allan: And when you say developer-first Guy Po, do you think – do you immediately jump to the IDE or do you – when you make that statement, was it more just, I want to make – reduce the cognitive load in development however that might be. I guess, I’m wondering if that is a tool-specific statement or a cultural approach statement.

[0:12:49.9] Guy Podjarny: Yeah, it definitely is bigger than the tool. So, the lens to look through is what if you only cared about the developers adopting your tool? If you really didn’t care about anything else, what would you do? And that’s the tunnel vision that we adopted. It’s like, we want developers to embrace this product, we think the tools today are not fit for purpose for developers. They’re built for auditors, they’re not built for developers and so, what is built for developers? Which tools do developers love and which companies do developers love?

We set out to really mimic and build all these role models that were the dev tooling companies that we most love and that manifests throughout the company, like in the colour scheme of the website and the choice of the logo that is behind you and is hiding here behind me, in the go-to-market motion, in the choice of the product sensibilities. We built a command lineage with the original product was only at command and interface and we put a lot of effort into the developer experience of that CLI but also, just like the language, everything around it, and also the people that we hired.

Like the people that I hired in the beginning are very much focused on people that have UX focus, that have, developer experience, and I think one of the things that really worked out well for us, which was semi-intentional, was we really combined some talent and competency in security that came mostly from Israel and Tel Aviv office with competencies around communities and the developer love and developer reach.

That came a lot more from the UK centre and our RND, our development was really in both of those domains. So yeah, I think a lot there. Probably like the most memorable example of that was the colour scheme and so, we wanted a warm – everything, all the security companies were like blue corporate, or maybe, maybe black and red, and we wanted something that’s like, developer-friendly and all that.

We wanted warm colour pallets and a lot of conversations about that and then – but when they tell you, you have a critical vulnerability, I do want to scare you just a little bit. Like, you do need to be, like, mindful, that this is important. So, we had all these deep conversations about it, we landed on this magenta colour for a high-severity issue. Even purple, for those who don’t know it, it was very much like at the time was the rise of the purple team, just like the blue team and the red team, the attackers and the defenders working together, hence the the purple. So, a lot, a lot of thought as to like, how does it represent? Wnd we went through. Like, we didn’t go to security conferences for two years.

Probably, we went only to dev conferences, we – so much so that I think about a year, something like a year into the company, I was having some advisory comment with some go to market, with some of demand gen marketing person to have a good, sort of, we’re a part of that program and he asked me, “Say, if a security person gets to the website, how do they register?” I was like, “That’s a good question.”

[0:15:38.2] Danny Allan: Nice.

[0:15:39.4] Guy Podjarny: If they have a GitHub account, they can log in with GitHub and then we added a Google account, which pretty quickly became like half our registrations. So, yeah, we are very tunnel-visioned on what would make developers get this.

[0:15:51.0] Danny Allan: Well, I love that story of the blend and I think that’s represented now, you talk about brand and marketing. Even in the dog, I think of Dobermans, which is the symbol, you mentioned is behind us here. Dobermans are scary dogs, but when you look at the Doberman patch, the dog for Snyk, he’s a bit of a blend. He’s not totally scary but he’s also not totally friendly either.

[0:16:12.4] Guy Podjarny: Yup. Yeah, that was another obsession. If you want to do this as an exercise at home, you can flip the eyes, like, the eyes are semi-circle, it really got – really try to walk the line. If you flip the eyes and you have that semi-circle be the other way around, it gets too friendly. It really was like, just at the edge of like at some point, you either want to go and pet the dog or you want to keep your distance and yeah, there was a lot of emphasis on that. So yeah, we definitely swept the details on that, I think it paid dividends, as conveying it that we’re not just another security company.

[0:16:42.4] Danny Allan: So, that’s technology and marketing and brand, and I totally see that. What about culture, what was important to you as you were starting the company on culture? Talk to me about transparency and how you believed the company should evolve from the inception in going towards the developer market.

[0:17:00.0] Guy Podjarny: Yeah, I think a lot of it really comes down to mimicking the sort of, GitHub, New Relic, others of the world at the time and so invested a ton in community. We started this podcast as The Secure Developer to share practices on the belief that in the world of DevOps, a lot of the breakthroughs happen because people were willing to talk about failure.

To get up on stage and talk about how this didn’t work, that didn’t work, and they had a sharing platform, there lies in security, that wasn’t really much of a place for defenders to come and talk about, what they’ve done and what their learnings were and all that and so, that was a buildup. Everything was very transparent. In fact, it’s interesting that sometimes the philosophy proceeded or you know what’s stronger than the product sensibility.

So, like, our vulnerability database at the beginning was on a GitHub repository, just out of the premise of we’re just transparent here, it’s in GitHub. It took us a while to realise that that’s not at all useful to users, it’s only useful to competitors. So, we stopped doing that but even till today, the advisories and the capabilities are public and I think probably the single biggest example of that is the fact that the product is free for open-source.

And I think today, that maybe feels like a given to people but it wasn’t at all at the time and it was definitely not in security. The fact that Snyk was, from the beginning, free for open-source maintainers, for open-source projects to use was very, very big. It was very important to us philosophically. It was so important that when we created a commercial team, like, the company was so oriented at serving the developer and serving the community that we had to create a carved-out team called Enterprise, that was the first team, Danny is on it.

It says, some people also care about who pays, and of course, over time, as the company grew and it became balanced that we have developer experience and the application experience team evolved over the years but so if an AppSec experience and the developer experience but yeah, it was very, very, very focused.

I do think, like, when you found, this is a bit more of an entrepreneurship tip but I think when you’re a founder, you have to be careful from the word, “and.” when you want to do this and this, you have to pause. There are cases in which you have to do this and this but I think you really have to be amazing at something to break through and if you’re just okay at everything, you just – nobody cares.

And so, for us, the passion, that focused on developers and everything around that community works. We even went as far at some point as acquiring a conference. We acquired DevSecCon at the time which is like, can you acquire a conference? It turns out, you can, sort of, and who has done a great job. our friends why they did a great job building up that event as a centre for sharing security experiences and such and we help to amplify it.

So, yeah, very, very passionate on community. I think everything else, the transparency, the colour scheme and all that, they are all side effects of focusing on what would make a developer discover you, love you, want to use your product, and successful in using your product.

[0:19:49.9] Danny Allan: So, if I play that back to you and I completely agree with what you’ve said, what I’m hearing is, it was really focused on developer-first as the core premise. Secondarily, that we would have this blend of helping the industry, red and blue team, and giving technologies that aided them, and lastly, very much a culture of transparency. I’ve always believed that great companies, long-term generational companies are built on a solid foundation. They may expand beyond that and clearly, Snyk has expanded beyond that, but is that a fair summation of what the foundations of Snyk are on which the organization was built?

[0:20:29.5] Guy Podjarny: I think they are and I think they’re also like, core to how we built the product and the ethos and sort of, everything around the company culture. I do think that it’s – the addition of the business was an important addition. It’s highlighted, probably, the biggest push and pull that happens within the company even till today when I think of the market between depth and breadth.

So maybe, and I’m slightly going a bit to the next chapter but I think it’s – what you’ve described was correct but this next one really probably cemented, how we have to operate today and how we are today, which is the addition of the needs of security and so, we have like, Snyk’s – everybody describes like, everybody remembers us as the overnight success, you know?

That was not the case with Snyk. we were – we’re actually pretty good because of the focus on a few good decisions. We’re pretty good at developer adoption all along and we had the best developer adoption that any security tool has seen, which was really quite mediocre for developer tools at large, and at the same time, we had no revenue. We had like for two years in, we had probably spent maybe four or five million dollars and we had about a hundred thousand in annual recurring revenue. If you’re unfamiliar with startups, that is not good. That is not and it’s not intentional.

[0:21:46.7] Danny Allan: Good to have funding.

[0:21:48.0] Guy Podjarny: Yeah, yeah, exactly, and we had a few near-death experiences on the funding route and I think the key unlock that has happened through the second year and then eventually manifested about two years in was really the understanding that developers like depth and security needs breadth. It’s like, if I’m a developer and I’ve said this since I think many times, although curiously, I might not have had a chance to say it on this podcast.

Which is if I’m a PHB developer, I couldn’t care less if you support JavaScript or not. It’s like, and it’s not because I’m narrow-minded. It’s just like, it doesn’t affect my day-to-day. Similarly, if I develop in AWS, I don’t care if you support Google Cloud or Azure. I care about my stack and it better be amazing. That’s the bar I’m used to, that’s the way in my – I love my purpose-built tools for my ecosystem.

And so, you really have to be deep to win over developers but security is already a massively fragmented space and it already is very, very hard to keep up with all the different threats and it’s just impractical for a security team to have five different directors of engineering and their company uses five different tools for say, open-source governance. It’s just – it’s not a lack of willingness to adopt agility and things like that.

It’s just not practical for them to do so and so, they need breadth. They need you to support 80, 90%, at least of some of the applications in their stack and cover a threat. Otherwise, it just might not be useable for them. They might love the tool but it’s not practical for them to use it and so, this combination of depth and breadth is effectively impossible. Like, you can’t have something that is fully deep and fully broad but it is the balance that we have to strike.

We could talk a little bit about SAST and how, that was broken for it and how it works there but I think that realisation was super-super important and I think, probably by chance, partly, by intention, open-source security was a domain in which it was reasonable to manage, to provide both depth in the ecosystems that was supported and breadth, and therefore, cross that sort of – it’s not quite the chasm, you know?

But cross that line to be able to provide a solution that both developers love and that security, loves, and is able to use to actually secure their organization and I think that became another pillar of Snyk. it became a pillar of the culture. It was hard to embed because we had security competency passion but we did not have enough security person empathy passion in the company. Well that’s, six years ago, and today, it’s equal, if not, like, even more a security practitioner empathy in the company but we have to do that, like for us to become the longer term. So, I would say it’s three years in, the company was had both of it and that became the core DNA for which we were –

[0:24:45.2] Danny Allan: Yeah, well, you clearly see that breadth and depth now. I mean, a CEO or a leader of an AppSec program is not interested in the CLI command line capability. They’re interested in the dashboards and the measurement and metrics over time but it feels like you’ve struck the right balance and certainly in the evolution in where we are today. I’m interested to move forward in the both market evolution and technology evolution. Maybe we’ll start with market evolution. Over the last eight years, because it’s really been eight years to date, how has the market evolved or has it evolved, maybe is a better question.

[0:25:21.9] Guy Podjarny: I think it evolved a lot. I think – first of all, it evolved in acceptance of developer security as the solution that is needed. It transitioned, feels like somewhere around four years ago or so was really a bit of a tipping point to go from, “Should I do this?” To “How do I do this?” I think it goes hand in hand with the acceptance and a little bit of mileage with DevOps.

I think a lot of organisations might have already chosen DevOps and Cloud but they have not experienced it yet. So, they haven’t really internalised how the speed of software development that those technologies bring make your existing AppSec program just pointless. Like if you are not embedding it into development you’re just not going to keep up.

So, enough people had to feel the pain but at the beginning of Snyk, we had a lot of conversations, I had quite a few conversations in which either people were saying, “Yeah, that’s great but we’re not ready for it,” or they were saying, “We don’t trust developers, you know?” Like, “Yeah, yeah, that’s all nice,” but as the security team was saying, “They’re never going to do the right thing on it.”

And I think around that, roughly that point in time in all the percentage, clearly there were always the brilliant and all those amazing security leaders to help us also build up the company that we’re at the forefront, many of whom I had the chance to interview in this podcast, but also like some majority tip when people started saying, “Okay, I know I need to do this but it is hard. How do I change the culture?”

“How do I get people to embed it? Help me out here, help me figure it out.” And so I think that’s a big change. Applying it further, I think there was an understanding of a slightly more meta change, which is software is heading the world and that an increased transition but frankly, it goes all the way back [inaudible 0:27:02.2] there is no back then from that network security or infrastructure security into application security, and how more and more decisions are being made at the application security aside our important and therefore, how you should just put more weight into application security as a whole. So, that’s I think – I think that specifically is probably something that is really only landed in the last couple of years.

[0:27:25.4] Danny Allan: It definitely is the case that customers are asking more for guidance in this, which is surprising to me. It’s been 25 years now that we’ve been – and more since we’ve been doing application security but it’s surprising to me how many organisations don’t have an opinionated perspective of how they should move forward and how it can help.

Tell me how the technology evolved. So, clearly, you started in the open source side of this, and over the years, well, over the last five years, I think there have been nine different acquisitions but talk to me about how the evolution of both building and buying technology drove Snyk forward to where it is today?

[0:28:02.7] Guy Podjarny: First of all, we came to the understanding that you don’t really want if you have like a bunch of files in your repository and you’re a developer, you’re thinking about all of them as representing your application. Saving from a dev lens, you don’t want like five different tools securing this file in your repo and this file in your repo and this file in your repo, and so that realisation drove us to start building new products maybe a little bit earlier into the goal startup conviction.

And so, we build a container security product and we’ve been saying, “We have your docker file in your repo and it might be vulnerable. It’s also dependencies, can we help you with that? Where we build an infrastructure as code product.” And both of those did quite well. Infrastructures code interestingly has not deepened into application developers quite as much as I would have thought. But containers are very embedded into it and if infrastructures code was a good segue later on into Cloud, which we’ll get to. So, I think that was like the first phase maybe of understanding that and went very well like it was well received. It was really us following the customers, the customer is saying, “Can you also do this for me? Can you also do this in a dev-first security fashion?” And we built it just as a startup lens on it.

We always built it in a very iterative – one of our principles at Snyk is ship it, let’s iterate, let’s not presume we know better than the world, let’s ship a thing and then evolve it and so we ship add-ons that have a little bit of functionality and was useful and expanding the mechanics until they could be a product that could stand on its own two feet. The one area where we couldn’t do that was SAST.

So, static analysis, I guess for the listeners, Danny and I both had the dubious experience of leading static analysis for like like in IBM days and I guess when I started Snyk, I swore off not there. So, Snyk will not have a static product. It is to do so we would have to invent new math. At some point, we realized, “Okay, look, we have to have static analysis product.”

Like that has to be part of that same thesis is you also have your source code promising that and they interplay with the others and so, we have to have a static analysis product and we looked at all the companies in the market and basically none of them looked good to us. We even set out starting to build a static analysis product, which was an unpleasant experience.

And while doing that and understanding our needs, we came across DeepCode, which was a company that was not doing security but they were taking this very novel approach to static analysis that basically treated code as data. So, it’s encoded data, I am massively oversimplifying here, and then use AI to understand the massive volumes of code in the world and understand patterns like an expert developer would.

And by basically encoding all of that world’s code into data and learning on it and by encoding your code as data then intersecting that with that knowledge we have from the world, it is able to do maybe three important things. one is scan code very, very quickly, which was mandatory, is mandatory for developer experience, and a lot of stack masters tools fall because it could basically benefit from all the the data analysis advancements of the world.

Two is, it could do that in a way that is increasingly accurate because it could learn like we are seeing the benefits of AI today. So, this is machine learning days and so, it’s good but also, more importantly, it keeps getting better versus rules that have to always be manually tuned to just fix some data. It just almost guarantees to always get better and then the third, which was critical for our depth versus breath element is that the way it works is it normalised the code, the way it works today is it normalises the code into data as it transfers it into data and so it works. There is some platform-specific content for everyone and every platform but for the most part, far more so than our open-source work, which was just I guess at a level of complexity that was reasonable to do it on language, a language could be done at both. To complete that story, you know we acquired DeepCode.

I think it was a great partnership, I think they brought amazing depth in that program analysis, something we brought in great product shops and really great security depth on it and together, we built Snyk Code, which is like a phenomenal success from a Snyk perspective and I think a real change an acre in the industry and then I guess the last one that I would –

The last phase maybe that I would mention is the whole world of Cloud and so I think the next step of appreciation and I think it’s still forming is this notion of context and the fact that you’re never going to fix all the bugs and you have a lot of code and now we almost like caused that problem because now, we can very effectively find all of these bugs, all of the security bugs but we’re never going to fix all of them.

And so, over the last few years is the rallying cry was prioritization. It’s like, “Can you help me? Help me figure out which of these I should care about more.” Which makes sense and I think for that you need context. So, some of the context come from analysis, let me better analyse the code and libraries and how they interact but a lot of it comes from context, like what has been deployed to the Cloud.

What is accessible to the Internet? Which of these, an attacker truly hack versus this thing that is like behind the firewall in my developer environment and it needs to be some compromised internal employee that is highly permissioned to even run the attack on this vulnerability? And so, I think the next year it really comes from this notion of Cloud and we’ve had a bunch of experiments over here.

You know, we acquired Fugue, which we learned a ton from, didn’t quite pan out precisely as we could expect. That also happened right in the midst of a financial market correction, that helped us refocus a lot more on AppSec first, but I think that is the next evolution into this world of application security poster management and SBM. I’m sure we’ll talk about AI, which is probably the next evolution on it.

But I think just getting today is this notion of like looking at things holistically, as a context, looking at all the codes together, looking at all of its journey, looking at all of its context of where it’s been deployed that helps it change so that you can look at the, million things that you have to fix, that you could fix, and find a hundred of them that you really have to fix to really make a big dent in your security culture. So, that is a bit about that but that’s the journey.

[0:33:58.1] Danny Allan: So, you’ve brought it back to the part where Snyk started, which is you’re sneaking data out of the runtime in order to prioritise what it is that needs to be –

[0:34:07.2] Guy Podjarny: That was very – that’s actually very fulfilling, like with the Helios acquisition now, adding a runtime agent to Snyk is a very closed-loop moment.

[0:34:14.3] Danny Allan: Yeah. Well, it’s fantastic to see it come full circle on that way and I agree that that runtime is what drives customers to understand what needs to be fixed first. I actually have a question on that, I just posted about this on LinkedIn. One of the challenges that I see around CNAPP and using runtime to drive fixes is it only covers those areas that you can collect that runtime environment.

Do you expect that that is just likely always be the case or that the world is going to shift towards Cloud-centric environments where you do get that runtime? Do you think it’s going to continue to be high rate? I guess, I’m curious how you see the evolution of this moving forward.

[0:34:52.9] Guy Podjarny: I think static analysis would always be easier than runtime analysis or dynamic analysis, by the sheer version that it doesn’t need a running application. Like, no matter how fast or fancy you are, you – it is still faster to contemplate all the possible ways in which a program might behave by looking at it statically than it is to actually get the application to perform all these random settings.

And so for instance, runtime behaviour, yes there probably will be and I think we’re already seeing it with open telemetry, with BBBF, like increasing technologies that make it easier to say, “Let me just look at the application as its running and capture everything that it does.” And I think that is mightily valuable. However, security is all about the unexpected behaviours. It is not about what it does when it is behaving as it should.

It is about, “What happens if I put a single quote over here, how does the application behave then?” And so I think in terms of modelling the application, I do think runtime will get easier and easier with BET stack analysis would still be easier but in practice, we really want to combine the the whole picture but in terms of figuring out what is possible, I think static analysis would always have better coverage.

And to a degree, runtime assessment would always have slightly better accuracy because it is seeing the thing happen and so I do believe that the eventual holistic perfect solution is the one that combines everything together but that if you really have to choose what would tell you about all the problems, then static analysis would be your go-to with runtime and those observations becoming ways to sharpen the picture and to indeed prioritise or just better understand an issue.

[0:36:38.9] Danny Allan: Yeah, I’m glad you brought that up because I actually agree with you. I think the foundation is the open source and static analysis, where the runtime and the Cloud signals and things are signals. They augmented to help you get better around the core because you are always going to have open source, you’re always going to have code. You may or may not have containers in IAC and runtime sensors that can feed you that data but it definitely makes you smarter.

[0:37:06.8] Guy Podjarny: Yeah, and it’s a bit into like misconfigurations in XDR, right? You can look at all these configurations and some of them are not that important, some are more but your XDR and runtime detection, I think you need to be not entirely sane to say, “I don’t need to scan for misconfigurations because my XDR setup is good enough that it will cache the attackers when they try to do it.” Like, I think you just need both. You need this stack analysis and – but the stack analysis is the one that gives you both.

[0:37:32.6] Danny Allan: Well, it’s about the right to win and then the reason I think about this enough a lot is because you people on the right who are doing Cloud security posture management over on the runtime and operation side versus dev-first application security posture management, which we are very focused on, which one do I think has more value and I think you and I are biased on this.

But I think the dev-first ASPM is far better and more important and more strategic in the long run than the Cloud security posture management simply because you can trace it back to where it all started and you can do that every time as opposed to just the Cloud scenarios or the container scenarios in a modern development environments.

[0:38:09.8] Guy Podjarny: One thing we’ve somehow managed to get to this phase and not talk about and it is my mission is remediation and I think actually a core learning maybe, you know as like a key sentence that we would say again and again in the beginning and we’re still saying today is a developer’s job isn’t to find issues, it’s to fix issues and if I – if all I do is I tell you about the problems and I don’t help you fix them, like at some point, you’re not going to like me very much. And you would rather not hear me, which is I experience a lot of security developers feel.

Snyk from the very beginning, from the crappy command line interface that we shift back in that October 31st, I think the 30th of 2015, it had a fix option. It ran Snyk Wizard and you would run through it and you would upgrade it to make the problems go away and the Fix VRs and GitHub and I think Fix remains a core-core-core premise route.

You know now, we’re, we have this exciting AI fixes and to ask them in Snyk code to actually fix your code and I think this notion of remediation is super-super-super important. It is important for developer production but also fundamentally it’s also true for security people. You don’t really get paid to know about the issues. It’s easy because that’s the way that your job manifests, it’s like make you aware of the risk.

But in practice, the security organisation’s purpose is to make the organisation more secure and then, of course, fixing issues wherever we can. So, making fixing easy is really the true end goal and it’s hard for me to think of anything that is not patchy that is long-term viable when it comes to fixing than actually going to the root of where the problem was and fixing that and so, I really think that you can debate a little bit interim solutions.

Am I willing to sacrifice coverage for just finding a few issues that I think are clearly issues I should fix? But if you want the fix to actually be automated, if you want something that actually has the chance of giving you long-term protection, you have to go to the core. You can’t take those shortcuts.

[0:40:11.0] Danny Allan: Yeah, focus on the fixes. It has certainly been a huge foundational component of Snyk since the very beginning. I have two questions for you on that. A, do you drive – have you been in a self-driving car and B, do you think we’ll ever get to self-fixing code? In other words, so you think we’ll get true autonomous developer security, where they never even look at this. It just fixes it as part of the process.

[0:40:33.5] Guy Podjarny: Yeah. I mean, I’m certain we will. I am certain we will. Clearly we aim to be a part of that but it’s hard to see why you wouldn’t and so just go through, trace the logic here a little bit, will AI improve to understand vulnerabilities and fix vulnerabilities automatically? Yes, I mean, I think that’s an absolute yes. Once that is improved, why wouldn’t you go through all of your code and fix all the vulnerabilities that you have there? Why wouldn’t you make that type of change automatic versus be something that is attended? And I think it really is just about when do we build enough confidence to have this move from attendance to autonomous but I think it’s a when not if and as we talked about, with the depth versus breadth, it probably wouldn’t come uniformly to every practice, every stack.

Ironically, this might actually benefit the stacks that change a little bit more slowly but I think it is an absolute estimation that we have to pursue. Also that it’s the only way to keep ourselves secure because AI will just make software development even faster and if you are going to be relying on AI to generate code, you have to rely on AI to generate fixes for vulnerabilities – that is – that are creative.

[0:41:52.0] Danny Allan: Yeah, I look back at Log4j and wouldn’t have been great to be able to say, “Go fix all the, the Log4j issues that exist out there.” And it just autonomously goes and finds them all and corrects, and updates, and patches. I do think we will get there. It is amazing that we’ve got this far through the podcast and we haven’t talked about AI but I do think that AI is going to radically shift the industry, continue to shift the industry is maybe a better way of putting it because we’ve been using AI within Snyk, within the static analysis and platform itself for the last five years.

[0:42:26.0] Guy Podjarny: Yeah, I think AI, you know you asked me about the market evolution and I think AI and AI trust is the natural continuation of it that is starting to happen and so, I think the reality is that AI is becoming part of software development. It will be more and more so, like AI will handle more implementation overtime and already today in many organisations, Copilot or the likes, you know write the majority of the code.

That code is definitely not perfect. Generally, it shows that it tends to be less secure than developer code but I think even if you disagree with that comment, like it is frequently able to have vulnerabilities in it. So, you have to have something, like if you’re relying on automation, you have to rely on automated assessment on it and so a lot of the next chapter when it talks to application security it’s not about whether you can trust developers and how do you equip that.

But rather whether you can trust AI and just like with developers, it is not a belief question. It is not a faith question, it’s a controls question. You know like, what is it that you have in place to help you have that trust, that conviction, that helps you tell your boss and the board, “Yes, we are protected and we’re able to do that.” And so I think this notion of AI trust is critical and I think for the foreseeable future, the code that AI writes and the code that developers write will be intermixed.

And so, really, for me, it’s really about the combined dev and AI trust platform that you need to be able to be secure in the AI era and to keep up with that pace and so for me, that’s absolutely the iteration and evolution and it’s exciting and frightening but it’s unavoidable, right? I don’t think you can really – you can’t say, “I’m just not going to use AI.” I was about to say like any more than you can say, “I’m not going to use the Cloud.” With AI, you probably – that gap maybe is even bigger. You’re even less able to say that on the Cloud.

[0:44:21.0] Danny Allan: Yeah, that is definitely true. There’s organisations now that are pulling back from Cloud or maybe not using Cloud but every single organisation without exception will be using AI in some way and every single person I would argue is going to use AI. I think the shift that will come is, this year it was all about AI. At RSA 2024, it was all about AI. I think RSA 2025 is going to be about governance and trust probably more than AI.

[0:44:47.2] Guy Podjarny: Yeah.

[0:44:47.8] Danny Allan: So, I think and that’s exciting. I think it’s we’re at an exciting reflection. Looking back on the Snyk history, two more questions if I may, I know we’re running out of time here. What do you wish you had known at the beginning that you know now? Like would you have done anything differently over the Snyk evolution and history over the last eight years?

[0:45:07.7] Guy Podjarny: I mean, I often wonder about that question and I think it’s very hard to know what would have happened had you known more of the answers upfront. Like, had I known about this need for security for breadth, would we have veered off this tunnel vision for security for developers earlier on? And if so, would that have actually not given us the foundation and the strength that the developer had that we had before?

I mean, that’s a very likely scenario had I known it a bit more, right? Had I – I think a lot of the things that I do wish I had known have to do more with organisationally, like the rate of growth during the highs of 2021 and then the the need to right size in 2022 was very painful, also some learning around people. I think the market evolution you have to have a thesis about where it’s headed. You have to anchor in the future.

And then, really the true strength is not in figuring out the perfect path towards that destination but rather with having the power to zig and zag on the way to it. So, a bunch of these zigs and zags were incorrect you know? Some of them were paying the price for even until today but if you are not able to zig and zag, you’re almost guaranteed to never make it to that destination.

So, I think while there has been a million mistakes, I am always hesitant to say we should – I wish I had known that earlier on. Some of the goodness comes out of making that mistake and then becoming who you are for it.

[0:46:46.0] Danny Allan: Yeah, who we are is based on the experiences that we have had and if I can say one thing, you have built an incredible company and an incredible brand. For those people who aren’t familiar with the seven brand powers, I often think, and you can go and look it up if you are not familiar with it but I think Snyk has the brand for developer-first security in America and Guy Po, you, and you specificall, but you and the team have been responsible for building an incredible thing.

If I may end with one question, which you have asked everyone. So, I am going to ask it back to you, which is around AI. If you could use AI to automate one part of your job, I know that you’ve moved on now from Snyk, you are starting a new company, and I am sure that you have a lot of stuff going on related to that. If you could use AI in one way related to your new company or your new role, what would that be? How would you use AI to make your life easier and better?

[0:47:40.4] Guy Podjarny: I think – so the company, the company and the person are a little bit different and I think the answer I got the most was really on at administrative aspect of life, which I think clearly I benefit from as well and would love to have more of but I think really I would love AI to just serve as a super extended memory of everything that happens. I feel, I don’t know if this is old age or just information overflow or a mix of the two. But I feel I get to meet amazing people through the journey and some with notoriety and some the world doesn’t know they’re amazing yet and have all these great conversations and learn and a lot of the synthesis that comes out of that is really what guides what I act on. I feel like there’s just so much that gets lost in the way and so I’m a notetaker on meetings, you know?

I try to think about it and again, I think like I’m decent that synthesis that I think really if I want to like have a true AI superpower, it would be around that. I have a lot of other exciting – I am very excited to see the future that AI brings in terms of personalisation and dynamic content that adapts sources of context and our reality at any time. But the tool I really most would want is something that can just remember for my own purpose everything that I have seen and happen to me so that I can access it at any time.

[0:49:05.8] Danny Allan: I love that answer. Actually, if I – I think I would modify my answer to be the same as yours. We often forget the lessons that we’ve learned in the past. As much as we want to remember them, we often forget them and live through them. I mean, as a society and as a culture in general but I love that answer. Well –

[0:49:25.2] Guy Podjarny: And it’s just like, just might say that this is be careful what you wish for because it is possible, like compressing some trauma, is that remembering the the positive spin on something but still, that’s what I would say.

[0:49:35.5] Danny Allan: Yeah. Well, Guy Po, it’s been fantastic to have you on the podcast and hearing the history of Snyk. Congratulations again on building an incredible company and thank you to everyone for listening and tuning in. We hope to hear you again the next time on The Secure Developer.

[0:49:51.0] Guy Podjarny: Yeah, thanks, Danny, and thanks for taking on amazingly over here and many of the things within the company. Yeah, and I am excited to now enjoy the creation, do a lot more, you know? And supersede the original. So, thank you.

[0:50:06.6] Danny Allan: Excellent, and thank you everyone for tuning in. We’ll hear you and have you join next time on The Secure Developer. Thank you.

[END OF INTERVIEW]

[0:50:15.8] Guy Podjarny: Thanks for tuning in to The Secure Developer, brought to you by Snyk. We hope this episode gave you new insights and strategies to help you champion security in your organisation. If you liked this conversation, please leave us a review on iTunes, Spotify, or wherever you get your podcast, and share the episode with fellow security leaders who might benefit from our discussions.

We’d love to hear your recommendations for future guests, topics, or any feedback you might have to help us get better. Please contact us by connecting with us on LinkedIn under our Snyk account or by emailing us at thesecuredev@snyk.io. That’s it for now, I hope you join us for the next one.