Ask Guypo Anything

EPISODE 121

[INTRODUCTION]

[00:00:01] ANNOUNCER: Hi. You’re listening to The Secure Developer. It’s part of the DevSecCon community, a platform for developers, operators and security people to share their views and practices on DevSecOps, dev and sec collaboration, cloud security and more. Check out devseccon.com to join the community and find other great resources.

This podcast is sponsored by Snyk. Snyk’s a developer security platform helps developers build secure applications without slowing down, fixing vulnerabilities in code, open source containers, and infrastructure as code. To learn more visit snyk.io/tsd. 

[00:00:49] Guy Podjarny: “So, I wanted to do something big, which I guess comes back to unicorn question, which is I knew that if it is successful, Snyk would be very impactful. So, it was go big or go home type bet. I don't think I thought about this in terms of unicorn or not unicorn. I just thought that if we successfully get developers in the security, it would be industry wide implications, and good things will happen commercially. And while Snyk’s journey as a company still has many, many, many more chapters to come, I think the industry, I'd like to sort of say that we've checked the box of getting, of breaking through and demonstrating that if you build the right tools, developers will embrace security.”

[INTERVIEW]

[00:01:33] Simon Maple: Hello, and welcome to another episode of The Secure Developer. I am not Guy Podjarny. My name is Simon Maple. I’m the Field CTO at Snyk and one of the co-hosts here on The Secure Developer. And the reason I'm opening this is because this is another special episode which is an Ask Me Anything or an Ask Guypo Anything. This is one of the episodes where the power really jumps into the listeners’ hands.

Over the last couple of weeks, we've been asking all of our listeners to really think up some questions that we can pose directly to Guy, and rather than Guy ask our guests a number of questions, this time, it is you the listeners asking Guy some of the questions. So, joining me here today, Guy Podjarny. Guy, welcome to your podcast.

[00:02:17] Guy Podjarny: It’s going to be fun. Thanks for being here, for driving this, Simon.

[00:02:21] Simon Maple: No problem at all. So, why don't we start, Guy, why don't we learn a little bit more about Guypo. So, Guypo, what would you say, let's say you finish a day's work. We'll say you finish the day's work at 5:30 PM for argument's sake.

[00:02:36] Guy Podjarny: Which never ever happens.

[00:02:36] Simon Maple: Which never ever happens. But what would a perfect evening look like for Guy Po where, obviously, chilled out, relaxed, enjoying life on the evening. What would you do?

[00:02:47] Guy Podjarny: Yeah, I think there's like various forms to it. But probably like, the two best paths are either kind of in the house or outside. So, outside, it's to go see some theatre show or some – I'm a foodie, I like kind of good restaurants, not just the food, but the whole kind of experience on it. So, some sort of multi-course meal, probably just my wife and I or with a couple of friends, sort of small forum. I mean, those are really nice evenings.

At home, yeah, I guess kind of like a lot of other people. It's nice to spend a bit of time with the kids. My kids are both kind of starting and so, 11 and 13, having a bit of time with them, typically they only have so much tolerance for my presence. So, we have some conversations, a bit of how the day has been, but a bit of quality time, and then kind of a glass of wine. My typical is like, have the dinner and once the kids are in bed, sit with my wife, have a glass of wine and chat. Occasionally we'll get sucked into TV. But actually, more conversationalists most of the time.

[00:03:44] Simon Maple: Absolutely. That sounds lovely. And I bet you've obviously traveled a lot and then lived in various places. Which would be the city that you would love to have that evening where you're out to see a show and enjoying some nice food. Would that be London or somewhere else?

[00:03:58] Guy Podjarny: It's a good question. I love a lot of places. Tel Aviv and London are amazing to sort of go out and have that sort of meal and have the glass of wine out there. But yeah, but there's a lot of others like Tokyo is probably the most fascinating city I've been to. But yeah, London, New York and Tel Aviv are kind of my trial for, at any time you can go and no matter how much you've done it, you'd be able to find fun, new interesting places you haven't been to. 

[00:04:22] Simon Maple: Yeah, amazing. Guypo, before we jump into some of the questions that others have asked, let's ask another one to understand what you love to read or how you love to learn. I know you're a big reader. What would you say is one of the most interesting recent books or genres of books that you're into at the moment?

[00:04:40] Guy Podjarny: I tried to alternate between like a fiction kind of analysis book, or I don't want to call it a business book, oftentimes kind of history and such are very interesting. I just finished a trilogy called The Fifth Element, sorry, The Fifth Season that is sci-fi and I like it when someone changes the rules of a world, but then actually adapts everything around that if you've introduced some fantasy like, science fiction like, new technology or new superpower. And then how does society actually arrange around that, so I like that.

And then geopolitics are getting complicated, especially kind of with a lot of changes happening in the world. So, I recently read Ray Dalio’s Principles for Dealing with the Changing World Order, the rise and fall of nations. It talks about the rise of the Chinese Empire and kind of this world and maybe the decline of the US, super fascinating. And Professor Noah Harari. He wrote Sapiens before many people know it, but he also wrote this book called 21 Lessons for the 21st Century that talks about kind of slices and dices, immigration and nationalism, and biotech and infotech, and how they play. So those are fascinating, I think. 

For me, it's all, it's kind of understanding the world, and I think this is a time of change, maybe more extreme and more immediate than maybe, I think others might perceive it to be. And so, understanding that, forming an opinion, figuring out where is it that you should adapt yourself, and for me, I'm donating sort of, chipping in, or is it that I lean in, and occasionally the escapades of intelligence to fictional worlds, and sort of seeing how it plays out there.

[00:06:08] Simon Maple: Yeah, amazing. Wonderful. So, we know a little bit more about Guypo. Why don't we jump into some of the questions that have been asked by the community? So, first of all, we're going to jump into this, we’ve categorised these a little bit. We'll start with the questions that have been asked about, The Secure Developer, this podcast. How long does the podcast we go for actually, Guy?

[00:06:24] Guy Podjarny : Ooh, probably. I want to say maybe five and a half years now, something like that.

[00:06:30] Simon Maple: Wow. That's great.

[00:06:30] Guy Podjarny: It’s been a while.

[00:06:32] Simon Maple: Yeah, absolutely. And still going strong, stronger than ever. The question comes in, being a lover of all things cybersecurity podcasts, I would love to hear what sparked the idea behind The Secure Developer five and a half years ago, then, Guy?

[00:06:46] Guy Podjarny: Yeah, it was a combination of, on one hand, a general interest and drive even with sort of the Snyk agenda and my own kind of push to kind of do better sharing within the security industry. So, before I founded Snyk, I was a part of the DevOps movements, kind of the first waves in velocity and the velocity conference, and others, were really like the performance industry of the operations industry, or were disrupted by DevOps. I think a key part of that was people getting up on stage and talking about outages, talking about failures, talking about learnings. And my experience has been in the security scene, that really doesn't happen, nearly as often. Definitely not sort of seven years ago.

So, at Snyk, like a core part of the ethos to begin with was can we do thought leadership? Can we give people sort of platforms to give talks? We even further down the road acquired a conference called DevSecCon. So, the podcast, when the idea came up was very appealing, because it was an opportunity to kind of give security leaders a place in which they can share what they've learned, what they've done, maybe mistakes they've made. And opportunistically, you get triggered, because we became part of Heavybit, which and I was a big investor at the time was a bit more of a program, that focuses on that helping dev tools come up, and they had this great setup for podcasts. So, I could be lazy, I could just get a guest, come along, initial ones were all in person, when I would fly to San Francisco. I would kind of get someone to come to the Heavybit offices where they had all the setup, and do a recording and they were great at sort of editing it and doing it. And for a good number of episodes, like a few, tens of them. They still produced the podcast.

So, it was a great opportunity to try it out. That was a bit of the opportunity taking side of it, and it was a lot of fun. I got to say that, running a podcast is just basically goodness all around, because you get to talk to smart people and ask them some of the questions that you're curious about, and then you give them a stage to share it with the world, and hopefully the listeners get something and learn something and come from it. So, it's a bit of a win, win, win. Very happy that it happened there and I think it was kind of seizing the moment there with Heavybit.

[00:08:46] Simon Maple: Yeah, absolutely. And almost six years ago, I guess for a developer security podcast, I'm sure the mindset, the market, et cetera, has changed a lot. I'm sure a lot of the discussions that you had six years ago are obviously, very different to today when cultures within organisations have changed so much. Actually, there's a second question which leads on really nicely from that, which talks about after all these years of episodes, what topics is being discussed now that you least foresaw in the beginning? And I love the next piece of text which follows, which is what would episode one, Guypo, be most surprised to learn that episode 119, Guypo, is talking about with guests?

[00:09:29] Guy Podjarny: This is a really fun question to think about. First of all, it was that skim back and look at the topics on it. So, I'd say, first of all, it's actually amazing how much hasn't changed and it's just sort of scaled. You look back to the first episodes of the podcast, they talked about engaging developers, techniques to sort of getting developers to embrace security, even sort of service mentality within security teams. They talk about security champions. They talk about security education, talking about measuring security, which I'll get back to in a bit.

So, a lot of inclusion, but some diversity in security. So, all of those topics are still alive and well. I don’t know if I’d be happy or sad about that, I think, at the time, it was a bit of this tiny echo chamber talking about it. And I think now those conversations are happening more in like industry level, instead of talking to some 100-person, cloud native organisation that gets the sort of the forward-thinking approach. Now, we're talking to the massive, governmental or large enterprises that are adopting this. I think the majority of it, amazingly, actually continues to be the same, just basically adapts to different context. I don't think I'm surprised by that, because I think that's – I mean, it's interesting to see it, but I think that was, I guess, it was on paper, the plan, the path we're going down. The areas that are different, probably one that's kind of throughout has been the complexity of measuring security.

And I think maybe, it was naive, I sort of would have thought that, we just haven't figured it out yet. But there are some people that have a clear answer and it's just sort of not well known. I think you're in sort of episode 120 or so, it basically feels like it's just not – we just don't yet have an answer to it. It's just a very kind of finicky beast and the interesting one, so that surprised me, but I would still be talking about measuring security. I would have thought that that would be more addressed by then.

I guess another midway part is the whole notion of cloud security coming to developers. When I started this podcast, and when I started Snyk, didn't really anticipate the sort of later learning that with the world of the cloud, a lot of these IT layers have become software, and they need a software security solution, and they need to shift left, and they need to move to developers. And today, it feels we're not in the early innings of this. I think people are now increasingly understanding this. It's not as established in our perspective in cloud security as it is in, maybe the core application security. But I think there was a learning that really very much sort of happened through the podcast and talking to smart people, about how they divide containers, security, and infrastructure security and the likes. That was a surprise throughout.

I think today, so probably the least expected topic that I have is regulation of security, which I find really interesting. And today makes a lot of sense to me. But I absolutely did not see it coming. I think when I started the podcast, my view on compliances, and sort of all of those regulations that you need to be compliant with and the government's getting into security and all of that was much more negative, was much more like, “Yeah, it's a deep technical complex topic. There's no way that it can really be properly addressed.” Fine, it's good for business, but what's not really useful.

And I think today, there are, like in recent episodes, not even that recent, but team from Mandiant, and Geoff from LinkedIn, and actually, like a variety of others, just had a conversation about this with Adrian Ludwig and Atlassian talking about not only the anticipation, but also the importance of having the markets or the government introduce some regulations and really forcing businesses to deal with security. I think that's really interesting and it maybe goes to show how critical it is to address this. I guess, when I analyse this, an evolution of the digitisation of everything, literally everything, that sort of all in and around us, and maybe the growing participation of nation states and sophistication of attackers.

But I think from under the context of The Secure Developer, I didn't think we'll get into regulations, but topics, supply chain security and executive order, calling for developer security, those worlds have definitely now blended a fair bit.

[00:13:44] Simon Maple: Yeah, it'd be interesting to also, I guess, as a follow up to that, understand what Guypo of 219, episode 219 will be talking about. I wonder if the regulation of security will continue across the EU, et cetera, and talking about mandating SBOMs and other restrictions there. But also, I wonder if we’ll still be talking about measuring security or whether that will be solved. Anything you predict or foresee as new topics going forward?

[00:14:10] Guy Podjarny: So, it's hard, of course, it's hard to foresee what happens. I don't think we will have solved supply chain security. I don't think we will have solved measuring security. Hopefully, we've made a dent in it and we advance, but I suspect those topics would still be alive and well in the conversations. I mean, I think one that would grow a lot is data security, including privacy. There is in general, in the world of tech, more appreciation that data is the heart oftentimes more than software or networks or anything like that. I think there's more and more functionality in the world that is moving to be, queries, really in practice or some form of like transformation or manipulation of data. And with those kind of security concerns.

So, I think the notion of how to secure the work of the data analyst or the data engineer, how to secure machine learning models, how to secure basically our storage and handling and processing of data and sharing of data. I think that would become more central, in CISOs of use. So, I definitely anticipate more of that. And it's interesting to think about transparency. Maybe this is like episode 319, whatever it is. If it's further out. I think the notion of decentralised data assets software, the whole world of sort of crypto and blockchain, not so much for the currencies, but for other as a processing model, as things that might run locally, but be somehow protected. Basically, maybe this is the evolution of zero trust. When you think about at first, the clients or anything, but are we going to get to a place in which the servers are anything as well. Compute might happen at any place, in any way, and the implications of data security, I think, is interesting.

So, those are two that I – the second is clearly more speculative. Data security, I feel very confident will grow. In fact, I'm almost surprised that it hasn't been yet and I think supply chain securities kind of rapidly elevated demand for attention is probably pushed into little bits to the side.

[00:16:16] Simon Maple: Yeah, very interesting, very interesting topic. It's great to hear that you just committed to another 200 episode there, as well, Guy.

[00:16:24] Guy Podjarny: Working on it, as long as people tune in.

[00:16:27] Simon Maple: Wonderful. So, I love this next question, which has been asked, which is actually, reusing one of the questions you very often ask our guests, or pretty much every time ask our guests at the end the podcast. If you had unlimited funds to solve a problem in the cybersecurity industry, what would it be, Guy?

[00:16:43] Guy Podjarny: Yeah, well, so I guess, the cynic might say that that's basically 2021’s reality. You have unlimited fun to tackle a problem in security, in the growth company. 2022, not so much. You're sort of a little bit more expectation of being responsible. But yeah, I mean, I'd be remiss to say it's like, I'm literally dedicating kind of the last seven plus years of my life to be tackling one of those, which is developer security. I remain, as much, if not more conviction about its criticality. Now, fundamentally, everything is moving to become software enabled and needs software security solution, and the world is becoming decentralised software creation of digital worlds. It’s happening at the edges, at the sort of at the teams, the independent teams that are running it, and we need to equip them.

So, I mean, that is not the sort of at the top. I'm kind of practicing that. I do have the kind of the luxury of doing some angel investments and things like that. I tried to sort of stay out of trouble in terms of anything that overlaps with Snyk, but still sort of see a bunch of interesting evolutions in that security space. One that is interesting that comes to mind, there is like a notion of almost pentesting as code and nuclei in project discovery, so that's kind of interesting. And there's a lot that's happening over there.

But I'd say at a high level, aside from developer security, which is clearly the most important thing to tackle, along with supply chain security. I'd say it's actually, the key solutions are less in security solutions and more in platforms, and trying to basically obviate away a whole bunch of security needs. Just make it so the developers don't need to worry about them, because they're just a part of the platform. I don't think there's sort of a single thing you do to make security go away. But there's a whole range of things. Things like intent-based authorisation in which every piece of software says what it wants to do, and then is constrained by the platform to only be allowed to do that or focused perimeters.This was in the last conversation I had with Adrian Ludwig on, what if a component had a perimeter, right? Or if we were really, really good at the microservice perimeter, so that the blast radius was smaller. So, you need to care about the problem. But really, the damage would be smaller, or like hiding data, back to data, hiding data from the platform. So, an attacker that did get into the system couldn't do anything with it, couldn't really access the data. Maybe they could manipulate future tampering. I think, things like that. What I would say is, when you talk about making a problem go away, I'm not a believer in, “Hey, we will have a system that automatically reverse engineers and understands how your system behaves, and therefore it enforces some set of behaviours.” I mean, those are handy and can be useful, so I'm not opposed to using them. But I don't think that's the – under the, what would I tackle, I think it'll be things that are more, more fundamental, more akin to what reacted with cross scripting to just make the problem go away.

[00:19:35] Simon Maple: And it's interesting that you mentioned that you spent the last seven years at Snyk solving a lot of similar problems, like being a developer, security. Let's move on to Snyk. Obviously, as the one of the co-founders of Snyk. One of the questions that's come in is what was the aha moment when you identified a gap in the market between existing appsec tools, and the fact that they didn't empower developers in the typical shift left mode that we've seen and in many neighbouring spaces.

[00:20:02] Guy Podjarny: Yes. Solutions on it. I think I talk about this a fair bit, as I sort of explained Snyk. I think, fundamentally, we were building auditor tools and we're trying to shut them down developer's throats and trying to get developers to sort of embrace security tools, security practices at a time in which developers are busier than ever. And so, the kind of a lightbulb moment, the aha moment was that if we want to get developers to embrace security, you need to build a developer tooling company, not a security company. And I guess that difference was something I've become aware of, because I left security.

So, I was in security from 2002, actually, from ’97, but in the industry, from 2002 to 2010. And then I went to performance, to web performance to making websites faster and the DevOps world, and sort of spent the next sort of six or so years in that world. And so, it gave me a lens to realise, well, it's actually not the same, and I think when you're sort of in security all the time, that's probably true for other industries, you can't really see what else it can be. So, my catchphrase at the time is you have to leave security to fix security, and you have to kind of be in a different place to be able to see it right, to see the delta, to see the alternatives. And so, the combination of those was to say, “Well, what if we just did what is obvious in DevOps world, to security world?” And yeah, we went from there.

So, that was the conviction. It doesn't, by the way, mean that it was obvious it would work. But that was the lens or the realisation that I guess, in sort of, I'm a fan of Hamilton's Seven Powers, it's a strategy framework, that term, the counter positioning, the sort of the approach that is this counter to what the industry is doing.

[00:21:48] Simon Maple: And it didn't mean that it was going to work. But when? Was there a key moment when you realised, “Actually, this is really starting to pick up or are people really connecting with what we're offering.” Perhaps it was a blog post or maybe it was a something that lifted the profile of the company. Was there a moment like that?

[00:22:09] Guy Podjarny: Yeah, I mean, I think Snyk’s journey. It's funny, when you're successful than everybody some thinks it was just this smooth, like, you just sort of sailed, of course, it was always correct. And we didn't pivot out of the core, but not for lack of temptation. So, I'd say, it can take an hour or more to sort of talk about all sorts of learnings and failures and attempts in the process. But probably, maybe if I draw like three key points in time, one was, we shipped the product at Velocity Amsterdam in a keynote, a free tool beta, like a crappy little tool that could apply patches, except there were no patches in the database. It was very initial. We didn't ask anybody to pay for it. It was an open tool very, very, very shortly after sort of founding the company. It was Assaf, my co-founder and I, we presented it, and I think that was a good start and we got people to use it. And then over the course of the next nine months, we got the first key insight nine, maybe even more 10 months, we had the first key insight, which is we saw people using the product, but not continuing to use it.

So, they would download the tool, which was just the command line interface at the time. They would use it, they would find issues, they will even like tweet positively about it. And when we talk positively about it, but they wouldn't put it in the build. They just never really bothered sort of taking that step. So, I think we started flowing into that about six months after the launch, or maybe less, and we started learning about it. About 10 months later, we launched maybe a bit less. We launched the GitHub integration. I think that was a key, that was probably like one of the most important product decisions that we've made was the realisation that we can approximate dependency trees by sort of looking at them in GitHub. And by virtue of that, we can allow some next, next, next experience when people go on to the website. Specifically, Snyk was always free for open source, but when it's on the command line, it doesn't manifest as much.

But in GitHub, we could make it free for open source, and we can be very visible, and that got us into the open source ecosystem. More and more open source maintainers started using Snyk, which I'm happy with, because they were securing the projects, but also to give us visibility, we were opening fix pull requests on open source projects, people saw that. And so, I think the developer virality, that was probably like a key point. It wasn't that overnight, as we launched it. We got there. But I remember getting like Free Code Camp to use it, and a variety of others, and to get some attention. And then for the subsequent year or so, we got a lot of developers using it and we got practically nobody buying it. It was really disheartening, is this business going to survive or a whole bunch of like, a whole wave of that interest coming from investors that failed to materialise by everybody, like the top tier investors, everybody sort of saying, “Yeah, come back. Talk to us when it's actually successful.”

During that time, I think we learned the delta between developers and security. What is it that you need? And I have this whole kind of rant here that will take us the whole time here about how developers need depth and security needs breadth, and we need to effectively kind of provide both to be developer adopted, but security purchased and security adopted product out there. And so, that didn't require – one thing, it required a series of kind of innovations, if you will. Required figuring out the broker, which was the thing you ran locally, that would connect your on prem GitHub Enterprise, which amazingly, we didn't support at the time with our service. So, you can use it, it required adding more languages. It required a variety and it took about a year until there was like a seminal deal at the time, but tipped.

About two years into the company, we were at about 100,000 ARR, which start-ups is not good making $100,000 a year after having burned several millions. But then we nearly 7x that in subsequent four months, and then we 7x again, in the year that followed. So, that was kind of a commercial turning point.

[00:26:03] Simon Maple: One of the big things that I know has been shared from Snyk across many different webinars and things like that, is the PLG motion and the dev first motion, that is really underpinned and driven the company. The question has come in, asked, what are the most important things that you or Snyk set in motion early to drive your initial PLG engine? E.g., community, shipping a stellar product, DevRel? I know you had a very good DevRel person early on, I think, from what I remember, particularly keen to hear this from a dev tooling perspective in a space where you're doing something relatively new for developers.

[00:26:39] Guy Podjarny: Yeah. I mean, look, the key to unlock successful product led growth is to hire Simon Maple as your associate advocate. That was definitely, by the way, important. But I think not entirely farfetched over there is, look a product lead growth is a big motion, and specifically like our kind of claim to fame, and probably key accomplishment is to kind of unlock that world, security in which because security teams, naturally – maybe let me explain this a little bit, because I think it's important. So, if you're a developer, and you're coding in whatever, JavaScript and you're deploying on AWS, and you're using VS codes to code and GitHub and Circle CI, then you care about support for that stack. And if I support or don't support other stacks, in my solution, it matters not at all to you. Because it doesn't. It just doesn't change your day to day lives.

But if you're a security person, and you need to tackle all this kind of growing, overwhelming number of threats and attacks, and you need to tackle your code security and your open source security, and you need to do threat modelling, but also secure containers on the cloud, and the human elements and security training and all these things that's already plenty fragmented, and you can't multiply that by every tech stack in your organisation. And so, you need solutions that offer breadth. The combination is very, very hard. And naturally, the security industry, because the security people tend to sign the checks, tends to buy us broad, even if it's shallow. And in turn, these types of broad solutions may take a long time to evaluate. They need to appease the whole company. So, they lend themselves to more sort of sales lead, top down sales, that are more involved, while developer tools that allow, “Hey, this specific profile here, can I win those over biases, product lead growth, and some sort of adoption in which a developer just picks it up and use it, sort of a dev team does, et cetera.” That combo was really difficult.

So, for Snyk to succeed in doing product led growth, we had to adopt the dev tooling approach. And so, we picked a specific niche that was big enough and small enough in Node.js. If you know the stories of New Relic and Heroku, which were some successful developer platforms over time, they, for instance, started in Rubyland, and they stayed in Rubyland, they stayed only supporting Ruby for years before they expanded.

So, we picked Node.js, which we felt was adopted well enough to care, but was small enough that we can kind of make it to the top if you will, and kind of become a known player in that ecosystem and really, really focused on that. And that hurt us commercially. It's a part of the key reason that we couldn't make money for a while, because it didn't satisfy that need of security teams. But the sort of the very firm conviction we had, that the most important thing is to break through to the developers, to get developers to embrace it. And then if we succeed in that. good things will happen down the road, along with investors that were the right investors that have that conviction, that's what we did.

I think from there, we evolved a whole bunch of important practices like the free tier and the sort of free for open source and the virality that drove. We built a commercial kind of scoring system called proc qualified leads that we scored and all of that. But really, all of those are implementation details relative to this belief and conviction to say, you have to pick a specific slice, focus on a user and a use case, the developer kind to secure their code, secure what they're building and provide them an open source security of that, or today, often referred to supply chain security, and really focus on nailing that was the most important way to make it work. If we deviated, there were many temptations, had we deviated from that, we wouldn't have had the motion that we have today.

[00:30:22] Simon Maple: Yeah, very interesting. And I think, hard for existing security focused tools that have been around for many, many years to then pivot into that, because this really is a mindset thing from day one, and has to be a complete focus and a complete from top down.

[00:30:38] Guy Podjarny: And throughout the company, I mean, the number of conversations we had about the Color scheme of the website so that it's warm and builder, not breaker. Same for the logo. We didn't go to events that were sort of security events. We went to developer events, but also just practically speaking, when you look around, you can barely name really a company, if any at all, that was really enterprise led and has become developer friendly and developer adopted. It just doesn't really happen. A lot of examples, basically, all the successful dev tooling companies evolve the other way around. But yeah, at the time, we nearly went bust, we need investors with the right conviction to kind of withstand the journey.

[00:31:18] Simon Maple: And if we flip this around a little bit, another question that came in was asking the opposite. What was the hardest thing? And I think we've probably answered it a little bit of this in some of our questions. But what was the hardest thing in the early days of building Snyk? And I'm sure the sight of a possible unicorn would be something that was not remotely envisioned, or was it? And I guess, another question there would be, maybe was it a distraction as the Synk, grew, as well.

[00:31:41] Guy Podjarny: So, everything in start-ups is hard. We were starting with a blank slate, and this big vision and conviction that you can create something that's really, really big, and that requires like a little bit of insanity, like a little bit of delusion, that delusion of grandeur, if I may say so, you think that that is doable, that it can be done. When you really literally have nothing at the outset. It's a blank slate. So, everything is hard. Hiring people is hard.

In my first start-up. So, for context, I had a first start-up that I sold to Akamai. I was CTO there for a bunch of years before founding Snyk. And in that first start-up, I literally, I think I spoke to like everybody that I knew, and nobody would come work for me. Like literally, nobody would make that leap of faith of saying, “Yeah, Guy will actually found a company that will succeed.” I was a good developer. I had a good reputation there, but like, nobody really will do that. And only when I got a great co-founder that has already founded and exited a company and has a network, only then people was like, “Okay, we’ll come work for you.”

So, the second time around at Snyk, I had that sort of credentials. I was already CTO. I already founded it and it was still very, very hard to hire. First accomplishment was getting Danny and Assaf, my co-founders to drop the start-up they were thinking of doing and come join me. And then bit by bit, you know, there's a whole bunch of people in the company in Anna Debenham, Gareth Rushgrove, who I've chased for years until – they wouldn't take my emails. I think she'd be okay with me sort of sharing the story here.

[00:33:09] Simon Maple: She still, does she? From what I understand.

[00:33:09] Guy Podjarny: She still doesn’t take my emails. That's a different story now. But she wouldn't take my emails. I have to get through someone else for her to sort of even be introduced, then she came to tell me no, in person just because basically out of courtesy. Then she took a contracting job and eventually joined it and it was very impactful, kind of in the forming of Snyk and throughout.

Gareth Rushgrove, now runs most of our products and most of our security products. At the beginning, it was friendly, would meet for coffee, and I know, even at some point before joining Docker considered Snyk, and then said, “No, I'll go to Docker.” So, you have to have perseverance. Hiring is very, very hard. I've already mentioned getting to revenue was very, very hard. Alongside all of those is maintaining the conviction and not pivoting, because security is a world in which there's a fair bit of money. I don't want to say that it's easy to create a successful security company, not at all. But if you have the traction and you know people and you're sort of in the traction, it's a much less risky path in terms of getting to your first dollars. And I guess, I had that chip on my shoulder. I had already founded and sold a company. I already had that check, a kind of personal repertoire. And so, I wanted to do something big, which I guess comes back to the unicorn question, which is I knew that if it is successful, Snyk would be very impactful. So, it was go big or go home type bet. 

I don't think I thought about this in terms of unicorn or not unicorn. I just thought that if we successfully get developers to embrace security, it would be industry wide implications, and good things will happen commercially around it. And while Snyk’s journey as a company still has many, many, many more chapters to come, I think the industry, I'd like to sort of say that we've checked the box of breaking through and demonstrating that if you build the right tools, developers will embrace security. So, I'm pretty chuffed about that.

[00:34:57] Simon Maple: Here's the question come in as well, and you’ll like the start of this question, I feel, Guy. Aside from using Snyk's tools, duh, what's the easiest thing a developer can do right now to improve the security posture of their development practice?

[00:35:12] Guy Podjarny: The top answer that comes to mind for me is care. I care about security. I think though, in practice, one of security's biggest challenge is that it is invisible, that you don't know that you're not doing it, and it's so easy to not notice. So, easiest thing is to just introduce a security question into every templated or structured process that you have. You're doing sprint planning, add a question to say, “What are we doing about security in this sprint?” You are doing code review at a standard question that says,” What are the security implications happening over there?” 

Every time you have something that you're doing in some form of like repeatable fashion, add the one or two security questions about it, and that would really make a world of difference in terms of just like remembering and thinking about the security implications. And my view is that the biggest challenge isn’t the security expertise, it isn't measuring security. It isn't all of those, which are all legit and important problems. But it's just no op. It's just the sort of the lack of action, because you don't know that you haven't done anything about security until it comes back to bite you. And so, I think that's the easiest thing. It’s true for many, not just for developers, but specifically I say, for developers, just add the security question wherever you possibly can.

[00:36:36] Simon Maple: I think, and I think we've said many, many times in the past, both on the podcast and in Snyk as well, making sure you add that question in the places where developers are being asked similar questions, you mentioned code.

[00:36:47] Guy Podjarny: Exactly. Whether they make a decision that might have a security implication. And so, anytime a decision is being made, there's a potential security mistake that's being made, and so just ask the question. Did you think about security?

[00:36:59] Simon Maple: Yeah. And a good follow on there, I guess, a lot of the time, I'm sure we have listeners from all types of different organisations, some enterprise and large organisations, but some equally, start-ups, people with small organisations that have small budgets. What would you advise cybersecurity leaders with a small budget? Or maybe free or low cost AppSec tools, what would you recommend that they try?

[00:37:23] Guy Podjarny: So yeah, I mean, part of it we just talked about, which is just start by introducing security into everywhere, in just as questions. I think the next step from that, and I’m going to get a bit maybe into tooling is to celebrate security and when it is well done. So similarly, security is not – it's invisible. But also, when you do it, it's just sort of table stakes. Of course, he did it. I think that's wrong. It makes security this thing that is all stick and no carrot. So, recognise people that do a good job. It doesn't cost you really anything. If you want to spend a few bucks, you can get them some sort of a security swag or some bragging rights type of things they can point out to say, “Hey, they've done something well.” There are a million examples through the years, here on the podcast about celebrating success and what you can do there. 

From a tooling perspective, I mean, yeah, of course, we should use Snyk. Joking aside, Snyk is not the only one that does have a very substantial free tier and it is for that purpose. It is so that it can accommodate and can be used by organisations, big and small, by teams just getting started, and it'll be anywhere from free to cheap, for you to use Snyk, if you're in a small volume, small size. I've also mentioned like, Nuclei. There are a bunch of open source projects, the OWASP world and others. I don't really want to get into, like use tool X or tool Y because I will get in trouble here. And I think there are a lot of good tools and a lot of not so good tools out there.

But the one thing I would worry a little bit about the open source alternatives, or just sort of the free ones is just be mindful. There are sorts of two types of mistakes you can make. One is you can use a tool or a feature that gives you a checkbox, but doesn't actually make you more secure. So, at least spend the time and understanding what is the additional security exposure you would get from using that. And then the second is, that I think I see this all the time. It's a shame, which is people, they save dollars on a tool, only to sort of spend five times as much on cycles of individuals on the team.

So, I would really sort of lean into putting weight on ease of use and reduced expenses. At the end of the day in the world of software, in most of our world, the most expensive resource is people and people time, especially in development. In security, both, very expensive positions. And so, just be mindful. I think if you slightly overspent on a tool, if you bought a couple of tools and they're sort of different. Very likely, that saves you money. Others, I know that sounds, like in Snyk, the vendor, I know that’s sort of convenient, but I truly believe it, that sort of thing. I see people being so many that jumping through hoops and sort of being very pleased with the fact that they've built a tool in-house instead of purchasing it and when you sort of find out how much time and knock subsequent dollars, they've sort of spent on it and will continue to spend on it maintaining this tool. 

I mean, it's really not the best equation for them to have. I think that’s it. Maybe it goes without saying that I would sort of say, if you're on a small budget, like focus on locking your doors and windows, security hygiene, misconfigurations, known vulnerabilities, just sort of getting people not to click efficiently. It’s like the basics versus the nation state attackers and lateral movement and things like that, which are important, but they're definitely a level next. 

[00:40:32] Simon Maple: Again, of course, that advice around free tools versus low cost tools, that goes well beyond security. And I know everything from IDEs even in terms of how much time it generally saves individuals, but also the frustration. People enjoy work, when they enjoy the environment that they work in, and that they enjoy their jobs, and using poor tools or using a poor development environment, can really affect people's willingness to work for those companies.

[00:40:58] Guy Podjarny: You could argue. This is a slightly simplistic statement that the whole existence of the name your open source project cloud, that sort of whatever, so and so, TerraForm cloud, or there are many examples of it, is because it's sometimes it's cheaper than free to use a SaaS solution. You don't want the cost of operating those. It doesn't mean open source isn’t awesome. I'm a huge fan. We're huge contributors. We very much would encourage you to sort of use that. But you have to be mindful that there is a cost to using open source, and you want to be aware of that cost and make the right decisions in terms of your overall cost and cost of ownership. 

[00:41:37] Simon Maple: So, Guy, we're going to finish with a very interesting question, actually. The question is, what separates a truly great entrepreneur from a good one? And I guess we should probably ask you, Guy, which of these are you? And what do you feel like you need to do to become a great entrepreneur?

[00:41:52] Guy Podjarny: Yeah. I mean, if I meet one, I'll tell you. I've actually met quite a few. So, there are smart people. I can opine on this without being a part of the cohort. What is challenging, though, that the reason like people love their silver bullets. It will be great to sort of say, “Oh, it's just one thing that separates you.” I'd mentioned sort of maybe three things, which is the fewest I can, because there's probably a dozen others.

But I think it starts from the ability to picture the markets, not as it is, but as it could be. So, it's not about saying, “Hey, I'm seeing people spend this many cycles over here. I can automate this. I can improve that.” Or people are asking for something, “I can kind of provide them with that.” But rather imagining, understanding the market, as it stands, understanding a problem, understanding the kind of first principles about it and being able to imagine an alternate reality, imagine a different place in which that is, which is a thought exercise. There's some element of talent here, but I think that's also a skill. It's just trying to think about, you can look historically at disruptions.

So, I think great entrepreneurs are able to not be constrained by kind of the current reality when they think about solutions. And I think a lot of the great founder led companies, because they sort of see a need, and they're able to imagine a world in which that need is addressed. So, I guess that's the core of it.

The second part of it is the ability to collaborate around it. On one hand, it's communicate it and explain it, and people think about messaging as a marketing vehicle. They think about, like, “I have the answers, and therefore, I would kind of be able to condense it to all these simpletons around so that they can understand it as well.” I think that's just flawed. Really, what you want to do is you want to be able to collaborate with customers, with other people on figuring out the solution and do it in a continuous fashion. So, that requires you to be able to take feedback, and this not terribly common combination of confidence in that sort of alternate reality you're painting, people talk about the intrapreneurs have a reality distortion field, that you could get trapped in, but then you need to let others into it as well.

So, you need that confidence, but then you need to combine that with humility. You need to combine that with an understanding that you could absolutely be wrong. You could be wrong about the destination. But more importantly, you can be wrong about the journey. And so, you really, really need to invest in seeing how are you taking the feedback. Do you just get defensive and try to push it out? Or do you try to understand? Generally, if people give you feedback you don't like, it’s either because you're wrong, and you need to learn from it. Or it's because you didn't communicate your ideas well enough, you didn't explain. So, either way, there's something for you to learn. And then you need to also get people along for the journey. So even when your right, you need to be able to inspire people to grow them. I think this notion of collaborating with others as you sort of shape your destination and I know I'm kind of lumping in way more than one or three.

The last thing that I would say, maybe this is one of the first or the second, is the focus on the customers. A lot of entrepreneurs, they build a great thing and they really focused on the thing they built. I like to say like, nobody cares about your product, not when it's small and when it’s big. People only care about the problem that it solves them. They care about the value that it provides to them. So, why or why, so many products of saying, “Hey, look, this is an amazing piece of technology. That's this, this and this and this.” And lead with that, it's just not relevant. It doesn't matter. What matters is what problem are you solving for me? What pain are you solving? What is going to be achieved by me using your product?

So, I think great entrepreneurs are just very, very focused on the steps of sort of outcomes, on the user need, on the eventual value versus the – it doesn't mean that there isn't some amazing piece of tech that they're building and solves it. But I think if you're a great entrepreneur, you're focusing on the value you are providing, not the technology that you're building. These are many, many, many – I didn't add resilience, of course. You need perseverance, to be able to sort of go take a lot of nos in the process, again, alongside with humility, which sometimes you actually are wrong, and you need to identify it. So, it takes a lot of things.

But I do want to say that at the end of the day, I like to use the wavelength analogy. I think when you go into entrepreneurship, then you need to brace yourself to a world in which the highs are very high, and the lows are very low. And there's no real two ways about it if you're creating something from scratch, and you found it. Within the same day, very, like minute things feel like they are the best or the worst ever, promote a failed build or sort of declined email to a successful, sort of whatever new coloured button or a meeting was accepted. They feel much more significant. It’s like a world that hasn't stabilised. Like there hasn't been any realisation.

As time goes on, the company becomes less existential, the wavelength diminishes a little bit, sort of the lows are a little bit less low, the highs are a little bit less high. Because they're not –you didn't feel like you were sort of an existential threat and managed to overcome it. You kind of had a bit of stability. But you have to embrace it, and it's not easy, but it's also really, really fun.

[00:47:13] Simon Maple: Awesome, well, Guy, that brings us to the end of this episode. Massive thank you for all the insightful answers that you've given and very open and honest answer. So, thank you very, very much for that.

And also, thank you to our listeners for submitting, providing us with all these great questions that were posed here today. I'm sure we'll run many more of these AMAs with Guy Po and others. So, feel free to let us know what you think of the format, what you'd like to hear to more of or less of, in this format, and we'd love to hear directly from you. Okay, until next time. Thanks very much, Guy, and we'll see you on another episode of The Secure Developer.

[END OF INTERVIEW]

[00:47:54] ANNOUNCER: Thanks for listening to The Secure Developer. That's all we have time for today. To find additional episodes and full transcriptions, visit thesecuredeveloper.com. If you'd like to be a guest on the show, or get involved in the community, find us on Twitter at @DevSecCon. Don't forget to leave us a review on iTunes if you enjoyed today's episode.

Bye for now.

[END]