The Reality of DevSecOps with Steve Giguere

Steve: [00:00:00] It was just us saying it. We weren’t actually shifting the word shift left.

Matty: It’s time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matt Stratton, and in the background you might hear Moxie, my new Australian Shepherd puppy who has decided she wants to join the show. But we have an awesome show with or without puppies today. But before we get into that, a word from our sponsors. BridgeCrew is the all-in-one cloud security platform for developers. They automate and embed security throughout the entire development lifecycle, so you can streamline your DevSecOps toolchain into one solution. By integrating infrastructure as code security and compliance into your version control systems and CI/CD pipelines, BridgeCrew empowers you to find, fix, and prevent cloud misconfig faster. Get started with BridgeCrew for free at arresteddevops.com/bridgecrew. Rootly helps engineers manage incidents directly from Slack without ever needing to leave the tool. They handle all the boring and tedious manual work during incidents, like creating channels, looping in the right people, and acting as your scribe to document that ever-important timeline. Companies from 20 to 2,000 manage hundreds of incidents daily on Rootly. It’s super simple and easy to use. You can install it in 5 minutes or less. Visit rootly.io to learn more and mention Arrested DevOps for $1,000 off when you book a demo. The role of a developer or engineer has evolved into a security-first mindset. The ability to confidently build and deliver your software assets across the globe while also avoiding supply chain threats is a priority for organizations to remain successful. Cloudsmith is software supply chain management for modern DevOps practices. They provide a single source of truth for all software assets while integrating with the package formats your team is used to. With a focus on securing your software supply chain, Cloudsmith is truly at the heart of your DevOps ecosystem. To learn more and receive a firsthand look at their solution, please visit arresteddevops.com/cloudsmith. I am joined today by Steve Giguere, who we’re going to talk all about the reality of DevSecOps. But before we get into that, Steve, welcome to the show. Why don’t you tell our audience a little bit about yourself?

Steve: [00:02:37] Yeah, Matt, thanks. Yeah, my name— well done. You nailed my last name. That’s normally the biggest hurdle early on in these sorts of things. I am currently a developer advocate for BridgeCrew, which was recently acquired by Palo Alto, specializing in cloud infrastructure security automation. Essentially. But before that, I have spent a bunch of time in a bunch of different security vendor companies. Mostly I was with StackRox, which was then acquired by Red Hat. I was at Aqua Security before that. And I spent quite a long time at Synopsys, which was— I got into there via acquisition, but spent a lot of time working with a lot of different tooling and large enterprises securing CI/CD pipelines. So that’s what I’ve spent the last 8, 9 years doing.

Matty: Awesome. Big fan of StackRox. So that’s cool. So we were talking about a bunch of different things we could go into. And one of the things I think is really interesting is when we think about this idea of DevSecOps, and I want to take a little time talking about what is this really like in practice. But before we dig into that, you know, as Andrew Clay Shafer would say, who wants to argue about the meaning of made-up words with me? But let’s argue about the meaning of made-up words for a minute. When you think about that term, DevSecOps, what comes to mind? What’s your interpretation?

Steve: [00:03:54] Oh, wow. It depends if you want my cynical one or the legitimate one. I mean, I jokingly said one night that DevSecOps is like security self-pending an invite to the DevOps party. And to an extent it is that because I feel like DevSecOps was a term that was invented by security as a reaction to the success of DevOps. Now, what it turns out to be in reality is actually— for a while, it was a bit uncomfortable, but I think now it’s coming to some sort of actual legitimate meaning, and that is trying to embed security by default in DevOps so we never have to use that word again.

Matty: I’ve said before, all apologies to Patrick Dubois and Andrew Schafer, but DevOps is unfortunately named because its name implies it’s restricted just to 2 different types of roles. And that’s never what it’s been meant. The fun bit of history is it’s called DevOps because Agile System Administration was too long of a name for a conference. So when they wanted to, when Patrick and Andrew wanted to start a conference, they said, we couldn’t call it Agile System Administration Conf. So what about DevOps? And, but that’s what gets us to this tacked on portmanteaus of you need DevSecOps or DevBizOps or DevQAOps, you know, without sounding like pedantic, but that’s also fun to do. A lot of us who’ve been doing this for a long time are like, but spoiler alert, it’s always been that. But it’s been a matter of that, that’s not where it’s been perceived or it’s seen exclusionary to like security. Because I think about before, I don’t want to sit and do the like when someone used the term the first time kind of thing. But before I’d ever heard about DevSecOps, I was giving talks about shifting left securely about, you know, and I remember Julian Dunn always used to talk about how security is just another aspect of quality. So it’s been in a conversation in the DevOps space since almost the beginning, but I completely appreciate how when you hear a thing called DevOps and if you’re a security professional, you’re like, but where’s the security? And that was absolutely something that’s always come up. I’m okay with it, except I look at it as DevSecOps is just the same thing we’ve always been talking about. It’s still DevOps, but maybe we gave it a little bit of a better name. So we think about that a little bit more because yeah, I feel like sometimes it’s perceived as it’s just security automation, right? And I think that’s a little— I think there’s more to it than that.

Steve: [00:06:20] Yeah, there’s people who misunderstand that it’s just a way of— actually, people misunderstand DevOps as automation sometimes and don’t understand that it’s more of a cultural thing. And I think that’s really where security is trying to get involved. I don’t know, off what you said about exclusionary, that it’s felt that way from a security perspective. Some of it is almost a self-induced purgatory that security has done because they’ve come from a world where they were allowed to have it thrown over the wall and catch it at the end. And now the idea of integrating and with a culture that is already established is difficult. And so sometimes automation feels like the best way in.

Matty: And I think that’s true because most DevOps transformations or implementations, or when you’re starting to work that way, people, they are going to be led by software engineering or web ops or whatever, you know, so security is feeling like it’s bolted on. And that’s one of the things I’ve always thought about that’s really important is if you’re trying to make this transition or this transformation, you need to have that tent be big right from the beginning. But it feels like I can completely empathize with why things happened the way that they did, because you already have probably a bunch of people in your software engineering part of the world or your ops people who already buy into all of it. They’re aware of it. They’re familiar. So, if we think back a few years when you’re trying to do this, and then now you’re going to, even if you want to make the tent big, you have to bring your security team that are used to being the chief no officer and all of that, because that’s how the organization wanted them to act. You have to bring them around to your way of thinking, which is hard. And I’ve given a talk before called The 5 Love Languages of DevOps. And I think it’s really important when you’re trying to affect change is realizing what resonates to you about something doesn’t resonate the same way to someone else. They have a different, you know, love language, if you will. And so, what makes sense to me about why this DevOps thing is hot and awesome as someone who’s building features Like all of those things actually to someone’s security may not be seen as awesome. They may be seen as, oh my God, that’s a huge problem. You’re actually making it worse versus being able to sort of frame to that and say, but oh, here’s why you will actually love this. And then because I found that a lot of the things we talk about when I was helping companies through this, where we’d get a lot of pushback from InfoSec, it’s like, but when you frame it into the way that all of a sudden this light bulb goes and they go, oh no, I want that. And a great example is I always like to say, I’m like, the problem with audits and why audits are theater is people lie. Computers don’t. I can’t tell you how many audits I’ve been a part of where it went down to, Matt, did you do this thing? Click yes or no. Sign your name saying you did this or whatever, which can— or didn’t do, which is either A, I can lie, or B, I can misremember. Because I can’t tell you how many times it would be like, did you ensure that on every deployment you did whatever? I’m like, Shit if I know. I mean, I assume I did because I’m good at my job, but if I’ve got an automation around it, we can absolutely see. And then the same thing with like change control, right? You know, if you’re trying to deploy something and it doesn’t meet all of the requirements that were stated in an automated way, the computer is just going to be like, screw you, Steve. Whereas as a person, you could be like, come on, Matt, man, my boss is on my ass. Can we just get this out? We’ll remediate it next week. And y’all might be like, okay, cool. That’s fine. The computer is just, care. Lights aren’t green, you aren’t going. And that resonates a lot because then people are like, oh, this is really helpful for my compliance. I get why this matters. But it’s not something that someone who’s trying to ship changes would ever think of as a benefit. I mean, they’ll get it if you tell them. They’re like, oh yeah, I can see how that’s cool. But that’s not what’s front of mind.

Steve: [00:10:12] Yeah, I think the security needs to matter to everybody. And it is very hard to convey that. And particularly when you’re trying— when you’re talking about automation as that way in, how do you implement automation in a way that it doesn’t seem slower and that whoever’s responsible for whatever it is you are checking for compliance or security or whatever it is you might be doing sees a positive outcome or actionable details that aren’t encumbering to what it is they’re trying to do in their day-to-day. So it’s got to be drip-fed, not sledgehammered. That’s the struggle I would say now, and coming from various vendors who sell things that do things that check things, It’s been over the past, a lot over the past 6, 7 years, like what that automation means and the correct version of it is this eternal chasing DevOps struggle.

Matty: How do we reconcile the everybody should care about security without going so far into NoOps land, which was the everybody should just, developers should just be responsible for everything. Like, how do we get that? How do we reconcile that? Because that’s the natural tendency. Especially with organizations that are like, cool, we need fewer people if the developers can do everything. If devs can do all of ops, then we don’t need ops anymore. That’s what gave us NoOps, which fortunately failed spectacularly. And I feel like NoSecOps or whatever would be the equivalent, but sometimes we want to go there. So how do we reconcile that?

Steve: [00:11:39] Ah, you’re treading delicately into the shift left world, aren’t you? Or that we haven’t said that yet.

[00:14:31] I don’t want to speak for them, but that’s a similar— maybe let’s see what my definition is and see how close we get. The, for me, shift left is the concept that it’s just not right. It’s not all the way. It can, we can shifting. If I’m all the way on the right, I can be middle and I still shifted something left and that’s okay. And there should be a little bit of security in the middle, maybe during our CD phase, just to make sure that we’re doing some preflight checks. Those are things that are quick and easy. So let’s do that. And if we drizzle the sprinkles of security all the way across towards the left into development and into even the education threat modeling and way over left, you don’t need anybody to do very much. It’s not like I’m taking the full burden and shifting it over. And I think that’s— we’re working on correcting mistakes that were made years ago. I used to work for a static analysis company and they would analyze some big Java code and there would be 10,000 things you had to do. That’s— and no one would do it because that’s just too many things. So they just go, all right, great, file that or suppress everything, and off we go. And this is almost like a pen tester trying to shift the whole burden over. Whereas if we look at some of the easier things we can do now, just checking misconfigurations in Dockerfiles, just little tiny things. If everybody does the little tiny thing, even if it’s not thorough, even if it’s not edge case, The culmination of all of that work, all of those little checks as we get to the end, means we’ve got something that sure won’t be perfect, but will be incredibly secure because all the pieces of the low-hanging fruit have been taken away on the way down. And that version, that very distributed deep shift left, that would be great. So it’s more about convincing every person who touches something on the way through And educating them about what’s your easy version of security I can ask you to do that won’t take any time, but will have a big impact later on.

Matty: [00:16:31] I’m interpreting that as shift left doesn’t mean shift leftmost, right? Like you said, lift all the way, you know, it’s moving it in that direction. And a couple of things, like you said, that kind of sparked some thoughts I’ve had too. So I believe that one of the reasons this has been hard in the past is that our security tooling was not for lack of a better word, democratized across our organization. And I’m sure I haven’t looked at this tool in a long time. I’m sure whoever does DevRel or whatever for this organization I’m about to mention will correct me and tell me it’s not that way. But I always used to use Qualys as the example. You know how much a Qualys license costs? Like, and then so if I was to go in and say, I want to give Qualys to all my developers, my CFO would have a heart attack. And it’s a very heavy, or at least at the time, I don’t know why I keep feeling like I have to qualify this. You know, come at me, Qualys. But, you know, it was very heavy. It was a lot to take on and it was very expensive. So when things like that happen, you inherently move all that to the right because there’s cost involved. So the more that we can democratize our security tooling, the better likelihood we have of it happening earlier or at least being thought of. And that goes into, as our old pal Ronald Reagan would have said, trust but verify. You know, if we think about the idea that I am going to trust that my developer, if that’s the example, runs whatever type of security testing when they commit, but I’m also going to check it in my pipeline. So that’s trust but verify, which I want you to do the right thing, but I’m going to put a check in place. And that’s just because sometimes we make mistakes. We can miss things like it’s just a double check. Now, on the same token, you can’t do trust but verify If you can’t put those checks in your pipeline unless you enable the developers to do them themselves, because it’s also really shitty to have a check way later in the pipeline. And then I get all my stuff in there and it chugs away. And now it gets to that last part and now it fails. And it’s, I couldn’t have even known that. So how could I have done it? We also know the cheapest, easiest place to fix a bug is the closer you introduce it to introduction, right? Do you feel like that’s gotten better? Like you’ve been in the tooling space a lot over the last couple of years. So is that something that’s a little easier to do?

Steve: [00:18:44] Yeah, I think we’re thinking of— actually, the industry has changed in certain ways that have made security harder, but in other ways it’s made it easier. Like, for example, there’s been so many different IDEs that people used to use, and it used to be very difficult to integrate because the way to be a part of a developer world is to be part of their IDE so that we’re part of their world. But There’s been a bit of a convergence on things like VS Code, because everyone— it’s just super easy and has a zillion plugins and just works. So people have been making plugins for VS Code that just does highlighting of potential security issues as you go for all manner of things, from YAML to Terraform to Docker to Node.js to whatever. It does it. And that’s great. And if we’re all converging and we’re all paying attention to that, that’s really good. Also, The idea of GitOps has really lent itself towards security because the ability for some kind of check to auto-generate a pull request so that there is, we’re just integrating to existing flows that you’re used to. You see from them, you learn them and you think, all right, well, I don’t want that to happen again. Take that into account or create a logged suppression of that so that it’s the security people then who don’t have to watch it with an eagle eye can see that, all right, this is a justified action that will mean this check won’t bother them anymore. No problem. So those are good examples of where we have moved into practices that have made that shift left, I think, really easy. It’s more the larger scale rearchitectures like microservice, monolith to microservice that have really confused a lot of the InfoSec people. And even though I feel like I’ve been playing in this for years, Kubernetes has matured. It’s a lot more secure than it used to be. There’s still a lot of confusion. Amazingly, there’s still a lot of confusion about it and what to do in terms of securing the modern software architectures and deployment models.

Matty: [00:20:39] I think, yeah, as the systems— that’s the same thing that has applied to ops, right, has applied to security. As our systems grow more complex, we have to get ourselves comfortable with this idea that we can’t hold the whole system in our head either. You know, where there used to be back in the LAMP stack days or equivalent, I could, as an ops person, I could know everything that existed in the system that ran my business to a certain point, right? I’m like, okay, I know the platforms, I know the components, I know all those things. So I know what to pay attention to. Whereas today’s distributed systems and so much more SaaS and so much more microservices and everything, it’s a fool’s errand to think you can hold the whole thing. And that’s a reframing of how we think about our systems. Right? The same way that we’ve had to think about the fact that our systems are in a constant state of failure and that’s okay. Within our large distributed systems, something’s always broken, but that doesn’t mean that the service that we’re providing to our customers is broken. And so, rethinking that, I guess, from a security perspective as well, is even when you move like models around towards zero trust, like we used to be able to really work really well at a perimeter level. We’re like, cool, you could do whatever you want inside, you know, or whatnot. And that’s a change. So I think that’s the thing, right, is like the things you have to learn are not so much technical. Like they’re not learning a tool. They’re not like, I have to be super good at Kubernetes, but you have to know what Kubernetes does so you can threat model it, you know, versus doing the easy thing of being like, I don’t understand that, so I won’t let it in because we can’t possibly become experts in it to know how to secure it, you know. And is there other ways to secure it? What do you see from, of all of this plethora of things we can do to like jack up our systems or whatever? If I’m a security person that wants to, to quote, do this right, do DevSecOps right, what are the concepts and stuff that I really need to get my brain around that are different than our traditional platform or traditional role?

Steve: [00:22:37] I guess it depends on the security person and where you’re coming from, because if I’m InfoSec, then I’m probably brought up on networking and firewalls, and I may not really even have a coding language under my belt. And that makes that side of the world difficult to understand. If I’m an AppSec person, then I’m going to be obsessed with the OWASP Top 10 and how I can secure those. And even security needs to take a lesson from DevOps, to be honest, because Dev and Ops is like AppSec and InfoSec. And yet we don’t have a word that merges those 2 worlds in security. And we’re siloed. And so we have that internal struggle where we need to really take a page out of that book. So it depends, but to try and give you an easy answer is understanding what does my attack surface look like and what is the low-hanging fruit? Because it’s not the same today as it was 2 years ago, as it was 4 years ago. And to understand that is one example would be Basic misconfigurations that don’t have CVEs associated with them are still bad. In fact, probably worse than CVEs. CVEs, I think, are worse than the OWASP Top 10 because they’re all like, this is the things that are super easy to fix. These are the things that the baddies know about because there’s known exploits and they’re out there, but you can search for them and prevent them. And then there’s the unknowns. Which is the OWASP Top 10. Have I accidentally designed this in? And I need things to check for that. But those are the really hard things to find. So, let’s recognize that I think misconfiguration gets a bad rap. It doesn’t get looked at as hard as it should. I remember hearing a podcast, and you’re probably going to tell me it was your podcast, that had Ian Coldwater on it, who was saying, back in the day of Kubernetes, there was lots of actual people hacking because it was so insecure by default. Because, and now, and she said, now it’s mostly misconfiguration that we see where things go really wrong, which is good, but we need to understand that.

Matty: [00:24:44] That very well could have been. Although interestingly, I’m 99% sure for the several times that Ian’s been on our show, they’ve never been on an episode that I hosted. But now I feel like I need to go back and listen to the episodes that they did with Bridget to see where that came from. Came up. I really like that idea of security needing to become cross-functional the same way we talked about DevOps. And when we’re looking to— so I have all— I would imagine the same transformational things apply, but if you’re an InfoSec professional, an AppSec professional or whatever, if you recognize this in your organization, like what are maybe some of the more security ways of thinking, you know, being more familiar with the way that people work in that space to try to affect breaking down those internal silos, or at least permeating them a little bit, which me talking about putting holes in walls probably makes all the security people go, oh no. Everybody just shuddered.

Steve: Yeah, it’s interesting. I think if I’m going security again, let’s go cultural to start. At the end of— I did a talk last year called Collaboration Over Competition, and it was about it was using DevOps as a model for success, just in life beyond, and something that security can learn from. Security needs to just hang out with the DevOps people. They need to break down their own cultural, their culture of no, and their culture of separation within organizations so that they are part of every process. They need to understand that if they’re going to buy security tooling, they should have DevOps and developers in on representation, in on the decisions so that they’re not mandating. And they should learn from the way that they use the tools that they already have so that they’re designing around their world, that, and they become part of their world in the process. And so just socially being a part of their world is the first step to understanding their technological part of their world. So I think that is a great lesson that people in security who tend to be a bit more ties and collars than t-shirts need to try and overcome in the shorter term.

Matty: [00:26:47] I love that idea of collaboration over competition, right? Because there’s a lot of, a lot of times that comes up as an unintended consequence all over the organization. So I was just thinking a little bit though, like when you’re talking about moving that into more of that collaborative conversation, does this come up even a little bit when, say, I’m, you know, an IC here at Big Corp or whatever, and I want to use this new tool, and of course it has to go through a security vetting. Like anytime, you know, most organizations, anytime you’re even thinking about, hey, I want to use Airtable or I want to, you know, consume this API or do whatever, if we’re going to buy— and usually it gets caught by procurement. I almost feel like you’re safe using a tool you don’t have to pay for because sometimes that’s a hole in the process. But you will, if it’s the thing you had to pay for, you 100% are going to get a security review because the procurement process has that. But I think a lot of times that security review is not collaborative. It’s, I fill out a ServiceNow ticket or whatever, and it’s going to come across your desk, Steve. You don’t know me at all. You don’t know the context. All you know is security request, security review required for fodunk.io or whatever. And you’re going to look at it totally in the context of just your usual threat modeling, but have no context, number one. So in 2 ways, I think this is bad. Number one, you don’t know why I need it, which is going to affect how you think about it a little bit. And it’s not collaborative, but also Also, if we haven’t collaborated, it actually is a little bit more of an insecure process because I might be thinking about this, using this in a way that’s very contradictory to the published use cases or how you might think I might use it. So, I might actually— you might miss something in the security review because we didn’t collaborate. What’s been your take on that? Like how security review of tools could be more collaborative, I guess?

Steve: [00:28:36] I agree. I think as a— if any security people are listening to this podcast, if development suggests a tool that is security that they want to use, just buy it. Because that’s great. Because that means they’re thinking, already thinking security. And it’s— that means they’re probably going to want to use it. The reality of development and ops is that they like to pull the tools. They don’t like having things pushed on them. So if they volunteer to pull something, even if it costs some money, then invest heavily in learning what that is and how it can be used. And maybe just let them have a go at it because you might learn its use case that you don’t understand because they’ve obviously got it in their head. So it’s not only an opportunity, is it an amazing situation to be in, but it’s an awesome opportunity to start talking because you really want to see what their use case is and why they want it. And then there, if they’re already interested in the tool, then they’re going to want to hear why, what your counterpoint might be on it. And so that’s an amazing situation to be in, frankly. That’d be awesome.

Matty: [00:29:45] What are some, you know, so we decided, you know, we’ve titled this the, you know, the reality of DevSecOps, but what are some, you know, maybe your top practical tips for someone who wants to do this type of work, you know, in their organization? What’s something they can start doing today or something that— what’s the next couple weeks look like, you know, to start chipping away at this? Because big organizations move slowly. They have to, and that’s okay.

Steve: Yeah, that’s— I think that’s an easy one. You touched on it already. Free stuff. Go to the CNCF and start looking at what is in the little security box in that massive landscape. It is already filled with things that you can go get for free. I mean, I think Trivy is an amazing container image scanning engine and it’s free. It even has a client-server mode. Like, it’s getting more and more advanced all the time. And even if you’re just using it to decide which base image you might want to use, that’s a huge step toward being more secure. It, it’s in VS Code, it’s on the command line, it’s dead easy. There are tools like we’ve got— this is— feel free to cut this if this is too much of a plug, but BridgeCrew has Checkov, which scans YAML files, CloudFormation, Terraform, all of those things to make sure you’re designing your infrastructure as code for your cloud correctly and not doing obviously obvious headline-grabbing things like S3 buckets that are wide open. You know, just a simple— and that’s free. Just go get it and use it. There’s lots of stuff out there that can get you started, and a lot of it actually does roll forward into the conversation that you just brought up, where it starts off as open source, but if you really wanted to scale it where security had observability into the 1,000 developers that have now downloaded it, then you have to talk about— then you have to buy something probably, right? That’s okay, because if I know the developers are using Trivy, then I’m going to look at Aqua and go, don’t change anything you’re doing, I’m just going to go pay these security people so I can see it. That is a great way to get started. And there’s just a ton of really good stuff, both from OWASP in terms of that side, in terms of containers, in terms of clouds. It’s just more than a few years ago. There’s tons of stuff that you can get started with.

Matty: [00:32:02] So I feel the need to say this because also it makes me feel like an influencer to have to put a disclaimer, but while mostly just so while BridgeCrew is a sponsor of this podcast, Steve’s not on because of that. Steve is on because we’re having great conversation. So it was totally okay for you to mention BridgeQ. Don’t worry about it.

Steve: Okay, cool.

Matty: But listeners, we maintain our integrity. Don’t worry about it. Nobody’s come up with a high enough sponsor payment to get us to do that. But, you know, if you feel like challenge accepted, we all have a number.

Steve: I have a podcast as well.

Matty: Tell us about your podcast.

Steve: Sure. My podcast is called CozyCast, and which is meant to be a weird crush-up of like DevSecOps, I suppose. Continuous Security Podcast was too long to say and was bland, and CozyCast sounded comfortable, and so I called it that. I used to have one called BeerSecOps, but then I had to change the name for various reasons, and I just changed it to CozyCast, but it’s wide open.

Matty: [00:33:03] We’ll put a link in the show notes too, so, okay. Make sure that everybody has the right link.

Steve: Yeah. And I guess I’m trying to be the other side of the coin to what you’re doing here, where I get people who are as, for example, the last person who was on the show is a CISO for hire. So he’s like, for people who can’t afford to hire a full-time CISO, this guy has an organization. They’ll send somebody in one day a week just to build your strategy out and tell you what to do. So you get the basics. And as you’re going from small to medium, that’s really useful. Until you can afford one and then away you go. And they’ll even help do that for you. So somebody comes in understanding what’s in place. That’s really cool. But in the same thing, I’ve had Liz Rice has been on the show, of course, because she’s a relative celebrity and she worked with me at Aqua. So she generally says yes to the show. But last year I had on the other one, I had Kelsey Hightower on the show and he, I’m name dropping like crazy now, aren’t I? But it was good.

Matty: Well, you plug in your podcast, so you need to, that’s all part of it. It’s great.

Steve: Yeah, but it’s great conversations because I always try and turn it back to, okay, but what do we do in this for security in this space? If it’s not a network security podcast, then it becomes— I try and make it one so that whatever it is we’re thinking about, it’s that collaborative thing where we’re trying to talk about a DevOps subject, but I’m trying to put a security spin on it all the time. So it’s fun. And then probably like yourself, I learn a lot from talking to random people in the industry who are willing to talk to me.

Matty: [00:34:32] I’ve quoted before, and unfortunately I think the blog post is offline now, but if I can find it, I’ll put it in the show notes. But Brian Barry, who started the Food Fight show with Nathan Harvey so many years ago, he had a great blog post that was called The Dirty Secret of Tech, or no, I think it was called So You Want to Start a Tech Pod? It was about starting a tech podcast. But one of the things he said in there that has always stuck with me, and I’ve seen it to be 100% true, is he said the dirty secret of tech podcasting is this is how you get someone to spend an hour talking to you that you wouldn’t normally be able to get an hour of dedicated time. And it’s not because these are— we’re talking about celebrities who like have to make their time worthwhile. But in seriousness, if I were to go up to you, Steve, at a conference and be like, let’s just sit down and talk for an hour about this topic, you probably wouldn’t. You know, I mean, it might happen organically if we were at a pub or something like that, but like you’re busy, you’re working, you’re doing things. And none of that has to do with being too important to do it, but there’s a mental difference of, oh cool, I’ll come on your podcast, or now we’re on your Twitch stream or something like that. And there have been so many things I’ve learned from just having people on the show and being able to ask the questions I want to ask as a proxy for, for our listeners. It’s been fantastic. I also think it’s interesting— longtime listeners of the show may, may know this— but the evolution of this show has been fascinating to me because we started it because it was supposed to be very, for lack of a better word, DevOps 101, you know, because when I first started getting involved in DevOps, the way I learned was listening to podcasts. And so many of the existing podcasts, just because of who was doing them, nothing negative about them, presupposed a certain background and familiarity with stuff. And I was like, and I was willing to take it on and figure it out by context, but I was like, but what about people who don’t have as much like nutty stuff as me. And so our joke was always this was the podcast for people who your boss read about DevOps in the in-flight magazine and said, hey Steve, we want some DevOps now. Side note, we have yet to find an in-flight magazine to mention DevOps, but if you find one, please tell me back when we can fly on airplanes again. That said, shortly after we started the show, I was getting a lot of like tweets and comments from people who were listening to the show, and I was like, why are you listening to this show? Like, you should be on the show, this should be your show. You’re an expert, you’re all this. What we’ve learned, if nothing else, this is my advice to any content creator, you can’t control your audience. Your audience is going to evolve and they’re going to be the people that are there. You just sort of have to own that. It creates some interesting challenges because we’ll get just as many, the show’s not technical enough versus the show is too technical. Comments because everybody wants different things. So we try to move around with that. But I love that we can have conversations like this. And so many people are like, hey, you know, how do I get to be on the show? Do we have to spot? Let’s just tell me a fun thing you want to talk about. I’ll love it. Let’s do it. Hopefully you listeners love it too. That’s the extent of I could get away with sometimes getting meta about podcasting when Bridget’s not on the episode. What if I am someone who is not from a security background, but I find security and DevSecOps really interesting, and maybe I want to either to sidecar it so I could be a better developer, or maybe even want to get more involved? Like, how can I learn more about this if it’s outside of my normal bailiwick? Um, yeah, that is—

Steve: [00:38:04] there, I think security is getting better at education. I know that there are people creating— well, I’m creating like a mini course now, but I’m creating it for— I don’t know if you’re familiar with WeHackPurple. Tanya Janka runs over in Vancouver this thing, which is awesome, and she’s focused entirely on educating. So there’s a lot of teeny things that they are churning out that are great if you just want to learn how to secure, or what threat modeling is, or what incident response plan would look like, these little pieces that you can chip away and add to your knowledge of security. I think it’s really, what she’s doing is awesome. She’s been on my podcast as well, plug. That’s really good. I, it would be, there’s also, I mean, you probably know this, there’s loads of, there’s almost too many certifications that you can explore if you really want to like just get a wide and very not deep feel for how security works. I mean, I think 6, 7 years ago I did this one called CSLP, which is like Certified Software Lifecycle— I don’t know, something practitioner. Who knows what it stands for? But it was like more about application security and supply chain, which is really hot right now. And it was great. It just touched on where you think you’re focusing on certain pieces of security. This is all great. It gives you a really good big picture And suddenly you realize what you don’t know, and then you can pick and choose where you want to deep dive from that. So I actually thought that was really good, even though now I think that that was like nothing compared to real life, like what that did, but it was a great intro. So it’s worth looking into some of the certifications. I know people who come out of school usually study things like encryption and whatever and security, but they still have to go and do something. That is more specific to the area that they really want to deep dive into because traditional education isn’t quite there yet.

Matty: [00:40:01] So we talked a little bit about if I’m on the security part of the org and how can I, you know, affect some change there. What are— if we think about, you know, we talked a lot about this is a lot of, you know, blah blah blah empathy. I always like to say it that way, you know, it’s— we’re like, we get it, walk a mile in the shoes. But maybe even What are some active things that I, as an ops person or a software engineer, an SRE or an SWE, can do both practically with technology or even in a process to help invite that over or just make life a little easier for my security friends?

Steve: As an ops or an SRE person, you’re probably already— if you’re an SRE person, you’re almost a security person already. I mean, in a way, that’s quite good. I think you did a podcast recently, I’m plugging you now, with Aaron Reinhardt, where he’s talking about security chaos engineering, and that whole world as it leans towards ops is a good thing to listen to because I like the idea that you can both intentionally destroy parts of your world and look or attack parts of your world, and you can collaborate with security on making that happen. So that’s a great ops security conversation that you can make happen to say, okay, so we have this huge Terraform that we just deployed and let go see if you think this is secure or not. And this can be a red-blue scenario where you can make that happen and you can both learn from it because security, they don’t know, they’re not going to know Terraform. So they’re not necessarily going to know what it is you’re doing. And so that is a great conversation. Is, is that kind of thing you’re going for?

Matty: [00:41:48] Absolutely. No, I mean, that’s— yes, it’s very tactical but also philosophical, so it’s fantastic. And yeah, I put— I don’t need to say this, this is more of saying everything’s in the show notes, but yeah, I went and got the— Tanya was on an ADO a while ago, which was awesome, so I’ll link to that. And We Hack Purple. Okay, I’m gonna ask one more question. This is just for me, and then I think we’re probably pretty good unless there was any other things we didn’t touch on that you wanted to— No, I think you’ve been pretty thorough. Cool. Okay, awesome. So to wrap up, I’ve been loving asking this question of people. I don’t always do it on the show, but I ask people this question in almost every conversation now. How do you like to learn? What are your tips for learning? How do you like learning and where do you get information from? Oh, I’m a YouTube person.

Steve: I, I, in spite of me liking creating structured courses, then they have to almost be in the YouTube format. Like they can’t be long. I have, I’ll probably watch them at 1.5 and there needs to be a GitHub repo that goes with it that shows me, you know, what perfect looks like. So I can go look at that before I look how you built it. That’s, that’s what I like to see. I don’t like being drip-fed. Like I want to go straight to the end and then go to the beginning, like a Quentin Tarantino film, and then jump around, let the plot change all the way throughout. And then I might go away and build some of it myself, screw it up and think, I just watched that. How did I get that wrong? Back a little bit, away we go. That’s, it’s a really different way of trying to— this is technical, of course, like when I’m trying to learn something new. That’s what happens. I’m happy to go through and make it, do it all wrong, having watched this lesson at 2x, thinking like I’m Commander Data and I’m going to take this all in. It’s never going to happen. And then make a mistake and then try again at 2x again, knowing that if I don’t have to, if I watch it 1.5 times at 2x, it’s still faster than watching it all the way through at the regular speed. So I’m okay. That’s me. I’m, I like that. And I like it when people design courses with lots of mixed hands-on. Actually, some of the structured courses I should say are getting better because like the CKA course I did was awesome because every section was super short and then immediately made you go do it. So there was no boredom time. And I found that was really useful. So that mix of video and hands-on is perfect.

Matty: [00:44:23] Fantastic. This was really, this was everything I could have wanted for after we had our conversation the other day. And I was like, yes, perfect. So good job, us. You can head over— yes, you can head over to arresteddevops.com/devsecopsreality for this episode’s show notes, which we actually have a whole bunch of supporting links and stuff. So if you’re a usual ADO listener, you’re like, yeah, I’ve seen your show notes, Matty. These will be a little better. So that’s a guarantee. You can return this podcast for nothing anyway. But if you did enjoy it, you know, if you head over to arrestedevops.com/itunes, you could leave us a review in iTunes Store. Yes, I know it’s Apple Podcasts, but I don’t want to replace the redirect, so we’re going to just keep calling it iTunes. We’re also available on Spotify, iHeartRadio, and Audible, so pretty much anywhere that fine and less fine podcasts are— can be found. Uh, Steve, thank you so much for joining me today. This has been a real treat. Thanks, Manny. That’s great. So this is Arrested DevOps, and remember, there is always DevOps. In the banana stand.