Alyssa Miller -- Bringing security to DevOps and the CI/CD pipeline

0:00Chris RomeoAlyssa Miller is a lifelong hacker, security advocate, and cybersecurity leader. She's the BISO for S&P Global Ratings and has over 15 years of experience in security roles. She's heavily involved in the cybersecurity community as an international speaker, author, and advocate. Alyssa joins us to talk about bringing security to DevOps and the CI/CD pipeline. We talk about the success of the DevOps transformation, mistakes AppSec teams make with DevOps, and explore the possible idea that DevSecOps is its own silo. We hope you enjoy this conversation with Alyssa Miller. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that's conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow your developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo.

1:19Robert HurlbutHey folks, welcome to another episode of the Application Security Podcast. This is Robert Hurlbut, Threat Modeling Architect, and I'm joined by my co-host Chris. Hey Chris.

1:41Chris RomeoHey Robert, this is Chris Romeo, CEO of Security Journey. For those watching the video version of this, I'm coming to you from the Security Journey Comedy Club where nightly I do various stand-up jokes and try to make people laugh a little bit, and we also talk about security as well.

1:55Robert HurlbutAbsolutely. And so in the last few episodes, we've been talking about DevOps. We've been looking at just various aspects of it. And today our guest is also going to be talking about DevOps. Alyssa Miller, welcome back.

2:12Alyssa MillerHey, I appreciate it. Thanks for having me.

2:16Chris RomeoAlyssa was also a co-conspirator on the Threat Modeling Manifesto, and this is her second appearance on the Application Security Podcast. So welcome back. Always glad to reconnect and Keep talking.

2:29Alyssa MillerYou guys, yeah, definitely always. And I mean, good topics, my favorite, right? AppSec. I'm always happy to dive in. Cool.

2:38Chris RomeoSo the— I guess what I wanted to do is my first question is set the stage a little bit because we have these words Agile, DevOps, and CI/CD, and they get thrown around in a lot of different contexts. And I thought it'd be good for our listeners that all probably have a definition of these, but let's, let's kind of see how that definition that they have in their brains right now is going to align with what your perspective is, Alyssa. Agile, DevOps, and CI/CD— work up some definitions for us from your perspective.

3:10Alyssa MillerYeah. What's funny, first of all, is that people take those 3 and think that they're all pure terms, that either you do Agile or you do DevOps or you do CI/CD. Some people will say, well, if you do DevOps, then you're doing CI/CD. Some will say, we do Agile DevOps. You're right. It's strange because you will hear a lot of different definitions, and for everybody, it means something different. In general, the way I've looked at this is Agile, first of all, is very process. It really refers to a process of how do we develop software? How do we run our software development lifecycle? And, you know, that's where we start to introduce things like user stories and scrums and sprints and things of this nature where we got away from heavy design, but we still did some design, right? When we did sprint planning, we'd pull in a bunch of user stories. We'd kind of— a lot of times those would tie together into a scrum theme and, you know, we'd lay that out and There'd be some form of design work. We'd roll that in, and you know that would you know turn into this pipeline. Our our sprints would take you know anywhere from a few weeks to maybe a month, but it was very cyclical. We could you know have one sprint running with one Scrum team, and then we'd start up another sprint with a different Scrum team. And so rather than developing big monolithic releases like we would do with a waterfall where we'd have big design time and then we'd have, you know, very specific requirements gathering and all the things. We got into this mode where we could do that a little more quickly. We could have multiple sprints running at the same time and be more agile. But so I'm going to skip DevOps for a minute because I'm going to come back to that and we'll talk about how CI/CD is different. from Agile. So CI/CD is similar, is more of a peer-ish term, in my opinion, because CI/CD is really focused on, okay, how do we, how do we move from development to deployment, right? And the idea is this idea of continuous integration, continuous deployment, where we are continuously doing development all the time. Devs are writing code, they're committing code, they're writing code, they're committing code. At some point, they promote that code, they're ready, and they say, all right, throw this in the pipeline. The pipeline spins up and the first piece of that is that continuous integration where every time code is either committed or promoted, pipeline spins up, it builds it, it moves it into an automated testing cycle, hopefully if we're really doing it well, and it flows and ultimately it gets packaged up and it gets deployed. We're not as slave to these heavy, stringent, phases where we have to go from one phase to the next and there's a gate sitting between each one. And, you know, so we have to stop and then do this thing and then we can move to the next phase, then we do this thing and then we move to the next phase. Instead, we're continuously just putting new code in, and the result is, as we identify flaws and things, we might actually deploy with known flaws. But if our CI/CD is happening fast enough where we're maybe deploying multiple times a week, maybe even multiple times a day if we're really efficient at it, we can afford to do a deploy, come back, fix any bugs that were found, and the very next cycle through addresses that. So that's kind of that utopian view of CI/CD. Everything's very heavily automated. We don't rely on manual processes. We don't rely on process gates that stop us from moving from one phase to the next. Now, let's talk DevOps, because this is the thing that really is frustrating, because everybody looks at DevOps— so many people, if I say DevOps, they start thinking right away about automation. They think about tools, automation, they start thinking about CI/CD pipeline, and that's where we're going to go. If we go back to the root of what DevOps is, we go back all the way to 2008 when Patrick DeBois sat there and said, hey, you know what? Development shouldn't be this hard. Why is it so hard for me to get my code to production? I got to get those operations folks working together with me so that we can do this. And he He gets together with another gentleman at a conference, they start talking, next thing you know, 2009, DevOps Days spins up. I bring that up because the whole point of DevOps is culture. It's not tooling, it's not automation, it's not even how do we develop software, it's how do we bring together these disparate groups who a lot of times are butting heads in the deployment process. You think about what it is in many organizations. We've deployed code, we want to deploy this code. Operations says, no, you can't do that, that's new technology, we don't know how to support it, or whatever happens there, and there's these conflicting priorities. DevOps is really about a culture where everybody has a shared responsibility for ensuring that the software that gets deployed is stable, it's deployed efficiently, and it's secure. That's DevOps. It's that shared responsibility. That's why I kind of address them in that order because DevOps is very different. It's not a mechanical process thing.

8:39Chris RomeoI love the way you came back to culture at the root of DevOps. I'm somebody who spent a number of years focusing in on security culture as an idea. In the last year or so, I've started adapting that to say, okay, what does security culture look like from a DevOps perspective? I totally agree with you. So many people go directly to the automation of, you know, DevOps is just a pipeline and a bunch of tools. I mean, with everything that we try to do, it's funny how the world of technology always falls back to people, process, tools. Like, you can derive that from anything you're doing. You can drop it back and say, okay, there's a group of people, they're going to follow a set of steps, they're going to use a bunch of tools to make them more optimized in how they do it, but once again, it's always the people that are the focus there, and that's, you know, from a DevOps kind of culture perspective, it's about the people.

9:34Alyssa MillerYeah, definitely. And I mean, I always— people have seen me talk about this, know I always throw the 4th one in there too, right? So we always say people, process, technology. I was adding governance, because if you don't have governance, it's kind of hard to really know how you're doing and are you really building a culture at that point. So yeah, I call it kind of like the 4 facets of building culture is people, process, technology, governance.

9:57Chris RomeoNow, when I hear governance, I want to dive into this a little bit because sometimes governance has a— that term can have a negative connotation, especially in a world of DevOps where I want to go fast. Like, you can't— when I think governance, I think tapping the brakes or slamming the brakes. So how do you rationalize governance together there without slowing down the speed of what we're trying to do?

10:23Alyssa MillerThat's exactly the problem. Governance is all about— everybody hears that word and, oh my God, we think about audits and all these different things, people coming in and doing these assessments. Governance— let's go back to basics again. Governance is really just about that visibility and the ability to measure what it is that we're doing. If I'm trying to deploy a CI/CD pipeline, I'm probably setting goals for how I'm going to make that transformation to CI/CD. For instance, in my organization, we're going through a CI/CD transformation right now and trying to get— we have specific goals for how often we want to do deployments, and that's a measurable thing. But if nobody's paying attention to that and nobody's measuring that, well, then what are you really achieving? The governance piece of that is, Where are we trying to go and how are we measuring it? It doesn't have to be something that slows you down. In fact, quite honestly, that should be something you're just building in. If I'm building a CI/CD pipeline, I should be building in that measurability. We've got all these really cool tools. We've got things like, in our case, Azure DevOps, where, okay, we've got this huge tool that handles builds and everything else. Why am I not pulling some stats out of that so I can actually measure how well I'm doing with bugs that are showing up in my code, security flaws that are showing up in my code, how quickly are my builds happening, are builds successful or not, how many broken builds do I have. All of that is— those are all things that we get out of a pipeline, so let's watch them, monitor them, and talk how we can make our pipeline better.

12:05Chris RomeoSo you're redefining governance then. See, I have the baggage of being around the world of security for a couple of decades, and so I'm bringing that baggage with me forward about governance, but I like how you're redefining governance, not in a stop sign kind of a mode, but more of metrics, traceability, tracking what's happening in the process so that we can get better, more from a process improvement, as well as being able to justify. At the end of the day, it always comes down to the money. We can pretend that it's about the technology, but when you're working inside of a big organization, your budget is determined by the amount of value you create. If you're not able to measure that and demonstrate that value, then your budget's to be less next year than it was this year because you're just not impacting the bottom line enough.

12:55Alyssa MillerYeah. No, exactly. Unfortunately, everybody kind of has that view of governance as like this— we think about security governance or we think about those other areas. We don't really think about what the stated goals, at least, of governance are, and that is just to ensure that we're achieving the things we say we're achieving. Yeah, I mean, when you bring it back to those brass tacks, it's like, oh yeah, we can actually shift this and make governance kind of a good thing. Which is always good, right?

13:23Robert HurlbutI think. You mentioned about DevOps being culture and change. Now, DevOps has been around for a little while now. I remember when it was very new and it was the hot topic and everything, but how successful has that transformation for companies to adapt to it or adopt it? How has that been? How successful?

13:45Alyssa MillerWe've seen a lot of varying levels of maturity in DevOps. There are some organizations who've embraced it and done amazing jobs. Anybody who's seen the Netflix Pave the Road presentation, and I'm forgetting her name now, who the name is associated with that, but you look at what they've been able to accomplish by building a culture of DevOps and really DevSecOps, where they've got this idea that, you know, Okay, here's our standard processes for how you flow through the pipeline, but if you as a dev understand that you're accountable for these things and you see a better way to do that, you are enabled and empowered to do that. Like, that, that's great. You know, if you see that an ops person says, hey, we're doing this thing in how we deploy our containers that, that's really creating problems, so if we just change it this way, it'll help me do the things I'm more accountable for.

14:47Chris RomeoYeah.

14:47Alyssa MillerThey allow that to happen. They enable and really encourage that behavior. There are organizations that are doing that and doing that very well. There's been a lot of discussion around things like security champions programs. We've been talking about that a lot longer than DevOps, but we're seeing things like that come to fruition where we've got this idea of how do we really truly bring those teams together? I've talked to a number of organizations. Auth0 is a great example. Actually, they just got bought, I guess, the other day I saw. But Auth0 has a really good DevOps culture. So there are organizations that are really doing well and they're leveraging those tools. There are others who try down this path but don't really have— this is where, again, kind of that whole vision of the culture comes into play. They don't really have that vision of what they're trying to do. They just know There was a lot of talk, especially early on as DevOps was arriving on the scene. Devs just kind of saw it as, hey, all that stuff we used to have to do, all those controls that were in place, they go away. We just write code and deploy it, and we don't have to worry about it anymore.

15:59Chris RomeoRight.

16:00Alyssa MillerThere were a lot of dev shops that kind of took on that idea that we're just going to go DevOps, and it's going to make us faster and more secure, but they didn't really understand why. The reality was they were They never really got anywhere with it. What I've noticed in the industry, at least within tech, within financial services, some of the more mature areas, is we are seeing high levels of maturity around DevOps. But then we're also in some of the less overall refined from an IT perspective, organizations, things like healthcare and manufacturing and other places, organizations that try to go through this transformation, if they even try it, are just— they're not getting there. They're not really seeing what it is that DevOps is supposed to be, likely because they've got an engineering team that looks at it from their perspective, but they don't necessarily have that supporting viewpoint from ops or from security to help really create that fully rounded culture.

17:12Robert HurlbutYou mentioned Netflix. I remember in the early days, there was a lot of, in terms of examples that we would point to, Netflix, Netflix, let's look at what they're doing. But that didn't fit everywhere, right? You know, not every organization could do that. So are companies adopting to fit first with their culture and then figuring out how they can could be able to implement this or consider it as well?

17:40Alyssa MillerYeah, definitely. I mean, that's a crucial thing, right? DevOps, and this is again why it's important to remember that it's a culture, that it's not this defined methodology or framework or whatever. It's really about building a culture, and how you're going to build that culture is going to be different in every organization.

18:02Robert HurlbutRight.

18:02Alyssa MillerYou know, I mentioned Auth0 before, and I know a lot— I'm familiar with a lot of what they've done to just try to build some of that, what they refer, and a lot of people refer to as like a frictionless environment where devs are just easily enabled to, within their cloud architecture, to really, you know, they have the tooling and the processes that security or operations concerns don't introduce new friction for them. And the same for operations, you know, They have the tools and the process and the support that they need to move in a frictionless way. But then it changes when you look at other organizations. For instance, Datadog is another one that I'm really familiar with. Their real focus was more around how do we build empathy and this idea of shared responsibility, and how do we use security as a way to enable our pipeline and to really build the automation for it? And so that was what was really important within their organization. And so that's where they've had to focus. And so as you look at these different case studies of organizations, you see how each one of them had to do something a little bit different in order to, to, to really address what were either the, you know, the challenges in their organization or to leverage the things that they were already doing really, really strong. and then use that as their advantage or a force multiplier, if you want to use that term, to kind of elevate their overall maturity in rolling out a DevSecOps culture.

19:38Chris RomeoI want to switch gears a little bit, and as we start to think about more specifically DevOps and security together, and I'm going to do something that sometimes could potentially be dangerous, I'm going to quote a tweet that'll give us a piece of, a nugget of information to discuss and maybe even potentially debate. So this is a tweet from DJ Schleen, who's a friend of the podcast, has been a guest a few times, and this is what he writes. Imagine a world where the DevSecOps battle cry that everyone is responsible for security actually exists. Have we just created another silo called DevSecOps, or is the term and philosophy just part of the maturation of DevOps? That one really caught me. I was reading that actually this morning. I was like, wow, that is an interesting idea. Did we create another silo called DevSecOps that we think is— are we seeing the world differently than the developers that we're actually trying to work with? Alyssa, I'd love to get your take on this first. What's your reaction to that statement?

20:50Alyssa MillerI think I know what he's referring to, and I've seen it in a lot of organizations, right? We've come a long way from Gene Kim and Josh Corman and their, you know, security's dead talk at RSA, right? DevOps took off, and we in security were, like, totally caught off guard. We had no idea what to do with it. You know, in 2009, DevOps starts really spinning up everywhere. Everybody's talking about it. We're going to get really efficient, and security was kind of just on the outside looking in. And so yeah, 2012, you know, those 2 guys do their RSA talk, and now security's finally ready, like, okay, we're going to dig into this, um, you know, how are we going to do it? And so we created this term DevSecOps because, well, you can't just be dev and ops working here, we gotta get sec in there too, we gotta have security being a part of this. And so what's happened is, and it's exactly in the words that you quoted, everybody is responsible for security. We came in as security practitioners who said everybody is responsible for security. Devs, you're responsible for security. What's wrong with that? It doesn't tie into that culture of shared responsibility. It says, hey, you guys want to do this? Well, now because we're not able to keep up, y'all gotta do our jobs too. But it doesn't take into account that security, we need to be accountable for making sure that software gets developed quickly. We need to be accountable for making sure that containers are not just secure, but that they're stable when we deploy software into them. It's that shared responsibility. I used to work for a company called Snyk. While I was there, I was responsible for putting together their State of Open Source Security report, excuse me, and we did a survey, and one of the questions we asked on that survey, 2 years running, was, who's responsible for the security of your software? Now, this was a multi-answer question. You could pick as many as apply, right? So, devs, operations, security, and other, or no one? Predominantly, like 85% said devs were responsible for the security of applications. 25% said operations, and I think it was around maybe not even 50% said security. Wait, what? Yeah, I think when we— you think that question about this silo, we did in a lot of cases because we missed the boat again. We totally did not understand what DevOps was all about. We tried to impose our will as security, like basically, you know, put the brakes on it. Like, no, no, no, guys, you can't just go run off and do this. You need to have us involved. How about this? Hey guys, how can we help? How can we enable this for you? How can we make life better for you? All too often, security practitioners fail to address it that way. And so we continued to get shut out. We continued to, you know, be put on the sidelines, or at best it was like, yeah, well, if you can automate your tools, we'll do it. We'll put them into the pipeline and, you know, we'll make them part of our CI/CD. And, you know, so from a security perspective, even today, I feel like a lot of security teams don't get it, and it does create this kind of siloed thing. So where you've got security working on its own, trying to, you know, bring security into the pipeline rather than, hey, security, how can we do things? How can we introduce things like, hey, 3 of us, threat modeling, right? You know, how do we do threat modeling? How can threat modeling actually make this pipeline more efficient for our devs? Let's talk about that for a minute because now suddenly they might want to welcome us in. But we're just not— we don't typically do a good job of that as security people, like showing how security is gonna make things better in your life. We generally are the people of no.

25:03Chris RomeoYep, and this ties directly into, like the two of you, I do pretty much one talk a year that I focus a lot of effort into. And so what I'm doing at RSA for this year is Developers Dislike Security. 10 frustrations and then resolutions that come with what we've done as security people. Where I really landed, it caused me to really have to look inwardly and say, how have I, as a security person, done things in such a way that it wasn't optimized, it wasn't working within the developer's flow? Where I landed on that is this idea of developer empathy. As security people, we have to walk a mile in the shoes of the developers. We cannot just continue to say, well, we're from security, we understand, we know how it has to be done. That doesn't work in a DevOps culture where we're going to be collaboratively working together and saying, hey, we're all in this working together to get towards this goal. That's where we got to get to though, and that's, you know, there's almost a controversial statement in that, you know, security needs to code. It's crazy that that is in the world of application security something that some people take that statement and say, well, no, no, no, they don't. Not in an application security world. But if you're going to work with those developers and try to collaborate with them, but yet you don't know the coding language that they're writing in, that's like, you know, it's like saying, you know, I'm going to advise you about this, but I really don't care about what you do, but just let me tell you how you have to do it. But I don't care about it. I don't care enough about it to actually learn it or figure out the language that you're using or the issues that you're facing. I got a lot of opinions, and you have to follow those opinions. And so, that's where I see this as— I see that there's a lot of truth in this tweet. Like, we've built this ourselves and we are responsible, and I'm addressing us as an industry altogether. I'm putting us all in the same boat and saying, we're all responsible for this because we've built it and we've enforced it, and now we gotta fix it.

27:14Alyssa MillerYeah. And I mean, You know, taking that even a step further, not even just the code, like understand their tools. Have you ever used ADO? Have you ever been in Azure DevOps? If that's what your, your teams are using, are you familiar with Jenkins? Do you know how it works? Do you know how to write YAML to automate these tools? If you don't understand those things, start studying. Because you have to be able to talk about— I'm not saying every AppSec person has to have been a former developer. I guarantee you it helps a ton coming from a former developer. But the fact of the matter is, I mean, honestly, I haven't been a developer in 15 years, so a lot's changed in the last 15 years. But yeah, I do sit down and I spend a lot of time trying to understand, okay, how do these things function in our pipeline? What are the tools that they're using? What do these IDEs look like today compared to what I'm used to? What do the different pipeline automation tools— what do all the deployment tools— what is it even like to be a developer and to define a container image? I'm going to deploy this container. I'm going to grab my base image, but then I'm going to do a whole bunch of stuff with it. As a security person, can I go out and look at an AMI in AWS and say, I understand what this is doing? If not, it really challenges you as an AppSec person. So again, not saying you have to have— no one's going to have all those skills. No one's going to know every programming language, but if you know a programming language, first of all, you can generally speak at least fairly intelligently to the others. You can spend a little time to at least get up to speed on some of it, but yeah, you've got to be able to communicate and meet them where they live.

29:05Chris RomeoI like your reminder too, when you're talking about Azure DevOps, and I think about like all of the training resources that are available whether you're using Azure, whether you're using AWS, whether you're using Google Cloud, there is a YouTube video that describes, or there's training even available from those sites directly for free that talks about like Azure DevOps. What is it? How does it work? What are all the pieces? If you're a security person and your team is building on Azure DevOps and you haven't even taken the time to go and understand the basics of it, I'm going to say it, shame on you. You should be kind of saying, hey, I'm going to support these people that I'm trying to work with. I'm going to go learn this stuff. Because that's how I can support them the best. I think that's where we got to go. But we got to transition, Robert, into our next question because we haven't even gotten to the thing that we were focused on here. We could talk all day long about DevOps. I think we literally could have an 8-hour session here, and we'd still be pretty energetic at the end of it. But Robert, take us into this, kind of what was our primary question for this interview?

30:07Robert HurlbutWell, and we sort of already hit on a couple of aspects, I think, but we were just trying to understand what are some mistakes that AppSec teams might make with DevOps or CI/CD? Like you mentioned, not understanding or not spending time to understand, but what are some other things that, that could happen or mistakes that could be made?

30:26Alyssa MillerYeah, absolutely. So at a very high level, right, it's understanding the concepts of CI/CD and DevOps and how we plug into it. Unfortunately, like I kind of alluded to before, Security kind of scrambled, like, how do we get involved? How do we stay involved in the pipeline as people are going into DevOps? How do we create this DevSecOps thing? I can't count anymore how many DevSecOps presentations I've been to where a person stands up there and talks about how to implement automated security gates. Well, you've got to put a gate here in the build process, and you've got to break the build if something fails. Stop. Gates don't work in CI/CD. The reality is, if you're going to do CI/CD, the pipeline flows one direction, period. You get to the end and you start again. It's that cycle, right? Those who are familiar, you've seen the infinity symbol and whatever else. Anything that you do as a gate pushes the pipeline the wrong direction, and now you've broken it. As far as I'm concerned. So the concept is getting to this point where security is not a gate between phases, it's integrated into the phases. So when we're writing user stories, we're adding threat modeling information in the user story. So when in our CI/CD where that dev is just going to take a user story and start writing code, at least they've got the information there, they understand what the threats are that they need to be aware of, and they can be aware of how to write security controls. Now, if you're really good, they update that user story with some of that information about the security controls. You can leverage that to automate your test cycles. So now you've got test cases that are automated, and those test cases then in turn, you know, can inform your post-deployment monitoring and how you set that up. But integrating security into those phases, so rather than, hey, you did a code commit, now you have to run your SAST tool and do your your static code analysis. Why isn't that built into the IDE? 90% of these tools out there now give you IDE integration. Are you leveraging that? Are your developers educated in, you know, just some secure coding practices? Do they have development standards? Do they have reference architectures that they can refer to? Do they have security champions embedded in their Scrum teams who bring that expertise to bear and can have those conversations? You know, everywhere along the way, get out of this mindset of we're going to put in gates. Gates are the problem. They create friction. We're supposed to be making this frictionless. So how do we get involved? And it's not just the technology, it's, hey, security people, are you— is there somebody with security knowledge attending your daily standups? Are you going to sprint planning meetings? Are you going to retrospectives? Are you a part of that process? Really making— if you're going to make a culture of DevSecOps, well, Dev, Sec, and Ops should all be in the same meetings together, working together to make these happen. SREs are meeting with them from the Ops side. Why aren't we from security doing the same?

33:44Chris RomeoYeah, I think that's— I like that approach that you're describing about not setting up not being a gatekeeper, right? That's been one of our struggles as security people is we want to be able to define the gates and we want to be able to control. It's all about control. And so one of the things that we've been recommending, we've just been in the process of building out content for helping people with secure coding with Ruby, secure coding with Python and JavaScript and some other languages. And one of the things that we've kind of fallen on as far as a a best practice from a DevOps perspective is to take some of those tools that would normally be gated and bring them into the developer's environment. So to your point about whether it's IDE plugins, whether that means I'm running certain tools on each code commit before I even start the pipeline going down, and so we're shifting left with our tools here, but seeing that as more of a best practice, like why let something get into the pipeline if it has a dependency vulnerability in it. Like, you could scan that on CodeCommit. There's different things you can do at different times in the CodeCommit process. And maybe you're running a check also in the pipeline because you're so afraid of a third-party vulnerability sneaking in. Maybe you've got it in both places, but it shouldn't be a gate. It's really more of a, you know, last-ditch effort to check it in the pipeline because it's been checked at CodeCommit. So that's kind of the way, and it sounds like that's consistent with what the guidance, Alyssa, that you're providing.

35:16Alyssa MillerYeah.

35:18Chris Romeoproviding here as well. It feels like that kind of lines up together.

35:21Alyssa MillerYeah, for sure. I mean, it's, you know, and there's a lot— and look at all the tools out there that do that, right? Like you brought up dependencies. Well, look at Snyk, look at WhiteSource, look at Black Duck. 3 of the— probably the 3 most popular tools for that. Every one of them plugs into multiple areas. They can integrate into the repo. So like you said, the minute a code commit comes in, They scan it. They know, you know, they grab all the dependencies, they go check. You know, some of them even do monitoring then all the way, the rest of the way through. So if a vulnerability pops up, a new CVE is released on a particular library that wasn't there when it first got scanned, they warn you about that. I mean, boy, could you imagine had Equifax had that back in 2017 with their Struts vulnerability? I mean, seriously, like, you would have had this tool that said, hey, you have this vulnerable version of Struts right here, go get it and fix it. But, you know, so looking at these tools, there are those capabilities. Yeah, we just, we, we need to be better about leveraging them. And let's be honest, I mean, in security, we struggle with that too, right? How many times do we buy big grandiose tools that can do a ton of things, we implement like 10% of it?

36:33Chris RomeoWhether we have all the blinky lights though, we used to in the data center, we could bring the execs in and say, see all that rack of blinky lights? That's your security investment right there. But I don't think that works anymore.

36:43Alyssa MillerWe don't have that because it's all in the cloud now.

36:47Chris RomeoIt's all on Amazon or Microsoft.

36:48Alyssa MillerWater data center or whatever.

36:49Chris RomeoSomeone needs to build an app that makes the blinky lights in my browser so I can be like demonstrating it for people and be like, hey, look at all the blinky lights we have here in our connection.

36:58Alyssa MillerHere's an idea for the cloud providers. Provide a video feed, a livestream where people can just hang really big picture frame size screens that just show the live feed from the data center.

37:13Chris RomeoThose are our servers, we think. Oh, wait, we just moved. Our stuff just got moved there. They were balancing and they moved us. Move the camera.

37:22Alyssa MillerIt's over there now.

37:22Chris RomeoTilt left, tilt left with the camera. Alyssa, as we're coming towards a close in our conversation here, what's a call to action? We talked about DevOps and Agile and CI/CD and mistakes, and we talked about culture, and we talked about a lot of different things. If you could direct our audience with like, hey, here's one thing you should go do, what would that be?

37:47Alyssa MillerSo, at a very strategic level, I'll say, focus on that value that security brings to DevSecOps, right? What is it that security can do to make their lives easier? How are you going to make lives of developers, of even your business folks, everybody who's involved in the process easier? So at the very tactical level, the first stage of that is looking at how can you as the security folks bring threat awareness early in the process and then automate the tools that you're asking them to use in a way that they integrate frictionlessly with what they're already doing. That will go so far in getting cooperation from your teams. I can tell you as somebody who in my organization right now is going through this transformation, how very cooperative and excited your engineering teams get when you show them, hey, I'm not creating something that's going to give you a headache. I'm creating something that's going to make your life better. Suddenly you've got all the cooperation in the world, plus it's a lot easier for you to get funding for a lot of that stuff because you can show, hey, invest in this security initiative and I'm going to make it so we can deploy faster by shrinking the backlog or speeding up, you know, the pipeline with automation or whatever it is.

39:08Chris RomeoAlyssa, thank you so much for sharing your expertise here. I know you've done a lot of talks about DevOps, and I'm guessing we got a couple of different— some pieces of each one kind of came out in this conversation, but it was very useful. The conversation about governance and the reminder about not putting gates up, these are things that are going to resonate with me for a couple of weeks here as I continue to ponder it. Thank you for your time.

39:33Robert HurlbutThank you.

39:34Chris RomeoThanks for appearing on the podcast again, and we look forward to a future conversation. Maybe a year from now, we'll see what's happened in DevOps since the last time we talked.

39:42Alyssa MillerI appreciate it. Thanks for the invitation. It's always an honor to join you guys here.

39:51Chris RomeoThanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.sec.podcast. securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination.