►
From YouTube: Threat Management Team: Office Hours
Description
Open office hours for topics related to Threat Management groups - Secure:Threat Insights & Protect:Container Security
B
Welcome
to
the
threat
management
bi-weekly
office
hours,
I'm
going
to
start
just
by
airing
something
that's
not
on
the
agenda.
Last
time
we
talked,
I
said
I
was
going
to
reschedule
this
to
buy
alternating
times.
That
would
be
more
convenient
for
amaya
and
apac.
I
have
not
done
that
yet.
I
will
do
that
after
this
call
apologies
out
of
last
week.
So
that's
an
action
item
on
me.
I'll,
add
it
on
here.
So
don't
wait
for
me.
Let's
get
started
with
the
first
item
in
the
agenda.
Philippe.
A
That's
me:
thank
you.
We're
going
to
have
15
minutes,
like
usual,
perfect.
A
All
right,
so
I
just
wanted
to
follow
up
on
the
last
discussions
that
we
had
a
couple
of
weeks
ago
about
inline
comments
between
albertans.
I
was
looking
for
the
issue,
so
there
it
is.
There
was
something
older
than
that,
but
I
couldn't
retrieve
it
for
some
reason.
So
this
is
the
the
main
issue
that
we
can
refer
to.
So
this
is
definitely
something
that
was
discussed
in
the
past.
D
C
So
our
so
how
many
viewers
can
can
see
it.
A
So
yeah,
the
idea
is
exactly
that.
I
and
that's
one
of
the
issues.
When
we
try
to
assess
the
nullability.
We
need
to
see
the
code
all
the
time
so
having
the
code
really
handy,
that's
something
that
will
serve
us
sometimes.
So
if,
when
we
click
on
the
vulnerability,
we
would
be
able
to
jump
directly
from
from
there
to
the
code
or
even
better.
A
But
instead
of
seeing
comments
from
the
reviewers,
you
would
see
directly
the
security
issues
in
the
code,
so
that
you
can
have
some
some
more
context
and
you
can
see
if,
for
example,
just
one
file
has
a
lot
of
findings
in
there,
then
you
can
say:
okay,
there
is
something
wrong
with
that
file.
We
need
to
do
something
either
it's
a
lot
of
first
positives
or
the
developer
completely
messed
up
with
the
changes.
B
Again,
I
don't
clearly
see
why
this
was
closed.
Back
then,
just
from
like
a
quick
glance,
but
hopefully
andy
still
has
some
recollection
of
it.
I
don't
know
about
how
you
want
to
proceed
with
that.
If
this
is
something
that
do,
we
have
a
new
issue,
or
is
your
suggestion
felipe
to
reopen
this
one
or.
A
F
F
Yeah
it's
a
year
and
a
half
old
looks
like
some
of
it
has
definitely
continued
to
carry
forward.
Obviously,
the
tab
security
report
for
the
mr
still
something
andy
is
looking
at
there's
a
whole
lot
more
stuff
in
here.
B
F
I'd
say
either
way:
selfishly
I
would
love
to
have
felipe,
create
an
issue.
F
A
A
We
open
a
new
tab
from
this
vulnerability
because
we
don't
want
to
reload
all
the
time,
the
dashboard
and
from
this
new
tab
we
open
a
new
tab
to
go
to
the
code
to
see
what's
what's
the
the
impact,
so
we
open
open
tab,
close
close
tab
and
it's
stacking
and
stacking
all
the
time.
It's
it's
not
super
tedious,
but
I
think
we
can
come
up
with
something
better
than
just
playing
with
tabs
all
the
time.
B
And
I
know
we
have
another
request
about
making
the
link
the
file
location
linkable,
so
you
don't
have
to
actually
copy
and
paste
and
go
there,
but
that
just
seems
like
it's
an
iterative
step
towards
having
the
code
closer
to
you.
Definitely
I
did
find
an
issue
that
was
called
inline
vulnerability
management.
Mvc.
That's
got
some
really
interesting
drawer
ideas
that
I
don't
know
if
that
would
apply
to
the.
B
A
All
right
next
point:
we
still
have
some
inconsistencies.
Inconsistent
still,
sorry
readout
promise
for
a
french
guy
in
the
data
reported
in
the
dashboard
sometimes
reported
as
detected,
and
you
can
see
that,
for
example,
in
the
screenshots.
A
To
is
that
something
that
I
can
share.
A
So
the
problem
is,
this
ability
is
detected,
the
status
is
detected
here,
but
actually
you
can
see
that
it
was
dismissed,
so
it's
either
detected
or
dismissed,
but
it
can
be
the
two
and
apparently
we
have
a
few
issues
like
this
other
some
vulnerabilities
like
this.
So
it's
really
hard
to
figure
out
what
is
the
real
status
of
or
a
security
posture
for
every
project.
F
F
Quite
all
right,
we,
this
is
what
happens
with
the
iteration
we've.
We
keep
finding
things
that
we're.
We
realize
that
the
yeah,
the
ability
of
the
tools
has
evolved
beyond
what
it
kind
of
started
with.
B
So
what
is
our
process
when
we
find
little?
I
would
hate
for
thiago
to
wait
or
sorry
for
fleet
to
wait
until
this
bi-weekly
to
bring
up
these.
You
know
individual,
like
data
issues,
but
you
know
asking
them
to
create
a
separate
issue
for
each
one
of
them.
I
mean
what
is
the
best
way
to
get
these
kind
of
things
troubleshoot?
Is
it
just
going
into
the
is
this
known
or
in
slack.
F
A
B
A
If
it's
blocking,
I
will
definitely
not
being
people
but
positive
breaking
in
your
channel,
okay
with
a
few
screenshots,
but
this
one
I
was
not
sure.
So
that's
why.
B
It
seemed
like
low
priority,
and
maybe
I
mean
if
you
see,
I
guess
the
bigger
thing
is.
If
you
see
something
more
than
you
know,
you
see
a
routine
or
a
pattern
like
those
are
definitely
things
that
we
need
to
make
sure
we're
aware
of
the
individual
ones.
I
know
we
need
to
do
some
data
integrity,
checking
and
some
triage
around
those,
but
hopefully
they're
more
likely,
one-offs.
A
A
Yeah,
that's
a
great
one,
this
one!
I
love
this
one.
So
one
of
the
main
issues
that
we
have
is
putting
together
the
workflow
between
the
vulnerabilities
and
issues.
Most
of
the
work
actually
happen
in
the
issue,
and
I
can
tell
you
for
sure
that
most
of
the
people,
including
the
appsec
engineers,
they
don't
have
the
reflex
to
update
back
to
vulnerability
once
the
issue
is
closed,
for
example
or
or
something
is
moving
in
the
issue,
and
that's
also
because
there
is
no
backlink
from
the
issue
to
the
vulnerability
itself.
A
B
Yeah,
I
know
someone
who
wrote
the
greatest
issue
about
this.
It's
such
a
really
easy
good
idea
that
needs
to
get
prioritized
around
this
and
we
create.
This
should
be
very
easy
for
us.
I
believe,
to
just
add
a
link
back
to
the
vulnerability
I
mean
without
doing
the
full
related
issues,
type
ui
treatment
if
it
was
just
part
of
the
description
of
the
issue
that
would
give
you
that
navigability,
back
and
I'll
go
find
that
issue
but
matt.
F
F
B
F
Then
I
guess
it
must
be
I'm
drawing
on
a
very
separate
conversation
that
has
nothing
to
do
with
this
meeting,
but
we've
been
doing
ux
interviews
with
the
aztec
team
and
watching
them
go
through
this
workflow.
I
saw
this
morning
doing
the
path
from
a
vulnerability
clicking
on
the
related
issue
and
then
in
the
related
issue.
There
was
a
line
at
the
top
that
said
from
vulnerability,
whatever
maybe
they're,
inserting
that
by
hand.
F
I
I
guess
so
let
me
look
at
I'm
going
to
share
something
in
the
chat.
This
is.
We
can't
share
it
on
the
video
if
we
want
to
keep
this
video
public,
but
if
everybody
would
like
to
go
look
at
this
one.
F
A
F
F
F
B
Tiago
just
brought
up
a
good
point
in
the
comments
of
this
issue
around.
We
could
be
using
our
special
reference
format
in
the
issue
description,
whereas
today
it's
a
link,
I
think
that's
what
you
were
trying
to
say
there
thiago
right
shout
out
to
consider
using
extensible
reference
for
vulnerabilities
in
the
description
as
a
first
iteration,
so
we're
not
even
first
iteration
anymore,
but
I
don't
know
if
that
would
be
a
future
hitter.
I
mean
it's
already
live
today
right.
It's
already
working.
C
B
And
that's
what
matt
was
just
looking
for
is
that
we
believe
there's
a
design
issue
around
the
actual
ui
box
around
that,
like
related
vulnerabilities,
but
this
link
is
already
currently
live
in
production.
This
is
already
getting
created
when
you
create
an
issue
off
a
vulnerability.
So
your
suggestion
around
using
the
extensible
references-
I
don't
know
if
that
would
be
a
second
iteration
or
improvement.
B
Necessary
based
on
the
fact
that
it's
a
pretty
clear
link
today,
it
doesn't
make
it
clear
to
you
that
it's
a
vulnerability,
a
standalone
vulnerability.
I
use
standalone
vulnerability
in
the
loosest
possible
term,
but
you
know
a
vulnerability
versus
another
issue.
I
think
it
actually
kind
of
looks
like
an
issue.
Let
me
go
back
to
the
tests
that
I
did
now
there's.
No,
it's
just
a
link.
It's
just
a
hyperlink,
hey,
dominic,
hello
speaking.
A
D
D
D
B
A
F
That
was
something
we
were
discussing
a
while
back.
Maybe
I
think
if
there
I've
heard
requests
for
let's
say
that
I've
got
a
bunch
of
dependencies
that
are
sorry
a
bunch
of
vulnerabilities
that
are
all
related
to
a
single
dependency
that
might
resolve.
Let's
say
10
vulnerabilities.
It
would
be
nice
to
grab
all
10
of
those
and
attach
them
to
one
issue
to
say:
go
upgrade
the
dependency
instead
of
making
10
separate
issues.
For
that.
So
I
think
that
was
kind
of
the
thinking
behind
allowing
multiple
vulnerabilities
to
be
related.
F
No
real
reverse
linking
from
the
issue
side.
The
issue
is
kind
of
blind
to
any
vulnerabilities
that
direction,
but
I
don't
see
why
we
wouldn't
allow
the
reverse
to
be
true.
One
issue
relating
back
to
multiple
vulnerabilities.
D
Step,
I
think
we
already
like
when
we
create
an
issue
from
the
the
report.
It
adds
a
link
automatically.
This
is
the
part
I
said
I
used
it
in
was
really
useful,
but
the
next
step
is
if
we
create
like
the
manual
entries
or
if
we
have
some
sort
of
import
process
for
the
hacker.
One
reports
like
we
have
linked
issues
linked,
merge
requests,
linked
vulnerabilities
would
be
great.
F
And
that's
actually
something
that
andy
and
I
are
working
on
in
these
designs-
that
we've
kind
of
we've
continued
to
reference,
this
sort
of
next
thinking
of
it
in
the
bulk
action.
So
right
now,
you
can
only
dismiss
as
a
bulk
action,
but
that
being
an
addition
where
you
could
actually
grab
a
bunch
of
different
vulnerabilities
and
say
link
to
a
single
issue
or
basically
create
an
issue
and
include
all
of
them.
So
it
would
be
a
much
more
straightforward
way
to
do
that
and
there's
not
really
one.
Today.
A
I'm
not
so
sure
I'm
not
sold
about
duplicating
the
the
data
from
the
vulnerability
directly
in
the
issue,
because
now
we
have
a
way
to
update
the
vulnerabilities,
but
it's
not
going
to
be
reflected
in
the
issue.
So
we
again
we
have
this
problem
of
on
one
side
with
the
vulnerability
with
some
data
we
have
the
issue
with
some
other
data.
The
studies
is
not
thinking
directly
so
at
best
we
can
synchronize
the
status
of
the
two.
A
But,
for
example,
if
we
change
the
severity,
it's
not
going
to
be
reflected
in
the
issue.
So
that's
that's
going
to
work
with
two
three
issues
or
two
or
three
variabilities,
but
if
we
need
to
scale
that
to
300
or
400
there's
no
way,
we
can
follow
everything
and
we
can
deal
with
that.
This
amount
of
data
I.
F
F
I'll
see
if
I
can
find
the
issue,
but
one
of
the
things
that
we
are
looking
to
re-do
with,
that
behavior
is
actually
taking
you
instead
to
a
pre-filled
issue
creation
template
so
that
it's
not
making
the
issue
right
away.
So
you
could.
It
would
start
with
the
copy
details,
but
just
like
you
would
make
you
know,
go
up
to
say,
file
new
issue.
You
could
edit
anything
that
you
wanted
in
there
and
then,
if
we
did
that
with
the
bulk
create
step,
we
would
probably
just
leave
it
more
like
a
blank
state.
F
I
think
that's
one
half
to
it.
I
think
the
other
half
is
doing
that
related
vulnerabilities
block
on
the
issue,
and
then
we
could
show,
I
think,
maybe
severity
is
actually
a
really
interesting
idea
to
show
there,
since
you
can
pull
in,
like
the
statuses
open,
closed
dynamically
for
related
issues,
and
mrs,
we
may
do
something
similar
like
for
the
vulnerabilities
potentially
show
status
and
severity
inside
there
and
then
that
way,
you're
not
cluttering
up
the
rest
of
the
issue.
With
that.
F
A
To
wrap
up
this
duplicating
the
data
as
one
advantage,
at
least
it's.
If
we
search
for
a
particular
cv,
we
will
find
the
issue,
but
we
will
never
find
the
vanilla,
because
it's
not
part
of
the
search
engine
in
gitlab,
so
at
least
we
would
be
able
to
retrieve
what
we're
looking
for,
but
that's
the
only
advantage
I
see
of
deeply
getting
the
data.
Otherwise,
it's
confusing.
B
A
B
F
E
F
So
I
actually
talked
to
mark
mcguire
about
this
months
ago
and
created
this
issue,
and
it
looks
like
they've
actually
picked
it
up
for
13.8,
at
least
that's
where
it's
currently
scheduled,
so
including
vulnerability
objects
in
the
global
search.
It'll
just
be
an
additional
tab,
so
fingers
crossed
we'll
we'll
get
something
for
for
free
in
terms
of
work
on
this
team,
it's.
F
E
A
C
Tick
off
the
bug
on
the
must
have
the
first
one
it
says
closed,
and
I
noticed
under
should
have
the
second
item
that
the
extensible
vulnerability
reference
is
now
turned
on.
So
it's
rendering,
as
with
the
markdown
with
the.
C
Do
you
see
that
the
last
bit
under
should
have
second
item?
The
last
link
says:
has
more
data
than
vulnerability
that
that's
the
new
extensible
reference
format
it's
turned
on.
C
E
B
So
I
wanted
to
bring
up
under
your
must-haves
the
second
item,
the
manually
group,
multiple
vulnerabilities
into
one.
I
mean
there's
not
been
activity
on
that
in
two
months
and
it's
sitting
in
design
assigned
to
not
andy.
So
I'm
just
curious.
If
that's
a
must
have
met.
I
don't
think
this
is
I
mean
it's
it's
in
the
backlog
too.
So
there
may
need
to.
B
F
It's
still,
I
think
the
intent
is
still
very
relevant.
The
design
direction
is
not,
but
it's
the
best
placeholder
that
I've
got
to
reference
back
to
that
right
now
until
andy,
and
I
complete
the
sort
of
next
vision
for
the
vulnerability
report
interface
and
then
we'll
do
a
solution.
Validation
with
philippe
you
dominic
and
a
lot
of
the
apsec
team.
A
That
could
be
solved
directly
if
we
have
this
ability
to
link
multiple
general
abilities
into
one
issue.
In
this
case,
we
don't
need
to
group
them
anymore.
That
would
be
even
better
if,
when
I
close
the
issue,
it's
going
to
the
right.
D
D
But
if
I
link
like
I
have
two,
we
have
the
scenario
right
now:
250
vulnerabilities
in
vue.js
templates-
if
I
can
grab
all
of
them
and
link
them
to
a
single
issue.
This
is
great,
but
the
next
time
I
have
to
act
on
the
issues
in
the
dashboard
I'll
have
to
select
those
250
issues
again
to
close
them
to
mark
it
as
results,
because
it's
not
automatic
when
the
issues
are
closed
and
like
any.
E
D
D
More,
there
are
many
things
that
if
we
get
one
of
those
a
bunch
of
other
things
lower
in
priority,
because
the
task
becomes
easier
like
if
we
have
strong
filtering
and
selection,
I
can
basically
filter
by
whatever
and
select
what
is
on
my
screen.
This
makes
all
the
tasks
easier,
so
so,
basically,
like
yeah,
if
x
happens,
maybe
y
lowers
in
priority.
B
And
I
didn't
mean
to
derail
the
conversation.
I
just
realized
that
this
issue
is
it's
not
these
aren't
things
that
must
happen.
You
must
have
in
q4.
This
is
a
rolling
list.
That's
come
from
previous
quarters
and
the
expectation
isn't
that
the
must-haves
will
be
done
at
the
end
of
january,
because
I
was
like
I
don't
know
any
of
these
top
20
items
are
going.
F
Yeah
so,
and
just
to
add
one
more
thing
with
manually
grouping
vulnerabilities
is
sort
of
a
solution,
and
that
was
an
initial
stab
at
the
problem
that
I
think
dominic
you
articulated
much
better.
Is
you
just
need
a
way
to
very
quickly
narrow
your
scope
of
work
to
a
specific
set
of
vulnerabilities
and
it
needs
to
be
fast
and
repeatable.
D
F
Grouping
was
our
initial
solution
for
that
we
have
things
that
are
very
group
like
it
is
closer
to
your
sort
of
filtering
saved
views
of
things,
we're
hoping
we
don't
have
all
that
much
time
before
the
end
of
the
year,
so
it
may
end
up
rolling
at
the
very
beginning
of
next
year,
but
when
we
do
the
solution,
validation,
walkthroughs
with
yourself
from
the
other
appsec
engineers,
that's
a
major
point
of
focus.
We
want
to
validate
that.
D
I
know
I
don't
know
which
team
is
working
on
that,
but
around
dast
findings.
We
found
that
many
of
the
like
it's
not
worth
reporting
bad
csp
on
a
thousand
different
urls.
It
should
be
one
finding-
and
I
know,
they're
working
on
grouping
all
noisy
findings
into
one.
But
I
don't
know
if
it's
the
task
that
will
only
have
one
report
or
if
it's
the
dashboard,
that
will
group.
B
Cool
philippian
number
six
is
kind
of
a
it's
a
it's
a
hot
topic
right
now,
so
we've
been
working
on
improving
this
scanner
filter
for
some
time.
We
just
had
a
big
conversation
with
danielle
and
matt
and
andy
and
young
and
myself
about
this
yesterday.
It
would
help
to
have
a
distribution.
Oh
so
you'd
you'd
like
to
see
numbers
there,
sort
of
like.
A
A
When
we
have
hundreds
of
results
in
the
dashboard-
and
I
want
to
see
if
there's
anything
related,
I
I
want
to
see
where
they
are
coming
from
so
every
time
I
have
to
click
on
every
single
scanner
to
see,
if
there's
something
related
to
that
or
not
that
could
save
us
some
time
to
have
just
just
a
few
numbers.
Next
to
the
scanners.
There.
F
F
I
think
maybe
the
issue
was
so
philippe
now
that
we
have
multiple
different
filters.
Let's
say
that
das
shows
a
thousand
with
the
currently
selected
statuses
that
you've
got
and
severities,
but,
as
you
start
to
filter
down
by
different
different
statuses
or
different
states
and
different
severities,
would
you
expect
the
number
to
dynamically
change
next
to
das
to
reflect?
What's
there?
I
think
that's
where
we
got
kind
of
hung
up
and
we
ended
up
not
proceeding
with
it
at
the
time
we
kind
of
put
a
pause
on
that.
E
Point
yes,
I
would
expect
that
to.
F
And
then
I
think
I
feel
like
it
was
just
a
concern
about
performance
having
to
go
and
actually
do
the
calculation
and
the
pre-fetch
of
that
as
soon
as
you've
changed
the
filter.
You'd
have
to
go
grab
everything
I
have
this
vague
recollection
of
it
doesn't
make
the
call
to
the
back
end
to
refresh
the
view
until
you've
selected
the
filter.
So
how
would
you
display
the
count
in
the
filter
before
you've
asked
it
to
go
refresh
the
view.
F
Yeah
I
feel
like
we
went
down
that
path,
but
no
it's
a
fair
point
that
it's
still
a
nice
to
have.
F
B
Either
any
of
these
things
ringing
any
bells,
they
are
totally
ringing
bells.
I
feel
like
it
was
in
scope
for
some
of
the
filter
work
that
we
did
on
the
earlier,
but
I
can
confirm
this
and
go
back
and
look
at
the
early,
the
mvc
for
the
dashboard
redesign
and
some
of
the
filter
changes
we
made
at
that
time.
I
don't
think
it
was
part
of
the
most
recent
report.
B
Type
filter,
work
that
daniel's
been
working
on,
so
I
think
it
was
d
scoped
from
that
initial
dashboard
redesign,
but
that
doesn't
mean
there's
not
still
value
on
it
and
if
we
were
to
approach
it
as
like
a
standalone
feature
enhancement,
you
know,
I
think
we
we
maybe
d
scoped
it,
because
the
effort
was
so
high
and
we
wanted
to
get
that.
Mvc
and
they've
lost
it.
You
know
I've
just
searched
around
and
I'm
pretty
confident
we
don't
have
an
issue.
That's
representing
this
right
now.
B
B
A
D
Yeah
kind
of
I
think
yours
is
a
bit
different
ish,
I
mean
same
result,
but.
D
D
A
D
D
C
So
I
don't
know
how
much
of
a
corner
case
it
is.
But
it's
I
didn't
know,
but
it
sounds
like
it's
that
there
might
be
real
user
customer
facing
benefit
from
having
an
advanced
sort
of
filters.
Cleanup.
A
F
F
Given
our
really
course
permission
sets
like
on
gitlab.com
or,
if
you're
a
self
manager,
it
would
make
sense
to
allow
that
only
for
the
owner
role
or
something
like
that.
But,
as
felipe
said,
if
you're
a
gitlab.com
customer,
that's
not
available
to
you,
so
you
can't
use
that
option.
Maintainer
feels
far
too
broad
to
be
able
to
allow
people
to
just
delete
the
vulnerability
records.
F
E
A
But
if
you
create
the
emergency
quest
and
and
you
see
that
the
problem
is
in
this
project,
that
was
super
fun
because
the
the
ci
configuration
was
not
really
steady.
So
if
you
were
in
the
branch
there
was
some
jobs
running.
If
you
are
in
master,
some
other
jobs
are
running,
so
it's
not
super
stable
and
we
didn't
see
in
the
merge
request
where
we
were
enabling
secret
detection,
for
example,
that
we
would
create
250
new
findings,
but
it
should
be
there
in
the
merge
request.
A
If
the
project
was
configured
correctly,
I
would
spot
directly
or
there
are
250
new
findings.
I
heard
something
wrong:
there's
no
way
we
could
have
so
many
secrets
in
this
project,
but
here,
in
this
case
the
emergency
quest
was
super
clean.
There
was
nothing,
everything
was
green,
so
when
we
merged
it's
random
master,
the
cache
was
running
a
bit
differently.
The
configuration
was
different
and
boom.
So
then
babe
we
have
these
250
new
findings
so
yeah
we
could
just
filter
them
out
and
and
dismiss
them
in
the
ui.
A
But
if
you're
thinking
of
the
the
github
project,
for
example,
I'm
not
going
to
share
too
many
details
here,
but
we
have
way
more
than
ten
thousand
findings
that
are
completely
not
going
to
be
used.
They
are
probably
first
positive,
we're
not
going
to
do
anything
with
them.
I
would
I'd
rather
not
dismiss
them,
because
once
we
will
have
a
search
in
place,
they
will
show
up
all
the
time
probably,
and
we
will
have
a
very
hard
time
to
find
something
in
the
dismissed.
F
Well,
I
wonder
if,
in
that
case,
philippe
it'll
help
some
too,
when
we
add
additional
statuses
for
dismissals,
there's
a
an
issue
to
extend
what
we've
got
today,
because
I
think
it
just
won't
fix
false
positive
but
we're
adding
in
two
or
three
other
states
so
that
you
can
more
accurately
like.
Is
it
a
test
case?
Is
it
a
you
know?
Are
we
just
we
it's
it's
a
true
positive,
we're
just
accepting
the
risk
and
we're
going
to
leave
it
there.
So
I.
D
Had
a
new,
a
new
type
of
dismissal,
I
didn't
I
wanted
to
find
the
issue,
but
I
didn't
find
it
the
other
day.
I
should
look
harder:
okay,
basically
something
that
is
marked
as
resolved
by
the
scanner
before
I've
even
looked
at
it.
So
now
like.
If
I
change
the
status
to
resolve,
I
mean:
maybe
I've
never
even
seen
the
bug,
so
I
I
kind
of
don't
want
to
commit
my
name
to
yes.
This
is
resolved
more
like
abandoned
ship.
It
was
the
the
the
status
I'm
looking
for
just
it
appeared
it's
already
solved.
D
F
C
Those
similar
it's
similar
use
case
that
came
up
with
the
alerts
for
container
security,
the
current
the
current
alerts
from
operations
they
they
have
four
status,
they
have
triggered
acknowledged,
resolved
and
ignored,
and
in
container
security
we
have
equivalent
for
all
of
those
with
with
different
names,
but
there's
one
extra,
which
is
confirmed.
D
The
ignored
that
I
think
you're
missing
would
fit
here.
We
have
business,
I
don't
know
it's,
I
guess
I
could
dismiss
it,
but
I
need.
C
Yeah
funny
enough
just
to
simplify
the
mvc
on
container
security,
we
mapping
statuses
on
to
existing
ones
before
we
can
implement
our
own
so
trigger
this
is
called
unreviewed
acknowledged.
It's
called
in
review
resolved
is
called
resolved.
We
don't
have
one
for
confirmed
and
ignored
is
called
dismissed.
C
D
Well,
I
mean
there's
an
issue
for
automatically
marking
as
resolved
and
there's
some
discussion
that
we
might
want
to
manually
review
the
solutions
and
everything.
I
think
this
is
a
legitimate
use
case
that
we
don't
necessarily
want
to
close
everything,
but
an
issue
that
we
never
acknowledge.
We
never
touched,
never
touch
the
status,
no
comment,
no,
nothing.
If
it's
marked
as
results
and
just
clean
it
up,
I
think.
C
E
D
D
B
Great
and
dominic
you
missed
this,
I'm
going
to
be
rescheduling
this
at
a
time
that
we'll
be
a
little
we'll
do
an
apec
and
an
emma
friendly
one
every
other
week.
So
one
one
one
occurrence
every
other
week
won't
work
for
you
in
your
time
zone.
I
imagine
it'll
be
too
late,
but
hopefully
the
other
one
will
be
a
little
earlier.
Maybe
the
sun
will
still
be
up
in
the
background.
E
B
All
right
was
there
anything
shared
today
that
should
keep
us
from
making
this
video
public.
I
think
we've
caught
ourselves
in
cases
where
we
are
going
to
share
information
about
a
customer
or
vulnerability
nope.
B
Think
so
I'm
gonna
go
ahead
and
share
this
in
youtube
and
I
will
put
the
link
in
the
threat
management
room.
So
thanks.
Everybody.