May 12, 2021

Software Security Gurus Webcast Episode #8: Guy Podjarny

Welcome to episode 8 of Software Security Gurus, with Matias Madou. In this interview, he chats with Guy Podjarny, Co-Founder and President of Snyk Security

They discuss scanning tools, and the rise of the developer in security programs. He also reveals his experiences in startup, and what he looks for in a great company.

Introduction: 00:00-02:10
Scanning solutions: Has the buzz finally died down?: 02:10-09:40
Can we ever get developers "on our side"?: 09:40-16:17
What does the application security industry still need today?: 16:17-22:50
The ingredients of a successful startup: 22:50-27:38

Listen to the podcast version:

Read the transcription:

Matias Madou:

Welcome to the Software Security Gurus Webcast. I'm your host Matias Madou, CTO and co-founder of Secure Code Warrior. This webcast is co-sponsored by Secure Code Warrior. For more information, see www.softwaresecuritygurus.com.

Matias Madou:

This is the eighth in a series of interviews with security gurus, and I'm super pleased to have with me today Guy Podjarny. Welcome Guy.

Guy Podjarny:

Thank you. Thanks for having me on.

Matias Madou:

Absolutely.

Matias Madou:

Hey Guy, do you mind sharing a few words about yourself?

Introduction:

Guy Podjarny:

Sure.

Guy Podjarny:

I'm the co-founder and president, I was CEO till last summer. I have this loose title now, President of Snyk. Snyk is a developer-first security company. I think we'll talk a little bit more about developers and security, focusing on open-source security, container security, and the likes. Further back in my career, I was a part of the early AppSec pioneers in Sanctum, building AppScan and AppShield. First web app security products, which got acquired by Watchfire, which got acquired by IBM.

Guy Podjarny:

Then I founded a web performance company that got acquired by Akamai, and I was CTO at Akamai for a bunch of years. The last step in that journey, really, is co-founding Snyk.

Matias Madou:

A ton of experience, and I would love to dive into two of these topics today, if you don't mind. Which is, first of all, yes, AppScan, scanning and developers. Moving from security to developers maybe. The second one is your experience with countless startups and as a founder, co-founder, coach investor, and so on and so forth.

Matias Madou:

Let's start with the beginning. Early on in your career, I think you had the opportunity to work for one of the best scanning solutions, which was AppScan. The reason I say that is, during that time I was at HP, and we had WebInspect. The polite way of saying is you were stiff competition. The honest truth is you guys were really kicking our butt with that solution.

Matias Madou:

The reality is today, I feel that the buzz is gone with these kinds of tools. Where, do you think, did it go wrong with these tools in the last 10 years?

Scanning solutions: Has the buzz finally died down?

Guy Podjarny:

I think there's been an evolution of ownership alongside the evolution of technology. WebInspect, at the time indeed, AppScan and WebInspect were the players, maybe a few a smaller ones doing the black box testing. They primarily were an automated pen testers activity. And at the beginning, it was really all about automating the activity so you can reduce the cost of pen testing, after you even convinced people application security was an issue because, at the beginning you didn't even know how to tell them. I don't know if you know this, but actually AppScan was originally created as a sales tool. Really, the product of Sanctum, of the company at the time, was AppShield, which was a web firewall. When we came to people and said, "Hey, you should buy this web application security protectors." They say, "Well, but I don't have that problem." So AppScan was built to basically demonstrate to them that they have vulnerabilities. Which overtime people said, "Well, the AppShield thing is scary, can I just buy AppScan?" And the rest is history.

Guy Podjarny:

It was very much ... It went from protection to just this automated pen test. Over the years, the appreciation for the fact that developers greatly outnumber security people and pen testers as a whole has grown. People understood that there was a need, there's a desire to run these types of tests early on.

Guy Podjarny:

From there, I think, a bunch of things happened. The term "shift left" came to be, the desire. I think I was saying this in 2003 It's not a new term, about moving it earlier in the cycle. The desire started there. But the tools were never really a developer tools. The tools that were built back then were auditor tools. When they were shifted left, all it meant was you invoked them in the build, in CI, which was massive [inaudible 00:04:12]. Or into QA phase, in some of those cases. It just wasn't enough to drive adoption. Also, I think developers themselves were ... It was still a period of time where it was very sequential, and ownership was very clear-cut. This is where I stop and you start. There wasn't as much inclination for developers to embrace it.

Guy Podjarny:

Then on top of that, I would also say that the black box testing, which today is called DAST, Dynamic Application Security Testing, it still hasn't found its way. It's not the most pipeline-friendly technology. It requires a running system that you would hack, sort of, you'd bash against. It's entirely doable to do it in a build surrounding, but it takes time. It takes effort. There's very [inaudible 00:05:12]. Today, still even fairly sophisticated scanners today, like Detectify or more forward-thinking crawlers, even they struggle to actually run in the build. They make it invoked from the build. The only thing I think you see in the build, from a black box testing perspective, is things like OWASP Zap, or things that are more unit testing. But what has happened is, and we can dig into those, is more a creation of new technologies that do that type of security assessment with static analysis and, more recently, SCA or Software Composition Analysis, finding vulnerable components, which are more pipeline-friendly, as well as a change in the approach of how to get developers to embrace them.

Guy Podjarny:

I think that's the rough timeline, I would say.

Matias Madou:

Do you think it has anything to do with just being the stick? Because I remember from back in the day, there was very little to help the developer, or to say, "Hey, this is how you remediate, or this is what you can actually do about this thing." It was very much, "Hey, you know what? We're going to do some pen test, and here are some results, and go fix it."

Guy Podjarny:

Yeah. I think the desire was there before. If you look at AppScan, it was Sanctum created AppScan, and then Watchfire bought Sanctum, and then IBM acquired Watchfire. Just to note, IBM Rational acquired Watchfire. IBM Rational, who was providing all the different developer tools, were the ones buying the security company, looking to build it in. Again, this is 2007. The desire to get developers to do it was already there. We actually, in AppScan, we did have a remediation tab. We had, you could basically see the vulnerability view, or you can see the remediation view of saying, "If you just fix this input validation problem on this parameter, then you'd fix all these different vulnerabilities."

Guy Podjarny:

I think it was usability was still poor for developers. The information was sometimes better, sometimes worse. I still think we lacked a lot of things, but I think it was just too hard. In everything in life probably, there's how much you care, and this is how hard it is. You need to care more than it is hard. The reality was that the security industry, I think what we've really mostly done is we've really tried to beat people. You're right, the stick element. Try to make you care more by trying to scare you, by trying to demand it of you, threaten you. In the world of, definitely in the world of DevOps or par developers, that just doesn't work it's about builders, not breakers. I think we were trying to inch up how much you care in the wrong way, and we weren't making it easy enough. We took an auditor-type product that would just find issues, that would take too long to run, that would report, as you point out correctly, its primary focus was around finding a problem versus guiding you to a fix.

Guy Podjarny:

We just told developers, "Hey, here, you can use this now." I think one of the changes that happened recently, and we definitely do this at Snyk and there's inklings of this happening elsewhere, is to actually take the opposite approach and say, "Hey, really what we should be building is developer tools and they should be tackling application security." I think once you take that lens, you do things differently. Your goal is the same, which is I want to identify and help fix a vulnerability, but the requirements, the knowledge around it, the way you interact with the product, definitely the way you celebrate successes and the likes, it just changes, night and day. For a developer, the experience of picking up AppScan back then, or picking up Snyk today, is night and day. There's really no comparing.

Matias Madou:

I think you're right, in this newer-type companies like Snyk, like Secure Code Warrior, and the likes, I think we acknowledge the rise of the developer, I can say. We try to think about what the developer cares about, and we try to see, how can we get ourselves in there to help the developer.

Can we ever get developers "on our side"?

Matias Madou:

With your experience, how do you think we can get the developer on our side? If I can use that. From a security perspective, how can we make him ... Not by the stick, but are there initiatives that you can do in your organization to make security or developers more aware about security and rally around the security of the product?

Guy Podjarny:

Absolutely. I think there's a lot you can do. First of all, you have to acknowledge that you have to. That there is really, fundamentally, when you look at DevOps, it moves us. The new practice of development moves us towards autonomous teams. Autonomous teams are meant to be able to take that code, and it doesn't matter if that means they have front-end and backend expertise, or the way they operate, or the way they secure software. They should be able to run quickly and create this tight loop from creating a piece of value, to getting it to the customer, to learning and adapting again.

Guy Podjarny:

If you are not trying to empower developers to make these types of decisions, without the security team organization, a security org being involved, then you're basically going against the business. Everybody else in your business is probably going to go faster. What you're doing is just saying, "No, no, no, we need to go slower." That just never wins. You have to, and I think the modern development practices today make it a necessity. You have to acknowledge that.

Guy Podjarny:

Then from here, I think there are basically two angles of what you need to do. For the developers, you need to make it easy. I would say first and foremost, I think every developer in the world, if it was the same effort to build secure software and insecure software, they would choose to build secure software. Really the [inaudible 00:11:22] is just how hard is it. We're asking developers to do a ton. Really what you want is you want to make it easy. Easy if you can, even fun. Practice like allow developers, give them the right information at the right time.

Guy Podjarny:

I'm a fan of gits. I think the git integrations. Git is where code review happens. If you integrate security controls into git, they happened at the same time that other code review practices happen. It's a natural place for a developer. You want to give application context, so when you describe a vulnerability, say you have a vulnerable component, you can say, "Hey, here are 500 components in your app. One of them is vulnerable, go fish." Or you can say, "Hey, you're using library A, it uses library B, it uses libraries C, and C is vulnerable." Suddenly you give the developer the context of the thing they actually put into the code, there is a myriad of them. And you definitely want to also not just be a naysayer and celebrate successes and highlights from a security team's perspective, which actually is a good segue to the other side. So that's on developers. There's a lot there, but if I was to summarize, I'd say, make it easy. Make it easy and it'll happen.

Guy Podjarny:

The similar change, which has probably no smaller, needs to happen in security. I like to say that it's not shift left, it's top to bottom that we need to do. Security team needs to go from being a controlling, top down-type organization, to being an enabler that drives for bottom up ownership. You have to allow developers to make those decisions. Security teams need to change their methodology. They need to focus on how do they help developers successfully find issues and address them, versus they themselves finding the issues, and going back.

Guy Podjarny:

I really don't care how easy it is at Snyk for a security person to run a scan. I care about how easy it is for a developer to do it, and I care how easy it is for a security person to govern, to loo across the board. But I don't care about how easy it is for them to run a scan.

Guy Podjarny:

Similarly, the security team needs a whole bunch of other capabilities in their product. They need things like, they need to relate developer activities to the different security posters that they lead to. They need to maybe partner. I really like Envision and a variety of others, actually, have a great pairing, similar to what finance and HR have done for many years. They pair an AppSec person with a certain set of dev teams, get the AppSec people to participate in standups and dev. Switch to being more of an enabler, an empowerer, build tools, help make it easy. It's their job to basically make that easy for the developers.

Matias Madou:

I couldn't agree more. I think for a developer, security just has to be there when he needs it. Doesn't have to go outside of his current set of tools. It just has to integrate what he's using on a day-to-day basis. From a security perspective, they have to be enablers. Previously, they were the naysayers. They have to be the enablers and see, how can I get that in production faster? How can I help you on a day-to-day basis?

Guy Podjarny:

Just to say that I think education is a big piece of it. When you think about developers, they need to know what to do, and then it needs to be easy. Sometimes even the knowledge is embedded into the technology that's invoked. Putting the right test in the build. You obviate the needs to ask the question, for the developer. But in many cases they don't. If you want to empower them to make good decisions, tooling is one aspect of it. Then proper education, and platforms like Secure Code Warrior for self-serve education. All of those are really good. They all boil down to that empowerment and ease of use, for the developers to make the right decisions, because they're going to make security impacting decisions, whether you like it or not.

Matias Madou:

Yeah, absolutely.

Matias Madou:

I think with Secure Code Warrior, what we're doing is we make sure that if they tackle an issue, if there's an issue filed, and it's a security issue, we want to be there, and we want to guide them and give them help and try to make sure they understand the problem, and find a solution on how to remediate a vulnerability and not make that same mistake twice.

What does the application security industry still need today?

Matias Madou:

Maybe if you don't mind, I would like to shift gears a little bit and tackle the second topic. As you've just mentioned, you have a ton of startup experience, being at Sanctum. For less than three years in your journey and being acquired by Watchfire, less than two years being acquired by IBM. You jumped ship, started Blaze.io. Again, within two years of being acquired. If I look at Snyk, it's five years old and it goes like a rocket ship. We can all agree that you have a ton of experience. I also, somewhere, I read that you even help startups with some seed funding, with some advice. My first question is, I know that needs your undiverted attention, but in all these other areas, in application security, where do you feel like, hey, there's still a need over here or over there. Is it maybe a company or an area of security that you're looking at that you find particularly interesting today?

Guy Podjarny:

I definitely love startups, whether I'm finding them, or I'm investing in them, or I'm advising them, or even just seeing the journey, I find it's almost like it's the way to stay fresh. It's the opportunity for you, or seeing someone else, think outside the box and tackle a real pain point.

Guy Podjarny:

First of all, I would say, security is a massive opportunity for many companies, I think it's a shift, at least at the resolution of DevOps, which really led to multiple industries, disrupted some and created some. I think the same type of change is happening for security. I see at a high level, and I've written about this, when you think about the pre-cloud and post-cloud era, or in-cloud era. Pre-cloud, applications where mostly coded libraries on top of a very hefty IT stack. There a centrally managed IT stack, and then it had some coded libraries, but your database, your network access, your VMs, everything was centrally managed and you'd open a ticket, your Oracle database.

Guy Podjarny:

In today's world, in the cloud world, and many companies are in the transition. They have some in that old world and some of the new world. The same threats exist. The same security risks exist. But now they're a part of the application. The same unpatched system, the same open port, the same unencrypted data, all these threats, they don't really care if you're in that old stack or new stack. Now these decisions are being made by developers. There's one transition that I think in the market, like Snyk is a part of it, but there's room for many, is that move from IT to AppSec. I think there's a similar move from IT, or central administration into DevOps, and into embedding security into that space.

Guy Podjarny:

A bit more specifically, areas that I think are really, really cool that I've been tracking are asset management. There's a big problem in DevOps. All of these are actually problems that are not just security, but security needs to be a part of that ride. This notion of knowing which entities, what's the unit that is moving around your system, is a key DevOps problem than having a security perspective of what are the security attributes of it?

Guy Podjarny:

I really like the thesis of the concept of security chaos engineering. I think it's a powerful one. Security lacks a feedback loop today, and while ops lacks the feedback loop as well, but at least there are some outages and they're shorter. They're not that disastrous. The number of outages, fortunately, is still far greater than the number of breaches. But even the number of outages weren't enough in DevOps to learn from, and to be the feedback cycle. So chaos engineering really gives them that predictability and simulates failure. Security chaos engineering is a term that is relatively new, I think in general and me. It basically talks about simulating security flaws and specific attacks. I think it's very nascent, but I think it's an exciting space.

Matias Madou:

It all comes down to security, but all going back to the developer, if I'm not mistaken. Or do you disagree?

Guy Podjarny:

I do, but you have to remember the lens here.? I live between DevOps and security, the whole DevSecOps space. I think there's just a huge, huge opportunity over there. There are other opportunities around two-factor authentication and the remote working clearly now in COVID-19 era, and this notion of access. It's already got the [CASPI 00:00:20:45], the cloud access world, there's already some bigger players in that space. I think that necessity, two-factor authentication.

Guy Podjarny:

I've given a talk titled, The Developers of Malware Distribution Vehicle, where I think there are two interesting security risks that come from developer empowerment. One is access to production. Today developers, because they basically have responsibility that goes from a code to production, oftentimes developers are much more ... Their machines are much more powerful. If you manage that production access in a naive way, it means there's some SSH key sitting on the developer's machine, on every developer's machine, oftentimes, that can just access production and starts querying access some junk box and go from there. That's scary. That's very, very scary. Same goes for access to all sorts of web resources.

Guy Podjarny:

There are newer solutions. There's one is called Small Step, which is interesting. There's open source one's called Bless that fix others. There's a variety of solutions to help control developer access to production, which I talk about.

Guy Podjarny:

The other one that's interesting is the open source private source interaction. There's actually an interesting, cool company called to Git Guardian that's in the space. We also talk to our customers and they talk about that concern, where they have private company artifacts, secrets being leaked to one of the developer's open source profile. Just by mistake, but because it's the same individual and because, oftentimes it's the same interface, their git interface even, that they work on, it's a fairly naive mistake. The power of the developer is probably an area of concern overtime for security as well.

The ingredients of a successful startup

Matias Madou:

If you look into organizations, what are the key ingredients? What do you look at it? Is it mainly people? Is it mainly the market? Is it mainly timing? Or some people say it's pure luck. Let's not discuss that one. There's always a factor of luck, but let's-

Guy Podjarny:

You mean that what makes a startup successful?

Matias Madou:

Yes, absolutely.

Guy Podjarny:

Well, I'm a big product go to market fit. I'm a believer in product go to market fit. I think what happens is startups, some entrepreneur, has a brilliant idea and hopefully even has the chops to actually build a product to do it. Then surrounding those people, there's all these desirable properties of a successful business, like being product-led, being a SAS business, being bottom up, and all sorts of properties that people want to have. People end up lumping all sorts of properties, from the go to market they wish they have, to the product they have. In reality, I think oftentimes you need to adapt that product to the go to market, or vice versa.

Guy Podjarny:

You have to really firmly ask, for instance, if you want a freemium product, what is the actual use case that your freemium offering is solving? What is it? Is it something people would actually use for a long time on the free tier? Are you comfortable with them not paying you for that stretch of time? If not, it's a free trial. A free trial is a different go to market. It doesn't mean you're building a community, and people with just funnel it, it means a trial. It means suddenly your behavior to those people that's registered is very different. That's just one of many examples.

Guy Podjarny:

Other questions are about channel. What's the minimum deal size you should have, and who's your user versus buyer. Which, for Snyk for instance, a big focus was the fact the developer's the user, but more often than not, security is the buyer. That creates a different go to market, different business management.

Guy Podjarny:

I think everything is hard in startups. You need a good idea. You need a good team. You need good technology. You need good timing. I think you can time markets plus-minus two years, if you did it well. But that Delta could be life and death for a startup, but you have to match that product and a product go to market.

Matias Madou:

It's keeping it real. It's keeping you real between what the market is that you want to capture, and the product that you're building, and making sure there's a match.

Guy Podjarny:

And how you approach it. How do you reach that market?

Matias Madou:

Maybe a final question. I once did an internship in Canada, in Ottawa. I read through your profile and you've actually spent 10 years over there. I actually didn't survive one winter. After three months I gave up and they went back to Belgium. What's the secret? How did you manage it to stick around in Ottawa for 10 years?

Guy Podjarny:

I actually like Ottawa. I moved to Ottawa for a year. I couldn't place it on a map when I moved there. For those who don't know, it's the capital of Canada. It was this quality of life type city. It's a city where people are genuinely nice. Because it's the capital, it has a good, enough culture and things around it.

Guy Podjarny:

You have to embrace the winter. My parents-in-law, when they flew in first time, they came from Israel. They literally got on the plane at plus 30 Celsius and got off the plane at minus 20 Celsius. That was the last time they visited it in winter. They visited in summer again, but not in winter. But for us, it's all about experiences. I'm an experiences guy. I embraced that you can skate on the canal. You can go around. I think it's a little bit of a never say never, on these places.

Guy Podjarny:

That's just when I said, I'm going to settle in a little bit, and Ottawa seems good. We bought a great house, an opportunity came to move to London, and lo and behold, I've been six years now in London. It's all about seizing opportunities.

Matias Madou:

Absolutely.

Matias Madou:

Just to be sure, I liked Ottawa. It was a fun winter. For all people [crosstalk 00:26:58]-

Guy Podjarny:

It's a harsh winter.

Matias Madou:

It is, but it's fun.

Guy Podjarny:

Yeah, it's a harsh winter.

Matias Madou:

It's fun. You can do dog sledding and all that stuff. I really liked it.

Matias Madou:

Guy, thank you very, very much for accepting being the eighth guru on the Software Security Gurus Webcast. It was a fantastic chat. Thank you very much.

Guy Podjarny:

Thanks for having me on. It was fun.

Matias Madou:

Thanks.

Never want to miss an episode? Get in touch and subscribe!