In a RE: Human Layer Security Podcast episode, Guy Podjarny, Founder and President of Snyk, explained why he believes decentralized application security is no longer a “nice-to-have”, and the benefits of putting security in the hands of developers. 

Q. Why did you start Snyk and what’s your mission?

I’ve been working on application security for over a decade now, and I’ve seen the market evolve quite a bit. But I’ve always been guided by the idea that application security should be put in the hands of developers.   

In the first wave of the DevOps movement, I left IBM and founded a web performance company. I was really engaged in the community and learned to appreciate the changes to development that DevOps has brought to bear.  

Snyk represents the realization that security needs to be embedded into development, and that it isn’t just a “nice-to-have” or an optimization play. It’s a must-have, and companies need to cater to developer’s needs.

The idea was to create a developer-tooling company that tackles security, and the key for us was to think about the user—not just the buyer; to think about the developer as the primary user and ask ourselves:

1. What would it take to get a developer to embrace security? 
2. What would it take to get a developer to be delighted by a solution that helps them tackle security? 
3. What would it take to actually break through and embed security into the development process?

We call this “developer-first security.”

Q. How do developers think about security vs. security professionals?

Where security professionals focus more on breadth, developers focus more on depth.

When someone working in cybersecurity sees a vulnerability, they think about risk. They zoom out. If they hear “vulnerable log4j library”, their first questions will be around how exposed they are. 

When a developer hears about the same issue, their default action is to zoom in on their particular application. Their first questions revolve around functionalities, performance, and scalability. 

And it makes sense. If you think about the actual job of someone working in cybersecurity, their job is to understand, identify, and help reduce risk. Even though they care about fixing the issues, that’s not their job. That’s the developer’s job.

Q. Why is security a must-have and not just a nice-to-have?

The world is increasingly dependent on software being built by independent teams that move fast. The faster you can get a line of code in the hands of a customer, see what the customer has done with it, then adapt to those needs and change the code…the better. The tighter that feedback loop, the better the business does.

The problem is, security tends to get in the way of this process. 

It remains centralized, requiring things to be reviewed, audited, and supervised—it doesn’t empower teams to work independently, which slows them down. And that’s a problem that has to be solved. Fundamentally, it’s only the companies that make security a seamless part of their processes that will succeed financially and thrive.

Q. How has Snyk confronted friction between developers and security?

Simplification is key. 

As humans, the equation is simple: you have to care about something more than it burdens you. Caring could be related to consequences, pride, money….there are a variety of reasons why you might care about something. 

As a company, Snyk tries really hard to communicate why developers should care. 

The problem is, for most developers, there was no real incentive to care about security. They didn’t get recognition from security teams, and it slowed them down in shipping features of capabilities. Lose-lose.

The primary thing that we’ve done is simply make it easier for them. Don’t get me wrong, we do our fair share of explaining the “why” and “what-ifs”, but our success boils down to simplifying security. We make it easy to pick up, use, connect, and integrate seamlessly. It’s a part of their natural code reviews.

Q. How can companies embed security into their business?

Security carries the risk of either being too restrictive or too easy to ignore or work around. The key is to make it collaborative. Instead of having it be dictatorial, it needs to be decentralized, just as we’ve done with the Operations department, before the DevOps change.

A decade ago, Ops was the department of “no”. They were the ones slowing things down. They were ticket-operated, teams weren’t incentivized to help, and instead maintained the “status quo”.  

But today, DevOps teams are platform builders. They’re enablers. They’re empower-ers. They aren’t just focused on risk; they’re focused on unlocking business value. That’s the same transition we need to see with security. 

This notion of a “blameless post-mortem” is one of the key strengths of the DevOps movement. When there’s an outage, you seek out the root cause and how to fix it as opposed to the person. It’s not about finding who to blame, it’s about finding the problem and addressing it.