►
From YouTube: GitLab - DevSecOps and Compliance Webinar
Description
GitLab enables developers and security to work together in a single tool, allowing for proactive security or “shifting left”. This session will cover what GitLab offers, how scan results integrate seamlessly with merge requests, and how to use the Security Dashboard to manage vulnerabilities.
A
Hi
everyone
Welcome
to
our
webinar
session
today
we're
going
to
give
people
just
another
minute
or
so
to
join
us
and
we'll
get
started.
Thank
you.
A
All
right,
let's
jump
in
thanks
again
for
joining
us,
we're
happy
to
have
you
with
us
today.
Our
our
webinar
session
today
is
devsecops
and
gitlab
and
I'm
joined
by
my
colleague,
Forrest
Livengood,
who
will
be
taking
us
through
the
content
before
I
pass
it
over
to
him
just
a
couple
of
housekeeping
items.
First
off
this
webinar
is
being
recorded,
so
you
can
look
for
both
the
recording
and
the
deck
to
be
sent
over
here
in
the
next
day
or
two.
A
B
A
B
All
right,
thanks
Taylor,
so
this
presentation
and
the
work
that
we're
doing
on
Taylor's
team
is
all
in
the
hope
of
providing
more
value
for
your
gitlab
subscription.
That
means
that,
if
you
have
a
question,
like
Taylor
said,
don't
hesitate
to
put
it
in
chat,
also
I'm
going
to
do
my
best
to
save
about
10
minutes
at
the
end
for
q,
a
for
any
questions
that
that
may
come
up.
B
So
my
name
is
Forrest
livinggood
I'm,
a
customer
success
engineer
for
our
strategic
Enterprise
accounts
and
I'm
coming
to
you
from
Nashville
Tennessee.
B
So
let's
jump
into
what
we're
going
to
be
covering
today,
so
we're
going
to
be
going
through
application,
security,
testing
and
Remediation,
and
we're
also
going
to
be
touching
on
policy
compliance
and
auditability
so
to
get
started.
I
wanted
to
dive
in
with
some
information
on
the
cost
of
finding
and
fixing
vulnerabilities
and
how
finding
those
earlier
is
much
less
costly.
B
It's
estimated
that
software
bugs
cost
59.5
billion
dollars
annually
and
the
stages
that
those
are
remediated
at
have
a
great
effect
on
the
cost
of
that.
After
an
application
is
released
into
production,
it
costs
30
times
more
to
fix
the
security
flaws
than
it
doesn't
design
and
15
times
more
than
it
does
in
Dev.
B
So
traditional
appsec
tools
were
built
10
or
more
years
ago
before
today's
modern
software
methodologies,
like
devops
and
daily,
deploys,
the
industry
needs
to
get
beyond
the
simple
shift
left
of
giving
a
Dev
a
light
SAS
with
their
IDE.
We
want
to
lead
a
new
era
where
security
is
baked
into
the
sdlc
with
a
single
application.
That's
purpose
built
for
the
modern
software
Factory.
B
We
have
to
keep
in
mind
that
applications
are
a
prime
target
of
cyber
attacks
and
lack
of
hygiene
allows
proven,
exploits
to
be
reused
and
appsec
tools
are
expensive
and
require
integration
with
both
technology
and
processes.
And
when
we're
thinking
about
shifting
left,
we
have
to
Target
the
dev
and
the
sex
teams
and
security
and
developer
teams
sometimes
lack
the
means
to
collaborate
and
scale
across
silos
and
so
scaling
security,
because
team
scale
means
empowering
Developers.
B
So
perimeters
fade
as
apps
become
portable
code.
Changes
are
happening
faster
with
more
open
source
apis
and
microservices
in
the
mix
and
iterated
development
is
incongruent
with
full
app
security,
scans
and
devsecops
doesn't
scale
well
without
developer,
enablement,
Automation
and
exception
based
security.
B
We
also
have
to
keep
in
mind
that
next
Generation
software
gives
gives
way
to
new
attack
surfaces
and
traditional
appsec
tools
are
usage-based
pricing,
so
you're
penalized
for
scanning
more.
B
With
traditional
appsec
tools,
Dynamic
application,
security,
testing
or
dast
could
be
done
near
the
end
of
the
sdlc,
because
it
requires
a
working
application
to
test
individual
developers.
Work
was
already
merged
into
the
main
branch
and
typically
in
a
dedicated
test
environment
where
QA
tests
could
be
performed
along
with
dast,
because
Das
occurs
so
late
in
the
life
cycle.
Interactive
application
security
testing
was
born
by
instrumenting
the
application
the
app
could
be
automatically
tested
for
security
vulnerabilities,
while
QA
tests
are
done.
The
intent
is
to
enable
the
developers,
but
a
working
test.
B
So
what?
If
you
could
scan
all
of
the
code,
every
time
seamlessly
for
devs,
using
fewer
tools
and
with
devsec
and
Ops
teams
on
the
same
page
and
keep
your
compliance
Auditors
happy
gitlab
enables
this
by
offering
one
application
that
spans
the
entire
sdlc,
including
application
security
testing,
we're
uniquely
positioned
to
truly
improve
the
workflow
of
both
Dev
and
appsec
with
gitlab.
All
of
these
tests
are
automated
into
every
merge
request.
B
B
So
here
is
an
overview
of
the
full
sdlc
life
cycle.
We
have
all
of
the
phases
and
and
stages
here
and
these
stages
weren't
created
by
gitlab.
These
are
created
by
Gartner,
it's
an
industry-wide
standard,
and
this
shows
how
the
gitlab
scanners
and
the
gitlab
security
tools
span
across
all
of
these
different
stages.
B
We've
got
static,
application
security,
testing,
SAS
dependency
scanning,
license
compliance
container
scanning,
dast
and
secrets
detection,
and
all
of
this
is
built
directly
into
the
merge
requests
later
on
in
the
presentation
we're
going
to
be
digging
into
each
one
of
those
in
a
little
bit
more
detail,
but
just
giving
an
overview
of
everything.
That's
included
directly
in
the
merge
requests
across
the
full
sdlc.
B
So
managing
vulnerabilities
is
everyone's
favorite
job
right.
What
do
you
do
when
you
find
10K
vulnerabilities?
Does
this
create
a
new
liability?
Also,
if
you
can't
fix
them
right
away,
are
they
now
an
even
greater
liability,
because
you
know
that
they
exist
with
gitlab?
You
can
automate
the
software
Factory
to
apply
the
policies
that
you
require,
and
now
you
can
focus
on
the
exceptions
not
on
managing
spreadsheets.
B
So
we've
talked
a
little
bit
before
about
you
know
how
we
want
to
to
change
the
to
identify
vulnerabilities
and
deal
with
things
before
the
code
is
merged.
So
what
does
that
mean
before
the
code
is
merged?
It
means
the
accountable
developer,
sees
results
immediately
on
every
change
that
they
made
vulnerability
and
license
risk
are
shown
within
the
pipeline
as
part
of
the
natural
flow.
B
They
can
see
that
everything
passed
and
if
it
didn't
they'll,
see
that
too,
along
with
information
to
help
them
remediate.
The
flaw
with
gitlab
a
review
application
is
spun
up
at
code
commit
before
the
individual
developer's
code
is
merged
into
the
main
branch.
The
developer
can
see
and
test
the
working
application
and
Das
can
scan
in
the
review
app.
B
B
The
key
to
gitlab's
approach
is
scanning
the
code
at
the
point
of
code
commit
before
the
code
changes
ever
leave
the
developers
hands
and
before
the
code
changes
are
mingled
with
others.
This
is
powerful
because
it
provides
real-time
feedback
to
the
developer
of
vulnerabilities
and
their
code
that
they
can
that
they're
still
working
on
and
can
easily
fix.
They
can
resolve
flaws
before
introducing
code
into
the
main
branch
before
others
get
involved.
B
So,
looking
into
this
workflow,
we
see
that
the
work
starts
with
an
issue
and
then,
with
that
issue
you
can
create
a
merge
request
and
this
spins
off
a
feature
Branch
separate
from
the
default
or
main
branch
here.
The
developer
can
do
their
work
and
commit
the
changes,
and
then
the
CI
pipeline
runs
on
the
feature.
Branch.
The
security
scans
happen
directly
in
the
feature
branch,
and
this
moves
the
security
testing
as
close
as
possible
to
the
to
the
developer.
B
B
Then
you
can
go
through
the
approval
process
and
once
everything
is
approved,
the
issue
is
merged
back
in
to
the
main
branch
and
closed
the
CI
pipeline
runs,
and
then
you
can
run
security
scans
and
view
it
on
the
security
dashboard
before
deploying
to
production.
B
So
gitlab
has
a
number
of
security
and
compliance
scanners.
We're
going
over
these
briefly
now
we'll
dive
in
in
a
little
bit
more
detail
later
on
in
the
presentation,
we've
got
SAS
scanners
to
to
look
through
the
static
code
and
and
find
any
vulnerabilities
like
SQL
injection
and
cross-site
scripting
directly
in
the
code.
We
also
have
dependency
scanning
that
looks
for
known
vulnerabilities
in
your
libraries
and
components
and
secrets
detection
to
look
for
credentials,
secrets
and
passwords
in
the
code
and
prevent
that
information
from
getting
merged
into
the
main
branch.
B
We
also
have
infrastructure
as
code
scanning,
so
you
can
use
the
infrastructure
as
code
scanning,
to
scan
your
configuration
files,
terraform
ansible
kubernetes,
any
of
that
for
known
vulnerabilities,
and
then
we
have
the
runtime
scans.
We
have
the
coverage
guided
fuzz
testing,
which
detects
unexpected
behaviors
and
program
at
the
program
method
level
by
passing
arguments.
That's
glass
box
testing,
then
for
our
Dynamic
scans.
We
have
the
dash
scan
and
this
is
a
scan
that
runs
on
the
running
environment,
to
to
get
more
interactive
results
along
with
web
API,
fuzz
testing.
B
So
because
gitlab
is
a
single
application,
we
can
leverage
the
review
app
like
we've,
been
mentioning
previously
a
fully
functioning
app
used
to
test
the
changes
made
to
the
code
and
to
run
Dynamic
appsec
testing
before
the
code
ever
leaves
the
developers
hands
and
before
the
code
is
merged
in
that
flowchart.
Before
we
saw
that
flow,
and
we
can
also
see
here
that
in
the
pipeline
itself,
we've
got
the
different
phases
in
the
test
phase
we're
looking
at
some
of
the
scanners
that
have
run,
we
can
see
container
scanning
dependency
scanning,
license
management
and
sast.
B
And
the
security
vulnerabilities
are
reported
directly
in
the
merge
requests
pipeline
report,
so
you
could
see
when
the
vulnerabilities
are
present
in
a
merge
request.
You
can
easily
deal
with
them,
fix
them
triage
them
before
the
merge
request.
Even
moves
forward
foreign.
A
B
Without
an
incremental
cost,
the
developer
can
remediate
it
now,
while
they're
still
working
on
that
code
or
create
an
issue
with
one
click.
The
dashboard
for
the
security
pro
is
a
roll-up
of
vulnerabilities
remaining
that
the
developer
didn't
resolve
on
their
own.
The
vulnerabilities
can
be
efficiently
captured
as
a
byproduct
of
software
development
and
a
single
tool
also
reduces
the
costs
over
the
approach
to
buy,
integrate
and
maintain
Point
Solutions.
B
So
developers
can
take
action
to
dismiss
the
vulnerabilities
or
create
an
issue
right
in
the
pipeline
workflow.
This
level
of
integration
is
only
possible
because
kitlab
is
a
single
application
for
the
entire
sdlc
gitlab
uses
the
tools
that
developers
already
used
to
create
and
deliver
a
more
secure
application.
B
We
also
have
suggested
solutions
to
automate
remediation
for
some
issues,
we'll
provide
a
suggested
solution,
and
so
that
can
be
easily
implemented
and
directly
resolved
right
in
the
pipeline.
So,
for
instance,
here
we're
looking
at
at
an
issue-
that's
pulled
up
by
the
cve,
and
we
can
see
that
the
solution
is
to
upgrade
that
library
to
the
newest
version,
and
that
can
be
done
automatically.
B
You
can
just
do
a
one-click
remediation
to
to
resolve
that
directly
in
the
merge
request
as
part
of
the
process
and
right
now,
some
of
the
the
suggested
automated
remediations
are
supported
for
dependency
scanning
and
for
our
container
scanning.
B
So
that
was
good
for
for
the
developers
that
are
working
on
the
code
as
they're
dealing
with
these
issues
and
inside
the
merge
request.
But
gitlab
also
provides
a
lot
of
tools
for
visibility
to
security
teams.
B
Here
we
have
an
overview
of
how
the
security
dashboard
looks.
The
security
dashboard
is
designed
for
directors
of
security
and
csos,
and
the
metrics
are
aggregated
by
group
or
at
the
instance
level.
These
are
directionally
directly
actionable.
We
could
see
assignments
and
Milestones
and
also
View
High,
Level,
Trends
and
metrics.
It's
a
great
tool
for
decision
making
and
we've
also
added
security
scoring
to
the
dashboard.
This
allows
you
to
prioritize
what
issues
need
to
be
addressed
and
get
a
quick
glance
at
the
the
health
of
the
individual
projects
yeah.
B
So
the
vulnerability
report
provides
an
overview
of
all
of
the
security
vulnerabilities
in
groups
and
projects.
You
can
drill
down
into
a
vulnerability
for
detailed
information,
the
originating
project
and
file
and
the
metadata
to
analyze
risk.
Then
you
can
take
action
on
these
vulnerabilities
by
creating
an
issue
and
or
dismissing
them.
B
It's
it's
important
to
keep
the
dash
the
security
dashboard
updated.
The
security
dashboard
displays
information
from
the
results
of
the
most
recent
scans
on
the
default
Branch.
The
security
scans
report
performed
every
time
the
branch
is
updated.
B
So
if
the
default
branch
is
updated
and
frequently
scans
are
running
frequently
and
the
information
on
the
security
dashboard
can
become
outdated,
as
new
vulnerabilities
are
discovered
to
ensure
the
information
on
the
security
dashboard
is
regularly
updated,
configure
a
scheduled
pipeline
to
run
a
daily
security
scan.
This
will
update
the
information
displayed
on
the
security
dashboard,
regardless
of
how
often
the
default
branch
is
updated,
a
daily
security
scan
can
can
be
configured
to
only
execute
jobs
that
relate
to
security.
B
This
can
also
help
your
pipeline
efficiency.
If
you
know
that
you
have
a
scheduled
daily
scan
running,
you
can
offload
the
SECU
some
of
the
security
jobs
to
that
that
are
running
on
the
the
main
branch
and
and
help
to
to
Pare
down
the
pipelines
that
you're
running
on
each
individual
merge
request
and
commit.
B
You
can
also
interact
with
vulnerabilities
directly
from
the
dashboard,
so
in
the
dashboard
you
can
see
a
vulnerability,
and
here
you
have
the
ability
to
dismiss
it.
If
it's
not
fixed
or
false
positive,
you
can
confirm
it,
and
this
this
shows
that
it's
been
confirmed
and
that
it
will
be
fixed
and
you
can
also
Mark
it
as
resolved.
So
you
can
verify
the
fix
and
resolve
it.
B
So,
like
I
said
it's
time
to
dive
into
the
the
individual
scanners
and
how
these
can
be
used
so
static
application,
security,
testing
or
SAS
is
a
set
of
technologies
that
are
designed
to
analyze
application,
source
code,
byte
code
and
binaries
for
design
conditions
that
are
indicative
of
security,
vulnerabilities,
SAS,
Solutions
analyze,
an
application
from
the
inside
out
in
a
non-running
state,
so
static
analysis
on
source
code
and
binaries
and
it'll
show
vulnerabilities
before
deployment,
and
it
uses
open
source
tools
installed
as
part
of
gitlab,
and
the
vulnerabilities
are
shown
in
line
in
merge,
request
results
in
the
merge
requests.
B
B
You
can
add
the
the
secret
detection
jobs
as
well
to
to
scan
the
static
code
for
any
of
those
sort
of
vulnerabilities.
B
Some
use
cases
for
sast
is
your
code,
has
a
potentially
potentially
dangerous
attribute
in
a
class
or
unsafe
code
that
can
lead
to
unintended
code
execution.
Those
could
be
found
in
the
SAS
results.
Also,
possibly
your
application
has
a
vulnerable,
cross-site
scripting
attack
that
can
be
leveraged
to
unauthorized
access
to
session
data.
B
So
that's
a
really
good
use
case.
You
want
to
make
sure
to
to
have
SAS
scanning
set
up
and
we'll
be
providing
this
deck
after
the
call.
This
has
a
link
to
the
gitlab
SAS
documentation
and
the
SAS
scanner
can
be
added
to
your
pipelines
through
the
UI
or
by
adding
the
the
SAS
template
directly
in
the
gitlab
CI
yaml
file,
because
the
security
scanners
are
template
based,
they're,
they're,
very
easy
to
to
drop
in
and
to
get
working
in
your
Pipelines.
B
However,
it's
not
necessarily
the
case
that
a
trusted
sign
container
is
secure
to
run
because
vulnerabilities
may
be
discovered
in
some
of
the
software
in
the
container
after
it's
been
signed,
so
container
security
scanning
gitlab
does
The
Following.
We
do
a
static
analysis
on
Docker
images
for
vulnerabilities
in
the
application
environment.
B
B
So
some
of
the
use
cases
for
container
scanning
is,
if
you
distribute
your
application
with
Docker
and
there's
a
great
chance
that
the
image
is
based
on
other
Docker
images.
That
may,
in
turn
contain
some
known
vulnerabilities
that
could
be
exploited
having
an
extra
job
in
your
pipeline.
That
checks
for
those
vulnerabilities
and
the
fact
that
they're
displayed
inside
of
a
merge
Quest
makes
it
really
easy
to
perform
audits
of
your
docker-based
applications.
B
And
then
we
have
Das
testing
so
running.
Static
checks
on
your
code
is
the
first
step
to
detect
vulnerabilities
that
you
can
put
that
can
put
the
security
of
your
code
at
risk
yet
once
deployed
your
application
is
exposed
to
a
new
category
of
possible
attacks
like
cross-site,
scripting
or
broken
authentication
flops.
This
is
where
dast
comes
into
place.
B
Das
Technologies
are
designed
to
detect
conditions,
indicative
of
security
vulnerabilities
in
an
application
in
its
running
state,
so
the
gitlab
Das
analyzes
running
web
applications
for
the
known
runtime
vulnerabilities
and
it
runs
the
live
attacks
against
that.
That
review
app,
that
Dynamic
environment
that
spun
up
as
as
part
of
the
feature
branch
and
you
can
provide
HTTP
credentials
to
private
areas
and
and
test
out
all
the
parts
of
your
application
and
it
uses
the
open
source,
E8
proxy
tool
to
modify
and
add
authentication
capability
capabilities.
B
B
And
on
the
license,
compliance
so
with
license
compliance.
Most
applications
rely
on
external
components
to
implement
specific
functions,
preventing
the
needy,
the
need
to
code
everything
from
scratch
every
time.
This
is
why
third-party
libraries
are
so
common
and
fetched
directly
by
package
management
tools
like
rubygems
or
npm.
B
However,
this
approach
requires
you
to
ensure
that
the
licenses
for
external
components
are
compatible
with
your
application
and
then
there's
no
conflict
that
could
lead
to
legal
issues.
License
compliance
automatically,
collects
all
the
licenses
used
by
your
dependencies
and
displays
new
ones
in
the
merge
request
widget
before
they
land
on
your
main
default
branch.
B
If
you're
using
auto
devops
license
management
is
automatically
enabled
for
your
projects.
Otherwise,
like
with
the
other
scanners,
you
can
manually
enable
it
in
your
custom,
gitlab
CI,
yaml
definitions,
so
some
of
the
use
cases
for
license
compliance
is
that
it
helps
you
find
what
licenses
your
product
uses
in
its
dependencies
and
to
decide
for
each
of
them
whether
to
allow
or
forbid
it.
B
If
your
application
is
using
an
external,
open
source
library
and
the
license
is
incompatible
with
yours,
license.
Compliance
will
flag
that,
for
you.
B
And
dependency
scanning,
so
in
modern
software
development
environments,
up
to
90
of
an
application
typically
consists
of
third-party
components,
mostly
open
source
software.
Dependencies
are
often
the
largest
attack
surface,
so
the
gitlab
dependency
scanning
helps
analyze
the
dependency
for
known
vulnerabilities.
B
It
checks
the
dependency
scanning
report
and
compares
the
vulnerabilities
between
the
source
and
the
target
branch
and
we're
using
the
the
gitlab
gymnasium
technology
and
the
vulnerabilities,
like
the
other
scanners,
are
shown
in
the
merge
request
and
the
results
are
available
as
a
single
report
so
for
dependency
scanning
some
use
cases
there
is
that
it
helps
you
automatically
find
security,
vulnerabilities
and
the
dependencies
while
you're
developing
and
testing
your
applications.
B
So
by
combining
the
the
license
scanning
and
dependency
scanning,
you.
A
B
Generate
a
a
bill
of
materials,
and
so
the
the
bill
of
materials
or
software
bill
of
materials
is
becoming
more
and
more
important
every
day,
and
so
with
those
jobs,
you
will
get
the
dependency
list
and
the
dependency
list
breaks
down
all
of
the
dependencies
and
licenses
that
are
being
used
in
your
application,
and
you
can
easily
export
that
and
use
that
to
to
meet
the
compliance
needs
for
any
software
bill
of
materials.
It's
a
really
really
powerful
feature,
and
it's
it's
really
really
good
to
have,
and
so
for
that
alone.
B
Foreign,
we
also
have
support
for
fuzz
testing,
so
you
can
utilize
coverage,
guided
fuzz
testing
or
API
fuss
testing
to
to
get
the
deeper
security
coverage
and
and
reduce
your
risk.
B
So
you
can
develop
these
to
to
monitor
the
stability
and
reliability
of
the
application
during
run
time
and
that
could
lead
to
exploitable
vulnerabilities
and
also
use
it
to
find
the
unknown
software
defects
and
weakness
by
inserting
malformed
inputs,
and
so
fuzz
testing
can
really
show
up
some
issues
that
may
not
have
been
discovered
by
SAS
or
Das
testing.
It's
it's
a
good
thing
to
to
have
in
the
mix.
B
And
so
with
that,
we
can
get
into
compliance
information.
B
So
governance
and
security
with
Git
lab
is
really
important
and
we
give
you
a
lot
of
tools
to
to
meet
those
needs.
Security
and
compliance
is
already
built
in.
We
also
allow
you
to
simplify
user
management,
there's
a
single
permission
model
model
to
to
bring
users
in.
So
you
don't
have
to
worry
about
multiple
auth
schemes
and
and
enforce
it
across
multiple
applications.
You
have
one
login
and
then
you
can
manage
the
the
permissions
granularly
from
there.
B
B
You
can
tightly
control
how
all
of
the
code
is
deployed
and
roll
out
any
changes
incrementally
to
reduce
the
impact,
and,
along
with
that,
you
have
to
review
apps
to
give
you
an
immediate
staging
environment
for
all
of
the
suggested
changes
and
to
run
all
of
the
the
testing
and
scanning
before
merging
the
code.
In
with
the
the
default
branch,
yes,
and
so
some
of
the
ways
that
gitlab
enables
compliance
without
friction,
is
we
address
controls
to
allow
you
the
segregation
of
incompatible
duties?
B
B
We
also
have
identity
and
access
approval,
controls
to
to
help
you
control
access
and
approval
and
configuration
management
and
change
control.
B
You
can
also
set
up
access,
restrictions
or
changes
to
configurations
and
pipelines,
and
so
that
way
you
can
be
sure
that
only
the
the
users
that
should
be
able
to
make
those
changes
to
configurations
can
make
those
changes
to
configurations.
B
We
also
have
protection
for
branches
and
environments.
These
are
really
important.
You
can
have
protections
set
up
on
specific
branches,
specific
environments
very
much
so
for
production
really
important
to
have
and
and
to
have
that
government
managed
and
again
auditing.
So
all
of
these
protections
are
great,
but
you
want
to
have
proof
of
the
protection
as
well,
and
so
the
auditing
capabilities
allow
you
to
track
all
of
the
changes
and
and
verify
that
everything's
working
as
expected.
B
So,
jumping
into
compliance
management,
there
are
different
things
that
that
make
up
compliance
management,
so
there's
policy
management
that
enables
the
defining
of
rules
and
policies
to
adhere
to
compliance,
Frameworks
and
the
automation
of
compliance
workflows.
And
so
this
enables
enforcing
the
design,
rules
and
policies
that
we've
created
with
the
policy
management
tools.
B
Then
we
have
the
audit
management
which
allows
you
to
to
to
view
all
of
the
changes
everything
that's
happening
and
make
sure
that
you're
adhering
to
all
of
the
compliance
workflows
and
the
policies
that
you've
set
up
for
that
and
then
Security
Management,
which
we
talked
about
earlier,
making
sure
that
the
security
scanning
and
license
compliance
is
run
for
every
piece
of
code
and
provide
a
dashboard
to
track
the
vulnerabilities.
B
We've
got
some
extra
resources
here
in
the
deck
that
you'll
be
receiving,
that
that
you
can
follow
through
to
get
more
detailed
information
on
the
compliance
Frameworks
and
the
compliance
features,
setting
up
things
like
the
separation
of
Duties
with
a
sampler
implementation.
So
that's
a
really
good
resource
to
have
foreign,
so
jumping
in
is
more
detailed
information
on
the
compliance
management
with
gitlab.
B
So
the
first
step
here
is
creating
or
identifying
policies
that
need
to
be
addressed.
For
example,
this
can
be
a
list
of
disa
stigs
that
you
may
need
to
complete,
or
another
type
of
requirement
list
that
you
may
need
to
keep
may
need
to
keep
track
of
the
Second
Step
here
is
automating
compliance
workflows.
So,
instead
of
having
a
person
manually
go
through
each
policy,
you
can
automate
the
workflow
by
creating
rules
that
need
to
be
met,
and
the
third
step
is
audit
management.
B
So
diving
deeper
into
policy
management
policy
management,
helps
you
define
the
rules
and
policies
to
adhere
to
either
internal
company
policies
or
policies
based
on
legal
regulatory
Frameworks
such
as
gdpr
sock,
2,
PCI,
DSS,
socks,
HIPAA,
ISO,
cobit,
fedramp
and
so
on
and
gitlab
offers
a
number
of
features
to
to
address
policy
management
and
those
features
really
allow
you
to
to
expand
on
the
on
all
of
the
things
that
that
you
need
to
to
get
done,
and
so
these
features
allow
you
to
have
granular
user
roles
and
permissions.
B
You
have
the
five
different
user
user
roles
and
permissions
and
according
to
people's
roles,
they
can
access
certain
information
and
do
certain
tasks,
and
this
is
rather
than
complete
access
to
a
repository.
So
if
you
have
a
a
repository,
you
can
have
the
the
user
rules
that
have
the
user
of
developer
have
access
to
the
repository,
but
then
there's
an
elevated
set
of
permission
for
maintainers
and
the
maintainers
can
have
a
little
bit
more
control
over
that
repository
and
so
just
general
access
to
the
repository
isn't
enough.
B
We
have
granular
permissions
above
and
beyond
that,
and
then
we
have
compliance
settings
where
you
can
create
and
enforce
compliance
policies
for
users
based
on
compliance
rules
for
specific
projects
and
groups,
we'll
be
jumping
into
a
little
bit
more
detail
into
that
in
a
minute,
and
you
have
the
credentials
inventory.
B
You
can
use
this
to
track
all
the
credentials
that
are
being
used
to
access
a
gitlab
self-managed
instance,
and,
like
we
talked
about
before,
with
protected
branches
and
protected
environments,
you
can
set
up
protected
branches
to
control,
unauthorized
modifications
to
those
specific
branches,
so
creating
pushing
and
deleting
of
branches
without
the
adequate
permission
of
approvers
and
of
course,
you'll
want
that
on
your
main
branch,
but
with
the
flexible
tools
that
gitlab
allows,
you
can
set
up
other
protective
branches.
So
if
you
have
other
branches
that
you
want
to
protect
as
well,
you
can
configure
those.
B
So
then,
once
the
policies
and
rules
are
defined,
you
need
a
way
to
enforce
the
policies,
compliance
controls
and
automation
of
compliance,
workflows,
focus
on
enforcing
the
policies
and
separation
of
Duties,
while
reducing
overall
risk
you
can
see
the
gitlab
offers
the
ability
to
create
templates
to
enforce
rules
and
policies.
Some
of
these
templates
are
sock,
2
socks,
ISO,
gdpr,
HIPAA
and
so
on,
and
then
to
expand
on
those
gitlab
offers
compliance
framework
project
type
templates,
where
you
can
create
projects
with
issues
that
map
to
specific
audit
protocols.
B
B
So
here's
an
example
of
that
a
key
aspect
of
governance
is
enforcing
pipeline
jobs
to
execute
on
projects
with
the
compliance
Frameworks.
Currently,
the
managed
security
jobs
are
provided
to
the
development
teams,
but
they're
part
of
the
local
projects
themselves.
This
means
that
it's
not
possible
to
enforce
certain
projects
to
use
them,
and
it's
possible
that
someone
could
remove
the
job
and
no
one
would
know
this
is
where
the
compliance
framework
comes
in.
It
allows
you
to
define
the
Frameworks
that
have
required
CI
jobs
and
assign
them
to
the
projects.
B
B
So
here
we
have
the
different
projects
assigned
with
the
compliance
framework
label.
We've
got
the
labels
assigned
here
and
so
then,
with
the
the
compliance
framework
and
the
compliance
pipeline.
This
enforces
the
execution
of
scanning
jobs
and
specific
jobs
that
are
required
by
those.
And
so,
if
we
look
at
the
the
pipeline
a
we
can
see
that
the
SAS
and
Das
jobs
are
added
automatically
to
the
pipeline
and
those
are
managed
in
a
separate
project.
B
So
if
the
the
users
of
project
a
they
can
make
changes
to
the
pipeline,
but
they
wouldn't
be
able
to
change
the
SAS
and
Das
scanners
and
they
wouldn't
be
able
to
remove
those.
Those
would
be
automatically
added
in
as
part
of
the
compliance
framework,
and
this
is
a
really
good
way
to
to
mandate
and
ensure
that
scans
are
running
when
they
need
to
be
running
on
projects
that
need
to
be
running
them.
B
And
so
the
current
approval
process
is
All
or
Nothing.
You
set
a
gate
for
all
of
the
work
and
require
someone
to
approve
everything
for
better
efficiency
methods
such
as
failing
a
pipeline,
because
a
job
found
vulnerabilities
are
used
to
prevent
something
moving
forward,
it's
good
on
a
prod
Branch,
but
not
good
on
a
Dev
branch.
The
problem
is
that
there
are
a
lot
of
situations
where
it
doesn't
make
sense:
false
positives,
vulnerabilities
that
existed
already
or
that
aren't
the
dev's
responsibility.
B
So
you
can
streamline
the
approval
process
with
the
scanners,
enforced
on
merge
requests
and
the
results
are
out.
The
output
are
displayed
right
back
into
the
merge
requests.
Gitlab
uses
the
data
from
job
artifacts
for
security
scans
and
test
coverage
to
enable
the
approval,
workflow,
contextual,
to
the
results.
B
That's
to
say
if
a
security
scanner
finds
results
that
are
high,
critical
or
unknown
severity
and
approver
from
the
security
group
would
be
required
to
approve
before
moving
forward
same
with
license
scanning.
If
a
license
is
found,
that's
not
on
the
allow
or
block
list.
Someone
would
be
required
to
approve
that
from
the
compliance
team.
B
We
also
have
extended
this
into
code
coverage
as
well
to
avoid
Tech
debt.
If
coverage
declines
due
to
the
code
introduced,
someone
would
have
to
approve
that
and
last
the
external
change
management
approval
in
your
change
management
tools
like
servicenow
the
status
check
API,
allows
you
to
provide
phone
visibility
into
the
status
of
that
approval
right
in
the
merge
request.
B
So,
let's
visualize
what
this
might
look
like
in
the
context
of
a
developer
in
a
merge
Quest.
This
shows
the
correlation
between
CI
jobs
that
are
run
in
pipelines
and
the
parts
results
given
back
to
the
developer.
Inside
of
the
merge
Quest,
you
can
see
that
everything
from
code,
Quality
Security
scans
to
test
results,
are
Consolidated
in
a
single
place
for
developers
to
review
and
take
action.
B
B
So
in
the
next
section,
I
wanted
to
talk
about
audit
management.
Compliance
audits
require
traceability
of
various
compliance
events,
like
user
actions,
permission
changes,
approval
changes,
logins,
password
changes
and
so
on.
This
information
exists
in
gitlab,
and
audit
management
claim
aims
to
provide
a
Consolidated
view
of
these
insights.
B
So
gitlab
can
give
you
information
on
who
took
an
action
what
that
action
was
and
when
and
why
they
took
the
action.
Then
we
can
look
into
if
the
action
was
compliant
or
authorized
and
when
did
it
happen
and
also
how
long
are
the
logs
related
retained
and
are
there
any
gaps
so
gitlab
answers
that
question
with
the
gitlab's
auto
defense
aim
to
satisfy
the
organizational
audit
logging
requirements
with
the
UI
or
the
API.
B
It
also
gives
an
advanced
log
system
of
20
plus
system
logs
on
the
the
self-managed
instances
where
everything
is
logged
to
analyze
the
gitlab
instance.
Also,
you
have
the
compliance
dashboard
that
aims
to
provide
compliance
insights
with
a
Consolidated
view
of
all
the
relevant
compliance
signals,
segregation
of
Duty
the
framework
compliance
license.
Compliance
Pipeline
and
write
in
the
merge
result
foreign.
B
B
So
yeah,
that
was
a
a
quick
overview
of
security
and
compliance
I
also
wanted
to
bring
up
some
some
additional
enablement
that
that's
available
to
you.
Our
Professional
Services
team
offers
a
lot
of
of
high
value
training.
That
is,
is
really
useful
for
accelerating
your
your
gitlab
value.
We
offer
trainings
for
gitlab,
Security,
Essentials
and
also
gitlab
for
project
manager
training.
B
B
Training,
which
can
be
very
useful
for
for
comprehensive
training
for
devops
team
managers
and
for
kind
of
a
more
Hands-On
availability
and
offering
we
have
the
migration
plus,
and
so,
if
you're,
looking
to
migrate
to
to
gitlab
migration
plus
offering
is,
is
something
worth
considering
to
to
accelerate
your
time
to
value
with
gitlab
and
and
ensure
that
all
of
the
best
processes
are
are
being
being
followed,
and
that
also
includes
three
instructor-led
trainings
and
and
so
for
more
information.
B
On
that,
we
we
really
urge
you
to
to
reach
out
to
your
sales
representative,
to
to
get
more
information
there
on
and
and
get
started
on,
accelerating
your
your
time
to
value
with
with
gitlab,
and
we've
got
some
documentation
that
that'll
be
included
with
the
deck
that
that
goes
into
more
depth
on
all
of
the
the
different
parts
of
of
compliance
management
that
we
went
over
so
really
urge
you
to
take
a
look
at
the
documentation.
B
It's
very
comprehensive,
very
useful
and
provides
a
wealth
of
information
foreign
with
that
before
we
jump
into
the
questions,
I
wanted
to
turn
it
over
to
Taylor.
For
for
some
quick
housekeeping.
A
Thanks
Forrest
yeah
I
just
opened
up
a
feedback
poll
just
a
couple
of
quick
questions:
we'd
love
to
get
some
feedback
on
on
today's
session
and
with
that
we'll
dive
into
some
questions
here,
the
first
one
is
we're
using
Sonar
Cube.
Can
we
keep
using
our
current
security
tools.
B
Yes,
definitely
yeah,
so
so,
if
you'd
like
to
you
can
definitely
integrate
external
security
tools
into
the
the
CI
pipeline.
We
have
a
lot
of
great
documentation
on
how
to
utilize
that
you
can
add
scripts
to
pull
that
in.
We
have
a
wealth
of
of
apis
that
can
be
utilized
as
well,
and
so,
if
you
want
to
to
keep
your
security
tools,
you
can
definitely
keep
those
for
for
sonar.
B
Cube,
specifically
gitlab
does
offer
a
code
quality
scanner,
and
so
you
can
use
a
code
quality
scanner
to
to
get
a
lot
of
the
information
that
you
would
get
with
with
sonar
Cube
if
you're
looking
for
something
that
is,
is
equivalent
and
doing
the
same
kind
of
work,
but
you're
absolutely
able
to
to
keep
your
your
security
scanners
and
one
of
the
other
things
that
that
I'd,
like
to
mention
is
that
some
security
scanning
tools
are
are
built
by
usage,
and
so
what
you
could
do
is
that,
if,
if
you
still
want
to
use
those,
you
could
use
those
at
certain
points
like
you
could
have
those
run
on
a
with
a
scheduled
pipeline
to
to
get
those
results.
B
Instead
of
running
it
on
on
every
single
merge
request
and
what
you
could
do
to
fill
in
those
gaps
is
to
use
the
gitlab
tools
that
are
really
comprehensive
and
a
really
really
useful
tool
set,
and
you
can
have
those
run
on
every
single
merge
request
and
then
continue
to
use
your
other
tools
as
necessary
or
in
a
a
scheduled
pipeline.
So
you
can
at
least
reduce
the
usage
to
bring
down
the
cost.
There.
A
Awesome
next
one
here:
how
does
Auto
devops
work.
B
So
Auto
devops
is
it's:
it's
a
really
good
tool.
It's
it's
kind
of
a
a
push
button
option
to
to
set
up
scanning
throughout
the
the
devops
lifecycle
in
your
project
with
one
click,
so
you
can
turn
on
auto
devops
and,
depending
on
your
your
gitlab
tier,
it
will
include
the
the
jobs
that
that
set
up
the
scanners.
B
It'll
add
in
things
like
the
SAS
scanner,
container
scanning
and
Secrets
detection
and
then
in
the
the
ultimate
tier
it'll
also
add
in
dast
and
the
the
license
compliance
and
dependency
scanning,
and
so
that's
automatically
added
in
to
do
that.
You,
you
have
to
have
a
project
that
doesn't
have
a
gitlab
ci.yaml.
A
B
And
so
that
can
be
a
really
good
way
to
start
is
to
to
enable
auto
devops
and
run
it
on
your
pipeline
and
your
project
and
take
a
look
and
and
see
if,
if
that's
working
and
if
that
meets
your
needs,
it's
a
great
way
to
kind
of
get
everything
included
and
see
how
it
goes
and
from
there
with
auto
devops.
B
If
you,
if
you
want
to
continue
maturing
your
CI
pipeline,
you
can
go
and
create
your
own
gitlab,
CI
yaml
and
then
utilize
the
templates
in
Auto
devops.
So
in
our
documentation,
we
have
all
of
the
templates
that
are
included
in
Auto
devops,
and
so
you
can
pick
and
choose
what
you
need
pull
those
out
and
if
you
need
to
override
those
or
update
those.
You
can
do
that
directly
in
your
your
gitlab
CI
yaml.
B
And
so
you
can
take
the
auto
devops
and
build
upon
it
or
use
pieces
and
then
update
it
to
to
meet
your
individual
use
cases.
And
so
it's
a
really
valuable
tool
to
to
get
started,
to
see
kind
of
the
best
practices,
recommendations
and
then
finally,
to
to
use
as
building
blocks
to
to
get
your
individual
use
case
met
in
the
ways
that
that
you'd
like
to
use.
A
Awesome
next
one
here:
does
our
security
team
take
license
seats.
B
So
the
security
team
would
take
license
seats
with
the
ultimate
tier.
You
have
the
ability
to
have
free
guest
users,
but
the
free
guest
users
don't
have
access
to
everything
that
the
security
team
would
need.
The
guest
users
don't
have
access
to
the
configuration
and
the
settings
and
with
the
security
team
they
need
to
have
a
a
very
high
level
of
access,
so
they
can
see
what's
going
on,
and
so
they
can
ensure
that
everything
is
is
working
correctly.
B
One
thing
that
you
can
do
is
use
auditor
users
if
the
the
security
team
is
is
just
auditing,
if,
if
they're
not
in
there
having
to
to
make
changes
and
and
deal
with
vulnerabilities.
So
if,
if
it's
an
auditor
role,
we
would
recommend
the
using
the
the
auditor
level
permissions.
B
Those
do
take
a
licensed
seat.
But
you
know
auditing
is
a
very,
very
important
component
of
of
security
and
for
the
the
security
team
that
is
looking
and
dealing
with
vulnerabilities,
interacting
with
with
code
reviews
and
providing
approvals.
B
They
would
need
to
to
have
a
a
normal
license
seat
that
would
be
used.
But
again
it's
it's
really
important
to
to
give
that
access
to
the
security
team
and
make
sure
that
they
have
access
to
any
of
the
projects
that
you
have
set
up
that
are
using
the
compliance
framework.
So
if
you
have
a
a
compliance
compliance
pipeline
setup,
the
security
team
would
need
to
be
added
to
that
group
as
well
with
the
separation
of
duties.
B
There
are
the
other
groups
where
users
outside
of
the
security
team
wouldn't
have
access
to
to
that
group
to
set
up
the
pipelines
that
can
be
included
in
the
security
framework,
but
the
security
team
themselves
would
need
to
to
take
license
seats.
A
Great
last
one
here:
how
can
I
prevent
secrets
from
getting
committed
in
the
first
place.
B
Okay,
yeah,
so
the
the
the
way
that
the
secret
detection
scanner
works
is
that
it
is
scanning
the
static
code
looking
for
things
like
API
keys
or
any
sort
of
sensitive
information
like
that,
and
so
that
is
scanning
in
the
feature
Branch
before
it
gets
merged
back
into
the
main
branch.
So
it's
a
really
important
scanner
to
have,
but
it
doesn't
prevent
that
code
from
being
committed
to
the
feature
Branch.
B
Initially,
one
thing
that
you
can
do
is
to
set
up
push
rules
and
in
the
push
rules
you
can
also
have
it
look
for
files
that
that
meet
certain
classifications
that
that
we
find
are
are
really
in
line
with
with
sensitive
data.
So
adding
those
push
rules
can
help
prevent
any
API
key
files,
text
files
or
password
files
from
being
committed
at
all,
and
so,
with
those
push
rules
enabled,
if
someone
tries
to
to
push
anything
into
the
input,
the
repo
that
matches
those
files
that
would
would
would
be
rejected.
B
They
wouldn't
even
be
able
to
to
complete
that
push.
So
that's
looking
at
the
file
names
themselves.
It's
not
going
into
the
code
like
the
secrets.
Detection
scanner
is
doing
where
the
secret
detection
scanning
is
happening
in
in
all
of
the
files,
but
it
is
a
good
idea
to
to
set
up
those
push
rules
to
to
prevent
that
kind
of
initial
push.
B
But
you'll
also
want
to
have
that
secret
detection
job
in
your
in
your
pipeline
to
make
sure
that
that
the
code
inside
of
all
of
the
code
is
being
scanned
as
well.
A
Great
thank
you
for
going
through
those
with
that
we
will
wrap
up
today's
session.
Thank
you.
Everyone
again
for
joining
us,
like,
like
we
mentioned
at
the
beginning,
we'll
be
sending
out
this
recording
and
deck
here
in
the
next
day
or
two
hope.
Everyone
has
a
good
rest
of
your
day.