DevOps Building Blocks Part 3 – Making the “Sec” in DevSecOps Happen – DevOps Unbound EP 40

Hey, everyone. Welcome. Welcome back to another episode of DevOps Unbounds.

If in case you're not familiar, DevOps Unbound is in every other week, uh, video series where we explore relevant topics in DevOps. And then about once every month, month and a half, we actually do a live version of DevOps inbound, where our studio audience or our, they're not really in the studio, they're on Zoom, but our live audience drives the questions and, and, uh, commentary of our show. And we have one of those coming up soon.

com, you can see the schedule. Today's, uh, version, though it's not a Live studio audience or a Live Zoom audience, it's a panel discussion and what a panel it is. I'm gonna introduce you to them in a second, but before we do, there's a little bit more housekeeping I have to take care of.

ai, digital cxo, and of course, tech Strong tv. Thank you for joining us. I mentioned Tricentis is our sponsor.

You're not gonna see anyone from tricentis on today's show, unfortunately, but that doesn't decrease the gratitude we have in the influence they have on us here. tricentis is, are leaders in continuous testing. They've been around a while as well.

com, and we're very grateful for their support and partnership on our DevOps Unbounce series. Next, um, these panel discussions are a little bit of a conversational free for all. We're gonna, we're gonna try to stick to the topic, but with a, this, this particular panel, who the heck knows, but we'll hope for the best.

We have some, it is an amazing panel though. com and, and we'll try to get to you. So that being said, this episode sec, uh, title is Making DevSecOps Happen, making Stuff Happen.

This actually is part of a, a little mini, you know, concentration we've been doing on DevOps Unbound on what we call our DevOps building blocks. This is part three of the DevOps building blocks. You can catch part one and two on Techstrong TV anytime you'd like.

Uh, but we're here to make DevSecOps happen. Couldn't think of a better group to make it happen with. Let me introduce you to them right now.

First of all, if you're gonna talk DevSecOps, you gotta talk about this lady. She kind of started it. org was her baby, and she's done so many things ever since then, and I always get a kick out of spending any time with her, whether it's in person or in law.

Online, though, in person is always better. My friend Shannon Leeds. Hi Shannon.

Welcome and maybe introduce yourself. Hi there, Ellen. It's so good to be here.

Um, you are absolutely one of my favorite people. I love the work we do with creating awareness in the industry about change and, and we're really where we are all actually headed. Um, I'm Shannon.

Lets, for those who don't know me, I'm the CEO of third Sport. It's a, it's a startup. Uh, so I've, I've ventured out into startup land and I'm really excited about that.

I've been in the industry for over three decades. I am what you would consider an emerging scientist researcher. I write code, I do lots of things.

I wear my dev hat at night and my, you know, other hats during the day. And, uh, this industry is something that I am super passionate about and super excited about in terms of helping us to transform. I think that there's a lot of work still left ahead when it comes to DevSecOps, and I think that we really need to band together to see everybody not left behind that we raise Alba.

Absolute thank you. It's always, it's our pleasure to have you. Thank you for being here.

Next up, another one of my favorite people coming at us from the land down under Boulder, Colorado. Um, the one and only Andy Mann. Andy, welcome.

Hey, Alan. So good to be here. Yeah, look, this is my Colorado accent.

I, there's nothing much I can do about it. Boulder has just bred this into me. It's great.

Uh, mate, it's so good to be here. Uh, really enjoy this series and this idea of foundational principles. I've written about this a lot.

Ah, man, I'm, I'm, I'm excited to get into this. This is gonna be great. And, and Andy, you, you are CEO of your your own analyst firm.

Now, Sage. I am. I am.

I, look, I call myself global CTO 'cause you know, the CEO stuff, I don't think I'm ready for that yet, mate. Uh, but as A-C-T-O-I think I can make this stick. Uh, yeah, Sage is my business.

It's a advisory firm, research market research, trusted advice for technology innovators and, and, and, and executives. Uh, and look, it's been great. It's only been running now for about six months, covering mainly around ops, the boundary lines of operations and all the things operations do.

And so I'm coming at this from SecOps, but I got a little DevOps in me as well, as we all know. So I'm excited to talk About all of it. And I, I wanna talk about this distinction between DevSecOps and SecOps.

We're gonna jump on that, but first I need to introduce our third panel members, the lady in Pink, Tracy Bannon. Tracy, welcome. Hey there, guys.

It's actually great to be here with all of you, Andy. It's nice to meet you. Now I've spent a good amount of time with Alan, uh, with Mitch, and with Shannon.

And actually Shannon and I are kind of like twins in terms of the things that we like to do. But coming at it from slightly different vantage point, a couple of decades in industry, but I'm a software architect and engineer. Um, security has always been a part of what I needed to do to take value out into production.

I work for a firm called the Mitre Corporation, federally funded research and development. So I kind of get to do the best of both worlds. I get to drive towards that leading edge, bring those innovations in, define new ones, and help to educate people in a, in a really objective way.

So, I loved community build. I love to contribute like this with, uh, tech strong with these types of conversations. 'cause there's a lot of stuff we have to do to help a lot of people.

So with that, I'll turn it back over to you, Alan. All right, chase, thank you. Let me introduce you then, to the last person I'm gonna introduce on our panel today.

I always save him for last. He's my co-host and CTO Principal gm, or principal Analyst GM of our Techstrong research group. My friend Mitchell.

Ashley Mitchell, welcome. Hey. Yeah, yeah, yeah.

And I thank you. Thank you for the introduction. Introduction.

That's definitely what I do. And, uh, as well as talk to these wonderful people, uh, any chance I get. So this is a great panel.

I think everybody's gonna love the conversation. Absolutely. So let me kick it off.

You know, I, I recently, I just signed the contract with R-S-A-C-R-S-A conference to do our, uh, DevOps Connect DevSecOps event Monday May 6th, uh, for RSA this year. I think it's the eighth or ninth year we're doing this. Right?

I love it. My friend Mark Miller works with us on it. Mark is gonna be driving a lot of it this year.

Um, I remember to, the first ones we did, it was, I gotta be honest with you, it was a, it was a, a, a, a, a pushing rope uphill event to get my security friends. 'cause I come from the security world to say that DevSecOps was a thing. First of all, they didn't even want to use the word DevSecOps.

They were talking about rugged DevOps and, and this and that. And, and, you know, is it marketing? And I don't even know if this DevOps is real.

Why does security have to do with it? It was crazy. Shannon, Shannon was there, actually, right?

She was one of the early putting out the manifesto, the, the, the actual manifesto for DevSecOps. I'm glad to say that as I sit here eight, nine years later, it's no longer pushing rope uphill. People I think generally acknowledge DevSecOps is real.

It's a thing. It is. It's part of this.

Um, and, and we've been able to bring together some of the DevOps tribe with the security community. The whole ops piece of it is, as Andy mentioned, is still kinda work in progress. But DevSecOps real, at least it is.

Maybe 'cause we all live in a DevSecOps bubble. When we look at organizations, when we look at the market, is, is DevSecOps real to everyone or is there still, I mean, there's always gonna be laggards, but am i, am IS you know, breathing my own exhaust? How, how real is DevSecOps when we get out into the real world?

Anyone could start, I'll throw out the grenade of it depends. Okay, it depends. It, I gotta start with, it depends.

We gotta start with wishy washy. It truly does depend on the domain that you're in, the regulations that you have to adhere to. It depends on the size of the firm, all of those different things.

It is pervasively known about everywhere. The trouble is helping people to adopt it in a reasonable way while changing their corporate cultures and helping them, well, helping them to build a new corporate culture and helping them to change their policies and get the skills that they need to get after this. Fair.

Sean and Andy, Mitch, thoughts? I was gonna chime in. So I, I don't think it depends.

I'm gonna be the counter on this. Um, I actually think that if you're building software, which most companies are, you're doing dev SecOps, you're just at either an early part of the maturity cycle and trying to figure out what to adopt, when to adopt it, or you're in the later part of the cycle realizing you need to work on continuous improvement. And there's all shades of parties in between.

And, you know, there's not necessarily one way to organize something. But I do think, uh, what the industry is possibly working its way through is what is cybersecurity and how does it work with product building and product development and software development? How do we consume products successfully from a security perspectives?

And, and ultimately, how do we achieve the balance of say, resilience, adoption, velocity and errors? Because that's ultimately what we mean for software trust. I think when, when we really first started DevSecOps Manifesto, it was about building trust and software, building software safer, sooner, you know, making it so we're building durable long-term capability as an industry.

And so I, I tend to believe that we're all on this journey together. Together. Some are kicking and screaming and other folks are going willingly and actually paving the way.

So we actually are in complete agreement, not disagreement. My, it depends, is exactly that. Where are you on that continuum?

If we consider the continuum could be that you are just truly starting your journey. I'm with you all the way, Shannon. Well, I I wouldn't say I would call it consciously or unconsciously.

You're doing it right or deliberately or not deliberately, right? No one, no one is raising their hand and saying, screw that. I want to, I want to develop unsecured software.

I enjoy putting out some really buggy crap into the market because after all, I have to get it done in time. It's about the value, right? And, and you know, no one says I, so I think deep down, we all want to deliver higher quality, But it isn't a want, uh, right?

That the question was where are we? I would agree with you. Nobody wants to do a poor job.

Nobody wants, except the nefarious actors. Nobody wants to put buggy code out or bad code out. But the fact of the matter is, it it, depending on where you are starting the imperatives have the risks.

Whether they are software risks and whether they are risks with your infrastructure, whether they're management business risks, it's how you are addressing your risks to still be able to deliver that, that value. At the end of the day, we've gotta deliver value and we wanna do it sooner, safer, happier, right? Yeah.

You know, I would, I would just sound one note of caution on this and maybe it's because I'm in the Rocky Mountain West here. Uh, and, and I don't get sucked into certain bubbles sometimes, but larger enterprises especially, you've still got these walls and they, they trouble me greatly. Uh, and the, and I think you are right.

Developers are trying to be secure. Uh, operations are running secure operations and they're all trying to do it. The, I think the key here is that DevSecOps is one word.

And that's what is challenging I think in the business that I'm in, talking to customers about how to do these things, especially larger enterprises. So yeah, I actually agree with you. I think I love it depends by the way, because so true.

Even some of the largest enterprises are getting this right, sometimes in pockets, sometimes broad, more broadly. Um, and, and it's definitely something we want to do. It's something we believe in as people, as developers.

I don't think I talk to anyone who wouldn't agree that we wanna develop and deliver and run secure software and they're trying to do it, but oh wow. There's pressure, there's budget pressure, there's time pressure, gotta get it out. Uh, it's, don't get in my way.

You are a roadblock. You are not. There's so much of this conversation, I think still happening in larger enterprises.

But you're bringing up a great point, Andy. There are so many different subgroups within organizations. Even if you're a very tiny startup, you have, if unless you're a single shingle, one human, you've got multiple humans in the mix, getting to definitions that people understand so that when they're saying these words, it means something similar to those people, at least in that room.

Education, the upskilling, to know what these things mean. If we kind of break down DevSecOps instead of it being a team that's over there and start to break it down into the principles of what you're trying to accomplish, people start buying in. Andy, we're gonna have to talk.

'cause I'm married to ops and I'm all, I'm all in on his side of this, that we had to do a better job. DevOps often, and DevSecOps has often been more focused on rapid development, more effective development. We haven't paid as much attention historically to what we need to do for ops.

I think it's an important point, Tracy, that it's not whose job it is, right? Which is sort of our siloed thinking. And we do have silos.

I mean, you're right, Andy. Look, those are tremendously hard to, to move past. It takes a lot of work, a lot of collaboration to, to get to that place.

Um, but thinking about more, you know, it's not whose job it is. It's every, every flow in the process. What are the, where does security play in that and who, who helps define what's important to do for security and who implements that could be the same, could be different people, could be people working together.

And so I can't think of it as a full supply chain or, or, or pipeline. Let's think of it that way. And workflow, pipeline and security happening in all parts of that.

And is it shifting right over here? Yeah, it's shifting, right? It's shifting left over there too.

But it's really part of all parts of it. And you know what, it's gonna be uneven, you know, innovation is uneven, right? And uh, you're kind of working on each part of it, maybe more so others than another.

We heard recently, I think it was Larry Macaron who said not don't necessarily shift left. And I, I love the way he said, I think he said shift smart. So to your point, Mitch, yeah.

Drawing things. I was in on that one. Yes, you are drawing things in both directions.

Security should be ubiquitous, right? Just like testing mindset should be ubiquitous. Then that, you know, then the challenge becomes how do you move in that direction?

I mean, Shannon, you're at the manifesto. How do we jumpstart an organization into learning, understanding and, and moving in that direction? Well, yeah, and I, I'm hearing a bunch of things that I think are still maybe following some of the, the marketing that's been out there for years.

And I think as a industry, one of the challenges we have is that these words get taken by the marketing folks and perpetuated and, and in my mind, um, you know, and having the market now, no, no, no, no. I actually love marketers. I think that they're fabulous.

And I'm gonna actually tell you a different tune, which is, I actually think that to be able to do, do true DevSecOps, we keep talking about it like it's a pipeline. It's not a pipeline, it's not SaaS. When we talk about shifting left, what we're really talking about is the business starts through a process of trying to figure out how to accommodate customers and build features for customers.

And we don't talk about how we think about customers in the right way, uh, when it comes to building software where adversaries are concerned. So in my mind, and this is how I kind of express it, because I think it starts with the pipeline in the right way. If we're gonna talk pipeline, it's um, you have to have an adv adversary mindset associated with your software development.

And that means that adversaries are just customers. You don't want, you gotta start there. Like I think marketing is my best friend when it comes to trying to figure out which adversaries should we be concerned about as an entity.

Why is it so challenging to get a concept like this through? It's because we don't start with the right thing in mind. And that's actually when we wrote the manifesto, we wrote it with this mindset of adversaries first.

'cause they're the ones we don't want in our pipeline. And when I say pipeline, I don't mean it the same way I think folks take it. When I think about pipeline, I'm actually thinking about customer pipeline.

I'm thinking about it from that business perspective. The things that you do to build software are a little tiny microcosm of the bigger, broader whole. And so when we talk about shifting left, we're talking about that feedback loop that incorporates a business that we're actually building off of the feedback loop of adversaries coming and showing up.

And we're actually building defenses into our software, into our systems, into our people to make sure that we're serving the people we, we most intend to serve. And I think this is where, when folks talk about shift left, I'm like, you still don't get it. Go look at the little diagram that was drawn long time ago.

'cause it actually shows the little bad guy in the hat. The little bad guy in the hat's. Probably the most important of that pipeline.

And the pipeline is not just what are you building and the development process, again, microcosm, the, the macrocosm in your organization is not even just your own organization, it's your third party ecosystem. And, and we really have to get DevSecOps sorted out in terms of non-marketing language. What is the, what are the principles of it?

And I think it starts with adversaries. If you aren't mapping your adversaries and you don't have metrics at the end and you don't have your software running through that, where you can actually say, you know what? We can trust our software.

It's actually achieving our customer goals. It's achieving our adversary goals, then you're, you're probably in the very early infant cycle, like I said, everybody's on the boat. 'cause like I don't believe in anybody being off the boat, but you're in the early cycle.

And then learn from some folks that have actually been there, done that and actually have written the book several times, but just won't write the book. 'cause it's a lot of work. Um, we talk about it, we teach it.

I, I think I've written the many books through videos, but I, I ultimately think there's been plenty out there that have gone that path. The thing I have not seen yet, and this is where Alan comes in, thank you for having the 10 year reunion this year. We are on the next 10 years of this cycle to really finalize the maturity process of this metrics.

Adversary personas, just like their marketing personas for customers, right? Get your pipeline sorted out so that your language matches the business. And you know, ultimately to me at this point, if you don't have your panel metrics, if your CEO doesn't understand or doesn't care, you're, you're on the technical part of this journey, but you're not yet on the business part of this journey.

You said something, Oh, go ahead. I was gonna say, Shannon, you said something I think everybody needs to latch onto actually two things. One is the persona of the adversary.

Uh, and treating them like another type of customer or stakeholder would be another word that I would use a thousand percent. Um, people, everybody who's listening to this panel needs to hear that. The other thing they need to cue in on is just like you, when I talk about flow, I'm talking about vision, business, vision the whole way through to fielded operations the whole way through to end value being delivered and received and the adversaries along the way.

So I talk about flow, whether we call it product flow, but that needs to be that broader conversation. If we continue to look at a figure eight or a, an infinity loop and say that that's all that DevSecOps is, we've kinda lost before we've ever gotten started, right? Yeah.

I love, I love that idea of getting past the infinity loop. Oh yes, please. So I mean, just thank you so much trace.

Uh, and look, I'm just fanboying over here for a little bit 'cause I'm listening to you two talk and I, you, you're talking about such an important thing, mindset, right? Uh, you're talking about changing the culture, um, talking about customer centricity, but most of all, you're talking about things to do. Culture.

Culture is an interesting thing, right? I fundamentally believe culture is a thing. You do not a thing.

You believe it's a result of activities. You can intu a culture by looking at the things that people do. The, the, the artifacts of activity define how other people see you.

You can have culture of DevSecOps in your head all the time if you're not doing anything. So this idea of actually bringing those security experts into those early planning me meetings, having that mindset where as a business you say, we will protect our customers because our customers are who we are servicing. You know, these are steps you can have.

One of the things I, I have a challenge with when I work with larger enterprises, actually, what do I do? So I read about DevSecOps. I believe in DevSecOps, but I'm in Dev, I'm not in sec.

So what do I do? Uh, you're giving people things to do and I think that's where, you know, 10 years on, we have made so much progress and thanks to people like you, mainly that we get to this idea of doing things. Not just talking about how to or what to, or culture or, or, or thinking.

But, you know, it's an action we've gotta take. Mm-Hmm mm-Hmm. I wrote a lot and spoke a lot over the last 18 months about something I call no hobbyists.

I actually have it out there as a hashtag every once in a while because as we've, because we've concatenated some phone names, DevSecOps, and people assume we need to shift left, right? Marketing hype to, to Shannon's point, there's also been a lot of responsibility clogged onto delivery teams. Whether you say that, you know, whatever makes up that delivery team, not withstanding we've clogged a lot onto them.

We cannot expect delivery organizations the delivery part of this to be responsible soup to nuts for security by any stretch of the imagination. We do need to provide upskilling. We need to provide opportunities to also collaborate.

I suggest that when you're having your initial focus groups with those end users, that security is there also prompting them, helping them think about it. Um, I think it's Allison Miller. Um, we both last year spoke about this concept.

We came at it very differently, but came to the same end that you can even leverage your user stories if you already have some user stories as a way to expose the end users and the entire team to thinking about security. So extend the mad lib as a, I don't know, an owner, I want to x, y, Z so that I, right? That's the mad lib.

If you add onto that, that I would like you to protect this bit of my information from this potential, right? Um, backlash or potential nefarious actor, people start to think that way. And it is a different type of thinking.

An example is, I would like to be able to enter in information into a, an address kiosk and receive directions on how to go there. And I need you to protect that information when I leave the kiosk, when I walk away. So people start to think about, oh my goodness.

So everybody needs to become steeped, right? To Shannon's point, everybody needs to be steeped in security thinking for us to begin to address putting it across all the aspects of the flow. Yeah, I think building, building onto your, um, mad libs, what I would say is, as a customer, I would like the software that software manufacturers build to be script kitty resilient at a minimum is a good use case that I haven't seen yet in, in most companies.

And why isn't it there? Because I think that's the beginning when we talk about threat modeling as an example, uh, one of the most crucial and critical components that you could do is threat modeling. And why don't we do it?

Because we don't actually treat it like the right component part that it is within our thinking. It is absolutely test planning. You are adversary pet planning.

So when you go to verify your controls, you should be using that threat model to determine whether or not you've been successful at mitigating the risks you think you should be mitigating. And then if that doesn't work out and you get an incident, you should tie it back to the threat model so that you're constantly making that threat model better, improving your defenses. And yet what we see is threat models get done, they get shelved, no one ever looks at them again.

And they're not, they haven't become a very rudimentary part of this process. And I think this is where we're still sort of failing as an industry Mm-Hmm. Is that threat models are crucial test plans that you need to have to verify.

They should be going to your pen testers, like whoever's gonna help you verify that your stuff is working, you should use that and they should actually have adversaries on them. So which adversaries are you threat modeling today? What persona are you trying to work on?

I, I think we talk about it, but we talk about it so deep and we don't actually talk about it in the way that actually makes it simple, tangible, useful, exchangeable, like all these things that actually operationalize what it means to build safe software. And that's where I think we have to kind of move from. It's a tool, it's a person, it's a culture.

It, it is actually much more collaborative than I think people think when you do it well and it it requires you, like, I'm gonna just tell you, I've sat with marketing folks and I'm like, what is SEU? And they're trying to explain to me and I'm like trying to explain adversaries and frankly, it's the best conversation you can possibly have. But I'll tell you that's just all, when we talk about silos and walls and all that stuff, it's actually language folks.

Like, let's just get past the word wall. Let's get past the silo term. It's language.

Like figure out how to simplify what you're talking about. You are the expert. But in that room where you're trying to collaborate with somebody, like you need stick figures.

F yi You brought, you said the word collaborate and that kind of brings us back to the threat model as I see them often threat models are done over here by this special group. And to your point, they are shelved. Imagine if you bring people together and expose them to threat modeling so that it is not done in isolation, so that it is not shelfware so that it becomes a continuous living document or living body of information.

I had really good Success. It's a test plan In starting that. It it is.

And not everybody is a part of that. I mean, I know that we live in very different worlds in terms of who I serve at this minute. I work a lot with the federal government and I can tell you that there's a lot of things that we're working to change to bring those people together.

But it can be very difficult to get the right folks in the room. Exactly. To your point, everything you're saying, Shanna, high five, total agreement.

I think the challenge we have is we built our own language for threat models and now we have to teach threat models to people and they don't actually use it on a daily basis. So why can't we just simplify the concept of threat model then call it a test. Because that's what it's, I was thinking we might use threat model.

We bring our, we might use language to developers and they go, huh? Right. You know, so we, it's the, we get in our own ways sometimes.

Yeah. Threat models are for us. FYI, you wanna be a security practitioner?

You should, you should speak stride. But do you need to have the whole world speak stride when like, that's not their job. What you gotta figure out is, all right, so I, after we strided, here's the boiled down list of things that have to get tested.

Did they actually get tested? How did we test them? How confident are we?

Like that's the language that's been in software for a really long time. QA has test plans if you go look at them, they don't look anything like a threat model. Like what are we doing?

And this is the idea of of of, you know, t-shaped people, right? The idea that you don't have to be the expert in security to take security seriously and build it into your practice. You know, it's about, you said it trace I think over collaboration, right?

Um, it's about collaborating. It's not, I don't have to be a security expert in ops to understand that I need practices and processes and maybe tools to help me manage secrets in prod, right? Um, so yeah, I gotta rotate keys, I gotta all this stuff.

I don't need to be a security expert, I just need to work with a security expert and help me this in In, yeah. Yes. Something I've been looking at for a long, long time is this idea of boundaries crossing the boundary lines if 'cause you are right trace, we talk about, uh, the differences in the wall.

Sorry Shannon, we talk about the wall, right? Um, and it's not really, it's just this hump, but it's a boundary every time we can cross a boundary line and meet someone on the other side and just help 'em a little bit. We are doing DevOps and we're doing DevSecOps.

We don't have to do their job and heaven forbid they should do my job. Exactly. But let's t shape collaborate, you know, all of that stuff is how we do it in practice.

You don't have to do it yourself. Lean on your team. And by the way, it works the other way around for security people.

They don't understand a lot about what we do or why we do it in operations, for example, right? I've gotta change my language in terms of availability and uptime responses and stuff and what it means to my customer. 'cause ops is at the coalface, right?

What does it mean to my customer when I have insecure software and we have to deal with it in real time in prod? How does that affect me? How does that affect you?

Collaborate, talk, cross boundary lines and yeah. You are both talking about ways to do that and I love it. Absolutely.

So this again goes to I think something i, I fundamentally see out there. And it, and it was also a mistake that a lot of the DevSecOps vendors made. They tried to take security tools and force them down the throat of developers and, and even ops folks or DevOps teams that weren't security people.

So it was like taking a a, a Greek dictionary and giving it to a bunch of kids who only speak English and, and saying, Hey, you better, you better understand the top 10 things in this dictionary. Number one, they didn't ask for the dictionary. Number two, they don't speak Greek.

Even if they wanted the dictionary, it was the wrong dictionary to give them. And number three, you were trying to get them to change. Fundamentally what they do is, or what they consider is to be their job, right?

People get real touchy about that stuff, right? If I want them to Be a the opposite of that, Alan, I saw the opposite where I wanted to provide the delivery teams with at least the visibility into some of the scan tools and into some of the security tools so that they weren't waiting for a special person to come in and look at it. And we ran into some interesting licensing challenge and budgetary challenge, different funding lines that said, Nope, only these security folks can use these tools.

And it was hard fought. It wasn't to remove those tools from security. It was to say provide as consistently early feedback as possible to those developers.

It took about a year and a half to work through that. And it eventually helped, but it required helping all those mindsets as well. Why do those developers need access to our tools?

Well, why don't we together look at how we can help operations by providing them more secure higher quality tools, reduce that cognitive load, help security to help us learn more about delivery and about the development pieces, help security understand what we're doing over here. Right? So it helped everybody, but man, No, but I, I think giving them security tools that are not made for them ah Mm-hmm.

Is again, you, you, you, you're swimming up upstream. I'm gonna pick up on that for a minute because I agree. I Agree because I'm gonna pick up on it for a minute.

Mm-Hmm. So I go in and I'm in like one of the development eyes won't say which one. 'cause you know, I'm trying to be fair and impartial.

Impartial, but let's just say I go in there and I search the word security. How many companies have really put an IDE plugin in place for the developer to be able to check their stuff early on for the test plan in the threat model that proves their stuff is adversary resilient? Mm-Hmm.

So the problem that we've had in in the industry is when said DevSecOps, like I think within a very short amount of time we saw highly mature DevSecOps products. Like that's a non-natural evolution fyi. And so, well I Think it's an oxymoron, but Yeah, I was gonna Say, and and you can see it in the market for DevSecOps tools is that there's been a plateau because those companies have taken legacy products, slap the label on 'em, they don't actually match what's necessary for there to be collaboration in the ecosystem.

And so those folks actually need to invest in solving the problem if they wanna continue the market. And so there are tools that developers need and there are tools that security folks need and there are tools that ops folks need to be able to run safe software. And, and our challenge right now in the industry, and, and this is really kind of a, a interesting place to be, we're at a very stagnant time in DevSecOps.

So if you're listening to me and you are a vendor stop competing with the same stagnant legacy tools, there are plenty of developers who would love to put a plugin in that actually can help them. Thank you. Some of you vendors out there that have like, specifically in the API security market, there's a few that have really gotten it and like they have some good stuff and thankfully like developers actually care about their stuff.

Um, folks talk about, you know, product-led sales in security and in developer part of the world it's product led growth. So those sales cycles and how we actually think about it. So if you wanna thought of security folks put security tools together that make it so you can do verification of controls, you can mitigate threats, but stop thinking that you have to do everything and then you're gonna just slap that it's a developer friendly tool and whatnot, right?

I'm not, you know, not to be a critic of it, but if you really wanna help the market, and I think most do, so Alan, I would just say this is what we had at the time and thankfully it actually happened because these tools needed to get put into the CICD pipeline or we were all gonna lose. But that's not the end, that's not the vision. If you aren't actually mapping your adversaries, you don't have test plans, you haven't got threat models that work, you don't actually have those feeding back into containment loops of incidents.

You're not actually building the right arsenal to be adversary resilient. And I think that's what's gonna be most durable long term. We've gotta sort this out.

I got a question for you. In your, in your, you're giving good advice to the market, right? And what, what you're seeing is needed.

What, what, what's your advice for people today who are like trying to figure out DevSecOps and how do I do this? And here's Shannon talking about, but I don't find a lot of that yet. Or I know these things.

Is that what I'm supposed to use? How do you help someone who's kind of grappling with those kind of questions about debt? Yeah, They, the adversary thing, super easy.

Start with if there's a low skilled adversary out there, you wanna prove your stuff as resilient enough, go look for the tools that are out there and test your software. Even if it is in fraud, stop being afraid of testing your stuff in prod. Holy heck, your adversaries are doing it.

Your stuff isn't falling over. So why is that such a non-normal event? I, I really like, once upon a time somebody told me I had to schedule with them to test their code and I was like, um, the adversaries aren't gonna do it, so neither am I.

And you know what, that became a norm because I said no. And sometimes it's boundaries, Right? Every day Go, go build your adversary map, here you go.

Low, moderate, and highly skilled start there doesn't even have to be precise. It's, you're gonna get to 30, maybe however many adversary personas, but start with that, right? Just skill and then prove with like, hey, bundle your tools and say these would be moderate skilled tools to run.

'cause they take me, you know, 300 hours to learn. So like they're gonna take adversaries that long to learn. Uh, and I think that once you kind of go there, you know, you have a little scorecard at the end that says, I ran my software through and I didn't have a lot of books, so therefore good.

I think, uh, I wrote an article on Medium about secur ability and I'm still waiting for folks to decide that they need to have a metric. I threw mine out there. Beat it up.

If you don't like it, find something else that works. Argue with me. Debate.

Let's get to something that's standard that we can leverage, but like it takes the courage and bravery to, to get started. So I would say, Mitch, some of these things, they're already out there. You can do them.

They're simple and you have to start, like developers need to start mm-Hmm. If you're a developer, by the way, blank sheet of paper and a pencil, tell me how to attack your software and go fix that. That's a, that's the beginning of your attack plan.

And guess what, that becomes the beginning of a tech plan. And then it can get s strided and you can get help from security people that's start with blank piece of paper and send it to me. Bring in the security expert, bring in the whoever, right?

All right. Use your arsenal around you, but you as the er, like I developed software right now at night. You know what, I did blank.

A piece of paper becomes sort of the beginning of your threat model. I didn't have the time to stride. So that kind of becomes the beginning.

So Mitch, I think get started as my, my message. Cool. I'm gonna, I'm gonna add just a little bit to that.

Thank you. You're right on what has to happen. Everybody needs to have some patience and some, some guidance to help people because the builders are not by nature necessarily the breakers.

So teaching them to break think, to think about adversaries is a little bit of a mindset shift at first. And the same thing. Those folks who I call the security folks and the testing folks, the breakers, they're not always in concert with what development is doing.

So there is some beautiful mindset sharing that needs to happen too to help a developer to think exactly like you're talking about Shannon, You're coupling sort of development, the test driven development, right? Sort of that to use It for adversary development. Yeah.

Just expanding that as part of your portfolio of what your testing is. Right? And to your point, Shannon, you can use your, your personas or ways to detect softwares to guide you if you don't know how to create all that upfront.

So it seems like that would fit really well into, you know, a workflow that a developer's can do on a regular basis. I'm already doing that. I just add more new tests.

Right? Yeah. Fair.

How about the op side? Do we have, are we running Outta well? No, Mitch, you got, you got two minutes, so go ahead.

I'm just gonna shout out to the, this whole op side of this too. We haven't gotten to, and Andy's like pacing in his chair and he's, he's only a few feet higher in altitude than I am. So I'm, I'm in the same bubble free zone, but Okay.

I, I just love that we spent, uh, 25, 30 minutes talking about dev and sec and now I got a minute for ops This big damn little op 45 minutes. But I'll tell you what we're gonna do. We're gonna do a part two where, 'cause to me this is one of the problems too.

We had feature crawl with DevSecOps. It went from about helping developers develop secure software all the way through to the other end of the, of the conundrum here to SecOps to, you know, PO to real, real time security and, and you know, post-release and, and observability and it's all part of DevSecOps. Is that really, was that the vision?

I, I don't think so. So let's, let's cut this one here and I'm gonna ask our friends at Tricentis and my tech drunk production team to rerun schedule another follow up to this where we're gonna shift right? A little bit, right?

And and take a look. Don't, don't hit me Shannon. Don't hurt Me.

Feel shield. Right. Shield, right.

Good. I love it. Shield, right?

Yeah. That language needs to be changed. Shield.

Shield, right. Okay. Yeah.

So we're do that. Okay. So I'm gonna call a stop on today's show.

If you enjoyed this conversation, stay tuned for part two coming in about two weeks. Shield Wright DevSecOps, truth or Fiction. Um, Andy, Tracy, Shannon, beyond my expect, I knew putting the three of you together was gonna be dynamite and, and it, it, it really proved out to be the case.

Um, and these aren't exactly the kinds of conversations I want to have at RSA Monday May 6th for our DevSecOps event there. Mitch, I'll give you the last word and we'll wrap it up. No, I, I think it was very interesting kind of where, where we talked about, you know, we really did shift left in our conversation, uh, to use that phrase and thinking about how do you get the mindset in the beginning.

And I think that's super helpful. So, and my mind automatically went well, how do we do that for operations? So that's part two that everybody can tune into.

And I also want to add my thanks to the TRICENTIS team for sponsoring this, Alan, you know, yeah, you wouldn't, you wouldn't get great conversations with this without some really thoughtful, um, input and ideas put together with, uh, with Tricentis and our team. So thank you. Absolutely.

All right, that's gonna pull a wrap on this episode of Dev of DevSecOps. They got me on Dev on DevOps Unbound. Stay tuned for our next episode where we're going to talk more about this.

This is Alan Shimmel for Techstrong. Have a great day everyone. Bye-Bye.