►
Description
In this video we are going through 2 spikes related to Security Orchestration Policy: https://gitlab.com/gitlab-org/gitlab/-/issues/280314 and https://gitlab.com/gitlab-org/gitlab/-/issues/280314 and we are presenting current state of the work and general idea of how this could be implemented on the backend side.
A
Hello:
everyone,
my
name
is
alan
percivsky
and
I'm
a
senior
backend
engineer
for
container
security
group
at
gitlab,
and
today
I
would
like
to
quickly
go
through
two
spikes
that
I'm
working
on.
So
the
first
one
is
how
to
add
a
job
that
does
not
exist
in
gitlab
ci
to
a
pipeline,
and
the
second
one
is
how
to
run
a
scheduled
pipeline
with
one
security
job.
A
So
the
main
idea
is
to
be
able
to
configure
a
policy
that
will
allow
you
to
to
set
up
policies
that
will
require
some
scans
to
work
and
that
will
actually
establish
some
standard
for
security
in
your
project
in
your
group
or
for
the
instance.
So
here,
for
example,
if
a
pipeline
is
run
for
the
master
branch,
then
I
would
like
to
set
scan
to
be
executed
or
dest
or
or
licensed
compliance
and
so
on.
So
you
can
specify
which
types
of
scans
you
would
like
to
make
sure
that
will
be
executed.
A
Every
time
you
run
a
pipeline
and
that's
why
you
have
those
two
spikes,
so
first
one
is
how
to
add
a
job
to
the
that
does
not
exist
in
gitlab
ci
that
will
be
executed
and
then
how
to
run
a
scheduled
pipeline
with
a
separate
set
of
jobs.
So
I
would
like
to
show
you
that
right
now,
so
I
have
a
project
here.
That's
a
very
simple
project.
I
have
a
gitlab
ci,
that's
actually
copy
paste
with
some
small
tweaks
from
autodev
of
cml
files.
A
A
So
you
can
see
this
is
the
one.
So
it
was.
We
have
container
scanning
dependencies
in
licenses
and
security
detection,
it's
all
here,
but
we
did
not
have
sas
so
what
we
can
do
to
have
sas
right
now
so
I'll
go
here.
This
is
the
very
simple
service
that
I'm
working
on
right
now.
That
will
execute
the
pipeline
with
given
scans.
So
I
I
need
to
run
it
in
my
console,
so
this
is
very
simple:
it
just
takes
the
scans.
I'd
like
to
run
it'll.
A
Ask
you
if
you'd
like
to
either
extend
the
currency.
I
configured
like
to
have
your
own
conflict
based
on
on
the
conflict
that
you
have
in
your
repository
and
it
will
take
those
scans,
create
the
yaml
file
and
then
use
that
yaml
file
to
run
pipeline.
So
that's
the
code,
but
I
would
like
to
go
here
and
I'll
start
everything.
So
I
have.
A
I
would
like
to
run
it
on
master
branch
and
simulate
sas
without
extending
say
config.
So
actually
what
I
would
like
to
do
is
so,
for
example,
I
have
a
pipeline
that
is
run
and
I
would
like
to
require
license
like
sas
can't
run.
This
is
what
I
would
like
to
show
you
like:
the
not
the
scheduling
part,
but
the
part
that
will
actually
like
mean
the
action
right,
we'll
trigger
that
based
on
comet,
that's
being
merged
or
when
pipeline
is
run
or
when
scheduled.
A
So
we
can
schedule,
for
example,
that
oh,
I
would
like
to
run
fast
every
single
day
at
8
pm,
right
and
so
on
and
so
on.
So
this
is
what
I
would
like
to
what
I'd
like
to
do
this
this
thing.
Okay,
so
I'll
get
back
to
my
console,
I
have
service
execute
for
master
branch
and
test
only
without
extending
the
ci
config.
A
It
will
do
the
magic
here
it
will
create
the
yaml
file.
So
here
you
can
see
like
this
is
the
result
of
the
yaml
file
and
we
have
lasas
only
and
some
jobs
that
are
required
to
build
everything
right.
So
then,
I
can
go
back
to
pipelines
and
we'll
see
if
it
actually
created
a
pipeline
that
we
wanted.
A
Let's
wait
a
second
and
we
should
see
it.
The
pipeline
should
run
okay,
we
have
it
so
you
see
here
we
have
already.
We
have
a
build
and
then
we
have
sas
only
like
we
have
sas
only
scans,
okay,
that's
great,
but
then
what
do?
We
would
like
only
to
extend
the
currency
icd
with
sas
scan
right,
so
how
we
should
do
that
so
get.
I
will
get
back
to
my
console,
and
here
I
was
mentioning
the
option,
extend
ci
config
and
I
can
specify
this
to
true
and
I'll
do
the
same.
A
It
will
do
the
magic,
it
will
create
a
yaml
file,
and
this
is
the
demo
file
that
was
created
and
you
can
see
that
it's
two
code
was
already
there
in
in
ci
ci
yaml
file
and
then
just
extend
it
with
with
the
sas
scan.
So
now
we
can
get
back
here.
We
already
have
one
that
is
running
will
not
wait
for
it
to
end,
but
but
let's,
let's
load
another
one,
because
we
have
already
two
pipelines
that
we
have
exited
manually.
A
Okay-
and
here
you
can
see
after
it
was
burst,
we
have
like
license
test
container
scanning
and
then
we
have
test.
So
this
is
exactly
what
we
wanted
to
achieve.
So
we
can
add
a
job
that
does
not
exist
in
each
lab
ci
to
a
pipeline
and
also
we
can.
We
can
schedule
a
pipeline
with
one
security
job.
What
is
left
right
now
is
being
able,
when
you
schedule
some
feature
through
like
scheduling
in
the
branch
and
so
on,
and
I'd
like
to
like
scan
it
every
two
hours
or
so.
A
I
want
to
be
able
to
to
see
that
as
a
developer
as
someone
that
can
actually
modify
everything
right
so
I'll
go
to
ci
cd
and
then
I
should
go
to
schedules,
and
I
should
see
here
somewhere
like
the
information.
Oh,
it
will
be
executed
at
this
time
and
the
sas
scan
will
be
executed.
A
The
other
thing
that
we
need
to
make
sure
in
scope
of
those
spikes
is
to
make
sure
that
nobody
will
disable
the
sas
scan.
So,
for
example,
I
could
go
to
to
my
ci
cd
cacd
configuration
to
yaml
file.
Let's
see
here
and
I
I
could
specify
the
variable
like
sas
to
disabled
right.
So,
for
example,.
A
A
A
But
if
I'll
schedule
it
using
like
the
configuration
here
right
so
do
the
same
as
I
did
previously,
but
with
that
variable
set,
I
need
to
make
sure
that
this
variable
is
not
being
like
saved
in
the
in
the
yaml
file,
because
we
we
really
want
to
make
sure
that
nobody
will
be
able
to
disable
the
sas
scan
and
the
project
and
then
expect
expect
the
runner
to
not
run
the
the
scan.
A
Because
of
that
variable
that
was
set
so
yeah,
and
this
will
not
happen
because
and
and
here
we
actually
are
setting
the
variables
all
variables
that
we
we
think
are
harm
and
that
could
do
harm
to
to
the
required
fast
or
any
other
security
scan.