►
From YouTube: Security Policy Overview, Roadmap, and AMA
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
Cool
thanks
for
joining.
I
just
wanted
to
give
a
walkthrough
of
what
we've
got
today
for
security
policies
and
then
also
cover
some
of
the
plans.
We've
got
for
our
roadmap
and
then
andy.
I
wanted
to
sync
up
with
you
on
related
plans
in
get
loud
for
fine
grain
permissioning,
because
eventually
we
actually
see
all
of
this
coming
together.
So,
as
I
mentioned
in
slack
right
now,
we're
storing
all
of
this
in
a
security
policy
project.
A
We've
really
designed
this
from
the
beginning
to
be
able
to
go
into
the
database,
and
that's
really
where
we
want
our
storage
to
be
like
in
the
long
term.
Vision
is
in
the
database,
which
means
we
will
need
to
have
gitlab
will
need
support
for
fine
grained
permissions
elsewhere
in
order
to
keep
feature
parity
with
what
we've
got
today.
A
But
there
were
a
lot
of
reasons
for
putting
it
in
a
linked
project.
Iteration
was
a
big
part
of
that
because,
right
out
of
the
gate,
we
just
automatically
have
a
full
history
of
all
of
the
policy
changes.
A
We
automatically
have
segregation
of
duties
because
you
can
manage
your
maintainers
for
the
security
policy
projects
separately
from
the
maintainers
on
the
development
project,
and
you
automatically
have
the
ability
to
require
two-step
approvals
for
any
changes
to
the
policies,
which
is
also
a
big
deal.
You
know
you
don't
want
to
let
just
one
person
unilaterally
change
the
policy.
A
Usually
policy
changes
themselves
have
to
go
through
an
approval
process.
There
are
a
lot
of
things
that
we
got
just
for
free
out
of
the
box.
By
doing
it.
This
way.
That
being
said,
we
are
doing
our
best
to
abstract
away
the
fact
that
these
are
stored
in
a
project,
because
the
user
experience
really
shouldn't
be
about
where
the
storage
layer
is
whether
it's
the
database
or
git
repository
or
something
else
entirely.
A
A
So
with
that
preface
I'll
just
share
my
screen
here:
real
quick
and
give
you
a
quick
walk
through.
So
on
this
project,
I'm
an
owner
and
actually
when
we
come
up.
A
Let
me
come
up
here
to
a
project
that
doesn't
already
have
a
security
policy
project,
so
I'm
an
owner
on
this
one
and
if
I
come
into
policies,
you'll
notice,
the
blank
state
here
says
this
project
doesn't
contain
any
policies.
I
can
go
and
I
can
come
in
here
and
I
can
click
edit
policy
project
and
I
can
choose
that
manually
in
the
ui.
A
I
can
go
through
and
search
and
find
one
or
I
can
just
dive
in
and
create
a
new
policy
and
part
of
this
workflow
is
because
we
have
network
policies
as
well,
which
those
are
not
stored
in
the
linked
security
policy
project.
So
that's
a
whole
other
thing.
We
don't
have
to
dive
into
that
today,
but
because
we
have
these
other
types
of
policies
that
don't
require
a
policy
project
to
be
linked.
First,
we
had
to
develop
the
workflow
around
that,
but
as
an
owner
I
can
come
in
and
I
can
just
right
away.
A
I
can
create
a
scan
execution
policy.
I
don't
have
to
worry
about
where
the
storage
is.
I
don't
have
to
think
about
it
as
soon
as
I
click
create
via
merge
request.
That's
actually
going
to
create
a
new
project
for
me,
it's
going
to
link
that
project
back
here
and
it's
going
to
open
this
as
a
merge
request
in
that
newly
created
project.
So
it's
going
to
do
all
of
those
things
behind
the
scenes
so
that
I
don't
have
to
worry
about
them
as
a
project
owner.
A
If
I'm
not
a
project
owner
and
yeah.
Let
me
come
over
here
for
just
a
minute
so
on
this
project,
big
lab,
org
project,
I'm
not
an
owner
and
we
don't
have
any
security
policies
yet
so
I
can
still
come
in
and
click
new
policy
because
I
might
be
creating
a
network
policy
and
again
network
policies
are
stored
directly
in
the
kubernetes
cluster,
and
so
I
can
still
go
ahead
and
do
that.
I
don't
need
a
security
policy
project
as
a
prerequisite
for
that.
But
if
I
come
in,
I
click
scan
execution
policy.
A
That's
where
I
get
this
blank
empty
state
saying
that
it
can
only
be
created
by
project
owners
and
it
links
out
to
our
docs.
So
again,
once
network
policies
go
away,
this
empty
state
will
be
able
to
move
that
over
onto
the
main
policy
page,
because
all
of
the
policy
types
will
require
a
linked
policy
project,
so
the
new
policy
button
can
go
away,
and
then
this
can
just
direct
you
straight
to
contacting
your
project
owner.
If
that
makes
sense.
B
A
So
it
actually
creates
a
new
project
inside
of
gitlab
and
then
it's
the
same
as
why
I've
gone
and
created
a
new
project
and
then
come
in
here
and
found
that
project
and
linked
it
up.
So
that
way,
you've
got
two
projects
and
they're
linked
to
each
other.
B
A
A
It
seems
like
quickly
would
be
a
merge
request
right
because
I
don't
have
a
name.
A
Okay,
so
create
a
corporate
website
dash
security
policy
project.
So
there
you
go
on
the
naming
scheme.
A
Put
it
in
that
same
group
that
the
other
project
was
in
so
you'll
notice.
Now
we've
got
corporate
website
and
corporate
website
security
policy
project
and
there's
the
description
right.
It
was
automatically
generated,
so
one
of
the
really
nice
things
about
this.
Linking
mechanism,
though,
is
that
you
can
have
it
supports
one
to
many.
So
this
security
policy
project
is
linked
to
this
corporate
website,
but
I
can
also
link
it
up
to
other
projects
like
this
data
generator
or
mobile
app
like
I
could
have
these
one.
A
C
A
Yeah,
so
that
piece
is
really
nice.
You
know
again
a
huge
benefit
that
we
got
just
by
virtue
of
going
with
the
storage
in
git.
So
again,
we'd
like
to
move
it
all
to
the
database,
we're
planning
on
that,
but
it's
a
little
bit
more
of
a
long-term
roadmap
item
for
us,
so
hopefully
justin
to
help
answer
your
question
about
the
empty
states
and
the
workflow
there
yeah
yeah
for
sure.
Thank
you.
A
A
At
the
moment,
one
thing
we've
got
on
our
roadmap
is
to
make
this
those
items
show
up
all
in
that
policy
page
so
right
now,
this
policy
page
will
only
show
you
policies
that
have
been
committed
into
the
default
branch,
but
we're
planning
to
surface
up
any
policies
that
are
pending
by
pending
via
mrs,
so
that
you
can
see
those
there
and
action
on
them
and
approve
them
without
having
to
jump
out
to
that
separate
project,
because
right
now
that
workflow
is
a
bit
disruptive
and
it's
kind
of
confusing.
A
A
Obviously,
we'll
have
to
have
all
of
this
ui
and
workflow
here
within
the
policy
page
before
we
get
rid
of
the
linked
policy
project,
because
you
still
need
that
method
somewhere
somehow
to
approve
the
policies
so
again
we're
in
the
iterative
way
that
we're
handling
this
we're
building
out
that
ui
here,
so
that
you'll
be
able
to
handle
the
approval
within
the
policy
page.
Instead
of
having
to
jump
out
to
that
external
external
project,
or
at
least
this
is
a
first
step
in
this
direction.
There's
still
no
like
approve
button
here.
A
A
So
we're
looking
to
actually
store
them
in
the
database,
but
we
will
keep
the
the
concept
of
security
as
code,
so
we're
very
deliberately.
A
You
know,
we've
got
the
rule
editor
mode
and
then
we've
got
the
yaml
editor
mode
and
so
that
yaml,
basically
just
maps
to
we'll
just
map
to
database
schema
and
vice
versa.
So
they
can
still
edit
these
as
yaml
and
view
it
as
yaml,
even
though
it'll
be
technically
stored
in
the
database.
So
the
goal
is
just
to
abstract
out
the
back
end
storage
layer.
A
B
Yeah,
no,
I
I
agree,
but
I
was
actually
kind
of
coming
from
a
slightly
different
angle
from
some
feedback
from
a
customer.
Yesterday
the
person
was,
he
was
a
security
team
lead
or
whatever,
and
he
was
expressing
his
frustration
with
having
to
go
down
into
yaml
so
much
and
he
wanted
a
very
you
know,
gooey
version
of
things
and
said:
yeah,
that's
fine
for
developers,
but
please
don't
make
me
do
that.
So
it
sounds
like
regardless
of
whether
it's
backed
by
yaml
or
database
you're,
going
towards
ui
parity
with
everything
that
you
could
construct.
A
Exactly
I
mean
from
our
research
that
we've
done
and
we
did
like
a
whole
problem
validation
on
this
almost
two
years
ago.
Actually,
before
we
started
any
of
this,
and
you
were
part
of
that-
and
you
remember-
I
mean
we
got
very
strong
feedback.
Everybody
had
just
it
was
like
apple
versus
my
windows,
like
you
know,
or
mac
versus
or
iphone
versus
android,
I
mean,
like
everybody,
had
an
extremely
strong
opinion
and
it
was
very
polarizing.
It
was
like
you
know,
talk
to
philippe.
A
I
work
in
yaml
and
yaml
only
I
don't
want
any
of
this
rule
mode.
Nonsense
just
give
me
the
actual
yaml
right
and
then,
like
the
person
you
talk
to
matt
like
yaml's
for
developers.
Give
me
something
I
can
understand.
So
that's
where
we've,
why
we've
gone
with
this
dual
mode
functionality
here,
so
whether
you
use
the
fancy
rule
editor
or
whether
you
edit
it
in
yaml
like
it's
all
one
and
the
same.
A
It's
just
a
matter
of
what's
your
preference
and
how
do
you
want
to
work
because
you
can
either
use
the
nice
ui
and
it
updates
the
ammo
live
or
you
can
just
edit?
The
yaml
and
that's
fine
too,
and
then
on
the
back
end
that'll
go
get
stored
somewhere,
whether
that's
in
git
or
in
the
database.
At
that
point,
it
doesn't
really
matter.
A
A
A
Another
thing
that
I
mentioned
is
being
able
to
view
the
policy
history.
So
that's
something
else
that
we
need
to
support.
A
And
again
so,
this
is
on
our
roadmap
to
add
in
to
the
side
tab,
but
a
change
history
log,
because
again,
if
we're
no
longer
using
that
linked
security
policy
project,
we've
got
to
provide
some
other
way
for
users
to
view
the
history
of
all
of
the
changes
that
have
been
made.
So
this
is
a
step
in
that
direction
as
well
and
we'll
need
to
make
more
changes
here
once
it's
actually
in
the
database,
but
just
providing
a
place
to
see
this
and
view
the
change.
History
is
a
pretty
big
step
as
well.
A
So
again
like
these
are
mocks.
This
shows
way
more
functionality
than
we
have
today,
but
hopefully
that
gives
you
at
least
some
idea
of
like
how
we're
slowly
moving
along
towards
getting
to
a
point
where
this
could
all
be
abstracted
away,
and
we
actually
have
this
item
way
down
here
at
number
10
to
hide
the
security
policy
project
and
automate
the
permissions.
A
So
before
we
move
to
the
database,
our
intermediate
plan
is
just
to
hide
away
that
linked
project
so
that
the
users
don't
even
know
it's
there.
They
don't
have
to
worry
about
it.
They
don't
have
to
think
about
it.
You
know
it's
all
entirely
behind
the
scenes
and
we
have
some
initial
thoughts
about
permissions
there
that
you
might
be
interested
in
andy.
A
I
mean
we
haven't
really
made
any
solid
decisions
on
this
one,
just
because
it's
so
far
out
for
us,
but
the
general
idea
is
that
you
would
be
able
to
set
up
the
equivalent
of
like
a
security
role
where
we've
got
developers
and
maintainers.
Today.
You
know
you
would
be
able
to
have
a
instance-wide
security
role
more
or
less,
where
those
individuals
would
be
maintainers
on
all
of
the
security
policy
projects
across
all
of
gitlab,
that's
sort
of
like
the
initial
thinking.
But
again
we
haven't
really
fleshed
that
out
or
finalized
those
requirements.
Yet.
C
So
the
direction
the
granular
permissions
project
is
gone
is
essentially
allowing
users
to
create
a
fork
of
an
existing
role.
So,
let's
say
developer.
I
can
fork
that
title
it
whatever.
I
want
security,
you
know
appsec
or
anything,
and
then
a
la
carte,
select
and
deselect
pretty
much
going
through
that
list
of
features
we
have
in
our
docs
of
permissions
of
what
you
want
to
allow
them
or
not
allow
them
to
do
so.
C
I
wouldn't
see
a
problem
with
having
that
kind
of
like
merge
into
kind
of
dating
the
security
policies
project.
Only
in
that
it
would
be
a
project.
Access
would
be
the
problem
so
because
it's
thought
of
the
project
access
feature
and
specifying
which
project
can
be
accessed,
isn't
something
that's
on
the
radar
yet
as
opposed
to.
We
can
do
what
within
a
project.
A
Yeah,
so
it
sounds
like
you
could,
where
you're
headed,
you
can
manage
that
at
the
instance
level
or
the
workspace
level,
or
what
have
you
but
yeah
you're
right
for
full
feature
parody
with
what
we've
got
today.
We
would
actually
need
those
settings
on
the
project
level,
so
you
could
say
for
this
development
project.
Who
do
I
want
to
be
able
to
manage
the
security
policies
for
this
specific
project
and
customize
that
list
on
a
per
project
basis?
A
I
have
a
lot
of
thoughts
about
ana
because
I've
dealt
with
that
a
lot
at
previous
companies
but
yeah.
Ideally,
you
want
that
to
be
a
flow
down
model
where,
basically,
the
group
inherits
from
the
workspace
and
the
subgroup
inherits
from
the
group
and
the
project
inherits
from
the
subgroup
and
then
you
can
either
set
that
to
use
the
upstream
setting
which
is
sort
of
the
default
or
you
can
override
it.
You
know
either
to
on
or
off
for
an
individual
on
a
per
project
basis
is
really
the
ideal
way
to
go.
C
Yeah
we're
working
on
that,
like
the
inheritance
of
like
least
access
right,
like
that
that
theory,
so
it
should
work
that
way
as
you
can
adjust
roles
by
group
right,
so
you
can
give
different
users
different
roles
depending
on
what
group
they're
in
or
they
can
inherit
down.
So
I
wouldn't
see
a
problem
with
that
right
now
and
the
whole
workspace
thing
is
gonna.
Keep
us
gonna,
keep
us
on
our
toes,
I
think
for
everything,
especially
policies
and
just
permissions
in
general.
So
there's
enough.
A
C
Yeah,
it's
essentially
what
you
were
mimicking
with
like
the
project
owner
or
maintainer,
can
only
do
these
actions
and
well,
when
we
tried
to
say
early
on
with
the
our
backstop
was
like.
Oh
just
make
security
people
maintainers
everyone's,
like
no
you're,
not
going
to
do
that
so
you're
mimicking
it
is
there
a
thought
on
when
workspaces
comes
out
how
to
trans
transition
away
from
a
policies
project
or
is
that
even
on
the
radar.
A
That
is
entirely
independent.
We
are
planning
to
use
the
new
the
work
that
the
workspaces
group
is
working
on
when
we
introduce
group
level
security
policies
and
that's
actually
the
very
next
item
on
our
backlog.
That's
right
here,
a
priority
to
add
support
for
group
level
policies.
So
we
have
this
all
designed
out
and
actually
we
are
just
waiting.
A
Their
back
end
object
that
they're
building
out
is
called
project
namespace
and
we
are
just
waiting
for
that
project.
Namespace
object
to
be
available
for
us
to
build
this
out,
so
this
is
this
is
planned,
but
the
the
work
to
make
this
available
at
the
group
level
and
subgroup
level
and
workspace
level
that
all
is
totally
separate
and
decoupled.
From
the
discussion
of
where
do
we
store
the
policies.
A
Because
yeah
right
now,
they're
just
building
out
that
back
end
namespace
object,
so
they're
not
even
working
on
workspace
right
now,
a
little
bit
confusing
right,
so
that
team
is
building
out
the
namespace
object
and
the
namespace
is
an
object
that
can
you
can
put
code
there.
That
applies
to
groups
subgroups
and
projects,
so
you
can
build
it
once
instead
of
building
it
three
times
over
and
that's
a
prerequisite
on
their
side.
A
C
Yeah
it
does,
I
think,
because
the
you
can
have
multiple
namespaces
in
a
workspace.
I
think
I've
seen
like
diagrams
of
that
so
far.
At
this
point,
I
think
one
question
that
is
not
there's
no
answer
to
it,
but
something
to
keep
in
mind
is
when
workspaces
becomes
available
for
in
this,
for
all
securing
protect.
A
We
definitely
need
it
at
the
project
and
group
level.
100.
That's
I
mean
that's,
not
even
a
question,
because
each
of
the
different
projects
require
their
own
settings
and
some
things
some
policies.
You
can
easily
just
set
it
in
an
instance
level
and
and
forget
it,
but
some
policies
require
project
specific
customization,
so
part
of
that
we're
addressing
with
like
the
way,
we're
handling
our
policies
so
like
when
we
require
das
to
run
instead
of
putting
in
all
the
parameters
for
das,
you
know.
So.
A
Das
is
a
great
example
because,
like
the
url
that
das
needs
to
go
scan
is
going
to
be
different
for
each
project.
That's
being
built,
and
you
know
desk
needs
to
authenticate
and
log
into
the
app
that's
built
and
again
that
those
credentials
are
going
to
be
different
for
every
single
project,
and
so
all
of
those
project.
Specific
settings
are
created
at
the
project
level
in
a
profile
and
then
the
policy
just
references,
a
profile
name.
A
So
as
long
as
you
have
really
good
hygiene-
and
you
create,
like
a
you
know,
if
you
use
the
same
name
for
these
profiles
across
all
of
your
projects,
say
it's
called
default
right,
then
you
could
just
go
and
say:
okay.
My
group
level
policy
requires
the
default
profile
to
run,
and
then
it's
going
to
pull
the
project
level
settings
because
each
project
has
its
own
settings
for
the
profile
that's
named
default.
A
So
there
are
some
things
like
that
that
we
can
handle
at
a
higher
level
and
just
have
it
up
there,
but
it's
gonna
be
really
hard
for
one
set
of
policies
to
apply
everywhere.
A
For
example,
different
policies
are
under
different
levels
of
scrutiny
like
different
regulation
levels.
I've
heard
you
know
a
lot
of
customers
that
have
like
you
know
we
color
code,
our
projects
or
we
classify
them
like
high
medium
low,
or
you
know
one
two
and
three
and
those
all
have
different
levels
of
scrutiny,
and
I
think
we're
gonna
have
to
continue
to
support
some
level
of
more
granular
customization,
because
some
projects
are
just
like
developers
threw
it
up
there
to
go.
C
Clean
yeah,
I
mean,
I
think,
there's
like
a
visualization
and
like
did.
We
check
the
boxes
across
all
of
our
applications,
layer
that
sits
at
the
workspace
and
then
there's
the
customization
tuning
for
the
specific
needs
of
an
application,
whether
it's
managing
pii
or
it's
like
fun,
with
learning
git
stuff.
Like
you
know,
you
can't
enforce
policies
straight
down
if
it's
just
a
project
to
like
my
project
for
my
cookbook
recipes.
I
don't
need
policies
on
that,
but.
A
Yeah
and
one
they
didn't
touch
on,
but
that
we're
planning
as
part
of
this
is
the
ability
to
customize
your
policy
rules
to
only
apply
to
policy
only
applied
to
projects
that
have
a
certain
compliance
framework
label
attached,
so
we're
planning
to
actually
integrate
tightly
with
that
feature
that
the
compliance
team
has
built
out,
because
there's
a
strong
desire
to
classify
projects
and
say
you
know,
this
project
requires
hipaa
compliance
or
this
project
requires
gdpr
compliance
and
this
project
over
here
does
not
you
know,
like
I
said:
if
I'm
just
a
developer
and
I'm
just
throwing
around
some
test
code,
you
probably
don't
even
need
to
see
run
any
security
scans.
A
You
know
or
require
merge,
request
approvals
like
you,
don't
need
any
controls
for
that,
because
it's
going
nowhere.
It's
just
purely
you
know
a
playground
to
test
things
in,
and
so
you
know
we
need
to
be
able
to
support
that
full
spectrum
of
controls
from
nothing
all
the
way
up
to
you
know
complete
security
and
we've
got
to
give
customers
a
way
to
classify
those
so
yeah.
That's
another
thing:
that's
going
to
help
is
having
policies
that
can
be
applied.
Only
to
you
know,
projects
with
a
given
compliance
framework
label.
C
Yeah,
those
are
almost
out
of
time.
I
think
the
last
thing
I
wanted
to
mention
was:
do
we
as
gitlab
have
a
good
definition
of
what
is
and
what
isn't
a
policy
that
belongs
in
this
part
of
the
application
that
does
these
certain
activities
versus
what
is
a
rule
requirement
for
merge,
requests
or
something?
You
know.
A
Yeah,
so
I
really
see
I
mean
it's
under
the
security
and
compliance
header
section
and
I
think
the
lines
really
get
drawn
around
persona.
So
if
it's
a
concern
that
the
security
and
compliance
team
is
dealing
with,
then
it
should
go
in
here
if
it's
something
that
a
developer
or
a
devops
engineer
or
someone
who's,
just
like
trying
to
automate
workflows
in
gitlab
elsewhere,
like
when
a
gitlab
issue
is
created.
I
need
you
to
also
create
a
linked
jira
issue
right
that
doesn't
have
anything
to
do
with
security
and
compliance
at
all.
A
I've
talked
with
like
gabe
weaver.
You
know
there
are
like
a
lot
of
other
areas
in
gitlab
that
could
benefit
from
this
kind
of
policy,
workflow
management
that
have
nothing
to
do
with
compliance
and
so
we're
hoping
to
allow
them
to
reuse
what
we've
built
here,
but
we
do
want
to
provide
a
good
segregation
of
duties
and
a
different
user
experience
for
each
of
those
personas,
because
there
is
a
pretty
strong
line
there
between
what
those
roles
and
responsibilities
are
for.
So
that's
really
the
defining
factor
and
principle.
A
So
yeah,
if
you're
just
saying
like
okay,
this
code
base
requires
back-end
approval.
If
it
touches
back-end
code,
I
mean
that's,
that's
on
the
development
team
right.
That's
a
development
approval
yeah
that
they
set
up
versus,
like
I'm
going
to
require
the
security
team
to
review
when
we
find
vulnerabilities.
That's
very
clearly
a
security
concern.
A
Yeah
and
there
may
be
some
overlap
between
the
two-
and
I
think-
that's
okay,
but
yeah.
We
really
see
this
as
the
home
for
everything
related
to
that
security
and
compliance
persona.
So
even
if
we
develop
two
ways
to
do
it
in
gitlab,
one
for
security
and
compliance,
people
and
one
for
developers,
that's
fine
too,
but
you
know
that's
the
boundary
that
we've
set
for
this
area.
Is
it's
got
to
meet
the
needs
of
that
persona?
Otherwise
it
doesn't
belong.
B
I
would
think
you
would
want
to
separate
them
as
well,
just
from
going
back
to
the
r
conversation
if
they're
in
separate
areas,
you
can
permission
them
separately,
because
I
can
see
that
being
a
big
problem
for
people
not
wanting
to
give
developers
access
to
the
security
policy
controls
just
because
they
need
to
create
a
you
know
like
an
mr
approval.
Workflow.
A
A
So
who
knows
we
may
even
let
you
just
create
generic
merge,
request
approval
rules
here
at
some
future
point
in
time.
We
don't
have
any
near
term
plans
for
that,
but
those
can
always
be
additive
to
the
ones
that
are
already
in
place
and
to
the
developers
it
would
show
up
as
like
a
read-only
rule
right
like
oh,
I'm,
a
maintainer,
but
I
can't
change
this
one,
because
this
was
put
in
place
by
the
security
and
compliance
team.
C
A
Yes,
so
anyway,
that's
generally
where
we're
headed,
if
you
haven't
seen,
I
know
we're
way
over
time
at
this
point,
let's
just
double
check,
oh
yeah,
so
I'm
still
good
to
stay
on
for
a
minute,
but.
C
Matt,
do
you
have
because
I
know
we
had
this
discussion
before
we're
like?
Oh,
that
sounds
like
we
can
just
make
it
a
policy
now
right
and
we've
talked
a
lot
about
like
settings
and
configurations,
and
you
know
vulnerability
management.
Ask
things,
I
guess,
there's
a
more
clear
definition
now
or
line
drawn
between
what
is
a
policy
and
what
is
a
configuration
for
vulnerability
management
right
with
this
policy
editor
and
this
yeah.
B
I
mean
I
I'd
say
yeah
generally
speaking,
so
like
perfect
example,
we're
still
looking
at
doing
auto
resolving
by
the
system
as
something
you
would
create
through
this
policy
builder,
and
I
would
kind
of
argue
on
the
side
of
it-
is
a
way
to
enable
what
is
or
is
not
a
policy
of
your
department.
So
if
you
have
a
security
policy
that
requires
a
human
review
before
resolving
something,
then
you
don't
enable
the
policy.
B
If
your
policy
allows
it,
then
you
can
create
this
rule
to
let
it
go
forward,
but
it
is
definitely
a
security
concern,
which
is
why
it
makes
sense
to
put
it
here,
plus
it's
a
lot
more
flexible
than
shoving
it
into
just
another
setting
on
the
security
compliance
configuration
page,
and
that
would
be
a
perfect
thing
to
sit
at
a
workspace
level
and
cascade
down
to
every
project
and
then
opt
out
the
ones
that
you
do
not
want.
The
auto
resolve
to
be
a
part
of.
So
I
think
this
is.
This
is
definitely
a
direction.
A
I
just
wanted
to
highlight
this
mock
if
you
haven't
seen
it
already.
This
is
in
the
settings
page
where
you
set
up
your
merge
request
approvals,
and
so
that's
this
is
what
it
will
look
like.
We
haven't
quite
done
this
development
work
yet,
but
it
should
be
done
fairly
soon,
probably
no
later
than
15.0,
so
we're
getting
rid
of
vulnerability
checks,
so
this
line
will
go
away
and
then
we're
adding
this
new
section
down
here
for
security
policies
and
you'll
notice.
A
We
list
them
so
that
you
can
see
them
all
in
one
place,
but
you
can't
actually
edit
it
here
and
that's
by
design.
We
send
you
over
to
the
policy
editor
if
you
want
to
make
any
modifications
so
again,
like
we're
doing
this
right
now
for
vulnerability,
check.
We'll
probably
do
this
as
well
soon
for
license
check.
A
C
C
This
makes
the
conversations
with
the
teams
that
have
been
working
on
like
another
type
of
rule
editor
or
you
know
the
and
create
they're
working
on
approval
rules
and
the
needs
are
similar.
But
if
you
look
a
level
deeper,
they're,
pretty
different
yep,
I
think
having
that
separation
is
a
little
more
clear
right.
A
Yep,
like
this
is
the
persona.
If
you're
this
persona,
you
work
here.
If
you're
this
persona,
then
you
work
up
here
right
and,
and
you
have
visibility,
so
we're
really
trying
to
keep
that
whole
ship
shift
left
visibility,
mentality,
which
is
why
we're
letting
everybody
everybody
developer
and
hire
see
all
of
the
rules,
and
they
can.
Even
you
know
you
can
even
open
an
mr
and
contribute
like
everybody
can
contribute.
Following
all
of
our
gitlab,
you
know
philosophies
here.
A
You
can
always
contribute
to
a
security
policy,
but
you
can't
actually
approve
it
and
merge
it
in
unless
you're
part
of
the
security
and
compliance
group.
So
that's
really
the
way
we've
intended
it
to
be
done
and
used
is
like
hey,
there's,
full
visibility
and
transparency
here.
If
you
think
something
can
or
should
be
changed,
go
ahead
and
open
an
mr
and
write
it
up
and
write
up
your
justification,
but
you
don't
have
the
authority
to
just
go.
Do
that
all
by
yourself,
yeah.
B
Sam,
so
in
that
mock
that
you
just
showed
the.
If
we
do
the
auto
resolve
like
we're
intending
right
now,
making
it
another
type
of
policy
or
another
type
of
rule
that
you
can
create
in
the
policy
editor.
Would
you
see
that
showing
up
there
as
well
in
that
security
section,
or
is
that
more
just
for
the
approvals.
B
Your
merge
requested
right
yeah.
I
realized
that
was
a
silly
question.
Let
me
modify
it
slightly
since
I
do
like
the
exposure
of
just
this
is
a
thing.
That's
here
is
that
something
we
should
put
in
here
or
just
keep
that
in
the
security.
Maybe
this
is
more
a
question
for
you
andy,
like
just
keep
it
in
the
security
and
compliance
section.
C
I
would
keep
it
in
the
security
and
compliance
section,
basically
just
because
how
the
system
works
like
it's
going
to
auto
resolve
once
it
no
longer
detects
the
vulnerability
anyway.
So
it's
not
like
you
can
do
anything
with
it
at
the
moment
of
time
of
being
in
an
mr.
C
We
have
a
tendency
to
want
to
like
put
things
in
things
with
like
things
to
have
like
consistency,
or
you
know
this
end
and
application.
That's
all
things
to
all
parties,
but
I
think
the
separation
is
needed
now
and
will
continue
to
be
needed,
as
we
have
built
more
of
a
vertical
inside
of
git
lab
for
security
and
compliance
specialties.