►
Description
Sam Kerr talks about compliance frameworks, why GitLab only allows one to be applied to a project, and some best practices on how to think about combining multiple sets of requirements.
Product documentation: https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration
A
Hi,
I'm
sam
kirk,
I'm
a
principal
product
manager
here
at
gitlab
and
today
in
this
video.
I
wanted
to
talk
to
you
a
little
bit
about
how
you
can
think
about
get
labs
compliance
frameworks
and
how
to
work
through
the
case
where
it
seems
like
you
might
need
multiple
compliance
frameworks
for
project
and
how
to
really
only
use
a
single
compliance
framework.
Instead,
one
of
the
things
that
gitlab
does
with
our
compliance
frameworks
is
that
we
only
allow
you
to
apply
one
to
a
given
project
at
any
given
time.
A
A
Furthermore,
let's
imagine
that
the
team
that
works
in
this
project
works
in
north
america
and
that
the
project
is
also
being
paid
attention
to
by
sox
and
the
group
that
manages
sox
compliance.
A
Imagine
if
we
had
gone
ahead
and
added
two
different
compliance
framework
labels
to
the
my
project,
one
for
north
america
division
and
one
for
the
sock
team,
sox
team.
Imagine
if
each
of
those
frameworks
define
defines
conflicting
requirements
in
this
simple
example.
I'm
saying
that
the
north
america
division
might
be
saying.
Projects
must
not
run
the
acme
test
3.0,
while
the
sox
specific
requirements
say
that
a
project
must
run
acme
test
3.0,
because
these
requirements
are
conflicting.
A
So,
basically,
what
this
might
look
like
is
the
compliance
framework
requirements
would
start
with
anything
defined
at
the
north
america
division
that
must
not
run
acme
test.
3.0
example-
I
talked
about
previously
that
would
be
defined
as
a
small
template
or
a
small
snippet
that
would
be
included
into
the
next
file,
which
perhaps
the
sox
team
has
written,
which
would
say
in
this
case
that
a
project
must
run
the
acme
test
3.0
scan
and
that
this
should
take
precedence
over
any
other
requirements.
So
overriding
that
north
america
division's
requirement
and
removing
the
ambiguity.
A
At
that
point,
we
will
have
had
a
single
file
which
can
then
be
applied
to
the
my
project.
The
compliance
framework
and
compliance
pipelines
can
be
run
without
any
sort
of
ambiguity
or
conflict,
so
conceptually.
This
shows
why
we
only
allow
a
single
compliance
framework
label
to
be
applied
to
an
individual
project
to
gitlab.
A
Now
that
we've
looked
at
this
from
a
conceptual
level,
let's
take
a
look
at
how
we
might
actually
implement
this
inside
of
a
real
gitlab
project,
all
right.
So
now
that
we've
looked
at
a
conceptual
example
of
how
we
might
want
to
bring
together
multiple
sets
of
different
requirements
in
a
compliance
framework.
Let's
look
at
how
we
might
do
this
actually
in
gitlab,
and
so
the
screen
that
I'm
sharing
right
now
is
our
compliance
demo
project
and
in
it
I
have
a
few
files.
A
We
have
a
file
for
the
north
american
requirements
that
we
talked
about
previously,
as
well
as
a
file
to
contain
the
specific
requirements
that
we
also
looked
at
and
if
we
look
at
the
north
america.yaml
file,
what
this
is
doing.
This
is
implementing
that
required
job
that
we
want
to
run,
and
in
this
case
it's
saying
we
want
to
run
the
acme
scan
2.0
rather
than
the
3.0.
A
If
we
look
at
the
socks.eml
file,
we'll
see
the
same
job
as
being
defined,
but
in
this
case
we
want
to
run
acme
scan
3.0,
and
this
matches
the
conceptual
example
we
just
looked
at.
So,
let's
take
a
look
at
our
compliance
job
yaml
file,
which
is
going
to
show
how
to
bring
these
two
sets
of
requirements
together
in
a
single
pipeline
definition
file
and
the
way
that
we're
going
to
do
this
is
we're
going
to
use
an
include
directive
in
this
file
and
we're
going
to
include
those
north
american
business
requirements.
A
A
This
is
going
to
be
what
actually
builds
the
application,
what
builds
the
developer's
code,
and
so
then
this
will
be
our
single
definition
for
how
we
reconcile
those
two
sets
of
requirements
which
may
conflict
with
each
other.
In
this
case,
we're
resolving
that
conflict
by
just
saying
use
any
definitions
that
are
in
socks.yaml
to
override
anything.
That's
been
defined
in
north
america.aml,
but
this
is
where
we
would
do
any
sort
of
more
involved
sort
of
disambiguation.
A
If
we
wanted
to
run
an
acme
scan
4.0.
For
example,
we
could
define
a
new
job
here
to
update
or
change
any
of
those
requirements
as
needed,
and
so,
if
we
go
look
at
the
actual
application
development
project
which
is
going
to
be
using
that
compliance
framework,
we
can
see
it
has
our
demo
framework
compliance
framework
label
applied
and
if
we
go
click
into
the
latest
pipeline,
we
can
see
our
required
job
was
added,
as
we
would
expect,
and
if
we
click
into
it,
we
will
see
that
acme
scan
three
redux
was
run.
A
So
what
we've
looked
at
in
this
video
are
a
few
different
things.
We've
talked
about
why
gitlab
has
intentionally
limited
our
compliance
frameworks
to
having
a
single
framework
applied
to
any
given
project
to
avoid
the
problem
of
ambiguity
or
conflicting
requirements.
If
multiple
frameworks
were
applied,
we've
talked
a
little
bit
more
about
what
that
looks
like
at
a
conceptual
level
and
how
to
disin
disambiguate
that
by
including
multiple
sets
of
requirements
together
in
a
single
definition
and
resolving
those
conflicts.
A
We
also
looked
at
an
example
of
how
you
can
do
this
in
practice
with
git
lab
using
include
directives
as
part
of
your
compliance
pipeline.
Configuration
so
I
hope
this
has
been
helpful
if
you
have
any
questions,
comments
or
feedback,
we'd
love
to
hear
from
you
again,
I'm
sam
kerr,
my
handle
is
at
st
kerr
at
gitlab,
if
you'd
like
to
have
a
conversation,
feel
free
to
tag
myself
or
any
other
team
member
on
issue.
We'd
love
to
hear
from
you
thanks.
So
much
have
a
great
day.