Today’s guest is Guy Eisenkot and he joins us to talk about how culture is a critical aspect of shift-left security and DevOps. Guy is the Co-Founder of Bridgecrew, a tool that solves the talent shortage gap for building secure infrastructure in the public cloud. Our conversation begins with Guy giving some insight about his path into development and security, and he details his training in the Israeli military and subsequent experience building security tools for the civil market. In today’s discussion, Guy gets into how the security responsibilities of platform and infrastructure teams have changed as well as what security teams are missing when it comes to DevOps security. He shares his insights about how security and DevOps teams have been able to synchronize and also gets into some of the biggest pitfalls in DevOps as far as cybersecurity best practices. We explore how infrastructure as code could be the driver of two paths, one leading to a dangerous amount of freedom, and the other, to the standardization necessary for automation. Toward the end of our conversation, Guy weighs in on the parts of the industry that show maturity as far as DevSecOps versus those that don’t, and he also talks about how the OpenSource tool Checkov helps solve poor security configurations during resource deployment. Tune in today and get ready to take some notes!
“We were learning what are the limitations of these orchestration capabilities, and how we can take legacy infrastructure and promote it into a modern stack. And that's where we saw DevOps is practically everywhere.” — @guysenkot [0:06:28]
“Bridgecrew essentially builds developer tools that help people from engineering organizations build secure infrastructure in the public cloud.” — @guysenkot [0:12:19]
“Where both security and DevOps come together for me is when you realize that in the cloud both of these buckets of initiatives are sitting on the same infrastructure.” — @guysenkot [0:20:38]
Links Mentioned in Today’s Episode:Secure applications from code to cloud.
**NOTE: Generated via ML. Expect crazy stuff to be translated that may have never actually been said by the host or guest :-) ***
[00:00:00] ANNOUNCER: This is the Cloud Security Today Podcast, where leaders learn how to get cloud security done. And now your host, Matt Chiodi.
[00:00:31] MC: When you hear the term shift left, or DevOps security, what's the first thing that comes to mind? Well, if you're like me, you think about automation and probably security tools. What we're going to cover today is not only why you should be moving towards shift left security in the cloud, but also how to get started. Get ready to take some notes, as Guy Eisenkot got from Bridgecrew, joins us to talk about how culture is a critical aspect of shift left security and DevOps.
[00:01:01] MC: All right. Well, thank you for joining us for today's podcast. Excited to have Guy on the podcast today. Guy is previously, I think, we would call you the founder or one of the founders, of a company called Bridgecrew. So, Guy, thanks for joining us today. I'm glad to have you on.
[00:01:18] GE: Happy to be here, Matt.
[00:01:19] MC: Awesome. So, let's just start by telling us a little bit about your background. I mentioned that you were a co-founder at Bridgecrew. Talk us about how did you find your way into DevOps and DevOps security? I’d love to hear about your journey. Oftentimes, we have who are listening to the podcast that are just starting out in their career and they see folks like yourself, and they're like, “Well, how do I align my career to maybe someday be in that position?” So, tell us a little bit about that.
[00:01:50] GE: I would love to. So, I’ll start the story with about 15, 20 years ago, I’m one of your classic ‘90s computer geeks, started with schoolwork, then some side projects gaming, and then really moved towards web development, messaging, technologies, worked around that in my early and late youth. And then I'm currently living in Israel, I spent some time in the States, but in Israel, we have mandatory army service. So, at the age of 18, after finishing my final exams, I was recruited into our intelligence department, a military intelligence department. And that gave me an opportunity at a very young age to work with some of the most sophisticated enterprise great technologies. And I think this is something that when you look at how the Israeli tech ecosystem has, and where's Israeli entrepreneurs, and even with developers, all kind of originated, you'd see that communal experience where at a very young age, you get access to some of the most complex technologies out there, enterprise tech.
This is like 15 years ago, we had the biggest data centers in the Middle East, that biggest DMC data center in the Middle East. So, an opportunity at a very young age to touch some of the most prominent technologies out there, and that's kind of a profound experience for me very early in my career. This army service incorporates both a lot of ad hoc challenges, and very strong problem-solving culture. So, you take a group of 18-year-olds that are motivated, patriotic, and you give them a mission. And it's not on the battlefield, it's on the technologic playing field, and then you just give him very high levels of freedom. And you see that with a combined culture of distributed our ship and very distributed responsibility module, you have the opportunity as a young person starting out with technology to initiate and innovate in places where you wouldn't naturally expect them.
So, I spent about five years in total, that includes officers training, and then a few years after that, even an additional role in one of our executive branches. And then, when I was 23, I got out and started out as a Junior Product Manager at a small early stage startup. This was around 2013. One of my virtual co-founders, Aidan Tendler and I met up through mutual friends and he had offered an opportunity to join the startup when they were just getting started. Startup’s name was Fortscale. They had, I think head think, a $2 million seed round, and we're just getting ready to start getting a product ramped up. And this is where – I think this is about 2011, 2012. This is where the emergence of data in our field really started to emerge. So, you had the first generation of endpoint security coming out, a lot of work that's getting done in in robust network telemetry analysis, and we build a product that analyzes machine learning, using machine learning analyzes telemetry from operating systems, and variety of networking appliances, to try to correlate and build models that could indicate potential intrusions into advanced systems.
So, I spent about four and a half years there at Fortscale. Eventually the company got acquired in 2018 by RSA security and that's where I had the opportunity to go together with our third co-founder, Barak, and was the Chief Architect into our sale, and essentially build out their machine learning based capability within a product line called NetWitness. It's their event management –
[00:05:14] MC: I remember. I remember knowing this.
[00:05:16] GE: Exactly, yeah. So, it's actually an amazing product, has some of the biggest deployments in North America. A lot of government work and it was their first time implementing some heavy-duty analytics in the system. We had a huge challenge bringing in a foreign technology into that stack. Can you imagine the length of complexity of going into a monolith and trying to do enterprise scale network analytics initially, in that time, and this is where we segue to DevOps.
One of our biggest challenges was still taking our machine learning algorithms that ran on a single server, usually a huge one, and then implement them into NetWitness, which was, I think, about six or seven-year-old technology back then, and tried to make sense of it and make that scale and make that work for their thousands and thousands of customers. And we got acquainted to some of the magic of orchestration via technologies like Chef, Puppet, SaltStack, that were predominantly using in our state at the time and we just fell in love. This is Barak and myself, as we are rolling out the integrated module. We are learning about these robust technologies. This is about three, four and a half years ago and we're learning a lot at the process. We're learning what are the limitations of these orchestration capabilities, and how we can take legacy infrastructure and promote it into into a modern stack. And that's where we saw DevOps is practically everywhere. We saw it when we migrate our packaging and delivery stacks. And when we eventually shipped out a product into one of the biggest companies in the world.
[00:06:44] MC: I love that. That's a great background. You're right, when you were talking about the beginning at this amazing culture around startups and technology that has come out of Israel over the last one to two decades and it's interesting. So, you come from a development background, right? I heard you say that, that's really where you started and a lot of times when I speak to people who are in security, they are often not right from that development background. So, I guess the question would be, how does that shape maybe how you look at security, versus someone who maybe comes from a compliance or from an audit background, where they're looking at it very differently? I guess the other part of that question would be is, why did that lead you to then go and co found Bridgecrew? What challenges were you seeing?
[00:07:27] GE: Yeah, I think if you've referenced development, one of the things that initially come to mind is that we constantly have barriers of entry in our minds. When you think of a new programming language, of a new cloud provider that you haven't worked with in the past and new type of framework provisioning language, architecture, principle, these are all concepts, abstract concepts that we as product and development people need to constantly be conscious of. I think one of the things that I personally liked when I came into this in the civil market, not in military market, was the fact that there's so much good and collaborative information around cloud development, infrastructure development, and actually cybersecurity. There are so many people that have gone through the lengths of writing the playbooks, writing the books, writing the manuscripts.
In recent years, the conference culture, which I think is amazing in our industry, all of those eventually took something that was very abstract, high barrier of interest for me as someone who is not constantly based in the US and helped me getting in touch with those concepts. And specifically, when you look at DevOps, which has even a stronger lean towards an open and communal knowledge, sharing culture, I think that's one of the places where I was most impacted by. It was much easier for me to learn orchestration frameworks in DevOps than it was to learn anything else, because they were all founded by people who had knowledge sharing, and communal aspects when they created these frameworks.
[00:08:53] MC: That makes sense.
[00:08:55] GE: To the second part of your question, I think where Bridgecrew comes into the picture, as founding concepts, we came into this. So, Bridgecrew was founded in 2019. This is about a year after the acquisition into RSA. Barak, our technical co-founder, Idan. Our CEO for Bridgecrew and I got together about a year after the acquisition, started talking together and understood there's an opportunity in the market to do something together. And before we even knew, we build a product around cloud infrastructure and DevOps, we just had long, long, long conversations discussing the path that we had together in the previous startup, our learnings, pre and post-acquisition, and just tried to process those experiences together to recreate something that was a meaningful outlook on the market based on that profound experience we just had together.
[00:09:45] MC: We've talked a little bit about it, but what does Bridgecrew actually do? So, what problem does it solve for security and DevOps teams?
[00:09:52] GE: Yeah, so foundationally, Bridgecrew solves, actually a knowledge gap and a talent shortage gap. So, if you look at organizations that are going or have undergone cloud transformation, the most impactful trend you'd see is that there's not a lot of people today in the market that have built robust, cloud native environments. And there's more and more of them today. But if you look two to three years back, outside your Google, your Facebook, your Amazon, your Netflix, you didn't have a lot of talented developers that have built hyperscale, cloud native environments. And we were looking initially at a few options on how do we help companies that are either early or late stage, ramping up that workforce. How can we make those organizations transition into the cloud and in business scaling to the cloud, something that's much more secure and safe?
We landed on one big topic, which is cloud infrastructure, which you and I are very familiar with. We saw that one of the profound changes that are happening when you look at a cloud native environment, is that infrastructures become democratized. People that were used two, three, four years ago, to get infrastructure as something that's almost a necessity. Now, it's become the building block when you build an application. You can use a package service from a cloud provider. You can bring your own components from open source or commercial software and run it on publicly hosted infrastructure. But infrastructure has become something that every developer now has to either use and actually compose in their day to day life, or it becomes something that they have to incorporate as they write application code.
One example is one of our biggest customers is one of the biggest financial web applications in the US, they had tens of new hires entering every month into the workforce, and some of them have never actually developed on something outside a privately hosted infrastructure. They were accustomed to work with the VMware stack, or the Red Hat stack and, and weren't really familiar with some of the abstractions and ideas that you get prepackaged when you work with a public cloud provider.
So, we zoomed in on infrastructure as code and we identified that infrastructure as code is becoming a de facto standard for building infrastructure in the public cloud. And we decided that we'll build the tools that help developers that have very little knowledge of cloud and how to really build secure infrastructure in the public cloud, and make that as seamless and simple as possible for them. So, that's probably a long way to say that Bridgecrew essentially builds developer tools that help people from engineering organizations build secure infrastructure in the public cloud.
[00:12:25] MC: So, I know that from some of our conversations, that you've been thinking a lot about the security responsibilities of platform and infrastructure teams, how that's changed. It's funny, I was speaking with a customer, just earlier this week, this was a Cisco and they were saying that in their environment, they've realized that over the last two years, there's been this massive shift where the security team has actually been doing less and less when it comes to security. And he was very uncomfortable with that. So, you've been thinking about this a lot. What are you seeing happening with that whole dynamic?
[00:12:59] GE: That's interesting/ I haven't thought of the impact of the load on security teams with regards to this transition. I've always thought about this as a DevOps or an infrastructure engineering problem. But this becomes something that now maybe relieves some of the work for security.
I'm seeing for the last two years wide scale adoption of security by design is a design principle. And I think that's extremely important when you look at cloud native, because I think it took a while for AWS, specifically and other cloud providers to understand they have enormous intellectual assets, they have to share with the broader community. And for too long, the practitioners had relied on each other to formulate the best strategy for cloud infrastructure. And I think really, in the last two years, I've seen opinionated intellectual frameworks that are getting crowdsource, getting distributed, getting used by more and more practitioners, whether that be by product vendors, consulting services, the CPSs themselves, the copywriters themselves, all of them together, making this knowledge more accessible. And the immediate result of that is that organizations are dedicated headcount to ensuring that development organizations are building security by design.
I think when I tried to analyze the trends that I’ve seen in development trends and cloud infrastructure development trends, is that as this democratization of knowledge gets more and more dispersed, the role of infrastructure teams and platform infrastructure teams is getting much, much more important. I think that for myself, as someone who's both an observer and a player in the space, I'm trying to really figure out how these teams are working today, what are their biggest challenges? What are the problems they're trying to solve? How are they trying to implement things like zero trust, lease privileges, dry code, all of these best practices that they read about, how do they do them in practice? I think these concepts are foundationally, changing the way that infrastructure gets built and deployed. I'm constantly thinking of ways where these problems are getting decomposed.
[00:15:13] MC: I think that one of the things that I often very much hear also from security executives, as I talked to them is that, although they feel like, as I mentioned before, they feel like, it's not that their security responsibilities are going away, but they feel like the visibility they once had, the way that they could get very deep into, for example, if something was running, even in a private cloud, you mentioned VMware, Red Hats, something like that OpenShift, they could still do all the normal things they could do in the past to get visibility. But now with the shift to cloud, and especially those organizations that have gone down the DevOps path cloud native, those security leaders feel like that visibility that they once had, is gone, especially as things move into code.
If you're looking at this through a DevOps lens, what are some things that you typically see security teams missing when it comes to DevOps security?
[00:16:08] GE: It's interesting, and it ties back to your previous comment about how workload for the security team has changed. And curious to see if you've seen these two things, two things that like instantly come to mind, is one, lack of access. I think security teams were previously accustomed to have these broad intimate set of privileges and access especially into core infrastructure. This is bread and butter. If you can’t configure your own firewall or networking rules, what's the point of having a centralized sock or knock? And in the public cloud, it's just different, right? You need AWS access keys, and you have to get provisioned through your one login on your Okta in order to get access to those subsystems. That's one drastic change. Have you seen that as well?
[00:16:55] MC: Absolutely. I mean, I remember not trying to date myself here. But I remember back earlier in my career, let's just put it that way, where the security – I was on the security team, and then we worked extremely closely with the IT team, but there were no changes that were made in the data center without it coming through a formalized change request. We knew the impact if someone wanted to make a network change, a developer was proposing opening some port, we were able to fully review those before the change was made, we can look at the risk impact, et cetera. And now, when you look at who is running most public cloud environments, it's not security in it. It's DevOps.
[00:17:38] GE: It's not. Yeah. One other challenge that I think security teams are having more and more is, and this could be something that's not you giving this one other thought, but I think the lack of consistent logging is something that – it’s always a struggle, right? We haven't been able to get consistent logging for Windows for what, is it almost 30 years now? But the cloud makes it – just a CloudTrail, as an example, AWS audit log. It's a comprehensive log. It takes time to understand the quirks. If you're a security professional, and you've been doing endpoint detection, and you've been doing Network Forensics, CloudTrail is different. It has, I think, probably 30 different types of events, probably tens, if not hundreds of subtypes. It can get very complicated and very frustrating if you don't know what you're looking for. You don't just spit it out into an elastic or a Splunk and query it using free text. You really need to understand how each event ties into the other.
This is something that I think it's taking security some time to get ramped up. It'll take just as it took time to build a consistent narrative around logging for every other component in our IT stack. It's going to take time to do it for cloud as well.
[00:18:50] MC: I think that that is very wise. I think that one of the other conversations that I often have with security leaders, security practitioners, is they want to ship security left, right? It's obviously been a buzzword in our industry, shift left, DevSecOps, but they are often struggling with, how do they actually put that into practice? And we've talked about a lot how security and DevOps teams don't talk to each other, et cetera. So obviously, there's the culture piece of it, which we'll talk about in a minute, but how have you seen the teams that have done security and DevOps well, what does that look like? How did they actually start? Maybe there's some organizations you've worked with who didn't have that, and maybe now, they're moving towards that higher level of security. What does that process look like? Because I know so much of this is, there's always people process and technology. So, what does that look like from your perspective? What have you seen work?
[00:19:44] GE: I'll try not to over generalize. But if I take a step back and think of DevOps as like a core foundation of DevOps, I see them, most teams essentially looking at themselves as the teams that are enabling business growth. You want to be able to deploy your application into a new region, let's do that with minimal disruption. That's a good DevOps initiative, if you were able to pull that off. It means that you have a healthy stack, you've implemented the best practices, that architecture is one that enables you to get that type of job accomplished. And then if you look at security, you usually see the role or you usually perceive your role as someone who's in charge of preventing that disruption of anything that could affect the business.
So, whether that be adding safeguards or adding additional controls, you're constantly thinking of that prevention of that potential thing that's going to happen, sometimes at the end of the road. Where both of these two concepts come together for me, is when you realize that in the cloud, both of these buckets of initiatives are sitting on the same infrastructure. And if they use shared infrastructure, the magnitude of accomplishments and goals both DevOps and security can achieve. I think is fundamental, and it's a game changer.
Let's just go back to that last example. So, let's go back to CloudTrail. It's a great tool for forensics, both for your operational resilience to find the root cause of a downtime. But it's also great for threat hunting, if you know what you're looking for. So, if CloudTrail is properly logged, and properly parsed, and it sits in a neat schema where everybody can access it, everybody wins, DevOps wins, security wins, it's a win win. And I think as more DevOps and security teams understands they share infrastructure, and they share resources, that's where I've seen some of the biggest and most impactful initiatives for fast growing companies.
[00:21:40] MC: Prisma Cloud secures infrastructure, applications, data, and entitlements across the world's largest clouds, all from a single unified solution. With a combination of cloud service provider API's, and a unified agent framework, users gain unmatched visibility and protection. And for our federal customers, Prisma Cloud is now FedRAMP Moderate. To find out more, go to prismacloud.io.
[00:22:09] MC: You touched on this, when you said that, what DevOps is trying to do, DevOps is about moving fast and breaking things, right? And we're trying to move as fast as possible, maybe not purposely breaking things, but trying to get to that next through that next sprint, so they can release that feature, whatever it might be. And security, again, a lot of folks that are in security that grew up in security, are a lot of times from an audit background compliance, and their job is to protect the enterprise. I think you're right. There's the shared infrastructure, obviously, in the cloud, that they're both working under, but when you have seen organizations come together, what are maybe some things, I don't know if you have any specific examples that you've seen. But I'm curious, what have you seen, perhaps bring those two organizations together?
[00:22:57] GE: This throws me back to one early engagement. This is pre COVID. And I remember me and my two co-founders, we had this routine, where we would go back and forth between Silicon Valley and Tel Aviv and kind of use that time together to plan and strategize and we would meet some of our design partners. So, we had this opportunity to work with one of probably the fastest growing companies in the valley back then, IPO last year. And we were accidentally brought into a room where the application security team brought us in to see how they in DevOps, negotiate some of the initiatives they brought to the table.
So, application security team had some initiatives around vulnerability mitigations, and some configuration mitigations. And then DevOps came in to, show how their backlog looks like. And together with an additional executive in the table, we saw how that discussion plays out. And what I think we took from that meeting is a couple of interesting findings that we then later tried to incorporate even into our product and product thesis. But one of the most important parts of that discussion was to bring in measurable wins for security in the eyes of DevOps. So, one example was a misconfiguration that the OPSEC team had brought together that was supposedly supposed to both mitigate vulnerabilities and also to prevent some additional work that DevOps have done manually previously.
So, by virtue of being able to compile a variety of initiatives into one main initiative with a common logic for both security and DevOps, I think they were able to get a better buy in from DevOps who were, as you mentioned, were very, very laser focused on their initiatives. So, they had a shared dashboard. And he showed the OPSEC initiatives on one end, and how that saves DevOps action items on the other. I think that's pretty advanced in the type of cultures that we've seen, but even bringing everybody to the same table and really talking metrics and stats i thought was profoundly intriguing for us to see.
[00:24:55] MC: I love the idea that they actually had a dashboard, almost do you think like a scoreboard, right? You’re watching a soccer match, you can look at that scoreboard and knew exactly what's going on, how much time is left, who's winning. So, creating something like that, that can be shared between DevOps and security. I do think that's very advanced. But I think that is likely something that creates excitement on both parts of a team, and brings them together. Otherwise, both teams are looking at things that are maybe diametrically opposed, ones looking at, “Well, how do I manage risk?” And the other one is like, “There's no concept of risk over here.” But like you said, I think when you have those maybe common metrics, I think I did a blog on this one time. I'd have to dig it up, put in the show notes. But I think having common metrics allow organizations to realize that, although they have different roles, and the outcomes are different, what they're trying to achieve at the end of the day, is to make the organization better manage level of risk, and at the same time, makes sure that the product that's being brought to market is brought to market in a way that keeps them competitive.
So, I think with those shared metrics, it's almost as if that organizations who do those types of things, that have that scoreboard will, in the end, differentiate in the market, because they can use security as a differentiator.
[00:26:15] GE: Exactly. And that's what I love the idea of an infrastructure platform team, because it suddenly gives a player in their organization and this is my way of saying there's DevOps as a function, and then there's infrastructure and platform teams that are becoming more predominant in some of the more advanced areas. And what those teams are doing is they're keeping a scorecard of initiatives that help more than one team, because they're the enablers. They're the ones that are going to say, “If we enforce key rotation once across all of our 200, 300, 400, AWS accounts, then we save us ourselves tons of time, whenever we want to deploy a new region or a new stack.” So, this is where I think the concept of unloading some of these mundane, probably boring work from people who are in charge of security in their application teams or people who have done generalized DevOps is going to become a very pragmatic solution for rapid growth.
[00:27:12] MC: So recently, at least here in the US, the Cybersecurity and Infrastructure Security Agency, or CISA, they started cataloging cybersecurity bad practices, which I thought was a great idea. Because we talk so much in the industry about best practices, checklists, things like that. So, I think it's actually wise that they're doing this. But when it comes to cybersecurity, bad practices in DevOps, what are maybe the top three that you see most commonly? Or just the top few, maybe if you can't think of three, but what do you typically see?
[00:27:44] GE: Oh, I can think of much more than three. I'm trying to prioritize. I think that the lowest hanging fruit I've seen constantly in the cloud has been unused resources. And this could sound maybe the most boring topic in the world. But take my word for it, if you're listening to this, look up unused resources on GitHub, you'll find tons of resources for finding those unused EC 2 instances that are running tirelessly or unused user roles and groups. The reason I think unused resources is such an interesting problem is that the definition could be very broad, and the impact could be very deep.
I think the Capital One use cases is a good example of a place where you have resources that are laying around. They’re configured one way, three, four years back, and someone could come in a few years down the road and those unused resources now become either a segue into a more privileged environment or a way to leverage or utilize existing sets of credentials. I think that's generally a practice that good DevOps, good infrastructure teams routinely incorporate into either daily or weekly cadences.
So, that's one. The other big one that comes to mind is non conformed environments. And this goes to if unused resources is like a very tactical problem, you build something, you build something next to it, you don't need it anymore, you forgot to delete or put a retention policy or something. Non confirmed environment is something that needs to come top down. It's the place where C level executive or VP needs to come in and say, “Hey, we're going to build in a confirmed way and we're going to use very concise design patterns when we build.” And this is not just a bad practice not to have this, it has the tendency of becoming a culture. So, environments or organizations that use conformity as a design principle, usually we'll have much less unused resources and much less garbage left around that's not lockable or traceable, and potentially vulnerable.
[00:29:45] MC: So, that's conformity. So, I guess another way of putting that would be having a highly standardized environment. It's interesting when you talk about security standards, or even just standardization of environments, it sounds kind of boring, like standards. But I always tell people standards are meant to be boring for a reason, right? And this was cemented for me. I was speaking with an engineer from Facebook a couple months ago. And I was asking them, I said, “How is it that Facebook can operate at such a hyper scale?” And privacy issues aside, which we all know that have been some challenges, but privacy issues aside, from a security perspective, do avoid absolutely spectacular breaches and things like that. That's such great skill. And the answer that came back was massive standardization. And you kind of think, wait a second, how can a company be so creative if they have such massive standardization? I think part of the answer is, is that and I've said this time and time, again, is that a lot of organizations assume when they move to the cloud, they are going to automatically get automation. And that's just not true. You've got to build it. You can't automate what you have not standardized upon, what are your thoughts around that?
[00:30:56] GE: We can talk for hours about how infrastructure is code essentially could be the driver of two very distinct and different paths. On one hand, it gives developers a big blank canvas with full access potentially to any resource they want to provision in the public cloud. And on the other hand, it's a great way to start templating, how resources are supposed to be crafted. We've seen both design patterns, sometimes in the same organization, where the fact that an organization would use infrastructure as code, let's take terraform as an example, could mean both that people can come in and go through a service catalog, select exactly the different components they need to build an application. And in a wizard like experience, get a piece of infrastructure ready to deploy with compute, database, networking, and IM all packaged together. This is for some of our more advanced customers.
On the other hand, that same tooling enables you to open up – you open up your VS code, you open up your JetBrain, and you can essentially write just whatever you want. And the challenge has been, even for us internally, when we scaled out and built out our product, how do we reconcile the fact that on one hand, this technology gives us such a huge and broad canvas, but on the other end is probably our best chance of getting that conformity that I talked about before. I think one of the challenges that we have had, and I think a lot of organizations are now facing is where do I put my boundaries? What are the red lines? Where are the gray lines? What's fully permissive? This is a tactical problem and a strategic problem as well. We've been trying to tackle naturally with our open source and commercial tooling. And I think the industry as a whole is, is really touching this topic more and more. And you can see cloud providers have – even AWS has like six or seven services that are all about defining and building permission boundaries.
[00:32:49] MC: I'm curious to get your thoughts on this, because this is where you kind of live every day, but you work with probably hundreds of different customers. And where would you say the industry, and I know it's hard to generalize, but where would you say the industry is at in terms of really kind of adopting this? We know there's the Fang companies, the Facebook, Amazon, Netflix, Google, and they've been doing this for years. But if you kind of exclude the Silicon Valley companies, and you look more at kind of a traditional Fortune 500, Fortune 100, where would you say they're at with really adopting not just infrastructure as code, but really, I guess, implementing and embedding security in that process?
[00:33:29] GE: It was interesting that you mentioned the Fortune 100, Fortune 500 companies as a separate bucket. And I'll tell you why, because it's one of our experience has been, we haven't mentioned this, but we have an open source project that gives anyone the opportunity to implement security and compliance best practices in their development pipelines. It's called Chekov, you should check it out. But generally, it's one of the ways you can use the product without using the product. The earliest adopters of that open source were two communities.
One, the first group, you mentioned the Fangs of the world. So, we had people from Google Cloud, Salesforce, Amazon, Amazon Core, not even AWS, that have had these problems and saw there was an open source alternative and just flocked into it. And then the other group was consulting companies. Think of your slaloms, you're in why, your digital transformation advisors, so they flocked into Chekov because they had projects with think of the biggest oil and gas companies in the world, biggest banking institutions in the world. They were adopting cloud infrastructure for the last two and a half, three years, and they needed this type of technology. And they were getting it through virtue of these consulting companies that were implementing these governance best practices for them.
So, I think these were the two initial buckets that I think are very advanced, your Fortune 10, Fortune 20 and then that Fortune 100, Fortune 500 that are getting these services acquired through consulting. And on the other end, my third bucket is hyperscale companies. And those are the companies that we've seen, just attract some of that talent that's coming in out of those bigger companies, and it's just the only way that they know how to work. So, if you work for Netflix, and you're familiar with paved road concept, when you go to work for Asana, or Coinbase, or Carta, or one of those 2019, 2020 IPO class, that's the kind of best practices and infrastructure that you're going to be building.
So, those were, I think, three main buckets where we've seen a lot of maturity. I think the rest of the market really varies. You can see this when you go out and talk to customers, especially outside of Silicon Valley that are trying to attract some of that very prestigious talent and doing their best to catch up with that high end of the talent pool.
[00:35:47] MC: So, you mentioned Chekov. I'm curious where that name – what is the tool do? Where can listeners get it? And then how did you come up with that name?
[00:35:56] GE: Good question. So, Chekov, so the name of the company that started with that is Bridgecrew and that is a Star Trek reference, right? Every Star Trek franchise had its own starship that had its own unique cast of bridge crew members. So, we had founded the company, we're all three big Star Trek fans and like sci fi fans, and we thought it would be interesting to reference DevOps and that foundational engineering team as the bridge crew of an engineering group or a company. And every one of our open source tools is named after a Star Trek character.
So, Chekhov was was first and then came, Here I Am and Yor which are things that probably people need to Google, but there's not as central characters as the other. But each one of them has a unique meaning. Yeah, but we like Chekhov. The domain was vacant, so we rushed to it.
[00:36:45] MC: That's another big part of it, right?
[00:36:47] GE: It is. Super important for the company. And what Chekhov does is it solves a very foundational problem when you code, which is to identify as early as possible, bad configurations. So, if you are familiar with terraform, essentially, it's a very plain programming language. First line, you need to say what resource you're going to deploy. If it's an S3 bucket, redshift and elasticsearch database, you write that on your first line. And then the next 6, 7 or 200 lines are going to be the attributes of configurations that are going to be the deployment parameters for that resource. And some resources are super simple, some are more difficult, but all of them have one combined trait, which is it's very, very easy to make mistakes. It's a single line of configuration to provision and unencrypted storage bucket, or to make a compute instance, open to the public Internet.
So, literally one line of code, two lines of code could essentially expose an application. So, Chekov helps developers, whether it's deployed in a CIS platform, or as part of a VS code setup, you can put it on so Chekov enables you to scan that code as it's getting composed. And to identify when either critical configurations are missing in your resource blocks, or misconfigured in those resource books.
[00:38:05] MC: I love it.
[00:38:06] GE: It's open source, you can download it, check it out, you can run it locally.
[00:38:09] MC: So, it sounds very DevOps friendly. It doesn't sound like it's a tool where you get to set something up, you have to go through a GUI, it sounds like something that would be command line driven, something very DevOps friendly. I've not used it.
[00:38:20] GE: It is. It's very lightweight. It's C libraries and that's a big design principle. And it's also Python, which is, I could say that that's our nod to the security community. We wanted to make it, to build it in a language that is accessible as possible. So, if you're more familiar with Python, because you come from the security side, you can easily ramp it up and deploy it locally and run it against even statically stored code that you have on your personal machine. The more advanced users would incorporate it in something like a Jenkins, or GitHub action or circle CI and just use that as a continuously deployed gatekeeper that scans everything that changed in that CI pipeline, and then alert or fail a build when it identifies a miss configuration.
[00:39:02] MC: That’s great. Well, Guy, I loved our conversation today. Thank you so much for joining us. If people want to connect with you, or if they want to learn more about Bridgecrew, where should they go?
[00:39:12] GE: Visit us either at prismacloud.io or go back to bridgecrew.io for the product intro or just Slack me, either on our Chekhov Slack channel, or find me on LinkedIn.
[00:39:22] MC: That’s great. Well, thanks so much, Guy. Appreciate it. Have a great evening.
[00:39:27] GE: Thank you, Matt. Bye.
[00:39:28] MC: See you.
[END OF INTERVIEW]
[00:39:29] ANNOUNCER: Thank you for joining us for today's episode. To find out more, please visit us at cloudsecuritytoday.com.