In conversation with Guy Podjarny, Founder & President, Snyk

In just a few years of hyper growth, Snyk has become a $2.7B unicorn, most recently raising $200M in September 2020. A developer-first security company, it has also helped usher the “DevSecOps” category.

At our most recent Data Driven NYC, we had the pleasure of hosting its Founder & President, Guy Podjarny, zooming in late at night from Israel.

We covered many interesting topics, including:

• What does DevSecOps mean?
• How did Snyk initially get developers to care, and how did they expand horizontally from there?
• What is infrastructure as code?
• Thoughts Snyk Code and Snyk’s vulnerability database
• The nuances of combining a bottoms-up, freemium motion focused on developers, with an enterprise motion focused on economic buyers of Snyk’s products.

Below is the video and below that, the transcript.

(As always, Data Driven NYC is a team effort – many thanks to my FirstMark colleagues Jack Cohen and Katie Chiou for co-organizing, Diego Guttierez for the video work and to Karissa Domondon for the transcript!)

VIDEO

TRANSCRIPT

[Matt Turck] Welcome, Guy. Really appreciate your joining us tonight, especially considering that you are normally based in London, which in itself would be five hours ahead. But as I understand it, you are actually in Israel tonight, so it’s like midnight?

[Guy Podjarny] I am but I’m a night owl, so I’m okay.

I hope you are appropriately caffeinated.

If I say anything, especially foolish, I’ll just jot it down to the hour.

Snyk has had a wonderful last 12 months from the funding perspective, revenue increase, employee count increase, and even acquisitions. What are some of the key things we can talk about that happened in this pandemic?

Oh, it’s been a crazy year. Snyk’s general trajectory – we’ve gone from 23 [in 2017], to 84 [in 2018], to 250 [in 2019], to 450 people [in 2020] in annual increments in terms of staff. So, we’ve done a fair bit here. This year was a bit different in lumpiness because there was a pause in Q2 in hyper-growth despite the undercurrent target with COVID. So, it might not have been for the best reasons, but pausing hiring in the midst of this hyper-growth, was actually such a breath of fresh air, being able to cement a little bit of the processes, and have some familiarity, and cope together with the more personal challenges everybody has across the pandemic. But still, we’ve grown from 250 to 450. We’ve grown, I think, about 200% in revenue, and a similar number in ARR.

We launched two key products, which are infrastructure as code, and we’ve acquired a company called DeepCode, which intersects with Snyk Code.

We also acquired, at the very tail end of the year a company called Manifold, which is a great set of talented individuals helping us bolster the platform. So really we grew all around. I think internally, just a ton of scaling – we really transitioned from startup to scale-up, if you will, over the course of these 12-18 months. We did raise about $350 million during that period of time as well. It felt like there was a sequence of these six to seven months apart type of fundraises – really almost overwhelming demand from investors. So, first class problems, but still something we had to manage over the course of the year.

Amazing. Well, congrats on all of that. Maybe as a jumping off point, what is Snyk?

Snyk is a developer-first security company. What we mean by that is the company was created on the belief that security has to be built into the development process because nothing else scales. Especially as we talk about DevOps and cloud, and a modernized surrounding, and that to achieve that, you need to build a developer tooling company, not a security company. That was really our light bulb moment, is to build a company that puts the needs of the developers, and how do we delight the developer first, despite the fact that the person signing the checks is oftentimes the security buyer.

So, that’s really the core of us. We’re about five and a half years old. We started Snyk open source and we can talk about the different product evolutions. I talked about the two products we launched, but we started off with this dev first mentality, tackling open source security, secure the open source components that we use, and have grown to what we call today cloud native application security, which is in a cloud native context in which developers are more and more empowered and they increasingly manage parts of the infrastructure in this cloud set up, everything becomes an API. So, basically we secure everything in the rebuild. If you look at files from Docker files to Terraform files, to all these different aspects. So, yeah, that’s Snyk in a nutshell.

Snyk is part of an emerging category that you guys have actually helped define, called DevSecOps. Do you want to talk about what that is and maybe contrast it with DevOps?

Yeah, DevSecOps, the gist of it, it’s about putting security in the middle of Dev and Ops, but it’s about adapting security to the DevOps motion. So, generally DevOps has predicated on breaking the barriers between developers and operations, about independent teams that can take the ball from one end of the court and run with it all the way to the other, and do that repeatedly without external dependencies and continuously.

Security hasn’t gotten the memo. As an industry, it’s still operating as a separate entity. So, teams are not independent. Oftentimes, they get dictated to, so they don’t really control their destiny. It’s oftentimes not continuous, it’s not automated and enough, a lot of manual reviews and manual processes. So, at a high level DevSecOps is about changing that. It’s about building a security model that allows you to ship continuously and through independent teams, but still be secure in the process, unless you’ve just been dropping the security controls. Then just like DevOps, you ask five experts, you get 10 opinions about the exact definition of DevSecOps. But fundamentally, it’s about bringing security into the DevOps fold. That requires transforming the security industry and the underlying security methodologies.

The fundamental reason for this, and the fundamental premise, is that a lot of the security tools were invented for a different world, whether that’s firewall, so endpoint security, that was invented for the previous generation, but in a world where you have cloud, and microservices, and containers – that has been breaking, is that the idea?

Yeah, there’s two things being mixed. There’s DevOps and cloud.

DevOps drives the need that I mentioned before about dev first security. It’s the idea that the decisions around security are being made by developers, and then you want the security control to be near the decision maker. It’s not a new need, it grew in importance over time.

Alongside the dev first security solution to the DevOps change, the cloud change happened. What the cloud did is it turned IT into an app. So, pre-cloud, applications were mostly some code and some libraries sitting on top of this hefty central IT stack, which might’ve been your central IT apps and databases and such. You had the team manager, your data center, your infrastructure, your VMs. Those IT teams are fairly security minded, and they had IT security solutions.

Now a lot of those layers have become APIs, and those APIs are now managed out of the repo as part of a development process, containers versus VMs is a good way to think about it.

So, they no longer require an IT security solution, they require an application security solution. And so really that’s the different transition where you could have done that first security just for the classic kind of code in libraries of the app. But we think that the right scope of responsibility for developers today, is really the sort of cloud native scope that includes these different components.

Let’s jump into the product. When you guys started initially, I believe the initial product was focused on helping secure open source projects, right? Was that the origin from a product standpoint?

There was an interesting kind of ambiguity with our name, which I think might’ve even kind of served us well, which is we were open source security. So on one hand you feel like it’s security open source. It’s the security that is open source in practice. It was securing your use of open source. So you’re consuming open source libraries, and there’s an ownership paradigm problem there, which is you download this stuff from the internet. Nobody’s really got your back. You need to know what you are using and you need to make sure it’s vulnerability free and maintain that over time.

So, that’s what we started with. When I think about reusable lessons here, what was interesting for us is we set out to be a developer tooling company following the developer tooling playbook, but we were talking to the security industry. So when we started, we started with very much the dev tooling playbook, which was pick a stack and deliver, pick something fairly narrow and deliver a great developer experience on that stack, win over that community. And so we build open source security or securing open source usage in node js. So mostly npm packages, which we felt was a niche that was big enough and small enough, big enough to care, to sort of have some commercial viability, but also small enough for us to make it to the top and become the standard in that ecosystem. That worked really well to get developer adoption and really quite poorly to get revenue. So as it turns out security, if the dev tooling playbook is go deep, stay deep you see Heroku, you see New Relic’s thing and Ruby led for a good while when they started.

The security person needs breadth. If you solve the security threat, but you only solve it for 50% of my apps, you’re not very helpful security. I’m going to need to buy another tool or find another solution for the other 50%, because I need to cover against this threat across 80%, 90% of my stack. So when we started, we started with this open source security, which proved to be good, it was a specific need and problem. And it was helped by the Equifax breach that kind of helped raise awareness during that time. But it was also a problem that we could kind of conquer that developer, but we managed to scale it horizontally to additional languages. So, that was the first exercise. Only once that was quite established. It’s not done. It continues as languages keep evolving and changing and there’s more languages to be added.

But once that was evolved, we expanded into containers, following customer demand. People realized everything we build has this question about how is it dev first? How, do we rethink the security problem from a dev first angle for containers? It felt the industry had been seeing containers as the evolution of the VM. And they’ve been trying to retrofit VM patching practices onto containers while we see containers is the evolution of the app. And so just that angle, that statement led us to build a different solution to addressing it, containers with this very successful… and then subsequently this year, we accelerated that more would have to speak, hearing everything in the repo. Another interesting learning that we had there is we shipped every new product we’ve added and now we’re doing it intentionally. Container was a bit more improvisation. We shipped it as an add on first.

We don’t ship crap products. Pardon my French here. You know, we ship very good products, but very narrow ones. And we ship them as add-ons and always developer friendly, always delivering on that promise. And then as we broadened and beefed up those products, we increased the price accordingly, and eventually we made those products standalone. So they can also be purchased even without buying one of the other products. And that has become a very capable, very healthy methodology for us. And we adopt that for new products as well.

Infrastructure as code is thinking for an insurance code, which secures our form scripts and the likes today.

Do you want to explain what that is maybe for people that are not familiar with the concept?

So infrastructure-less code – increasingly more and more of your infrastructure is automated. Instead of spinning up the first iteration of infrastructure-less tools that came along to automate, originally you would log in to Sage and have some server you’d provision a machine that comes up, you’d SSH into it, or someone would start installing stuff on it. And then the layer tools called Puppet, Chef, like that generation of tools came along and introduced automation. So, instead of you logging in and SSH running those things, so you would actually have something automated run it. And then subsequently solutions like Terraform came along, which are more cloud minded. And they managed not just cloud, but they’re just sort of more modern, more dev oriented around how much control you have and how sophisticated your infrastructure configuration is.

At that point. You have a code in your repositories that sets up your infrastructure. That code, like any other, can have bugs and security mistakes. For example, you probably didn’t know that Kubernetes by default runs as roots. So you need to explicitly tell it do not run as roots when you don’t want that extra capability in case that machine gets compromised. So that’s one of thousands of different security mistakes you might make, but developers are not security experts. So they need a system that, in a developer friendly fashion, helps them identify these problems and then fix them. Our view once again, for this one, there’s a world of cloud security. It focuses on more of a data center in the cloud type approach. Come on, log in, see, which doors did you leave open for an attacker to walk in. We took more of a developer approach and said, Hey, as a developer, you just asked me to make infrastructure decisions, help me out.

Help me figure out am I doing this correctly? And so we build things, we build a solution that’s git oriented that connects to your source code, repositories and flags decisions in a developer friendly fashion and aims to automatically fix them. We open fix pull requests that basically are kind of like a helper developer sitting along next to you and help you address the vulnerabilities or the security mistakes that you’ve made. And that’s been our approach. Hopefully that starts to sound consistent with the other products that I’ve mentioned.

And what about Snyk Code? What does that do?

So Snyk Code is interesting, to an extent it expands a little bit more into the history. So in the world of vulnerabilities, actually the majority of the industry today is focused on not these open-source components or all that, but rather on custom vulnerabilities in your own code. You write code, you write bugs, some of them are vulnerabilities. So there’s a plethora of an alphabet soup here of SAST, DAST, all sorts of like static analysis, dynamic analysis, interactive, which is instrumentation based, all sorts of solutions, trying to uncover in different ways vulnerabilities in your own custom code. The one that has the most promise and the most anguish in it is, is SAST, which is theoretically scanning your code during program analysis. So just inspecting your code automatically and figuring out whether there is a security mistake here.

Can I identify a path that an attacker might take from injecting some data into a form field and going all the way into your database and stealing some data out of it? And SAST is a great promise because you connect to the source code and it has full visibility and practice. It’s a very, mathematically hard problem. And it resulted in a decade worth of tools. I’m responsible for one of them. I built AppScan Source quite a few years ago now that is just laden with false positives. They find issues very very well, but they’re laden with false positives. And so what we’ve done with Snyk code is we figured we will not enter the SAST world unless we can really change the paradigm here, unless we can actually build something that is fast enough for CI/CD, which these tools are not, and that is accurate enough to actually be usable to developers. Because as it stands, these tools are not usable for developers.

The interesting play here is we actually ended up acquiring a company that does this in Zurich, DeepCode, which was not a security company. It came in as a quality analysis, super sophisticated machine learning base, I can kind of ramble on about how amazing the technology is. But I think maybe the interesting part is that to find that we kind of scoured the market for all the sort of security, static analysis companies that we might work with. It was actually in the quality world that we found that technology that we firmly believe is the best one. So we’ve acquired them, we’re bringing them onto the platform now the product is now available. And it completes again, that view of the repository, which is secure the code that’s in your repository as well.

Yeah. Actually, as a quick aside, I’d be interested to learn more about how they do it. So they just train models based on …

It’s a combination of program analysis using machine learning. It surveys the older code on GitHub, if you will, and identifies for starters, it trains sources in sync. So it identifies API that might be sources of information, or might be destinations of sensitive actions like a form field and like database, but it does so using machine learning. So you can give it 10 form fields, like read from form field type examples, and it uses machine learning to find a thousand more. And then subsequently it looks historically to say, well, I’ve seen this bad data path or this data path from source to sync from form fill to database. And I’ve seen many, many projects modify that as an indication that there was a problem here and they fixed it and they did it in some bulk or consistent fashion. So, there’s a lot of machine learning around – you have to still do the program analysis and understand the software – but then the machine learning really kicks in at understanding what’s right and what’s wrong based on an analysis of large volumes of quantities. To do that at scale and in a timely fashion required some pretty significant innovations on the tech front to just do it fast enough and absorb it .

Very interesting. The vulnerability database also sounds super interesting. And that’s something you guys have been doing for a while, or is that more recent? What is it, what does that do?

Yeah, from the beginning. So I kept harping on the developer first angle, but in practice, we combined developer first and security expertise. In the context of open source vulnerabilities, I can have an amazing system that tells you which libraries you’re using, but I need to tell you whether they’re vulnerable, I need to know which vulnerabilities are known. And what happens is in the world of open-source dependencies, open-source projects, an open source maintainer would fix a vulnerability, would say as much in the release notes. And that would sort of disappear into the ether of GitHub. And so we build actually from day one threats, intel systems that listen. So we have a team now about 25 odd people that have a system that reads sources of information. It’s just like these like social feed torrent – we actually also technically read those social feeds.

We read open source projects, like the Apache JIRA projects and GitHub and many other sources. And we identify candidate vulnerabilities. That system has gotten very sophisticated over the years and it uses machine learning to identify candidates. So some of it is simple, straightforward. It’s like bring the NVD database in and we’ll identify and some of it is much more natural language processing and other sort of combination of hands to be able to identify candidates. What’s important for us though, is that we are a curator. So any of those vulnerabilities we find, they’re a candidate vulnerability and the human says yes or no, this is the vulnerability and adds additional metadata. And those have become an asset that we have really, which is the vulnerability database on top of which the products work and also has become a great source of power for the ecosystem partnerships. And we have a variety of like Datadog and Dynatrace and Trend Micro, and like a lot of players in the ecosystem, the Linux foundation, Google Chrome, many players rely on it now as their sort of information source for vulnerabilities, because there is no other good one really in the ecosystem.

I’d love to spend a few minutes on the go-to-market side of this, which might be interesting to anyone who’s building a comparable company in terms of motion. So as you said at the beginning, you guys initially started with security open source, but you’re actually not an open source company. You have a freemium model, not an open source. Can you talk to the thinking behind being freemium and not open source?

I have lots of thoughts about freemium, but fundamentally to me freemium is about a use case. So what you want to do is you want to satisfy the needs of someone to do something.

In our case, we defined our freemium tier as twofold. One is we want to help open source projects secure their project. So we made Synk free for open source. So open source projects can use Snyk at no charge, we can scale substantially. I heard someone refer to it as cheaper than free. Not only is it not open source, but it is actually even better for them because we also operate and run it for them. Then subsequently they help us amplify the business to help us get awareness in the ecosystem.

And some of those people work at companies. And then for companies, we built a more classic freemium model, which is at a certain volume and at smaller teams you can use things for free and at some point we’d like you to talk to a salesperson and maybe move up.

So this bottom-up motion was very focused on developers, developers succeeding, having successful, delightful use of the product. Really lower the bar, but why wouldn’t you? Because every developer wants to build secure software. It’s just very hard. And so we made it easy. When you got to more larger scale or governance entities, that’s really where a commercial offering where you just kind of tip into the commercial.

And we actually stick to that model today across the different products we’ve made the free tier more and more generous. The open source piece it’s just a misnomer, which I think again, I think we inadvertently benefited from just because like GitHub, GitHub is not an open source company but it benefits from the halo of open source. But we do take care to be very good citizens in the open source community and ecosystem and give back.

It sounds like you have this combination of product-led growth, like developer focused, bottoms-up strategy. And then presumably like an enterprise motion where you sell to the management – how does that work?

So we have a different user and buyer. The security person is a user. It’s an important user of ours, but we are, as I said, at the beginning dev first, we see the developers the most important user of the product. But generally you get the product that’s purchased out of the security budget. In smaller organizations and mid organizations, we see more and more development teams also purchasing – also platform teams and DevOps. But it’s still like a governance function or mindset that typically pays the bills versus a developer that needs to be using it on a day-to-day basis. So our sales model has always focused on that area for developers. 

What do we want is adoption – use it, succeed. That’s also true in existing customers. They might have purchased the license for 50 developers and they might have 200. How can we show our value to more of those developers that are in that organization? That’s combined by more of a governance message and outreach that goes to security people. The majority of our business is still freemium and inbound-led. So we make noise in the ecosystem. We have actual free users that are scored and we send them a relevant email. We identify organizations like a little bit outbound-ish is we identify organizations that have a lot of free users in their organization, but we reach out to them from outside. And then it gets complimented a little bit with slightly more traditional out-of-band.

But I think the key thing is that we’ve taken advantage or we leverage our freemium motion and community presence to bolster even the conversations with the buyers. I think you have to do that as well or you have to be able to explain to someone signing a large check, “Why is your product worth that amount?” The groundswell gets you adoption. They get you in, it’s kind of yours to lose, but you still need to be able to, to satisfy the CXOs or the senior person’s needs. When you talk about million dollar deals and higher.

How does that scale from an organizational standpoint ? Do you have like one centralized marketing function and like one part does like dev rel, the other part does buyer marketing, what does that look like?

Yeah. So it’s a good question. I think in general, as the organization scales you go from a generalist to specialist. As the company grew, at the beginning it was a bit all hands on deck and that division didn’t matter as much everybody was very connected to it. So the same product leads and marketing leads cared about both the freemium motion and the top-down motion, both the user and the buyer.

As we grow, we have more and more specialization. Today when you look at where we stand, we have a dedicated product led growth motion, which manifests as a subgroup within product, a subgroup within marketing and the subgroup within marketing has a dev rel view to it, which is more community-minded and such, and has a growth component to it, which is a bit more funnel management, a bit more understanding how many users did we get, how many, how well, what percentage of them activated and can became successful users of them? How well are we monetizing those users? 

And so it’s mostly led between product and marketing, but there are dedicated leaders and dedicated people under them. Because it is true and we’ve seen this as we went through that it became hard for someone leading both the product-led growth side and the enterprise motion to say, no, I will put aside this like very large customer’s requirements, and I will prioritize this sort of freemium user need instead of that.

So you have to make that decision strategically and provide resource isolation so that you wouldn’t steal resources. You wouldn’t starve resources away from the freemium motion. And also that there would be some people in their organizations that all they care about – and saying it in air quotes, because they do need to have a bigger picture in mind – but their primary concern is free user success. Despite the fact that dollars are not directly attached to them.

So we have a few audience questions that came up but we are sort of running out of time, so let’s do them as rapid fire if possible. So one of them is what skills are appropriate to have as a DevSecOps person? Is there such a thing as people that have that job?

Yeah, it’s a job that shouldn’t exist because it’s all about breaking barriers, but a DevSecOps person is very similar to an SRE. They should be a person able to build software, build services and help developers successfully find issues and fix them, as opposed to an auditor who should be good at finding those issues themselves and doing it. So, that’s probably the primary transition.

Okay, great. When building a developer first platform how did you approach product design? What are the specific features that get developers in the door and what features are the most important for dev teams, presumably the buyer to stick around?

For the buyer maybe a bit more security, but the key thing is to think about the bigger context of that user. And so for us it translated to automated remediation, because a developer’s job isn’t to find issues, it’s to fix issues. While an auditor, arguably their job ends with finding issues. That translated to Git integrations, like the workflows of where do they live. So what I would say it really boils down to what’s the broader context in which someone would run it, not just technically, not just shift left, run it earlier in the process, but rather, what else are they doing? What do they know? And really try to put yourself in their shoes and reduce friction as much as you possibly can.

Guy, thank you so much for coming in and talking to the data-driven investing community, especially at a very, almost we’re at 12:30am your time now. So really appreciate it. It was a pleasure or we’ll let you, I guess, go to sleep.

Happy to be here.