►
From YouTube: Overview of GitLab Scan Result Policies
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
Well,
today,
I'll
be
covering
just
a
brief.
Walkthrough
of
the
new
scan
result
policies
in
gitlab.
These
scan
result
policies
replace
the
previous
functionality
of
vulnerability
check.
So
if
you
come
into
your
project
under
settings
general-
and
you
come
down
to
merge,
request
approvals,
you'll
see
in
the
past,
we
have
this
vulnerability
check
feature.
We
are
actually
removing
this
in
the
15.0
release
and
replacing
it
with
security
approvals.
A
Instead,
you'll
notice
that
if
you
have
any
security
approvals,
these
will
be
listed
just
below
all
of
your
approval
rules
so
that
you
can
easily
differentiate
them
while
also
seeing
them
in
the
same
place.
These
security
approvals
are
all
edited
and
managed
over
on
the
security
and
compliance
policies
page.
So
let's
take
a
look
at
this
security
approval
policy
and
see
how
it
was
created.
A
If
we
come
over
to
policies
you'll
see,
I
have
two
types
of
policies
in
my
project
right
now.
One
is
a
scan
execution
policy
and
the
other
is
a
scan
result
policy,
and
in
this
one,
I've
created
a
policy
to
require
approval
for
all
criticals
and
highs.
The
workflow
for
creating
these
policies
is
to
come
in.
You
just
create
a
new
policy
you
can
choose
which
of
these
two
types
you
would
like,
and
when
you
come
in
and
choose
a
scan
result
policy.
A
It
lets
you
write
rules
that
come
into
effect
once
a
scan
finishes
running
so
to
mirror
that
policy
that
I
just
created,
I
would
come
in
and
create
a
name
require
approval
for
all
criticals
and
highs.
I
would
set
it
to
enabled
I
could
add
a
description
if
I
wanted
to
and
then
I
can
come
through
and
I
can
specify
which
scanners
I
want
to
trigger
this.
A
These
approvals
based
off
of
how
many
vulnerabilities
I
want
to
allow
what
state
of
vulnerability
if
it's
newly
detected
or
previously
detected
to
trigger
the
the
approval
requirement
and
then,
lastly,
which
branches
that
I
want
to
require
the
approval
for
so
in
this
case,
I'm
going
to
go
through
and
select
everything,
because
I
want
it
to
apply
to
all
security
scanners.
A
You
wanted
to
also
trigger
if
there
were
any
medium
vulnerabilities
if
it
found
more
than
10
medium
vulnerabilities
that
were
being
introduced
in
a
particular
project.
So
you
can
chain
these
rules
together
to
create
more
complex
sets
of
criteria
for
these
approvals.
If
you
want
to.
A
A
So
all
of
this
ends
up
being
stored
as
yaml,
essentially
security
policy
as
code.
If
I
want
to
edit
that
yaml
directly,
I
can
switch
over
to
this
yaml
mode,
where
I
can
edit
all
of
these
things
right
here
in
mine.
If
I
prefer
that
or
I
can
come
back
to
the
rule
mode,
if
I
prefer
the
visual
editor
once
I
do
this,
it
actually
will
cause
it
to
configure
with
a
merge
request.
A
If
I
take
a
look
at
my
group,
you'll
notice,
I
have
this
customer
web
portal
project,
which
is
the
development
project
that
I've
been
working
in
and
then
there's
also.
This
security
policy
project
and
these
two
are
linked
together.
So
here's
my
customer
web
portal
project
and
if
I
come
in
to
edit
it
you'll
see
that
these
policies
are
actually
all
being
stored
as
yaml
in
this
linked
security
policy
project,
and
if
I
come
in
here,
I
can
actually
see
the
yaml
that's
already
been
committed
in
it's.
A
A
Some
of
the
benefits
of
storing
this
as
code
are
one
you're
able
to
see
the
full
history
of
any
changes,
and
this
is
just
a
benefit
that
comes
from
git,
so
you
can
click
on
history
and
see
a
full
audit
trail
of
who
changed
it.
And
what
and
when
the
other
benefit
of
having
it
in
a
separate
project
is
that
you
can
define
who's
allowed
to
review
and
approve
and
merge
things
into
this
project.
A
So
when
I
make
those
changes
back
here
in
this
ui
again,
it's
just
creating
a
merge
request
into
the
linked
security
policy
project
and
then
that
merge
request
itself
can
go
through
its
own
set
of
approvals.
So
if
you
want
to
require
two
people
to
approve
any
changes
to
these
policies,
it's
really
easy
to
set
that
up
now
in
the
lab.
The
other
benefit
of
having
things
this
way
is
that
you
can
have
this
security
policy
project
linked
to
multiple
development
projects,
so
it
doesn't
have
to
only
be
linked
to
this
one.
A
If
we
were
to
come
back
to
our
overall
group
you'll
notice,
I've
got
several
projects
in
here.
I
could
actually
have
this
security
policy
project
applied
to
all
of
the
projects.
If
I
wanted
to
link
it
up
to
each
one
that
way,
I
would
only
have
one
set
of
policies
to
manage
across
my
entire
set
of
projects,
and
it
can
even
span
across
group
boundaries
if
you
wanted
to
apply
to
projects
in
another
group.
A
So
those
are
the
details
on
how
and
where
the
policies
are
managed.
Ultimately,
the
scan
result
policies
get
applied
in
the
merge
request
itself.
So
here's
an
example
merge
request.
I'm
making
a
change
here
to
introduce
a
new
version
of
mariah
db.
It's
actually
a
really
old,
outdated
version
that
has
a
lot
of
known
vulnerabilities
and
so,
when
the
security
scans
ran,
it
detected
one
critical
and
five
high
vulnerabilities
and
that
clearly
violates
the
policy
that
I
have
in
place
and
so
you'll
see
here.