►
Description
Short-term Compliance Epic: https://gitlab.com/groups/gitlab-org/-/epics/3156
Short-term Security Orchestration Epic: https://gitlab.com/groups/gitlab-org/-/epics/4598
Long-term Shared Vision Prototype: https://gitlab-org-threat-management-defend-demos-policy-mock.34.83.185.53.nip.io/group_create.html#
Feedback Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/326520
A
A
It
appears
that
we're
doing
a
lot
of
duplicative
work
so
today,
I'm
here
with
sam
kerr,
who's,
the
product
manager
for
the
compliance
team
and
we're
going
to
be
talking
about
our
direction
and
our
strategy
and
how
our
two
directions
are
going
to
come
together
over
the
long
term
to
provide
an
incredible
amount
of
value
for
our
users.
Sam
kerr
is
going
to
describe
his
short-term
strategy
I'll
go
over
my
short-term
strategy
and
then
we'll
describe
where
we're
headed
in
the
long
run.
B
All
right
thanks
sam
yeah,
so
I
want
to
talk
a
little
bit
about
a
capability.
The
compliance
group
has
been
working
on
which
we're
calling
custom
compliance
framework
pipelines
and
really
the
the
problem
we're
trying
to
address
with
this
is:
we've
realized
that
there
are
compliance
teams
that
need
to
ensure
that
certain
steps
are
done
as
part
of
a
commit
or
a
merge
request
for
every
single
project
in
their
organization.
B
So
I'm
going
to
share
my
screen
and
I'll
walk
you
all
through
something
that
we're
going
to
be
releasing
in
1311,
which
is
here
in
a
couple
weeks,
all
right.
So
what
I
am
sharing
right
now
is
the
group
settings
for
a
group
that
has
a
number
of
different
compliance
frameworks
defined
for
it
for
this
demo
we're
going
to
talk
through
this
one
here,
which
is
called
sam's
framework,
and
so,
if
we
go
into
editing
this
and
take
a
look
at
it,
you
can
see,
you
can
add
a
name.
B
If
we
switch
to
this
project
sam's
compliance
you'll
see
this
is
our
new
gitlab
cieml
file,
and
this
is
what
we
would
envision
a
compliance
team,
creating
where
they
would
have
that
single
source
of
truth.
To
say
this
is
our
compliance
policy.
The
steps
that
have
to
be
run
on
every
merge
request
or
pipeline
or
commit,
and
in
this
example,
we
have
a
compliance
required,
build
job
that
runs
in
the
build
stage.
B
So
now
that
we've
looked
at
the
compliance
perspective,
let's
go
look
at
what
it
would
look
like
from
a
developer's
perspective
and
for
this
one
we'll
look
at
sam's
app.
This
might
be
a
project
where
the
application
is
defined,
but
you'll
note
it's
been
marked
with
the
sams
framework
compliance
label,
so
we
go
and
look
at
the
pipeline
definition
file
for
this
project
we'll
see
all
it
has
is
a
single
job,
just
a
job
that
says
it's
building
the
app.
B
This
is
incredibly
powerful
because
the
developer
didn't
have
to
do
anything.
They
didn't
have
to
understand
anything
about
the
compliance
requirements
of
the
organization
and
the
compliance
team
doesn't
have
to
worry
about
making
sure
every
developer
project
has
been
updated
correctly.
The
compliance
framework
applies
that
single
policy
is
code,
sort
of
approach
to
every
project.
That's
been
marked
with
the
compliance
framework
label.
A
On
our
side,
we
have
many
of
the
same
problems
that
sam
kerr
described
for
compliance
teams.
Although
we're
focused
on
security
teams
and
one
key
difference,
is
that
they're
focused
almost
exclusively
on
requiring
scans
to
be
run
or
requiring
certain
actions
to
be
taken
afterwards
based
off
of
the
results
of
those
scans.
So
it's
a
more
narrow
set
of
use
cases
for
the
security
teams
than
the
compliance
teams.
A
A
This
provides
for
separation
of
duties
where
the
permissions
and
management
can
be
handled
separately.
For
that
separate
security
policy
project
and
again
it
provides
that
separation
of
duties
between
the
developers
and
the
security
team.
In
that
security
policy
project
users
can
put
a
yaml
file
that
defines
the
policies
that
they
want
to
have
run.
For
example,
when
a
pipeline
runs,
I
want
to
require
a
das
job,
to
run
with
a
certain
das,
scan
and
site
profile
parameters
that
actually
runs
after
the
ci
yaml
file
executes
as
a
separate
post-processing
job.
A
A
Essentially
what
it
does
is
it.
It
puts
it
totally
into
separate
process.
You
could
even
specify
das
disabled,
true
in
your
gitlab
ci
file,
and
it
still
would
would
run
that
dash
scan
because
it's
actually
executing
it
at
the
very
end
of
everything.
After
the
the
gitlab
ci.yaml
file
has
been
parsed
and
executed
in
the
long
run.
We
want
to
take
this
experience
and
provide
a
cleaner
ui
around
it.
So
our
next
iteration
will
be
to
provide
a
listing
of
the
policies
that
have
been
created.
A
You
can
still
edit
that
associated
policy
project,
but
this
will
basically
be
a
view
of
those
yaml
policies
that
have
been
defined
in
that
space,
and
we
have
the
benefit
of
being
able
to
do
this,
because
it
is
a
little
bit
more
constrained
to
specific
policies
so
that
we
can
parse
those
out
without
dealing
with
all
of
the
complexity
and
the
numerous
options
that
are
available
in
the
full
gitlab
ci.yaml
file.
So
in
here,
when
users
create
a
new
policy,
it
will
automatically
create
that
new
project
for
them.
A
B
If
we
zoom
out
a
little
bit
and
look
at
how
both
of
us
are
approaching
we're
taking
slightly
different
approaches
to
ultimately
end
up
at
the
same
place
together.
The
approach
that
we've
taken
in
compliance
is
really
around
allowing
full
customization
full
power
of
a
gitlab
ci
yaml
file
to
be
applied
to
a
project.
Anything
you
can
do
inside
of
a
pipeline.
You
can
do
inside
of
a
compliance
framework
pipeline
from
the
other
end
with
security
and
policies.
B
Where
I
showed
the
one
where
it
was
saying.
Sam's
framework
you
know,
will
allow
being
able
to
specifically
define
where
and
when
policies
should
be
applied.
If
this,
then
that
style
rules
will
help
address
many
of
the
common
cases
that
our
users
will
have,
while
at
the
same
time
giving
them
that
full
flexibility
of
a
pipeline
definition
file
enables
the
different
teams
using
it
to
do
whatever
they
need
to
be
able
to
do.
If
one
of
our.
If
this
than
that
rules,
doesn't
provide
the
flexibility
they
need.
A
This
would
be
a
group
level
policy
that
I'm
managing
where,
as
part
of
this
policy,
you
could
come
in
and
define
which
labels
you
want
to
have
this
apply
to.
So
this
would
be
leveraging
the
project
level
compliance
framework
labels
that
the
compliance
team
is
working
on
to
specify
the
types
of
projects
inside
of
the
group
that
this
policy
should
be
applied
to,
and
then
we
take
this
nice.
A
If
this,
then
that
style
editor,
where
you
can
say
you
know
if
a
pipeline
is
run
against
the
main
branch
or
the
default
branch,
or
perhaps
you
want
to
execute
this
on
a
schedule
for
a
daily
or
weekly,
you
know
regular
schedule
and
then
you
can
come
down
and
you
can
add
any
number
of
actions
that
you
want
to
have
take
effect,
including
the
ability
to
execute
a
ci
script.
So
this
brings
the
work
that
the
compliance
team
is
doing
into
the
user.
A
Experience
that
the
security
orchestration
team
is
doing
where
you
can
link
to
any
arbitrary
cimo
file,
or
even
just
start
putting
in
a
custom
block
of
yaml
that
should
be
run
as
part
of
that
pipeline
or
as
part
of
that
on
that
schedule,
so
that
you
can
enforce
that
to
run.
But
you
still
get
the
nice
clean
user
experience,
that's
being
worked
on
by
the
security
orchestration
team.