Why does AppSec feel like it’s being left behind in cybersecurity? We have a lot of tooling, but it remains labor-intensive and unable to give us rich context. Are we waiting on the right tools or just the incentives to improve the process?
Check out this post for the discussion that is the basis of our conversation on this week’s episode co-hosted by me, David Spark (@dspark), the producer of CISO Series, and Steve Zalewski. Joining us is our sponsored guest Eric Gold, chief evangelist, Backslash.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our sponsor, Backslash
Full Transcript
[David Spark] Fans of the CISO Series, guess what? We’re going to be at BSidesSF and RSA next week in San Francisco and we want to see you. Two great opportunities to do just that. On Sunday, April 27th, 2025, we’re doing a live audience recording of the CISO Series podcast at BSidesSF. And on the next night, April 28th, 2025, that’s a Monday, we’re going to be having a party co-hosted with Vanta at Lucky Strike.
All the information, you can find it if you go to the events page on CISOseries.com. We look forward to seeing you there.
Intro
0:38.632
[David Spark] Why does AppSec feel like it’s being left behind in cybersecurity? We have a lot of tooling, but it remains labor-intensive and unable to give us rich context. Are we waiting on the right tools or just the incentives to improve the process?
[Voiceover] You’re listening to Defense in Depth.
[David Spark] Welcome to Defense in Depth. My name is David Spark, I’m the producer of the CISO Series and, oh, my co-host, it’s Steve Zalewski. Steve, say hello to the nice audience.
[Steve Zalewski] Hello, audience.
[David Spark] I like that introduction. By the way, I’ve noticed the co-hosts are coming up with new ways to sort of greet themselves. And you have your “Hello, audience” greeting that I like a lot. By the way, we’re available at CISOseries.com. If you have not been there at least, I recommend three to four times a day to stay healthy, going to CISOseries.com.
Yes. Go there to stay healthy and check out all our other programming. Our sponsor for today’s episode is Backslash. They’re the ones who make the Backslash App Graph. It’s AppSec using a digital twin of your application. We’ll actually learn a little bit about that later in the show because also Backslash has brought our guest today, who I’ll introduce in just a moment.
But first, let’s talk about our topic, Steve. Steve, you pointed out, this was a post on LinkedIn, that there are a lot of tools out there for AppSec. There’s like not a shortage of them. So, static analysis tools have been around for decades, and we’re seeing SBOMs becoming common as we shift left.
So, why does it feel like there’s so much frustration still around AppSec? What holes are these tools missing? Because we have not solved the application security issue, have we?
[Steve Zalewski] No, and it’s coming up more and more often, and in more and more flavors, but what I think is happening is that the app dev process has changed dramatically. And so, we’re solving an old problem. We haven’t moved to where the problem has evolved to with app dev.
[David Spark] That is an extremely good point. Essentially the classic Wayne Gretzky line, “Go where the puck is going to be, not where it is now.” And many of them are staying where the puck is now.
[Steve Zalewski] Yep.
[David Spark] Always nice to quote Wayne Gretzky, and I think that might be the first time we’ve done it on any CISO Series show. Let’s bring in our guest. This is actually a person I’ve known for a long time personally, and it’s just so great that we’re getting involved professionally too, as well.
He’s our sponsored guest, actually, from Backslash, the chief evangelist over there. Great guy, Eric Gold. Eric, thank you so much for joining us.
[Eric Gold] It is great to be here, Dave. I’m looking forward to it.
What’s the motivation to fix this problem?
3:29.367
[David Spark] Yaron Levi of Dolby Laboratory said, “AppSec is first and foremost cultural and an incentives problem, hence why it is difficult to solve. Most AppSec tools provide data about how broken the process is without offering any real value on how to address it. If the software engineering staff have responsibility for the quality of their code, they should be responsible for the security of the code, at least at the basic level.
Most of what I heard over the years from engineering teams was, ‘We don’t have time for this. We have features to deliver,’ which means there is no incentive or priority from the top.” By the way, that couldn’t be more classic, that last line from Yaron.
And Max Solonski said, “The industry keeps skinning the wrong cat and comes up with new elaborate tools to do it, the latest kind being AI scanning. You cannot winterproof your house by bringing more space heaters.” Good point. [Laughter] “Develop secure code and implement effective security development lifecycle – 95% of AppSec is good governance.” So, both of them are really leaning on it’s a process problem, and there aren’t the right incentives.
Do you think – because they said at the beginning, it hasn’t been solved – could we solve it just with that, Steve?
[Steve Zalewski] So, there’s two processes here, right? There’s the software development lifecycle process, and then there’s the security process. And what people oftentimes don’t realize is security as a process cannot stand by itself. It has to be laid on top of a solid engineering process. Otherwise, it’s garbage in, garbage out.
[David Spark] That is a very good point. So, they have to essentially understand, know, and realize how we can be part of the engineering process, not pulling engineering to security, right?
[Steve Zalewski] Yep. And that gets back to quality of their code. Security now is not something we bolt on. If we want to bake it in, we have to realize that the OWASP Top 10 has to do with the underlying quality of the code, not the ability to secure the code. And I would say that’s what they’re really teasing out here is, how do we put a software factory together where security is part of the factory, not an add-on, okay?
It’s not paint sealant. It’s actually considered a core component of the quality of the function of the code.
[David Spark] Eric, you’re nodding your head on this one. What would you add?
[Eric Gold] [Laughter] It’s a sad truth that developers are judged on their output and quality. Security is probably a distant third after that. When you look at the tools that are available to the developers and to the security practitioners that they work in concert with, they’ve really been gypped by the tools because there hasn’t been much innovation for the past 30 years in code analysis tools.
They all evolved from the virus scanners of the late ’80s and early ’90s that just look at code line by line, and that just creates a lot of noise because, yeah, you can discover a lot of line-by-line vulnerabilities. But then when you look at the actual execution paths in applications, not all of those vulnerabilities really have a path to actually do anything for you, and it’s the tools that have straitjacketed everyone and that have added to the frustration.
[Steve Zalewski] So, let me play on that a little bit, and we’ll be quick, which was there’s another consideration here, which is the way we do app dev. It used to be we wrote the code, right? So, we’re going to write a thousand lines of code. We know what it is, and it solves some functionality. Well, with open source and AI, more and more we’re including code somewhere else.
So, that thousand lines of code is ballooning to 10,000 lines of which only a thousand is executable. So, we have 9,000 lines of latent problem. And that’s another thing that we’re having to acknowledge here with the change in how we do app dev to have this conversation around what the security tools need to do.
Would this work?
8:02.769
[David Spark] Adam Shostak of Shostak + Associates said, “We’re going to see a shift in the ratio of vulnerabilities to design flaws as languages get better. When that happens, the importance of threat modeling will grow. How do you avoid design flaws in your code? Security will become another quality that devs are responsible for, and they’ll be experts, like we have performance and reliability experts.” David Alkema of Optiv said, “Especially in the citizen developer case, people are writing code or creating no-code automations to solve a problem.
It’s on us to create and enable developers on secure-by-default languages and environments. Identifying exploitability will always be key. Just like traditional VM programs have moved to more nuanced analysis, our application security tools need that as well.”
And lastly, Ross Young of Team8 said, “I would love to see us patching the programming languages to make it impossible to write code with OWASP Top 10 vulnerabilities. For example, what if prepared statements was the default in every software language?” Steve, you’re nodding your head. I’m going to you again on this one.
I like Ross’s comment, like prevent people from making an obvious mistake. This should be under the definition of a guardrail, shouldn’t it?
[Steve Zalewski] And this gets back to how we do development, right? We are not developing today the way we were 10 years ago, including the citizen developer, because we’re getting away from compiled, and we’re using interpreted languages. And so, therefore, I think we actually… I’m hopeful that we can do a better job of having the code itself, right, be self-protective to do things like prevent the OWASP Top 10 or to take a look and do some of that analysis embedded into the interpreters themselves.
So, I think this is, again, one of those areas where 10 years ago it was a good idea. Now, I think we’ve actually reached an interesting kind of inflection point that we could do something about this.
[David Spark] Eric, this seems like this problem is so compounded given just we have so many more developers and many that don’t have any training. Yes?
[Eric Gold] Yes, absolutely. Absolutely. It’s quite unreasonable to expect that developers are going to be able to keep up with the new types of vulnerabilities. I don’t agree that there’s going to be a shift of the ratio of vulnerabilities to design flaws. I think we’re just going to see different types of vulnerabilities occur.
So, you’re going to see fewer of the type of vulnerabilities that we see today, but there’s going to be a new breed of vulnerabilities that we’ve yet to discover. And yeah, you could use threat modeling to understand those new type of vulnerabilities. But the core problem is that developers are not security experts, and they won’t be security experts.
There’s got to be a new way of filtering out the noise and identifying what the true vulnerabilities are in your application.
We think at Backslash that that is going to be to focus on the actual exploitability, which we call triggerability. It is the combination of can this code be reached in the application? Is there a path to that vulnerable package? And second of all, if it can be reached, is there a way to actually detonate the vulnerability?
Can it be exploited? The combination of reachability and exploitability is what defines triggerability. And if we focus on the triggerable vulnerabilities, that’s what’s going to decrease the signal-to-noise ratio, and even as the nature of vulnerabilities change, it’s going to help developers to become more part of the team to eliminate vulnerabilities from applications.
Sponsor – Backslash
12:12.706
[David Spark] Who’s our sponsor this week? Well, our sponsor is Backslash and let me tell you a little bit about them. In fact, actually, Eric was just explaining the whole capability of exploitability and triggerability and let me start with a question. Are you unhappy with your AppSec tools and processes?
Is your team fatigued from endless false positives, finding it hard to convey the urgency and relevance of findings to developers, creating unnecessary friction and frustration? Nobody likes this. So, if you answered yes to any of these questions, you’re not alone.
Application security is in a rut because while the world of software development has progressed by leaps and bounds, facing even more disruption with the use of AI-assisted coding, AppSec tools are having a hard time catching up, and piling on more features onto existing tools will just lead to more of the same frustration I was talking about at the beginning.
So, Backslash is here to change that. With a completely fresh approach, Backslash models your application, creating a digital twin of your code. Using an AI-enabled App Graph, it then uses this model to traverse the code, finding vulnerabilities that are both reachable and triggerable, just what Eric was talking about.
Categorizing findings into human, understandable business processes and allowing developers to simulate the security impact of updates.
Organizations looking to modernize their AppSec use Backslash to dramatically improve their efficiency and eliminate the frustration caused by legacy SAST and SCA tools. To learn more, you’ve got to go to their website, and their web address is this. It’s backslash.security. So, it’s actually the word backslash, backslash.security.
If you actually type in a backslash, you know that character on your keyboard, and put a .security, I don’t know what the heck you’re going to get, but it’s not going to be good.
Does anyone understand what’s going on?
14:08.520
[David Spark] Diogo Rispoli of OpenText said, “There is an unspoken belief that AppSec can be solved with a risk-only approach and compensating controls. Security does not speak and does not want to speak the development language. When a tool adoption is the first step on your AppSec program, you are lacking a plan.
And when your main plan is to delegate AppSec to your dev team, you still have no plan. Application security is about building maturity. Tools are part of the problem, but I see people blaming the tools for lacking fundamentals all the time.” So, this was going to actually what you were saying also, Eric, of like people’s frustration with tools and thinking – and this goes back to a greater discussion we have about security – that a tool will solve all your problems.
They don’t solve all your problems. So, where can we start building a plan and understanding how to get to the root of the problem? Because the bottom line is, it’s not to create secure code. It’s to not be exploited, isn’t it?
[Eric Gold] Yeah. The tough thing is that people are looking for quick and easy solutions instead of the right solutions, but there’s no magic bullet. At Backslash, we’ve taken a holistic approach. We realize that the risk of an individual vulnerability is actually their use in a real attack path. You have to understand though, the interconnectedness of the code in an application, as well as the business processes that that code is participating in, in order to really understand the risk associated with an attack path.
What is more important? If you find a critical vulnerability that’s orphaned and can never be reached in the code, or if you find a critical vulnerability that is both reachable and triggerable? In other words, it can actually be exploited or detonated or activated in some way, and it’s sitting on an attack path to treasure.
We have to work on fixing what matters and not working to fix the things that don’t matter.
[David Spark] Well, by the way, you’re not going to get any argument from anybody here on that because they know the classic line of you don’t need to fix all the vulnerabilities, just the ones that matter. Steve, let me go to you, and I’m going to throw this out and to see if this would be a right path to go, and just tell me how you react to this.
We do not need to write secure code. How do you feel about that? In that what we need to do is understand how our applications are going to get attacked and fix that. I know it’s a bold statement to make, just want to see how that lands.
[Steve Zalewski] Aspirationally, it’s going to remove the friction, right, that security has instituted into app dev. We have to do something about the fact that this is an underlying friction and the friction is too high to the degree that what we’re talking about here is to be able to put a first line of defense, to be able to leverage technology and AI and process to build secure code to the degree that we can, right, or at least resilient code.
And then be the last line of defense, to find the triggerability, and to be able to look at the exploitability that will occur potentially at the point of creation or at the point of deployment, okay, in leveraging AI. Then what we’re going to see here is the human writing the code and being augmented by AI and tools to try to clean it up versus AI now looking over the human shoulder and looking at this and then notifying the human when it finds something that it can’t clean up itself.
So, that front-end process of app dev, you’re seeing the process of app security now reducing the friction in the process itself.
[David Spark] And let me just throw this out, is that this whole philosophy of shift left, which you explain it to anybody, it makes logical sense. I am not against the logic of that. And also, the idea of writing secure code, it makes logical sense. But how much can a developer know what a hacker’s going to do in the future?
They don’t, do they, Eric?
[Eric Gold] No, and other industries have figured this out, that it is not the individual components alone that need to be tested. You have to test the component’s interconnectedness in a system. Every other high-tech industry does this. They focus on systems. And it’s almost like we need to change the noun that we’re using to describe these risks.
Instead of calling them vulnerabilities, we need something more specific than vulnerabilities because vulnerabilities can be completely benign. If they’re unreachable, then nothing can happen with them. That is why we’ve come up with the term triggerability. I actually suggested to the company that we call triggerable vulnerabilities, triggles, like the tribbles from Star Trek.
Yeah.
[David Spark] [Laughter] You didn’t win them on that?
[Eric Gold] I’m still fighting that battle. Maybe I’ll win it now that it’s recorded in this podcast. But to call everything a vulnerability, it’s like the sky is falling. Not all vulnerabilities matter. It’s the triggles that matter, the triggerable vulnerabilities.
[David Spark] The triggles. All right, we’re going with the triggles.
[Steve Zalewski] I see a t-shirt in our future here.
[Eric Gold] [Laughter]
What would a successful engagement look like?
20:11.502
[David Spark] Ross Hendrickson of Inspectiv said, “I am happy with the increased attention AppSec is getting with the advent of AI. I am less happy with the amount of noise it is now generating from said AI. What still frustrates me is how everything in AppSec seems focused on just showing me all the possible broken windows and does not let me know where I am truly vulnerable, much less what I can do today to make it better.
How we are managing this today is the way we always do. People, process, and technology, we collaborate with our security teams, teach, educate, and prioritize the best we can. I just think it can be better.” Eric, I think you’re kind of down on this. Yes? You like this?
[Eric Gold] Well, I actually think that this hits the nail on the head. We find ourselves in a constant battle because on the one hand, of course, we want to focus on what really matters. But on the other hand, there’s an entrenched checking the boxes approach that expects tools to find everything. People are very, very annoyed with false positives, but they are absolutely hysterical with false negatives.
The trend in AppSec in the last couple of years is definitely moving towards a contextual risk-based approach. The issue I have with what most vendors are doing is they are not fundamentally changing their approach. They are just piling more layers on top of it, like ASPM. To make the most out of that crappy pile of old tools they have, let’s put an ASPM on top of it.
In my opinion, and in the opinion of Backslash, this is very short-sighted, and it’s not really going to solve the root cause of the problem, which is the antiquated approach that comes from virus scanning that I described earlier.
[David Spark] Steve, I throw this to you. Is there just like an overall new philosophy we have to have on application security? And if so, I want you to close the show and give us this grand new philosophy, Steve Zaleski’s new way of attacking application security. By the way, I’m setting you up, Steve.
Make it sound good.
[Steve Zalewski] So, this is what we call maverick thinking, okay? Steve’s maverick thinking.
[David Spark] I know. Everyone tune in. By the way, you should just go to our website, type in “maverick thinking,” and this is where Steve’s grand ideas of how to solve all the problems in security land. So, here we go, Steve. Let’s hear it.
[Steve Zalewski] [Laughter] Okay. So, Steve’s vision here is we are on a path to fundamentally change the way we think, right? And it’s the first line of defense to prevent vulnerabilities has been our primary method, and we’re going to continue to do that. But we now have to have a last line of defense because many of the things that go wrong can’t be seen at the time that the code is developed because they’re unknown risks, which means the last line of defense is how do we understand exploitability, okay?
And I still say that’s still kind of old school. Where we’re moving to is understanding business material exploitability, which was how does it impact my business? And if it doesn’t, okay, then I can basically put it on the side. So, I’m finding a way now to apply more filters that are associated with the business risk, not the cybersecurity risk, and that is where we’re moving to.
That is where innovation of people, process, and technology is moving us to, but that means governance, risk, and compliance. We still have to provide evidence of compliance, but what we’re really understanding now is what is our risk profile for the company, and how much risk can we accept relative to an existential threat?
That’s what we’re doing.
[David Spark] I like it. All right.
Closing
24:31.980
[David Spark] We’ve come to the end of the show, and this is where I ask both the guests, which quote was their favorite and why? Eric, you showed a lot of admiration of the last quote. It could be that one or another one, which is your favorite?
[Eric Gold] I did. In fact, it was that quote from Ross Hendrickson of Inspectiv. And what resonated with me was when he said that what still frustrates me is how everything in AppSec seems focused on just showing me all the possible broken windows and does not let me know where I am truly vulnerable, much less what I can do today to make it better.
That’s what resonated with me.
[David Spark] All right, Steve, I throw it to you. Which quote was your favorite and why?
[Steve Zalewski] So, the challenge with this whole topic, right, is that it’s not one thing. There’s so many facets to this, as we’ve discussed.
[David Spark] It’s so ludicrously complicated.
[Steve Zalewski] It is complicated, right, because of all the ways. So, I’ve looked at all this, I say, you know what I’m going to do? I’m going with David Alkema of Optiv, okay? Identifying exploitability will always be key, and I think that’s the new world. Exploitability, material exploitability, business risk exploitability is the new direction that we need to align to and that the people, process, and tooling will follow.
[David Spark] Very good. Well, I want to thank you, Steve, as always. I want to thank Eric’s company, Backslash, for sponsoring this very episode of the podcast. Remember, Backslash App Graph, the AppSec, using a digital twin of your application. You go to backslash.security. Remember, write the word backslash out.
Again, if you put in a backslash, you’re just asking for a world of hurt. It’s not going to be good for you. Eric, any last words, how people can get in touch with you, if they want to learn more about Backslash, if they want to see how this actually works, how the AppGraph works, and how you can see that triggerability and the triggles?
[Eric Gold] [Laughter] Yes.
[David Spark] How would they get in touch with you?
[Eric Gold] Well, first of all, you can read a blog post that I wrote about triggles on the backslash.security website.
[David Spark] You know what? Give me the link to it. We’ll put it on the blog post for this episode.
[Eric Gold] Okay. The best way to reach me is on LinkedIn. I’m there all the time. I think I’m an open profile, so it’s easy to send me messages, or just eric@backslash.security.
[David Spark] Remember, write it out, write that word out.
[Eric Gold] [Laughter] Yeah. And I always love to hear from people about application security issues. All of us at Backslash, we’re really passionate about this stuff. So, we love talking about application security, and we love answering questions about our products. So, please just reach out if you want to learn more.
[David Spark] Awesome. Thank you so much, Eric. And thank you very much, Steve. And thank you to our audience. We greatly, greatly – and I know I say this at the end of the show every time, but you know what? I mean it. Steve, you know I mean it. We greatly appreciate your contributions and listening to Defense in Depth.
[Voiceover] We’ve reached the end of Defense in Depth. Make sure to subscribe so you don’t miss yet another hot topic in cybersecurity. This show thrives on your contributions. Please write a review, leave a comment on LinkedIn or on our site CISOseries.com where you’ll also see plenty of ways to participate, including recording a question or a comment for the show.
If you’re interested in sponsoring the podcast, contact David Spark directly at David@CISOseries.com. Thank you for listening to Defense in Depth.