►
From YouTube: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights group
A
B
Thanks
thanks
lucy,
so
the
topic
is
regarding
the
the
enum
that
is
lately
being
introduced
with
it
with
nmr
that
mikhail
submitted.
So
in
that
one
there
is
this
origin
enum,
which
accepts
value.
That
is
api.
I
guess
so.
The
the
the
question
that
I
posed
was
that
if
we
are
going
to
use
api
then
it
might
be
difficult
for
us
in
the
future
to
distinguish
we
manually
created
vulnerabilities
versus
vulnerabilities
created
by
by
scanners.
B
The
concern
is
that
if
we
use
api
as
an
origin,
we
in
the
future
or
is
there
a
plan-
sorry
is
there
a
plan
to
distinguish,
but
we
manually
created
vulnerabilities
and
the
the
ones
found
by
the
scanners,
because
probably
we
will
need
to
filter
them
in
the
ui
right
matt
like
using
a
filter.
Do
we
have
a
filter
where
we
say
just
show
us
just
show
me
that
the
vulnerability
is
created.
C
Manually,
so
I
just
closed
that
merge
request.
It
stems
from
the
issue
that
okay,
so
basically,
every
vulnerability
has
a
report
type
and
the
graphql
mutation
that
we
are
planning
to
use
for
the
user
interface
will
create
vulnerabilities.
C
With
the
report
type
of
generic,
I
was
under
the
impression
that
you
could
integrate
a
custom
scanner
in
the
gitlab
ci
dot
yml
file,
which
would
ingest
some
some
some
kind
of
arbitrary
report
you
could
make
up
and
I
figured
out
if
you
can
do
that,
then
you
could
possibly
create
a
vulnerability
with
report
type
of
generic,
which
would
be
actually
created
by
the
security
scanner,
and
I
think
it
was
like.
Oh
boy.
C
So
this
is
not
a
problem
and,
to
sum
it
up,
basically
any
vulnerability
created
by
the
graphql
mutation
will
have
the
report
type
set
to
generic,
and
this
is
what
we
can
use
to
differentiate
between
vulnerabilities
created
by
the
api
call
or
by
the
user
interface
and
the
vulnerabilities
coming
from
the
security
scanners.
So
the
origin,
technically
speaking,
is
no
longer
needed.
I
thought,
basically,
you
could
fool
the
security
scanner
to
create
a
different
type
of
the
vulnerability
than
it's
supposed
to,
but
I
just
tested
it
manually
on
my
gdk
and
it
does
not
happen.
C
B
This
means
that
when
a
vulnerability
has
the
reported
generic,
it
means
that
it's
a
100
percent,
we're
sure
that
it's
it's
created
manually.
C
And
this
brings
me
to
another
point
recently.
I
I
kind
of
realized
we
have
this
thing
called
starboard
vulnerability
create
service
which,
which
creates
vulnerabilities
based
on
starboard.
I
think
that's
a
container
security
does
a
container
a
scanner
and
it
sets
its
report
type
to
cluster
image
scanning,
which
shouldn't
which
shouldn't
create
report
type
generic
vulnerabilities,
so
we're
safe
on
that
front.
B
Okay,
because
I
guess
matt,
we
will
filter
them
on
the
vulnerability
report
page.
We
will
filter
them
right
and
we
will
allow
users
to
filter
only
and
display
only
vulnerabilities
that
were
created
manually.
That's
the
intention.
I
guess.
D
Matt
yeah
yeah,
absolutely
so
I'm
kind
of
looking
through
the
designs
again
real
quick
just
to
make
sure,
but
it
seems
like
we
might
do
something
slightly
differently
since
we've
tied
the
filters
are
basically
report
type
for
git
lab
is
kind
of
the
same
thing
as
kind
of
like
the
name
but
like
when
we
integrate
a
third-party
scanner.
It
appears
separately
under
the
vendor's
name
and
then
the
report
type.
D
So
I
think
we
may
have
something
additional
like
that,
like
anything
that
has
a
generic
schema
would
go
in
a
like
a
header
that
might
say
you
know
manual
finding,
so
I'm
trying
to
find
that
the
design
for
it's
not
explicit.
I
don't
think
I'll
need
to
talk
to
andy
about
that,
just
to
make
sure,
but
then
each
of
the
enum
types
like
code
review,
bug,
bounty
or
whatever,
I
think
would
appear
underneath
those
as
individual
filters.
D
B
So
so
the
the
manual
is
like
the
header
and
then
code
review
is,
is
a
subheader.
So
it's
a
like
sub
category
set
to.
D
In
the
design
example,
get
the
slack
control
out
of
the
way
there
we
go
yeah,
so
we've
got
like
today.
The
gitlab
header
has
secret
detection
dependency
scanning
sas
and
das
by
report
type.
I
would
expect
to
see
manual.
Finding
would
probably
be
here
in
this
drop
down
as
a
header
and
then
code
review
is
one
of
the
options
and
then,
if
you
have,
you
know,
bug
bounty
or
api,
whatever
else
is
in
the
enum.
B
So
scan
type
is
the
report
type.
I
guess
in
the
back
end
right.
D
C
C
And
if
you
want-
and
we
we
also
have
what
I
mentioned
to
you
yesterday-
we
have
also
detection
method
which
would
be
another
filter,
and
I
imagine
the
detection
method
would
be
code
review
the
value
we
have
like.
We
have
this
xss
cross
site
scripting,
it
has
manual
finding
and
the
method
is
called
review.
So
I
imagine
we
would
have
two
filters
report
type
which
would
be
generic
or
we
could
rename
it
to
manual
finding,
and
we
would
have
also
a
different
filter
for
the
detection
method.
D
Well,
I
guess
that's
why
I'm
saying
it's
a
little
bit
different,
because,
right
now
we
use
the
schema
type
lumped
under
a
vendor.
I
would
almost
treat
the
generic
schema
type
like
a
vendor,
making
it
its
own
header.
So
if
you
you
could
keep
it
in
the
same
filter,
but
I
realized
that
we're
pulling
different
pieces
of
information
to
construct
those,
so
we
would
be
using
the
the
detection
type.
D
D
I
think
this
will
make
more
sense
too
and
we're
just
sort
of
looking
at
a
static
picture,
not
the
picture
that
I
want
to
demonstrate.
So
let
me
work
with
andy
or
I
could
even
mock
something
up
pretty
quickly
to
show
what
I
think
it
should
look
like,
and
then
you
can
tell
me
that
that's
never
gonna
work
and
it's
well.
Did
you
rethink
it.
C
Right
now,
because,
like
we
have
this
security
scanner
integration,
which
means
that,
if
you
don't
want
to
use
our
internals
the
scanners,
that
gitlab
provides
you
can
you
can
somehow
integrate
your
own
scanner
in
the
gitlab
ci
dot
yml
file,
which
uses
the
artifact
reports
keyword,
you
can
say
hey
this
particular
ci
job
is
going
to
give
you
the
results
of
an
api
fuzzer
or
I
don't
know
dust
scanner
or
a
sas
scanner
and
we're
expecting
those
scanners
to
adhere
to
some
kind
of
schema
and
the
generic
schema
here
is.
B
My
understanding
is
that
we
still
need
to
figure
out
the
exact
details
for
this
so
for
regarding
the
manually
created
vulnerabilities
should
we
just
add
a
column
and
then
say
this
is
manually
created
so
that
in
the
future
we
don't
have
backward
compatibility
issues
in
the
database.
C
I'm
not
sure
what
you
mean
by
that.
I
I
I
basically
basically
engineered
in
that
in
that
way,
so
you
can
create
manual,
vulnerabilities
and
keeping
the
data
compatible.
I
mean
we
are.
I
did
have
to
hardcode
some
values
because,
like
we
don't
expect
the
user
reporting
to
vulnerability
to
like
provide
us
with
a
scanner
name,
because
there
is
no
scanner
to
begin
with.
C
I
mean
if,
if
the
vulnerability
was
created
manually
by
the
users,
it
can
mean
that
either
that
user
is
manually
importing
the
data
from
a
scanner
security
scanner,
which
is
like
I'm
not
sure
why-
and
the
other
possibility
is
that
the
user
basically
found
the
vulnerability
himself
and
in
that
sense
scanner
name
makes
no
sense
requiring
the
user.
To
give
us
a
scanner
name
makes
no
sense
to
me.
So
I
hard
coded
the
scanner
name
like
manual
scanning
or
something
like
that.
B
Yes,
but
from
my
understanding
right
now,
apart
from
the
report
type
being
generic,
there
is
no
way
for
us
to
distinguish
between
a
manually
created
vulnerability
and
the
skills.
B
Yes,
so
would
just
adding
a
new
column
and
then
in
the
database
and
then
saying
okay,
this
is
like
is
manually
created
or
something
like
that
and
then
having
it
true
or
false
would
help
us
to
distinguish
in
the
future,
because,
from
my
understanding
it's
still
like,
we
still
need
to
iterate
on
on
the
design
and
write
map.
So
maybe
a
future.
If
we
think
about
the
future,
maybe
just
having
a
column
would
solve
a
lot
of
problems.
C
B
Yes,
but
in
in
the
past
we
had
some
assumptions
that
in
like
in
the
future,
it
changed,
so
it
created
some
backwards,
compatibility
problems
and
right
now
we're
first
stuck
with
those
decisions.
We
cannot
go
back,
so
I'm
just
asking.
Is
this
another
moment
like
that
or
we're
completely
sure
that
generic
will
not
be
used
for
something
else?.
C
C
Yes,
if
it
turns
out,
we
have
a
generic
report
schema
for
a
security
scanner.
Then
we
can.
We
can't
start
supporting
it,
but
before
that
we
will
need
to
migrate.
The
manually
created
vulnerabilities
to
a
different
report
type
or
maybe
perhaps
we
could
back
the
origin
field
which
I
initially
proposed,
but
it
doesn't
matter
at
this
point.
D
Yeah,
I
think
part
of
the
complication
with
it
was
just
having
the
other
scanners
take.
What's
in,
what's
common
in
their
space
report
formats
and
moving
those
all
into
the
generic
format,
that's
where
the
generic
details
field
sort
of
spun.
Out
of
that,
I
would
still
very
much
like
to
have
a
and
well,
I
guess,
could
we
also
just
not
call
it
a
generic
schema?
Could
we
just
name
it?
The
like
general
schema,
just
give
it
a
different
name.
That's
not
generic!
Would
that
avoid
that
problem
too.
D
Right
then,
we
wouldn't
have
to
backboard
or
do
anything
with
it,
but
I
would
very
much
like
to
have
some
sort
of
format
where
people
can
incorporate
tools
that
are
not
necessarily
the
these
traditional
code.
Security
scanners,
you
know,
come
up
with
whatever
you
want
lightweight
tooling.
I
think
there's
a
lot
of
interesting
use
cases
and
benefits
for
that.
D
But,
like
you
said,
we
don't
have
it
now
and
I
think
we
can
address
those
problems
if
they
come
up
in
the
future
but
yeah
for
now,
I'm
happy
to
have
the
generic
just
be
anything
that
goes
in
here.
I'm
also,
I
guess,
from
a
user
perspective,
I'm
a
little
bit
less
worried
about
them
getting
sort
of
confused
about
the
source,
because,
ultimately
you
know
the
customers
are
going
to
control
their
instance.
D
C
I
was
I
was
worried
because
I
was
pretty
much
convinced
you
could
fool
the
ci
ingestion
to
create
a
different
report,
type
like
just
just
taking
to
artifact
file
modifying
the
scanner
type
inside
the
artifact
file
and
having
a
gitlab
ingested,
but
I
just
tried
doing
that.
I
copied
I
copy
and
pasted
api
fuzzing
report
change
the
scanner
type
inside
the
artifact
to
generic,
but
it
didn't
create
a
generic
vulnerability.
C
B
B
D
Yeah
and
that's
why
it's
confusing,
because
right
now
we
group
by
vendor
type,
is
it
get
laborers
at
a
third
party
and
then
it's
by
basically
by
schema
by
report
type.
But
this
will
be
a
heading
that
is
the
report
type,
which
is
the
generic
report,
type
we're
going
to
call
it
manual
finding,
and
then
each
of
the
detection
methods
is
going
to
be
the
sub
selections.
B
If
we
do,
if
we
do
that
way,
so
we
have.
Where
is
that
the
the
initial
design?
I
think
it's
the
first
page
yeah
here
so
in
the
scan
type
it's
going
to
be
manual
and
then
there
will
be
code
review
or
other
detection
methods.
But
the
thing
is
this:
is
the
report
type
filter
and
we
will
mix
it
with
the
detection
method
input?
So
it's
going
to
be
two
filters
combined
and
code
wise,
it's
possible,
but
it's
going
to
make
it
an
ugly
code.
Can
I.
A
D
A
C
You
can
look
further
down
in
the
discussion
I
outlined,
which
detection
methods
we
currently
have
yeah
these
ones.
If
we
want
more,
we
can
add
more
no
problem.
B
Okay
but
yeah,
so
my
concern
is
that
we
gonna
have
one
input
here.
I'm
sorry
yeah
one
input
here
for
two
different
filters
and
that's
gonna,
add
a
bit
complexity.
D
Yeah,
that's
that's
kind
of
what
I
was
trying
to
explain
earlier
was,
I
wasn't
sure
how
okay
challenging
or
ugly
that's
gonna
be
technically,
but
I
guess
thinking
from
a
user's
perspective.
We
don't
want
them
to
have
to
understand
that
these
are
two
different
things
right
like
I
would
just.
I
could
know
that
I
went
for
a
scanner
versus
a
manual
input
type.
D
That's
why
I'm
a
little
hesitant
to
split
it
out
into
two
separate
filters,
because
I
wouldn't
necessarily
understand
why
they
were
separate
things
and
then
you
would
get
into
weird
combinations
if
we
broke
it
out
like
how
would
that
behave?
If
you
had
selected
sas
as
well
as
something
in
a
different
filter,
are
you
now
handing
those
together?
So
you
would
never
see
results
like
you.
Would
today,
yeah.
B
So
would
ideally
we
would,
we
would
have
so
we
right
now
we
have
detection
methods,
but
that's
a
new
new
new
field
right.
We
just
introduced
it.
I
guess.
B
B
So
my
like,
I
would
expect
that
we
we
have
a
report
type
that
is,
for
instance,
not
generic,
but
it's
like
generic
code
review
or
generic.
Whatever
detection
method
we
have
so
we
combine
in
the
back
and
we
combine
the
detection
method
with
the
report
type.
So
we
don't
have
to
do
ugly
things
in
the
in
the
front
end
if
we're
going
to
have
one
filter,
because
otherwise
it's
going
to
be
ugly
and
ugly
code
means
more
bug
and
more
bug
means
less
happy.
Users.
C
B
C
A
C
We
would
give
you
a
list
of
scan
types
and
every
item
on
that
list
would
be
the
actual
field
name,
we're
filtering
against,
and
the
second
one
would
be
the
actual
value.
So,
for
example,
if
you,
if
you
like
click
on
the
drop
down
there,
you
have
sas
and
you
have
code
review,
so
sast
would
be
report
type
fast
and
the
code
review
would
be
detection
method,
code,
review,
yeah,
and
this
can.
C
B
Like
we
do
with
the
project
filter,
the
project
filter
is
populated
by
the
back
end,
so
we
make
a
request
to
the
backend
and
then
retrieve
the
the
values
of
the
items.
That
could
be
a
solution
and
it
could
be
yes,
it's
much
better
than
doing
this
hard
code,
hardcoded
yep.
C
I
I
I
I
think
I
could.
I
think
I
can
do
that
work,
but
are
we
planning
to
get
these
filters
down
this
milestone.
A
So
the
work
as
we'd
broken
it
down
was
going
to
be
done
in
this
milestone,
but
I
do
believe
that
maybe
we
missed
some
work
when
we
broke
it
down.
I
know
that
we've
got
the
add
a
new
vulnerability
button
and
the
new
page
creation
or
the
page
to
create
it,
but
I
didn't
see
any
issues
and
savash.
You
can
tell
me
I'm
totally
wrong
about
this,
representing
filterwork.
B
Nope,
but
actually
was
thinking
it's
it's
it's
even
better.
If
I
do
it,
I
create
the
issue
because
this
way,
like
the
front-end
drives
the
request
and
the
back-end,
so
that
there
is
more
collaboration.
B
Exactly
exactly
this
is
always
the
best
scenario
for
for
front
and
back
and
collaboration.
So
I
I
I
can
do
it
happily
and
I
think
we
don't
have
an
issue
for
that.
Quincy
thanks.
A
D
It'd
be
kind
of
clunky
to
not
have
the
filter,
but
at
the
same
time
it's
probably
not
huge.
I
just
thought
of
something
savash
and
me
how
again?
This
is
a
terrible
idea.
Please
tell
me,
but
to
keep
at
least
in
the
very
short
term
if
it
simplifies
anything
since
you're,
basing
all
of
the
current
filters
off
of
the
report
type.
D
Could
you
just
have
a
single
new
entry
based
on
the
generic
report
type
that
just
says
manual
finding
incorporate
that
into
the
list
with
our
existing
scanners
and
then,
if
you
select
that
it
would
just
display
anything
if
it
was
code
review,
bug
bounty,
we
were
basically
we'd,
ignore
the
detection
method
as
a
first
pass,
and
then
we
could
work
to
break
that
out
separately
with
any
back
end.
Changes
in
a
future
iteration.
C
C
I
believe
we
currently
expose
the
generic
report
type,
so
you
may
want
to
you
might
want
to
like
verify
that,
but
I
think
we
basically
whenever
we
add
a
report
type,
we
expose
all
of
them
at
the
same.
At
that
point
I
mean
when
I
added
a
generic
report
type,
it
should
be
exposed
to
the
front
end,
I'm
not
sure
if
frontend
is
consuming
it,
but
I
think
it
should
show
up
in
the
list.
B
Yeah,
I
can
verify
it
later.
I
can't
say
it
by
heart:
right
now:
okay,.
D
B
D
B
All
right,
so
I'm
going
to
add
one
issue
and
then
drop
a
comment
there
somewhere
a
creative
thread
just
as
a
reminder
for
me
in
the
future
that
andy
will
take
a
look
at
the
design
and
if
there
is
this
code
review,
the
detections
method
will
be
included
in
the
filter.
Then
we
may
consume
this
from
the
back
end.
So
we
need
a
separate
issue
for
that.
So
just
as
a
reminder,
I'll
drop
a
note.
C
B
I
think
we
we
hard
code
them,
but
I'm
not
sure
if
we
hardcode
them.
It's
just
one-liner.
C
B
We're
pretty
good
sorry,
if
we're
not
hardcoding
them
it's,
then
it
should
be
a
one-liner
in
the
backend.
A
We're
pretty
far
over
the
end
of
our
call,
so
I'm
gonna
make
sure
that
this
recording
also
gets
added
to
the
issue
that
savash
creates
for
context
and
shared,
and
there
is
one
item
that
matt
added
just
to
look
at
async
before
the
next
call
for
a
future
planning
breakdown
around
our
jira
issue
integration.
D
Mostly
for
miho
and
tsubasa,
that's
when
I've
been
having
a
side,
slack
discussion,
mostly
with
me
how
on
and
a
little
bit
of
thiago
it's
a
customer
request.
So
it
was
something
we
were
going
to
see
if
we
could
get
the
quickest
thing
for
them
since
they're
on.com
and
they
they
can't
do
self-serve
database
query
things.