Welcome to another episode of the Cloud Native in 15 Minutes podcast. If you haven't listened before, the goal of the podcast is simple, to explain some complex but increasingly important and even strategic technologies and about the time it takes for a coffee break or a short commute or a walk or whatever it is you do to kill 15 or 20 minutes. So I'm Derek Harris from Pivotal and our guest today or my guest today is Guy Pajarni. Guy is the co-founder and president of a security startup called Sneak, S-N-Y-K, and host of the Secure Developer Podcast. And so in this episode, we talk all about security in the age of containers and open source and CICD and microservices. Guy talks about some of what Sneak does, but also just generally what good security hygiene and organization looks like within a company, whether it's what some people call DevSecOps or whether it's taking an SRE type approach to security and just kind of how that responsibility is split between developers and operations and security folks. And we talk about keeping up with the scale of containers you're running. If you're running 20 container images to one VM or one physical server in the monolithic world, I think it's a really insightful conversation on how it is that an organization and enterprise can try to keep up with not just new vulnerabilities, but really just get their security hygiene in place as the scale and speed of everything they're doing. And then their software development just keeps on increasing. So I think you should listen. And also, before we get into the interview, just a quick reminder, please subscribe to the podcast on Apple Podcasts or Spotify or Google Podcasts, wherever it is you listen. That's always a big help. And if you'd like to give it a rating on Apple Podcasts especially, please feel free to do so. And with that, here is Guy Pajarni of Sneak. Okay, Guy, so thanks for being on. To start, can you explain in about 30 seconds what Sneak does and why you think it's so necessary today?
2:05For sure. So Sneak is a developer tooling company that does security. So really, we try to think about security problems from a developer perspective because as the world, as software eats the world, everything's security is becoming software security. And we think that that's the domain of developers, really. That's the only way to scale security is to get developers to embrace it. We focus on open source security and container security. And we find and fix vulnerabilities in these open source components and container images in a way that is kind of continuous and elegant and embeds into your dev process without slowing you down. All right, cool. And at least from a software perspective, right, in the world that Sneak plays, how do you think security has changed over the past, I don't know, 10 to 15 years? And like, has open source been a big part of that? Yeah, I think, you know, open source is a component of DevOps, if you will, and a whole stack of changes that really transformed the way software is developed, developed faster. You know, software just sort of gets written and gets deployed. The path from writing a line of code to deploying it is much, much faster. And it is continuous, right? It doesn't stop. It's, you know, from CICD to a myriad of other technologies, including, you know, open source components and including containers. It just became continuous. And that really kind of rocks the boat for security because security's natural motion has been to work through gates, right? It's you stop here and you will audit. And so as software becomes fluid, right, becomes continuous, the opportunity to do those stops and to audit goes away. And that forces, that changes the world of security to need to embed itself more into the pipelines, into that continuous process, as that's really its opportunity. And so that creates, you know, a set of opportunities around, you know, policy enforcement and automated policy enforcement, but it's also hard.
4:07A lot of security tools don't work quickly enough, easily enough, self-serve enough to really fit into these environments. So they need to adapt. They need to change. You know, some do it more successfully than others. And then subsequently, that pace, that change in development pace, also means that there's no delay. And the security team, which is typically outnumbered, you know, 50 to 1, 100 to 1, can't keep up. So you need not only to move those tools to be embedded into the pipeline, you also need a lot of their operation, a lot of their daily use to move to be done by developers. So that's the DevSecOps, if you kind of choose a buzzword, you know, transition. And that's a change that very much impacts developers around the need to sort of embrace more responsibility, but also impact the security world. As, you know, they need to sort of shift how they handle it to be more of a, more like an SRE, like a reliability engineer or, you know, a guiding entity, but expect more of the operation to be done by the developers. So, yeah, all I would say, like pretty, pretty substantial changes that are, they're not in the last 10 to 15 years. They're very much kind of playing out right now. All right. And I mean, so you definitely touched on this, but I wanted to ask, you know, just kind of expressly, I mean, so, so open source, you know, being a big part of what you do, but how have these other things, right? You mentioned containers, but, you know, the idea of microservices architectures and cloud and, and, you know, software as a service, everything. I'm sorry, big bang there. Sorry, everything, you know, like all the, how have all these shifts and all these new kinds of prac architectures and tooling and stuff changed the way that that enterprises have to think about security? Yeah, so what they, what these different tools, what these different platforms do is they enable speed, right? Like fundamentally, you know, DevOps and all of those technologies that underline it are, are all about a faster time to value, right?
6:08Faster time from indeed a line of code being written to, to a customer or user being able to use it, a faster time to adapt to a new marketing, a new market need, a new customer need. So it's really all about, all about speed. And really, when I, when I think about, about this transition to, to, to DevOps, to security, you can think about it in, in three levels. You can think about DevOps technologies. And, you know, these are indeed the ones you mentioned, microservice, actually like less microservices, more of the cloud, the containers. And then you have DevOps methodologies like microservices or, or the continuous processes, the CICD. And both of those are very important in terms of, of their sort of impact on how you do security. You have to change your security to tackle, you know, these new technologies and to tackle these new methodologies. Because both of those accelerate development. But more than anything, it really kind of goes back to the DevOps shared ownership mindset. Because really these, so these methodologies, you know, microservices and CICD are a means to an end, right? They're a, they're a, they're a mechanism to allow small developers teams, development teams to take ownership and go through the pipeline and, and take on ops responsibility. And security basically needs to be embedded into that. So, so definitely these technologies and methodologies matter and they impact and they contribute to the acceleration of development. But I think sometimes it's wrong to think of them as the source. It's not that they contribute to it, it's the DevOps shared ownership mindset that drove the evolution, right? And the adoption of these technologies and methodologies, which in turn create the security need. I hope that makes sense. Yeah, definitely. So, so it sounds like what you're saying, and correct me if I'm wrong here, is it's, yeah, it's not like, because some people argue open source, for example, is more secure for various reasons, right? It's not like that is inherently a vulnerability, right? But like, so it sounds like we were saying is, you know, maybe it's, maybe it's just the, the pace of things, the scale of the number of components, the scale of everything, right?
8:14That's, it sounds like that, and maybe even some more obfuscation in terms of what's being used, whereas you're embedding components inside containers, you're, you're, you know, you're building applications that are comprised of, you know, various different services and whatnot. I mean, is that kind of like the, we're saying, the, all the tech, the technological stuff, some of it just like picks, ramps up what's expected. Yeah. It kind of makes. Yeah. So I, I agree. I think that's, that's, that's, that's a, that's a good statement. Definitely open source is not less secure, nor more secure than, than closed source code. And, and it's not, you know, nor is, you know, a DevOps methodology, right? Or a continuous pipeline more or less secure, you know, than a different approach. They just have different properties. Specifically, specifically, I do come back to people. So when you think about open source, for instance, it does two things. One is, is prevalence. So because open source is there, because you don't want to reinvent the wheel, then you go off, you have a piece of code that is very, very useful, and everybody embraces it. So it's not that that piece of code, OpenSSL or Bash or, you know, the Docker engine or whatever it is, is, is more or less secure. It's just that it's amazingly prevalent, you know, just far more so than any commercial software. So when a vulnerability does get found in one of those components, it has a whole world of victims available to it. So its implication on, on the entire internet ecosystem could be seismic, could be far more substantial than, than commercial software. So in that sense, open source is not more or less secure, but its security is more important. The likelihood of an attacker exploiting a vulnerability in an open source component is just higher. And you can kind of make the argument that a cloud application versus one that is just sort of hidden in the data center, if it is more exposed to the world, it provides more value, but it also increases its attack surface. So that's one aspect, but the other, maybe a very people oriented aspect of open source is one of ownership, right?
10:16And it has to do with, with the fact that an organization that uses open source is getting a piece of value for free. But they're downloading it from the internet, and their use of it is at their responsibility. So organizations need to, need to build a new muscle, right? They need to understand how do they, how do they use this software that they did not write and take ownership of securing it, even though it's, it's not their developers that wrote it. And that's, you know, I think that's a very substantial change to how, how companies think about managing their software. And, and frankly, kind of an area where I think solutions like Snicker, that's the notion, right? You need a new tooling ecosystem, whether it itself is open source or commercial, to allow you to just cope with this new world of ownership that you have to have around securing your open source components. All right. Yeah, that makes a lot of sense. And I think, you know, if anyone's listening and isn't aware, right, I mean, the Equifax breach a couple years ago was famously an unsecured, unpatched open source. Yeah, absolutely. Absolutely. And I think, so for open source security, you know, Equifax was kind of the poster boy, you know, so the poster child of, you know, a Java vulnerability, you know, a Java struts vulnerability that wasn't sophisticated, wasn't fancy, was very severe, and was very prevalent, that was discovered and tripped up Equifax. So it's really about, you know, and that resulted in the cascading kind of a breach, and they've had a whole bunch of other security mistakes, but the linchpin, sort of the core of it was this vulnerable, unpatched Java library. If you look at the Capital One case right now, more recently, the Capital One breach, where it was a configuration mistake, from all we can tell, you know, and again, not a fancy configuration mistake, just, you know, overly permissive access control. All of those things are, they're not about, you know, a super sophisticated tool. They're about usability, they're about security hygiene at scale, right? They're about developers operating it at speed, without slowing down, and just owning, you know, owning all of those changes as an organization.
12:22Yeah, definitely. I think the, like you said, the at scale part, I think is key. Yeah, absolutely. Each of them, securing, exactly. Securing a server or a library is easy. Securing 10,000 of them or a million of them, that gets hard. Right. Are there things happening right now that you see opening, you know, new, that are kind of new avenues for vulnerabilities or new challenges to doing this aside from just, you know, aside from some of the stuff we talked about, if I looked at, you know, serverless or functions, right? Or are there other things that are kind of coming around that, that might, that people aren't thinking about that, that could, that shift this or make it even more difficult to, to manage? I think, so every new technology introduces some elements of risks, but I don't think that those are the, the, the primary ones, right? If you look at, at serverless, there is a certain risk around, you know, the fact that people assume that serverless are, are immutable, that you run, that an instance gets spun up every time a function call is invoked, and then runs and then gets killed. When in fact, that's not correct, you know, oftentimes, probably practically all frameworks will keep an instance warm. So the next function invocation might run in an environment where the previous one ran. And therefore, if you left any sensitive data on the server, that might leak, you know, and due to another security flaw, you know, similarly with containers, you talk about sandbox escaping and breaking them out. So they do introduce some security risks, but I don't think those are the primary ones. The, the, the primary security challenge comes back to that element of scale. So it comes back in serverless to, again, vulnerable libraries or, or access to data, but doing that across, you know, just a sprawling and fast moving set of functions that anybody can deploy. So really, really, really what I would say is that all of those technologies, while you should care about their, their new introduced security risk, you really mostly, mostly should think about them at scale. And to think about, you know, how do you replicate that within also your existing staffing constraints?
14:23All right. Yeah. Well, I want to get to that, but you might, I mean, we haven't talked too much about containers. The one thing I do want to ask specifically about containers is, and to the scale question is, do you have a sense of, like, when you look at your customers, the number of, you know, if you're saying like, okay, you know, maybe in the, in the physical or VM world, you know, they were running this number of, I mean, not that it's a one-to-one comparison, right? But they're trying to manage this number of things. Now the container world they're managing, like, do you have a sense of what that scale difference is in terms of volume? Yeah. I think the number of, of images is oftentimes roughly 10 to one, sometimes even more like 50 to one as companies go from the monolith mindsets to the microservices. So typically it would only do that transition if you're 10 to one. And oftentimes you see as the evolution comes along, there might be 50 microservices and every microservice is kind of its own image, right? So it's kind of its own kind of a flavor type of a server that gets deployed. In terms of running instances, it's actually even far greater because in the, in the VM world, it still tends to be, even when you're elastic on the clouds and things like that, you still tend to use your servers for a longer period of time to beef them up. While the containers tend to be very purpose-built, much more elastically scaling. So they get spun up, they get spun down. So there it's not uncommon to see a hundred to one or 500 to one ratios in terms of how many, how many virtual machines, if you will, right? If you call it a container machine that's running an instance, a virtual machine that run. So it's definitely at least one and sometimes two or more orders of magnitude, more different machines. And it was already hard to deal with a number of VMs when we went to the cloud. So it's not like this was built on, on stable foundation. Right. Okay. And, and get, yeah. So getting back to the, the, the people part of it, I mean, where do you, in the organizational part, where do you think, or, you know, where should this security responsibility lie within an organization? I mean, we, you know, we talk about baking it everywhere, but like, I think the question is how much can, can you, can you rely on developers or should, you know, should developers have to be security experts?
16:25Right. So like, where do you, how, how do you see a modern security organization looking? Yeah. So I think, I think that's a great question. And I think a lot of, a lot of security organizations are, are shifting or changing the way they work. I find the best analogy is really the sort of system reliability engineers or DevOps automation type teams that got created. So what you want is you want an end state in which the security team sees themselves as a, is a governing organization that is responsible to, to being experts in the field and knowing what's right and bringing in tooling and automation and putting them in place. To help developers do the daily job. So, you know, when you think about DevOps, you think about a developer, you know, needing to use build and needing to, you know, log activities that they do and being on call and being responsible when, when one of the systems that they operate go down. But you expect the system reliability engineer to understand what it means to do high availability. You expect them to be, to, to put in place good tooling around, you know, indeed log aggregation and around dashboards and alerts. And, and then the developers are the users of it. So the same, the same flow, the same guidance should happen here in the security teams, which is the security teams need to be more service providers and guiders. And you see security teams in the likes of, if I give a shout out to like Auth0 or Segment or really a variety or one medical, a lot of them are shifting there. So they're hiring more engineers into the security team and those, those people build, sometimes literally they operate microservices to run it, but otherwise they think about building automations into the pipelines, building technology to make it easier for developers to do it. And then the developers, they need to adopt it. They need to accept the responsibility. And that's really the, the chase, right? And it's not an, unlike a very different chase to the one that is happening in the, in the world of reliability and safety.
18:30So a lot of, of similar lines and, and I guess, I don't know what the name is, but we're looking for like that security SRE type role as we evolve. I like that better than DevSecOps security SRE. DevSecOps is a tricky, it's a really, really tricky word. You know, it's a, you know, it's DevEverythingOps, but, but, but it is about security kind of coming into the fold of, of the DevOps movement. All right. And then finally, Guy, I think you answered this question, but I mean, I'm just going to answer this correctly. Maybe, you know, if you, if you have something else to add, like, like, like what can organizations, especially large enterprises do to keep secure going forward? Like, it sounds like organization is a big part of it, right? Without just kind of, you know, historically, like, like you said, locking down security, right? And making it a roadblock, but actually, you know, scaling, you know, or keeping secure, you know, keeping that security function fluid as, as everything evolves, right? Is this organized, as the organizational part, you think automation plus organization, is that kind of the. Yeah, there's kind of the, the tactics and the strategy. So I think on the tactical front, I think automation is, is your friend, you know, and you want to find security solutions that you can put into your pipelines, into your developers' hands that automate a lot of that activity, both for efficiency and to make it easy for developers. You want developer adoption, so you want, you know, you know, developers, there's, there's how much they care, and there's how much effort it is to use a security solution, and it needs to be, they need to care more than it is hard, right? You know, and then they would mobilize to act. So I think that's the, that's the low hanging fruit. That's the immediate thing is around find those, put those together, and focus on security hygiene, focus on vulnerable libraries, on vulnerable container images, on cloud configuration, focus on those elements, because those are the ones that, that can kind of come back and bite you the most. And then long term, think about your security team's location inside your org, can you affiliate them more with the engineering organization, think about, about the individuals and the competencies inside your security teams and how they're divided, make sure that there's enough.
20:31Understanding and affinity to, to, to, to the software engineering teams and ability to build tools, and to be, be a supporting entity, right, be an entity whose, whose job is not to say no, but rather to make the business and specifically the technology teams thrive. All right, great. Sounds like a great place to end. Thanks a lot, Guy. I appreciate it. Well, thanks for having me, Horne. Thanks for the questions. There you have it. I hope you learned something. For more information about Snyk, you can visit Snyk, S-N-Y-K dot I-O. And you can listen to Guy's podcast, the Secure Developer Podcast at, wait for it, thesecuredeveloper.com. Easy enough. For more information about Pivotal's broad suite of products and services for building and managing cloud-native applications, as well as, I should note, some of the automation hygiene we talked about in this, in this podcast around making sure components and stuff are, are up to date and patched in a timely manner. You can check us out at Pivotal.io. If you want to know what I think is a really interesting user story, Google Pivotal Wells Fargo. And you'll, you'll probably, some of the top results will be, uh, uh, some stories about how Wells Fargo is updating and repaving its, its, its platform on a regular basis. I think one or one or multiple times a week at this point. Um, and you know, it's an interesting story about, uh, how you can automate security in this, uh, fast, fast moving world. Um, and then, anyhow, if you like this podcast and you want to keep up with more content on all things, let's say digital transformation, but, you know, educational stuff, cloud native, whatever you call it, without, without too much of a vendor spin, you can check it out. Check out the home of this podcast, which is Pivotal.io slash intersect. That's Pivotal.io slash intersect as in the intersection of business and technology. So thanks for listening.