►
From YouTube: Secure:Threat Insights group discussion 2021-04-06
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Cool
all
right
thanks,
everyone
for
joining
lindsey
is
still
out
on
pto.
So
I
guess
I
will
be
the
embassy
for
this
team
meeting
this
week.
So
let's
see
started
at
the
top
here,
it
doesn't
look
like
we
have
any
follow-ups
from
previous
discussions.
A
Looks
like
not,
and
I
see
savash
it
looks
like
you
were
the
only
one
that
put
something
under
the
demo
side,
but
it's
a
refactor.
Nothing
visual
is
that
yeah
still
the
case
yeah
it's
a
little
case,
exactly
cool
anybody
else
before
we
hop
down
into
the
planning
breakdown.
A
A
It's
almost
a
year
ago
on
feedback
on
the
mr.
The
code
quality
team
did
something
very
similar
in
fixing
their
diff
inside
the
mr,
and
this
is
us
sort
of
taking
what
that
team
did
and
bringing
it
over
for
the
security
widget.
B
C
A
Yeah,
I
think
they
kind
of
are-
I
don't
think,
yeah
savash
on
this
one
there's
going
to
be
really
anything
different
in
the
ui.
This
is
just
going
to
be
what
we're
servicing
in
terms
of
the
diff
for
the
mr
security
widget.
A
I
think
for
this
one
whoever
looks
at
this
one
and
does
the
planning
breakdown
is
probably
worth
reaching
out
to
make
sure
it
is
linked
in
here
yeah,
so
the
the
code
quality
group
who
basically
did
the
pattern?
I
think
that
it
looks
like
we
want
to
follow
for
the
diff
on
this
one.
D
A
A
Yeah
see,
I
think
these
are
the
mrs
that
were
from
the
code
quality
team
that
are
related
to
this.
It's
I'm
not
even
going
to
attempt
to
explain
what
it
is,
because
I
can't,
but
it
was.
I
think
it
was
trying
to
do
a
smarter
version
of
looking
at
the.
A
G
I
think
I
mean
correct
me
if
I'm
wrong,
but
my
basic
understanding
of
this
thing
is
it's
like
it's
fairly
simple
words.
Like
you
said
it's
just.
Instead
of
diffing
off
the
current
we'd
have
to
diff
off
of
whatever
the
merge
base,
but
would
that
mean
that
we
would
have
to
run
two
vulnerability
reports,
one
off
the
merge
base
and
one
off
of
the
the
the
merge
request.
G
A
Itself,
yeah.
I
need
to
make
sure
that
the
right
stuff
is
linked.
It
looks
like
the
mrs
are
linked,
but
oh
no,
okay,
so
it
is
it's
just
not
oh
cause.
It's
an
epic
and
you
can't
link
epics
okay,
so
this
is
where
basically,
it
came
from.
So
this
is
what
chaga
was
pointing
to
that
this
was,
I
think,
the
relevant
comment
that
showed
what
the
update
was
actually
going
to
do.
A
Well,
we
can
always
answer
questions
in
the
issue
on
that
one,
I
will
say
it
looks
like
this
is
something
that's
getting
a
little
bit
more
attention
from
outside
of
our
group
as
well,
just
because
this
was
a
an
effort
to
clean
up
a
lot
of
things
in
the
mr
for
consistency
and
kind
of
kick
this
one
down
the
road
for
a
little
while.
But
I
think
some
of
the
recent
focus
on
sas
and
sus
and
all
the
other
acronyms
are
putting
a
little
bit
more
attention
this
one.
A
So
I've
got
it
in
1312
and
it
would
be
a
nice
one
to
see
if
we
can't
keep.
If
we
need
to
kick
some
stuff
out
to
to
keep
it
at
13
12.,
it
could
be
a
good
one
unless
it's
gigantic,
which
I'm
hoping
it's.
A
Actually,
I
think
we
can
skip
look
at
this
one
now,
so
this
one
to
me
seemed
like
it
actually
might
be
very
similar
or
might
even
end
up
being
the
same
thing
so
after
the
first
one,
it
would
probably
be
good
to
take
a
peek
at
the
second
one
to
see
if
it
seems
like
that's
actually
a
duplicate
that
we
can
close
it
out.
E
The
resulting
masters
wait
that's
five
miles
ago.
I
am
not
sure.
E
E
A
E
E
So
there
is,
there
will
be
an
issue
to
get
rid
of
those
as
well,
but
at
least
from
march
we
shouldn't
have
any
duplicate
vulnerabilities
in
the
database.
E
It's
technically
almost
impossible
for
them
to
get
into
the
database
behalf,
because
we
have
a
unique
unique
index
on
duid
and
the
uid
comes
from
the
location
and
identifier.
Partly
there
is
a.
They
are
also
scoped
to
a
project.
E
A
A
So
if
I
was
expecting,
let's
say
the
gitlab
sas
analyzer
and
an
integrated
third
party
to
find
the
same
thing,
if
I'm
in
the
vulnerability
report
for
that
project,
am
I
only
going
to
see
one
analyzer,
that's
made
that
detection
and
how
do
we
make
sure
that
it's
consistent
every
time
I
run
those
two
analyzers
that
we're
not
you
know
flipping,
which
one
is
the.
I
guess
the
persisted
record
for
the
duplicate.
E
I'm
not
sure
if
that's
going
to
happen,
but
my
guess
is
that
whichever
report
is
being
parsed
first
will
be
persisted.
So
let's
say:
if
you
run
the
ast
and
saskat
says
scanner
at
the
same
time,
and
whichever
ends
up
being
paused
first
will
be
the
one
that's
persisted.
E
F
E
Duplication
takes
part
in
two
places.
The
first
one
is
store
report
service,
which
basically
compares
the
findings
within
one
report
and
sees
if
there
aren't
any
duplicates.
If
yes,
then
it
merges
them.
Obviously,
but
the
store
report
service
doesn't
discover,
duplicates
from
other
reports
in
the
same
pipeline
and
that's
when
the
database
uid
index
comes
in.
So
if,
if
you
have
like
two
separate
reports
and
two
of
them
have
the
same
vulnerability
but
coming
from
different
scanners,
only
one
of
them
is
going
to
get
inserted.
The
other
one
will
get
discarded.
G
G
B
E
E
Only
one
of
them
is
going
to
show
up
because
we
parse
the
reports
before
presenting
the
vulnerability
list
to
the
user,
so
you're
going
to
get
only
one
scanner
showing
up
the
vulnerability
in
the
report.
Gotcha.
A
That
may
just
be
something
at
least
for
now,
if
that's
not
in
the
documentation,
we
may
need
to
just
make
a
note
about
that
that
we're
only
showing
you
one
instance
of
the
something
but
okay
yeah.
I
don't
want
to
keep
going
down
this
path
too
much
more.
It
seems
like.
I
don't
think
that
it's
a
super
common
case
either.
A
I
think
people
typically
are
using
an
existing
third-party
scanner
that
they've
already
got
internally
and
you
know
they're
paying
for
or
they're
moving
over
to
the
gitlab
scanners,
for
you
know
same
type,
so,
okay,
so
all
that
said
this
may
actually
not
be
an
issue
anymore,
because
it's
looking
like,
I
think,
most
of
the
conversation
was
quite
a
bit
old
and
then
was
sort
of
between
us
sounds
like
investigation
first,
just
to
see
if
it's
actually
something
that's
still
going
on,
and
this
may
be
a
non-issue.
G
Which
would
be
cool
real,
quick?
I
just
want
to
clarify
something
so
it
the
report.
So
in
the
pipeline
tab
the
will
there
be
duplicate
vulnerabilities
me
how
in
the
pipeline.
G
G
G
E
Will
create,
we
will
create
feedback
for
that
and,
if
you
try
to
show,
if
you,
if
you
like,
try
to
refresh
the
security
widget
on
the
pipeline,
it's
going
to
basically
look
up
any
feedbacks
for
the
for
for
the
findings
and
like
shown
them
as
cross,
crossed
out
when,
when
there's
a
feedback
for
them
that
dismisses
them.
So
I
I
think
I
think
that
by
the
time
we
present
the
user
the
vulnerability
list
on
the
pipeline
widget,
we
already
parsed
the
report.
A
G
All
right,
I
can
give
a
quick
rundown
of
this
one,
so
the
issue
came
in
saying
that
vulnerabilities
were
not
stored
in
the
report
until
after
the
pipeline
was
completed,
even
though
they
had
like
a
they
had
a
manual
step
that
they
wanted.
They
basically
wanted
the
vulnerability
stored
in
the
report
before
the
pipeline's
completed
because
they
had
a
manual
step
in
there.
Sebastian
made
a
change.
I
looked
at
it.
G
Maybe
we
don't
want
this
at
all
to
to
force
it
to
store
the
reports
before
the
pipeline's
complete
there,
because
this
is
one
use
case,
like
the
users
have
a
very
specific
use
case
where
they
want
the
report
stored
because
they're
about
to
deploy
it,
where
it
could
be
that
in
any
number
of
things
where
the
vulnerabilities,
the
security
reports
run,
there's
a
manual
step
where
they
want
to
like
look
over
the
vulnerabilities
and
then
run
it
again.
G
This
is
you
know
this.
One
is
a
very
specific
one
to
their
use
case
and
to
force
this
use
case
on
all
users.
It
does
kind
of
break
what
we
have
with
all
of
our
other
pipelines,
where
we
don't
actually
store
anything
in
the
report
until
the
pipeline
is
complete,
which
kind
of
breaks
a
consistency
that
we
have,
and
I
think
one
of
our
values.
What
convention
over
configuration.
A
Yeah
there
was
so
I
was
actually
halfway
through
typing
a
comment
on
the
end
of
this
when
we
started
the
meeting
thomas
made
a
really
interesting
point
about
a
year
ago
in
one
of
the
linked
issues.
A
A
The
report
goes,
yep
vulnerabilities
are
not
there
marks
them
as
resolved,
but
then
the
build
actually
fails
because
something
about
the
new
dependency
doesn't
work
right.
I
remove
it
now
I'm
going
to
get
new
vulnerabilities
where
I
had
them
before.
So
I
think
it's
I
don't
want
to
say
it's
necessarily
dangerous,
but
it's
certainly
confusing
so
yeah.
I
like
I
agree,
jonathan,
I'm
wondering,
and
this
may
not
be
how
this
works
at
all.
I
saw
you
know.
We
have
all
these
suggestions
down
here.
Is
there
a
way
to
in
the
manual
step?
A
G
Yeah,
and
did
I.
G
That's
what
that's,
what
we
were
kind
of
talking
about
yesterday
is
like
have
a
flag
being
have
a
state,
something
in
the
stage
where
okay
store
off
the
report.
If
they
want
to
do
it.
That
way,
I
mean
I,
I
think
that
that
does
get
to
that's
that,
like
I
mentioned,
you
know
when
we
have
a
failed
pipeline
and
we
have
these.
G
These
vulnerability
reports
stored
on
a
failed
pipeline,
which
is
it
can
cause
other
issues,
and
then
they
yell
at
us,
because
they
get
that,
because
we
have
other
vulnerabilities
that
weren't
expected
but
yeah
to
have
a
stage
to
have
a
flag
or
something.
It
would
probably
be
the
best
way
to
go
on
this,
but
I
do
I
don't.
I
really
don't
think
we
should
change
the
default
behavior.
D
G
A
I
appreciate
you
guys
kind
of
realizing
what
this
was
gonna.
Do
I'm
sorry,
the
work
got
all
the
way
down
the
route,
but
I
think
it
was
definitely
the
right
thing
to
raise
the
attention
on
this
and
pull
out
the
change,
because
understanding
is
more.
I
agree
like
what
the
user
is
asking
for
is
not
what
I
think
most
people
would
expect.
A
I
would
almost
venture
to
say
that
their
process
is
maybe
not
the
best
practice
in
this
case,
because
they're,
allowing
all
these
things
to
keep
going
through
and
they're
waiting
until
just
before
production
deployment,
to
do
an
audit
against
things
that
are
already
in
the
default
branch,
which
seems
not
the
right
place
to
do
that
so
yeah.
This
has
to
be
something
you
would
have
to
very
specifically
configure
in.
G
To
me,
yeah,
like
I
said
it
to
me,
it
seems
like
a
workflow
preference
issue,
workflow
issue
where
having
the
pipelines
run,
complete,
store
the
vulnerabilities
and
then
have
a
separate
pipeline.
If
they
want
to
deploy
it
separately,
might
be
the
best
solution
for
them,
but
yeah.
That's
I'm.
On
the
same
page,
though,.
A
G
G
A
Now
that
was
missing
at
the
time
when
we
went
to
the
standalone
vulnerabilities
model,
so
I
think
that
would
make
more
sense.
I
just
wanted
to
be
sure
so,
for
I
respond
back
to
that
customer
on
that
opened
the
defect
to
say:
look.
This
is
not
what
it
does
today,
we've
kind
of
explained
why
we
don't
feel
this
is
a
bug.
This
is
what
we
were
thinking
for
a
new
feature.
You
know
some
kind
of
configuration
that
you
could
set
and
it
would
have
to
come.
G
Yeah
yeah,
so
when
they
were
asking
for
behaves
similarly
to
failed
pipelines,
it
does
and
that
that
issue
does
not
indicate
that
there
was
ever
anything
that
was
actually
done
to
to
change
that
behavior
gotcha.
A
Yeah,
so
I
feel
like
maybe
he
was
referencing
this
thinking,
that
the
failed
pipelines
were
still
merging
the
results
which
would
imply
that
you
don't
have
to
have
a
successful
pipeline
for
that
to
happen
and
that's
what
he
wants,
but
that's
not
actually
the
case.
That's
what
I
wanted
to
confirm:
yeah,
okay,
cool!
Well,
we
are
out
of
time
that
was
a
lot
of
stuff
we
went
through
this.
One
is
something
I
think
we
can
do
async
it's
really
only
the
first
one
to
look
through
savasha.
A
It's
probably
going
to
be
of
interest
to
you
because
there's
a
lot
of
front
end
on
that
one
and
parent
epic,
just
for
reference.
If
anybody
wants
to
start
putting
stuff
in
there,
we've
got
it
for
the
eventual
implementation
plan,
yeah
cool
anything
else
before
we
close
out
good
all
right,
awesome
thanks.
Everybody
have
a
wonderful
rest
of
your
day.
Bye.