Jun 23, 2023

Cloud-Native Realm: A Comprehensive Look at Kubernetes Security with Steve Giguere

TLDR;

Kubernetes is not a solution for all. It always depends on the use case. It depends on the growth stage of the company, expertise in the team, and few more. Surprisingly, monoliths could be a better solution sometimes.
Automation is a key practice while adopting Cloud Native Security. Shift Left by Integrating security practices like Policy as Code, SCA integration in the pipeline, Code Signing, SBOM generation, etc.
Software Composition Analysis and SBOM are important when adopting Open Source tools. Trust but verify. Use solutions like Image Signing, SLSA framework. Integrate with CI/CD pipelines to have a clear understanding of the dependencies and their vulnerabilities.
Prior to adopting Open Source tools, do a deeper analysis in terms of support from the contributors, community, release frequency and engagement. To avoid any security & operational risks in future. Also, contribute back upstream so that others can benefit from it.

Transcript

Host: Hi, everyone. Thanks for tuning into another episode of Scale to Zero. I'm Purushottam, co-founder and CTO of Cloudanix. Today's topics include cloud-native security, Kubernetes security, and DevSecOps. To discuss on these topics, we have Steve Giguere with us. Steve is a developer advocate with Palo Alto Networks, specializing in cloud-native application security and automation into cloud security, Kubernetes security, and DevSecure. To discuss on this topic, we have Steve DeVayer-Simmer. Steve is a developer advocate with all of the networks specializing in cloud-native application security and technology. Prior to this, he was a cloud security architect specializing in containers and Kubernetes, and it's been several years establishing DevSecOps best practice.

Prior to this, he was a cloud security architect specializing in containers and Kubernetes, and additionally spent several years establishing DevSecOps best practices for enterprises who are moving to cloud. Steve, it's wonderful to have you in the show. For our viewers, a few who may not know, do you want to briefly share about your journey?

Steve Giguere: Yeah, no problem. Thanks for having me on the show. This is really great. My journey, okay. I started life writing code, like a lot of people do. And from there I expanded into managing other people who ran code.

I took a bit of a turn and I got into what I guess is called code craftsmanship or code quality for a while. Of which there are several very prominent figures in that space and then craftsmanship turned to security somehow. And then suddenly I became all about security of code. I became very involved in what would be called maybe traditional application security. So anything OWASP related to the top 10 getting very into coding.

And then from there, as the world seemed to transform and DevOps took over, cloud transformation became a thing, Kubernetes became a word we knew from something that made no sense at all. And now pivoting from Kubernetes to containers to cloud and now infrastructure as code and now supply chain, it's been a pretty wild ride.

Host: Right, that's an interesting career that you have. And yeah, I look forward to learn some of those as part of the podcast today. So let's start with like, How does it what does it do a day in your life look like today?

Steve Giguere: Well, it's a pretty good day in my life in that no two are the same. I don't know if that's what it's like for you. I spend a lot of time traveling around the different conferences for CloudSec and AWS Reinforce coming up very soon, having just come back from RSA and B-Science in Las Vegas and preparing content. I work regularly with our product teams, looking at innovations, talking about the general landscape of security and what...what priorities we need to focus on.

So I'm very heavily involved with product development still. I'm an active contributor to open source still, keeping my knives sharp in that sense. So day to day, it can be anything and everything around software security, but largely just trying to get the word out, like yourself with the podcast and with what you do, trying to raise awareness, make developers more secure by default. This is really what it's all about.

Host: Oh, yeah. Looks like you have a lot of things going on. You're sort of working with the product team. You're working on open source and many different areas as well. So yeah, it's a pleasure to have you in the podcast. So thank you for coming.

So the way we do the podcast is we have two sections. The first section focuses on security questions. Second section focuses on rating some of the security practices. So let's start with the security section, right? So you spoke about cloud native security. So

When we say cloud-native security, what does it mean?

Steve Giguere: Sometimes it's able to define cloud-native security by what it isn't. I think it's very interesting. There was a while, so the CNCF or the Cloud Native Computing Foundation released a glossary. It wasn't actually all that long ago of cloud-native terms. And some of the key ones weren't there, like cloud-native and cloud-native security. The ones you really want were the last. I don't even know if they're there now, but when it first was released, there was no definition for it. Right?

because it was so open to criticism. If you take it as what cloud native is, meaning born in the cloud, then it's an understanding of the vast connectivity of resources and code, applications and orchestrators that happen within there, and the attack service and attack vectors that can be associated with that. And of course, how to proactively, ideally proactively, remediate risks before they become vulnerabilities.

But of course at the same time have enough observability in place to be reactive when necessary and translate all of that information back into being a more proactive approach. So it's a cloud-native security feedback loop is ideal. But that's not really where it ends, is it? Because somebody who lifts and shifts or uses a model lift to microservice approach to moving something into cloud, they're still going to the cloud-native conferences.

There's no word for that. It's your cloud. So it still applies, but then there's another facet to that because moving an existing monolith into microservice often means you have issues with training, with employee understanding of what the new attack services look like. They might be familiar with what a monolith and server model looks like, or even some on-premise. So suddenly, there's a whole transformation element involved there that means.

You've got a serious change management issue on your hands in terms of understanding security in that space. So cloud native in its purest form is complicated to say the least, and even made even more complicated by some form of cloud transformation. It's amazing. But we're all caught in the middle of this tornado.

Host: Yeah, it's funny that you highlighted right that it's not very clearly defined. I have heard from some folks who say that cloud native security is Kubernetes security and I'm like not exactly right. So that there is that confusion. So I would like to understand like

How is it different from let's say the traditional security. Let's say as an organization, I'm trying to move to the cloud.

Cloud Native Security versus traditional security practices. How would you see them as different?

Steve Giguere: Well, I guess now you've in a way you've inadvertently asked me what traditional security practices are. And I'm probably at risk in trying to do that, but I'm going to try. I think there was a time, let's say go back to like 2014, 2015, where there was a lot of pressure. People would think their go-to tool would be maybe a static analysis tool. Open source usage wasn't as prominent as it is now, where there are, choose your report.

Most applications are about 80% open source, maybe more if you look at the entire supply chain, for example. But back then, a lot of people did a lot of building themselves, a lot of creating of their own open-source projects that weren't quite as mature as they are now. And most people really were not using Kubernetes. And if you were, well, good luck, because it was a mess. And from how it worked in its early, early stages to it's having zero security controls whatsoever. But...

It traditional practices were really, really focused on your code, secure your code. And then there were companies that came out looking at dependencies, but really only at the first layer, not so much dependencies on dependencies. And then we were then, then when we pen test it and it was slow and we would release and if I have companies I worked for, if we released quarterly, we were pretty happy and then, and, and yeah, you, well, yeah, that was, we were thrilled.

And then things started to speed up. DevOps became a thing, fast builds became a thing, and a lot of the traditional tools, I think security got a pretty bad reputation for being a blocker. I mean, legitimately so. Static analysis tools were slow, they were accurate, they were comprehensive, but they were slow. And we got a bit of a bad reputation. People started coming up with new methods of...isolating what was and wasn't high value, some new interesting ASTs like IAST, which would plug into runtimes, specifically for Java, and those are great, but very, very difficult to implement in reality.

So once we started moving into things that were microservice-based, I personally, this is not reflecting any company I've ever worked for, found...traditional, let's say, application security static analysis tools to almost become irrelevant. They started to... The tech stacks fell into the hands of small DevOps teams, which means now we're using Go, we're using Rust, we're using languages that static analysis tools mostly didn't understand, and actually weren't too bad at just being secure by default anyway because we learned from our predecessors. Now we started amping up the open source usage.

And things like SCA, or software composition analysis, became, OK, maybe this is now top of mind. And then we started to use declarative languages for provisioning our cloud. So suddenly, cloud security posture management became a thing. We better check we just did that right in the cloud. And then we shifted that left. And then we started realizing, well, maybe static analysis for infrastructure's code is a good idea. Let's find it before it becomes part of the cloud.

And all of these methods are a constantly transforming learning process to realize whatever it is we do to try and secure the we're doing now. Developers are going to change it in six months and they're going to do something different and they're going to containerize it. They're going to push it into Kubernetes and they're going to expose all of our ports and now we know everything we thought we could look at. We can't see anymore. And the attack services, we don't even understand the attack surface of the thing that's orchestrating the application we secured.

let alone necessarily the application. So it's, it is, it, everything has changed. That's probably the summary, isn't it?

Almost everything, the things we, everything's flipped on its head. The things we cared about most, we can care about least. And the things we hadn't even thought about are our most vulnerable elements these days. And now we're not, now we're talking about supply chain. The thing that builds the stuff that we're going to use that goes into the stuff we're going to use is under attack.

Host: Right. So you touched on many areas, right? Like moving from monolith to microservices, from supply chain security, starting analysis, a lot of them. I want to dig deep into those. But before I go there, my one last question on cloud-native security is,

What mindset shift is needed for organizations?

Let's say somebody who is very familiar with the cloud-native traditional security and they need to move to cloud native security. What do they need to keep in mind?

I think organizations need to keep people in mind. That's probably maybe a cliched answer. If you look at some of the, some of Microsoft's techniques that outwardly say 20% of your time at least needs to be spent on personal development. That's not to be dismissed.

Things are changing so fast that if you're not allowing developers and ops and everyone in this space, including security, to spend every Friday getting caught up on what has changed in the world as opposed to thinking you are doing the right thing. Now you will not be doing the right thing in one month and understanding that personal development is absolutely critical, not just for being an intelligent and successful cloud into developer, but absolutely if you feel that you're going to be able to secure the result. That I think is, I think it's always been important if you look at any of the methodologies in terms of the DevOps handbook.

But I think it's becoming more prevalent today, because if you're not keeping up in terms of security, then you're falling behind.

Host: Yeah, so I totally agree with you on that, right? Because the technology landscape is moving so fast, your developers need to be aware of it and get familiar with it. So personal development does make a lot of sense. So one of the things that you highlighted is let's say we are moving to cloud native. So we are moving to cloud. We are deploying our infrastructure using some declarative languages and stuff like that. One of the challenges with Kubernetes, which is very similar to how cloud as well, is the misconfigurations, right? It's possible that you have set up some policies which are not following the best practices. So

When it comes to Kubernetes, how should those be avoided?

Steve Giguere: Well, there's a lot of open source examples out there that can, we can talk about open source, I can talk forever about open source, that can check Kubernetes manifests for just basic issues that are wrong. And you can really, you can build them into IDEs like VS code or any of the JetBrains varieties that can tell you what you're doing wrong as you're creating manifests, which is already a start. Thankfully, most people aren't deploying vanilla Kubernetes anymore. They're using a managed service.

And managed services, like any of the big cloud providers, are doing already a great job of providing something that is more than nothing. Kubernetes, in some of its earlier forms, had some great big gaping holes in it that it is, if it weren't for the fact that attackers are often just as behind as we are,

If you could make a time machine and go back to 2018, there's a lot of Kubernetes you could take advantage of. But it's important just to try and shift that left. I'm a big proponent of that phrase, even though it's also a bit of a cliche of “getting developers involved that when they do something, they can eliminate some low-hanging fruit and just creating a secure Kubernetes deployment that wraps their application”. In addition to that, there are measurements, variety of tools that will just check the Kubernetes itself.

Make sure you're using the up-to-date version. Make sure that the API server's not public. There are all sorts of different, very basic configurations of your Kubernetes deployment to make sure that, although your cloud provider is doing their best, make sure that everything is looking secure. This is, I think, a job in itself is to make sure you've got a secure version of Kubernetes, because really, and I'm sure you know this, all it takes is one...overly provisioned moment of some piece of a cloud container that can be accessed. And it's very, very easy to pop out of that. And suddenly you're on the host. Now you're moving, now you're looking at cloud metadata and now you're moving sideways and now you've got IAM credentials and then kaboom, it's all gone. I mean, there's, there was a great example last year of, of, well, I think it was last year where the Nginx ingress, which was used everywhere.

Not only was it a privileged container, but it allowed you to run code that would then have complete root execution, extract all secrets, all everything, keys to the kingdom. It was amazing. And this was considered infrastructure, not even your own.

Host: Yeah, right. Yeah, it was last year when engine Nginx happened. Yeah. And you highlighted one key thing, right? That like managed Kubernetes definitely comes with a lot of security baked in. But when it comes to cloud, there is that shared responsibility, right? So, I'm assuming the same applies to Kubernetes as well. So,

As a practitioner, which area should ignore that I know that the cloud provider will take care of this from a Kubernetes security perspective and these are the areas that I have to take care of when I'm deploying in a Kubernetes world.

Steve Giguere: It depends on your interpretation of the shared responsibility model, really. I had a really good conversation with, he co-hosts another podcast, Mike Johnson. He's a CISO and we were talking about what can we rely on the cloud securing? And in his opinion, the answer was nothing. He said that the cloud provides you with a very secure-able environment.

And as it's Kubernetes now, I would even say it's a very secure-able environment and it wasn't necessarily always. It had a lot of defaults that could catch you off guard. The S3 buckets became infamous for being wide open and unencrypted, but now defaults to S3 buckets are not that. And there has been some corrective actions made over the last few years to make sure a lot of the low-hanging fruit that developers, or sorry, attackers, I should say, developers might get wrong, but attackers are looking for have largely been eliminated.

So I think if you're looking for what you can ignore, I mean, if you look at the headlines from five years ago, most of that should be taken care of unless you've actively turned something off, right? That you've gone against the defaults to make that sort of thing happen. But otherwise, I think that that level of advice is, trust but verify, is never assume that the cloud is going to secure something for you and never assume that Kubernetes, and whether it be a managed service or not, is going to do that for you. It's nice to think it might.

But I think that's a trap that I wouldn't want to get myself into because although they will progress slowly towards the bare minimum of defaults to be secure, they also want you to use the platform. And so an unsecure platform is a lot easier and friendly to use than a secure platform. So there's always going to be a leaning towards ease of use over secure.

Host: Yeah, and the S3 default disabling public buckets that came this year, I think March or sometime they made it public, like they made it default, which should have been from day one maybe, right? And that goes back to what you just said, like the usability versus making it secure. So maybe they chose the usability first.

And then now with maybe like there are so many vulnerabilities or so many attacks that we have heard they might have acted on it and addressed it right. So make sense.

One of the things that you highlighted is a lot of automation right when it comes to creating your own environment so deploying your workloads and I want to touch on sort of mix automation and misconfiguration a little bit right.

When you are using automation, if you do not do the configuration correctly, it can impact, it can leave your environments vulnerable, right? Because it goes through, let's say, your CI CD, your DevOps, DevSecOps pipeline and it gets rolled out every time. So

What role does automation play in DevSecOps when you are particularly focusing on Kubernetes configurations, let's say.

Steve Giguere: I think it's actually essential. You can't have a secure platform without automating your security. And it allows you to create, well, some people say security as code. Some people say policy as code. There are things out there like open policy agent that can do things like this and make sure that you're actually codifying the rules before you deploy things into Kubernetes and you can apply those rules as early as you want. And that would be great if you could do all everything in the ID and everyone did it.

Oh my goodness, that would be a wonderful place, wouldn't it? But you can also deploy it in the pipeline so that you can break the pipeline if you see something's about to deploy that has high business risk. You can create rules around that. You can combine some of your checks of Kubernetes with SCA scans of the images themselves and say, look, we've got a manifest here. It's referencing an image that we didn't build. What are the vulnerabilities in that? Where is it going to be placed? What is the context of my Kubernetes deployment? Is it internal? Is it going to be production?

And you can create far more complicated security as code rules that allow you to make sure that you're actually maintaining a high speed pipeline in terms of deployment, be it that of infrastructure or application. At the same time, when you find something, you know it's real. It could be that you have an image reference that says, I'm going to use this Nginx here. And it's awful. It's like Nginx 117, something really old. But it's just going on to a development server that's going to do something that has no access to any internet, let it go. If you could build that context detection in through automation, it's amazing.

And then worst case scenario, you deploy an admission controller into your Kubernetes. That is, I like to refer to it as the bouncer of the door, who's looking to make sure you're wearing the right shoes and checking to make sure you look at the kind of character we want in this place. That's a good thing to have.

And there's a very remedial style of assessment that an admission controller normally does, just looking for the really bad stuff. But that's just another line of defense in depth. You've got admission controllers, you've got your CI checks, pushing that. You may even have pre-commit hooks that can use tools before you even check in to Git to stop you from doing things. And then of course, maybe I bang on too much about it, but automation that checks things in the IDE, and ideally suggests fixes for you. That would be even better, wouldn't it?

Host: Yeah, I love your analogy of admission controller, like the bouncer into a club, right? So the automation thing that you highlighted, like policy as code is very similar to how, let's say we create infrastructure as well, right? Using like Terraform or Pulumi nowadays to create your infrastructure so that you are in sort of complete control what infrastructure is getting deployed into your cloud. Yeah, makes sense.

Thing that we hear a lot about when it comes to Kubernetes is that it's complex, right? Because it gives you so many capabilities, there are so many ways to do things. Like even to expose your service, there are different ways to you can do that, right? Let's say I'm like I'm running a startup.

We are a growing startup, is Kubernetes the right solution for us?

Steve Giguere: Early on, maybe not. I mean, the reality is, there was a very good article that came out, I think last year, about when to use Kubernetes. Because Kubernetes is an attack surface. It is like everything else. It is complex. It's easy to get wrong. And

At an early stage, particularly in terms of cost, you might just want to go pure serverless, because it's just an easier way of doing things. It can be more secure by default. But there are some very careful architectural arguments, necessarily, about whether you're going to go serverless or whether you've got something large enough and dynamic enough and configured well enough and scalable enough that Kubernetes is truly the solution for you. I like Kubernetes a lot.

For the features that it gives you in terms of resiliency and scalability in terms of all the moving parts. But it's not the most straightforward way to be successful if you're really small. I think it's great for medium and it's great for large. But if I could just define it, when's best for Kubernetes right now? Oh my goodness, that would be, wouldn't this be the best podcast ever?

Host: Yeah, totally. I echo that sentiment, right? Like it always depends on which stage you are in and stuff like that. You touched on cost and that's often seen as another challenge as well, right? And recently there was a blog post from the Amazon Prime video team. They said that they moved from microservices to monolith and they could save up to 90% of their cloud cost. What's your take on this now?

Steve Giguere: Hmm.

I'm assuming then you read the original article by Prime where they showed the architecture that they'd created and they're moving data around, they were caching on an S3 bucket. It was like at a glance, I think in hindsight, they themselves probably looked at that architecture and went, what were we thinking? We got Kubernetes fever or we got serverless fever or we got...

Cloud Native Fever and we just went, oh, we've got to use this and step functions and it's going to push here and do this. And the whole time, we're pushing vast amounts of data around while doing this. I think I saw a reaction article also that I think was in the new stack that had everyone thought, no, I don't know if people really looked at the architecture about it before they said, I can't dare you go back to monolith. And

Some people were fans, some people weren't. I actually am a huge fan of the article because they did the right thing. When you're handling that level of data, yeah, it's fun and creative to come up with the method that they did to do it, but I feel there's a lot of people looking at that design and went, you should have spotted that a long time ago. This is just not a good design that you came up with. Very creative, but not good. So I don't know that that's.

Like that's going to become a trend. I think it got a lot of attention, but I think maybe it woke people up to the idea that it's not great for everything. Monolith still has its place in the world. And this is a great example of when that was correct.

Host: Yeah, and that also sort of highlights that Kubernetes is not the solution for everything, right? It's always depends on your use case, your as we spoke about earlier, like if you're a startup, it doesn't even make sense to invest in Kubernetes that early; maybe monolith is the right solution. So it always depends on your scenario and situation before you pick up Kubernetes. Makes sense.

One thing that you highlighted is that the industry, how it has moved from let's say monolith to microservices. Similarly, adoption of open source, open source software has increased quite a bit as well. And that brought in more challenges, like supply chain security related challenges. We have seen attacks of SolarWinds, Twilio, there was one PyPy and In fact, there was a recent study by Anchor which highlighted that

There are like 85 to 97% of enterprises code bases use open source and 62% of those are vulnerable to supply chain attacks. So from a DevSecOps perspective, what's your take on this?

Steve Giguere: In fact, there was a recent study by Ion that highlighted that there's like 85 to 97% of enterprise that's not working. There you go. Perfect. And there's a few percent of those and one of them is to supply data. Mm-hmm. So.

Well, it's absolutely correct. I think when I mentioned earlier, this is actually a good question because it supports what I said in an earlier answer. The pivot to comprehensive software composition analysis, I think, is absolutely critical because it's something that can be done as early as viewing a pip lock file or looking at viewing anything. Let's go back and be way back to Java and say, POM XMLs or looking at package.json in an IDE.

There's no reason why we couldn't have plugins that say, I see what you're using. You're going to want to bump that, because the version you've referenced has become out of date. It's got vulnerabilities. Tell the developer creating these dependencies. You're not going to be able to check this in until we see the bare minimum of whether this is correct. And that's going to solve quite a few things just out of the box. I think additionally, we've started to become a lot more aware of the depth of transitive dependencies.

I'm sure you know what that is, but for anybody watching that doesn't know what that is, it's when you have a dependency on a dependency on a dependency on a dependency.

And a friend who likes to say it's turtles all the way down because how do you solve the bottom turtle, right? How do you know if a vulnerability in a transit of dependency is even reachable? How do you even know that it affects you? How do you even know it's there if it's seven levels deep? It's quite fascinating. Some experimentation I did last year for some research, which was post-Log4j, Log4Shell research, to see in an average Java application where was Log4Shell. And it turned out almost everybody was using it directly.

And that was their fix. But most applications had four different versions of Log4Shell in their dependency tree at every level, all the way down to the bottom. So inevitably, the first thing you fixed you probably still had it. But it was in something that used something. And so whether it was exploitable is another question, but it was just interesting to see how deep this problem is still probably present out in the world in spite of people having changed their first level line of defense.

So I think it's absolutely critical that 60% of all the world, yeah, I completely believe it. It's just a case of working out how and where things are as long as we, and not to sound doom and gloom, changing the surface and making sure you're doing the bare minimum of just software composition analysis, creating software building materials, making sure you pass those software building materials through the downstream so that people are aware of what you've included. If we all do that better, then we're gonna move the needle in terms of that number.

And additionally, new innovations in terms of code signing and providence with frameworks like Salsa are also going to make a huge difference now. But at the moment, I think that with this to double on Salsa, some of the levels that have just come out with the release of 1.0 are eminently achievable. And if we can all pay attention to things like that, then the entire supply chain working together is going to make, hopefully make those numbers a lot better.

Host: Yeah, that's spot on. One of the things that you highlighted is like software composition analysis or the S-bombs, right? So let's say I'm using an open source library. And generally open source libraries are like the maintainers. They are not doing it full time, right? So let's say

I find vulnerability in one of the packages that I use and the developer or the maintainers are They're not doing it full-time, right?

So, let's say I find..not updating to let's say latest go back latest coercion or something like that. How should organizations address that?

Steve Giguere: Yeah, well, that's another amazing problem that we have. When you're dependent on open source, you have the notion that can be highlighted by some tooling out there of operational risk, which is if you're dependent on a particular package, do you have observability on that dependency in terms of its activity?

How fast are they remedying any issues? How many contributors are there? When was the last time a commit was created? You might really, really like it, and it might really do what you want, but if it's not something that is reacting quickly to reported problems, then you've created an operational risk that is going to give you a security risk sometime in the future.

So these are the sort of issues that you're highlighting that we actually need to get ahead of, because if you've already found a vulnerability and you've reported it, and you're not an active contributor back to the open source project upon which you were dependent, I guess I would say it probably would be a bit harsh, but you created a problem for yourself. If you love an open source project, ask get some of your developers to help and push things back upstream. Add features, become a part of the community so that when you find a problem, you are part of the solution as well.

Host: Okay, so I love your answer like there are two things that I could gather from it right one is do a proper evaluation before you adopt a new open source technology so that you don't create security risks for you in future and the other thing which is more important is if you like the project why don't you contribute back to the community right like if you see there is a gap fix it and push the fix to the upstream others can also benefit from it and that's the in a way the value of open source. So love that answer.

Steve Giguere: Yeah, it's a prominent problem. I don't know if you remember how long it was. It's again, within the past year, the author of, was it Colors? And sabotaged his own project because no one was contributing back upstream. He was just doing all the work and millions of people were using it. And he just got fed up and ruined his own project. And it really messed with the world.

Host: Yeah, yeah. Yeah, I mean that again goes back to, yeah, right. That again goes back to like it should not only be consumed, right. You should also give back to the community so that others can also get benefit the way, let's say as an organization you are getting benefited out of it. So yeah, contribute to open source. That should be part of every organization's sort of KPIs in a way, right? If you're using open source, you should contribute back to the open source as well.

Host: So, speaking of open source, there are so many open source tools available, right?

Steve Giguere: Yeah, sure. Do I want my incredibly biased answer first, like being the one I work on? That would be Chekhov. I'm actually blatantly wearing a Chekhov t-shirt now. It is a scanning tool. It's free. You can get it at Chekhov.io for infrastructure as code. It started off as a Terraform tool because born out of just obvious frustrations with Terraform very easily extended into things like cloud formation and serverless templates.

And now it does Kubernetes manifest, but also including Helm and Customize, because those are abstractions from the traditional YAML. So it does all of that level of checking. So that, big fan of that, we're just working on now and having just released the idea of...graphing connectivity between resources, because as you know, a manifest has a lot of dependencies. And so you can see connections between deployments, service accounts, the access control of that service account, our secrets connected to all of this is now gonna be part of an open source project, which is amazing what it does. It's a never ending labor of love. Outside of that, free stuff.

I think, well, most people, I think, trivy for container scanning has become kind of the standard. Everyone uses it. It's fast. It's unbelievably quick. I think that's a no-brainer in using something like that. I could go on too long. In terms of observability, there's a lot out there that is completely free and completely amazing.

Actually, I almost want to ask you, throw one into the pile, because you must have a favorite open source tool as well that you like. Or you can plug if you want. Ha.

Host: Yes, sure, sure. So there is a open source called Signoz. They do open source observability. Like since you were speaking about observability that I could recall that. And they are doing amazing things when it comes to observability. So yeah, I would definitely ask our audience to check it out.

Steve Giguere: Yeah, that sounds awesome. So now I'm going to have a Friday show that I do every second Friday on Twitch. And in every single one, I try a new open source tool. So I have a growing list of things that I want to try to see how they work. S-bomb generation, there's a lot of free stuff around there sift and things like that. These are these are becoming standards in terms of making sure uh have I hit five yet? I mean the thing I can give you 500 that's that's the problem I'm trying to I don't want to I don't this is like when you

And we're talking, it's like when you're talking about, trying to mention say thank you because I just won an Academy Award. Inevitably you forget someone that you meant to mention. I'm gonna do a completely unknown one.

There was, and it's one that we're working on as well, which is, I'll be able to plug again, sorry. But it's called Your, it's Y-O-R. And it embeds into the CI-CD platform and automatically get details both based on commit and on the resource itself and adds tags. Because you can add tags to anything in infrastructure's code, right? Whether it be labels or whether it be specifically tags. And it automatically creates a set of very cohesive and trackable tags. And we've started using this for cost observability in cloud platforms.

Because you can track the moment of the tag back to a specific get, which means you know the owner and you know, the team and all of this information, just based on strategic tagging of resources, be it Kubernetes or cloud, you can suddenly glean all of this information that you just didn't, you just did not have before.

So right now I'm working with the team on how to do this for Docker files so that you see a Docker file built. Now you can tell every instance where that Docker file the image from that specific Docker file is now running, should something happen. It's just this code-to-cloud traceability tool that was just very difficult to achieve before. And if it gains traction, we're thinking about a CNCF donation for it. If it works, and once we get all the bugs out of it, it'll be pretty good.

Host: Yeah. No, that's that sounds amazing, right? That sounds amazing because tags is one of the key components which is needed for the costing like mapping it to the cost impact. And especially during the economic times that we are going through, everybody is trying to figure out where is where am I being when it comes to cloud, right? So yeah, so what we will do is we will tag all of these projects when we publish the video so that our audience can also get benefit out of it.

Yeah, so yeah, so that's a great way to end the security questions section.

Bonus: Here are a few open source libraries which could be used by organizations to kick start their security needs. Checkov, Syft, Trivy, Signoz, Yor.

Now let's go to the secure rating security practices section. The way it works is I'll sort of share a security practice and I'll look for a rating from your side like one being the worst and five being the best and if you want to add any context to why you think it's a one or a five that would be lovely as well.

Steve Giguere: Okay.

Host: So let me go through the first one. Security processes are a roadblock to business growth. So grant users unrestricted access to the systems and applications so that business growth is not affected at all.

Steve Giguere: Okay. One, it sounds, it's like the worst thing ever. Yes, security processes have a reputation for blocking development, maybe. And that's maybe a bad thing. Maybe that's a, I would say now is a misconception. It's not like we don't have a history of doing it, as I said earlier, but granting unlimited access to everything. Yeah, that's a pretty bad idea.

It goes completely against the notion of least privilege or zero trust or call it whatever you want. That is the total opposite of what actually people should do. However, saying that, I have met several people in startups where that is exactly what's happening.

Host: That was on the spot like I was expecting that honestly the rating. Let us go to the next one which is same incident never recurs. So once an incident is resolved, let us move on to the next incident. There is no need for like a retro.

Steve Giguere: Oh boy. All right. Statistically, I don't think I would ever say what you just said, but I don't think it deserves a one. I think if you've suffered an incident, let's use like LastPass as an example. People think because LastPass has reported breaches several times that you should, I've been told you must leave LastPass and go to another password manager. And if I was using this. And my impression is...

I actually really trust LastPass because they've experienced their weaknesses firsthand. Nothing got out. And I went, this is good. I trust this. I'm not saying it'll never happen again because look at it. LastPass were breached. They thought they fixed it. They got breached again. It happens right away. So it's certainly not true that incidents never happen twice. They can easily happen twice.

Because attackers who have an attack vector pivot the attack vector on the defense. You look at the patch for log4j. First one, create another problem. Next one, next one, there's three. There wasn't until 217.1, I think, where they'd actually fixed it. So to think something can't happen twice, I would assume completely the opposite. If it happened once, it may happen again right away, even if you've applied the patch, because you don't know that the patch 100% works. So I would just say trust would verify at that point.

You did what you could. Amplify and tailor observability around that specific instance so that when it does happen again, you know instantly because you've tailored your runtime security to it.

Host: Make sense and thank you for the examples as well. The last question is conduct periodic security audits to identify vulnerabilities, threats and weaknesses in your system and applications.

Steve Giguere: Yeah, I mean, that's great. That's actually great advice. I mean, depending on how you define periodic, I mean, if we get into the idea of that practice, you want to make sure that when you say periodic, that you are tailoring that definition to the business risk. I've seen versions of security that do snapshot analysis of your cloud, and they do it periodically in a way that I think isn't enough.

I think having continuous monitoring of run time is a far better way of doing things. So the further you get away from production, the more periodic you can be. But I think you're ideal if you can do it under minimal load and under minimal friction. As close as you can get to continuous is really always the best method of security, because it doesn't take very long if your periodic is too periodic to realize that really you're just closing the door after the horse has aborted.

So, well, I think it sounds like a good practice, a solid definition, I give it a four out of five, as long as we are adjusting periodic, related to business risk.

Host: Yeah, makes sense close to continuous. Okay. Makes sense. Yeah. So, the that's a great way to end the podcast. Thank you so much, Steve for joining and it was a fun conversation and there was a lot to learn for me especially. I hope our audience will also learn something as part of the episode.

Steve Giguere: Cool. Yeah, thanks for this. It's been a lot of fun.

Host: Yeah, thank you so much.