Guest: Stephen Giguere
Company: Bridgecrew
Show: Let’s Talk

Ask any developer and they’ll be quick to tell you that container security is very different from traditional IT security. Stephen Giguere, developer advocate at Bridgecrew, believes it comes down to mindset. When companies make the migration from monolithic to microservice architecture, it’s a change that IT and security have to contend with. Along with that migration, you’re also having to move to new languages and technology stacks. On the subject of languages, Giguere says, “The use cases and abuse cases are far more known in something like Java or even C++ or C#. Now we’re rewriting everything in Go or in Rust or in Python, and we’re packing them all up into little pieces, which makes the interconnectedness hard to really understand from a security perspective.”

It’s also important to understand the supply chain because you’re assembling pieces, like Lego building blocks, into applications. Some of these pieces you’ve written and some you haven’t. That can be a problem.

That supply chain is a very important issue. Giguere states, of the traditional application release, “We did understand the supply chain. When we wrote the code, and we compiled it, and we released it, there were potentially third-party elements that we were bringing in and we could vet those because they went through a process.” With microservices, Giguere indicates that we are, to an extent, giving control over to the developers and that, with DevOps, Ops is now part of development. Giguere adds to this thread of thought, “Look at Docker’s original marketing mantra, ‘Build once, run anywhere.’ In order to build something as a container, you’re taking on a lot of responsibility that developers don’t realize that they’re doing, they’re involving potentially up to 80% open source in their own code.” Developers take a kind of miniaturized version of an operating system and pack it into a container. By doing this, developers know if they can run it on their desktop, it’s always going to work.

But Giguere poses the question, “What are the security ramifications of doing that?” Now the supply chain starts with the developer and isn’t being siloed off into ops and security. Giguere would argue that “Most organizations really do not understand the supply chain involved and all of the intricacies that are surrounding it.”

But there’s a cultural shift happening. Giguere points out that events like KubeCon include a large number of security talks now, which means the idea is gaining serious traction. To that, Giguere says, “I think, at the very highest level, where culture begins, that security understanding is beginning to trickle down and there is an accountability that developers understand.”

How does a company like Bridgecrew help customers secure their workloads and environment without overwhelming them with complexity? Giguere says, “What we’re trying to do is not necessarily force some form of tool from the highest level onto developers and DevOps teams.” With that in mind, Bridgecrew is trying to embed security, almost invisibly (if not frictionless) into the already existing environment, whether that’s GitHub actions, VS Code on a developer’s desktop, or built into the cloud. With this, Giguere says, “It’s all part of the same world. And once we succeed in doing that, I think that’s when we’ve achieved this kind of DevSecOps reality.”

Of course, with modern security comes the idea of chaos engineering. Although not new, Giguere believes, “Using infrastructure as code really lends itself well to chaos engineering, because you can now destroy something and actually push a button and run out to redeploy and it’s back to the state it was in.” He adds, “That’s a great practice that can be a kind of social event to bring together all of these silos to see, all right, well, what, if it didn’t work, why didn’t it work? What happened? Did we recover? Did we need to push the full reboot to redeploy everything? Or, did we survive gracefully? And how can we credit those that made that happen?”

Bridgecrew specializes in infrastructures, code, and misconfiguration detection and remediation. That’s their bread and butter. According to Giguere, “A lot of the breaches that make the news, they’re not necessarily vulnerabilities, but they are more a misconfiguration or a series of misconfigurations. If we can find those in a shift-left way, then that’s really great, but let’s not discount the vulnerabilities, not at all.” He also adds, “When you just scan for container vulnerabilities, and if you do that at scale, so you connect to a registry and you scan everything that’s there, you can be flooded. It can be too big of an elephant to eat, essentially.” In the end, it all comes down to prioritizing vulnerabilities. To that, Giguere says, “It’s one thing to know you have a vulnerability. It’s another thing to know that it’s in an image that is connected to a load balancer and that load balancer has exposed ports.”

The summary of the show is written by Jack Wallen

Here is the rough, unedited transcript of the show…

Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya and welcome to [inaudible 00:00:09]. Today we have with us Stephen Giguere, developer advocate at Bridgecrew.

Stephen Giguere: It’s amazing to be here.

Swapnil Bhartiya: So, first of all, Stephen, it’s great to have you on the show. And since today, we are going to talk about the new announcement that is coming from Bridgecrew, which is container vulnerability scanning. Before we go there, I want to understand from you, security kind of has become… It’s no longer an afterthought. It has kind of taken a forefront. Companies are talking about securities a lot, but when we talk about security in the container and cloud, the word is different from traditional security. If you look at a container, people pull a container from public repository, everything else, you don’t know what is in there. Most of the time people don’t know there will be hard links, there may be dependencies. So, you’re taking a lot of risks, you know? If you’re a company, you’re running something, which is valid in your own license that you’re using. So there are so many risks involved with that. So let’s start with the problem area that, how do you see container or cloud native security as different from traditional IT?

Stephen Giguere: Well, I think it’s just the way things are packaged, for example, in containers. The idea of moving to containers and moving to cloud native, and even moving to something like Kubernetes, encompasses an entirely new mindset. Now, if you’ve done this, your organization is probably re architecting, what was largely maybe a monolith, into a microservice architecture. So that is a change that your IT and your security are already having to contend with. And that’s just that alone. If you’re doing that, you’re probably doing it so that you can make the best use, financially and architecturally, out of cloud services. So that’s another element of security that you’re having to contend with.

Now in the midst of all of that, this move has made a… is meant that you’re moving to new languages. So you’re moving to new technology stacks. So, moving away from Java, which is a known quantity, even in terms of security, it’s easier to secure Java because there’s just more of it out there. The use cases and abuse cases are far more known in something like Java or even C++ or C#. Now we’re rewriting everything in Go or in Rust or in Python, and we’re packing them all up into little pieces, which makes the interconnectedness hard to really understand from a security perspective. And, then they’re being pushed into registries and- Docker, for example- as functional units, and then reassembled like Lego building blocks into applications. Some you’ve written, some you haven’t. So understanding what the supply chain is surrounding that, is the problem

Swapnil Bhartiya: You used the term supply chain. And I love that term, especially if you talk about open source, as you also said, there are so many dependency, so many things that you are pulling in there. Do you think that companies do understand that they are not talking about, as you said, the whole model, it’s very, you get a binary, install it in your… You’re talking about, did you understand software supply chain at all? Because, if you don’t understand this sort of supply chain, you can not even address the problem there.

Stephen Giguere: Exactly right. And I think we did understand the supply chain. When we wrote the code, and we compiled it, and we released it, there was, there potentially were third-party elements that we were bringing in and we could vet those because they went through a process. Now, because we’re giving control to an extent to the developers. The whole DevOps movement means that Ops is now part of development. Development is creating the environment. Even if you look at Docker’s original marketing mantra, let’s say “Build once, run anywhere.”

In order to build something as a container, well, you’re taking on a lot of responsibility that developers don’t realize that they’re doing, they’re involving potentially up to 80% open source in their own code. They’re taking kind of a miniaturised version of an operating system and they’re packing it into this container because they know if they can run it on their desktop that when it enters into a registry and it moves through tests and into prod, it’s always going to work. And that is a huge relief for them, but the emphasis on, well, what are the security ramifications of doing that? Because now the supply chain is starting with the developer. It’s not being siloed off into ops and into security anymore. So, I would argue that most organizations really do not understand the supply chain involved and all of the detail intricacies that are surrounding it.

Swapnil Bhartiya: How much cultural change you’re also seeing where companies, as you said, rightly, that they still don’t understand the supply chain, but are you seeing any trends where companies are actually, even, embracing? We do love to talk about DevSecOps, DevOps, but are companies embracing these?

Stephen Giguere: I think they are embracing it. It was… DevSecOps was a bit, I don’t know, a bit finger in the air. Like, what does that actually mean? Is it truly a culture like DevOps was, or is it… I once described it, like, last year as a security’s self-penned invitation to the DevOps party. We wanted to have a portmanteau, as well, that we could leverage to make sure people thought about security. But I think now, if you look at the density of talks at events like KubeCon, and seeing how many are now about security, it’s definitely gaining traction. And I think at the very highest level, where culture begins, that security understanding is beginning to trickle down and there is an accountability that developers understand.

Swapnil Bhartiya: I will go back to your earlier point, once again, taking the monolith, breaking it down into smaller services. I think it’s easier to deal with one monolith versus dealing with a lot of microservices, especially if you look at the Kubernetes world, things get complicated very quickly. Things are complicated quickly, already. There are so many knobs, there are so many components, which also, you know, kind of becomes intimidating. And then we already have kind of resource crunch. It’s hard to find people who are very well-versed in these technologies. So how do you, as part of either Palo Alto or Bridgecrew, look at this problem, the complexity, because automation is kind of key in today’s world. So how do you look at it to make it easier for the companies, even if they don’t understand supply chain, even if they’ve struggled with these paradigm shifts, their workloads are still secure.

Stephen Giguere: Right, exactly right. So what we’re trying to do is, not necessarily force some form of tool from the highest level onto developers and DevOps teams, right? Actually, I’ve been doing this for long enough that I’ve been a part of organizations that have made that mistake. Organizations can spend thousands to millions on a tool that never gets rolled out because, simply, developers outnumber everyone. And if they don’t want to use it, it’s not going to end up happening. What we’re really trying to do now is embed security, almost invisibly, if not frictionless, into the environment that already exists, whether that be, GitHub using actions, whether that’d be VS code right on the developer’s desktop, or built into the cloud provider that already exists and would try to provide actionable data that is understandable by developers by Ops yet held accountable by security, into the environment that already exists. So it feels just like you’ve got a compiler error having a security error. It’s all part of the same world. And once we succeed in doing that, I think that’s when we’ve achieved this kind of DevSecOps reality.

Swapnil Bhartiya: Talking about DevSecOps, it could be seen as trickle up or trickle down. And you also said businesses are spending billions of dollars. We’re also seeing the role of chief information security officers, or CSOs, how much do you see that role has influenced how many companies do have those roles and how do they really coordinate where… It’s not, you know, even if… The funny thing is, even if we do talk about breaking down those silos, there are still silos, right? So talk about that, also.

Stephen Giguere: It’s funny you say there are still silos. One of the areas where one of the biggest silos exists is within security, or independent of security, Ops and dev, security is trying to work their way into, into DevOps. But one of the moves into containerization and the combination of dev and ops is an inadvertent combination of AppSec and InfoSec. Security, unfortunately, for the most part, hasn’t caught onto this, and security still has an InfoSec team, thinking they’re still responsible for infrastructure, and an AppSec team that is looking for CDEs, and cross-site scripting, and injection. And yet, the applications are being delivered to them, in combination. A container has the possibility for all of these things, all in one piece. And the reality is, security needs to collaborate better to understand what does the attack surface really look like? And we need to work together on that.

So that is one silo that still exists. The other silo, I think, which is probably the largest one, and this is where we need to accomplish DevSecOps, cause as much as we’d like to believe it, the security people like us, we’re still not quite going out for going out for a beer with DevOps. We’re not integrating socially and culturally with these teams, such that we understand them and they understand us. And I think that culture change is going to go a long way to understand how they think about it, what incentivizes them, and what, how those incentives might potentially be a compromise to our security posture.

Swapnil Bhartiya: Right, and one thing that we, I think, where all these people in different silos, they do come together is when a lot of companies start pressing practicing chaos engineering, where they break things and then suddenly… So how much total do you think, chaos engineering plays in not only security, but also to kind of break these silos, and bring everybody, because actually, you know what? When a company is into trouble, something breaks, then everybody comes together, same room, trying to figure out whose fault it was and how to fix it. So, so talk about chaos engineering a bit.

Stephen Giguere: Yeah, I think you’ve hit the nail on the head there, chaos engineering isn’t new. It’s a rebrand of something that is incredibly old, but the fact that this microservice in cloud-native environment and provisioning things, using infrastructure as code really lends itself well to chaos engineering, because you can, now, destroy something and actually push a button and run out to redeploy and it’s back to the state it was in. And it, that should work. So if it doesn’t, that’s a great practice that can be a kind of social event to bring together all of these silos to see, all right, well, what, if it didn’t work, why didn’t it work? What happened? Did we recover? Did we need to push the full reboot to redeploy everything? Or, did we survive gracefully? And how can we credit those that made that happen? And I think that’s a great, great point you’ve just made, about chaos engineering. I think a lot of companies, like Netflix is famous for pioneering it, and a lot of companies really look to them for leadership, but it’s difficult to make it happen smoothly. And there’s a lot of information and books around that and a lot of professionals and SREs that can help you along the way, but it’s not as prevalent as I would like it to be. So if the people that are watching this podcast do look into it, it’s very useful, both technologically and culturally.

Swapnil Bhartiya: Now, let’s address the elephant in the room, which is the container vulnerability scanning that you folks are announcing. Tell us a bit about that.

Stephen Giguere: Sure. Bridgecrew specializes in infrastructures, code, and misconfiguration detection and remediation. That is kind of our bread and butter. It’s what we do. This can be Terraform, it can be cloud formation, serverless framework, Kubernetes, YAML, Helm, any of those things. We’re for what people are doing wrong. And the reason we’re doing that is because as people get better at writing code, and as code and application are broken into microservices, finding those traditional CVEs is difficult. And in fact, if you look, a lot of the breaches that make the news, they’re not necessarily vulnerabilities, but they are more a misconfiguration or a series of misconfigurations. If we can find those in a shift-left way, then that’s really great, but let’s not discount the vulnerabilities, not at all.

And so what we’ve added is the ability, when we’re analyzing a GitHub repo, looking for infrastructure’s code, this can be YAML files or Helm, and if they are, more often than not, there’s also a Docker file there. If we’re looking at the Docker file, not only do we scan the Docker file because it has its share of, let’s say, bad practices that we can look for, but we can now also build the image in a sandbox and then scan the image itself. Thanks to a collaboration between Bridgecrew and Palo Alto Networks. We can determine what CVEs are present in the image in the base image. And we can aggregate all of that in combination with infrastructure’s code, misconfigurations, all under one roof.

Swapnil Bhartiya: If we look at Bridgecrew, you folks, more or less focus on infrastructures code, which, where you don’t change things too much. That’s the whole point of it. And then, now you’re talking container, which, containers come and go. So immutable versus ephemeral. So talk about, of course, you have to be where your customers are to help them, but talk about, why are you shifting focus to, not shifting focus, but also increasing focus towards container security as well?

Stephen Giguere: Okay, now, I can understand that. So there’s a real strength in being able to combine the infrastructure’s code misconfiguration with the container vulnerabilities. The reality is, is that, when you just scan for container vulnerabilities, and if you do that at scale, so you connect to a registry and you scan everything that’s there, you can be flooded. It can be too big of an elephant to eat, essentially. Now prioritizing vulnerabilities, be that container scanning, or let’s say, even traditional SCA, software composition analysis. It’s one thing to know you have a vulnerability. It’s another thing to know that it’s in an image that is connected to a load balancer and that load balancer has exposed ports.

This is the information you can get by scanning code for misconfigurations. And you can see the context within which these container vulnerabilities exist. So when you see everything together, suddenly you realize, okay, hold on here, this is a deployment I really care about, this as a load balancer. Checkov, for example, or Bridgecrew has flagged that there is an exposed port on port 80, but I also have an image connected that I can see is out of date, and it has several known vulnerabilities. I can use this, and we can grow the product as well, but not only, we can use what we already have now to combine those two perspectives. And this is the true integration of apps i can InfoSec together and really leveraging them to help us prioritize.

Swapnil Bhartiya: Can you also talk about, whether we talk about Palo Alto Network or Bridgecrew, how are you offering these, the container- label scanning features functionality to users, are there different services, products, or they get it as part of the whole package?

Stephen Giguere: Well, I’ll look at it from the Bridgecrew perspective, because from the Palo Alto perspective, Prisma is a whole other animal. Bridgecrew is integrating the container scanning as part of its standard offering. So you can create a free Bridgecrew.cloud account, you get full access to everything. I think it’s 15 days. So you can, I think as of next week, all of this functionality will be integrated, and you will see that as you integrate a GitHub account, then all of this information will just simply suddenly start to appear. There’s no real buttons to push in terms of ease of use. It’s incredibly simple and there’s even mechanisms in place to automate poll requests. So all of that is integrated out of the box.

But as you may or may not know, Bridgecrew’s foundation, at its core, is an open source package called Checkov. Checkov actually can do the same thing. It already has options that we don’t really talk too much about to utilize the twist CLI from, from Prisma and scan container images, even on the desktop, even on the command line. Then that is kind of what’s happening in the background when you run Bridgecrew. Now you can do this on the command line, and that can be done for free, or you can do it via the Bridgecrew.cloud platform.

Swapnil Bhartiya: Stephen, thank you so much for taking time out today, and talk about not only the container vulnerability scanning capabilities, but also security in the cloud-native container world in general. Thanks for your insights today, and I look forward to our next conversation, thank you.

Stephen Giguere: No worries. It’s been a pleasure.