►
From YouTube: Hands On GitLab DevSecOps Workshop - September 27, 2023
Description
In this workshop we focus on how you can secure your application with GitLab.
We will first take a look at how to apply scanners to your CI/CD pipelines in a hands-on exercise so that any vulnerabilities are caught as soon as the code is committed.
Next, we will look at compliance frameworks and pipelines to show how you can ensure no one within your development teams is cutting corners and exposing your application.
A
All
right
welcome
in
everybody
we'll
give
a
few
minutes
for
everyone
to
start
trickling
in
here.
I
appreciate
you
all
for
joining
in,
depending
on
where
you
are
in
the
world
either
good
morning,
good
afternoon
or
good
evening
to
you
all
and
like
I
said
we'll
just
give
H
folks,
just
another
minute
to
join
in
we've
only
got
an
hour
and
we've
got
a
ton
of
content
to
to
go
through
so
we'll
be
starting
here
shortly.
A
In
the
meantime,
I
want
to
welcome
you
to
our
Hands-On
workshop
on
security
and
compliance
within
gitlab.
This
is
your
hand
firstand
on
workshop
at
gitlab.
We
want
to
make
sure
that
you
have
a
working
gitlab.com
account,
which
is
our
SAS
platform
form
that's
different
from
an
account
on
our
self-managed
instances
of
gitlab
that
you
might
be
using
within
your
own
organization.
A
So
if
you
have
a
self-managed
instance,
you'll
need
to
create
an
account
on
gitlab.com
I've
got
the
link
to
sign
up
for
gitlab.com
account,
if
you
don't
have
one
already
here
on
the
screen.
I
also
put
some
information
here
in
the
chat
for
you
all
to
get
situated
with
a
lab
environment.
A
You
know
getting
signed
up
for
a
gitlab.com
account
as
well,
as
you
know,
going
through
the
provisioning
process
for
your
sandbox
group
on
gitlab.com,
we're
walking
everybody
through
that
today's
Hands-On
Workshop,
but
just
wanted
to
get
everyone
Head
Start,
with
these
lab
setup
instructions
in
the
chat,
as
well
as
on
the
screen
here
with
the
QR
code
and
a
link.
So
you
can
take
a
screenshot
as
well.
A
If
you
can
get
access
to
the
chat,
all
right
looks
like
we've
given
folks
another
minute,
so
let's
go
ahead
and
get
started,
so
today's
Workshop
is
going
to
focus
on
security
and
compliance.
Within,
gitlab
and
I
just
want
to
make
sure
that
you
all
are
aware
of
what
the
the
workshop
is
going
to
be
focused
on.
A
My
name
is
Chris
garte
I'm,
a
senior
customer
success
engineer
here
at
gitlab
based
out
of
Los
Angeles
California
after
today's
session,
please
feel
free
to
connect
with
me
on
LinkedIn
I've
got
a
QR
code
that
takes
you
directly
to
my
profile.
So
if
you
want
to
scan
that
and
start
connecting
with
me,
there
I
do
take
the
time
to
share
posts
that
highlight
some
of
the
key
topics
that
I'm
discussing
with
my
customers
on
a
weekly
basis,
as
well
as
sharing
new
features
and
capabilities.
A
That
I
think
are
important,
based
on
my
regular
interactions
with
customers
in
the
field.
I'm
also
sharing
my
gitlab
profile.
So
you
can
see
some
of
my
latest
contributions
and
yeah
look
forward
to
being
able
to
connect
with
some
of
you
all
that
want
to
connect
with
me
on
LinkedIn,
just
sharing
here,
the
the
lab
setup
instructions
for
those
of
you
who
have
just
joined
in
after
my
introduction.
So
let
me
just
introduce
you
to
the
fictional
scenario
for
today's
Workshop
today.
A
I
want
to
welcome
you
to
the
team
you're,
officially
part
of
a
brand
new
startup,
that's
creating
a
public
leaderboard
for
the
hit
new
racing
game.
Tanuki
racing
this
groundbreaking
new
application
has
been
developed
and
deployed
in
a
Beta
release.
However,
the
developers
are
lost
on
how
to
make
it
more
secure.
So
as
a
new
security
specialist
on
the
team,
they've
asked
you
to
use
gitlab
to
enhance
the
application
overall
security.
So,
let's
take
a
look
at
today's
agenda.
First,
we'll
get
you
set
up
with
the
lab
environment.
A
That's
on
our
SAS
platform.
So,
if
youve
just
joined
in,
we
just
want
to
make
sure
that
you've
got
a
gitlab.com
account.
If
you
don't
already,
please
go
ahead
and
sign
up
for
that.
I'll
repaste
instructions
for
our
new
joiners
also
got
in
the
upper
right
hand,
corner
a
link
to
the
lab
setup
instructions
if
you
lost
it.
A
A
Third,
we'll
take
a
look
at
the
compliance
framework
and
compliance
pipelines
function
Audi
within
gitlab
how
to
go
the
configuration
of
specific
compliance
rules
to
ensure
good
governance
of
our
projects,
pipelines
in
the
fourth
section
here,
parsing
the
results
we'll
be
making
sense
of
all
the
vulnerability
findings
generated
by
shifting
left
in
the
fifth
section,
with
sbom
and
license
compliance
we'll
explore
the
software
bill
of
materials,
which
is
what
sbom
stands
for
and
license
license
compliance
information,
that's
generated
when
we
shifted
left.
A
Finally,
we'll
take
a
brief
look
at
on
demand,
scans,
audit
events
and
more
then
we'll
I'll
point
you
in
the
right
direction
on
how
to
transfer
your
project.
If
you
want
to
save
your
work
to
your
own
personal
namespace,
on
gitlab.com
or
to
your
group
on
gab.com,
your
organizations
group
on
gab.com,
then,
finally,
we'll
we'll
wrap
up
with
a
a
conclusion
on
what
we
learned
and
what
we've
been
able
to
complete
in
today's
Workshop.
A
So
thanks
for
joining
again
and
we'll
go
ahead,
Dive
Right
into
lab
setup,
so
to
get
set
up,
we'll
need
two
things:
we'll
need
your
own
gitlab.com
account
and
then
we'll
also
need
to
get
provisioned
with
a
a
subgroup
on
our
gitlab.com
platform,
SAS
platform
that
will
allow
you
to
get
an
ultimate
license
applied
to
it
to
take
advantage
of
all
the
security
features
that
we'll
be
showing
you
today,
as
well.
A
As
you
know,
forking
a
project,
a
source
project
to
that
subgroup
where
you'll
be
performing
some
of
the
activities
and
the
exercises
that
will
be
guiding
you
through.
A
Today,
all
right
so
to
get
set
up
as
I
mentioned,
the
lab
set
of
instructions
already
go
through
this
and
I
put
it
here
in
the
chat
as
well.
We'll
need
to
go
to
www.gb.
Demo.Com
I've
got
it
here
in
a
separate
Tab
and
what
you
need
to
do
when
you
go.
There
is
just
click.
The
blue
redeem
invitation
code
button
and
copy
the
invitation
code.
That's
shown
here
on
the
screen.
I
also
put
it
here
in
the
chat
as.
A
Well,
sorry
for
the
repetition
there,
sometimes
when
people
join
in
a
little
bit
later,
they
don't
see
the
back.
The
back
scroll
on
the
zoom
chat,
I'll
paste
in
the
invitation
code.
That
is
just
provided
to
you
and
click
provision,
training
environment
from
there.
You
want
to
grab
your
gitlab.com
username.
So
again,
a
prerequisite
to
this
Workshop
today
is
to
log
into
gitlab.com
or
sign
up
for
a
gitlab.com
account
and
grab
your
username.
A
So
you
can
find
that
by
going
to
the
main
navigation,
finding
your
avatar
icon,
clicking
that
and
in
that
drop
down
menu,
you'll
find
your
username
prefix,
with
that
at
symbol,
you're
actually
going
to
copy
everything
after
the
at
symbol.
So
mine
is
just
see
garte
and
we
want
to
make
sure
that's
added
here
in
this
field
on
gitlab
demo.com
for
provisioning
you're
not
going
to
want
to
include
the
at
symbol.
A
If
you
do
include
the
app
symbol,
your
the
provisioning
won't
work
and
you
may
may
get
a
four
or
four
error
when
trying
to
access
your
group.
So
after
you
put
in
their
username
correctly
without
the
app
symbol,
as
well
as
the
invitation
code,
go
ahead
and
click
provision,
training,
environment,
you'll
get
to
a
page
like
this.
If
you
click
this
blue
Mig
group
button
and
you
don't
get
a
404,
everything
looks
like
it's
set
up
correctly.
I've
got
an
example
project
already
in
here.
That's
set
up.
A
That's
the
really
speed
up
things,
but
for
your
purposes,
when
you're,
just
going
through
this
provisioning
process,
you'll
see
an
empty
group
on
gab.com
provision
for
you,
so
hopefully,
everybody's
gotten
set
up
with
the
lab
environment,
just
based
on
that
work
walkth
through
and
the
lab
setup
document
that
I've
shared
with
you.
If
you
can
give
me
me
a
thumbs
up
or
just
let
me
know
in
the
chat
that
everything's
going
well
with
the
lab
setup.
Let
me
know
that
everything's
going
well.
A
A
Call
again,
if
you've
got
that
for
four
error,
that
means
that
you
might
have
copied
the
username
incorrectly
when
going
through
the
lab
setup
instructions,
and
you
can
always
go
back
to
gitlab
demo.com
and
go
through
the
redeem
invitation
code
process
once
more
with
the
same
invitation
code
and
typing
in
your
username
one
more
time
making
sure
you
don't
have
that
app
symbol,
making
sure
there's
no
typos
and
when
you
click
provision,
training
environment.
It
should
take
you
to
the
group
and
again,
if
you've
lost
your
place
as
well.
A
That's
really
a
great
method
to
to
get
back
to
your
group,
since
it's
a
bit
more
unique,
it's
hard
to
remember
exactly
what
the
path
might
be
or
how
to
get
back
to
it.
Since
you've
got
a
unique
identifier
for
your
test
group,
so
you
can
always
go
through
the
Redemption
process
again
just
to
get
back
to
your
provision
subgroup
on
gitlab.com.
For
today's.
A
Workshop
all
right
so
next
thing
that
we
need
to
do
is
to
Fork
a
source
project.
That's
going
to
be
used
for
the
Hands-On
exercises
within
your
sandbox
group,
going
to
paste
in
some
instructions
here
on
the
project
to
Fork,
so
you're,
going
to
open
up
that
that
link
there
in
another
tab
or
window
and
you're
going
to
create
a
fork
of
that
project.
A
So
that's
here
in
this
leftand
screen
left
hand
side
of
my
screen
here:
you're
going
to
click
this
Forks
button
and,
depending
on
your
layout
of
your
monitor,
may
be
bigger,
so
it'll
be
in
the
upper
right
hand
corner.
So
you
can
click
that
button
and
what
I
like
doing
is
I,
like
renaming
the
project
so
going
from
the
original
name
to
Workshop
project
and
then
selecting
your
name
space.
So
the
name
space
will
be
the
target
group
or
the
the
sandbox
group
that
was
provisioned
for
you.
You'll!
A
Have
that
unique
identifier
in
the
name
of
the
group,
you
can
just
copy
that
unique
identifier
and
paste
it
there
and
select
the
namespace
that
should
automatically
select
that
name
space
to
for
the
project
into
that's
your
private
subgroup,
that's
unique
to
only
yourself
as
part
of
this
Workshop,
you
can
leave
the
project
lug
at
its
default
Workshop
Workshop
d
project
and
then
leave
the
visibility
level
at
private
click
Fork
project,
and
then
that
will
work
the
project
in
your
test
group
again,
if
you're
just
joined
in
we're
going
through
the
lab
setup
instructions,
I've
got
it
in
the
chat.
A
My
colleague
Steve
had
already
pasted
in
the
lab
set
of
instructions
and
we're
just
going
through
the
forking
process
to
make
a
copy
of
the
source
project
into
our
sandbox
group.
We're
calling
it
Workshop
project
to
make
it
easier
to
identify,
but
this
is
our
Target
project
for
working
in
the
sandbox
environment.
So
you
can
see
that
here,
alongside
my
completed
projects
that
I
created
ahead
of
today's
Workshop,
it's
not
necessary
to
have
these
completed
projects
again.
A
I
only
had
that
there
to
speed
things
up
when
I'm
in
explaining
going
through
the
Hands-On
portion
so
yeah
once
you
Fork
the
project
you'll
go
ahead
and
open
up
your
Workshop
project
that
was
forked
and
you're
going
to
remove
the
fork
relationship.
So
that's
in
the
main
navigation
of
the
workshop
project
go
to
settings
and
general
and
then
you're
going
to
scroll
all
the
way
down
on
the
settings.
Page,
the
general
settings
page
and
find
Advanced
click,
open,
expand
and
then
find
remove
Fork
relationship
and
click.
The
red
remove,
Fork
relationship
button.
A
So
that's
all
the
steps
for
getting
your
lab
environment
set
up,
but
I
also
want
to
note
that
when
you
make
that
fork
of
the
project
that
source
project
that
I
linked
in
the
chat
there,
the
gitlab
security
and
compliance
project,
it
doesn't
bring
over
the
issues
which
are
the
exercises
for
Hands-On
portion
of
the
Workshop
today.
So
you
want
to
reopen
that
that
link
that
I
put
in
the
chat
for
gitlab
security
and
compliance
and
open
up
that
source
project
again-
and
you
know
what
I
like
doing-
is
I.
A
Have
it
Side
by
sign
out
on
a
single
monitor
in
different
tabs
or
Windows.
But
if
you
have
multiple
screens,
you
could
just
have
it
in
two
different
screens,
for
example.
So
I
like
to
open
up
the
plan
issues
screen
of
the
gitlab
security
compliance
source
project
on
one
side,
which
has
all
these
issues
and
then
you'll
be
doing
all
of
your
work
in
the
workshop
project
that
you
fored
into
your
sandbox
subgroup
on
gab.com.
A
A
A
Right
sounds
great,
so
we've
gone
through
the
forking
process,
we've
removed
the
fork
relationship
and
I've
helped
you
identify
where
we're
going
to
be
working
through
the
workshop
steps,
which
is
on
the
source
project.
So
now,
let's
go
ahead
and
just
jump
right
into
the
main
content
of
our
Workshop
today.
So
first
we're
going
to
talk
about
shifting
left,
which
is
a
common
term
used
in
the
devops
industry
and
what
that
means
within
the
gitlab
context.
A
All
right
so,
first,
we
want
to
take
advantage
of
how
gitlab
enables
us
to
shift
left
and
capture
our
security
mistakes
right
at
the
merge
request.
Instead
of
month
later,
when
it's
spotted
by
a
random
security
scan
that
happens
on
production.
Well,
we
will
review
the
code
that
enables
security
scans
and
create
a
merge
request
to
bring
it
into
the
main
or
default
Branch.
A
The
shiting
left
is
a
fundamental
devops
practice
and
helps
discover
issues
with
code
much
earlier
in
the
delivery
value
stream,
rather
than
finding
those
problems
much
later
on,
where
it
can
be
harder
or
more
costly
to
correct
So
within
the
gitlab
context,
I'm,
showing
you
the
gitlab
flow
and
how
we're
shifting
left
within
today's
Workshop
so
we're
moving
the
detection,
communication
and
Remediation
of
vulnerabilities
much
closer
to
where
the
developer
developer
begins
their
changes
right
on
the
feature
Branch.
A
So
when
working
in
the
gitlab
flow,
you
may
create
an
issue
of
work
that
needs
to
be
done
by
the
developer
and
when
they
start
doing
that
work
they
create
that
feature
branch
and
then
they
create
a
merge
request
when
they
want
to
merge
that
the
work
that
they're
doing
on
that
feature
Branch
into
that
default
or
Master,
Branch
creting
their
changes
and
then
the
CI
pipeline
runs
and
within
the
CI
pipeline.
A
We've
introduced
security
scans,
such
as
secret
detection,
scanning
container
scanning,
so
on
and
so
forth,
we've
got
a
review
app
that
gets
spun
up.
It's
an
eeral
environment.
We
could
be
potentially
performing
Das
scanning
as
well.
On
a
infal
environment.
Discussion
happens,
you
know,
code
and
Security
reviews.
Even
with
you
know
these.
What
we
call
Scan
results,
policies
to
essentially
enforce
a
mer,
merge,
request,
approval
rule
if
a
certain
level
of
vulnerability
has
been
detected.
Within
that
merge
re
Quest.
You
know
security
teams
can
improve
those
changes.
A
If
it's
determined
that
you
know
that
the
vulnerability
is
a
false
positive
or
the
vulnerability
has
been
remediated
and
the
merge
request,
approval
is
no
longer
needed.
Then
the
merges
happen
to
the
default
branch
and
the
issues
closed.
And
then
you
have
your
pipeline
to
run
the
CD
the
deployment
to
your
target
environment
for
your
production.
So
that's
just
an
idea
of
what
we
call
shifting
left
within
the
gitlab
context
and
just
wanted
to
highlight
what
we're
going
to
be
doing
today
in
our
Hands-On
Workshop,
all
right.
A
So
that's
a
brief
overview
of
Shifting
left.
Let's
go
ahead
and
switch
to
my
other
screen
here
and
what
you'll
be
doing
on
your
end
is
having
that
source
project
with
the
issues
on
the
leth
hand,
side
I'll
drop
a
link
there.
A
You
don't
have
that
yet
and
on
the
right
hand,
side
it's
the
the
lab
setup
or
the
the
sandbox
project
that
you
forked
into
your
subgroup
called
Workshop
project
and,
and
so
what
we're
going
to
do
here
is
we're
going
to
start
with
this
first
issue
in
the
source
project
called
shifting
left
we're
going
to
click
into
that
and
follow
the
instructions
here.
So
this
section
focuses
on
shifting
left
as
a
security
practice
and
how
our
code
changes
will
display
security
results
after
a
commit,
rather
than
mons
down
the
line.
A
So
first
we
want
to
add
all
the
security
scans
to
this
Workshop
project.
So
first
we
want
to
make
sure
we're
on
the
main
page
of
this
project.
You
can
click
the
breadcrumb
of
our
sandbox
project
within
our
provision
test
group,
that's
on
the
main
page
now
and
then
once
we're
ready
we're
going
to
go
ahead
and
go
to
the
pipeline
Editor
to
edit
our
gitlab
CMO
file
to
introduce
the
shifting
left
strategy
go
into
the
main
navigation
go
to
build
then
go
to
pipeline
editor.
A
This
allows
us
to
quickly
edit
our
gitlab
CI
ammo
file
directly
within
the
gitlab
UI,
and
it
has
a
built-in
linter
in
case.
We
make
any
mistakes
as
well.
So
what
we're
going
to
do
we're
just
going
to
take
a
look
at
the
current
setup
of
our
pipeline
automation
through
the
gitlab
CMO
file
in
the
sandbox
project.
It's
pretty
simple.
We've
only
got
a
build
stage
and
we've
got
the
build
job
defined
within
the
build
stage.
A
What
we
want
to
do
is
go
ahead
and
create
a
new
Branch,
so
this
is
actually
looking
at
the
gitlab
CMO
file
on
the
main
branch,
but
we're
going
to
want
to
create
a
new
Branch
to
start
to
introduce
the
shifting
left
strategy.
So
you'll
want
to
go
to
the
main
navigation
go
to
code,
then
go
to
branches,
then
we're
going
to
go
ahead
and
click
new
Branch
here
from
the
branches
page
within
our
sandbox
project.
A
We're
going
to
call
this
new
branch
called
completed
pipeline,
completed
Das
Pipeline
and
we're
going
to
create
that
from
the
main
or
default
Branch
we're
going
to
click.
The
blue
create
Branch
button,
and
so
now,
once
youve
created
a
new
Branch,
you
should
be
redirected
back
to
the
main
repository
page
and
you
should
see
in
this
drop-
down
menu
that
we're
on
the
completed
pipeline
branch
that
we
just
created.
So
now
we
can
go
back
to
the
pipeline.
A
So
what
we
want
to
do
make
sure
we're
in
the
completed
pipeline
branch
in
the
pipeline
editor,
so
it
should
be
already
selected,
but
if
not
make
sure
you
select
completed
Pipeline
and
we're
going
to
copy
this
entire
snippet,
which
is
our
shift
left
strategy
and
I'll,
go
ahead
and
explain
exactly
what
we
needed,
what
it's
all
doing
here,
but
we'll
delete
all
the
contents
of
the
existing
gitlab
CMO
file
on
the
completed
pipeline
branch
and
then
paste
in
that
snippet
that
we
grabbed
from
theuh
Source
issue
working
through
our
Workshop
instructions.
A
So
here
we've
actually
added
many
more
stages
to
our
pipeline.
In
addition
to
the
build
stage,
we've
got
unit
test
feature
staging
clean
up
and
production,
but
more
importantly,
we've
got
an
include
statement
here,
which
includes
different
templates
that
are
vendored
in
or
provided
by,
the
gitlab
engineering
team
that
provide
the
security
scanning
functionality
that
we
wish
to
add
to
this
Workshop
project.
So
we've
got
container
scanning,
we've
got
code,
quality,
dependency
scanning,
SAS
scanning,
secret
detection
and
then
SAS
infrastructure
is
code
scanning.
A
So
all
these
can
be
enabled
just
by
simply
adding
the
relevant
template,
that's
provided
by
gitlab
and
maintained
by
the
gitlab
engineering
team.
So,
if
you're
on
our
SAS
platform,
it's
basically
updated
whenever
we
make
updates
to
the
SAS
platform,
if
you're
a
self-managed
user,
those
updates
to
those
templates
are
updated.
Anytime.
A
You
make
an
update
to
your
self-managed
instance
of
gitlab,
so
you
want
to
make
sure
that
you're
always
up
to
date
as
much
as
possible
to
get
the
latest
changes
and
additions
and
improvements
to
the
security
scan
tools
that
you
might
be
using
within
your
self-manage
instance.
Next,
we've
got
some
definition:
s
of
job
definitions
or
job
statements
here
for
container
scanning
the
dependency
scanning
job,
so
these
are
ways
that
you
can
customize
how
the
security
scan
tools
operate
within
your
project
by
default.
A
You
don't
necessarily
need
to
to
do
this,
but
it
is
a
way
to
better
control
how
the
security
scan
tools
operate.
It's
going
to
be
out
of
scope
for
today's
Workshop
to
go
through
in
detail
what
all
these
different
variables
are,
but
I
definitely
recommend
you
consult
our
technical
documentation
for
each
security
scan
tool
to
get
an
understanding
of
how
you
can
customize
those
security
scan
tools
specifically
for
your
Project's
needs.
A
Yeah.
Let
me
see
here
if
there's
anything
else,
I
should
go
through
I.
Think
one
thing
to
mention,
too,
is
because
we're,
including
these
templates
Upstream
that
are
vendored
in
from
the
gitlab
product
itself.
You'll
notice,
here
in
the
pipeline
editor
clicking
this
tree
icon
that
it's
got
a
link
to
the
specific
gitlab
template
file
for,
say,
container
scanning.
A
There
and
then,
if
you
want
to
see
the
fully
merged
configuration
of
the
all
the
template
files
with
the
existing
content
of
your
gitlab
C.O
file,
the
pipeline
that
you've
built
you
can
click
full
configuration
and
see
all
that
merge
together
all
right
so
now
that
the
changes
are
in
and
there's
no
errors.
There's
the
syntax
is
all
correct.
We're
going
to
go
ahead
and
change
the
commit
message
say:
shifting
left
and
we're
going
to
commit
those
changes
to
the
completed
pipeline.
A
Branch
all
right,
so
what
we
want
to
do
is
create
the
merge
request.
Now
that
we've
created
the
shift
left
strategy
and
we
want
to
introduce
that
into
our
main
or
default
Branch
so
to
actually
merge
this
code,
we
want
to
go
back
into
our
main
navigation
here
then
going
go
to
code,
then
branches,
and
then
from
here
we're
going
to
click.
A
This
new
merge
request
button
in
the
row
of
the
completed
pipeline
Branch,
that's
active,
we're
going
to
click
that
button
on
the
completed
pipeline
branch
and
the
merge
request
could
just
be
the
same
as
the
the
commit
message
that
we
added
shifting
left
and
what
we
want
to
do
here
is
make
sure
that
the
delete,
Source
Branch
when
merge
request
is
accepted
is
unchecked.
So
we
still
maintain
this.
This
feature
branch
that
we
created
and
go
ahead
and
click
merge,
request
or
create
merge
request.
A
It's
important
that
you
remove
that
fork
relationship
before
doing
this,
to
make
sure
that
that
merge
request
shows
up
in
your
Workshop
project
and
yeah.
Now
that
I've
created
a
merge
request,
we
can
see
that
there's
a
pipeline
L
running
on
this
merg
quest.
If
we
go
ahead
and
click
into
this,
we
could
see
some
of
the
U
shift
left
strategy
already
happening
within
the
merg
quest
based
on
the
completed
pipeline
Branch.
A
All
right,
you
don't
need
to
actually
run
the
pipeline
again,
it's
only
if,
for,
for
example,
this
pipeline
didn't
get
kicked
off
automatically,
but
that
instruction
is
there.
Just
in
case
you
didn't
see
the
the
latest
pipeline
for
shifting
left
and
adding
all
the
security
scan
tools
to
gitlab
C
file,
all
right,
so
that
takes
us
through
that
first
issue
within
our
Workshop
today,
we'll
go
back
to
my
slides
here
and
go
and
talk
talk
to
you
a
little
bit
more
about
the
compliance
framework.
A
A
Going
all
right
so
with
the
compliance
framework
just
looking
at
a
road
map
here,
let's
want
to
review
shifting
left.
A
We
were
able
to
set
up
security
scanning
directly
in
our
project
by
adding
those
security
scan
tool
templates
to
our
gitlab
CMO
file
and
then
started
merge
request,
bringing
in
that
new
shift
left
strategy
into
the
main
branch
we'll
leave
that
running
in
the
background,
and
then
we
can
start
to
look
at
what
it's
doing
there
after
we
get
through
these
slides
here,
but
for
this
next
section
we're
going
to
be
implementing
a
compliance
framework.
A
So
now
that
we've
started
to
define
a
new
pipeline
for
security
tests,
we
decide
that
we
want
all
the
developers
to
abide
by
security,
best
practices
as
well.
What
we're
going
to
do
here
is
we're
going
to
enable
compliance
framework
on
our
project,
which
is
essentially
a
label
to
ensure
that
the
right
jobs
are
run
in
the
correct
order,
so
that
developers
can't
skip
a
a
few
steps
just
to
push
out
a
new
feature,
and
so,
for
this
feature,
compliance
Frameworks
and
compliance
pipelines.
A
You
know
Gil
lab
has
developed
this
feature
to
enable
you
to
abide
by
any
number
of
compliance
policies
that
might
be
listed
here
on
the
right
that
your
organization
might
be
concerned
about.
So
some
of
these
might
be
familiar
to.
You
may
vary
from
region
to
region,
and
so
what
you
can
do
within
gitlab
is
to
create
what
we
call
compliance
framework.
A
It's
called
essentially
it's
a
label
that
you
can
apply
to
projects
or
groups
of
projects
that
would
map
to
specific
audit
protocols
or
some
compliance
needs,
such
as
Hippa
or
sock
2.
To
help
maintain
that
audit
Trail
and
manage
compliance
programs,
then
you've
got
the
compliance
framework
pipelines
which
you
can
associate
with
the
compliance
framework,
so
essentially
a
default
pipeline
or
pipeline
that
needs
to
be
applied
pipeline
configuration
that
needs
to
be
applied
to
any
project
that
has
that
compliance
framework
applied
to
it.
A
So
you
know
these
could
be
jobs
that
you've
defined
in
this
compliance
pipeline
that
need
to
run
on
every
single
project
that
has
that
compliance
framework
applies.
It
I'll
get
to
it
in
in
a
more
Hands-On
example,
when
we
go
through
the
workshop
instructions,
but
at
a
high
level
it's
really
a
great
way
for
you
to
ensure
that
you
know
certain
things
are
always
happening
within
your
gitlab
pipelines
that
developers
won't
be
able
to
override
or
or
not
won't
be
able
to
change,
but
they
can
add
on
to
it.
A
They
just
won't
be
able
to
remove,
say,
for
example,
that
job
that
you
defin
Upstream
in
the
compliance
pipeline,
so
the
benefits
of
gitlab's
compliance
pipelines
and
compliance
Frameworks.
It
really
have
make
sure
that
your
development
teams
are
following
best
practices
when
it
comes
to
security
and
compliance
compliance
features
can
be
applied
to
many
different
projects,
making
it
really
easy
to
maintain
how
that
governance
happens.
A
Within
in
your
organization,
you
can
simply
create
that
single
compliance,
Pipeline
and
compliance
framework
and
apply
that
across
the
board
to
many
different
projects
so
that
they
have
to
inherit
or
utilize
what
you
have
to
find
in
that
compliance
pipeline
again,
this
prevents
developers
from
skipping
the
necessary
scans.
It
could
be
a
security
scan.
A
Some
type
of
quality
scan
anything
else
that
your
organization
requires
is
part
of
that
compliance
on
those
specific
projects
when
they
might
be
trying
to
push
out
a
feature
or
a
change
at
the
last
minute,
and
you
can
utilize
this,
of
course,
external
scans
as
well.
It's
really
super
flexible,
it's
whatever
you
can
Define
in
a
gitlab
CMO
file.
Whatever
you
can
script
there,
that's
exactly
what
you
can
enforce
through
compliance
Frameworks
and
compliance
pipelines.
So
let's
get
hands
on
with
this
again.
A
We'll
switch
back
to
my
other
screen
here
and
we're
going
to
go
into
issue
two
of
the
source
project
and
go
to
compliance
framework.
So
for
this
we're
going
to
be
creating
a
compliance
framework
that
will
ensure
our
pipeline
runs
the
correct
jobs
in
the
right
order.
That
will
ensure
our
Dev
team
won't
be
able
to
skip
a
few
steps
in
the
pipeline
and
might
be
able
to
introduce
a
vulnerability
by
skipping
those
steps
so
for
step,
one
defining
our
framework,
the
framework's
luckily
been
predefined
for
us.
A
You
can
navigate
in
a
new
tab
by
clicking
this
link
here
to
essentially
see
where
that's
been
defined.
This
compliance
framework
pipeline
in
a
a
separate
project,
Within
the
same
group
hierarchy.
If
you
click
this
compliance,
dgab
C.O
file,
you
can
see
exactly
what
it's
going
to
enforce
on
this
Workshop
project
that
we've
created
in
our
sandbox
environment.
It's
got
a
specific
order
of
stages.
Do
pre
build
unit
test
and
cleanup.
A
So
any
of
these
stages
that
are
defined
in
this
order
can't
be
removed
U,
but
you
can
certainly
add
on
additional
stages.
If
you
need
to
the
compliance.
Job
has
been
defined
here
and
it's
going
to
run
in
the
pre-stage
so
that
compliance
job
will
always
run
in
the
do
pre-stage
before
all
the
other
stages
are
executing
within
the
assigned
projects
pipeline
so,
and
it
simply
just
going
to
Echo
out
this
message
in
the
in
the
job
log.
A
And
lastly,
this
last
four
lines
here
is
just
to
make
sure
that
the
individual
projects
configuration
continues
to
be
added
on
on
top
of
the
compliance
pipeline.
That
gets
applied
to
this
project,
and
so
that's
that's
a
mandatory
thing.
It's
something
that
you
apply
by
default
for
all
projects
or
for
all
compliance
pipelines.
We'll
close,
this
out
just
wanted
to
explain
what
the
compliance
pipeline
was
and
what
what
our
project
will
be,
inheriting
from
all
right
so
applying
the
framework.
A
So
what
we
can
do
here
is
go
to
the
workshop
project
in
our
breadcrumbs
as
we're
going
to
the
main
navigation
and
go
to
settings
we're
going
to
apply
the
compliance
framework,
which
is
essentially
a
label
that
has
that
compliance
pipeline
assigned
to
it.
So
we're
going
to
go
to
settings
in
general
in
our
Workshop
project,
scroll
down
in
the
middle
there
you'll
find
compliance
framework,
expand
that
and
then
choose
our
framework.
It's
going
to
be
security
and
compliance.
Workshop
save.
A
Changes
and
it's
going
to
show
you
here
as
a
label
that
the
security
compliance
Workshop
compliance
framework
has
been
applied
here
here.
So
now,
if
we
go
back,
if
we
were
to
run
another
pipeline
in
the
future
on
this
project,
then
we
can
actually
simulate
that
now.
If
we
run
a
pipeline
just
on
even
just
the
main
branch
it
doesn't
matter,
we
run
that
pipeline.
A
We
can
see
that
the
compliance
job
has
been
inherited
now
and
the
do
pre-stage
has
been
added
without
us
actually
adding
or
making
any
modifications
to
the
workshop
project.
Gitlab
C.O
file
right.
So
that's
inheriting
that
compliance
pipeline
through
the
compliance
framework
that
we've
applied
to
this
Workshop
project,
all
right,
so
that's
it
actually
for
for
the
second
issue
here
in
our
Hands-On
exercise.
A
Well,
you
can
find
the
relevant
documentation
here
to
see
how
the
pipeline
compliance
pipeline
is
created
and
associated
with
the
compliance
framework
label,
but
that
is
out
of
scope
for
today's
Workshop.
So
just
make
sure
you
read
the
docs
on
that,
if
you're
interested
on
seeing
how
that
works
and
how
it's
configured,
but
that's
actually
how
it's
applied
and
how
the
the
compliance
pipeline
gets.
A
Inherited
all
right,
we're
on
to
lap
three
section:
three
parsing
the
results.
So,
as
a
quick
recap,
we've
seen
we've
been
able
to
extend
the
cicd
configuration
with
the
compliance
framework
actions
just
by
adding
the
compliance
framework
label
to
the
project
via
the
settings
and
that'll
ensure
that
the
relevant
card
rails
for
our
development
team
are
in
place,
and
you
can
look
to
applying
that
for
your
own
projects
if
you've
got
the
ultimate
subscription
for
your
organization,
all
right.
So
for
this
section.
A
Now
that
our
merge
request
pipeline
is
completed,
we
know
that
it
works.
We
want
to
merge
it
into
the
main
or
default
Branch.
Let's
take
a
look
at
the
scan
results
and
create
any
policies
that
we
need
to
prevent
security
breaches
in
the
future,
so
just
as
an
overview,
I
kind
of
went
through
the
the
security
scanners
that
we're
using
by
looking
at
the
included
templates.
I
can
go
through
that
again.
A
Here
we've
got
the
static
application,
security
testing
or
SAS
scanner,
which
analyzes
a
source
code
for
known
vulnerabilities
that
are
included
as
part
of
the
development.
It's
just
the
source
code,
not
the
actual,
compile
code,
dynamic
application,
security
testing,
which
I
didn't
include
as
a
template,
but
we'll
talk
about
how
to
create
an
on
demand
scan
that
will
basically
allow
us
to
potentially
schedule
a
Das
scan
of
our
project
that
analyzes
the
running
application
on
a
deployed
environment
for
known
vulnerabilities
by
seeking
to
hack
into
the
application.
A
Next
we've
got
container
scanning,
which
scans
Docker
images
that
your
application,
or
that
your
project
might
be
building
for
known
vulnerabilities
in
the
built
application
container,
as
well
as
any
base
IM
that
you're
leveraging
as
well
dependency
scanning
will
scan
project
dependencies
for
known
vulnerabilities,
reported
in
open
source
components.
A
So,
if
you're
using
any
type
of
dependency
manager,
we'
got
a
large
array
of
support
across
different
package
managers
and
dependency
managers,
and
so
chances
are
you'll,
be
able
to
leverage
our
dependency
scanning
feature
to
look
at
those
dependencies
and
see
if
there's
any
known
vulnerabilities
for
the
dependencies
that
you're
pulling
into
your
project.
Next,
we've
got
license
scanning,
so
it
scans
the
the
licenses
of
included
open
source
components
to
determine
if
they're
compatible
with
a
set
policy.
We'll
be
talking
about
and
I'll
actually
be
showing
you
in
a
Hands-On
demonstration.
A
You
know
how
to
create
a
a
licensed
compliance
policy
to
make
sure
that
you're,
not
including
any
specific,
open
source
licenses
in
in
your
project,
to
prevent
any
legal
implications
or
legal
issues
with
your
project
and
finally,
we've
got
secret
detection,
just
as
it
sounds
scans
for
Secrets,
checked
into
the
source
code
and
I'll.
Warn
you
if,
if
there's
a
secret,
that's
been
detected
and
if
it's
a
gitlab
token,
it
could
also
automatically
revoke
any
G
lab
tokens.
A
But
if
it's
a
any
other
type
of
secret
it'll
simply
notify
you
and
then
it's
up
to
your
team
to
revoke
and
rotate
the
that
that
secret
and
remove
that
from
the
source
code
right
and
we've
got
just
a
simple
kind
of
screenshot
here,
showing
all
the
scanners
in
different
stages.
A
Right
now,
all
those
scanners
are
happening
in
the
test
stage,
but
certainly
you
can.
You
can
modify
that
as
well.
You
can
override
the
stage
that
any
analyzer
you
add
through
the
templates
to
you
know
be
in
its
own
stage.
A
If
you
want
to
create
a
security
stage,
for
example,
but
really
what
this
is
illustrating,
is
that
we're
enabling
the
quickest
feedback
to
the
developer
right
in
the
pipeline
of
the
merge
request,
as
they
push
changes
to
their
feature,
Branch,
where
they
can
review
the
finding
in
the
security
tab.
So
just
a
brief
discussion
policies
I
touched
on
this
earlier.
A
This
is
one
of
the
many
reasons
that
a
lot
of
our
customers
move
to
to
gitlab
and
gitlab
ultimate
is
the
ability
to
create
governance
and
enforce
security
and
licensed
compliance
policies
across
all
of
their
projects
in
their
organization.
So
the
there's
two
different
types
of
policies
you've
got
the
scan
result
policy,
which
is
essentially
a
dynamic,
merge,
request,
approval
rule
that
will
allow
you
to
create
a
mandatory
approval
and
block
a
merge
to
say
a
default
Branch.
A
A
So
if
you
wanted
to
enforce
SAS
scanning
or
dependency
scanning,
you
can
do
that
easily
with
scan
execution
policies
and
if
you
wanted
to
run,
say
Das
scanning
on
a
specific
schedule,
you
could
do
that
through
scan
execution
policies
as
well.
So
let's
go
ahead
and
go
handson
again
in
the
Workshop
project
here,
so
we're
going
to
go
back
into
the
source
project
here.
A
A
We
just
want
to
demonstrate
this
to
generate
all
the
security
reports
that
you
could
see
at
the
at
the
project
level,
so
we're
going
to
go
ahead
and
go
back
into
the
merge
requests
so
in
our
Workshop
project,
we're
going
to
open
up
the
main
navigation
and
we're
going
to
go
to
code
and
merge
request
and
we're
going
to
go
to
our
shifting
left,
merge
request.
It
might
have
been
named
differently
if
you
use
a
different,
commit
messager
name
for
the
merge
request
itself
and
then
right
below
the
approval
section.
A
Approval
is
optional
right
now,
because
we
don't
have
any
approval,
rules
or
scan
result
policies
yet,
but
we'll
get
into
that
a
little
bit
after
this
we
do
see
some
merge
request
widgets.
So
these
are
kind
of
easy
ways
for
you
to
better
understand.
Excuse
me:
the
the
results
of
security
scan
tools
that
we've
implemented
in
our
sh
shift
left
strategy.
So
we've
got
the
license
compliance
widget
here
says
it's
detected
eight
licenses
for
the
source
Branch.
A
If
you
open
up
that
widget,
you
can
see
some
of
these
licenses
that
are
used
and
what
packages
are
using
that
specific
license.
If
you
click
into
it,
you
can
see
exactly
what
those
packages
are,
so
the
Pache
license
1.0
is
used
by
this
package,
and
this
package
same
with
the
MIT
license.
We're
actually
going
to
be
working
on,
creating
a
a
scan
result
policy
to
make
sure
that
or
licensed
compliance
policy
to
make
sure
we're
not
including
the
MIT
license
on
feature
changes
to
our
project.
A
So
that's
just
the
Insight
on
the
license:
compliance
widget
here
code
quality
same
thing:
we
can
see
kind
of
results
of
the
code
quality
scan
we've
got
the
security
scanning,
so
this
is
important
here.
This
is
all
the
security
scan
tools
all
rolled
into
one
widget
for
the
security
scanning.
A
We've
got
SAS
secret
detection
dependency
scanning
container
scanning
all
the
security
vulnerability
findings
based
on
the
Source
branch,
and
we've
got
some
critical
findings
here,
based
on
the
the
SAS
scanner,
25
critical,
zero
High,
zero
others,
you
could
see
all
of
them
here
and
if
you
click
into
one
of
them,
you
could
see
the
vulnerability
a
little
bit
more
information
about
it.
The
file
that
it
was
detected
in
the
specific
line.
A
If
you
click
into
that
it'll
go
directly
into
that
that
file
and
that
specific
line,
you
can
take
a
review
of
what
was
being
changed
on
that
Source
branch
and
what
introduced
that
vulnerability
got
some
identifiers
to
help
you
understand
from
some
documentation
that
might
help
you
understand
what
the
vulnerability
is
and
why
it's
creating
a
vulnerability
for
your
application.
What
tool
essentially
found
that
vulnerability
and
the
potential
severity
there?
You've
also
got
the
ability
to
dismiss
the
vulnerability
directly
from
this.
A
A
Strategy
We'll
add
a
comment
dismiss
it
and
that
should
remove
it
there
or
that
should
say
Market
has
dismissed
and
you
could
do
the
same
throughout
all
these
different
vulnerabilities
here.
Well,
let's
just
say
we're
feeling
a
little
bit
risky
here,
we'll
just
go
ahead
and
merge
the
the
future
brand
and
get
get
that
into
our
main
branch
just
for
demonstration
purposes
today,
so
we're
going
to
create
that
pipeline
for
the
main
branch,
the
the
changes
have
been
made
and
committed
to
the
main
branch.
A
You
see
that
here,
if
we
go
back
to
the
workshop
project
through
our
breadcrumbs
and
you
go
to
the
gate,
lab
CMO
file,
we'll
see
we'll
see
our
shift
left
strategy
with
all
the
template
files
that
we've
included
here.
So
we
should
see
also
that
a
a
pipeline
has
been
kicked
off
on
the
main
or
default
Branch.
A
If
we
go
back
into
code
or
build
and
then
pipelines
from
the
main
navigation
of
our
Workshop
project,
we'll
see
this
merge
Branch
pipeline
into
Main
and
the
pipeline
that's
been
created,
so
essentially
the
results.
So
we've
got
the
the
scan
scan
tools.
The
security
scan
tools
already
running
on
the
main
branch.
Now,
once
this
pipeline
is
completed,
we'll
be
able
to
actually
see
all
of
the
security
results
from
the
project
level.
A
So
everything
that
we
were
reviewing
in
that
feature
Branch
was
just
isolated
to
the
merge
request
and
the
merge
request
widgets.
But
if
there's
any
vulnerabilities
found
on
the
main
or
default,
Branch
that'll
actually
show
up
at
the
at
the
project
level,
within
the
main
navigation,
secure
and
the
security
dashboard
and
vulnerability
report.
Since
the
pipeline
is
still
running
here
on
this
sandbox
project,
ahead
of
today's
Workshop
I
went,
went
ahead
and
ran
the
pipeline
on
another
copy
of
of
the
the
project
call
completed.
A
So
this
is
not
something
that
you
should
expect
to
see
here
in
yours
just
yet,
because
the
pipeline
is
still
running,
but
I
wanted
to
show
you
what
it
looks
like
once
the
pipeline
is
completed.
So
again,
this
is
a
the
same
project
that
was
forked
in
another
copy.
We've
got
the
security
scan
tools
on
the
main
branch,
and
the
pipeline
is
already
completed
there.
You
can
see
it
completed
on
the
this
latest.
A
One
of
these
latest
pipelines
run
on
this
separate
project
that
I
created
and
if
I
were
to
go
into
the
main
navigation,
secure
and
vulnerability
report
you'll
see
now.
These
are
all
the
active
vulnerabilities
that
have
been
found
and
discovered
on
the
the
main
or
default
branch
of
our
project
U.
So
this
is
where
you
do
all
of
your
vulnerability
management
within
gitlab.
A
If
you
need
to
create
work
based
on
vulnerability,
ities
that
are
already
existing
in
the
project
again,
this
is
only
populated
when
you
do
those
security
scans
on
the
default
branch
of
your
project.
One
cool
thing
that
is
actually
just
recently
released
in
gitlab
16.4
was
the
vulnerability
bulk
status
updates.
I'm,
going
to
put
a
link
here
in
the
chat
on
our
release.
Notes
on
this.
This
is
a
really
re
recent
release,
part
of
16.4.
You
can
essentially
select
many
different
vulnerabilities
and
do
a
bulk
status
update.
A
Let's
just
say
these
are
all
false
positives.
You
know
we
could
say
dismiss
on
all
of
them,
call
it
a
false,
positive
and
add
a
comment,
false
positives
and
then
change
the
status.
So
this
is
a
kind
of
efficiency
savings.
I've
talked
to
at
least
one
customer
in
the
past.
That's
asked
for
this
feature
and
I'm
glad
to
see
this
now
in
place.
So
just
a
tip
for
you
all.
If,
if
you're
on
this
s
platform,
it
should
already
be
available.
A
If
you're
a
self-,
bandaged
customer
make
sure
you
get
up
to
16.4,
so
you
can
start
taking
advantage
of
that
productivity
Improvement
to
the
vulnerability
management
process,
all
right,
so
just
going
back
here,
let's
see
here,
you
know
one
of
the
other
things
that
I
wanted
to
show
you,
but
didn't
get
to
do
this
in
time
was
the
security
dashboard
based
on
the
workshop
project.
This
is
a
you
know,
essentially
a
view
into
the
vulnerabilities
and
their
accounts
over
time.
A
So
you
can
kind
of
track
your
work
as
you
secure
your
project
on
a
daily
basis,
and
so
this,
the
security
dashboard.
This
graph
of
all
the
vulnerabilities
found
in
the
default
branch
is
only
updated,
daily,
at5
UTC,
so,
unfortunately,
I'm
not
able
to
show
you.
This
live
through
the
workshop
project,
but
I've
got
a
live
example
that
you
could
see
here
from
link
from
the
instructions
on
another
project.
A
This
is
just
kind
of
like
an
example
project
that
doesn't
have
a
lot
of
activity,
but
you
know
you
can
imagine
if
we're
remediating
or
resolving
those
vulnerabilities
over
time
you'll
see
the
number
of
criticals
go
down.
Number
of
highs,
go
down,
you'll,
see
those
kind
of
like
lines
go
down
and,
as
more
scans
happen
on
our
project
on
a
regular
basis,
it
might
go
up
if
more
vulnerabilities
are
introduced
as
well.
It's
kind
of
a
good
way
to
track
progress,
all
right
step
three
here
so
step.
A
Two
was
just
all
about
showing
you
what
the
project
level
views
are
on
security,
looking
at
security
vulnerabilities
over
time
in
your
project,
as
well
as
doing
your
vulnerability
management
through
the
vulnerability
reports.
So
next
let's
go
ahead
and
add
in
some
security
policies
to
prevent
some
of
these
things
from
happening
in
the
future.
I'm
going
to
go
back
into
my
sandbox
group
here
and
go
back
to
the
workshop
project.
A
So
I
can
do
this
fresh
for
you
all
so
on
the
lefthand
navigation
I'm
going
to
go
to
secure
and
then
policies,
then,
from
here
I'm
going
to
go
ahead
and
click.
The
new
policy
button,
this
next
page
I'm,
going
to
create
a
scan
result
policy,
so
I'll
click.
The
blue,
select
policy
button
under
scan
result
policy
and
I'm
going
to
create
an
approval
policy
based
on
secrets
that
are
found
in
our
project.
I'm,
going
to
call
it
secret
detection
approval
policy,
leave
the
description.
Blank
make
sure
it's
enabled
and
then
for
the
rules.
A
The
scan
type
will
be
a
security
scan
I'm
going
to
make
sure
it's
just
selecting
the
secret
protection
scanner
for
this
Rule
and
it's
going
to
run
against
a
default
Branch.
Instead
of
all
all
protected
branches.
This
no
exceptions,
drop
down
is
a
new
feature
that
was
recently
added.
It
allows
you
to
create
exceptions
based
on
different
branches.
That
may
not
need
this
rule
applied
to
it,
but
we'll
leave
it
at
no
exceptions,
since
we
want
to
make
sure
it
applies
to.
A
You
know
just
the
default
Branch
with
no
exceptions
and
we're
going
to
make
sure
it
finds
any
vulnerabilities
that
match
all
of
the
following
criteria.
So
the
severity
is
all
severity
levels
doesn't
matter
what
severity
level
the
secret
is
that's
an
issue
we
want
to
block
the
merge.
The
status
is
new
and
all
vulnerability
States.
You
can
change
this
to
previously
existing
too.
A
If
you
wanted
to
catch
any
secrets
that
have
been
committed
in
the
past
as
well,
and
you
can
select
all
vulnerability
States
as
well,
but
we'll
just
do
new,
because
there's
no
secrets
protected
right
now
go
all
the
way
down
and
for
actions
we're
going
to
require
one
approval
from
an
individual
user.
So
you
can
use
this
to
spe.
A
Select
specific
team
members
such
as
a
secur
security
team,
member
or
even
groups
within
your
group
hierarchy
that
have
team
members
that
are
that
should
be
reviewing
these
potential
vulnerabilities
caught
by
the
secret
detector,
secret
detection
tool
and
approving
or
reviewing
to
see
if
it
is
a
true,
positive
or
false,
negative
or
false,
true,
positive
or
false
positive.
A
So
we're
going
to
require
approval
from
an
individual
user
called
Logan
Stucker
he's
one
of
our
team
members
that
helped
create
these
workshops
for
us
and
we're
going
to
configure
with
emerge
request,
and
so
what
it's
actually
doing.
It's
going
to
create
a
new
project
within
your
group
hierarchy
for
the
security
policy
that
you're
applying
to
this
project
and
it's
going
to
create
that
security
policy
or
scan
result
polic
as
code.
So
we're
going
to
go
ahead
and
merge
that
scam
policy
that's
created.
You
can
see
that
there.
A
If
you
go
into
the
Workshop
project
security
security
policy
project
in
the
breadcrumb,
you
could
see
it's
created
this
directory
within
this
project
and
the
policy.
yaml,
so
that
policy
is
now
stored
as
code
and
it's
been
applied
to
our
project.
So
we
want
to
go
back
to
our
our
Workshop
project
here
and
we
can
see
that
living
alongside
it
there.
A
So
now,
if
we
were
to
create
another
merge
request
with
a
leak
token
in
the
codebase
merging
would
be
prevented
until
it's
removed,
or
we
added
our
approval
to
allow
that
merge
to
actually
happen
all
right.
So,
let's
go
ahead
and
simulate
adding
the
secret
to
our
project,
we're
going
to
go
ahead
and
go
back
to
our
Workshop
project
and
we're
going
toh
copy.
A
This
simulated
secret
here
go
into
the
edit
dropdown
of
the
Repository
view
or
Workshop
project
and
click
web
IDE
we're
going
to
make
a
quick
change
to
this
run.py
file
and
underneath
the
first
two
lines
we're
going
to
add
in
the
secret
and
we're
going
to
make
this
commit
to
a
new
Branch.
A
So
we're
going
to
use
this
little
drop
down
arrow
here
next
to
commit
to
main
if
you're
not
familiar
with
the
web,
IDE
I
went
from
the
Explorer
view
to
the
source
control
view
here,
on
the
left
hand,
side
and
then
now
I
can
go
ahead
and
click.
A
This
little
drop
down
button
here
to
commit
to
a
new
Branch
instead
of
the
default
Branch
we're
going
to
leave
it
empty
we're
just
going
to
use
the
suggested
Branch
name
and
we're
going
to
hit
enter
and
then
we're
going
to
create
an
MR
using
this
popup
little
window
here
to
create
the
merge
request
directly
from
the
web.
Ide
made
this
update
to
the
file
and
we're
going
to
make
sure
that
merge
options.
Delete
Source
branch
is
unchecked
here
and
create
the
merge
request
all
right.
A
So
we
can
see
that
the
the
scan
result
policy
has
already
been
applied
here.
It
says
that
it
requires
one
approval
from
Secret
detection
approval
policy
and
if
we
expand
that
you've
got
Logan
Stucker
here
listed
on
this
on
this
row.
So
it's
going
to
run
the
pipeline
here
and
if
it
finds
a
secret,
it's
going
to
require
this
approval.
A
If
it
doesn't
find
a
secret,
then
it's
going
to
say,
approval
is
not
required,
we'll
let
that
run
and
I
can
actually
show
you
in
a
in
a
previous
project
here,
since
we
don't
have
too
much
time
to
let
that
run
and
see
it
live
I'll,
go
into
my
test
group
and
go
to
my
completed
project.
A
And
I
can
see
through
one
of
the
merg
requests
that
I.
A
Created
that
it
does
require
an
approval,
you
can
see
a
different
scan
result
policy
related
to
a
license
compliance
policy
that
I
created,
but
it
does
see
that
secret
a
leak
secret
has
been
detected.
If
you
were
to
expand
the
merge
request
widget,
we
see
that
there's
a
iCal
vulnerability
for
the
AWS
access
token
that
was
detected.
It's
in
that
run
that
P
file.
We
open
that
up.
A
We
can
see
that's
the
one
that
we
added
there
and
so
again,
you'll
need
to
wait
for
the
pipeline
to
complete
within
your
own
Workshop
project,
but
this
is
something
that
I
ran
earlier.
A
So
I
could
show
you
live
on
on
the
workshop
today
again,
you'll
have
access
to
this
Workshop
area
of
gab.com
for
for
two
days,
48
hours
and
so
feel
free
to
keep
playing
with
it
and
waiting
for
those
pipelines
to
complete
and
taking
a
look
at
the
results
in
within
your
own
sandbox
space
and
so
yeah.
We
Wen
we're
not
able
to
merge
because
it's
blocked
because
of
that
scan,
result
policy
for
for
secret
detection
excellent.
So
that
takes
us
through
the
issue.
A
Number
three
looks
like
I've
got
about
six
minutes.
Seven
minutes
left
not
sure
I'll
be
able
to
go
through
everything
here,
but
I'm
going
to
just
talk
a
little
bit
more
about
what
you'll
be
doing
next
and
you
know
if
I
can
show
you
a
little
bit
more
without
walking
you
through
it.
I'll
I'll.
Try
to
do
that
here,
all
right,
so
the
next
section
here
is
on
licensed
compliance
and
Es
bomb
or
software
build
of
materials.
A
So
with
so
many
high
Lev
attacks
appearing
many
headlines,
most
governments
have
started
to
require
a
software
building
materials.
So
we've
decided
that
it's
in
our
best
interest
to
have
these
reports
ready
to
go,
so
we
could
quickly
check
if
we're
affected
by
the
next
breach.
So
this
has
really
been
kind
of
spearheaded
by
the
the
solar
winds.
Fallout
I'm
sure
you
all
are
well
aware
of.
This
I
won't
go
to
too
much
detail.
We
don't
have
too
much
time
now,
but
I
want
to
show
you
more
of
the
Hands-On
section.
A
What
gitlab
provides
is
an
sbom
report
and
we'll
show
you
how
that's
downloaded
it's
in
the
Cyclone
DX
format
which
been
developed
by
OAS
and
it
provides
the
following
information,
provides
the
dependency
name,
inv
version
dependency
licenses.
The
package
used
to
install
the
dependency
dependency
hierarchy,
the
image
scans
in
vulnerability
spound,
including
the
severity
description
and
some
more
details
there.
Let's
go
back
into
the
Hands-On
exercise.
I
can
show
you
this
pretty
quickly
so
with
the
fourth
issue.
A
Here,
I
won't
go
through
it
live,
but
to
review
and
download
your
sbom
report
I.
Think
I
should
be
able
to
do
it
here.
A
Five
minutes
left
all
right,
go
through
this
quick
and
go
to
main
navig
ation,
secure
dependency
list
and
we're
going
to
see
all
the
dependencies
that
have
been
detected
on
our
default
Branch.
If
we
want
to
download
the
software
build
materials,
we
can
also
oh
hold
on
Chie
I'm
on
I'm
on
the
call
I'll
sign
it
in
in
a
second
okay
got
five
minutes
left:
okay,
great
good
job.
A
Okay,
sorry
about
that,
my
son's
home
from
school.
Now,
so
we
can
download
the
self-revealing
materials
by
clicking
the
export
button.
I'm
almost
done
Chazzy,
you
can
go
side.
Can
you
practice
piano,
please
so
we'll
download
the
software
building
materials
by
clicking
that
export
button
on
the
upper
right
hand
corner.
So
it
downloads
the
software
build
materials
as
a
Json
file.
It'll
automatically
kick
off
the
download
here
and
we'll
get
it
into
our
downloads
directory,
and
let's
say
we
want
to
avoid
including
packages
or
software
that
uses
the
MIT
license.
A
We
can
create
a
scan
result.
Policy
license
compli
policy
directly
from
the
secure
main
navigation,
secure
and
policies.
A
Page
click
new
policy
go
under
select
policy
on
the
scan
result,
policy
and
we'll
do
deny
NT
license
we'll
make
sure
the
scan
type
is
license,
scan
it's
going
to
make
sure
it's
looking
at
all
protected
branches
and
then
the
license
status
is
all
so
newly
detected
and
pre-existing
because
we
want
to
make
sure
that
any
existing
packages
are
removed
if
it's
conflicting
or
against
our
license
compliance
policy
and
the
license
is
matching
MIT.
A
So
you
can
use
the
autocomplete
there
to
find
the
specific
license
that
you
want
to
exclude
again
we're
going
to
require
approval
from
an
individual
user
Logan
LF
Stucker,
then
we're
going
to
configure
with
merge,
request
I'm
going
to
merge.
This
merge
request
into
our
scan
result
policy
security
policy
project,
and
that
should
apply
it
now
to
our
Workshop
project.
Go
back
into
the
workshop
project.
We
can
go
to
the
license.
A
Compliance
page
secure,
license
compliance
for
the
main
navigation
and
we
can
see
that
we
are
violating
our
license
compliance
policy
for
the
MIT
license
being
included
now.
So
we
need
to
remove
these
different
components
for
libraries
to
make
sure
we're
we're
in
compliance
with
our
licensed
compliance
policy
and
any
new
merge,
quests
or
changes
that
are
happening
within
our
project.
That
requires
a
merg
request.
Those
merges
will
be
blocked
if
it
includes
the
MIT
license.
A
We've
got
on
demand,
scans,
audit
events
and
more
you'll
be
getting
a
copy
of
today's
slide
deck
as
well
as
you'll
still
have
access
to
the
Source
material
as
well,
so
you
can
kind
of
go
through
it,
but
essentially
this
next
section
here
is
just
showing
you
some
additional
functionality
outside
of
your
shift
left
strategy
to
improve
the
security
posture
of
your
projects
within
your
organization,
we
got
security,
education
tools
that
you
can
enable
to
better
enable
your
developers
to
learn
about
the
security
vulnerabilities
that
are
being
discovered
and
yeah.
A
There's
a
Hands-On
exercise
that
you
can
walk
through
in
the
source
project
to
learn
more
about
how
to
configure
the
that
the
on
demand
scans
that
you
configure
as
well
all
right
so
quickly.
Here,
I
just
want
to
highlight
that
you
can
transfer
the
project
if
you
want
to
keep
your
work
outside
of
the
the
48
hours
that
you
have
access
to
the
the
sandbox
group
and
the
workshop
project.
A
Will
the
ultimate
license
just
keep
in
mind
if
you
transfer
it
to
a
namespace,
such
as
your
organization
group
or
your
personal
name,
space
that
doesn't
have
the
ultimate
license?
You
want
to
have
access
to
the
full
Suite
of
functionality
that
that
we
shared
with
you
today,
but
you
may
want
to
consider
just
keeping
your
work
if
you
want
to
use
that
in
the
future.
On
a
you
know,
a
gitlab.com
trial,
for
example.
A
All
right,
let's
see
here
so
just
want
to
make
sure
that
you
know
how
we
can
help
you
be
successful.
I
just
skipped
over
a
lot
of
slides
here
that
weren't
necessarily
part
of
you
know
what
I
wanted
to
explain
for
the
Workshop
today.
But
you
know
we
can
continue
the
conversation
and
continue
to
help
you
after
today's
Workshop.
So
gitlab
offers
many
different
ways
to
maximize
the
value
of
your
investment
through
different
training
options,
access
to
subject
matter,
experts
and
best
practices.
A
So
we've
got
a
learning
management
system
for
self-paced
learning,
that's
free
for
all
of
our
customers,
that's
through
level
up
that
gitlab.com
and
if
you
want
to
get
a
certification,
you've
got
paid
certifications
as
well
through
that
platform.
If
you
want
to
have
more
Hands-On,
more
lengthy
training
over
multiple
days,
we've
got
private
instructor-led
training
from
our
Professional
Services
team.
A
We've
also
got
monthly
webinars
offered
by
myself
and
other
members
of
the
customer
success
engineering
team
that
are
introductory
presentations
and
Hands-On
workshops
like
you've
gone
through
today
across
multiple
use
cases.
You
can
also
engage
a
customer
success.
Engineer
customer
success
manager,
a
member
of
this
customer
success
team
depending
on
your
eligibility,
and
make
sure
that
you
know
you
can
get
more
best
practice
guidance,
and
you
know
if
you're
interested
in
speaking
with
us
look
for
an
invite
to
to
meet
with
us
after
today's
Workshop.
A
Another
tool
that
I
didn't
mention
here
is
priority:
support
if
you're
a
gitlab
customer
our
support
Engineers
can
help
you
navigate
our
documentation,
how
to
best
leverage,
the
security
scan
tools
and
our
vendor
templates
through
the
security
scan
tools
and
the
vulnerability,
V
vulnerability
management
process.
All
right,
so
apologies
for
going
pretty
quickly.
Here
we
covered
a
lot
of
ground
in
today's
Workshop
I
want
to
thank
you
for
for
joining
in
and
participating
today,
and
you
know
if
there's
any
additional
questions
that
I
could
help
answer.