Steve Giguere -- Cloud AppSec

Cloud security is on an evolutionary path,  with newer platforms embracing secure-by-default settings. This has led to a significant improvement in security but also adds complexity as developers need to understand these defaults when deploying to the cloud.

Steve Giguere defines cloud application security, describes cloud-first development and cloud complexity, security by default, and the need to broaden AppSec by creating new security personas and being secure from idea to destination. Steve provides many nuggets of insight from his travels, including pointing us to Wing, a programming language for the cloud that includes code and IaC together.

We discuss the consolidation of application security, particularly Static Application Security Testing (SAST) and Software Composition Analysis (SCA). These should not be separate products but must provide actionable insights and be tied together for practical reachability analysis.

We introduce a new segment of rapid-fire questions, asking about what Steve would put on a billboard at RSA or Blackhat and asking for book recommendations. Steve recommends "Hacking Kubernetes," praising its use-case focus and engaging narrative.

We plan to revisit this conversation in a few years to see if Steve's predictions about the security pipeline and other aspects of cloud application security have come to fruition.

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @AppSecPodcast
➜LinkedIn: The Application Security Podcast
➜YouTube: https://www.youtube.com/@ApplicationSecurityPodcast

Thanks for Listening!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Transcript

Chris Romeo: 0:00

Steve Giguere has experienced a wide breadth of technologies throughout his career, spending the aero, telecoms, and automotive industries improving quality, safety, velocity, and efficiency. After spending many years as a solution architect, specializing in Kubernetes security and establishing DevSecOps best practices for enterprise CI/CD pipelines, he's currently a Cloud Security Advocate with Prisma Cloud by Palo Alto. Specializing in cloud and application security. Steve joins us to discuss cloud application security, the complexity that it brings, how it changes security, and predictions on how it will change the industry over the next five years. We also introduce a new lightning round of questions with Steve as our first volunteer. We hope you enjoy this conversation with Steve Giguere. Hey folks. Welcome to another episode of the Application Security podcast. This is Chris Romeo, CEO of Kerr Ventures, and also joined by my threat modeling friend. Well, I guess you're my friend in general too, but my threat modeling friend Robert Hurlbut. Hey, Robert!

Robert Hurlbut: 1:48

Hey, Chris. Yeah, Robert Hurlbut. I'm a Principal Application Security Architect at Aquia and focused on threat modeling, as Chris mentioned, and so really glad to be here.

Chris Romeo: 1:59

Robert, you're also part of the group I collectively and affectionately refer to as my threat modeling besties.

Robert Hurlbut: 2:05

There you go.

Chris Romeo: 2:06

So the, it's a, it's a tight-knit group, but, uh, it's, it's definitely, you're, you're definitely in that, uh, in that population. So, uh, we're gonna talk about cloud application security. We're gonna unpack what that means. But first we're gonna let Steve share his security origin story because I already saw a piece of it and I was like, I really gotta hear this now cuz I'm, I'm fascinated when people's security origin stories go way back into their past. So Steve, welcome to the show and let's dive in with that origin story.

Steve Giguere: 2:36

All right. Thanks Chris. Yeah. Um, uh, I dunno if I introduced myself, I guess I'll introduce what I, who I am and what I do first, and then I'll go into the origin story. Sure. Steve Giguere, uh, if you're reading my last name, that's how you actually say it. It's, uh, it's, it's more complex for like seven letters. Um, and I'm a cloud security advocate for Prisma Cloud, uh, by Palo Alto Networks. But my origin story, more importantly, the snippet you caught, uh, was high school. So this is going back to the eighties, unfortunately. Uh, and we actually, I was lucky enough to have a, a learning system, which was UNIX based, and this is fantastic. It turned out my, my father worked in a university and they had the exact same systems, so he thought it would be fun to bring me home, the system administrator manual for it so I could read through how it was actually, you know, how, how it worked from a higher level. Totally fascinated, saw a few observable flaws, and back then security wasn't all that good. So it was relatively easy to elevate my privilege from just a student to the teacher and just, you know, my lack of imagination of a 16 year old, just to see whether this really worked. I changed everyone's password to Peaches, which was the name of a dog, and sure enough, the teacher couldn't log in, nobody could log in. Class was canceled. In my mind, I was a little bit of a hero. I stupidly told someone that I did this, which then got back to the teacher, which got back to the principal, which then got me temporarily thrown out of high school and banned from the computer room entirely, uh, which was, which you'd think would've put a dent in my, you know, computing career at early stages, but, um, the same, the same father who gave me the book thought, this is ridiculous. So he, he campaigned and said, you can't deny him an education. So they sent me to adult high school at 16, uh, and the adult high school happened to be teaching C programming, so that's like throwing gasoline on a fire. And so I, so I so began my, uh, my career in, in coding and, and my interest in security. Uh, back then though, there wasn't really, there wasn't like you could get into security, you know, the eighties and nineties were just like, let's just churn out largely embedded systems and C code. And so I spent the nineties basically writing code, transitioning from C to C++ to Java. Um, and then from, and then crossing all sorts of different industries. I mean, I was in the aerospace injury, uh, industry for a while where if it doesn't work, planes crash, that's real bad. So I got quite into quality and then got into telecoms and then from there into automotive and then, back into quality, which is how I ended up, um, in the early days at, Coverity, which was a static analysis tool, uh, and now acquired by a Synopsys. And then through Synopsys, encountered the full spectrum of what was considered application security back then, cuz we had acquisitions like Black Duck, we had Codenomicon, who, those were the fuzzy experts that found Heartbleed. And then started Cigital. So we had Cigital individuals. We, we had Gary McGraw and John Steven Finley were part of the team. Uh, we're all about BSIMM and thing and building security in, and, and that, that progressed for quite a while until I, I, I worked well, I encountered situations where any, nothing we did worked. And largely this was the cloud. So the cloud containers. Kubernetes was being introduced. Why on Earth people were using Kubernetes in 2017 blows my mind, cuz it was a disaster back then. Nevertheless. It was, it was happening. And, uh, it, it, it struck, it struck me as interesting and I felt like already then I felt, okay, we need a new approach to this. This is, this is weird. Uh, and then went from there into cloud and container security companies eventually landing at another startup called Bridgecrew, which focused on cloud and infrastructure's code security, which was then swallowed up. Once again, this seems to be a common theme with me by a rather behemoth of a security company, which is where I've landed now, and I am now in what? I mean, this is a sneak preview, but we're actually in the, in the process of changing our entire division to be the application security division. So this is that this doesn't, that was not as short as I meant it to be. I apologize for that. Maybe we can post edit

Chris Romeo: 7:10

No, it's good. We, I always love to hear, I love to hear people's origin stories and, and how the different connection pieces came together. And, you know, you mentioned, uh, kind of a, a, a flash from the past here. The, uh, name Codenomicon. Like I was, I was at Cisco and, and Co. We were a big, like, I think we were Codenomicon's first gigantic customer. And so they would always have us out. They used to do that event at, at Black Hat. It was called Codenomicon, and uh, that was one of my first big speaking engagements I ever did. A friend of mine from Cisco and I opened for Bruce Schneier. So Bruce Schneier was the primary keynote and they put us up before him. And so that's my, I guess, my claim to fame and security that I once opened for Bruce Schneier in Vegas.

Steve Giguere: 7:56

All right.

Chris Romeo: 7:57

Let's talk about cloud application security, though.

Steve Giguere: 8:00

Cool.

Robert Hurlbut: 8:04

Yeah. So Steve, uh, this term, uh, you know, putting this all together, cloud application security. So what is that?

Steve Giguere: 8:14

Yeah, it's, it, I don't know that it's a thing yet. I would, I would like it, I would, it's almost like DevSecOps. I would rather, the security was already there in DevOps and so that the word didn't have to exist, but maybe, and maybe it sounds a little bit forced, but it's, it's a way of. Suggesting that perhaps application security needs a slightly reordered or reimagined perspective. If we're, if we're, if we are being cloud first or cloud native, maybe the order of operations or maybe the hierarchy of importance of what we're doing in terms of app application security might actually be a little bit different than, than what we have considered to be important previously. I mean, I can go way back and if I think of the way, well, actually, the way that Synopsis when I was there constructed their application security platform. The first thing they did, they did was go out and buy a SAST platform. They figured that was the fundamental, it had to be there. And this is what everyone considered step one of application security. And I were to wonder if someone were to build a cloud application security platform from scratch, what would be the first thing they would go and get? Would it still be SAST, or would it be something completely, completely different? And this is where I'm, I'm, I'm. I would argue that it wouldn't be

Chris Romeo: 9:35

So when we think about complexity, you know, when I think cloud and I think application security, these two things coming together, there's definitely opportunity for complexity. And so when you think about cloud first software development, let's start there, cloud first, software development. I guess first of all, from your perspective, what is cloud first software development, but then also as a secondary question, how does that breed complexity for Cloud AppSec?

Steve Giguere: 10:05

Yeah. Well, if you've got the, uh, if you're starting with, with cloud first, generally you're, you're embodying DevOps principles. You're using, uh, Containerization and probably Kubernetes. Maybe serverless. Probably serverless, and you're putting together smaller teams that are interacting with a sole purpose, usually communicating via APIs that that integrated ability to look at an application, say for example, if we're talking about monolith versus microservice, it's a bit of a cliche, right? You're probably going in with microservice mentality first, and having experienced this transformation when I was working with teams and at large organizations, it was daunting to, to try to run tools like SAST when a tiny piece of code out of context of how it actually gets used within the larger application meant that a lot of the code looked very clean. Whereas the system level application, the communication between, meant that we were looking at system level vulnerabilities, not necessarily code level vulnerabilities. So there was already an added level of complication or complexity already with that. Then we've got the concept of if you're putting some coat into a container, you've just handed a un uninitiated or uneducated developer, a piece of the infrastructure and. Obviously we're getting a lot better at that. You know, uh, container scanning tools are a dime a dozen these days and they're largely free. But when this started, this certainly wasn't the case. And you could put something into a container that you could put rock solid code into a container that the container itself had a vulnerability or the orchestration of the container. If we think of, it wasn't that long ago, we had a critical run C vulnerability that was a little bit of a disaster, and we've had any number of Kubernetes misconfigurations that have, fortunately over the years, never surfaced in the wild, which is, you know, luck. But also the fact that adversaries that are out there are as uneducated as some of us. So they haven't really, the Kubernetes made a lot of changes and a lot of added, a lot of secure by default initiatives as it matured that I imagine adversaries wish they had a time machine and they could just go back a little bit to 2018. Because it was, there was just so, so much opportunity to exploit back then. So all the different layers in terms of coding, containerizing, orchestrating, and communicating, and then pushing that into a cloud, which again is secureable, but certainly not secure by default. We've got the, uh, we, we've got our response, the shared responsibility model of the cloud to contend with, and then across all of these different layers, We're still siloing to an extent the way we approach security. So we may have a cloud security team, we probably have an application security team. We might have a SOC that is looking for, uh, runtime security alerts, and they're not necessarily all communicating. So there's, there's, there's, I would say, an incredible amount of complexity if we're going for the cloud first, that we're hoping the advantages outweigh the, the negatives or the threats that might be, that we might be introducing, um, through potential our, our lack of education or our lack of understanding, or a lack of ability to threat model. Something so complicated.

Chris Romeo: 13:32

So, complexity is definitely a challenge when we think about the cloud, but on the flip side, when I look at the modern cloud offerings and I'm seeing so many more secure by default options, That I almost have to actively disable, like I have to make a conscious decision to make this thing's security go down. And so

Steve Giguere: 14:04

Yeah.

Chris Romeo: 14:04

I was, I was working with a client and um, just to give, I'm not gonna talk about who it is, but as, just to give a live example, they had built their original platform years ago. It was running on the cloud, but it was had been architected 10 years ago. They had built a from scratch, a new component of their platform. Both of these were running on the same cloud provider. The new one that, that was brand new, had inherited so many more secure by default settings that they couldn't even go back and retrofit onto the old, they were in the process of, they're in the process of trying to retrofit the original, but it's so much work now to go back and retrofit and upgrade the security settings and not break stuff. Whereas the new versions of the platform have all these secure by default things that they're just like, oh, we just got that covered already, because we never even had to deal with it. We just turned this service on before we started deploying code, and it was good. And it's, it's, it's locked down in so much better states. So, any thoughts, Steve, from your perspective on that transition from the cloud being good, but not as secure to where we sit today?

Steve Giguere: 15:18

Yeah, I, well, I mean, who's gonna complain about that? That's an amazing, um, pro bit of maturity and progress as we, as we go towards the cloud. Um, I was at AWS re:Inforce recently and was particularly impressed by the keynote, where they were introducing a lot of built-in, um, let's say secure, I don't wanna say secure defaults, but that it seemed very much they were providing a lot more security now than, than before where this is, well, most clouds, they look to see, they, they have the advantage of mass observability on how people are using the cloud. And is it, if they turn on a security by default, is, is this the default setting anyway or is everyone gone into a non-default setting and, right, let's, let's just use a zip storage bucket and everyone. It used to be unencrypted, now it's encrypted. But why? Because everyone was turning on encryption. You weren't gonna break everything. It suddenly became the default. So let's make security the default and it's not gonna upset anybody. And we're moving towards that, which is, which is amazing. Now that's not the the be-all and end-all of security, but it's just cer, it's certainly a huge advantage in terms of maturity. I think in terms of complexity, it does mean you need to understand what the defaults are. When you're implementing something that's about to be deployed to the cloud, you need to understand, is this secure by default? Was it last year? And it, it adds a level of complexity in terms of just keeping up and there's already enough to keep up with in terms of security and writing code for the cloud. Already now you've gotta be at, well, or you have to do it maybe what we do, go to every single conference and, and listen to all the keynotes to make sure you're, you know, what's up.

Robert Hurlbut: 17:02

So going back for a moment to this, those terms, cloud and application security, if we're just focused on application security alone and, and keeping it separate, uh, are we sort of putting ourselves as at a disadvantage, uh, by just simply saying that application security is only about applications? And, uh, along with that, And if we also think about the cloud centric, um, and, and security around that, uh, do we need new personas? You know, there's this idea of security personas around application security. Do we need new ones if cloud is in the mix?

Steve Giguere: 17:44

I think it's possible. Well, that's a good question actually. I like the idea of there being, uh, new personas. Um, I, but definitely I think to go back to the original point of the question, are we putting ourselves at a disadvantage? I think we're, we are, we are, we're actually, we're actually not taking advantage of the potential context of our application. If there's a, let's say there's, there's a SAST finding that, that could be cross-site scripting or something, or, or, or the old classic SQL injection, which I realize is not number one anymore, but nevertheless, you know, an oldie but a goodie. But we can trace the, uh, reachability of that, that finding via integration with our cloud observability. So say if we've got, we're deploying our cloud as entirely through infrastructure as code, which would be a wonderful place to be at. And we've got our application and we understand our Kubernetes as being deployed via manifests. Essentially, we're in a wonderful world of everything as code. If there's an ability to take the context before it's even deployed, so we're not, we're not even in cloud yet, and we can see that a vulnerability is reachable. That is, that is a huge advantage. If we can combine all the different elements of what may be used to be considered InfoSec, to use that to define the reachability of AppSec, then I guess my modern argument of cloud application security is that, well then, then, that's still application security. So now do we include the infrastructure's code, do we include all of those other elements that our application runs within because it helps us in application security? Is that now application security?

Chris Romeo: 19:32

When you think about different organizations that you're interacting with these days, do you see a very well-defined line cutting off cloud security and application security? Because when you were talking about the modern application is containers, its orchestration, its infrastructure as code, I guess in my mental model, I think of all of that as application security. I don't think of a delineating point where, no, that's a cloud security problem on the side, but I also don't work in a big company anymore. Like I used to work in a big company, but I don't, and so I've kind of, I guess I've lost perspective on is there a hard line and I just maybe don't know about it anymore.

Steve Giguere: 20:17

Yeah, it's interesting you say that cuz I think you, you hit the nail on the head there. The smaller the company, the more they get it, uh, the more that there is an understanding that everything is code. So the infrastructure or the terraform or the cloud formation, whatever it is that I'm, I'm building, I'm going to run it through some form of static analysis. I'm going to check its references to make sure that if it's referencing a dependency, am I checking that dependency for third party vulnerabilities? Am I pulling third party modules in terms of terraform? So do I consider those secure? Am I running a, to even extend it? Am I running a GitHub workflow? All right, well, my GitHub workflow references a container. Am I checking, scanning the container that's referenced by the GitHub workflow? Am I using a GitHub action? Does that GitHub action use actions? How far am I considering my application, where does it end? It's, it's a bit of a turtles all the way down kind of scenario where we need to look at the entire thing and the younger, and the more startupy the company that I'm encountering, the more they say, yes, of course this is what we're doing. We're going to make sure that the entire application is secure all the way from the inception of the concept all the way to as a running environment in the cloud. This is application security. Now, however, the larger the company, if you, you know, I, I used to specifically work in the financial sector. Um, that was, that was turning the Titanic sometimes to try and get the one team to meet the other team. I, I have been in many rooms where I'm meeting cuz we've requested representatives from, you know, a DevOps representative. We need somebody who understands application security. We need somebody who, you know, who builds and, and secures your cloud. And they're all shaking hands at the same time I am. I'm thinking have I, have I just introduced you all? This is weird. And that, you know, red flags are going. So it almost seems that it is, it, it is to do, you know, we all know big companies move slowly, and I think there's a, a, there's a, an evangelism or a, a bit of, um, socializing the idea that, that, that these, these teams need to almost be integrated by default. They need to follow that DevOps model and say, well, you know, application and infrastructure have combined in DevOps. Maybe we need that happening in security. We don't have a name for it yet, but something that makes us work more as a team.

Chris Romeo: 22:45

So is that kind of your, is that where you're directing us or where you're kind of aiming at here? Because like, I feel like we've, we've defined cloud application security. We've talked about some of the things that breed complexity and some of the challenges that exist there. But I guess now, as somebody yourself who's thinking about this a lot, is kind of pushing this in the industry. Like, what, what do you, what are we supposed to do with it now? Like what's our, what's your dream end goal of like five years from now you're looking back and you're like, this, this, and this happened, and I'm so happy because cloud application security is a thing now.

Steve Giguere: 23:25

That's cool. Yeah. All right. Uh, well, I, I think of it in terms of if I had a clean slate, and this is often what you see when you're dealing with smaller companies and why I think smaller companies are doing such a good job of it. If I'm constructing, how is my, how is my application going to go from its idea to its destination? I'm, I'm gonna have a platform team perhaps that's going to enable that. Maybe I'm going to use GitHub, maybe I'm going to use. I dunno, something internal Jenkins, goodness forbid, uh, maybe a pipeline of some sort is going to be constructed that's going to carry my application out. My first application security job would be to ensure that I actually built a pipeline that isn't going to be the problem. And that for me, that's like now, it's now step one. I wanna make sure that I'm, I, I'm building a secure delivery mechanism and I've ticked all the boxes and I've got whatever tools or automation in place to make sure that that isn't going to be the problem. As we, you know, have seen over the past few years, there's been a few, um, let's, let's say attacks or breaches that have been tampering with software in transit. And I think this is now very much on all of our radars. So if I was starting from scratch, that would be the methodology is to make sure I've got a solid pipeline and then I would go back, you know, to make sure that it was going to go to a solid destination. But I would have to do that via infrastructure as code. So actually I'd be shifting all of this left to make sure that I'm building something and I'm creating a culture of security with my developers, which is a whole other conversation I'm sure. Uh, with, with training and understanding that we're gonna start running software, but that software we're creating is going to have infrastructures code in it. It is going to have application code, it is going to have serverless functions, and all of these pieces are going to interact via different methods of permissions, these privilege and, and, and secure communications. But because we're doing it all as code, let's make sure that we've got something that's secured by default as early as possible. And we have it. We know we, we we're lucky enough to have all of those tools in place. I mean, I, I was actually, interestingly, I was looking at something which I haven't played with yet. There's a, there's a new language, which is, I think it's called Wing or something, I can't remember, but it, it actually, you actually write infrastructure as code and application code in the same language, and it auto detects and creates least privilege IAM policy. Like it's, it sounds bonkers, so I wanna play with it, but to me some those kind of abstractions are. Where I think we're gonna end up going, where we're, we're looking as left as possible so that when we reach runtime, our security operations centers are less obsessed. We're, we're less flooded with alerts and noise, and we're actually, we're getting contextual risk alerts. That if, if that was where we were in five years, I would, I'd probably be out of a job.

Chris Romeo: 26:22

Well, that's, I mean, that's always what we're trying to do. We're always trying to put. Ourselves out of a job. The funny thing is, I've been doing this, I've been doing security for 26 years and I'm still here and I probably got 26 more years at least, and, and then there's gonna be a new set of problems here. But, so if I was to sum up what I heard you say though, let me, let me kind of read back to you what I think you're saying Cloud application security is, just to confirm. So cloud application security is the integration of everything that I need to build, implement, well, implement, build, and deploy a secure application, including infrastructure as code, and everything I need in the cloud. It's, it's, it's unifying these two things together in a seamless way that's automated, it's secure, and it's performant at the same time. Is a fair assessment?

Steve Giguere: 27:20

I didn't, I, I didn't say performant, but I like that you added that.

Chris Romeo: 27:24

I try to work that word in cuz it's, it's one of those words that, uh, you know, I feel like I've, I have a, a, a a good vocabulary if I can work in things like performant. See, I used it again. That's two times. I get two, two

Steve Giguere: 27:35

You sound so smart.

Chris Romeo: 27:36

...credits with that.

Robert Hurlbut: 27:37

The new word of the day.

Chris Romeo: 27:39

New word of the day. Yes. I like to have a word of the day. So, um, let's, let's do some lightning round questions. So I, I feel like we got, I feel like we have a good foundation for Cloud AppSec and I feel like. Steve in five years, we're gonna do another episode. We're gonna do a, so a, add it to your calendar, you know, it's July 13th, 2028. Add that to your calendar. We're gonna wanna do a five year

Steve Giguere: 28:00

I'll be living on an island somewhere.

Chris Romeo: 28:02

...retrospective on this, this cloud AppSec. Well, we'll do it from an island. I mean, that, that sounds like a great plan. Um, so, we'll, we'll definitely, I'd love to, we'd love to circle back with you in the future though. And it's always, With a topic like this, it's always fun to, to do a retrospective and say, well, did, did things happen as we thought that they were going to, or did things go completely different? But let's do some lightning round questions. Robert, I'll Yeah. Robert, I'll give you the first lightning round question. Now. We're gonna try to hold you to like a minute, Steve, on each of these questions. So that's the fun on the lightning ground. It's gonna be snappy. And here we go. Robert, you go ahead. I'll give you the first one.

Robert Hurlbut: 28:37

Yeah. What's your most controversial take on application security?

Steve Giguere: 28:43

Most SAST tools suck. I dunno if that's controversial or not,

Chris Romeo: 28:50

That took like five seconds!

Steve Giguere: 28:52

Yeah. I used to work for one. That's a, it's a good thing. I don't work there anymore. Um, yeah, no, I, I think SAST tools, uh, just a lot of'em don't work, are too noisy, are findings focused. They're, they're not looking at context. They're, they just, they're not designed to be combined with the entire ecosystem. And I, I, I would love to see a, uh, a smarter, greater, better SAST emerge,

Chris Romeo: 29:17

Yeah, it does seem like an area that's has a lot of opportunity for innovation, but there just hasn't been. Anything that you look at it and you go, wow, that's the next, that's the next thing in this space. Like somebody's leveled it up and they've cleared the fence and they're, you know, they're heading towards the next thing, like it seems like it's been status quo for way too long. All right, so the second

Steve Giguere: 29:41

I thought of it. Oh, sorry. All right. Go ahead.

Chris Romeo: 29:44

No, go ahead. Go ahead.

Steve Giguere: 29:46

Uh, I thought of that when... did, did Chris, did you do, you did the State of Application Security at RSA, correct?

Chris Romeo: 29:54

Yep, I did. Yep.

Steve Giguere: 29:56

And you had a number one thing that said application security will consolidate. And I remember you saying, you saying that, and I thought, I hope SAST is involved.

Chris Romeo: 30:07

Yeah, I was, I was, I I think there's gonna be consolidations amongst the market, but also amongst the technologies, because when I think of SAST and SCA, why are these two separate products? They should be the same thing. They're, they're, they're, they should provide actionable insights. They should be tied together so that you're doing reachability analysis before you're doing prioritization of dependency vulnerabilities. Because if you can't get to the code, It doesn't need to be a critical vulnerability. I shouldn't get a page pager alert or set or open a Jira ticket at critical mass for my developers if that's not reachable. But to really get there, we've gotta unify those technologies and, and they've gotta, they've gotta get smarter in, in how they coordinate, um, the, the intelligence that they're gathering. Okay, so second lightning round question. If you could put a single message on a billboard, so at Black Hat or RSA. So this is gonna be a paper billboard, not a digital one. Cause somebody would try to change it on you. Um, paper billboard at RSA with like a single sentence on it. What, what would you put on that billboard?

Steve Giguere: 31:22

Oh my brain went to a automated. Automated. Everything is application security.

Chris Romeo: 31:31

Hmm. Yeah, I like that.

Robert Hurlbut: 31:35

Yeah, definitely. Good. Uh, what's your most recommended? To book about security.

Steve Giguere: 31:43

My most recommended book, uh uh, I could, it depends if I go really retro or whether I go the last one I read, which I really liked. Uh, the last one I had, which I really liked was written by a friend of mine, uh, two, two collaborative friends of mine, uh, Michael Hausenblas and Andrew Martin wrote, Hacking Kubernetes. I liked it because it, it was very use-case focused. It had characters. Um, I, I just thought it was an easy read from a security perspective. It wasn't, it wasn't boring. Not to say all security tools are boring, but, you know, um,

Chris Romeo: 32:22

Was it

Steve Giguere: 32:23

if I were gonna go

Chris Romeo: 32:24

in vein of like, um, was it in the vein of, um, Gene Kim's DevOps, The Phoenix Project? Like it was story based?

Robert Hurlbut: 32:31

No.

Steve Giguere: 32:33

it's, it's, yeah, if you're not right, it's not quite.

Robert Hurlbut: 32:36

no.

Steve Giguere: 32:37

It's not story based, but it does talk about characters and talk about scenarios in a way that is very reproducible so that you can learn in an interesting way. Um, but then I would go way back, you know, like, I think one of the first ones I ever saw was like The Web Application Hacker's Handbook, um, because it was like a attacker focus book, right? I like, I like that rather than somebody telling me, here's how you do a secure, here's how you do secure coding. I like somebody telling me here's how you break things. And then I'm like, okay, that, that awakens me to, without even being taught what I need to do to prevent things like this. So that, that's way, I don't even know what year that was. That's probably early two thousands, maybe. I don't know. Super early.

Chris Romeo: 33:24

I think there's been a couple

Steve Giguere: 33:25

probably almost irrelevant now. Yeah. I might, I don't even know if it's still relevant. Yeah. But that was, that's cool. So if you're, if you're listening to this podcast and you're, and you're young, And you can find it. That's, that's not too bad.

Chris Romeo: 33:39

Very cool. So how about a key takeaway, Steve, or a call to action, something you want the audience to do based on us and our discussion of Cloud AppSec and. You know, the different facets that we went through there and, and the fact that you have to, you know, do a, uh, report or a, a recount of this in five years. any, anything you want our, uh, anything you want to give the, the audiences homework to help you achieve your mission or maybe key takeaways or anything like that.

Steve Giguere: 34:10

Uh, I would, oh, something I haven't talked about that I think is always a key takeaway for me because although I work within the application security team, I work, my coding side still works within the open source team, and so I would, my key takeaway would be don't forget about open source, because there's a lot of free security out there through OWASP and otherwise that if you're a startup or you're looking to apply security super easy in a, in a great way, that's, there's a fantastic community around it and it's a great way to meet new people and fellow security enthusiasts. So that's always plugging open source.

Chris Romeo: 34:48

Nice. What would be, uh, your couple of recommendations of open source security tools, like things in the OWASP universe that a let's, let's use the, let's say an early startup doesn't have a lot of budget. Um, they don't have a lot of budget to buy, go bunch of bunch, buy a bunch of commercial tools. Like what are a couple of things you'd recommend that they start with?

Steve Giguere: 35:11

Oh, I'm gonna be gratuitous cuz I work on a tool called Checkov, which is a scanner for open source infrastructure as code security. I think it's really good. I add to, I add rules to it all the time. So gratuitous plug there. You can, you can go take a look at that. Um, I, I, it's. It's pretty popular. I am a huge fan, uh, for container security. I am a huge fan of Trivy. It's crazy fast in terms of container scanning on your desktop. Um, I, I think that's, that's a remarkable, it, it's game changing in terms of, um, container, uh, container scanning, security. Um, I still like ZAP, like OWASP ZAP, like, I just think it's like a, I don't, I don't know. It's probably questionable as to how often I use it these days, but for some reason it, it, it strikes a chord, you know, A warm and fuzzy, huh, pun fuzzy, fuzzy feeling, um, within me and, and just extending that, just go look at, like, OWASP has so many tools, it's ridiculous number of tools that you can, you can dive into in terms of open source. So it is a cornucopia of, uh, of, of open source, amazing things.

Chris Romeo: 36:26

Well, Steve, thanks for, uh, for sharing your perspectives with us and with our audience on cloud application security and all the different pieces of that coming together. Um, you introduced me to Wing, I I did Google it while we were continuing to talk this Wing, it's winglang.io programming language for the cloud. So I'm gonna take a closer look at that and. Uh, hopefully some of our audience hadn't heard of it before as well, and they can take a look at it and see. Um, but yeah, I mean, I I I was serious about that. I'm gonna, we're gonna look you up in a few years and we're gonna do a retrospective on this and see what, see how it, see, see, did it come true cuz I, I, I like what you were describing about if, if the, you know, the pipeline, the security pipeline, all these things are just built from scratch and solid. I wanna see if that becomes a reality. So, we'll, we'll definitely reconnect in the future and have that conversation. So once again, thanks Steve.

Steve Giguere: 37:19

Thanks, Chris. Thanks Robert.