Ashish Rajan: I’m so glad you came. Infrastructure as code security could not be complete without having you here Barak, so I’m glad you came in. Thanks for coming in, man. Thank you for having me. I’m going to start with the obvious that people have how did you get into this thing? So what was your journey to development and to where you are right now? Because technically you call yourself a developer, but you’re cyber security now, man.

Barak Schoster Goihman: Yeah, it’s been a hell of a journey. So I started programming at the age of 14. Found my way into a technological unit that Israeli defense force spent some time there building some big data systems. And then my first role outside of the Israeli defense force was for a cybersecurity company. I need some data science at the, at the army.

And then I started to do data science at four scale, which was a security analytics company. It was acquired later on by RSA. Then they joined RSA, which is another security vendor. And I was very focused about on-prem security and anomaly detection. And. I was the software architect of our [00:01:00] group at, at some point when doing devops for our team and building the architecture of our product for the cloud.

I realized that there are a few gaps that I have as an architect when writing my Terraform and cloud formation and serverless Lambdas. And this is where we decided to start bridgecrew to handle our day to day paints.

Ashish Rajan: Interesting. And for people who don’t know what Bridgecrew is, cause I mean, I’ve been a fan of you guys for some time as well.

And so what is bridge crew again?

Barak Schoster Goihman: Right. So bridgecrew is a, an infrastructure as code security company. We help developers, DevOps, engineers, SREs, and security engineers to secure their cloud infrastructure very early on for the moment that you are writing code till it’s deployed.

And after that,

Awesome.

Ashish Rajan: So this is like a question that I ask every guest in, cause this is the cloud security podcast as well. What does cloud security mean for you?

Barak Schoster Goihman: That’s a great question. So I think cloud as a beginning is a huge opportunity because everything is defined as API and cloud security for the first time [00:02:00] means that you can enforce security using APIs all across the way.

So if you’re writing code that calls APIs, if you’re writing containers, You can run a lot of security scanning using APIs or very low small agents and automation. So you can actually automate a lot of the scanning and remediation of security so for me, cloud security is an automation framework or

reality.

Ashish Rajan: That is pretty awesome. And I’m amazed how everyone has a different definition of it. Cause I think people try and cover different aspects of it as well. And this is a great, great segue to the topic, which is infrastructure as code security. Ive heard Infrastructure as code? What is this? Infrastructure as code security?

Barak Schoster Goihman: All right. So let’s go back like 20 years ago. Do you want the network? A security product. You bought an appliance later on, you had a VM and later on you with the cloud, you had an API which helps you define the network ACL and a security group where you can define ports and what’s allowed to go in and [00:03:00] out in, in of traffic.

And if you have that defined in API and you want to do it in scale, you start to write scripts that are there is running and provisioning, a lot of security groups and a lot of servers underneath those security groups. And if you want to do is API is to have a state. There comes infrastructure code.

There is a set of manifests like Terraform, cloud formation, Kubernetes, serverless framework, contemplates, et cetera, and even Ansible and chef that helped us as engineers. To define how a predictable environment would look like in code. And if you define a predictable environment in code, you would like to define security controls to be predictable the same way.

And when I’m saying predictable, it means that you deploy something 10 times, it will always deploy the same, no human interaction involved. And you want the same activity that you have for cloud infrastructure. You want to have the same predictability for your cloud security.

Ashish Rajan: Yep. Interesting. And the predictability is only possible in cloud as well.

So this is quite a unique opportunity for people listening in to go for the [00:04:00] first time. Infrastructure has API earlier. If we’re just VSS admin person, Hey, I need like a, I don’t know, eight decided I need five servers make that happen. I kind of conversation now. It’s like, Oh, I can just write one line of script.

Which can happen, make me create five servers in one go. So very unique opportunity at that point. And it kind of makes me think as well. I wonder why a lot of people confuse this with application security as well. Sometimes, especially the field like cloud security is just either infrastructure security or application security.

So can tell us what the difference between application security versus infrastructure score security is.

Barak Schoster Goihman: Yeah, so I can understand why people think those are the same infrastructure is code is code, and you can run static analysis on top of it and application securities code like Java and C-sharp et cetera.

And you can run static analysis on top of it. So you have those two concepts that run static analysis. Why aren’t they the same? And the main reason for that is one the attack surface is different. The problem space is different. [00:05:00] Cloud infrastructure security is about cloud misconfigs. Like you forgot to turn on encryption backup and recovery audit, et cetera.

And application security is more like SQL injection vulnerability, third party supply chain, vulnerability, et cetera. So you need different experience as a security practitioner or a dev ops engineer to solve each one of those. And also. In a lot of times, those are different personas in the organization.

AppSec have their own team in large enterprises and infrastructure security usually falls under dev ops or SRE roles. Because if you write the code, that provision resources, you own it. So you build it, you own it. You’ll fix it. And that’s the current motion in infrastructure as code security.

Ashish Rajan: In a way it’s a different threat landscape as well.

I guess you’re looking at different problems, but I guess we’re not an application security person, be an infrastructure as a code security person as well, or August. It’s more like, I guess, is there like a delineation there or [00:06:00] do you see them kind of being done by the same person?

Barak Schoster Goihman: In some organization, I see them done by the same person, but like, it’s really like, you have so many knowledge you need to grasp as a security engineer.

And if the knowledge is there somewhere else in the organization, why not start there? So for example, S3 buckets are usually not being watched by an application security engineer. They are watched by dev ops and SRES. So there are probably the right person to fix that problem.

Ashish Rajan: Right. Okay. And that kind of makes me feel the other half of the challenge as well did you find it , interesting. Coming in from a perspective that, Hey we are going. Into a very developer friendly world first.

Well actually, do you have a definition of devsecops ?

Barak Schoster Goihman: Yeah, so I, it is a relatively new trend from the last few years.

There is teams while I mentioned, like, I tried to make it distinct between dev ops and security engineers. The reality is not that way and upsets engineers. The reality is that everybody. Need and should work together. And in some cases, those teams that work together [00:07:00] in that kind of a culture shift are called DevSecOps or SecDevOps or just DevOps which is where operations teams, development teams and security teams should work together as a cultural.

Ashish Rajan: Yeah. And I think it’s worth calling out because now we’re kind of in a world where all these . Acronyms and names are being thrown out as well. Right? So we are, we’ve already spoken about infrastructure code security, application security DevSecOps, and I love the fact that you call yourself a developer.

What was the reasoning behind the whole developer first? Why was that important for you to have a developer first cloud security kind of like an approach because I’ve, to your point, everyone’s collaborating, right?

So do we need to have this separate, like a wave they should be driven from?

Barak Schoster Goihman: I think that a J frog is a cool DevOps company that said that every company nowadays, every big company is now a software company from airlines to Bookstores. Everyone are software companies. So if you want to help each and every company out there [00:08:00] to be successful, you need to help their developers because there are software companies today.

So look at Amazon who was a bookstore now, a software company. Well, for a lot of years, they are a software company. And if you want to help them to be successful as a development team, you need to help their developers by. Finding the right person, very early on to fix the problem. So there is a term called shift left, which means generally is you might have a lot of JIRA tickets that are flying after the fact when you’re finding a security issue.

But if you want to turn it left in the lifecycle from production and operation to QA and to them, there is a way to do that. And it’s by integrating to CICD pipelines. Yep. And giving the, with their, or into IDs and giving.

Ashish Rajan: And I guess you’re pointing to comes with maturity as well.

Not everyone would be at a stage where they’re using CICD pipeline as well. Right?

Barak Schoster Goihman: Well, you are correct. But if you want like to deliver at the cloud at scale you’ll have some kind of CICD somewhere. Out there. Otherwise you’ll just have a lot of [00:09:00] engineers doing manual deployment and manual configuration in the cloud.

And it’s just not scalable

at some point

Ashish Rajan: cool. Well, I’ve got a 1st question already, so Rajeev is asking more from a context of placing a controller on a file level in a operating system.

It’s probably in the context of infrastructure scored security, but I’m keen to know your opinion on this as well. If you have one, yes.

Barak Schoster Goihman: Are there. Options of scanning storage systems or endpoints using endpoint protection. So there are solutions for that. I agree. It’s not part of the infrastructure security frameworks, like terraform cloud formation, but you can do an automation

for that.

Ashish Rajan: Yep. And I think it’s actually probably leads to a very interesting question as well, because. I think where Rajeev’s questions came from the whole part, taking that a step further, like a lot of people kind of still have the transition challenge where on-premise endpoint security is all about file integrity.

Like the integrity of the file hasn’t changed. But as in cloud, It’s all about. Well, it could essentially, because the servers have been clicked deploy, whereas in the context of a cloud to your point, you’re using Terraform, you [00:10:00] have kubernetes cloud formation, code pipeline. You can just like keep going.

There’s so many different ways of deploying into cloud to begin with. Absolutely. It’s probably worthwhile having that distinction. So is there another abstraction from so it almost feels like there’s infrastructure code security, which is kind of what you’re talking about. Terraform Kubernetes , containers.

What else would you put in there that called falls into the I guess the bridge crew category.

Barak Schoster Goihman: So everything around the traditional cloud security from. The infrastructure is code to them, manifest themselves to the runtime status of a resource in the cloud. So where it was provision using Terraform or other framework or not, if you have given a manually provisioned EC2 that would be, it’d be an area of cloud security, because you want to know that it has an EBS that decent creep, that it is within a matching security group, et cetera.

So solving the issues just in Code level is not enough. You should always monitor both code and runtime environment to get a [00:11:00] full visibility of your cloud

security.

Ashish Rajan: i ve got another LinkedIn user cost of fixing a vulnerability is cheap, but if identified earlier in the life cycle, that’s a hundred percent true. My friend, I’ve got a question, which so I’ve got a question from Abraham. Are Reese, which software would you recommend for a fresh security analysts to pick up first Ansible Terraform SaltStack kubernetes? Ooo theres a lot of words in there ?

Barak Schoster Goihman: It’s a

hard one. Escort Trent Like it’s public data. Ansibel Was the largest infrastructure is code framework out there widely used. The thing is, Terraform is the fastest growing one. So it’s probably already over Ansible. So I would choose Terraform over Ansible. And that’s for Kubernetes, that’s the largest open sourcing to CNCF.

You should probably pick this up too over SaltStack. So my answer would be to Terraform

and Kubernetes.

Ashish Rajan: Oh, perfect. And I think is plenty of open source resource for this as well. So we need to dive deep dive into terraform and kubernetes, and then you kind of go into infrastructure as code security as well.

[00:12:00] And is there someone you follow to learn Kubernetes online or just Google searches? So

Barak Schoster Goihman: if it’s around Kubernetes security, I really like a project by a guy called M adhu called Kubernetes goat. It’s a great tool. It’s open source. It lets you provision a vulnerable by design Kubernetes cluster.

And there is actually a CATA Coda for that meaning a live course that you can do and see what issues that Kubernetes cluster has. It also scanned by some open source tools. So it’s fun to watch

Ashish Rajan: Cool. All right. I’ll hopefully Abraham, that answered your question. Keep them coming. So I’ll move back to I think, yeah, just making sure I’ve answered all the questions.

So that was the other extreme was the question that we went down the path of, but it’s a great segway into my next one as well.

Terraform Kubernetes cloud formation. So there’s another term that keeps floating around every time with infrastructure as code security, which is configuration as code, or some people even go down the path of policy as code as well. So are, do you see them being different to [00:13:00] infrastructure as code?

Barak Schoster Goihman: Right. So infrastructure is code is a way to right. Cloud configuration defining in different, there is also, which is a declarative way of defining how your servers we look like generally there is an impairment, the way of doing that. You can also, instead of learning your own language, you can use CDK, which would be item or type strip or, or presuming.

And you can write the infrastructures code in that manner, too. And there is a term called policies code, I guess, that you

meant that

the policy is code would be a way to automate enforcement or preventative controls while you’re writing the code and scan your code for misconfigured before you apply them to production.

We actually have an open-source around that called check ov that lets you write policy as code for infrastructure as code security. And it also comes with the more than 500 or 600. Baked in policies created by the community.

Ashish Rajan: So you should check that again. Oh yeah. So I’ll probably leave the link for the open source repos [00:14:00] over there as well.

And I’ve got a question from Camille coming in soon. Hey Camille, thanks for coming on the show Man, do you have a question for Barak? Good to see you again, actually another question, but I wanted to we’ve ben using Chekovs, because you mentioned a tool for, for first, but recently we have seen a great tool called space lift, kind of the thing this out is strange because it ultimately the security and the compliance with Rigo regularly.

It’s something you could see with OPA feel open policy agent, mostly commonly using kubernetes and specially with DAS allows you to specify your rules the times when the following deployment could be done. And all of that is within you Rigo, a great tool. I had a question. Have you ever tried to like.

Syndicate. So have you tried seeking for care form like this, depending on the language you wanted to do?

Barak Schoster Goihman: I did try syndicate. My personal taste is I prefer T eraform I [00:15:00] have to have a very strict defined language around cloud infrastructure. Because it’s easy, very easy to read declarative language. I don’t have like magic tricks of code, like reflection and unpredictable stuff happening on my cloud infrastructure.

And it’s very easy to inspect and collaborate on. I do see the advantages of syndicated because people want not to learn a new language. Like they want to use what they know. Like Python or TypeScript, but my personal opinion is. It, but it is worth to learn a new language

if it gives you the right tools.

Ashish Rajan: Does that answer your question, Camille?

I was trying to thinking about the stability of CKD, the stability of CDK or facilities.

Barak Schoster Goihman: It’s a pretty stable

Ashish Rajan: thanks for that, Camille. Great question, man. And always good to see you as well. Cool. So we’ve got a question from Darpan as well.

Who’s also another regular person on he was like one of my previous guests as well. Would love to get some thoughts on post deployment infrasecurity. Any thoughts on that?

Barak Schoster Goihman: Yes. So we talked about pre deployment. You need to scan as early on [00:16:00] to prevent stuff from happening, but let’s say. That you have a production environment and you have an SRE getting a phone call overnight asking him, Hey, you need to change something in that server.

He’ll probably do a manual change instead of having to write code, et cetera, those things happened. So if you want to really know and have the full context of what’s running in production, you should have post deployment infrastructure, security controls in place. So that will give you full visibility in the full context, on what’s happening on production, whether it was defined in code or not.

And other scenario is not everything can be, or is always defined in code and lots of organizations that are having a kind of 80 20 percentage of a defined in code and define manually. So for those stuff that are defined manually, you should have controls on ranting. And some organizations are in the transition to infrastructure as code and not have anything there.

So it’s also

Ashish Rajan: okay. Good, good to share. And Darpan, if you have an opinion yourself as well, love to hear that as long then. [00:17:00] Thanks for that question of word. Mark. He’s definitely had coffee today. He’s quite active today. OPA established for preflight checks, policy validation and prevention control toxin.

And on that.

Barak Schoster Goihman: Yes. So another people are comparing chekov and OPA and I’m really thinking there are competing tools. OPA has the way to analyze Terraform plan and you can write policies in rego. Personally, I find rego harder than Python and also P have other use cases like authorization and admission control.

Where checkoff is cutting, actually the code itself, not planned files and all it is also moti infrastructure is code framework. Then it comes with a set of built-in policies, varying opiates, like other bundles that you need to take care of, so they can complete each other. Like if you want to have your infrastructure as code scanned by checkoff, you can.

And if you want to have an admission controller using OPA you can. So I see a lot of mixes in some of the organizations and it’s really a matter of. The level of complexity, you’d like to get it [00:18:00] on. Even though I’ve seen people doing crazy stuff with checkov and OPA and your personal flavor.

Ashish Rajan: We’ve got Rajiv back with another question. Is there a module or something in Terraform that scans for hardcode and open checks, password scans for misconfigure adding more to my question.

If a policy to block a SNMP protocol, which I scan IAC for policy violations?

Barak Schoster Goihman: So definitely you can define in checkov. So checkov has a built-in check for example, to check for hard-coded. AWS access keys, and also a Lionel keys and other POS and iOS frameworks. And you can also write a custom check to block SNMP protocol.

It’s pretty easy. It’s probably nine lines of code. That’s right. These custom poles.

Ashish Rajan: Ah, sweet. Hopefully that answered your question, Rajeev. I’ve got another question from Sahil, where do you start with cloud infrasecurity? Can you help lay down a blueprint for beginners in this field? Great question. I was going to get to a later, but I think we can answer it now since Sahil is already here.

Barak Schoster Goihman: So there are a good set of practice projects. There is Kubernetes [00:19:00] goat that we mentioned for Kubernetes, but there is also Tera goat, CDK goat, and CFN goat for cloud formation. So those goat projects, their meaning from OWASP is to have a vulnerable by design infrastructure. So you can use each of those goat projects to, to kick the tires.

And you can start with using the open source tools like checkov or OPA to scan for infrastructure misconfigure and see what’s out

Ashish Rajan: there. Awesome. And I definitely have to call it out that I wasn’t aware of OPA until all of you guys started talking about it. I’ve obviously I’ve learned something as well today.

I’ve got another person, Kevin, who’s a regular on the show as well. Regula by another pronounced fugue is OPA based and similar to chekov is that it does infrastructure code scanning and is open-source. So both I get checkoff and regular are open source and OPA is open source as well.

Barak Schoster Goihman: Yes, that’s correct.

All of them are open source,

Ashish Rajan: so I’ll definitely recommend people check those options out as well. Darpan, there is a telephone Sentinel natively support by [00:20:00] HashiCorp. Stria is another nice OPA based solution for those policy as code declarations should work. What are your thoughts on policy as code? I always wonder.

Thanks for that. Darpan I I think we kind of touched on this earlier. Config as code policy, as scored infrastructure as code. Everything is code as well. So where do you see like,

it’s pretty amazing. There’s a lot of open source going on right now. Do you see like this at some point consolidating, like, I think, cause you know how we have like, Infrastructure as code I think for me personally, I feel like, Oh, there should be policy in code that as well, Config as code I still put them under the same umbrella as infrastructure as code security.

Do you put them in the same umbrella as well? Or is that more like the line there? It’s not

Barak Schoster Goihman: necessarily a line because Policy as code is a good practice to have even not for security, best practices, but also for cost. Like you don’t want to have expensive servers turned on. That can be a policy. You would want to have backup and recovery in place.

That can be a policy. So I see them go [00:21:00] hand in hand. There is no clear line

Ashish Rajan: there. that kind of goes through the next question then. Do you see misconfigure and I remember seeing a presentation from you a while ago, how common is misconfig, even if you take Terraform or , how common is it?

Because for people like, well, I don’t know where all they might just think, why would I use this? So what, I think you had a stat someday, but I don’t know if you don’t understand, but curious to know, how common is misconfigure.

Barak Schoster Goihman: Well, it’s been a while. About a year ago we scanned thousands of open source infrastructure as code modules from GitHub.

And we identified that one in every two almost one in every two open-source modules have a misconfig. We’ve done some work with the open source contributors , to fix that over time. But there is a big chance that you’ll have a misconfig, not because there is like a big appetite to compromise your cloud.

By those open users, they re they breathe good software, and they just wanted to share it with the community. But is, is that each module is very opinionated. And he has some defaults and he should not always [00:22:00] use the same defaults for your environment. You should consider which defaults you’d like to have when you are using a pre-made infrastructure.

as code module.

Ashish Rajan: Awesome. Yeah, that’s a great answer as well because it’s kinda like, it reminds me of the CIS benchmark thing. It’s great, but you can need to carefully consider that if everything applies to you, like what if you have a multi account structure in AWS? All that so great answer as well there.

So that probably brings me as a good segue into the next one as well, because we’ve been talking about OPA. CFN nag and all these other open source tools, right. For people who are listening to this and going I have a paid version. Why should I consider open source? Like, so what are the like, and I know we are very as a community, we are very open source friendly.

I love open source as well, personally. what do you for people who are thinking of making a decision between open source versus the paid version, what are some of the things people should consider? Whether it’s for infrastructure as code security in general? Cause you’re, you’re a co-founder as well.

So where do you see that? as a gotcha between, like what is should people think about as a [00:23:00] why should they go for open source versus a paid version? When would they make that call

Barak Schoster Goihman: as intrepreneurs or as users?

Ashish Rajan: As users, I guess I’ll probably make that call as users. So you’re a developer yourself. You have an open-source option? Yes. In front of you, you have a paid option. I don’t know if you’ve seen, but just go. I just want to open source. I want to do it myself. Yeah.

Barak Schoster Goihman: So to think that I start with usually as a developer, I started, could we the open-source or with the free version, just to have something running and whenever I Getting into the first world.

I usually check the paid version and see if it’s worth my time of writing more pieces of code to handle it, or can I get it like for a few more dollars and it would help me scan it. It’s a matter of maintainability. And the amount of effort you’d like to put into it over time and the amount of focus you’d like to have it on top of it.

So there are a lot of vendors not only Bridgecrew and trying to be vendor agnostic in my answer that rely on open source tools and have the power of the community with them. And I think that as a [00:24:00] developer, you just want to try and see the value as fast as possible. And you should go where you see the value, if it’s a paid version, go

Ashish Rajan: for it.

Yeah. And I think too, worthwhile calling out, the paid version would come with support as well. Whereas opensource, if you go down that path to your point about the maintenance, you’re going to have to be okay with the fact that you would have to maintain the code for the life of it being used in the company.

Barak Schoster Goihman: It’s a matter of also as a responsibility as an engineer. So let’s say that you have taken an open source and it. I’m not saying that chekov is like, the chekov is very simple, but let you have an open source that you need to put effort on a daily basis to maintain it within your organization, to keep , your application security secure, or your cloud security or your corporate security there.

You need to maintain that open source. It means that you’re putting money into it, but in a different way, you’re putting people and salaries and time into it. And you can have these time saved if you’re just buying a tool instead of. Getting more and more people in it’s hard in, in the security landscape to hire good people.

[00:25:00] So that’s the,

trade-off

Ashish Rajan: that’s a valid point. My friend, I’m going to ask another question on this space, because I think you’re definitely seeing, because I think a bridgecrew open-source repos have probably been one of the fastest growing as well, in my opinion. And I’m sure in the, by wider opinion as well, I wanted to kind of ask you, like, where do you see this go into in the future? Where do you see this in infrastructure as code security space become as you kind of go deep into it? Cause you guys recently released the whole VS code version as well. . I’d love for you to kind of go into that. Like when you started the whole infrastructure as code, we talking chekov Terraform, Kubernetes

How to do security. Well in that space, And now I guess, the visual code scenario as well from you guys. Can you explain that whole transition? Why going in that direction and where do you see the whole industry kind of go as infrastructure as code security?

I think that the thing that we have in mind is we try to help the user persona.

And how does our user persona dev ops history or security engineer? [00:26:00] Used to use infrastructure as code to security. They usually start with open source, like Terraform or Kubernetes. So the first, most friendly way to approach them and give them the right tool would be in the same distribution manner which is open source tool.

So we started an open source tool called Chekhov, and we made sure that it is one thing, very easy to use. Second. Have very easy to contribute more content into it. So we really wanted the community to be built around it and to contribute more policy. So you’ll have the power of many and three to be very approachable.

So we chose to open source chechov for those reasons. I don’t know how, but it succeeded. And when we open-source the vs code extension, we asked ourselves, right. We saw people running Chekhov in CICD pipelines. And we asked them, what can we do better? And they are saying like, right, CICD pipeline takes 40 minutes after running unit tests and declining, et cetera, et cetera.

How can I run it faster? So we took the checkov open-source tool and [00:27:00] created another wrapper around it for VS waste code extension. And this code is the law, the most popular ID out there. And we tried to help all of those dev ops engineers by. Just having answers in seconds to their while they’re writing code to misconfigure that they’re writing in as code.

So this is how we came out with the vs code one

great approach. So do you reckon the future has got to moving in that direction where you’re going to have to be able to pick it up? Not just add, say a code commit. It’s more, it has to be in the ID level.

Barak Schoster Goihman: Yeah, definitely. So. First more and more power is coming into CICD pipelines.

And probably the next trend would be to IDs. Especially when code spaces is probably coming soon. So code spaces is the web version of this code that was announced and it’s going

Ashish Rajan: to come soon. So that’s how we realize

Barak Schoster Goihman: that that’s going to be really interesting. So yeah, more power to the developer would be inside the idea.

Ashish Rajan: Yeah, I I’m personally looking [00:28:00] forward to it as well. VS code takes a lot of time to install on a Mac book. Like all these updates that keep coming in as well. So I’d love to see that version change. I’ve got a comment from Kelvin. Pulumi likes to compare infrastructures, text versus infrastructures software to clarify ISE options that you have DSL versus general purpose programming language.

Actually, it’s a good primer for people who maybe not from a developer background. What’s the different between a DSL and a general purpose programming language. According to you.

Barak Schoster Goihman: Yeah. So a domain specific language would be very much like a config file in some manner. And you are limited in the things that you can do.

I personally like limitations. It’s good to have boundaries, in my opinion in some, in some code aspects then Pulumi is that can be written in a generic language like Python or TypeScript. So you can do anything with it. It might. Lowered the barrier for some engineers who wouldn’t like to learn a dedicated VSL [00:29:00] and for others, it might be a place for more complexity, because if you can do anything, you can write more complex code.

The good thing about Terraform as the DSL is that they edit loops and conditions over time. And it is being more like a programming language over time. But. Yeah, it is limited compared to Pulumi, which is in Python

Ashish Rajan: or typescript.

Yep. So I guess the a person’s preference is Terraform

Barak Schoster Goihman: yeah. Terraform, but that’s that’s just my opinion, I guess that Kevin has an otherwise,

Ashish Rajan: well, I don’t know.

I don’t know. I’m sure. Now, Kevin doesn’t I hate to love another one, but a battle, but you get it out there. It’s all a question like, Oh, actually I’m talking about DSL, the general public’s language also. That was a great comments there, Kevin. So. I want to switch gears now. Cause I know we’ve been talking about open source and how dowe do infrastructure as code security, but I do want to talk about you as a a startup founder as well.

For people who may not be familiar bridgecrew, the company that you are I guess co-founder and CTO [00:30:00] for there was a really amazing deal that happened between yourself the bridge crew guys and Palo Alto. I won’t go into the details of it, but I do want to do kind of bring it back to. Some of the audience members that we have have their own start-ups or they are currently working on their startups as well.

So it’d be good to kind of know, like, as one of the successful startups, like you kind of went in a very different way where it was developer first instead of, Hey, I’m going to make a paid product because I want people to pay for it. So what was the motivation going behind develop a first open source product.

Because you are developing yourself or what, what kind of triggered that kind of movement for you personally for your startup?

Barak Schoster Goihman: Right? So, so our first tier is open source, but we do have a larger product that is paid and there are lots of companies that are using that. And our way to build that product was both the open source and the commercial was just ask people how they solve their cloud security issues.

And we went to more than 120 or 180 [00:31:00] discussions with people from Netflix and And either like we talked with people from Airbnb and other cool companies that have been doing that. We just asked them, Hey, how are you doing that without getting into too much details? How are you doing cloud security?

Yeah. And the answer was, we have a finding in the cloud, we open a JIRA ticket and we send it to, to the engineers and we were like, all right. So the people that are actually fixing stuff are the engineers. Why not help them instead of. Trying to fix the JIRA pipeline. So it starts for every company, but in a lot of company, that was the common dominator.

So we started creating a Chekhov, an open-source tool, and we got more and more validation on that topic that it can be solved early on. And this is how we started.

Ashish Rajan: That’s pretty awesome. And I love that you guys have taken over the infrastructure as code security space as well. So I’ll definitely encourage people to check out the.

The company and the open source repositories that you guys have. I know many developers listening to this and who was like, Oh, Barack is a developer himself was going to try [00:32:00] to some company. Where do you I guess what’s your, I guess, advice for a, a younger Barak trying to get into the whole startup space as a do.

And he, or she, the developer as well.

Barak Schoster Goihman: Always be curious, always thrive to learn something new and if don’t do the same work twice, always automate everything. So that’s my, yeah.

Ashish Rajan: I’ve got, I’m going to switch gear one sec, one switch gear back to where we will be focused on what a question from Sahil.

And I think it was it’s probably starting off in cloud security. If we can help him out. I’ll definitely the one do that. His question is how do you take care of multiple cloud services and environments as there is no standard approach defined that works everywhere else. You have an answer for that as well?

Barak Schoster Goihman: I’m going to go for, we checkov this time again. So checkov can scan multiple infrastructures code frameworks, which works on multiple services and multiple clouds. And it has baked in policies from. The community from people who know better than, than me. So I’m using that as a source [00:33:00] of learning because even when I’m writing today, I have someone contributing a new policy that I’m all right.

I didn’t know. I should secure this service that way. So I am using that as a framework for myself to learn how to write a more, a security infrastructure

Ashish Rajan: in the cloud. Awesome man. good on you for saying that as well, because this shows how humble you are as well. Cause I mean, it’s. There’s always something to be learned, right?

It’s like it never ends. It’s never ends. So do you feel like you need chutzpah to succeed as a startup and probably explained to people what chutzpah is?

Barak Schoster Goihman: So it means a lot it can be the ability to dare and it can also be to defy an authority. It depends how well you can do it in a. Humble approach. But if you want to disturb a specific market, you, you need to fight against, or to explain how to build a new, how to educate the market, to build something new and to do something differently or you need to fight [00:34:00] against other larger players and explain why your way is better.

So you might need some chutzpaht, but they’re like elegant

Ashish Rajan: ways to do that.

Awesome. Awesome. And I’ve, I do want to call out for all the Hindi speaking Indians out there, or non-Indians out there will speak Hindi is a word which is similar. And I think I was talking to a Baraka was earlier called Jasbah means very similar things.

And you’re like, I dunno how, but Hindi and like Hebrew kind of somehow. Gel somewhere in the, in the past. And they’ve kind of come up with similar word for the same context as well. One final comment that came in from Regina was lots of opportunities in government and DOD space check, DISA and mitre attack framework.

And if you could let me know. So automate DISA and mitre attack framework definitely in the DOD space, there’s a lot of opportunities there, but. That’s pretty much what we had time for, man. So thank you so much for taking the time out for people who kind of have follow up questions and we’ll get in touch with you.

Where can they connect with you? Like where do you hang [00:35:00] outside?

Barak Schoster Goihman: So probably Twitter it’s Barak Shuster is the handle or, or LinkedIn that’ll be available there. And also we have a Slack channel that I have available. It’s slack.bridgecrew.io So you can sign up and just direct message me.

Ashish Rajan: Awesome. And I’ll leave those social media, social comments on there as well, but this was awesome, man. Thank you so much for taking the time out. I’ll see you on the clubhouse room soon for people who are joining us live on the other live streams, I will see you all next week as well. It’s always a pleasure to have you guys and we’ll have another version of cloud security podcast thanks so much for Barak.

I I’m looking forward to having you on and probably seeing you in person in, in Tel Aviv soon, man. Yeah. Looking forward for it. Awesome. Thank you.