Welcome to Tectastic, where we navigate the intersection of technology and business, uncovering innovations that redefine our world. Britney, Greenfield. Welcome to it's fantastic. It is so lovely to have you here. Thanks so much, and great to be here. You're in the right now, you're in the security space, but you've been a an entrepreneur for a while, and you're in the the software supply chain security vulnerability space. Yep. Which is really a big market right now.
A lot of innovation going on. And I just wanna talk about that because I think interesting when you talk about a space as deep as this, it's also as broad as this. How many different touch points you can have in it you hit on something, I think, really important. We say application security is all security now, right? That's why it's become sort of this broad amorph space for a long time. You know, people were tagging it on as devsec ops.
Yes. We call it say that that's just the hair ball of stuff. Right? We weren't actually solving any problems with that new word. And, you know, it really just touches on every it's, if, if you need somebody to execute on a security policy, that's related to code who's doing it, the application security. And so that's why it's moved past the just scan which is so critical, right?
They all the studies show, the more often you scan and then prioritize and actually do something with those scans, and it's the less likely you are to be reached, but it's gotten so tied up in actually development practices that it's not just about breach for dot but actually project delivery and overall business risk reduction. It's funny because we have all these conversations that you're out pitching.
You always end up having conversations with the VCs and Hammer one paradigm that they view to be the dominant one or whatever. And we just got into a debate with one of them that's very deep in AppSec. And, they were saying, 10 years ago, everybody moved, like, the shift left it fully, and it then it made less the dev ops, dev to suck up thing. Yeah. And I started laughing, because it's absolutely not true. No. Right? Nobody did. Everybody said they did. Nobody did. Yeah. Nobody actually did.
And why is that, and you just said it. It's you have to engage the software engineer in the remediation of it, right? Yeah. Yeah. But that's not who's finding it. That's not who's even really understands that it's AppSec, which is usually a different division of the company. It's usually under the CIO instead of under the CTO. Yeah. So and it wasn't just engagement.
You know, one of the things that, you know, when I founded Wabi 7 years ago, I realized that it was, it was actually a translation issue. Right? Always. Yeah. Application security lives in this or all security lives in this very binary world, bad stop. Your anti virus doesn't pop up and go, oh, this is add ish. Would you like me to consider? It says, no. There's a policy. I'm gonna block this if you don't like to call somebody and maybe they'll think about it. Right?
Versus development, and this is the dirty secret that we've never talked about, the fact that software is imperfect. They development lives in this world of brave. What's good enough to get out today, and what can we do later, whether it's a fix or an improvement. And, you know, and so this wasn't just like we've gotta translate the queen's English into text in English. And I love Texas. I've got family down there for all your your audience down there.
But, you know, this was pig me into English. And we had to find a way to ask and enable each other to respect each other's cultures with out disrupting their existing workflows. And that's really what we were born out of. It's actually where our name comes from as well. I don't know if you're familiar with the Japanese concept of Wobby. Yeah. Let us accept imperfections in the things that we create as a step towards enlightenment.
And that's really the the side of application security that we deal with to say it's okay as long as you followed the process, including the process for when you didn't follow the process. Else. Yeah. So what's really interesting is we I think we're actually in alignment on on a lot of things, and it would be interesting to discuss, like, where that could go. But that's a different conversation out for the show. But love it. Because of the way that we approached it is we're not AppSec.
Honestly, we don't care. Right. What we are is software engineers live in this almost ivory tower world. Right? But they're also the quorum mission critical piece of most organizations today, and they're being asked to do a thousand things that they were never trained to do. Right? Yes. Where app security, this is where the shift left thing completely fell apart. They don't know They don't speak the language, and they don't care because that's not what they're getting the bonuses based on.
Exactly. So it's not just an incentive misalignment. What we did in that 1st generation of devsec ops when we tried to shift left and force it all onto the developers was we actually ended up overwhelming both teams Absolutely. With ton of data and no actionable information. If we could make developers security SMEs, we won't have a 3,000,000 person shortage in the cyber security industry.
And by the way, if application security folks could be developers, right, then then we we might not need secure cutting training. Right? Yeah. Yeah. And and and they're not. And the reality is, well, historically, folks that are leading up sex teams nowadays, typically were, like, developers that became security wants. And as the cyber security industry grew, they transitioned. But the reality is is most application security managers don't have any hands on keys experience.
So they don't they don't even know the experience. So but it's not fair. Let's separate out the specific jobs. It's not fair for us to ask somebody on either side of the equation do something and just expect them to know how to do it. Oh, you had training this quarter. I sent you a 5000 page manual. No. Right? That's that's a human problem. And that's really, you know, where technology and we're both looking at this technology ports people in doing their jobs better, period. Right?
And that is what we have failed to do in solving in this shift left, devsec ops, what ever. I couldn't be in more in alignment with that exact view. And, I mean, when you said something there that was really funny to me because, it comes up so frequent. Like, we want our software engineers in any organization to become domain experts too. Correct. We want them to understand exactly the business so they don't make silly mistakes. Right? Right.
Of the other things you said was we don't expect either one to really be able to do the other's job. I don't want a software engineer to have to become a policy wonk or a security operator. But you actually can fix the problem in a very interesting way. And that's actually what we do. Yeah. So what what we try to do is take the stuff off the hands of the software engineer by giving the security ops person the ability to actually write the code. They don't do it themselves. Our tool writes it.
Yes. It creates the patch for the software and submits it. That's huge. Right? Yeah. And it's the contact Right? They need to know. And I love that, right, because it's about facilitating better collaboration between the two teams at the end of the day. That's what we're trying to solve to make sure they each understand the process and where the other team is in the process. We spoon feed it to them sometimes. Sometimes we just do it for them.
And, you know, I love that that you're writing the code for them because, actually, that is where you need collaboration. I think I think security gets the short end of stick. Wait. Both sides get the short end of the stick on different arguments. Right? Security gets the short end of the stick saying they don't care about developers you're getting code out. They actually do, right?
At the end of the day, they're working for an organization, and that organization's job is to get that code out for one reason or another, whether it's an internal support system or attack what they're delivering to the customer. But when you have 100 developers for every one application security manager or position, There was no way they can be responsive, and we actually did.
Our 2022, were about to release our 23 annual continuous security results, but actually two thirds of organizations said that their security teams did reply to developer feedback. Right? So the desire is there. But again, you can't meet that scale in today's environment. The other reason I would say industry's got away for too long, saying I've shifted left or I'm doing dev set jobs is they weren't actually done with their DevOps transformation. Not even a little bit. Not even a little bit.
Today, you at least have 80 percent of organizations, do we dev ops? And we could argue that's a separate separate podcast. You know, it's a little bit of a utopian state. But what happened in the last couple of years that brought security to the forefront, why, you know, we were able to meet and and, you know, finally application security is cool kid, versus the red headed step child.
And, you know, it's because as they implemented these dev ops, programs, they realizes their band aided devsecops programs, put it hold up. And that was a lot of Excel, a lot of 1st generation vulnerability management, a lot of, you know, over the wall. Hey. Hey. Hey. Did did we pass the secure cool. We're good to go. Right? Turns out that does scale. Yeah. Even a little bit.
Like, it's funny because, my co founder, he was the CTO at Nike when I was brought in as the inter I was the the interpreter first they brought in after that. And we both had kind of different jobs. Yeah. My job was to help the company become digitally native to start moving at speed, be innovative. His job really is to derisk what I'm doing. Right? I'm there to go fast to break things and to build an organization that does that, and he's there to make sure we don't break anything.
And it's, you know, it's so important. That's the number one thing we talk about is derisking the business, right, by derisking other components. We don't talk about reduced reach risk. Right? That's inherent. Right? You do good application security, you fix your vulnerabilities. Great. The question is, how do we derisk the business overall? Well, that requires us to accept or organizations to accept I can actually probably only fix 5% of these vulnerabilities. What are the 5% that I can fix?
What are the controls I can put in for the other things I can't fit? Right? And again, this gets to that collaboration and making it simple for somebody to do their job without necessarily having to understand this very, very other different complex thing that's actually getting done. So in my former life, at one point, I've I've done this multiple times because I still like having my hands with a keyboard on a regular basis. I like to code. It's fun for me. It's why I got into it.
And I had just been brought into Nike, and I was Hammer important role that it was supposed to do with this transformation, but it meant I wanted to get in. I wanted to look at what they had and understand it. Mhmm. And we had software security scans that were giving us these big reports. And every freak and team had these, like, really long lists of vulnerabilities. Right? And I was like, well, there's gotta be a cheat code here. There's gotta something I could do.
So I started looking for commonalities. Like, is there a particular library that's got a bunch of issues for us? Is is there a particular project that's got a bunch of stuff and where can I put my time? And what I kept finding over and over again was those two things came up a lot, but there was also zombie code everywhere. Like, does this even get used? Does anybody know what this does? It's insane. And, you know, it's I'm not gonna say I've never worked for an organization.
That's had that problem, right, because that doesn't not exist. It's actually one of the the, questions that we actually get and we can manage for in our orchestration. Is, how do you make sure? So zombie code suddenly appears, right, because either it was old and somehow got reintroduced or somebody did some hackathon project and At the time, it wasn't anything we cared about. And now it's actually on, like, a mission critical asset. And so we could say, hold on one second.
We Hammer seen this checked through our process. Somebody wanna chime in here and just route out the notification. I think it really gets to this. Not at obviously, I know you deal with AI a lot. And in cyber, everybody says AI, this AI map. But I think this is one of the reasons that application security was the red headed stepchild, there's still a very human component. Right?
Like, that zombie code existed for a reason, and maybe the knowledge hasn't been transferred, but, but it's the, helping us ask the right questions about what's going on. And that's where, you know, it's it's I actually rail on the move fast and break things all the time because at at its core devops is not about moving fast and breaking things. About moving efficiently and taking the time to fix things at the right time. Yeah. And sometimes that's a conversation. 100% agree with that.
You probably can't read what's on that board, but I was trying to walk somebody through why these red headed step children exist in the space. Because, you know, if you're talking to somebody like my wife who's a non tech person, she doesn't really understand the space at all. How would she? Right? Why would she? I think someone gets also the fact that we assume our code is being secured or the way that other things secured. Right? We all have MFA and whatnot. And, like, I, I do.
Like, I'm every day, I've one stood up closer to, like, taking my money out of the bank and putting in my math It's in my Yeah. Lyrics. Yeah. The more you know about it, the the scarier it gets in some way, Like, she was trying to understand what we do. I was I was walking her through, like, what our platform does. And she goes, well, why do you need a tool to do that? Don't you guys do that? I'm like, no. Everybody outside of this world thinks that's how it works, but it's not it should be.
That's what the implication of the word engineering being tacked onto what we do right, is risk mitigation. That's every other engineering discipline is heavy on the risk mitigation side. Software engineering doesn't really do that. Not really. And it's this process back here. That's the problem. Right.
So the the thing that I talked through really quick on that is just the value of software in most organizations is really about taking the strategy and implementing that in a way that directly impacts your customer, especially if you're direct to consumer. And the problem with all the red headed step children in this space is that they're outside that process. Right? Okay. 90 degrees. Right? Yeah. I've I've said this.
I I actually just we did sort of a lunch and learn with our team and did a deep dive into the personas, and I lane profit center versus cost center. Right? And and product at the end of the day has always gotten the pass because whether it's to support the delivery of the customer's end product, right, like Starbucks with coffee, right?
They the customer still getting coffee, but the technology enables it to end up in their Hammer, or to actually deliver some software to the customer, they are the closest tangible thing to driving value for the business. Not that security doesn't drive value, but it's really hard for security. It always has been across each each segment of security, say, here's the ROI on the thing that didn't happen because I did my job very well, Hill, and so, therefore, didn't Hammer. ROI. Right?
And that's that's exactly what you're talking about. Development. And this is where, I would say, development leaders have known for a long time that this was a iceberg problem. Right? They weren't given a prac way to solve this. And therefore, they took their profit center power and said, we would like to pass. The other side is, I think security has known for a file that they weren't giving a practical way.
And, you know, there's a large infrastructure company we work with, and they said 9 out of 10 times, they were giving the pass. Because they couldn't even try to enforce it because they knew that they hadn't given the right information. They weren't tracking well. And so they had to just say, yep, we'll give you the past. We're talking critical infrastructure, and that was their security. And he said, we'll take it, we'll take it on our cell. Right.
And then that's a unhealthy cycle on its own because then those teams get into constant firefighting mode and tons of manual work and whatnot. And you hit the male on the head, the assumption that we do it this way Hammer been keeping people from doing it the right way for so long. Yeah. So my co founder will was talking about his time at a very large company. He was the CTO of also, and he said that even as the CTO, who sets policy sets the goals for the organization.
He spent months negotiating resolution of these critical vulnerabilities that were in there. And and he's like, I can tell somebody to do it, and I still couldn't get it done. Yep. Exactly. It's the, you know, I got ninety nine problems, and why is this vulnerability? 1. And, and, and security just was not delivering on that because they didn't have a way to translate them.
And it for me, I kept going back to the short term versus long term, like, the existential risk of security vulnerabilities is there. Right? If a log 4 j type issue comes up and it exposes all your client data. You are out of business. Right? But probability, and is it gonna happen while I'm the CTO? Always another Christian job. You know, but it's also that.
And, again, that's that's why I spend a lot of time with folks like yourselves, but although don't have to evangelize to you, talking about it's business risk. Right? Yes. This is not about Christian, and that's where people get scared or think that taller walls and deeper modes will do the trick. Right?
If we're talking about delivery risk and, you know, in the same study that I referenced beforehand, The number one benefit of integrating security into the software development life cycle was decreasing project delivery And it makes sense. Right? But I think we finally have gotten to that maturity, a, as long as we go, you and I keep going and and speaking the good word that applications risk is business Christian there are lots of different levers that you've pull to manage that.
And sometimes that is also not fixing the thing. It's not Britney, I'd love this conversation. I wanna give you a chance to, like, give some last advice to the audience and, like, send them to your website so they can find out more as well. Yep. So I would say that, last word of wisdom when it comes to application security is that you've gotta find a way to bridge that gap between security and development. If we can enable them to collaborate, then we can actually solve this problem.
And as technologists, we're taught people, process, and then tools. And right now, what's been missing in the industry, people on board, they get it at this point in time. What's been missing is the process. You've gotta make the process easy for people. So those are my last words, wisdom, but I'd love to share plenty more with you. So feel free to connect with me on LinkedIn or visit www.wabysoft.com to learn more and just reach out. As you could tell, I always loved talking about this.
So I'd be happy to continue the conversation with any of you. And that's a wrap for this episode of Tectastic. I wanna thank you personally for joining us, and we'll see you next time. Until then, keep exploring, and stay curious. Overwhelmed by tech debt, discover Vala AI. The solution to tech challenges with the simplicity of a click. No engineering background? No problem. Vala AI enables anyone to effortlessly tackle issues, freeing up your time from tech headaches.
Make tech debt vanish with Vala AI, where your tech solutions are just a click away.