►
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
All
right,
so,
I'm
sure
you're
familiar
with
the
old
vulnerability
check,
feature
yeah
we
deprecated
and
we
removed
that
in
the
15.0
release.
So
that's
actually
gone
entirely.
We've
been
replacing
that
for
quite
some
time
with
the
new
security
policies
feature.
So
actually,
why
don't?
I
just
start
this
from
kind
of
the
old
view
where
you
would
go
here
into
the
settings
area
and
you
look
at
these
merge
request
approvals,
you'll
notice,
there's
no
longer
an
option
for
vulnerability
check
and
instead
you'll
notice.
A
So
we
presented
in
this
view
so
that
you
have
one
place
to
go
to
get
a
list
of
all
of
your
approvals
that
apply
to
the
project,
but
we're
actually
following
a
principle
of
separation
of
duties
here,
so
that
the
security
and
compliance
approval
policies
can
be
managed
separately
from
all
of
the
other
like
development
approvals.
And
that's
because
we
tend
to
see
a
different
persona
right.
The
security
and
compliance
team
that
manage
these
security
approvals,
whereas
the
maintainers
of
the
project
typically
have
permission
to
manage.
All
of
these.
B
A
In
fact,
let
me
pull
up
our
documentation,
real
quick,
because
we
have
a
good
visualization,
so
you
end
up
with
two
separate
projects
in
gitlab,
and
these
do
not
even
have
to
be
under
the
same
group,
so
they
can
anywhere
in
gitlab
and
it
supports
a
one-to-many
linking
so
you
can
have
one
security
policy
project
that
manages
the
policies
for
multiple
development
projects.
If
you
would
like,
but
again,
the
management
of
that
linking
is
restricted
only
to
the
project
owner.
A
So
the
very
first
time
that
a
policy
is
created,
you
actually
have
to
have
a
project
owner.
Do
that
if
a
police,
a
project
isn't
already
linked,
so
you
see
here,
I've
got
the
customer
web
portal
project
and
I've.
My
customer
web
portal
dash
security
policy
project
is
linked
and
in
here
I've
got
three
policies.
Two
of
them
are
enabled
so
you've
got
the
green
check
this
one's
created,
but
not
enabled
it's
sort
of
like
a
draft
or
test
policy,
and
if
I
come
up
to
the
main
group
up
here,
you'll
see
this
project.
A
You
know
this
happens
to
be
in
the
same
group.
It
doesn't
have
to
be
in
the
same
group
to
apply,
but
in
here
it's
just
a
very
vanilla
project.
Right
we've
got
this
sorry,
let
me
come
back
in
you
know,
readme
and
get
lab
security
policies.
Folder
and
in
here
is
a
policy.yaml
file.
That's
it,
but
by
separating
this
out
in
a
different
project,
yeah.
A
Exactly
it's
great,
you
have
your
own
approval
process
for
this
security
project
too.
So
you
can
say
you
know
dominic,
you
by
yourself
are
not
allowed
to
change
the
security
policies.
You
have
to
submit
this
change
for
approval,
so
in
here
it's
just
yaml.
You've
got
you
know
three
different
policies
that
are
gonna
be
in
here
should
be
in
here.
A
Right
yep,
so
that's
our
you're
right,
that's
the
feature
we
just
released
of
group
level
policies.
So
that's
what
you
manage
at
the
project
level
and
then
you
can
actually
do
the
same
thing
at
the
group
level.
So
here's
my
group,
I
have
my
policies
yep.
This
is
that
required
past
one
and
you'll
see
this
one.
Is
this
wayne
financial
security.
B
A
A
And
then
in
here
to
edit
these
policies,
you
can
of
course
read
our
documentation
and
manually
create
the
yaml
yourself,
but
we've
also
been
hard
at
work.
Creating
a
nice
ui
experience
for
this,
so
this
security
gate
policy.
Some
of
these
are
scan
execution
policies.
They
require
scans
to
run
and
then
scan
result
policies
require
approval
when
new
vulnerabilities
are
found.
So
if
I
click
new
policy,
it
kind
of
gives
me
an
overview
of
the
difference
between
the
two.
A
We
won't
really
dive
into
the
scan
execution
ones,
because
that's
not
really
the
focus
of
today's
competition,
but
the
scan
result
ones
are
really
what
replaced
vulnerability
checks.
So
if
I
come
into
the
security
gate
policy,
you'll
see,
I
can
either
edit
the
yaml
directly
here
in
yaml
mode
or
I
can
come
over
to
rule
mode
and
anything
I
type
here
is
going
to
live
update
on
the
right.
A
A
I
want
to
trigger
any
time
there's
a
critical
and
a
high
that's
newly
detected
in
the
main
branch.
For
you
know
you
can
chain
lots
of
these
rules
together.
If
you
want
for
das,
I
only
care
about
the
criticals,
for
you
know
sas.
You
know
you
can
just
kind
of
keep
going
here.
I
think
right
now
we
have
a
limit
of,
I
believe
it's
five
rules,
but
we're
we
do
have
an
issue
plan
in
our
backlog
to
review
that
limit
because
it
was
kind
of
just
arbitrarily
set.
A
So
there's
not
really
a
reason,
necessarily
why
that
couldn't
potentially
be
higher
and
then
just
like
before
you
can
specify
either
users
or
groups
as
eligible
approvers.
For
these,
so
again
lots
of
criteria
here
that
you
can
filter
on.
You
know
you
can
get
really
specific
on.
You
know
exactly
what
you're
looking
for.
B
Cool
cool
yeah
I
like
that,
a
lot
I
think
it's
really
close,
but
for
our
current
use
case,
our
our
big
problem
is
that
the
current
categories,
like
secret
detection
or
best
recess,
is
a
bit
too
big,
because
right
now,
all
of
those
things
have
very
high
number
of
false
positives.
So
to
if
we
block
on
all
those
findings,
it
would
be
nice,
but
developers
will
hate
us
so
so,
if
we
could
filter
either
by,
I
don't
know
how
to
like.
Maybe.
B
B
If
there's
a
detection
for
this
rule,
then
now
we
want
an
approval
just
because
yeah
we
most
of
the
findings
are
still
false.
Positives,
we're
just
trying
to
tune
the
rules,
but
we
have
a
separate
set
of
custom
rules
that
really
are
created
after
the
next.
When
we
have
we've
had
a
couple
of
vulnerabilities
that
are
super
similar,
we
try
to
create
a
rule
that
really
makes
sure
we
never
see
this
again
and
those
are.
B
A
A
Be
really
really
good.
You
can
do
that.
I
understand
from
like
a
feature
request
perspective.
It
would
definitely
be
nice
to
do
that
in
that
policy.
Ui
yeah.
A
A
B
B
A
So
that's
the
nice
thing
is,
you
can
be
specific
about
which
scanners
you
want
to
include
or
exclude,
and
then
you
can
say
if
it's
introducing
a
new
if
a
critical
or
high
is
newly
detected.
So
if
it's
newly
detected,
that
means
it
doesn't
care.
If
there's
an
issue
created,
it
just
looks
to
see.
Is
this
detected
in
the
merge
request
branch
and
not
in
the
default
branch.
B
A
The
case
it
will
trigger
on
the
newly
detected
state.
All
of
these
other
four
statuses.
The
previously
detected
is
kind
of
a
catch-all
for
the
other
three,
and
then
you
know
these
other
ones
are
like.
They
already
exist
on
the
default
branch
in
a
confirmed
state
or
dismissed
or
resolved.
So
you
know
that
that's
kind
of
more
of
an
edge
case
scenario
for
most
of
our
users.
A
I
have
heard
it
from
some
users
like
they
actually
want
to
enforce
that.
As
like
a
clean
up
mechanism
to
say
you
know,
you're,
not
putting
any
new
code
in
until
you
go
back
and
clean
up
your
criticals.
That
already
so
you
know,
that's
the
thing,
but
assuming
you
know,
most
users
come
in
and
they
just
want
newly
detected
would
be.
It
sounds
like
what
you're
looking
for.
A
Yeah
exactly
yeah,
so
once
the
link
is
created,
the
owner
should
make
sure
to
give
you
maintainer
permissions
on
that
linked
project
yeah.
And
after
that
point,
you
don't
need
the
owner
anymore.
You
know
the
owner
is
only
to
set
up
that
link
and
to
give
you
permission
to
to
manage
that
policy
project.
A
So
after
that,
you
make
your
changes
in
there,
and
you
know
once
those
changes
are
merged
into
the
default
branch
for
the
security
policy
project,
then
it
takes
effect
for
any
projects
out
there
that
have
that
policy
linked
up
to
it.
So
you
can
link
that
do
that
linking
at
the
group
level,
if
you
want
now,
we
actually
just
turned
that
on
in
production
or
the
subgroup
or
the
individual
projects,
and
it
just
all
flows
down.
B
Very
cool,
okay,
yeah
there's,
definitely
something
we
can
do
with
that
and
clean
up
some
custom
stuff.
I
think
I'll
just
write
something
up
and
post
in
the
turn
on
security
approvals
and
get
that
project
issue
that
is
10
months
old
and
try
to
I.
I
think
my
proposal
will
be
different
from
what
the
original
issue
had
there,
but
yeah.
A
Yeah,
like
I
said
you
know,
this
is
an
area
where
the
board
of
directors
actually
allocated
money
to
hire
a
new
engineer,
to
focus
exclusively
on
this.
Only
that
happened
about
a
year
ago,
so
we
now
have
like
a
full
year's
worth
of
development
here
that
you
did
not
have
you
know
eight
months
ago,
so
yeah.
B
A
You
can
tell
a
lot,
has
changed
and
we're
actively
adding
more
to
this
area
too,
like
it's,
not
stopping
here
so
anyway.
I
liked
your
idea
of
closing
out
that
issue.
That's
there,
because
it's
really
long
and
bloated,
and
maybe
just
creating
a
new
one
too,
if
you
wanted
to
go
that
route
either
way.
It's
up
to
you.
B
B
A
B
That
and
core,
I
think
the
name
I'm
not
super
into
that
initiative
and
I
don't
have
a
whole
lot
of
details.
So
I
don't
know
if
I
can
answer
your
questions,
but
we
can
try.
A
B
A
So
that's
something
that
you
could
actually
do
with
get
lab.
You
know
without
paying
for
encore
or
twist
flock.
Of
course
you
know
if
you
want
to
run
those
as
well,
there's
no
reason
that
you
can't
run
all
three
kinds
of
scanning,
but
it
would
be
fantastic
if
we
could
get
that
started
as
well,
just
from
a
dog
fooding
perspective,
so
that
we
can
start
getting
some
feedback
on
what
we've
got
to
scan
the
production
environments.
B
A
It
cannot
be
anyway
yeah,
it
could
be
additive
right,
it
doesn't
have
to
be
an
either
or
discussion.
We
could
run
twist
block
and
get
lab
scanning,
and
we
are
it's
not
quite
ready
yet,
but
to
do
that,
it
actually
goes
back
to
the
same
policy
approach
again
you
would
create
in
this
case
you
would
create
a
scan
execution
policy
and
right
now
you
have
to
work
just
with
the
yaml.
A
We
don't
have
the
rule
mode,
yet
that's
under
development
as
well
right
now,
but
you
would
create
a
schedule
instead
of
running
as
part
of
a
pipeline,
you
created
as
a
schedule,
and
then
you
would
have
you
would
specify
which
agents
you
know.
All
you
have
to
do
is
install
the
get
lab
agent
for
kubernetes,
and
then
you
specify
the
name
of
the
agent
in
a
production
agent
here
and
then
you
put
in
a
cadence
which
is
really
just
a
cron
job
syntax.
A
You
know
something
like
that
and
I
think
it
has
to
be
quoted
so
that
it
doesn't
three
ml
errors
and
then
you
put
in
here
container
scanning
or
cluster
cluster
image
scanning,
I
believe,
but
when
it
does
that
it's
going
to
run,
you
know
per
the
cadence
that
you
define
and
then
it'll
actually
show
up
on
your
vulnerability
report
under
operational
vulnerabilities.
So
you've
got
your
development
ones
and
then
you've
got
your
operational
ones.
Okay,
and
you
can
filter
that
to
only
scan
specific
namespaces
anyway.
B
Absolutely
if
I'll
take
the
link
from
this
recording
and
post
it
in
the
channel
and
paying
some
people.