Ashish Rajan: Hello and welcome to another episode of Virtual Coffee with Ashish, which is also for cloud security podcast. If you’re here for the first time we talk about cloud security topics that is effecting the IT world and the OT world. And we’ve been talking about this for a whole season. This is season two, and I have an amazing guest today because we have an interesting topic.

Infrastructure as code security what is it? And why should even be cared about security? What are you even? I could develop a basic unity. So. All of a sudden, a lot more, and I’ve got a really great person over here because I’ve been following his content for some time.

And I’m really glad that I could bring him on.

Matt Johnson: Hey, how’s it going?

Ashish Rajan: Good. Thanks for coming in, Matt. Not

Matt Johnson: a problem at all. Thanks for having me.

Ashish Rajan: I’m going to start with the obvious one, right? How did you get into this space? Like I was going to say the cybersecurity space, but how did he get into this space at all?

Like the developer advocate? What is it? What do you guys do?

Matt Johnson: It’s a really interesting one. Actually. I have always been like, I’ve always been a security geek. I always liked kind [00:01:00] of the idea of being a pen tester and kind of, you know, breaking things and creative ways and, and all that kind of stuff.

So I’ve always kind of had a security background. My profession actually kind of took me into Linux and networking and kind of low level operations kind of before DevOps when it was kind of separate. Ops teams and dev teams and QA teams. So that’s kind of how I got into like my first, you know, official, like proper IT job.

And from there kind of ever since I’ve just found out myself, always working on like that bridge between developers and operations. So when I was in an ops team, we’d always be trying to write tools to allow like even simple stuff that never used to exist with on-premise. Data centers, like just giving developers access to the logs from production so that they don’t need to keep requesting the logs from operation team.

You know, just automating that kind of ability for developers to self-serve. And so for a long time, I’ve just kind of worked in that like developer tooling space. And then that kind of got [00:02:00] rebranded as dev ops and started working closely with the developers but all the way through it much of it even just doing kind of that role is advocacy.

Like whether it’s advocacy to the developers as to how to use those tools or why they might want to use those tools or why they might want to output the logs in a certain format to make it easier for us to kind of provide that data back to them through like cabana and elk stacks and all that kind of stuff.

So. I just kind of naturally fell into the advocacy role. I got an opportunity in my last company to kind of do that full time because I was finding myself doing a lot of the conference talks and a lot of the kind of internal talks within our company. Anyway. And then with bridge crew, it’s kind of allowed me to tie those two passions together.

Like I am doing advocacy, but I’m also doing it for like a really cool, like. Security focus team. So I get to kind of keep that hobbyist, like pen testing, security, passion, and I get to do the advocacy stuff.

Ashish Rajan: I love the fact that your passion for combining how others can learn and build their [00:03:00] tools and do all this. I think it’s a great. Piece of work, which has been almost like coming up in the last couple of years.

Right. I don’t think before that there was a whole developer advocate or maybe even longer, but I think it’s a great field just because it allows people to, Hey, I have this person who’s not a salesperson and I can just talk to him about how do I do this. And as a technical level, that’s what I love about this field.

So I’m glad we have people like you as a developer advocate, man. What about cloud security though? How do you define cloud security?

Matt Johnson: It’s an interesting one. Isn’t it? Because it’s just kind of a catch-all term. Like for me, I think security is such a, it’s kind of insane for how kind of small the security industry is in general, but like, it covers so many things.

Like for me kind of cloud security, if I had to put a term on it, anything that sort of anything that changes. Because of needing to use you know, the APIs and the functionality that the cloud provide. We’ve always had certain types of [00:04:00] security transfer perfectly into the cloud, right?

We’ve always had to close, open ports. We’ve always had to not give away our SSH private keys. We’ve always had to. You know, make sure we don’t have as dwell injection and, you know, application vulnerabilities and try and protect against them and protect against insecure dependencies. All of that is still necessary today.

If someone says cloud security, you kind of still have to consider all of that because just because your applications are running in the cloud, that is all still normal security stuff. But for me, the things that are cloud specific, I think.

Are often overlooked the fact that there are different ways of doing things on Amazon and Azure and Google them pick your favorite cloud provider. There are ways of doing things on those platforms that are different than if you were doing it yourself or on prem or, whatever. And there are API is that didn’t exist.

And for example, IAM like that is a AWS only thing. And getting that wrong could allow someone to assume an admin role into your account and access all your resources [00:05:00] like that is a hundred percent cloud security, because that is a security thing you need to care about that you wouldn’t care about if you weren’t running in the cloud, because it’s something that only exists to enable that cloud service.

I guess that’s how I’d define it. It’s an interesting question.

Ashish Rajan: Yeah, and to your point, in an on-premise world identity. Depending on the organization, identity is actually a whole team. You wouldn’t even like hear about it until like, Oh, I need access to this AWS thing. I don’t know what it is, but I guess I need access to it.

And then you go to this identity team and Hey, can I get access or whatever the process may be, but in a cloud world, Because identity is considered, like, I guess the crown jewel that’s the new parameter as a lot of people are calling it. Right. It’s kind of like the obvious, like, Oh everyone, if anyone gets access to identity, you have access to the whole data center.

Matt Johnson: Yeah, like it’s the downside of it being AP multi-tenant API is that anyone can use is there has to be a way of granting anyone in the world access to those things that anyone. [00:06:00] Yeah. So that kind of, that side of things I definitely see a scope security and there’s a few other things that like, It’s not really security.

It’s more that historically we got away with doing security through obscurity. So if you’re in a private data center and you have like firewalls and all that kind of stuff, it didn’t really matter. If someone accidentally spun up a VM, they shouldn’t have done with a load of open ports and things because chances are.

It’s in a private sub net, like it’s only accessible from within that data center, it’s still bad. It’s still allows an attacker to kind of move sideways and find other footholds like, but chances are, you would have got away with it. Like you’re not going to get away with that. Accidentally opening up an instance with a public IP or like accidentally creating it with the public IP.

So I think even some of the traditional stuff, like we have to be more mindful of. And I guess we could call that cloud security as

Ashish Rajan: Yeah. And because the topic is infrastructure as code and for some people may not even know what infrastructure as code is, what is infrastructure as code and what is infrastructure as code [00:07:00] security.

Matt Johnson: like everything we’ve kind of just talked about there. Like I do come from like a proper like hardware, Linux operation geek side. So you probably noticed. What I was just talking about was SSH and VMs and spinning things up, like all that kind of like everything you do in the cloud nowadays, realistically, unless you’re just playing around, unless you’re just kind of learning a new feature or a new thing, you’re realistically not going to be using the UI to spin up your resources, you know?

Across any cloud provider you’re going to be using the APIs or you are more likely going to be using some kind of tool or framework that consumes those APIs like Terraform or like CloudFormation so that you can kind of maintain a bit of sanity on what infrastructure you’re running.

And so. Any kind of security aspects around like how you are writing and managing that infrastructure as code, how you’re codifying your, like I said, be Terraform and be it serverless framework that CloudFormation anything you can do to kind of [00:08:00] embed security at that level so that you’re not only feeling thinking about security risks.

Once you have real infrastructure running, like infrastructure is code security allows us to think about security. Before we even apply that Terraform before we even run that cloud formation and allows us to kind of try and detect things before they even make it to production in the same way. You’d run kind of security tests and, you know, unit tests and things against your application code base.

You wouldn’t just find out it’s broken when you deploy it to production, hopefully you do your best to kind of have some kind of CIA system to make sure you’re catching issues first. Yep.

Ashish Rajan: Do you find that this is quite common, like the whole infrastructure as a code? Is it becoming common?

Cause I think I hear a lot of people talk about the fact that you and I totally believers of this fact that we should automate everything and we should have the infrastructure as code. Do you find that a lot more people are coming into this space?

Matt Johnson: I think from the conversations we’ve been having, it is growing.

The message is getting out there that actually [00:09:00] like. Infrastructure is code is kind of mature enough that this is how you should be running it. And I think there’s also a scenario where, the number of products from each cloud provider now, and the number of dependencies you need. So for example, spinning up, a Kubernetes cluster in Amazon?

Like if you actually look like there’s Terraform modules for that now, because even in Terraform, the individual number of objects, you need like a VPC and a sublet and a VPC and this and this and this and this and this, like it’s, it’s just not really feasible to manage. A cloud estate anymore without infrastructure as code.

So I think purely for that, you know, engineers are lazy in a good way kind of thing. I think, yeah. Infrastructure is codes. Like the only way people are realistically going to get to that problem. And I think that message is as definitely been growing in the last kind of couple of years, that this is now the way to do it.

Ashish Rajan: I thought it was supposed to be a secret between all of us. We don’t tell them we’re lazy. We just charge them for the dollars you spend. But sure. Matt I’m one of the hardworking people just in case my [00:10:00] boss is listening

Matt Johnson: I always say I script badly in Python when I have to.

So, you know, I probably did spend eight hours writing the automation.

Ashish Rajan: Well, that’s the thing. And I love that about automation and I feel like everyone’s trying to do. And I must clarify the point that you, and I are trying to make about automation. It’s not the fact that it just lazy.

It just the fact that while you can work on more interesting things, instead of repeating the same thing again and again so. And I think you’ll find this as more developers or is it more security people or is it a mix of people trying to work in this infrastructure as code security space? Because I do want to go a layer deeper.

And I think, I think you know where I’m going with this, but I’m keen to know. Do you find like an equal spread?

Matt Johnson: Yeah, so I think like everything, it depends. I think there are teams of developers, like. I, you know, the, the term kind of security advocate within like a dev team has kind of started becoming more and more popular, like someone who is a developer and that [00:11:00] developer team, but also like has a mindset to be thinking about security either naturally or like, because the company wanted to make sure there was someone on that team with a security focus and this kind of created that role and giving it a name.

I think you have dev teams with like mindsets like that, where people have either been bitten by security before and you know, really want to ensure that they’re thinking about security as part of their dev pipeline. But then I think equally you also have developers that are just focused on.

Product version updates, deadlines, you know and security is still a little bit of a pain in the ass. And in those teams, you might have a security team coming with a massive, list of check boxes for a given validation or compliance. And you know, there’s still that kind of us and them mentality of security are slowing us down.

So I think you do get both. I still certainly see both sides. And one cool thing about infrastructure is code security is actually showing kind of people, people who are still a little bit reticent and see [00:12:00] security as a blocker, actually, how using automation using infrastructure as code, you can actually turn security into an enabler.

Like it doesn’t have to be. I spend a manual day of my week going through security issues. You know, you can just have that peace of mind as part of your pipeline.

Ashish Rajan: Oh, so, and is that what would be developer first Cloud Security ? I think I’ve heard you talk about that in you, some of your talks, where does developer first cloud security?

Matt Johnson: Yeah. So exactly developer first cloud security or DevSecOps. Cause we seem to need to give everything an acronym these days. Like I’m still in the, over the fact we now give vulnerabilities their own websites and logos and stuff, but anyway,

Ashish Rajan: Oh yes. All of us were being scarred because clearly I’m not going to go into the woods.

It’s my turn into a bitch Fest, right?

Matt Johnson: Just like we had the dev ops movement, right? When suddenly your dev team and your ops team took like, I’m probably going to give a horrible, like recap of dev ops here, but like, you know, the idea that you, you take the two teams, [00:13:00] merge them into one team and they all have a shared responsibility for the entire life cycle of the applications so that, you know, you need to automate.

You need to work with the ops team and the ops team with the dev team, from the very start to ensure logging self-serve, you know, CICD and in just that way, you know, operations effectively then became a you know, a code problem. Right. We started to codify, we started building automation pipelines. We started automating logging and automating health checks.

And, you know, you see that kind of thing with like, in Kubernetes nowadays, like built-in And just the same way, like security teams embedding themselves or becoming part of the responsibility of the dev team as well, like that’s developer first security. So instead of having, you know, your ops and your dev stuff in your dev team, and then security still being a bunch of dashboards and a bunch of tools by a security team somewhere completely separately you’re actually taking the same approach.

How do we. Build those [00:14:00] security checks. How do we build security validation? How do we do that in a co-defined way that doesn’t feel to the developer, like taking a break from that development to go and do some of this stuff somewhere else. And a fine example of that would be So we have a, we’ll talk about open source tools like checkoff and things like that.

But our bridge crew platform, for example can integrate with GitHub to do automatic security scannings of pull requests. So like that for me is a perfect example of like developer first security, the developer raises a PR to merge into their production or their testing, or, you know, whatever branch and in the same tool that already using that already and get home it’s part of their day-to-day workflow.

In there they immediately see an automated comment going, Hey, you’re about to commit some Terraform, which actually is really insecure. Here’s the diff here’s what we’d recommend changing on that. You know, that isn’t, I need to go to a separate security tool and then run a scan and wait for the results and download the PDF or go and talk to the security team [00:15:00] to bless the release.

You know, it’s, it’s exactly what they’d be expecting to see from their unit tests or their integration tests or, you know, any, anything else. Yeah,

Ashish Rajan: I’m with you on that. And I must say every time I’ve spoken about automation and coding to securities, I always got what, why, why, so why is it?

And, and I can totally go into this quite quite a bit, but I think what are you also kind of pointing out as the fact that maybe it’s time that developers should become part of the security team as well, where they can help security bridge that gap? Like a bridge crew bridge that gap into, Oh, this is how you can automate this.

You don’t have to look at all the screens and all the codes coming out of it. If you just. Give me the list. I can automate it if that’s what you want to go down the path of. I love it and I a hundred percent behind it. So I’m glad you’re promoting it, man. I’m glad you’re talking about it as well.

I think something else that you kind of touch on and we’d love to hear thoughts on this as well, [00:16:00] because you mentioned everything was turning into a code and obviously developing land is code when it’s not running in live production. And then there’s code which is just lying in GitHub. Is there like a static code analysis or runtime analysis, dynamic analysis, that kind of stuff , in this space

Matt Johnson: as well.

Yeah. Hundred percent. And, and just on the, on that top yeah, we’ll come back to that actually. Yeah, so static analysis, I’m just trying to kind of mentally keep, Oh yeah.

Ashish Rajan: Maybe we do that. If you want to pause it, come back to whatever, how are you gonna

dig

Matt Johnson: it? No, that makes absolute sense. I was, I was just going to say, like, I you know, you’re talking about kind of you know, bridge crew and kind of trying to provide that developer first stuff.

Like I personally find it impossible to like, Work on things and kind of talk about things that I’m not passionate about. So yeah, the fact that I get to like carry the flag for like dev integrated with security and security integrated with dev, it’s awesome.

Ashish Rajan: Well, that’s why I started the Cloud Security Podcast

cause I could just start voicing this as well that security is changing in the cloud world. It [00:17:00] just. Happens to be a slow change, but I’m glad people like you and I, some of the people who are actually commenting as well that I’m sure I’m glad all of us are here to kind of be the, for lack of a better word, pioneers who are trying to promote this.

Like, Hey, we were for the first. Top people to talk about this. So and now we come to the question about static code analysis and run runtime analysis. What are your thoughts on that?

Matt Johnson: Yeah, so exactly the same as in code. And just like everything else with security, you know, defense in depth, like one or the other is not the right answer.

The right answer is pretty much always all of them or both, or however many you have. So. We have a open source tool called checkoff and it’s spelled slightly differently. So I will try and put that. If you could put the URL,

Ashish Rajan: I I’m going to put that in here. That’ll be easier.

Matt Johnson: Is a perfect example of a static analysis security tool.

So the idea with checkoff is we have a load of Security rules, security policies, you know, [00:18:00] triggers for violations, whatever you want to call them and check off basically scans the infrastructure as code manifests that you’re writing and doesn’t require them to already pre be deployed because like Terraform we support Terraform.

We support Kubernetes. We support helm serverless framework on for Azure. And the idea is because your Terraform is obviously describing. The state of your resources. We can actually look at that configuration. We know what the defaults are, for example, for Terraform. So if you create a resource where the default I’d like not putting a specific item in a Terraform object is an insecure default, checkoff, will say, Hey, you kind of need to say, you know, Encryption enabled because you’re creating this S3 bucket and by default decryption will be disabled and that’s, you know, not good security practice or, Hey, we’ve just seen that.

you’ve passed secrets into the environment variables of this Terraform, and that means it’s going to be committed to Git and you [00:19:00] don’t want secrets in Git, so that would get flagged or, Hey, you’ve just created a VPC and a set of security rules. And the security rules have like zero zero, zero, zero slash zero.

And that will be open to the whole public internet. You probably don’t want to do that. And we can do all of that in static analysis by kind of warning. Before you even think about running that Terraform or cloud formation, or pick your favorite infrastructure as code framework we can kind of go, Hey, that’s probably not something you want to deploy.

And so that’s static analysis, right. And yeah. That still doesn’t mean that you don’t need. To look at the security. Once you actually have objects running in the cloud, because not everything in your account may have been created by infrastructure as code security. You might have a brownfield site where there was a load of manual stuff set up in the account when the account was first created, and you’re still going to want to check those items for, , insecure configurations, open ports [00:20:00] secrets where they shouldn’t be.

And so, yeah, runtime, like check your infrastructure as code for common issues or issues that may become a security issue when deployed and then sorry, bill time. And then runtime, obviously just keep checking the the cloud resources. You actually have live as well. Just to make sure there’s no drift in security posture.

And then there’s also a bit of a middle ground as well, which is, you know, you can also put those static analysis tools, like in your CIC D pipeline instead of just running them. On your developer workstation, so that your entire flow from kind of writing the Terraform on the developers machine, they might validate it just with a local run of the tool.

It then gets validated before it gets promoted in the CI CD pipeline so that you can’t accidentally, you know, ignore an issue on your local machine. And then obviously checking with runtime as well.

Ashish Rajan: I definitely recommend people check out a bridge crew as well, because I think it’s really interesting challenge that you guys are solving in this cloud security [00:21:00] space as well.

There is a recent tweet from Scott Piper for people who may be following him. I think he had been tracking APIs from 2015 that are started off with the old, just 100 or something in 2015. And now we are at about 9,000 API calls in AWS. With about, I don’t know, 500 something services since 2015.

And it blows my mind. And by the way, this is just one cloud service provider. We’re not even talking about Azure or Google cloud

Matt Johnson: that’s what I was kind of saying earlier with you know, it’s just not something that you are going to manage nowadays, without infrastructure as code.

There were too many APIs there. There were too many products, there were too many things that depend on other things. Oh

Ashish Rajan: my God. Yeah. And incident response, because of what someone coming in for incident response next month, and we were talking about this thing where incident response is also not the same as on premise where, Oh, it’s just one server.

No, you could have hundreds. Like the whole auto scaling group and How it dynamically scales in 100 machines, you’re basically promoting the wires into a hundred [00:22:00] machines as well. Like that kind of incident response is like, ah, this blows my mind, man.

Matt Johnson: If I, if I could quickly that just reminds me of something.

I was I didn’t say earlier when we were talking about kind of the need for security to become part the sec and DevSecOps and kind of develop as being in the security team and security team being in the dev teams, as we’ve just said, like there is too much and it moves too quickly now, like to not have to not use code, to solve this problem.

So, you know, a security team. That was signing off on, VMs or physical servers or kind of the security posture or kind of, you know, quality scans to name, like one tool that I’ve, I’ve kind of historically seen used in like large enterprises. , how were they going to do that to your point when there’s an auto scaling group, which is spinning up, maybe, I don’t know, 50 servers every hour and then ripping them down.

Who is blessing those images? What are you doing about Lambdas, which may or may not be getting updated every few seconds? Like there’s just too much [00:23:00] movement to not take a co-defined approach to fix it, to monitoring that.

Ashish Rajan: Yeah. And again, this is just one cloud service provider. Like what if you have Azure and Google cloud in the mix as well?

So. Yeah, it scale is a challenge in cloud for all teams, I guess. I’ve got a question from Casey as well with cloud networking. Is it almost a requirement to learn Yaml Python or Json for a guy with a little coding experience? Should I focus on these? What are your thoughts on this?

Matt Johnson: I, I read that earlier in the, in the chat.

I think. Networking, especially like Yaml, well, you’re, you’re not really sure going to get away from it because no matter which infrastructure as code framework, you write in. You’re probably going to be writing some Yaml or some Json. So, you know, the basic syntax of Yaml and Json and use like an online, like syntax testing pricing tool to kind of understand the basics of that syntax.

I think that that’s necessary in terms of Python. [00:24:00] I don’t think so. I like Python and I kind of bridged that gap between like ops and code and Devin things, but, you know, there’s enough maturity in like Terraform modules, for example. Like learning Terraform and understanding like how the Terraform VPC module creates a VPC in your cloud environment or how you add security rules or how you do VPC pairings and things like that.

I think there’s enough maturity in those objects within Terraform that you could probably just learn an infrastructure as code language and kind of keep yourself away from Python. Unless you’re doing some like really. Like cutting edge customization stuff. I’m pretty sure that the networking side of those tools is pretty solid.

Ashish Rajan: That’s a great answer, man. I think worthwhile calling out because Terraform would make you cloud-agnostic as well in a way, right? You still need to have on API calls for each individual cloud providers, but at least you’ll learn a skill, which is the same with Python as well. So to your point yeah, I can see value in that as well.

[00:25:00] Matt Johnson: I mean, there’s nothing wrong with learning a programming language, for sure.

Ashish Rajan: Oh, yeah. Especially if you haven’t done something before, like just to get that the logical brain working on, how do I follow a sequence? Where does this mean?

Matt Johnson: Right. But yeah, in terms of like, would I put that down as like absolute requirement to kind of start thinking about using infrastructure as code?

Like no, absolutely not. Like try, try

Ashish Rajan: Terraform. Yep. Yep. And I think by the way, if you’re learning Python, but in Python three, not 2.7, say

Matt Johnson: 3.3 0.9, are we on now? Yeah. And

Ashish Rajan: I have a question from Vineet aswell. So what kind of specific training do you recommend for developers who are new to IAC?

Matt Johnson: Yeah, I saw this and I went crap. I don’t have an answer to that. I think

Ashish Rajan: I was going to say with infrastructure as code security, I usually, depending on which cloud service provider you’re working with, , we only spoke by the fact that the AWS has 9,000 APIS to deal with.

If you have the cloud service provider that you already preferred [00:26:00] in your organization, AWS Azure, Google cloud, most of them usually have like a ready to go template on their websites from how to develop an infrastructure. That’s a great way to start in terms of training. There’s a lot of DevOps training.

There’s a lot of automation training with the talk about it. They talk about how to use our Terraform, how to use Jenkins and all these things, but these are just tools for enabling you to do the infrastructure as acode. So I normally would just start with the cloud service provider and see what they have done because they don’t normally have a service.

I think you have cloud formation templates for AWS template for Azure, and the same goes for across the board, but. It depends on the provider you choose, but most providers would actually have like a template for, to start with.

And then you start layering that with Terraform or Python to add the automation to it. I don’t know. What do you think, man?

Matt Johnson: Yeah, I agree like there’s so many kinds of free resources available. Like more and more people, [00:27:00] especially with kind of COVID and the fact that we’re not traveling as, like, I’m just seeing so many, like good online resources.

It’ll completely depend to Ashish’s point what are your requirements ? Which cloud provided you care about? What problems are you and your team trying to solve? I definitely think like having a project, like having a mini goal in mind, like. Pick something you want to do, and then start reading down the line of how you will do that. Googling and online resources. And I think trying to just learn infrastructure as code. Doesn’t particularly work. You kind of just want to pick yourself something you want to achieve and kind of follow that path to learning the bits necessary because everyone has their own, like slight opinions on infrastructure’s code and the best way to do it and the wrong way to do it.

And you’re better just focusing on a particular challenge, I’d say. And even if that’s just a tiny a tiny little goal we have another open source itool called air IAM

and one of the cool [00:28:00] things that can do is basically connect to your AWS account, take all of your IAM roles, users, permissions policies, and convert it into Terraform.

So even if you, and the idea being that you can then start managing your IAM configuration. As codified, you know, so you can commit it to Git you conversion it. You can track it, you can then see, or you can use that kind of snapshot of state to check drift detection for your IAM environment. In fact, we did a blog post kind of hacking that together in a little CICD pipeline to kind of take that snapshot and then compare it.

With a diff tool against a future version to see if your, IAM config changed. But for example, like even if you’re not planning to use that Terraform, what you will end up with is a set of Terraform, which replicates your IAM configuration. So it might be cool to go and read through that Terraform to kind of understand how that translates to the things you actually have in your.

IAM environment. There’s also another open source tool called Terra forma, which does exactly the same for kind of other AWS objects, like EC2 VMs and things like [00:29:00] that. So that could be a cool way of kind of taking a snapshot into IAC of what you already have running and kind of use that to learn like, Oh, okay.

So this is how this is represented in Terraform. That might give you a really good, good starting point.

Ashish Rajan: Yep. Perfect. And I think we’ve got a good response from Kevin as well honestly, I’m liking power shell. A lot recently because it’s now cross-platform support by both Azure, AWS, nice way to board the CLI like running single commands or running a full script.

But I agree with the host languages, when that represents is the simplest. I hadn’t realized partial was cross platform. That’s good to know.

Matt Johnson: Yeah. I’m also intrigued what he means by supports by AWS. I’m going to have to add that to my list of things to go and research. Does that mean that like the AWS, the, the U S CLI has like auto-completion and like some, like some PowerShell, like objects to make it work really well,

Ashish Rajan: or, yeah, so I know for sure, partial definitely allows you to install AWS CLI.

There is another [00:30:00] one. Sometimes software test engineers are great for automating security since they like to think about breaking things versus just happy. My code works. That, that yeah. What do you think of

Matt Johnson: that?

Yeah, I think that’s kind of what I was saying before about like the different mindsets you do get some, like. Kind of security focused developers that want to be that security advocate and maybe QA test engineers are actually kind of a perfect candidate for that role within a team. And then you get developers that like, yeah, just need to get the code working and get it running.

Like, you know, meeting the deadlines. Maybe you have like a really angry product manager. That’s, you know, breathing

Ashish Rajan: down your neck. That’s right. All our product managers are nice. They just want deadlines and features. Kevin just shared a link. So it seems powershell is a code cross platform across windows, linux and MacOS

you’ve made us learn something now. That’s cool.

Matt Johnson: Microsoft’s doing that whole, like, Microsoft’s like really embracing the whole [00:31:00] open, source bandwagon thing. Aren’t they at the moment?

Ashish Rajan: So it’s a great podcast to be bringing this up as well, because we’re going to go into the whole open source versus paid versions as well.

I was going to bring up that, but going back to our actual interview thank you guys. And keep those questions coming in. In terms of, we spoke about the whole static analysis and runtime analysis. And I believe bridge crew has a few products in this space as well. We mentioned checkov already. You mentioned air. IAMalready. And for people who don’t know, and I know there not that many, but are there any open source codes that you can source code names that you can share and what do they do, I guess?

Matt Johnson: Yeah, sure. So certainly for us, we have a checkov, which is You know, static analysis for infrastructures code security.

That’s. If, if you take like one command to try downloading and run a PIP install or brew install, checkov. And just try running it against a directory that has either some Kubernetes or some cloud formation or some Terraform in it. And the cool thing with that is community [00:32:00] contributions of the security policies that it checks for by default are actually in the code base.

So there’s no like downloading a tool and then have to go and get a rule set from somewhere for that tool. Like we have like 500 plus policies out of the box. So that’s a really good place to start, like in the world of infrastructure’s code security, we’ve also got Air IAM, which I just kind of touched on, which is designed really thelp you.

Codify and also look for issues in your IAM configuration, like misused roles, unused users, users with passwords that, you know, should have been rotated. And haven’t things like that. With that also got a load of training resources that might be really useful regardless of, you know, whose open-source tool you do and don’t use for your IAC security.

So we have the goat project, so we have Tera goats and CloudFormation goats. And they are basically purposely vulnerable git repose with a load of really badly written in secure infrastructures code in there. So the Terraform one obviously has a load of an [00:33:00] insecure Terraform. We’d like all the bad defaults and all the security misconfigurations and that’s really good for like running these IAC security tools against if you don’t want to run them against your production code, if you’re just learning, if you’re trying to understand what the tools can do for you Those allow you to kind of have a really good test bed to kind of see what those tools are trying to protect against and to kind of see how those tools another one I’d love to shout out is Kubernetes goat, which isn’t one of our projects.

But yeah, the guy that Wrote that has done a fantastic job. That’s a really good learning resource for Kubernetes security in general. Like there’s some misconfigured insecure, manifests that work really well with tools like checkov, but then there’s also kind of information going into like, some of the vulnerabilities within the Kubernetes cluster itself and how that might be exploited and how you protect yourself.

Like it’s a, it’s a wonderful resource.

Ashish Rajan: Thanks for sharing that. I’m glad that you bought the tools and the open source.

Vulnerable Tools that you’ve been working on. And I’m going to go back back to what Casey was asking about earlier. [00:34:00] These could be a great way to start for what not to do and what not to deploy in production as well. I think there are a few other projects. I think if you are into just learning about cloud security, as well as the person named Scott Piper, he has some really awesome resources.

I think he started the flaws.Cloud as well, which is like a great place to go in and have a look at. What a vulnerable AWS environment would be. Although there is an opportunity for people to create something similar in Azure, as well as Google cloud.

But these are great tools, man, but. I was going to say for people who may be starting off, where should they ? Cause it could be all whelming that we’ve already listed.

I at least 10 tools right here. Or 10 open source repositories right here. Where do you start?

Matt Johnson: It’d be remiss of me kind of not to highlight this because Kristoff’s done a great job of kind of taking kind of checkov and other open source IAC security tools and kind of doing a bit of a showdown and kind of showing the differences and showing how you write your own custom checks in each one and kind of really going through like the current [00:35:00] landscape of open source kind of.

Infrastructure as code static analysis tools and it’s, it’s a wonderful write-up. So I just wanted to share that with everyone. And then, yeah, very, very similar to the, where would you start to learn infrastructure as code? Question I’d say , have a goal. Everyone will have an opinion, like everything else online, there will be

Ashish Rajan: impartial opinion,

Matt Johnson: right?

Yeah. Yeah. Like how, you know, everyone will have an opinion which may or may not be marketing and may or may not be technical. You know what I mean? Like half of the jokes you will find on any search for any of these topics will be companies trying to sell you training. Half of it will be a marketing opinionated version from XYZ company.

You know, so I think definitely having a goal is important. And one thing that you will find is unless you’re kind of in a brand new environment, chances are there will be security violations, right? There will be things in your current environment that need fixing. [00:36:00] That can be really daunting.

So for example, you know, imagine running a tool like checkov against TeraGoat, you’re going to get, I mean, Tera goes intentionally vulnerable, but you’re going to get hundreds of security violations and that’s not a particularly good feeling for trying to get started in security. So I think one of the things I would say is like, as you go through and like run these tools

try and find tools that don’t require you to do kind of any major overhaul, like find the tools that you can and really easily just add as an extra command in your CIC D pipeline, or you could run them locally, for example, checkov against your local Terraform, just to get a feel for them. Like you shouldn’t be rearchitecting things just to kind of, start learning and start getting into the, the IAC kind of security world.

Have a goal, work out what you’re trying to do, and don’t be worried if the suddenly so many things that you think you have to fix immediately. We were actually having this conversation with some community [00:37:00] contributors with checkov. How do you as a security team, let’s say you say tomorrow, right?

We want checkov to be in the CICD pipeline of. All of our company’s infrastructure as code repos. And we’re going to block deployment, if there’s any issues flagged up by checkov you are going to be that security team that we were talking about, where developers then see you as a blocker, not an enabler.

So we were almost talking about like, is it worth thinking about a security tool that yes, there are issues. But maybe only like per pull request or per commit, maybe it just picks the top three of the issues off the list and expects that developer to fix three of the a hundred issues and then allows the deployment pipelines go on.

It. Doesn’t allow you to introduce any new issues, but if there’s already a massive backlog of security issues, you accept that they are not all going to get fixed immediately it’s better having that information and understanding. Your security posture and your security footprint.

[00:38:00] Like even if you’re not going to be able to fix it all immediately after, so don’t be scared of the output, I guess, is what I’m trying to say in a really roundabout way. It’s better to have that data. It’s better to have these tools and understand. And also you know, don’t kind of question yourself either.

You know your code base, you know, your customer, your product, your app, whatever you’re doing, like security tools are going to spit out general security violations. It might be that that security violation doesn’t apply to you. It might be that you actually have a reason why you need that to stay as it is.

It’s not gospel as they say, don’t be worried about all the violations. It’s better to just kind of understand the state you’re in and then work out like where to go from that.

Ashish Rajan: Hmm. That’s a good response, man. And this is a good point because you may find that a language which you were comfortable with. Like, I think we mentioned python earlier, but someone might find TypeScript is much more easier for them to understand. So there’s something for everyone.

It just said you need to find [00:39:00] what’s the one that works for you. I definitely feel it can be overwhelming Rome. Wasn’t built in a day. So one bite at a time, my friends and I love the fact that we have so many people who are actually passionate about, do want to call out Kevin and Catlyn as well, man.

Like they’ve opened my eyes towards the whole powershell world that I was totally ignoring for all this while. That there is so much opportunity there as well that we could be working on. So if, instead of python, powershell is where you rock Oh my God. Like there is a cross-platform opportunity there as well.

So there’s so much more to this space then I guess, and I did want to kind of one more thing with people with no security background as well. Do you reckon they would still be able to take advantage of the open source tools, I guess, as long as you’re a developer, I imagine.

Matt Johnson: I think this is probably where the build versus buy comes in. Honestly, like, cause there’s a, there’s kind of a you know, that whole, I’m not going to use the right word here, but that whole fallacy of like, it’s free, it’s [00:40:00] free and I’m going to use it because it’s free. And then you realize that you’ve just spent like three man months.

Integrating the free tools. And obviously if you’re being paid away, suddenly that tool isn’t free. So if you kind of have no security knowledge at all, or if you’re kind of a dev team that knows you need a security team, but you kind of don’t have a security team in your organization. Yeah. That’s where I definitely say it would be worth.

Almost paying for products that like almost give you like a virtual security engineer. So I’m obviously going to shameless plug bridge crew because that’s what we try and do. We take all of the kind of scanning and checkov and Air IAM and kind of drift detection and try and build that into a, integrated, easiest kind of click it’s done way of kind of giving developers that security insight.

So, you know, if you get an issue in a pull request saying, Hey, you’re about to commit some insecure Terraform, it will give you a link where you can read up on that particular security issue, why it’s a policy violation, why it [00:41:00] matters and almost kind of be that that extra security person and, you know, similarly for security tools for.

Code scanning. Yeah, go, go find tools to help your team there. If it’s a developer that wants to kind of move into kind of being a security professional, obviously I’m never going to say don’t do that because it’s an awesome industry and a, an area of the industry to be in. But like, if you have like deliverables and deadlines and you just know that you have that gap that’s probably a good build versus buy conversation.

Ashish Rajan: That’s awesome. I was going to say to any developer listening, if you’re trying to get into security, it’s a great field. Get into it. We need more developers on the security side. Just Saying because we definitely are trying to bridge the gap. I want to keep using the bridge. That analogy. Now

Matt Johnson: I’m stealing.

Yeah.

Ashish Rajan: Bridging this

Matt Johnson: and into security. We do podcasts and drink beer. It’s awesome. Yeah,

Ashish Rajan: that’s right. I think I was going to say in terms of. A hundred percent supportive developers getting into the [00:42:00] cybersecurity space because we definitely need to fill the gap. And it also was while calling out that it’s an industry which has enough resources out there to help you start that journey.

I think we’ve already spoken about some of the tools already and to your point about the best tool for the best job. Like if you want a team, which has, I dunno, nine cloud security engineers and 50,000 developers, and you can, you guys can codify the whole thing. You then you, maybe you might think that, Oh, I don’t actually need a paid version until you get to that point.

But if you are like a really small team and maybe even one person developer, one person security in a startup, maybe sometimes the paid option may be a better option. So yeah. I think you play it right?

Matt Johnson: Yeah. And it might be that, you know, that just gets you to where you need to be. Like you’re solving your immediate issue within your team to kind of.

Overlay that necessary kind of security oversight and security scanning into your team. But you know, if you’re interested in the security side anyway, like that doesn’t stop you then [00:43:00] getting really into reading the violations, understanding it. You can almost use that product as like, you know, known good knowledge in the field of security to kind of start learning and understanding and kind of, you know, becoming more security minded yourself and kind of start your journey that way.

Ashish Rajan: I’m going to switch gears now, but I think we’ve been talking about infrastructure scored as security for some time. And we touched on an open source versus a paid version as well.

Conscious of the hour that we have. How does one start in the whole open source space? Right. Like, I think we might have people over here. They want to contribute the heard, all these tools what am I looking at? I’m like making my own repo, solve my own problems.

Like where do I stand in this case?

Matt Johnson: Again, it will depend on like what that person’s trying to achieve. But like all the open source kind of security scanners, like obviously I’m gonna kind of focus on checkov, but as I said, we kind of. Have the checks out of the box as part of the code base.

So you can also write your own checks if you don’t want to kind of open [00:44:00] source them. But yeah, if you want to contribute, like one of the easiest ways to contribute to kind of security posture is if there’s something you want to check for in your environment, that isn’t one of the default checks, write a check and submit it as a pull request.

So not only is it then going to be by default in all the future versions of Checkov, you may or may not use it. Across your infrastructure. But they’re super simple to write. And because they’re all already in the code base, there’s a load of examples to kind of go and look through and learn how to write those checks.

Yeah. So definitely kind of contributing checks, whether it’s to checkov whether it’s to any other kind of open source security policy tool, I’d say that’s probably. Like the easiest and would definitely be a really well-received routes into contribution.

Ashish Rajan: I think so. And to your point, if they find that , their problem is really unique, you could still make your own tool and add that as a check in to checkov or any other open source tool of your choice, because that for you’re giving it out to the community as well.

So other people [00:45:00] can benefit as well. I think it’s kind of like the whole. You’re sharing your knowledge kind of a thing. I think this is the same way we’ve been talking about all these different technologies and 9,000 APIS and everything. I think we’ve only reached to this point because there’s a lot of people who have contributed and nto i the space and saying, Hey, I’m not going to keep this secret because I think it was generic enough and nonsensitive enough that it can be shared across other people can benefit from it.

Like that’s how I see the whole open source

Matt Johnson: completely. And, and certainly within the kind of security open source community. It’s a friendly group. Like one thing I would say, like, if you’re not sure where to start, but you know, you want to contribute, join a few slacks reach out to people, tell people you’re looking to contribute.

Like it’s a pretty friendly group from what I can see. Even that message would, I’m sure it’d be appreciated.

Ashish Rajan: Yeah, well I did coffees and apparently Matt takees beer and coffee. Yeah. That’s right. Reach out and do that. They can do, we can do that as well. All right.

[00:46:00] That’s really late in the night for you as well. I do respect the fact as well, man. Dude, this was awesome. So where can people find you if they will have any follow up questions or a want to talk to you more about this as well?

Yeah.

Matt Johnson: Love to we’re building a community for. People that want to talk and learn and get involved in codifying security. So this whole thing of adding security into infrastructure as code automatically kind of scanning security, everything we’ve talked about. So we’ve got the codafide security Slack, and that’s at Slack.Bridgecrew.io.

But if you are, if you’re not ready for the full commitment of another logo down the side of your Slack app, then just reach out to me on Twitter. I’m at Metta Hertz. Yeah. Love to carry on the conversation. Any more questions, things like that.

Ashish Rajan: Sounds good. And I’ll, I’ll make sure I’ll include the links in there as well in the, in the show notes.

So people can actually get to it. But this was awesome, man. Thank you so much for spending your time with us. Well, I got a lot of value. Sounds like those episodes that I’ve actually learned something new as well. So [00:47:00] shout out to the other folks. Who’ve kind of taught us something, but thanks for coming in, man.

This is really awesome. Really

Matt Johnson: appreciate it. Yeah. Thanks for having me on I’ve. I’ve really enjoyed it and I’m super jealous of your green screen by the way. It looks great.

Ashish Rajan: Yeah, this is me before COVID, by the way, this is this has been a minder of what COVID has done to me

Matt Johnson: reminder a reminder of where you will be after all this yeah, that’s

Ashish Rajan: it in that shape.

But thanks again, man. I really appreciate it. I’ll see you soon then. Thank you. Thanks

Matt Johnson: again.

‍