AI-Powered Security Orchestration in DevOps with Brittany Greenfield

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability for some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast, and my goal is to help you create DevOps toolchain awesomeness. Hey, it's Joe. And welcome to another episode of the test skill, DevOps toolchain. And today we'll be talking with Brittany Greenfield, all about DevOps continuous security development, application security, posture management, and a bunch more. Really excited to have on the show. If you don't know, Brittany is the CEO and founder of wabi. She is also a leading force in application security, recognized as a top woman in cybersecurity by Cyber Defense Magazine and her peers in the Cybersecurity Excellence Award, as well as a 40 under 40 by Boston Business Journal. So she really knows her stuff. And I'm really excited because today she is the founder of a company, wabi, that has really pioneered what is known as application security posture management space with its continuous security platform that bridges the gap between security and development, which is really in the wheelhouse of what I think you're all interested in. So if you want to know about the future of DevOps, you don't want to miss this episode. Check it out.

Hey, if your app is slow, it could be worse than an error. It could be frustrating. And one thing I've Learned over my 25 years in industry is that frustrated users don't last long. But since slow performance isn't sudden, it's hard for standard error monitoring tools to catch. That's why I think you should check out bugsnag, an all in one observability solution that has a way to automatically watch for these issues. Real user monitoring. It detects and reports real user performance data in real time so you can quickly identify lags. Plus you can get the context of where the lags are and how to fix them. Don't rely on frustrated user feedback. Find out for yourself. Go to Bugsnag.com and try for free. No credit card required. Check it out, let me know what you think.

Hey Brittany, welcome to the Guild.

Hey Joe, thanks for having me.

Awesome to have you. I guess. Before we get into it, I'd like to maybe set the stage with defining some terms just to make sure everyone's on the same page before. What I get into is a what I think is a really great solution and a great technique. The first one is I think we were talking back and forth in email and you said you don't necessarily believe in DevSecOps, and this is a big debate. So can you tell us a little bit more? Like, what is DevOps? How's it compared to DevSecOps? And why do you think SEC should be part of DevOps or not?

Yeah, no, absolutely. So the reason I don't believe DevSecOps should exist as a term is it should just be DevOps, which should just be development, right? And if we think about where DevOps came from, it was really about breaking down silos, and DevSecOps is no different. The only difference is the job of the people that are responsible for delivering it. And what really happened was we had DevOps become, even if not fully implemented, but really the norm of development. By about 2015, however, security was just sort of left behind in it for some very functional reasons. One, security, especially application security, is difficult, right? It doesn't run the exact same way DevOps processes do. There's a lot more, I call it sort of the system of checks and balances, like building a house. When you look at DevOps, you have that quality control to say, are there four walls and a door? So I can call it a room. But security gets a little more nuanced in terms of the configurations and also the number of silos you have to break down. It's not just necessarily just one security person you're dealing with, right? Whereas DevOps or One Security team, you could also be getting as far out as legal and compliance and whatnot to be able to accept some of this risk. And so really, that term DevSecOps was born of the recognition that as development organizations, we'd moved forward to say, let's break down silos, leveraging automation and orchestration to maximize efficiency on the team. And we hadn't brought security along on the ride. So part of my mission with WABI is to make that term, DevSecOps obsolete because it should just be the norm.

So how are you doing with that? You must speak with a lot of companies, a lot of users. Are you seeing a breakthrough or is it still like a, you know, education?

It is a breakthrough for sure. Right. We've. If you get into the sort of technical market adoption thing, it's in the plateau now, which doesn't mean it's gone away. It just means Everybody recognizes that DevSecOps is the norm now. Actually, from an execution perspective, it's not as good, and that's because it's no different. Right. The transformation to DevSecOps is not going to be any easier than the transformation from DevOps other than the lessons that companies got to learn from that. And that's because we haven't leveraged automation and orchestration the same way in integrating security into the SDLC as we did in DevOps. And so now you compound that with the fact that 80% of organizations are actually true DevOps organizations versus having just sort of adopted pieces here and there. And all of these band aided approaches are falling apart very quickly. So yes, everybody knows this is the new norm for me, but most enterprises are actually still in the place where they've implemented DevSecOps, but they haven't codified it as part of their existing SDLC process. We can dive into why that is.

Yeah, absolutely. You mentioned a lot of people trip up on the execution piece. So how do you integrate then security and DevOps?

Yes, well, so that's our realm, right? That's what we call what has been termed application security posture management. And so we're so thrilled that there's our own acronym in this big Alphabet soup that security has and development has. And really what it gets at is none of the concepts should feel foreign to any development team, right? Paid in development. To make sure we get things out on time, on budget, on specific, we leverage a couple of things. We manage our tech debt and security. That's just called vulnerability management. We leverage orchestration, right, because that improves developer productivity, right? We can't all be experts in the exact thing that we need to do now, nor can we be available at all the time. So we need to know when we need to direct our attention to something. And then the third is, you know, really what I think is the norm now that we've seen come with the DevOps transformations isn't just monitoring, but observability. And the analogy I like to use here is that we've created all of this data, but it's not enough to have data, you have to have actionable information. Data is saying, hey, it's 34 degrees. Well, here I am in Colorado and that is a warm day here, beautiful spring day. If you said that to somebody in Los Angeles, they'd be pulling out the puffer jackets, right? Maybe even apocalyptic. And that's the information part because that information is going to provide the context that allows you to make educated decisions. And this is really, you know, the area we address that doesn't say, hey security, can you suddenly start acting like development? Hey, development, can you start to act like security? Let's use everything that's already available. To us to marry the processes.

All right, let's dive a little more into that then. What is Wabi then? I mean, is this AI? Like AI, we have all this data, so we'll throw some machine learning and all of a sudden we have application security, posture management. Like how does this work?

So you know, AI is an intrinsic part of it, right? Cyber's always been rife for AI applications, even before AI, you know, AI was at the tip of everybody's tongue because of all the data, right? What we want to do, and especially in cyber, there's a real scale issue. And this has been one of the challenges in DevSecOps programs if there's one application security manager for every 100 developers. So we've done some research ourselves that actually shows developers recognize that security is responsive to feedback, but they don't have those automated feedback loops. So how can you be responsive if you can't get back in real time at the same pace? Right. It's just this is one of the many areas of disconnect and this is where AI is super helpful. It's an intrinsic part of our platform. But, but what we are is a SaaS platform that orchestrates the end to end application security lifecycle as part of the software development lifecycle. So developers get to keep doing what they're doing, which is developing code and they get the security tasks that they need to fed into their process at the right time. So rather than, hey, we're going to stick you in security training once a quarter and expect you to magically remember the right security thing to do in exactly this right time, we're going to orchestrate that and sometimes do that for you or just tell you what the manual step is and then allow you to have the chance to put that feedback. And so, you know, one of the things I think every developer has become very familiar with nowadays is SAS scanning, static analysis. And that's something that many of our customers require to be completed before the pr. So Wabi, so instead of as a developer, instead of having to hit a button or call your friendly security person, Wabi, once you submit, the PR will automatically kick that off, bring those results back and prioritize them for you. And if your company says you have to fix the criticals first, kind of like bugs, we're going to block you from completing the PR or allow you to route it to somebody for an acceptance. That's one example of that, you know, and so, but there's, that goes from the design perspective, right? Some customers even have, depending on the kind of confidential information, hey, we've got to have an actual meeting before we'll even release the features we can orchestrate that to. Also the thing I think we don't talk about so often, we talk about the differences between security and development, but not the similarities. Both security and software are living, breathing things. So changes are happening all the time. So we can take in changes from the security side or from the application side that may change the security requirements.

All right, so how is this information fed?

Yeah, a lot of people, I think they know of like a security scan. You check in code, you do a security scan, that's the first stage of your pipeline. Didn't pass, doesn't get checked in. This sounds more like an end to end kind of shift left shift, right. How does it feed the information? How do people get the information at the right stage and not being necessarily security experts when they do get like, hey, this is an issue, like how do they even know how to fix it? I don't know if that, that's a lot of questions wrapped in one, but.

No, no, no, no, but you hit the nail on the head. This is why this has been so complex and what's made Wabi really a pioneer in it. So let me take a step back because I used a phrase that most people may not be familiar with. We're all familiar with sdlc, right? The software development life cycle. Application security is no different. There's an application security life cycle, different things. It's not just the testing. This is where I would say the fallacy of DevSecOps was that, hey, you've got a DevOps tool, I've got a tool to secure it. And now we're doing DevSecOps, right? All that did was create more data without information. The application security lifecycle really looks at it at the development of the product and says, what is the thing that has to be done at the right time? And it's not just testing. A lot of times, you know, I'm sure folks on in your audience are familiar with the term secure coding. There's no test for that. Right. We just need to say, hey, you're dealing with PII, so you need to put a 15 minute timeout on. That's just a best practice. Or you know, there could be gates that are put in that in the singular of a policy not being followed it would be fine. But maybe you have 20 policies that weren't followed across an entire team or product and that's when security would want to stop it. And so you know, when we talk about the application security lifecycle, I'll use a simple analogy. Something that we all share is that we go into buildings every day, right? And we trust that we go into those buildings every day and they're safe because the right set of checks and balances has been applied. And. And when something needs to get fixed, it also gets put onto a punch list. Should start feeling very devopsy, right? This is the world of application security. And so that's when we talk about that end to end. And what Wabi does is we manage that whole set of checks and balances. And on top of it, as we know in development, nothing ever goes to plan, right? Software is imperfect. So when something doesn't go to plan, we also manage that set of chutes and ladders, so to speak, of where it needs to get routed. So organizations just like the way we make educated decisions about what's good enough to ship today from a quality perspective and from a feature perspective can also do that from a security perspective. So that's when we talk about that application lifecycle, it marries exactly to the sdlc. It's just a different set of rules.

Gotcha. So is it like a compliance application then, where companies, each company may have different standards that they want to follow and you would merge, they would put it into the application that would manage then compliance as well?

Correct. You've hit on a couple, three very important points. So I'm going to pick on the word compliance, okay? Because compliance is a dirty word. If you're only doing security to do compliance, then you're just doing check the box security. Right? But you redeemed yourself in the next statement.

Which was every company has their different set of standards, right? And those standards are obviously sometimes driven by regulatory standards or frameworks that they choose to. But the way a company chooses to implement that standard is different, right? Those standards say something like use a firewall and check it on a regular basis. And you know, just like humans, your risk profile and my risk profile are different, regular is different. And so that's gets to that nuance and sort of the third point on that is that each company, especially in large enterprises, treat also their applications with different risk, right. If I'm a bank, you know, to the end user, an end user sees bill pay and wire transfers as the same thing. I'm sending money to somebody, the bank sees that very differently, even if nothing else, because the wire transfer platform is separately regulated. But you know, also wires are instantaneous, bill pay is batched. So as you Start to think about the world of risk that you're willing to accept on that you're going to implement those standards differently. And that's why this gets very nuanced very, very quickly as we think about the ways that are, you know, a lot of times security is thinking about how the outside world's trying to get it right and what our risk profile is on the outside world. And development really aligns with the business customer promise delivery risk. So how do you marry those two? So that's why I say compliance is a dirty word, because you're not thinking about business risk and customer risk if you only think about compliance.

Right, right. So I used to work for a healthcare company and they would sell radiology machines to different regions, different countries and they all have their different regulations and you know, we could be audited by the fda. So it sounds like having a tool like this is. Would help automate that process rather than having like a checklist that could kind of correct. Evolve with you as well as regulations change also.

Exactly right. The world that we're living in is very dynamic, so changes are going to happen. And you know, that checklist, this is, you know, you asked earlier about the reality of DevSecOps having been adopted. This is how people are doing application security by checklist now. And you want to know what happens. Security calls development and they go, hey, did you do that thing I asked you to do, which was probably a month ago? Yeah, of course I did. Right. We worked with one large telco, said, look, we accept the fact that nine out of ten times we give development the pass because we haven't been able to effectively communicate to them the standards in real time. So that's on us, not on them. To not have informed them. And then we can't follow up. Right. We can't collaborate. And again, this should all feel very familiar. This was the same challenge Dev and Ops had at the very beginning that was creating a drag on actually delivering the product.

Love it. Yeah. I know a lot of developers have a large definition of done, like security. Just checkbox. Yeah, sure. But this sounds like it's a little more, you know, it could catch a lot of things that you may not even thought of, but when you were checking in the code.

Exactly. And I think there was, you know, there's been such an emphasis, you know, we talked about the scale issue on trying to shift a lot of security to development, which, you know, best of intention. You know, there's a big company out there that has done this. Best of intention. But it just creates a mess in a different place because we're not expecting developers to suddenly become security experts. Right. The same way wouldn't expect security experts to become experts in development. And I think that's where, you know, we're well past that cultural transformation part and that's really where our world of application security lives in the process transformation part. And then we support with the tools.

Right. So the role of developer really has a lot of pressure on, like you said, a lot. Some companies said you do everything, you do the testing, you do the security, you do the performance, the whole shebang. So do you see security experts still being involved then in the process? Like, like with your application, do they work with the application, they work with the teams for training or like do they do the heavy weightlifting?

No, it's less training. They get to become strategic and become really more part of the team. Right. We've got a problem, how do we solve it? So there's two ways that security teams get to better interface with development teams with aspm. One is rather than having to wait for your friendly security person to respond to your email or your Slack or whatever, you know, the developer is actually getting that information in real time. So that's one. So for the security teams, you're actually seeing a huge reduction in the manual work effort. So one of our customers saw their manual work flip from, Pardon me, their AppSec teams workload flip from being about 75% manual and 25% automated to being 25% manual and 75% automated with our platform. And the reason the manual work wasn't going away and they were perfectly fine with it is because that manual work then became strategic. Are we delivering the best policies to our developers that actually align with how they develop? Right. I use the example of a policy might be something like you're dealing with PII, so you need a 15 minute timeout. Well, maybe it's a bulk import and a 15 minute timeout wouldn't work on it. Right. So let's triage this together and figure out how to come up with a better policy. Or we have come up with a blocker, Right. And how are we going to work around it? One of our customers uses a library from a well known software publisher and that customer said, hey, you have a vulnerability, we need you to fix it. And the software publisher said, it's not a vulnerability to us, it's not high risk to us. And so they then. So the development and the security teams that our customer then were able to get together and say, how Are we going to manage this? What are the guardrails? We're going to put in and to do that and that's again, you know, sort of where we step in. We're the guardrails. They've got. The security team's got to do the strategy side. Wabi does the guardrails through the orchestration and the automation and then development gets the information fed to them and if needed they can make the link back to security to be able to work on it together.

All right, so what's the current situation with Wabi? If I'm a security expert, does it mean like they have to manually look through their policies? They're mainly doing code reviews, they're finding an issue, they're running it over to the dev team. Hey, can you fix it? They fix it, they fix it, they check in, they go back, they review it. Is that the manual type of workflow that this replace Correct.

Right. Like, and that's if they can get there in time. I mean. Right, right. Much more tactically. Right. You get, and these are in well educated DevSecOps teams. Right. One of our customers develops essentially DevOps software and they said hey, my teams are actually very aware of this and I get 10 emails a day saying is this the test I need to run now or do you need me to fix this vulnerability? Right, that's, you know, that's a bunch of time that he may or may not have and that's exactly what's happening today. I could pull up a 12 sheet workbook that one of our customers uses or used. That was the security code review checklist. Before they could do it and want to know what it did, it referenced a bunch of thick PDFs that nobody knew what it was and what does it mean for me in this moment? And that's where we're really try and we do take the need for expertise out and we spoon feed the information the right place, right time, right person. And so that way as things change, you don't have to be. Not that we won't all still always need security training, but you don't have to be reeducated in what the new policy is. But yes, what you described is exactly how application security happens today without Wapi.

So this might have been a bad implementation, but when I used to work with and we had security scans there'd be like a lot of false positives and then there's so many, so much information, so many things that people didn't know like what to focus in on what was real what wasn't and they would just ignore it at some point. So this solves this as well, I would think, right? Like how does it solve this issue?

And that's a key. You know, I mentioned it earlier. If we think about application security, posture management, it really deals with three realms and that's the realm of vulnerability management, which is really, if you just think about it, a specialized kind of debt. You're starting to see the new buzzy term risk based vulnerability management. And again, that's just criticality plus severity. What do I need to fix and in what order do I need to fix it? And that we absolutely do. But you've got to have it as part of the whole puzzle, right? Because if you're just doing vulnerability management, like if you're just grooming a backlog in a closet by yourself, right? What doesn't matter? And that's, you know, that vulnerability management, the big thing that people have accepted, which was tough and is tough in a lot, most organizations that are still doing exactly what you described, that will feel very normal to a lot of people in your audience. You know, they were getting all this data thrown out at them. And first of all, it wasn't aggregated it across tools and time. And the second thing, it wasn't contextualized for that company or for that application. And so you need one record, right? And this is how WABI approaches it. We have one record, we can roll it up and even see the vulnerabilities in different assets because you may even have a shared asset between a low value application and a high value application and that would change the rules that you'd want to apply. And then across time, and then we reprioritize it to say, hey, we actually care a lot about this vulnerability and that needs to go in the 5% that we're going to fix this month. And then there's 10% to maybe even 15% that we can fix later. So what are the SLAs around that? And then what about that 80% that we just need to sit and monitor so that it doesn't become something bad? And maybe there's a different future rule, but that actually never needs to end up back in the developer's backlog because we're fine accepting that risk because we can't fix everything.

Love it. All right, so here's a long question. I don't even know if it's going to make sense, but let me try to unravel it. I run a new show on Automation and DevOps and I've been seeing a lot of news recently around the security, like with the White House. I think they unveiled a fiscal plan recently and it was like $13 billion of injection to the federal cybersecurity budget. And they also released something called Back to the Building Blocks report where they said the burden of cybersecurity should fall on the shoulders of tech companies and the federal government rather than individual users. And on top of this you mentioned that Gartner mentioned ASPM as a transformative technology coming into play. So is this a convergence of like, is this where we're all heading? Is this why people should really pay attention now? Like every time I see the government releasing any reports, even though they say they're not going to have a feeling they'll stop poking their fingers into it and that's going to cause companies really take notice.

This one I have not minded too much. So I'm going to split up that question a little bit.

Okay.

You know, first one of the problems of application security is that it's always been a little bit of a Reddit headed stepchild, right? It looked too developy to be to be security. Right. Because it's proactive. It's about the process. And in development we set a process because that's how we get things out and make decisions about it and then look too security ish to be development. And so it's sort of been out on its own. But the harsh reality that nobody ever talked about and why I'm glad it's getting so much spotlight now, even if it does mean one more government report, you know, is that 9 out of 10 breaches begin due to defects in code. You rarely, rarely hear about it in the news reporting because it'll be something like ransomware. The hackers, you know, did this kind of infiltration, mitm, whatever it is. And but what it was was that defect in the code, that vulnerability that wasn't fixed or wasn't found provided the entryway for them to be able to execute on their attack. And so now application security as the building blocks. I actually thought they did a phenomenal job with this report as the building block of security is where we're starting to see this convergence that I say application security is all security, right? Because if you need a taller wall and a deeper mode and this is a little bit where they get into the burden falls on the tech companies. Because remember, every company is a tech company today, even the government in its very wayward ways. And. But if you want a taller wall and a deeper mode, right. AKA Firewalls and, you know, and better network security and API security and AI security and stuff. You've got to work with the development team to execute that. Right. There's very little security nowadays that exists without collaborating with development. And that's really why you're seeing application security, posture management become this transformative, you know, hot button in technology that people want because you can't bring together all those pieces. And you know, I go back to sort of our starting conversation about DevOps. At the end of the day, all of this is just good development because it's about good collaboration and breaking down silos.

Love it. And you know, with the speed of development nowadays, this is almost like automating the gap between developer and security.

Almost sounds like correct. Exactly. Right. We're not expecting, nor should we developers to suddenly start doing different things, right? They've got good workflows, those will evolve as development evolves. Same with security. They've got their own workflows, right. Developers crave autonomy and information so that they can execute on that autonomy. And security professionals crave accountability. Did you do the thing that we're supposed to do to make us safe? And so we, you know, this has always been our philosophy and our pillar here around, you know, how you actually integrate security into development is let everybody do their own thing, right? Then the way that they want to do it and find a way to translate the two into each other. And that's, that's really the future of how we address this problem.

Nice. So if someone's listening, Wabi, like I have to check this out. How hard is it to integrate it into existing systems? A lot of times I think I used to work for healthcare insurance companies, older companies, they kind of have legacy things like how hard is it to implement?

Yeah, it's interesting you bring up the legacy things, right? Everybody goes, don't worry, we're 100% cloud. We know we make that cloud. You're like, I guarantee you have a server sitting in a closet somewhere.

Absolutely, yes.

And it's something that we actually said, if we're going to make this work, right, we have to make it very easy. So obviously, you know, we're API centric, but one of the things we did because we realized very, our customers being very large, Mid Market, Fortune 500 some in DOD, you know, they have that complexity that says, hey, I've got this system, you know, don't worry, we're going to sunset it one day.

Right.

We actually developed an agent that allows if somebody needs to connect to an on Prem system. Right. Sometimes it has to do with sensitivity of data and other things. And so for us, right. The analogy I like to use about WABI and how we work is we rely on those connections, but what you want to connect to is going to change over time. And it's kind of like if you remember pictures of the old telephone operators when I'd call and say, hey, I want to be connected to Pennsylvania 3, 4, 5. And they go, okay, sure, hold on a second. That's how we were built to be able to say, hey, look, I'm actually at a different phase in my development transformation and now I'm using serverless. I want to connect to a serverless security program. Can I do that? Great, right? We can build an integration for it, if we don't already have it. And now you have that serverless. Or the other side could be, hey, we're going to serverless and we just need attestation, right? We just want to know, right? Because we're still experimenting on cool. Wabi can do that. And it's the recognition that everybody is a special snowflake and your program is going to be different and we've got to be flexible to roll with that.

Okay, Brittany, before we go, is there one piece of actual advice you can give to someone to help them with their DevOps security efforts? And what's the best way to find contact you and learn more about wabi?

Yeah, the actionable insight. I would say pick up a phone and call an application security manager. I really mean this, and I don't mean to sound all kumbaya, but if you're a developer or in a development organization, ask them what they are trying to achieve with their application security program. No different than what we discussed here where you said I think of application security and I think of testing. It's such a much bigger puzzle. And ask what you can do to help that. That's the one actionable piece of information I think I can give that's going to move the ball forward a lot faster because right now both teams are getting inundated with too much data and they don't have the context to turn that into information. And when, if you can start with that conversation, you're going to find that the ball starts rolling pretty quickly and you can figure out how to facilitate those feedback loops. And when you're ready to facilitate those feedback loops, Wabi's here, you know, with our full continuous security platform that can manage the end to end implementation of your security into your software development lifecycle. You can visit us at our website www.wabisoft.com. that's two Bs. Or feel free to reach out to me on LinkedIn. You know I love having this conversation with anybody wherever you are in your DevSecOps journey. So just reach out and mention that you heard me on Joe's podcast and you want to have a conversation. I'd love to continue it.

Remember, latency is the silent killer of your app. Don't rely on frustrated user feedback. You can know exactly what's happening and how to fix it with Bugsnag from SmartBear. See it for yourself. Go to Bugsnag.com and try for free. No credit card required. Check it out, let me know what you think.

And for links of everything of value we covered in this DevOps toolchain show, head on over to testguild.com forward/p142 and while you're there, make sure to click on the Smart Bear link and learn all about SmartBear's awesome solutions to give you the visibility you need to deliver great software. That's smartbear.com so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed, creating end to end full stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the Guild community, I'd love to hear from you. Head on over to test guild.info and let's make it happen.