The Security Table gathers this week to discuss expectations about tooling in the Application Security industry. Matt emphasizes that tools should essentially automate tasks that humans can perform but in a faster and more efficient manner. The conversation then shifts to the overwhelming nature of communication platforms like Slack. Izar highlights the challenges of managing attention spans and context-switching when one is part of numerous Slack channels, likening it to being in a room with a hundred simultaneous conversations.
The hosts further discuss the integration of tools and the importance of contextualization. Current tools provide too many results, lack context, and therefore fail to recommend effective solutions. They touch upon the idea of startups building their own suite of tools to ensure seamless communication between them, even if they aren't the best in their individual categories.
The episode concludes with a thought-provoking statement from Chris, who envisions a future where AppSec might become obsolete, and development could potentially absorb the security team. He teases this topic for the next episode, urging listeners and co-hosts to ponder this radical idea.
Overall, the episode provides a look into the current state of security tooling, the challenges faced by professionals, and the potential future of the AppSec landscape.
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel
Thanks for Listening!
The Security Table gathers this week to discuss expectations about tooling in the Application Security industry. Matt emphasizes that tools should essentially automate tasks that humans can perform but in a faster and more efficient manner. The conversation then shifts to the overwhelming nature of communication platforms like Slack. Izar highlights the challenges of managing attention spans and context-switching when one is part of numerous Slack channels, likening it to being in a room with a hundred simultaneous conversations.
The hosts further discuss the integration of tools and the importance of contextualization. Current tools provide too many results, lack context, and therefore fail to recommend effective solutions. They touch upon the idea of startups building their own suite of tools to ensure seamless communication between them, even if they aren't the best in their individual categories.
The episode concludes with a thought-provoking statement from Chris, who envisions a future where AppSec might become obsolete, and development could potentially absorb the security team. He teases this topic for the next episode, urging listeners and co-hosts to ponder this radical idea.
Overall, the episode provides a look into the current state of security tooling, the challenges faced by professionals, and the potential future of the AppSec landscape.
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel
Thanks for Listening!
And we're all burned out and we just want a vent.
Chris Romeo:With that, welcome to the security table, because that is the story of the week. It's that, uh, it's been a long week for all of us. And so we're going to have some fun. We're going to talk about expectations of tooling in our industry. And when I say our industry, I mean, the application security...
Matt Coles:Product security.
Chris Romeo:...machine? What's the, how do I describe this? It's, what do they call the defense industrial sector? Is there an application security industrial sector that we're talking about here? Is there a AppSec? I don't know where I'm going with this. I'm
Matt Coles:Let's go there. Let's not go there. You're already stepping in the landmine. Come on.
Chris Romeo:oh, come on. That's.
Izar Tarandach:No, seriously, are we creating problems just so that we can write tools to solve them? That's a good question.
Chris Romeo:That's a deep question right
Matt Coles:That's an interesting one.
Chris Romeo:That's like an inception kind of moment, like the tool within the tool. But let's talk about expectations of tools. So when we think about application security, there's a big collective of tools that are commercial. There's a big collective of things that are open source that you can kind of connect together to get some of the same results. Like when you think about expectations of tools, like what are, what are your expectations of tools? Like, let's, let's put together a list of things. Like, what are we, what are we expecting our tools to do for us?
Matt Coles:So, oh.
Izar Tarandach:You go.
Matt Coles:So I think in a nutshell, the way I would characterize it is I expect a tool to do something a human could do only faster and more efficiently. So tool A tool is automation an automation's job really should be a facilitator or something that humans can use to do tasks that they can do by hand, but, but really they don't have to do by hand and can, in fact, the tool can do it more consistently and reliably, um, assuming it does its job and is correctly programmed in this case. Uh, you know, it's important to think about the classes of tools that we're talking about, not just whether they're free or commercial, but you know, are we talking static code analyzers? Are we talking vulnerability scanners? Are we talking, uh, you know, network penetration testing tools? Um, a host of, a host of different types of tools do different things, and those things, again, could be done by humans, whether they do it by hand or they do it by scripts that they write. But really we're taking sort of industry knowledge, collective knowledge of the industry and the community to feed these things so that they do their job well enough to replace, free up humans to do other things. And in some cases, of course, we know that those other things can include verifying the results that come out of a tool. So it doesn't completely eliminate the human activity.
Chris Romeo:Izar, do you agree with that general definition?
Izar Tarandach:Yes. Yes.
Matt Coles:Yes, I was going to say, I win!
Chris Romeo:Finally! Izar is speechless!
Izar Tarandach:Finally somebody muted me.
Chris Romeo:It's because I muted him so that we could say he was speechless. What a joke.
Izar Tarandach:So here's the thing, like, like many, like most things in this, this industry, in this life, I, I changed my opinion over the years. Right. Once upon a time, tools for me were exactly what Matt described, but uh, over time I figured out that that expectation might be misplaced. I might be looking for a silver bullet where not only they wouldn't give it to me, but they can't give it to me, and fall into that scan and patch loop that we discussed the other week, and all that stuff, and I think that what I look for in a tool nowadays is more in terms of the auxiliary processes around what I need, rather than the core knowledge. So yeah, it's great to have tools that check configuration, that check, that check spawns and all that good stuff. But, give me a tool that improves communication between the teams, and I'm as happy as, give me a tool that reduces context switching for an application security engineer, and I'm happy. Give me a tool that lets me do remote threat modeling easier. It's good for me. So, I think that we have a lot of tools that do security, we have less tools that support security. And I'm missing that.
Chris Romeo:That's an interesting kind of angle you're taking on this in that tools, but when, in the context of where we live is, is security tools, they don't really focus on improving communication, collaboration, things like that. They focus on finding a particular result. And like I heard on another podcast in the context of Slack, and this just blew me away, right, because people talk about the use of um, Slack and enterprise messaging as a better thing than email. Take a guess, we're gonna have a little, we're gonna have a little guessing time here. How often, on average, does a software developer check Slack?
Matt Coles:Three times a day.
Chris Romeo:Okay, Izar,
Izar Tarandach:I don't know, I know people who pretty much live inside Slack.
Chris Romeo:So what's your guess? Matt's at three times a day.
Izar Tarandach:Constantly?
Chris Romeo:Every six minutes.
Matt Coles:There you go.
Chris Romeo:And these are people that are writing code, and they're in the flow state, they're, they're cranking, they're doing things, and every six minutes. And so that's a very interesting proposition that you're kind of, or I cannot, but point of the tooling that you're pointing out here is. We haven't done anything to, to focus on collaboration and communication and, and the softer side of, of security. Tools have been all about just cranking out results and stacking them up for someone to hopefully deal with someday.
Matt Coles:Well, can, can I
Izar Tarandach:wait, just to address that Slack thing.
Matt Coles:yeah, go
Izar Tarandach:I think that's horrible. That's terrible. That's ridiculous. That's bad. We shouldn't be there. We should be actively getting out of that situation, right? And we keep stacking things and things on top of Slack. It's becoming a control center of sorts. You can start full processes from Slack. You can get your notifications of those processes in Slack. And at the same time, it's eating at our attention span. It's eating at our context switching. I mean, it's not uncommon for people to be in like, I don't know, a hundred different Slack channels. Imagine being in a room, listening to a hundred people talking about different things at the same time. Right? At least you go to Black Hat and people are talking about the same thing. But imagine being in a room and you have to pay attention to 100 conversations and they are all happening in real time, in different ways, and it's information that you need for your job.
Matt Coles:So,
Chris Romeo:stat. I want to throw one more stat at you because it's in this same thing. That's going to blow your mind as well. I saw this as, and, and it's not, has nothing to do with security. It has to do with interruptions. The average 18 to 27 year old gets something like 2, 500 notifications a day on their phone. I have notifications turned off on my phone, but I'm old school. Like I don't, like my phone, I don't want to be bothered. I don't want something to go bing, bing, bing all day long, because I know I'm on that same programming that everybody else is, that if I get the bing, what's, what's happening? What happened? You know what, I need to know something that's happening. And so, um, that, that one just blew me away too. I was like, wow, that's a lot of notifications. People are texting all day long, they're, they're Snapchatting, they're Instagramming, they're doing all these other things that I probably don't even know that they're... Exist at this point. But once again, it's this, it's this constant interruption culture. I know that's not where we were going, but we're kind of, we're kind of focused on this for a minute. So Matt, what are your thoughts?
Matt Coles:So first off, I just want to, I think I misunderstood the question and Izar took us down a different path. I was avoiding the collaboration side of tooling because, well, that's a different space. I guess what you're, what you're really talking about is integrating security tools with communications platforms, right? Whether that be Jira, or Confluence or, you know, those types of tools or Slack or Teams or whatever, some sort of messaging, because there are companies that do that for a living that are much better at that. And I thought we were talking about security tools, like things that operate on products or applications. So my mistake, but I understand where you're coming from, right? And, and that's absolutely a goal, should be a goal, right? Is how you communicate that information in a way that developers and others can take advantage of it quickly and efficiently. Because tools should be about efficiency and productivity.
Izar Tarandach:But that's exactly what I'm challenging. I think that we came to rely on things like Slack and Jira way too much, just because everybody uses them. So we assume that the frictionless path is to go and work on them as well, right?
Matt Coles:Well, so, I guess trends happen because, you know, people in the industry learn these platforms, they get comfort with them, and then they collectively go, Well, hey, we're all a group and we all know how to use Slack, so let's go ahead and use Slack. As opposed to... But as soon as something new comes along, there's a progression, right? to try and adopt those new things. So if you're not using Slack, what are you using? Right? Companies may be using Teams, they may be using uh, Mastodon or something, I don't know, but, um, or other
Chris Romeo:They have get Mastodon installed at some point.
Izar Tarandach:But
Matt Coles:Well,
Izar Tarandach:the point.
Chris Romeo:Good luck with that.
Izar Tarandach:the point. You just got into a more of the same, right? And what I'm saying is, you know, take a Purple Team exercise. You could do it over Slack. That'd be awesome. Yeah, it works great, and Slack now has new features that do even better for you to share ideas and data and whatnot. But is that the best thing?
Matt Coles:well, how do you so how would you, so I guess, rather than asking what the best tool is, what characteristics of that communication are you looking for?
Izar Tarandach:Great, that's the question. So again, in a Purple Team exercise, for example. I'm on the blue team. It would be great to see the screen of the red team in parallel as I'm there as they do their stuff and I see my stuff and I can correlate both of them in real time without it passing through some sort of a filter that needs to, they need to tell me now we're doing this and I have to interpret that and figure out what it looks like in my head and go see my stuff, right? So,
Chris Romeo:taking, taking the collaboration tools out of the picture and making, cutting out the middle person, right? It's, it's going to, it's, it's providing a tool that has the communication and collaboration built into it directly.
Izar Tarandach:I think it's more about not intermediating that, that exchange, that sharing through some kind of filter that may change what's being shared. So if you go Slack and you consider just text, just text, right? I can send you a message saying, hey, here's what I'm doing right now. And you can answer, here's what I'm seeing right now. But if at the same time, I have a tool that shows me both screens at the same time and I can relate what I'm doing to what you are doing in real time, that makes my life much easier. I'm doing the interpretation. It's not two filters, two human filters. with a media that perhaps can or cannot pass all that I need in order to know what's happening.
Matt Coles:That seems very specialized, right? That's like, that's very specialized for that use case. Um, but, but maybe that, I mean, maybe that's the right way to look about this, right, is, I mean, you have to really, in order to choose a method, you have to know what your, what characteristics you have. So that makes sense. Are there other things similar to that where this would become commercially viable? Right, because that's the next thing, right, is either you're going to write it yourself or you're going to make, or somebody has to build it and
Chris Romeo:sure. You're going to squash our dreams by making something have to be commercially viable. Come on. Like,
Matt Coles:or a pet science project for somebody who can
Chris Romeo:I'm on, I'm on, I was thinking the same thing. Like as I started to, I was, I was thinking about this myself and I'm like, so wait, now we're in a world where I have separate communication channels in every tool than my security suite. So my SAST tool has a, a set of forums and conversations and my RASP and my. SCA, they all have different, they all have these. So I end up with 27 different communication things that I have to do.
Izar Tarandach:So let's go there. Let's go there. Let's say you have those 27 tools and you have Slack in the middle. You're getting 27 different channels of information. Chances are that many of those are either related or the same thing viewed by a different tool. One category of tools that I am not... aware exist broadly. I can think of one or two examples that I'm not going to mention, but that exist. One tool that would bring all these 27 channels together, figure out who's who in terms of who relates to whom, and the different sources of information and whatnot, and present me that information in terms of five different pieces of things that say, hey, from all those 27, these are actually five things that those 27 things are telling me exist. Focus on these, not on the 27. Five is a much nicer number for me than 27, especially if I have to check it every six minutes.
Chris Romeo:mean, I think we just invented a category of AppSec tools that already exists called ASOC. Application Security Orchestration and Correlation is a segment of the market that is focused on taking feeds from noisy AppSec tools, building or adding contextualization around results, and then giving you a view of that. So you don't have 10, 000 events. It's like a sim for AppSec tool results.
Izar Tarandach:I don't speak Gartner.
Matt Coles:And, well, and, and, and,
Chris Romeo:Wow, that hurts, man. That hurts.
Matt Coles:and, and, and, and, and, and, and, and, and,
Izar Tarandach:you're the CEO. You're the CEO.
Matt Coles:And then realistically, realistically, of course, you could always ask chat GPT, hey, monitor these feeds for me and, and give me the salient points.
Chris Romeo:And then ChadGPT starts hallucinating about, Oh, there's a big problem happening right now because it somehow knew about some attack from years ago. It's happening now and everybody's freaking out.
Izar Tarandach:the CEO Okay, we said ChatGPT. We have to say EPSS and threat modeling. That's it. Enough. We did it for today.
Chris Romeo:Laid over.
Matt Coles:SBOM, SBOM..
Izar Tarandach:All the jars are full now.
Chris Romeo:Whoa, whoa, Matt, watch your language here. This is a family show. Come on. Alright, so we thought we were going to revolutionize the industry, but we, we just reinvented a, apparently a Gartner category, even though there's tools that exist in it. Izar. Um, so not just a Gartner category.
Izar Tarandach:I didn't get the memo. I'm sorry.
Matt Coles:You're going to get the sales calls.
Chris Romeo:that's right. I'm going to, I'm going to sign you up for a bunch of demos and stuff from people. to get all kinds of people
Izar Tarandach:Actually, apparently that's the thing. I, I heard from people that didn't go even close to some conventions and whatnot, and all of a sudden they go like the day after the convention and started getting so much spam. So, there are people out there who are signing up other people.
Chris Romeo:There is a, uh,
Matt Coles:that's interesting social engineering attack actually.
Chris Romeo:yeah, there,
Izar Tarandach:not, it's not difficult to manufacture the QR code, right? So you just slap it on top of it.
Chris Romeo:there is, I'll go a step further. I found there is a service that will sign people up for email lists. So if you want to, if you want to cause somebody difficulty, you put their email address in and it'll go sign them up for like hundreds, if not thousands of different legitimate email lists.
Izar Tarandach:without verification.
Chris Romeo:Yeah, without,
Matt Coles:Well, it's self, it's,
Chris Romeo:verification and, and approval is a joke when it
Izar Tarandach:That's why we can't have nice things, you know.
Chris Romeo:It is, I mean, can spam is, as a, as a legislation, like, it, it has all these things that people are supposed to do and penalties if they don't. But, email is one of these things that people just abuse the heck out of without the proper approvals and things. So yes, you can just go there. I could sign up your email for 2000 email lists and none of those people are going to care. I didn't opt in.
Izar Tarandach:So I'm looking here at the homepage of DefectDojo, and it doesn't mention that category that you mentioned. And that's actually my go to when I need an example of a tool that does more or less what I would like to see other tools doing.
Chris Romeo:DefectDojo is not referring to themselves as an ASOC at this point.
Izar Tarandach:I don't think so. Which just makes them more in my book.
Matt Coles:an open, it's an open source application vulnerability management correlation and orchestration tool.
Izar Tarandach:You see, by
Chris Romeo:They
Izar Tarandach:the time I finish saying that, I already got 16 more alerts.
Chris Romeo:Let me just check Slack real quick. Hold on. It's been six seconds.
Izar Tarandach:Have six minutes already passed?
Chris Romeo:Yeah, six seconds. Every six seconds I check for new messages. I
Matt Coles:So, so, I mean, I think you're using, you use Purple Team as a, as a very concrete example here.
Izar Tarandach:Yeah, but it was an extreme example.
Matt Coles:Okay. So what's a more mundane example?
Izar Tarandach:Oh.
Chris Romeo:mean, let's use the SAST tool. Let's, let's, how would you layer enhanced communication on top of a SAST tool that isn't Slack and isn't Teams?
Matt Coles:So I would look at, I would look at GitHub as an example. So if PRs, if PRs is included SAST and you use PRs as a vehicle for shared code reviews and comments on code changes. Right. That's something that GitHub does today. Right. Is that sufficient for, you know, 90 percent of the use cases out there for when development teams need to do shared code reviews, peer reviews, um, you know, uh, security analysis? And, and why restrict it to just SAST when you can have, uh, a build framework that also runs, uh, other Other tools. I'll, I'll keep the, keep the other four letter, four letter acronym out of, out of that. Uh, right. But correlating other information together as part of a PR so, so that changes can be, can be taken into context and reviewed appropriately. Right. Use the tools to assist the humans in doing their jobs more effectively.
Izar Tarandach:I think that GitHub is a good example of something that lives in that boundary where developers and security people can meet and sort of start speaking the same language. Because the, uh, some of the artifacts created by security tools in GitHub end up giving to developers something that they can immediately work with and have to interpret less. With that comes the fact that, uh, If there is a thousand ways of doing something, there's 1,001 ways of doing something, and it's an arms race for those security tools to create PRs that speak, I don't know, Terraform, whatever the IAM or whatever happens this week.
Chris Romeo:Yeah, but in Matt's example, we're talking about native tools that are already integrated into GitHub
Izar Tarandach:Right? But the output that they
Matt Coles:I wasn't, I actually wasn't, I actually, so I actually wasn't, wasn't, I was saying tools that get integrated with GitHub, whether it's native with, or,
Chris Romeo:All
Izar Tarandach:but the output that they, they give has to work on whatever CI pipeline you have. Right. And that's where you get the multitude of, uh, of, uh, uh, options and, and perhaps not every tool speaks that specific thing that you are using in your pipeline.
Matt Coles:but I guess the important part is.
Chris Romeo:But we would agree thats a better practice though, right? To use I mean, it's certainly better than having Communication on Slack about results coming out of a scanning tool like SAST, like having an integrated onto the PR, there's no better place. You can put it to be in the developer's flow. Now I'm assuming they're using GitHub
Matt Coles:GitLab, pick your, pick your CI platform, slash,
Izar Tarandach:But, but then I think that we, we fall into the discussion between communication and action. So the PR is an action thing, right? The PR is check this thing that I'm, that I as a tool, I'm telling you you should do differently and enable it or, or, or reject it. But Slack is just, hey, I have something to tell you.
Matt Coles:But I think it's important though, with GitHub, it's a human, it's a developer generated activity. I made a change and the tool is doing all the workflow bits for, I made this change, help me review it before I commit it.
Izar Tarandach:It's again, sorry, it's the loop. So it starts the way that you said, but then you have an action that says I checked your code, and by the way, there's a mistake in there, and here's a PR that fixed that mistake.
Matt Coles:Okay. So the tool helps the human be more efficient.
Izar Tarandach:going both ways, right? And I think that where the tools are verbose and create too many of those things, then you have too many of those things at two levels. You have too many PRs to review, and you have too many alerts about those PRs. So, PR to review are going to stack up in your inbox in GitHub, is it called an inbox? I don't think so. And they're going to pile up in your Slack channel dedicated to that.
Chris Romeo:That's another,
Izar Tarandach:of the...
Chris Romeo:you've highlighted another challenge in modern tooling though, in that. The pattern that tool providers have followed so far has been: create a tool that has a policy that looks for things and then reports everything it finds. There's no, like, no, nobody has built a, a, an intelligent SAST tool. That I'm aware of. And what I mean by an intelligent SAST tool is, it doesn't just scan and dump out all of the things that are wrong with my code. It has some prioritization, some contextualization built into the SAST tool itself. And well, I'm not creating a new Gartner category here, by
Matt Coles:Uh, there, there are tools that used to do that. I don't think that they still do that, but there, there were some that tried to do that. Coverity. So Coverity tried, tried to, right? So they built a model, the model based, so rather than being, rather than doing the grep based thing, right? Uh, tools like Coverity, they tried to do model, they did a model check approach, I believe, way back when, I'm not sure if they still do. Um, but they tried to, and I know Izar, you're laughing over there because, you know, results may vary, but they at least tried, right? They tried to minimize false positives.
Chris Romeo:Yeah, but they still dumped... That doesn't... So they still dumped all the things they found. What I'm saying is nobody has said, okay, no matter how we scan for results, that's half of what my tool does. Once I get the scanned results, now prioritization, doing some contextualization.
Izar Tarandach:Oh, there are, there
Matt Coles:Oh yeah, there are.
Izar Tarandach:there are. Yeah,
Matt Coles:You can even do that with, with any of the stat SAST tools, commercial SAST tools out there. You, I mean, you could tell it only look for this type of issue
Chris Romeo:I mean, why do they return 10,000 results, though?
Matt Coles:Because they're misconfigured; because they're misconfigured.
Chris Romeo:So, but I don't think anybody's doing I don't think there's a SAST tool that is intelligently providing me a summer. They may be doing a some some type of summarization. My point is is there a SAST tool today that will give me the five things that I really should fix before next Tuesday?
Izar Tarandach:It's the top five in the list, right? They're not going to say these are more important than
Chris Romeo:it's exactly, it's top five of 500, like I want, like,
Matt Coles:but if you, if you
Chris Romeo:argument though, is nobody has layered a, a, a piece of any of these tools that does that for me, that gets me some legitimate, these are the five things I have to fix in the next month.
Izar Tarandach:Because it goes against the context, right? It's what we spoke the other week. We have to have these tools not only be more intelligent, sorry smart, but we have to give them visibility beyond the immediate line of code. We have to somehow code Where that code lives, what it does, how important it is, and then put all that into the mix and come out with something.
Matt Coles:right. So.
Izar Tarandach:Just a second. When you started describing your smart tool thing, the only thing that came to my mind was some scanner that you scan your code, it doesn't say anything. And you check the status code. And it goes back to you like, there's a problem, and you ask, what's the problem? And it goes, well, if you don't know what the problem is, I'm not telling!
Chris Romeo:Yes, we are building this, we are building this because it won't, we won't have to do anything. All we'll have to do is pretend that a scan was run and then just provide that error code which then they look in the man page and see that's the error code actually says, if you don't know what this is, you've got bigger problems.
Matt Coles:If you have to ask, you can't afford it.
Izar Tarandach:That's the IBM approach to error codes.
Matt Coles:so back. So back to your, back to your prioritization discussion. So tools today, by and large, I think commercial tools especially, but probably some of the open source tools as well. First off, have a ton of configuration options that probably nobody is using effectively. Right. So, so you could say, you know, say pick a, pick a SAST tool and say, I want to, I'll, I'll pick Center Cube'cause it's open source, right? So it's, it's free. Free and available I could say. Um, I want to, um, I wanna look at only Java vulnerabilities and I wanna only wanna look tho look for those vulnerabilities that tie to a CWE Top 25 issue. Right? And so it, in theory, will filter out all of those scan results down to that set. So that's a, that's a configurable option that gives some level of prioritization. Now I have, so now I have a set that is constrained, right? Now add to that configuration options to say, well, I really want to bubble up to the top critical findings. Now obviously it's going to decide what critical is, not you, right? Because it's not smart enough to know context. At least at that point, but that's where, that's where some of these tools that do say control flow analysis, right? Can say, well, I get data from the outside and then it comes in and causes a buffer overflow. That sounds more critical than something that only uses data internally. And if you pair that with information about the project, like this is an internet facing web application. Now you can do true prioritization and our tools that used to do this, again, I don't know if they still do. Fortify was a good example. Uh, and Tenable is another example from this, from the scanner side where, um, you would provide information about the projects to your scanning into sort of a, like a control center or security center kind of thing. I think that they called it security center, in fact, on the fortify side. Uh, and, and that would tell you about this project is this type of application and therefore, That allows you to do some sort of business prioritization for the results that come out. And so, they're not smart by any means, at least they weren't in, and this is, well, I'm talking like a decade ago. So they weren't smart in that regard, at least not by today's standards. But it's not a stretch that you couldn't get there. Well,
Izar Tarandach:Yeah.
Chris Romeo:Yeah, I mean that's, that's, I think it's just a missing piece. I think it's a missing opportunity.
Matt Coles:I think what's really missing is the correlation of other data. Right, so we're talking about SAST, and we're talking about... Scanners, the other
Chris Romeo:can say SCA, it's okay, SCA is okay.
Matt Coles:I wasn't going to say SCA, but I was going to say, I was going to use a D word that you don't want me to use.
Chris Romeo:what do you mean?
Izar Tarandach:Dread?
Chris Romeo:mean dead? The tool, the, the, the tool that I now refer to as dead, the
Izar Tarandach:I hear dread?
Chris Romeo:of tool or dread.
Matt Coles:so, uh, but correlating information across all these tools to give you a complete picture that will give you prioritization, right? Like I find you have an open port and that port ties to a piece of code and that code has a vulnerability. And now I can know that, you know, that this is more severe than one that isn't.
Izar Tarandach:yeah.
Chris Romeo:that's why we're seeing some startups now that are trying the mode of building their own SAST, SCA, the bad word. Um, and then other.
Matt Coles:SCA is good, software composition analysis.
Izar Tarandach:Well, yeah, depends which SCA we're talking about. It's horrible when we get to the point that we have to recycle acronyms.
Matt Coles:Oh my god, oh
Chris Romeo:But you,
Izar Tarandach:people, two people can be talking about SCA, have two completely different conversations, and it actually makes sense. It's terrifying.
Chris Romeo:but my, my
Matt Coles:like Stig's recently.
Chris Romeo:My point is you've got, you've got some startups that are trying to build each of the pieces of the tooling so that they can build in the contextualization to have the SAST and SCA talk to each other and, and, and enrich the results coming out of it. Now, the challenge there is. It's not best of breed. It's not, it's going to be tough to have best of breed in every category if you're building all your own. Maybe the contextualization will be enough to get you to market acceptance. Because the contextualization of three average tools in those various classes is worth more than best of breed in each of those categories that don't talk to each other. I don't know. That'll be for the market to decide.
Izar Tarandach:Now, let's, let's take that to, to its extreme. Let's say that tools start being smart that way. Are we done with security people?
Matt Coles:No.
Izar Tarandach:What's going to be missing?
Matt Coles:I think you still need, you still need a human to provide context, and you still need a human to make certain decisions that the tool can't make, should not be making automatically.
Izar Tarandach:But given all that information, won't developers be able to do those, to make those decisions?
Matt Coles:Oh, oh, sorry, yeah, I'm sorry, I wasn't,
Chris Romeo:Well, that's a good, that's a good place for us to end for today, which, you know, it's kind of a strange way to start. But, here's what I want to talk about next time. And I think this is something that I've been kicking around and I want to get both of your opinions on it. I see a future world where AppSec is no longer. I see a future world where development eats security, the security team. And I don't want to get into it. We don't have time to get into it today, but I want to put that on your both in our, our listeners minds to be thinking about, but also the two of you so you can chew on it. And then let's come back together next, uh, for the next episode. Let's deal with that issue. Cause I really want to understand. I have strong opinions about it, but I want to get your takes as well from, uh, coming from this from different perspectives. So let's wrap up for today and let's come back next episode and let's, let's really wrestle with that issue and we'll have some time to prepare for it as well.
Izar Tarandach:Mmhm.
Chris Romeo:Thanks for listening to Security Table, folks. Have a great rest of your week.