DevOps Chat: Container Security and More with StackRox’s Ali Golshan

Security has many faces, which is why it’s so difficult to implement effectively. Each environment is different; each security solution is different; the needs of each organization is different. That’s why, as Ali Golshan, StackRox founder and CEO Ali Golshan put it, security has gotten a bad rap.

Golshan and his company are approaching security from a more DevOps-focused view, providing the necessary tools to enable DevOps teams to include security throughout the entire process. In this DevOps Chat, he and I discuss the many facets of DevSecOps, container security and more.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat. Today’s chat is a little DevOps, a little security, a little containers, little bit of everything. Happy to be joined by StackRox founder and CEO, Ali Golshan. Ali, welcome.

Ali Golshan: Thanks for having me.

Shimel: And, Ali, I think I mispronounced your name. It’s “Golshan.” Correct?

Golshan: Correct. Yes, thank you.

Shimel: Cool. I try to do it right. So, Ali, let’s start with the obvious, though, maybe some people out here have not yet heard of StackRox, so, before we dive in, just a quick sorta elevator pitch so they have some context.

Golshan: Sure. We started StackRox three-and-a-half years ago. The premise for the company was we saw a couple of major shifts in the industry. One happened to be the introduction of containerization and microservices, which is a sub-effect of this larger trend that we’ve been seeing, which is application security and development becoming full product life cycle, so ensuring that you can cover security and compliance and requirements from build to deployment to runtime. And containers provided, really, a great packaging and a construct for building applications and microservices.

And then the second part of it is is that, when you look at this model, we realize that there’s really three fundamental things that are disrupting a $30-billion security industry. This is the whole notion of a full product life cycle needing to be automated. It’s immutability and ephemerality. And, because you can’t forklift traditional security solutions and deal with these three constructs, we decided to go after solving this much bigger problem for what we like to see is for the future of cloud.

And where we started was containerization just as the fundamental building blocks. As time and market has progressed, we’ve progressed with it, which is focus more on things like APIs and orchestrators and managed cloud environments, but very much with kind of a host-application-centric view of the world. We’re not a network-based tool. We’re not a log-ingest based tool. We tend to focus a little bit more on security automation, detection, and creating a multifaceted risk view of your environment, specific to containers and microservices.

Shimel: Got it. So, you know, there’s a lot in there and we’ll come back to StackRox maybe a little later in our chat today, but I wanted to – let me hit on a couple of things you mentioned. So the first thing is this whole idea of cloud-native, container-native. You know, when we first saw the shift to the cloud, the security industry’s response was what some analysts called “cloud-washing” existing security solutions. So they took their existing security solutions and they said, “Okay, now it could run in the cloud too. It’s a cloud security solution,” but it really wasn’t. It was a on-prem security solution moved to the cloud. It wasn’t cloud-native and it really was a little bit of a round peg in a square hole.

I think we’re seeing the same thing when we talk about security solutions built or trying to provide security for containerized applications. Right? What’s involved? Can you – you know, I don’t wanna coin the phrase, but can you “container-wash” an existing security solution and make it a container security solution, Ali, or do you really need sort of container-native-designed security?

Golshan: To your point regarding traditional cloud environments, I think that was a smaller chasm, where security companies had to cross, because that original movement was a little bit more about virtualizing your environment. So there was still some kind of applicability of running things like WAS or endpoint solutions, to be able to broaden your security posture to the cloud. Obviously, the fundamental problems we saw were created were around how do you automate and provision workloads and then the nature of those workloads remaining. Those were kind of – the new capabilities in the cloud were actually the pieces that created gaps for security.

So, if you then think about that and expand that further, the capabilities and designs for containers are even kind of another order of magnitude different than traditional. It’s not just virtualization and then outsize your boundaries. It’s virtualization; it’s microservices, every function broken down into a particular service; controlling it end to end. So, if you think about that there’s a large portion of the security industry that doesn’t even look at some of the most critical components of this process, which is the build and deployment. Building constant context there. Building declarative policies from that environment and then using it further. So I think that’s one of the major reasons we don’t see the applicability of traditional security solutions, even more so in containerized environments.

Shimel: Yep. I mean, Ali, I agree with you and I think that’s why, frankly, a lot of what is today passing for container security seems to be people doing vulnerability scans of containers or, as I think I had spoken to you about the last time we chatted, you know, network IDS for the container. It just doesn’t – it seems very much square peg, round hole. And I’m not saying you don’t need vulnerability management, whether you’re in a container or not, and I’m not saying you don’t need intrusion detection, whether you’re in a containerized environment or not. But to say that that is, quote unquote, a “container security solution” seems just pushing it and just trying really hard to sell.

But wanted to come back to another thing you mentioned in your opening remarks. And that was around this whole idea of not only are we living in a containerized age, but we’ve seen the rise – and I don’t wanna say the dominance of – but, you know, the whole CI/CD software factory pipeline model of which DevOps is an integral part of and we talk about shifting security left into the software development life cycle. And this is yet another way that traditional security has to give way to how things are done today, so how does that influence or how does that play itself out, in terms of StackRox?

Golshan: The way we think about that is, if you think about who were the first companies who moved towards containerization and microservices, they were all companies that needed to deal with massive scale, building velocity in their development and to the offerings they have for their customers. And, as a result, they realized that kind of traditional model of building and deploying and managing was just not sustainable because it wouldn’t scale with the human element. So this notion of DevOps, and even containerization as a result, were really tools and methods for companies to be able to increase their level of automation and sophistication as to how they managed and run their infrastructure.

So the way we look at this is is that, also, it’s the same reason why a lot of those first movers build their own security models around this environment ’cause nothing like it existed. So we see security kind of mapping to the same model, which is, if you think about it, things used to be a little bit more around a model of batch process, respond, do analytics, take those sorts of options. And, again, the way we look at this is is that what containers have done is break that fundamental workflow. That fundamental workflow isn’t kind of “Build something. Check. Build. Check. Build. Check. And have all these gating factors applied by security.” It’s a lot more fluid now. So, as a result, security has to kind of integrate into that whole workflow.

And this is one of the big things we talk about, which is is that the reason you can’t take traditional security solutions and apply ’em here, it’s not just the form factor of what they’re applying to, but it’s also the entirely new workflow that’s been created by DevOps and these types of environments that impact how a security tool should run. Because it’s not just tying it to a form factor or choke point. It becomes more of a service mesh – not to borrow the word “service mesh” from kind of the service mesh project, but that’s why it lends itself very well. It’s a number of services integrated across the process and then, as you automate these processes, they become force multipliers for each other. That’s how DevOps works and that’s how security should work as well. You can’t break that workflow model just because your security tool.

Shimel: Agreed. And you’re using the term “workflow model” and I think that’s a great descriptor of it, but, you know, a lot of goes back – and, again, part and parcel with DevOps – a lot of it goes back to the whole sort of Lean IT, based on Lean manufacturing. Sort of, it really is a factory pipeline kind of workflow model. And, when you think about it, the fact that, all this time, we’ve always kinda just stuck security on at the end, at the end of the packaging, so to speak, and then wondered why it didn’t work so great. It’s kinda obvious when you look at it that way, isn’t it?

Golshan: No, absolutely. I mean, that’s a interesting analogy, right? If you think about it. If you have kind of a industrial environment and you have manufacturing, if you move from a manual workflows to robotics and automated work flows, the sort of security you apply is gonna be very different – how you look for bugs, how you look at, for example, applications. This is a good analogy because it’s a very indicative kind of model of what the current industry’s going through.

Shimel: Mm-hmm.

Golshan: So I’ve become a big believer that you can’t – this is where I think security goes wrong, trying to cover too many things at once. If you have a completely new emerging model, like containers and microservices and DevOps, it’s okay to say that our security or our approach deals just with that particular area. And, as small or as big as it may be, it’s important because it adds credibility that you actually understand what it fundamentally is built from and what it’s doing ’cause, if you say anything other than that – “Well, no, mine can cover network and end points and VMs and containers and Lambda.” – well, that’s just a lot of the reasons why the security industry got the bad rap it did. It’s just things fundamentally work different.

Shimel: Agreed. Agreed. So, Ali, I think we’ve done a great job here, in the first ten minutes or so, of laying out these sort of macro-factors that are affecting not just the tech or even just the security industry, but the – it’s really affects the whole world because we’re all – every company’s a software company now. And so this really has worldwide bedrock kind of effect.

But let’s turn back to StackRox, right? Full circle back to the beginning. So how are all of these things manifesting itself in –

Golshan: Yeah, so the way we look at it is –

Shimel: – in what became StackRox?

Golshan: – is have one solution that has two modules to it that interoperate. We have the StackRox module that covers build and deployment and StackRox that covers runtime and production. And the way we look at this entire flow is very basic – on one side of the equation, you get to look at all the static and declarative information and you get to use it to say what things should be able to do, and then, any time you run it, be it in deployment, QA, or production, you get to learn from that application more and more and see what it actually can do.

So our mission is really bridging what it should do versus what it can do. And the reason, for us, the automation part of it is a big part of it is, you know, as companies mature their overall workflow, they will have additional tools that are gonna be provided by their platform providers, by their cloud providers. As an example, you touched on vuln-scanning. Absolutely everybody should do vuln-scanning, but, more and more, we’re seeing it cloud providers and platform providers provide it, so the key there is not to provide vulnerability; it’s to be able to do vulnerability management.

And the way we look at vulnerability management, it’s either being able to provide the customer the scanner or ingesting the data from all the scanners and then helping them prioritize it – “Where is this running in production? In production, what services are accessible by this?” So, if you have a low vulnerability that is running in a production environment, in a mission-critical app that is exposed to the Web, it should be valued higher than a high vulnerability that is running in dev in a closed-off EPC that has no access to any other services.

So context is what helps you prioritize, but it also flows the other way. So, in runtime, if you’re doing detection, it’s important to understand, if an attacker, for example, shelved and broke into a – broke out of a container, grabbed some tokens or credentials, you wanna be able to go back and look at the, for example, the secrets that are being managed through the orchestrator and see where else those particular credentials or secrets are available, where else that deployment has happened.

So, if you think about it, on the left side, you get a lot of really great insight. On the right side of the process, with the runtime and production side, you can make use of those to build very good boundaries and gating factors, and that naturally reduces your attack surface. So, as you feed this information back to the build and deployment, remove credentials or privileges or tools that are unnecessary, you’re inherently making your infrastructure and applications more secure. And, as a result, we have a much better landing zone for what we apply detection to. We don’t have to detect everything; we know where the weak points or where the gaps are in the system, to focus our detection.

So that’s kinda how we think about the overall StackRox product. Give the customers, especially the build and deployment and dev teams, the right security, auditability, automation tools on the build and deployment side, and then give the right runtime detection, alerting, response, forensics, and enforcement on the runtime protection side, for security folks.

Shimel: Excellent. And we’ve got a few minutes left here, Ali. I wanted to – for people who wanna get more information about StackRox, is it stackrox.com? S-T-A-C-K-R-O-X?

Golshan: It is. Yeah. We have all of our information on our website and we actually offer free risk assessments using one module of our product, where a customer can just grab it and understand much better as to what they’re dealing with when it comes to their container infrastructure.

Shimel: Okay. Let me come back one other thing to you and, you know, the proverbial “Let’s see your roadmap” slide, but I don’t really want you to show me your roadmap. But what do you think is next, not only for StackRox, but as a result of this macro environment that we’re living in? What’s the next shoe to drop here and how do StackRox sort of – I’m sorry about the noise there – how do StackRox respond?

Golshan: Sure. I think it’s a couple of things. One is we’re seeing more maturity across this entire stack, so we’re seeing convergence around orchestrators; we’re seeing kind of the standards around runtime engines being built; we’re seeing how public cloud providers are consolidating certain services and making other services much easier to use. Perfect example’s all the efforts around, for example, Kubernetes, between AKS, between EKS and GKE.

So, when we look at these trends, it shows a couple of different things. One, not only are the containers different, but the entire attack surface is going to look very different, so the way you approach this world is gonna look very different in the future. We’re not gonna make the same mistakes we did with traditional security, which is we’re not gonna make the host overly exposed with a lot of user accounts and credentials and privileges and tools and packages. So we think that that host will obstruct the way and the orchestrator will become kind of a new cloud operating system, with APIs.

And, as a part of that, you’re gonna end up seeing a lot more complexity, so, as companies get more comfortable running applications as microservices, more containers, better grasp of the orchestrator, they’ll get more comfortable running more complex operations and applications on top of it. Naturally, that comes with maturity. And once you have that, you end up going from kind of what right now is, which is very early stages of this ecosystem, which I would consider to be low entropy, to a very high entropy environment you’re gonna end up seeing.

As a result of that, the way we see security being built is, one, that’s why it’s very important to focus on automation, integration, and the workflow, but, secondly, we see security having to be built in cloud native as a form-factor-agnostic model, meaning leverage the existing frameworks to – if it’s collecting data, for example, from the system, use, for example, things like the extended Berkeley Packet Filter to use that. If you’re running on Amazon or Google, you can use things like Pub/Sub or Kinesis.

So it’s building more modular, programmable, and pluggable architectures, versus building a binary that deploys in a container and then you replicate that container against a bunch of hosts. It’s about building a sensory model that can understand different environments and make sense of them, not single agents that unilaterally take action, because, as complexity, heterogeniality grows, naturally, there’s gonna be a lot more gray area, as far as use cases go. And that’s where you run into the old problem of alert fatigue, noise, false positives, and then, eventually, you end up with 50 security solutions.

Shimel: Excellent. Excellent. Well, Ali, we’re about out of time, but I gotta tell you, man: I love this chat. This was great. I’d love to have you back on the –

Golshan: Yeah, same here, Alan.

Shimel: We’ll dive into some more of this stuff. Good stuff. Ali Golshan, cofounder and CEO of StackRox, here on DevOps Chat. This is Alan Shimel. You’ve just listened to another chat. Have a great day, everyone.

— Alan Shimel