►
From YouTube: GitLab 12.7 Kickoff - Defend:Threat Management
Description
Be sure to check out the Threat Management planning board: https://gitlab.com/groups/gitlab-org/-/boards/1420734?&label_name[]=group%3A%3Athreat%20management
A
A
So
we
can
see
it
looks
like
there's
only
one
thing
on
the
board
right
here,
but
there
are
actually
two
things
we'll
get
to
that
in
a
second,
so
we
are
breaking
out
our
issues
into
more
granular.
These
group
scoped
labels.
So
this
now
falls
under
the
threat
management
and
the
category
specifically
we're
talking
about
right
here
is
vulnerability
management.
So,
let's
look
at
the
thing:
that's
not
on
the
board,
so
we've
had
this
in
flight
for
over
for
a
while.
A
Now
it's
it
missed
the
12
5
release,
unfortunately,
and
we
we
weren't
able
to
finish
it
in
twelve
six.
This
is
another
large
project
that,
even
though
it's
an
MVC
as
there's
a
lot
of
moving
parts
to
it,
what
this
is
the
standalone
vulnerability
objects.
Is
it's
really
taking
the
concept
of
what
you
see
today
if
you
are
dealing
with
vulnerabilities
as
results
from
our
scanners,
like
our
SAS
scanner
or
scanner,
and
it's
elevating
that
to
a
first-class
object.
A
Now,
what
that
really
means
is
we're
going
to
be
treating
these
kind
of
like
you
would
treat
it's
a
an
issue
today.
So
it's
something
that
can
be
uniquely
linked
and
have
a
standalone
URL
be
interacted
with
provide
comments.
Now
it's
not
going
to
change
a
whole
lot
functionally
for
end-users,
but
what
it's
going
to
allow
is
a
lot
more
power
and
flexibility
going
forward
and
how
we
actually
manage
our
well
findings.
A
So
these
are
things
picked
up
by
a
scanner
that
could
be
an
indicator
that
there
was
a
vulnerability
detection
and
then,
ultimately,
how
you
deal
with
these
and
track
these.
So
this
is
kind
a
cornerstone
piece
of
work.
That's
going
to
be
replacing
a
lot
of
what
we've
got
in
flight
today
that
backs
the
security
dashboards,
the
pipeline
and
the
EM,
our
security
widget.
A
So
this
work
is
going
to
continue
into
twelve
seven,
which
we
hope
to
wrap
that
up
and
then
we'll
actually
start
migrating
some
of
the
pieces
that
are
that
I
just
mentioned
over
onto
this
new
architecture.
So
a
lot
of
this
is
behind
the
scenes,
but
expect
to
hear
more
about
this
in
the
coming
releases.
A
Now
the
other
item
that
we're
targeting
for
12:7
is
it
kind
of
sits
on
top
of
this.
So
when
I
mentioned
that
the
standalone
vulnerability
objects
is
going
to
be
sort
of
the
underpinnings
of
a
lot
of
features
who
ought
to
build
going
forward?
This
is
a
good
example
of
that.
So
we
want
people
to
be
able
to
create
we're,
calling
system,
notes
and
they're
interacting
with
the
vulnerability.
A
So
traceability
and
history
is
very
important.
We're
trying
to
look
at
the
of
the
life
cycle
of
a
given
vulnerability.
It
can
be
useful
not
just
for
the
engineering
teams,
the
individual
developers
or
your
DevOps
teams
or
dedsec
ops
teams.
It
can
also
be
useful
for
your
internal
security
teams
or
your
auditors
making
sure
that
they
can
tell
exactly
what
happened
with
a
vulnerability
if
it
was
closed
and
for
what
reason
was
it
resolved,
etc.
A
A
It
starts
in
an
open
state
or
an
action
state,
and
then
the
user
can
actually
move
it
to
a
confirmed
state
indicating
that
it
was
actually
a
vulnerability,
not
a
false
positive
and
the
user
can
also
once
from
the
confirms
they
can
also
revolt
resolve
it
once
a
corrective
action
has
taken
place
and
of
course
you
can
also
reverse
these
decisions
as
well
backing
it
up
to
previous
States,
it's
pretty
straightforward.
This
is
just
what
the
user
generated
system
note.