Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Izar Tarandach (00:11):
And we're all
burned out and we just want a
vent.
Chris Romeo (00:15):
With that, welcome
to the security table, because
that is the story of the week.
It's that, uh, it's been a longweek for all of us.
And so we're going to have somefun.
We're going to talk aboutexpectations of tooling in our
industry.
And when I say our industry, Imean, the application
security...
Matt Coles (00:36):
Product security.
Chris Romeo (00:37):
...machine?
What's the, how do I describethis?
It's, what do they call thedefense industrial sector?
Is there an application securityindustrial sector that we're
talking about here?
Is there a AppSec?
I don't know where I'm goingwith this.
I'm
Matt Coles (00:50):
Let's go there.
Let's not go there.
You're already stepping in thelandmine.
Come on.
Chris Romeo (00:56):
oh, come on.
That's.
Izar Tarandach (00:57):
No, seriously,
are we creating problems just so
that we can write tools to solvethem?
That's a good question.
Chris Romeo (01:04):
That's a deep
question right
Matt Coles (01:05):
That's an
interesting one.
Chris Romeo (01:06):
That's like an
inception kind of moment, like
the tool within the tool.
But let's talk aboutexpectations of tools.
So when we think aboutapplication security, there's a
big collective of tools that arecommercial.
There's a big collective ofthings that are open source that
you can kind of connect togetherto get some of the same results.
(01:27):
Like when you think aboutexpectations of tools, like what
are, what are your expectationsof tools?
Like, let's, let's put togethera list of things.
Like, what are we, what are weexpecting our tools to do for
us?
Matt Coles (01:40):
So, oh.
Izar Tarandach (01:43):
You go.
Matt Coles (01:44):
So I think in a
nutshell, the way I would
characterize it is I expect atool to do something a human
could do only faster and moreefficiently.
So tool A tool is automation anautomation's job really should
(02:05):
be a facilitator or somethingthat 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, thetool can do it more consistently
and reliably, um, assuming itdoes its job and is correctly
programmed in this case.
Uh, you know, it's important tothink about the classes of tools
(02:28):
that we're talking about, notjust whether they're free or
commercial, but you know, are wetalking static code analyzers?
Are we talking vulnerabilityscanners?
Are we talking, uh, you know,network penetration testing
tools?
Um, a host of, a host ofdifferent types of tools do
different things, and thosethings, again, could be done by
humans, whether they do it byhand or they do it by scripts
(02:49):
that they write.
But really we're taking sort ofindustry knowledge, collective
knowledge of the industry andthe community to feed these
things so that they do their jobwell enough to replace, free up
humans to do other things.
And in some cases, of course, weknow that those other things can
(03:11):
include verifying the resultsthat come out of a tool.
So it doesn't completelyeliminate the human activity.
Chris Romeo (03:19):
Izar, do you agree
with that general definition?
Izar Tarandach (03:27):
Yes.
Yes.
Matt Coles (03:29):
Yes, I was going to
say, I win!
Chris Romeo (03:32):
Finally! Izar is
speechless!
Izar Tarandach (03:35):
Finally somebody
muted me.
Chris Romeo (03:37):
It's because I
muted him so that we could say
he was speechless.
What a joke.
Izar Tarandach (03:42):
So here's the
thing, like, like many, like
most things in this, thisindustry, in this life, I, I
changed my opinion over theyears.
Right.
Once upon a time, tools for mewere exactly what Matt
described, but uh, over time Ifigured out that that
(04:04):
expectation might be misplaced.
I might be looking for a silverbullet where not only they
wouldn't give it to me, but theycan't give it to me, and fall
into that scan and patch loopthat we discussed the other
week, and all that stuff, and Ithink that what I look for in a
(04:27):
tool nowadays is more in termsof the auxiliary processes
around what I need, rather thanthe core knowledge.
So yeah, it's great to havetools that check configuration,
that check, that check spawnsand all that good stuff.
(04:48):
But, give me a tool thatimproves communication between
the teams, and I'm as happy as,give me a tool that reduces
context switching for anapplication security engineer,
and I'm happy.
Give me a tool that lets me doremote threat modeling easier.
(05:12):
It's good for me.
So, I think that we have a lotof tools that do security, we
have less tools that supportsecurity.
And I'm missing that.
Chris Romeo (05:23):
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 securitytools, they don't really focus
on improving communication,collaboration, things like that.
They focus on finding aparticular result.
And like I heard on anotherpodcast in the context of Slack,
(05:44):
and this just blew me away,right, because people talk about
the use of um, Slack andenterprise messaging as a better
thing than email.
Take a guess, we're gonna have alittle, we're gonna have a
little guessing time here.
How often, on average, does asoftware developer check Slack?
Matt Coles (06:06):
Three times a day.
Chris Romeo (06:08):
Okay, Izar,
Izar Tarandach (06:09):
I don't know, I
know people who pretty much live
inside Slack.
Chris Romeo (06:15):
So what's your
guess?
Matt's at three times a day.
Izar Tarandach (06:19):
Constantly?
Chris Romeo (06:20):
Every six minutes.
Matt Coles (06:23):
There you go.
Chris Romeo (06:26):
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 everysix minutes.
And so that's a very interestingproposition that you're kind of,
or I cannot, but point of thetooling that you're pointing out
here is.
We haven't done anything to, tofocus on collaboration and
communication and, and thesofter side of, of security.
(06:48):
Tools have been all about justcranking out results and
stacking them up for someone tohopefully deal with someday.
Matt Coles (06:55):
Well, can, can I
Izar Tarandach (06:56):
wait, just to
address that Slack thing.
Matt Coles (06:58):
yeah, go
Izar Tarandach (06:59):
I think that's
horrible.
That's terrible.
That's ridiculous.
That's bad.
We shouldn't be there.
We should be actively gettingout of that situation, right?
And we keep stacking things andthings on top of Slack.
It's becoming a control centerof sorts.
You can start full processesfrom Slack.
(07:19):
You can get your notificationsof those processes in Slack.
And at the same time, it'seating at our attention span.
It's eating at our contextswitching.
I mean, it's not uncommon forpeople to be in like, I don't
know, a hundred different Slackchannels.
Imagine being in a room,listening to a hundred people
talking about different thingsat the same time.
(07:41):
Right?
At least you go to Black Hat andpeople are talking about the
same thing.
But imagine being in a room andyou have to pay attention to 100
conversations and they are allhappening in real time, in
different ways, and it'sinformation that you need for
your job.
Matt Coles (07:57):
So,
Chris Romeo (07:57):
stat.
I want to throw one more stat atyou because it's in this same
thing.
That's going to blow your mindas well.
I saw this as, and, and it'snot, has nothing to do with
security.
It has to do with interruptions.
The average 18 to 27 year oldgets something like 2, 500
notifications a day on theirphone.
I have notifications turned offon my phone, but I'm old school.
(08:19):
Like I don't, like my phone, Idon't want to be bothered.
I don't want something to gobing, bing, bing all day long,
because I know I'm on that sameprogramming that everybody else
is, that if I get the bing,what's, what's happening?
What happened?
You know what, I need to knowsomething that's happening.
And so, um, that, that one justblew me away too.
I was like, wow, that's a lot ofnotifications.
(08:41):
People are texting all day long,they're, they're Snapchatting,
they're Instagramming, they'redoing all these other things
that I probably don't even knowthat they're...
Exist at this point.
But once again, it's this, it'sthis constant interruption
culture.
I know that's not where we weregoing, but we're kind of, we're
kind of focused on this for aminute.
So Matt, what are your thoughts?
Matt Coles (09:00):
So first off, I just
want to, I think I misunderstood
the question and Izar took usdown a different path.
I was avoiding the collaborationside of tooling because, well,
that's a different space.
I guess what you're, what you'rereally talking about is
integrating security tools withcommunications platforms, right?
Whether that be Jira, orConfluence or, you know, those
(09:23):
types of tools or Slack or Teamsor whatever, some sort of
messaging, because there arecompanies that do that for a
living that are much better atthat.
And I thought we were talkingabout security tools, like
things that operate on productsor applications.
So my mistake, but I understandwhere you're coming from, right?
And, and that's absolutely agoal, should be a goal, right?
Is how you communicate thatinformation in a way that
(09:45):
developers and others can takeadvantage of it quickly and
efficiently.
Because tools should be aboutefficiency and productivity.
Izar Tarandach (09:54):
But that's
exactly what I'm challenging.
I think that we came to rely onthings like Slack and Jira way
too much, just because everybodyuses them.
So we assume that thefrictionless path is to go and
work on them as well, right?
Matt Coles (10:09):
Well, so, I guess
trends happen because, you know,
people in the industry learnthese platforms, they get
comfort with them, and then theycollectively go, Well, hey,
we're all a group and we allknow how to use Slack, so let's
go ahead and use Slack.
As opposed to...
But as soon as something newcomes along, there's a
progression, right?
to try and adopt those newthings.
(10:29):
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 (10:39):
They have get
Mastodon installed at some
point.
Izar Tarandach (10:42):
But
Matt Coles (10:42):
Well,
Izar Tarandach (10:42):
the point.
Chris Romeo (10:42):
Good luck with
that.
Izar Tarandach (10:44):
the point.
You just got into a more of thesame, right?
And what I'm saying is, youknow, take a Purple Team
exercise.
You could do it over Slack.
That'd be awesome.
Yeah, it works great, and Slacknow has new features that do
even better for you to shareideas and data and whatnot.
But is that the best thing?
Matt Coles (11:05):
well, how do you so
how would you, so I guess,
rather than asking what the besttool is, what characteristics of
that communication are youlooking for?
Izar Tarandach (11:15):
Great, that's
the question.
So again, in a Purple Teamexercise, for example.
I'm on the blue team.
It would be great to see thescreen of the red team in
parallel as I'm there as they dotheir stuff and I see my stuff
and I can correlate both of themin real time without it passing
through some sort of a filterthat needs to, they need to tell
(11:36):
me now we're doing this and Ihave to interpret that and
figure out what it looks like inmy head and go see my stuff,
right?
So,
Chris Romeo (11:44):
taking, taking the
collaboration tools out of the
picture and making, cutting outthe middle person, right?
It's, it's going to, it's, it'sproviding a tool that has the
communication and collaborationbuilt into it directly.
Izar Tarandach (11:58):
I think it's
more about not intermediating
that, that exchange, thatsharing through some kind of
filter that may change what'sbeing shared.
So if you go Slack and youconsider 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 whatI'm seeing right now.
(12:20):
But if at the same time, I havea tool that shows me both
screens at the same time and Ican 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 humanfilters.
with a media that perhaps can orcannot pass all that I need in
order to know what's happening.
Matt Coles (12:39):
That seems very
specialized, right?
That's like, that's veryspecialized for that use case.
Um, but, but maybe that, I mean,maybe that's the right way to
look about this, right, is, Imean, you have to really, in
order to choose a method, youhave to know what your, what
characteristics you have.
So that makes sense.
Are there other things similarto that where this would become
(13:01):
commercially viable?
Right, because that's the nextthing, right, is either you're
going to write it yourself oryou're going to make, or
somebody has to build it and
Chris Romeo (13:11):
sure.
You're going to squash ourdreams by making something have
to be commercially viable.
Come on.
Like,
Matt Coles (13:16):
or a pet science
project for somebody who can
Chris Romeo (13:20):
I'm on, I'm on, I
was thinking the same thing.
Like as I started to, I was, Iwas thinking about this myself
and I'm like, so wait, now we'rein a world where I have separate
communication channels in everytool than my security suite.
So my SAST tool has a, a set offorums and conversations and my
RASP and my.
(13:41):
SCA, they all have different,they all have these.
So I end up with 27 differentcommunication things that I have
to do.
Izar Tarandach (13:48):
So let's go
there.
Let's go there.
Let's say you have those 27tools and you have Slack in the
middle.
You're getting 27 differentchannels of information.
Chances are that many of thoseare either related or the same
thing viewed by a differenttool.
(14:09):
One category of tools that I amnot...
aware exist broadly.
I can think of one or twoexamples that I'm not going to
mention, but that exist.
One tool that would bring allthese 27 channels together,
figure out who's who in terms ofwho relates to whom, and the
(14:31):
different sources of informationand whatnot, and present me that
information in terms of fivedifferent pieces of things that
say, hey, from all those 27,these are actually five things
that those 27 things are tellingme exist.
Focus on these, not on the 27.
Five is a much nicer number forme than 27, especially if I have
(14:52):
to check it every six minutes.
Chris Romeo (14:54):
mean, I think we
just invented a category of
AppSec tools that already existscalled ASOC.
Application SecurityOrchestration and Correlation is
a segment of the market that isfocused on taking feeds from
noisy AppSec tools, building oradding contextualization around
results, and then giving you aview of that.
(15:15):
So you don't have 10, 000events.
It's like a sim for AppSec toolresults.
Izar Tarandach (15:22):
I don't speak
Gartner.
Matt Coles (15:23):
And, well, and, and,
and,
Chris Romeo (15:26):
Wow, that hurts,
man.
That hurts.
Matt Coles (15:28):
and, and, and, and,
and, and, and, and, and,
Izar Tarandach (15:31):
you're the CEO.
You're the CEO.
Matt Coles (15:32):
And then
realistically, realistically, of
course, you could always askchat GPT, hey, monitor these
feeds for me and, and give methe salient points.
Chris Romeo (15:42):
And then ChadGPT
starts hallucinating about, Oh,
there's a big problem happeningright now because it somehow
knew about some attack fromyears ago.
It's happening now andeverybody's freaking out.
Izar Tarandach (15:54):
the CEO Okay, we
said ChatGPT.
We have to say EPSS and threatmodeling.
That's it.
Enough.
We did it for today.
Chris Romeo (16:01):
Laid over.
Matt Coles (16:02):
SBOM, SBOM..
Izar Tarandach (16:04):
All the jars are
full now.
Chris Romeo (16:05):
Whoa, whoa, Matt,
watch your language here.
This is a family show.
Come on.
Alright, so we thought we weregoing to revolutionize the
industry, but we, we justreinvented a, apparently a
Gartner category, even thoughthere's tools that exist in it.
Izar.
Um, so not just a Gartnercategory.
Izar Tarandach (16:24):
I didn't get the
memo.
I'm sorry.
Matt Coles (16:26):
You're going to get
the sales calls.
Chris Romeo (16:28):
that's right.
I'm going to, I'm going to signyou up for a bunch of demos and
stuff from people.
to get all kinds of people
Izar Tarandach (16:36):
Actually,
apparently that's the thing.
I, I heard from people thatdidn't go even close to some
conventions and whatnot, and allof a sudden they go like the day
after the convention and startedgetting so much spam.
So, there are people out therewho are signing up other people.
Chris Romeo (16:52):
There is a, uh,
Matt Coles (16:53):
that's interesting
social engineering attack
actually.
Chris Romeo (16:56):
yeah, there,
Izar Tarandach (16:57):
not, it's not
difficult to manufacture the QR
code, right?
So you just slap it on top ofit.
Chris Romeo (17:02):
there is, I'll go a
step further.
I found there is a service thatwill sign people up for email
lists.
So if you want to, if you wantto cause somebody difficulty,
you put their email address inand it'll go sign them up for
like hundreds, if not thousandsof different legitimate email
lists.
Izar Tarandach (17:21):
without
verification.
Chris Romeo (17:22):
Yeah, without,
Matt Coles (17:24):
Well, it's self,
it's,
Chris Romeo (17:25):
verification and,
and approval is a joke when it
Izar Tarandach (17:29):
That's why we
can't have nice things, you
know.
Chris Romeo (17:32):
It is, I mean, can
spam is, as a, as a legislation,
like, it, it has all thesethings that people are supposed
to do and penalties if theydon't.
But, email is one of thesethings that people just abuse
the heck out of without theproper approvals and things.
So yes, you can just go there.
(17:52):
I could sign up your email for2000 email lists and none of
those people are going to care.
I didn't opt in.
Izar Tarandach (18:01):
So I'm looking
here at the homepage of
DefectDojo, and it doesn'tmention that category that you
mentioned.
And that's actually my go towhen I need an example of a tool
that does more or less what Iwould like to see other tools
doing.
Chris Romeo (18:18):
DefectDojo is not
referring to themselves as an
ASOC at this point.
Izar Tarandach (18:22):
I don't think
so.
Which just makes them more in mybook.
Matt Coles (18:29):
an open, it's an
open source application
vulnerability managementcorrelation and orchestration
tool.
Izar Tarandach (18:34):
You see, by
Chris Romeo (18:36):
They
Izar Tarandach (18:36):
the time I
finish saying that, I already
got 16 more alerts.
Chris Romeo (18:45):
Let me just check
Slack real quick.
Hold on.
It's been six seconds.
Izar Tarandach (18:48):
Have six minutes
already passed?
Chris Romeo (18:51):
Yeah, six seconds.
Every six seconds I check fornew messages.
I
Matt Coles (18:54):
So, so, I mean, I
think you're using, you use
Purple Team as a, as a veryconcrete example here.
Izar Tarandach (19:00):
Yeah, but it was
an extreme example.
Matt Coles (19:02):
Okay.
So what's a more mundaneexample?
Izar Tarandach (19:06):
Oh.
Chris Romeo (19:09):
mean, let's use the
SAST tool.
Let's, let's, how would youlayer enhanced communication on
top of a SAST tool that isn'tSlack and isn't Teams?
Matt Coles (19:20):
So I would look at,
I would look at GitHub as an
example.
So if PRs, if PRs is includedSAST and you use PRs as a
vehicle for shared code reviewsand comments on code changes.
Right.
That's something that GitHubdoes today.
Right.
Is that sufficient for, youknow, 90 percent of the use
(19:43):
cases out there for whendevelopment teams need to do
shared code reviews, peerreviews, um, you know, uh,
security analysis?
And, and why restrict it to justSAST when you can have, uh, a
build framework that also runs,uh, other Other tools.
I'll, I'll keep the, keep theother four letter, four letter
acronym out of, out of that.
(20:04):
Uh, right.
But correlating otherinformation 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 thehumans in doing their jobs more
effectively.
Izar Tarandach (20:22):
I think that
GitHub is a good example of
something that lives in thatboundary where developers and
security people can meet andsort of start speaking the same
language.
Because the, uh, some of theartifacts created by security
tools in GitHub end up giving todevelopers something that they
(20:44):
can immediately work with andhave to interpret less.
With that comes the fact that,uh, If there is a thousand ways
of doing something, there's1,001 ways of doing something,
and it's an arms race for thosesecurity tools to create PRs
that speak, I don't know,Terraform, whatever the IAM or
(21:08):
whatever happens this week.
Chris Romeo (21:09):
Yeah, but in Matt's
example, we're talking about
native tools that are alreadyintegrated into GitHub
Izar Tarandach (21:15):
Right?
But the output that they
Matt Coles (21:17):
I wasn't, I actually
wasn't, I actually, so I
actually wasn't, wasn't, I wassaying tools that get integrated
with GitHub, whether it's nativewith, or,
Chris Romeo (21:23):
All
Izar Tarandach (21:23):
but the output
that they, they give has to work
on whatever CI pipeline youhave.
Right.
And that's where you get themultitude of, uh, of, uh, uh,
options and, and perhaps notevery tool speaks that specific
thing that you are using in yourpipeline.
Matt Coles (21:41):
but I guess the
important part is.
Chris Romeo (21:42):
But we would agree
thats a better practice though,
right?
To use I mean, it's certainlybetter than having Communication
on Slack about results comingout of a scanning tool like
SAST, like having an integratedonto the PR, there's no better
place.
You can put it to be in thedeveloper's flow.
Now I'm assuming they're usingGitHub
Matt Coles (22:03):
GitLab, pick your,
pick your CI platform, slash,
Izar Tarandach (22:08):
But, but then I
think that we, we fall into the
discussion between communicationand action.
So the PR is an action thing,right?
The PR is check this thing thatI'm, that I as a tool, I'm
telling you you should dodifferently and enable it or,
or, or reject it.
But Slack is just, hey, I havesomething to tell you.
Matt Coles (22:29):
But I think it's
important though, with GitHub,
it's a human, it's a developergenerated activity.
I made a change and the tool isdoing all the workflow bits for,
I made this change, help mereview it before I commit it.
Izar Tarandach (22:45):
It's again,
sorry, it's the loop.
So it starts the way that yousaid, but then you have an
action that says I checked yourcode, and by the way, there's a
mistake in there, and here's aPR that fixed that mistake.
Matt Coles (22:58):
Okay.
So the tool helps the human bemore efficient.
Izar Tarandach (23:01):
going both ways,
right?
And I think that where the toolsare verbose and create too many
of those things, then you havetoo 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 tostack up in your inbox in
GitHub, is it called an inbox?
(23:22):
I don't think so.
And they're going to pile up inyour Slack channel dedicated to
that.
Chris Romeo (23:28):
That's another,
Izar Tarandach (23:29):
of the...
Chris Romeo (23:30):
you've highlighted
another challenge in modern
tooling though, in that.
The pattern that tool providershave followed so far has been:
create a tool that has a policythat looks for things and then
reports everything it finds.
(23:51):
There's no, like, no, nobody hasbuilt a, a, an intelligent SAST
tool.
That I'm aware of.
And what I mean by anintelligent SAST tool is, it
doesn't just scan and dump outall of the things that are wrong
with my code.
It has some prioritization, somecontextualization built into the
(24:11):
SAST tool itself.
And well, I'm not creating a newGartner category here, by
Matt Coles (24:15):
Uh, there, there are
tools that used to do that.
I don't think that they still dothat, but there, there were some
that tried to do that.
Coverity.
So Coverity tried, tried to,right?
So they built a model, the modelbased, so rather than being,
rather than doing the grep basedthing, right?
Uh, tools like Coverity, theytried to do model, they did a
(24:36):
model check approach, I believe,way back when, I'm not sure if
they still do.
Um, but they tried to, and Iknow Izar, you're laughing over
there because, you know, resultsmay vary, but they at least
tried, right?
They tried to minimize falsepositives.
Chris Romeo (24:53):
Yeah, but they
still dumped...
That doesn't...
So they still dumped all thethings they found.
What I'm saying is nobody hassaid, okay, no matter how we
scan for results, that's half ofwhat my tool does.
Once I get the scanned results,now prioritization, doing some
contextualization.
Izar Tarandach (25:12):
Oh, there are,
there
Matt Coles (25:13):
Oh yeah, there are.
Izar Tarandach (25:14):
there are.
Yeah,
Matt Coles (25:15):
You can even do that
with, with any of the stat SAST
tools, commercial SAST tools outthere.
You, I mean, you could tell itonly look for this type of issue
Chris Romeo (25:21):
I mean, why do they
return 10,000 results, though?
Matt Coles (25:22):
Because they're
misconfigured; because they're
misconfigured.
Chris Romeo (25:24):
So, but I don't
think anybody's doing I don't
think there's a SAST tool thatis intelligently providing me a
summer.
They may be doing a some sometype of summarization.
My point is is there a SAST tooltoday that will give me the five
things that I really should fixbefore next Tuesday?
Izar Tarandach (25:43):
It's the top
five in the list, right?
They're not going to say theseare more important than
Chris Romeo (25:47):
it's exactly, it's
top five of 500, like I want,
like,
Matt Coles (25:52):
but if you, if you
Chris Romeo (25:52):
argument though, is
nobody has layered a, a, a piece
of any of these tools that doesthat for me, that gets me some
legitimate, these are the fivethings I have to fix in the next
month.
Izar Tarandach (26:05):
Because it goes
against the context, right?
It's what we spoke the otherweek.
We have to have these tools notonly be more intelligent, sorry
smart, but we have to give themvisibility beyond the immediate
line of code.
We have to somehow code Wherethat code lives, what it does,
how important it is, and thenput all that into the mix and
(26:28):
come out with something.
Matt Coles (26:29):
right.
So.
Izar Tarandach (26:31):
Just a second.
When you started describing yoursmart tool thing, the only thing
that came to my mind was somescanner 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'tknow what the problem is, I'm
not telling!
Chris Romeo (26:51):
Yes, we are
building this, we are building
this because it won't, we won'thave to do anything.
All we'll have to do is pretendthat a scan was run and then
just provide that error codewhich then they look in the man
page and see that's the errorcode actually says, if you don't
know what this is, you've gotbigger problems.
Matt Coles (27:07):
If you have to ask,
you can't afford it.
Izar Tarandach (27:09):
That's the IBM
approach to error codes.
Matt Coles (27:14):
so back.
So back to your, back to yourprioritization discussion.
So tools today, by and large, Ithink commercial tools
especially, but probably some ofthe open source tools as well.
First off, have a ton ofconfiguration options that
probably nobody is usingeffectively.
Right.
So, so you could say, you know,say pick a, pick a SAST tool and
(27:35):
say, I want to, I'll, I'll pickCenter 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 lookat only Java vulnerabilities and
I wanna only wanna look tho lookfor those vulnerabilities that
tie to a CWE Top 25 issue.
Right?
And so it, in theory, willfilter out all of those scan
(27:55):
results down to that set.
So that's a, that's aconfigurable option that gives
some level of prioritization.
Now I have, so now I have a setthat is constrained, right?
Now add to that configurationoptions to say, well, I really
want to bubble up to the topcritical findings.
Now obviously it's going todecide what critical is, not
(28:16):
you, right?
Because it's not smart enough toknow context.
At least at that point, butthat's where, that's where some
of these tools that do saycontrol flow analysis, right?
Can say, well, I get data fromthe outside and then it comes in
and causes a buffer overflow.
That sounds more critical thansomething that only uses data
(28:38):
internally.
And if you pair that withinformation about the project,
like this is an internet facingweb application.
Now you can do trueprioritization and our tools
that used to do this, again, Idon't know if they still do.
Fortify was a good example.
Uh, and Tenable is anotherexample from this, from the
scanner side where, um, youwould provide information about
(29:00):
the projects to your scanninginto sort of a, like a control
center or security center kindof thing.
I think that they called itsecurity center, in fact, on the
fortify side.
Uh, and, and that would tell youabout this project is this type
of application and therefore,That allows you to do some sort
of business prioritization forthe results that come out.
And so, they're not smart by anymeans, at least they weren't in,
(29:23):
and this is, well, I'm talkinglike a decade ago.
So they weren't smart in thatregard, at least not by today's
standards.
But it's not a stretch that youcouldn't get there.
Well,
Izar Tarandach (29:33):
Yeah.
Chris Romeo (29:36):
Yeah, I mean
that's, that's, I think it's
just a missing piece.
I think it's a missingopportunity.
Matt Coles (29:42):
I think what's
really missing is the
correlation of other data.
Right, so we're talking aboutSAST, and we're talking about...
Scanners, the other
Chris Romeo (29:52):
can say SCA, it's
okay, SCA is okay.
Matt Coles (29:55):
I wasn't going to
say SCA, but I was going to say,
I was going to use a D word thatyou don't want me to use.
Chris Romeo (30:00):
what do you mean?
Izar Tarandach (30:01):
Dread?
Chris Romeo (30:01):
mean dead?
The tool, the, the, the toolthat I now refer to as dead, the
Izar Tarandach (30:06):
I hear dread?
Chris Romeo (30:06):
of tool or dread.
Matt Coles (30:08):
so, uh, but
correlating information across
all these tools to give you acomplete picture that will give
you prioritization, right?
Like I find you have an openport and that port ties to a
piece of code and that code hasa vulnerability.
And now I can know that, youknow, that this is more severe
than one that isn't.
Izar Tarandach (30:27):
yeah.
Chris Romeo (30:28):
that's why we're
seeing some startups now that
are trying the mode of buildingtheir own SAST, SCA, the bad
word.
Um, and then other.
Matt Coles (30:40):
SCA is good,
software composition analysis.
Izar Tarandach (30:42):
Well, yeah,
depends which SCA we're talking
about.
It's horrible when we get to thepoint that we have to recycle
acronyms.
Matt Coles (30:48):
Oh my god, oh
Chris Romeo (30:49):
But you,
Izar Tarandach (30:50):
people, two
people can be talking about SCA,
have two completely differentconversations, and it actually
makes sense.
It's terrifying.
Chris Romeo (30:57):
but my, my
Matt Coles (30:58):
like Stig's
recently.
Chris Romeo (30:59):
My point is you've
got, you've got some startups
that are trying to build each ofthe pieces of the tooling so
that they can build in thecontextualization to have the
SAST and SCA talk to each otherand, and, and enrich the results
coming out of it.
Now, the challenge there is.
It's not best of breed.
(31:20):
It's not, it's going to be toughto have best of breed in every
category if you're building allyour own.
Maybe the contextualization willbe enough to get you to market
acceptance.
Because the contextualization ofthree average tools in those
various classes is worth morethan best of breed in each of
those categories that don't talkto each other.
(31:41):
I don't know.
That'll be for the market todecide.
Izar Tarandach (31:45):
Now, let's,
let's take that to, to its
extreme.
Let's say that tools start beingsmart that way.
Are we done with securitypeople?
Matt Coles (31:59):
No.
Izar Tarandach (32:01):
What's going to
be missing?
Matt Coles (32:04):
I think you still
need, you still need a human to
provide context, and you stillneed a human to make certain
decisions that the tool can'tmake, should not be making
automatically.
Izar Tarandach (32:14):
But given all
that information, won't
developers be able to do those,to make those decisions?
Matt Coles (32:19):
Oh, oh, sorry, yeah,
I'm sorry, I wasn't,
Chris Romeo (32:21):
Well, that's a
good, that's a good place for us
to end for today, which, youknow, it's kind of a strange way
to start.
But, here's what I want to talkabout next time.
And I think this is somethingthat I've been kicking around
and I want to get both of youropinions on it.
I see a future world whereAppSec is no longer.
I see a future world wheredevelopment eats security, the
(32:45):
security team.
And I don't want to get into it.
We don't have time to get intoit today, but I want to put that
on your both in our, ourlisteners minds to be thinking
about, but also the two of youso you can chew on it.
And then let's come backtogether next, uh, for the next
episode.
Let's deal with that issue.
Cause I really want tounderstand.
I have strong opinions about it,but I want to get your takes as
well from, uh, coming from thisfrom different perspectives.
(33:07):
So let's wrap up for today andlet's come back next episode and
let's, let's really wrestle withthat issue and we'll have some
time to prepare for it as well.
Izar Tarandach (33:15):
Mmhm.
Chris Romeo (33:16):
Thanks for
listening to Security Table,
folks.
Have a great rest of your week.