►
From YouTube: Threat Management Team: Office Hours
Description
Open office hours for topics related to Threat Management groups - Secure:Threat Insights & Protect:Container Security
A
Welcome
to
the
threat
management
office
hours,
we're
gonna
quickly
summarize
what
the
original
question
was
alexander.
Can
you
restate
your
question
for
the
video.
B
C
Sure
so
alexander
was
asking
about
having
vulnerabilities
created
from
like
potentially
from
alerts
and
then
also
how
that
could
fit
in
with
some
of
the
policy
management
stuff
and
from
I
think,
I'm
a
little
less
clear
about
alerts.
I
think
sam
and
I've
kind
of
talked
about
this,
but
that's
more
stuff,
that's
happening
in
production.
On
the
infrastructure
side,
it
may
make
sense
to
convert
some
alerts
into
a
vulnerability
if
it's
something
for
like
an
internal
team
to
address
or
patch
something.
C
I
see
a
more
a
stronger
use
case
for
the
policy
piece
which
I
think
sam
is
about
to
give
us
a
demo
of
and
it'll
make
a
little
bit
more
sense
when
you
see
it,
but
because
it's
sort
of
a
generalized
rules
builder,
I
think
it
would
be
great
for
setting
up
things
like,
for
example,
today
we've
got
the
vulnerability
check
rule
or
the
security
approval
gate.
Whatever
you
want
to
call
it,
it's
kind
of
just
a
one
or
a
zero.
It's
on
or
it's
off.
C
If
it's
on
it
enforces
any
critical,
high
or
unknown
vulnerabilities
are
blocked
from
being
merged
without
an
approval.
That's
great,
but
it's
not
really
flexible
right
like
what.
If
for
a
particular
project,
I
only
care
about
criticals
what,
if
I
don't
care
about
hives
from
a
particular
scanner
that
I
know
is
noisy
right
so
using
something
like
what
sam's
got
with
a
policy
builder,
you
could
construct
those
very
specific
kind
of,
I
guess
logic
rules
and
use
those
to
enforce
different
things
for
like
the
vulnerability
management
workflows.
C
D
There
we
go
is
that
better,
so
we
don't
have
everything
that
matt
talked
about
in
this
prototype,
but
we
do
have
some
things.
So
we
created
this
new
vulnerability
management
policy
type
and
that
lets
you
write
some
rules
around
some
of
the
actions
that
users
can
take.
So
if
you
want
to
actually
prevent
users
from
ever
dismissing
vulnerabilities,
you
can
do
that.
You
could
potentially
extend
this
out
to
add
some
additional
criteria
or
have
this
say
you
know,
allow
the
action
but
require
a
comment.
D
You
could
also
write
some
rules
around
when
vulnerabilities
change
severity
so
that
you
could
either
allow
or
prevent
users
from
changing
that
severity
or
provide
a
comment
if
they
decided
to
upgrade
or
downgrade
the
severity
of
vulnerability.
So
we
don't
have
like.
I
said
we
don't
have
everything
that
matt
talked
about.
I
think
some
of
that
other
stuff
would
probably
come
in
your
scan
results
policy
where
you
say
you
know,
if
you
know
dependency
scanning
finds
one
or
more
critical
vulnerabilities.
D
You
might
have
an
action
down
here
that
says
you
know,
ignore
that.
Don't
generate
the
vulnerability.
Just
you
know
we,
don't
we
don't
really
care
about.
You
know
whatever
this
may
be
so
this.
If
this,
then
that
logic
is
definitely
highly
extensible,
so
we
can
have
that
flexibility
to
adjust
this
as
needed,
depending
on
our
users
needs
in
the
future.
B
C
For
instance,
that
says
dismissals
require
an
approval
before
I
do
that,
if
that's
on
a
vulnerability
report
like
project
level
thing,
why
would
I
put
that
at
a
yaml
file
right?
I
should
be
able
to
turn
that
on
and
off
without
triggering
a
pipeline,
so
quite
a
ways
out,
but
I
think
that's
a
really
really
good
direction
to
sort
of
point
at
so
that
comes
up
in
the
future.
E
I
have
a
minor
remark
or
question
that
would
be
super
useful
to
me
personally
in
the
sec,
auto
team,
and
is
that
and
also
as
former
part
of
the
security
operations
team,
we
sometimes
had
issues
that
were
high
crit
that
were
critical
or
high
priority
that
would
be
cycled
between
faces
or
the
severity
would
be
changed
and
it
nests.
It
wasn't
necessarily
appropriate,
probably
someone
that
was
a
bit
tired,
changed.
E
It
sculpt
it
down
whatever,
but
is
this
also
intended
to
work
with
labels
so
that
you
sort
of
build
your
own
home
brewed
version
of
the
artifact
that
you
are
having,
so
you
have
vulnerabilities,
you
have
scanned
results
from
those
vulnerabilities
from
those
countries
or
results,
but
is
there
also
a
plan
to
use
the
normal
labels
defined
per
project
or
labels
that
are
scoped
can't
be
changed?
If,
then
else?
E
What
are
your
thoughts
because
for
me
it
would
have
been
useful
to
say
if
a
issue
type
label
or
incident
type
label
is
high
or
critical.
It
cannot
be
marked
done
unless
you
whatever
or
you
cannot
be
scope
or
change
the
priority
of
an
incident
label
issue
once
it
has
been
set.
If
then
blah
things
like
that,
but
sort
of
more
like
oriented
to
label.
C
I
don't
know
sam
if
you
had
any
plans
on
the
label
side
I'll
say
at
least
from
the
vulnerability
object
side
right
now.
We've
purposely
avoided
adding
labels
just
because
we
want
to
make
sure
that
vulnerabilities
are
really
for
just
sort
of
the
triage
and
understanding
what
the
specific
problem
is.
And
then
you
create
issues
in
mrs
from
that
and
attach
it
to
do
the
actual
sort
of
like
workflow
and
follow-up
pieces,
so
I'll
say
no,
not
in
the
near
future
for
the
vulnerability
side
but
yeah.
I
don't
know
about
sam
labels.
D
D
Das
scheduled
scan
policies
so
we're
starting
with
like
a
super,
narrow
slice
and
like
we
have
a
long
ways
to
go
before
we
even
start
approaching
vulnerability
management
type
policies,
so
it
the
the
editor
is
definitely
flexible
enough
to
allow
what
you're
describing
it's
just
not
any
time
on
the
near
term.
Right
now,.
C
E
Yeah
so
at
least
the
way
we
use
them
in
the
team
and
as
far
as
I've
seen
in
the
security
team
is
pretty
much
only
we
set
the
label.
So
there
are
no
external
team
members
like
yeah
from
other
teams,
other
departments
that
touch
our
labels,
but
sadly,
due
to
the
way
the
gitlab
org
git
labcom
hierarchy
is
structured.
E
Many
could
because
the
the
maintainer
permissions
sort
of
trickle
down-
and
there
are
people
outside
of
the
security
team
and
the
security
department
and
the
sec
auto
team
that
have
maintainer
permissions
in
our
groups
and
projects,
so
they
could
change.
They
could
make
an
issue
that
is
a
critical
make
it
a
low
and
if
you're
not
paying
attention,
it's
now
a
low,
and
we
don't
work
on
that.
So
we
aren't
as
big
so
that
as
to
make
it
possible
that
does
so.
E
That
sort
of
thing
gets
lost
in
the
noise,
but
abstracting
away
a
bit.
It
could
happen
yeah.
So
that's
that's
why
I
mentioned
because
one
of
one
of
the
concerns
I
remember
I
was
I
used
to
discuss
with
people
was
okay.
How
can
we
guarantee
that
the
priorities
of
issues
is
not
changed,
that
there's
a
paper
trail
that
we
can
react
to
it
so
yeah?
It's
it's
been
in
our
minds.
It's
not
a
high
priority
thing,
but
it's
been
on
our
minds.
C
Yeah,
no,
that's
an
interesting
point.
I
think
that
sort
of
starts
falling
outside
of
the
direct
purview
of
this
team.
When
you
start
talking
about
issue
workflows
and
enforcing
permissions
and
things
you
can
and
can't
change
about
them,
I
will
say
that
that's
probably
a
better
place
to
look
at
the
vulnerability
object,
so
our
severities
are
a.
We
have
a
set.
You
know
severity
level
for
everything.
C
C
I
think
there
was
actually
I
don't
remember
who
opened
it,
but
there
was
the
idea
of
trying
to
map
some
of
our
labels
to
the
severities.
When
you
create
an
issue
like
if
it's
critical
map
that
automatically
to
a
severity,
one,
for
instance,
there's
nothing
to
prevent
people
from
changing
that,
but
I
suppose
you
could
kind
of
use
that
as
another
trigger
to
say,
hey
these
two
things
are
out
of
sync
get
a
little
a
little
funky,
but
I
think
that's
part
of
the
problem
is
just
get
lab.
C
C
A
And
jason
you're
more
than
welcome
to
join
us
at
any
time.
If
you
ever
want
a
puzzle,
he'll
put
the
link
there
in
the
zoom
chat
for
you.
It's
constantly
got
a
puzzle
going.
You
can
look
in
the
threat
management
social
channel
if
it
changes
and
thank
you
for
joining
us
on
our
office
hours.
So
we
did
update
this
to
have
an
apac
and
a
maya
friendly
schedule.