►
From YouTube: DevSecOps / Compliance
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
A
All
right,
let's
kick
things
off!
Thank
you,
everyone
for
for
joining
us
today.
We're
excited
to
to
have
you
with
us.
My
name
is
taylor
lund,
I'm
a
a
manager
of
technical
account
managers
here
at
get
lab
and
joined
by
my
colleague,
jamie
reed,
who
serves
the
the
same
position
for
a
different
team.
We're
grateful
to
to
have
you
with
us
this
morning
or
afternoon,
just
a
couple
of
housekeeping
items
to
to
get
started.
A
If
you
have
any
questions
that
come
up
throughout
the
presentation
feel
free,
please
feel
free
to
put
those
in
the
q
a
portion
of
zoom,
we'll
we'll
get
those
answered
for
you
throughout
the
session
or
or
towards
the
end,
either
by
typing
those
answers
back
to
you
or
or
jamie
well,
we'll
have
some
time
at
the
end
to
go
through
some
as
well.
This
webinar
is
being
recorded,
so
you
can.
A
B
Thanks
tiller
and
thank
you
all
for
your
attention
and
time
today.
We
appreciate
you
investing
it
with
git
lab,
so,
as
taylor
mentioned
the
purposes
of
today's
webinar,
what
I
intend
to
present
here
is
is
really
the
story
of
devsecops
in
gitlab
how
you
can
improve
your
application
security
testing
and
meet
compliance
and
auditability
requirements
using
our
tool
with
that
I'll
share
my
slides
and
we'll
get
going.
B
I'll
reiterate,
as
I
get
going
here,
feel
free
to
ask
questions
at
any
point
via
the
q,
a
tab
at
the
bottom
of
the
webinar,
we're
happy
to
entertain
those
and
for
any
questions
that
we
can
answer
live
we'll
we'll
pause
the
presentation
and
address
those
during
a
couple
of
specific
breaks.
Like
I
mentioned.
B
Why
are
we
having
this
conversation?
Why
talk
about
shifting
left,
if
you
weren't
aware
finding
and
fixing
vulnerabilities
earlier,
is
far
less
costly
than
once
they
reach
your
production
or
your
main
line
branch?
The
cost
of
remediation
can
increase
by
up
to
15
times
by
the
time
you
hit
production.
B
We
can
see
here
this
on
the
left
hand,
side
of
the
slide,
some
results
from
nist's
impact
of
inadequate
software
testing
as
part
of
the
2019
software
development
price
guide
and
on
the
right
hand,
side.
Here
we
see
a
chart
from
another
analyst
where
the
cost
of
remediation
grows
significantly
at
each
stage
in
the
process.
So
if
you
can
avoid
introducing
a
bug
at
the
requirement
planning
stage
or
the
coding
stage,
you
could
save
between
6
and
15
or
even
30
times
as
much
your
cost
and
remediation.
B
The
problem
here
is
that
even
basic
application
security
is
hard.
Traditional
appsec
tools
were
built
more
than
a
decade
ago.
Before
today's
modern
software
practices
and
methodologies
like
devops,
were
commonplace
as
an
industry,
we
need
to
get
beyond
the
basic
idea
of
simple
shift
left
in
giving
devs
a
light
sass
in
their
ide,
and
we
want
to
as
gitlab
lead
us
into
a
new
era
where
security
is
baked
into
the
software
development
life
cycle,
using
a
single
application,
a
single
data
store
and
a
single
pane
of
glass
purpose
built
for
the
modern
software
factory.
B
An
additional
problem
here
is
that
modern
software
compared
to
legacy
application
security
implies
that
changes
must
happen
far
faster.
B
B
As
I
talked
about
the
idea
of
next
generation,
software
also
creates
additional
application
attack
services.
Software
is
composable,
meaning
network
security
becomes
far
less
relevant.
The
idea
of
high
walls
and
content
concentric
circles
they're
not
going
to
cover
you
right.
You
need
to
have
a
more
comprehensive
security
scanning
plan
in
place.
B
Maybe
you
run
ci
and
even
use
a
merge
request
or
a
pull
request
to
kick
off
a
deployment
pipeline
which
then
might
hit
a
test
environment,
and
at
that
point
you
might
be
saying
to
your
qa
or
your
security
teams,
all
right.
You
know
this.
This
new
version
of
the
application
is
available
for
scanning.
B
So
imagine
for
a
second.
If
you
would
a
world
where
you
could
scan
all
of
your
code
every
time
you
commit
it,
make
it
seamless
for
the
developer,
using
few
fewer
tools
with
devsec
and
ops
all
on
the
same
page
and
keep
your
compliance.
Auditors,
happy
gitlab
offers
this
by
offering
a
single
application
that
spans
your
entire
software
development
life
cycle,
which
includes
application
security,
testing,
we're
uniquely
positioned
to
help
you
truly
improve
the
workflow
of
both
your
dev
and
your
application.
Security
teams.
A
B
B
With
this
approach,
there's
no
need
to
buy
separate
single
solution
tools,
but
if
you've
already
got
robust
sas
or
das
tools
that
you've
had
around
for
a
long
time,
you
can
reduce
your
costs
and
improve
your
speed
to
remediation
by
using
them
more
sparingly
and
integrating
the
results
within
gitlab's
merch
request.
Widgets.
B
As
you
may
be
aware,
gitlab
operates
across
10
stages
of
the
sdlc,
the
secure
stage
we
offer
functionality,
including
static
application,
security,
testing,
container
scanning
dependency
scanning,
license
compliance
secrets,
detection
and
dynamic
application
security
testing.
All
of
these
can
be
built
within
your
merge
request
so
that,
as
developers
iterate
on
their
code
and
collaborate
with
one
another,
they
can
also
collaborate
with
your
application
security
team
and
empower
themselves
to
remediate
these
vulnerabilities
before
they
make
it
into
production.
B
B
B
B
This
ends
up
very
powerful
because
it
provides
real-time
feedback
to
the
developer
of
any
vulnerabilities
in
their
code,
while
they're
looking
at
it
and
they're.
In
that
context,
before
the
context
switched
and
moved
on
to
some
some
other
task,
the
developers
themselves
are
empowered
to
understand
and
remediate
the
flaw
in
their
code
before
merging
it
in
a
main
branch
and
before
needing
to
involve
others.
B
As
I
mentioned,
security
still
has
agency
and
awareness
of
this
process
and
in
fact
I
think
for
most
organizations.
I
would
encourage
the
idea
that
security
collaborate
within
the
merge
request
itself
is
part
of
a
review.
We'll
talk
a
bit
later
about
how
you
can
enforce
these
types
of
reviews,
depending
upon
the
degree
of
vulnerabilities
uncovered
in
a
given
merge
request.
B
As
the
next
log
for
shell
type
vulnerability
emerges,
you're
going
to
want
to
be
able
to
to
understand
any
third-party
dependencies
that
are
baked
into
your
production
apps
and
whether
or
not
you're
vulnerable
secret
detection.
Another
important
one
in
today's
software
development
landscape.
This
helps
you
detect
credentials,
secrets
or
passwords
in
source
code
before
you
merge
them
in
a
mainline
branch,
and
you
can
also
optionally
run
the
scan
as
part
of
a
pre-push
or
pre-commit
hook,
which
will
help
you
ensure
that
these
types
of
secrets
never
make
it
into
the
repository.
In
the
first
place.
B
B
We
recently
introduced
infrastructure
as
code
scanning,
which
can
help
you
scan
your
terraform
ansible
cloud
formation
or
kubernetes
configuration
files
or
kubernetes
manifests
for
known
vulnerabilities
and
on
the
runtime
side.
I
mentioned
das,
but
I'll
also
mention
here:
coverage,
guided
fuzz
testing
for
both
web
apps
and
also
api
fuzz
testing
for
apis.
B
B
I'll
pause
here
for
some
questions,
I
see
a
couple
filtering
in
and
I
think
this
is
a
sensible
point
to
address
any
questions
that
have
come
up
because
I've
already
covered
a
lot
of
ground
in
terms
of
the
scanners
available.
I
see
a
couple
of
questions
here
related
to
what
is
I
asked,
let's
pause
and
take
some
of
those,
so
one
attendee
asked
what
is
I
asked
or
iast?
B
That's
infrastructure
is
code
scanning
right,
so
that's
scanning
either
terraform
ansible
cloud
formation
kubernetes
manifest
those
types
of
configuration
files
that
offer
you
a
declarative
way
to
declare
to
configure
your
desired
infrastructure.
You
can
run
scans
against
those
to
ensure
that
you've
got
a
secure
configuration
set
there
in.
B
I
see
another
attendee
here
asks
for
some
differences
between
gitlab
security
scans
versus
those
by
like
a
competing
vendor
like
a
fortify,
while
I
probably
won't
be
the
best
first
to
dive
into
all
of
those
details.
B
What
I'll
do
is
direct
you
to
our
docs
page,
where
you
can
learn
all
about
the
different
types
of
scanners
that
gitlab
wraps
and
develops
ourselves
and
how
those
scans
might
differ
from
like
a
microfocus
fortify
but
like
microfocus's
fortify
offering
we
offer
static
application
security
testing
for
a
huge
bouquet
of
different
languages.
B
The
third
question
I
see
asked
here
was:
do
we
have
templates
for
these
types
of
tests
and
scans
to
run
the
ci
cd
pipeline?
That's
an
emphatic
yes,
and
I
will
certainly
lean
on
cody,
sean
or
matt
to
share
the
appropriate
documentation
link
here.
But
the
probably
the
best
place
that
I
would
start
would
be
to
take
a
look
at
our
auto
devops
template,
which
is
actually
just
a
composed
selection
of
different
scan
of
different
ci
templates.
That
include
things
like
security
scans.
B
So
you
can
grab
components
like
the
security
scan
template
that
autodevops
calls
to
then
use
and
really
get
like
a
prebaked
version
of
exactly
this.
So
when
we
look
at
the
slide,
I'm
showing
sharing
here
this
test
stage
can
be
included
by
grabbing
a
copy
of
the
templates
which
we
publish
on
gitped.com
and
all
of
those
tests
will
run
automatically
I'll.
Invite
my
colleagues,
sean,
cody
or
matt
to
correct
or
augment
anything
I've
shared
here
either
in
chat
or
live.
If
you
prefer.
B
Cool
well
moving
on.
Let's
talk
about
enabling
developers
to
address
these
security
findings,
so
we've
talked
a
bit
about
what
scanning
looks
like
in
the
context
of
a
pipeline,
and
now
I
want
to
show
you
what
it
looks
like
in
the
context
of
the
merge
request
itself.
So
in
this
slide
here
we
have
a
screenshot
from
a
merge
request
and
this
one
is
labeled
width
or
work
in
progress.
B
So
the
developer
here
is
still
actively
working
in
this
branch
and
by
tagging
it
as
whip
they're,
indicating
to
their
colleagues
and
the
rest
of
the
team
that
this
is
not
ready
for
merge.
It
doesn't
require
yet
say
like
an
application,
security
review
and
they're
just
actively
working.
This
merch
request
before
they're,
really
ready
to
say,
hey
my
code
is
you
know
my
branch
is
ready
for
review
and
let's
talk
about
when
we
push
it
to,
you
know
merge
it
back
to
main,
let's
say
so.
B
This
request
to
merge
here,
which
is
the
future
branch
the
developer
is
working
on
into.
In
this
case,
the
master
branch
has
a
pipeline
that
is
run
on
it
and
has
a
required
approval
here
and
we'll
talk
a
bit
more
about
what
these
types
of
required
approvals
mean.
But
you
can
configure
either
by
way
of
the
the
now
deprecated
vulnerability
check
or
the
new
scan
result.
Policy
editor
that
gitlab
introduced
in
the
last
few
months
the
idea
of
required
approvals.
B
So,
for
example,
if
you
wanted
to
build
a
pipeline
that
required
approval
from
a
group
of
like
application,
security
professionals
or
maybe
a
back-end
maintainer
in
the
case
of
a
specific
level
of
vulnerability
being
uncovered,
you
can
configure
that,
and
this
merge
request
will
then
based
on
the
results
of
the
security
scans,
set
up
a
required
approval.
If
there's
no
security,
scans
scan
results
or
findings
above
a
certain
configured
degree
of
vulnerability,
that
approval
won't
be
required.
B
So
this
helps
developers
move
forward
with
the
bias
for
action,
but
also
ensures
that
if
you
don't
want
to
introduce
any
say,
high
or
critical
vulnerabilities
into
mainline
branch
that
you
offer
that
you
know
check
in
the
process
to
say
whoa
before
you
hit
merge.
Let's
make
sure
that
an
appropriately
credentialed
member
of
the
team
reviews
the
change
you're
proposing,
but
the
real
value
of
of
the
merge
request
view
here
is,
in
the
latter
two
rows.
B
What
we
can
see
here
as
part
of
what
we
call
merge
request
widgets
are
the
results
of
the
security
scans
that
have
executed.
As
part
of
that
pipeline
view,
I
showed
in
the
prior
slide
we
can
see
here
in
this
proposed
change
that
the
security
scanners
that
ran
as
part
of
the
pipeline
detected
24
new
vulnerabilities
and
that
either
the
developer
or
application
security
has
already
dismissed
four
vulnerabilities.
B
So
as
part
of
the
findings,
you
can
actually
click
expand.
Here.
You
can
also
jump
out
to
the
full
report,
which
will
show
you
the
job
log
of
the
scanner
itself
or
by
clicking
expand.
You
can
jump
into
the
type
of
vulnerabilities
found
and
I'll
show
you
that
view
here.
So,
for
example,
if
you
click
expand
in
that
merge
quest,
what
you'd
be
shown
here
in
a
developer
friendly
way
is
a
drill
down
view
of
the
findings
that
say
sas
and
other
scanners
have
found.
B
So,
in
this
case,
the
sas
scanner
had
found
a
selection
of
medium
and
high
volume.
High
severity
vulnerabilities,
one
of
these
high
high
severity
vulnerabilities,
was
actually
dismissed
as
something
that
didn't
require
remediation.
So
this
offers
you
the
ability
to,
on
an
exception
basis,
override
a
finding
and
move
forward.
If
everyone
agrees
that
that's
a
safe
thing
and
a
good
thing
to
do.
B
If
you
were
to
click
into
one
of
those
vulnerabilities
that
I
showed
on
the
prior
slide
and
drill
into
it,
you
would
be
presented
with
what
we
call
a
vulnerability.
Page
vulnerabilities
are
first
class
objects
within
gitlab,
just
like
an
issue
or
a
merge
request,
or
an
epic
they're,
their
own
data
type
that
really
their
their
own
unique
first
class
thing
that
you
can
manage
within
gitlab
itself,
so
with
an
ultimate
license.
Developers
can
choose
to
dismiss
this
vulnerability
with
a
comment.
B
They
can
also,
alternatively,
opt
to
create
an
issue
to
acknowledge
the
vulnerability
and
create
a
call
of
action
for
this
particular
vulnerability
to
be
addressed,
or
they
can
opt
to
go
back
to
their
merge
request
and
address
the
finding
directly
in
the
mr
by
pushing
another
commit.
How
might
they
do
that?
Well
within
this,
this
vulnerability
page
there's
a
number
of
different
links,
including
one
to
the
cve
here
and
one
to
a
page
with
some
detail
on,
in
this
case,
a
serialization
vulnerability.
B
B
So
the
socket
server
receiver
component
as
part
of
this
vulnerability
is
known
to
be
vulnerable
and
the
developer
could
simply
they're
even
presented
with
a
proposed
solution
here.
So
if
you
want
to
remediate
this,
finding
simply
upgrade
your
palm
xml
to
pull
in
the
most
recent
version
of
this
third
party,
logback
core
library.
B
Beyond
just
linking
the
developer
to
resources
to
understand
the
vulnerability
and
providing
you
know
details
as
to
what
the
solution
might
be,
we
also
offer
quick
remediation
with
automatic
remediation
for
select
dependency
scanning
and
container
scanning
findings.
So
in
this
case
the
container
scanning
scanner
here
has
uncovered
a
known
cv
from
2019
from
adam's
project
here
within
one
of
his
third-party
dependencies.
In
this
case,
he's
pulling
in
a
known,
vulnerable
version
of
the
muscle
or
musl
dependency.
B
The
upgrade
the
solution
here
would
be
to
upgrade
your
muscle
dependency
from
118
to
118
r3,
to
118,
r4
and
again
for
select
findings.
When
you
open
up
the
vulnerability
card,
you
can
opt
for
auto
remediation,
so
you
click
resolve
with
merge
request
which
is
going
to
automatically
open
you
up
into
a
web
ide
and
show
you
directly
that
line
that
you
should
change
and
how
to
change
it,
and
you
can
add
that
to
a
fresh,
merge
request
to
address
this
phone.
B
B
B
Into
your
security
risk
via
what
we
call
our
security
dashboard,
this
allows
either
directors
of
security
or
cso
types,
immediate
visibility
into
a
group
level
security
posture.
So
they
can
understand
quickly
any
at-risk
projects
with
security
grades.
They
can
see
a
burn
down
chart
of
vulnerabilities
over
time
for
the
given
group
and
for
a
given
project.
They
can
see
the
different
types
of
grades,
a
through
f
based
on
the
number
of
high
or
greater
severity
vulnerabilities
per
project.
B
B
Here's
a
screenshot
an
example
and
really
an
example
of
what
the
vulnerability
report
looks
like
at
the
group
level,
so
here
to
drill
down
to
a
specific
group
and
click
into
the
vulnerability
report.
Our
group
security
dashboard
provides
an
overview
of
all
the
volumes
across
all
projects
in
that
group
and
its
subgroups.
B
B
Here's
the
project
level
view
so
the
project
security
dashboard
displays
the
results
of
the
most
recent
security
scan
on
the
default
or
the
main
branch
of
the
project.
You
can
use
it
to
find
fixed
vulnerabilities
affecting
that
branch
and
the
display
of
this
graph.
This
report
reflects
each
and
every
time
the
the
mainline
branch
pipeline
has
been
run.
B
B
B
So
from
that
dashboard
view,
if
you
were
to
click
into
a
vulnerability
you'll
be
presented
with
that
same
vulnerability
page,
you
can
navigate
back
to
that
first
class
object
to
say:
here's
the
vulnerability
itself
where
it
was
detected
at
what
time.
So
this
in
this
case
pipeline
three,
three
seven
four
five
as
part
of
this
project
discovered
an
rce
patch
request
for
for
a
spring
data
spring
group
library.
B
So
our
dependency
scanning
scanner
using
gymnasium
uncovered
this
as
part
of
the
pawn
xml
for
this
maven
project.
B
Like
I
talked
about
before
you
can
manage
the
status
of
the
vulnerability
from
this
page.
So
by
default
it's
going
to
be
detected
right.
Scanners
have
uncovered
this
vulnerability.
That's
the
new
state
of
this
this
finding,
but
from
there.
If
you
wanted
to
have
more
of
like
an
approvals
based
process
where
an
application
security
team
reviewed
the
findings
for
the
project,
you
can
also
change
the
state
to
confirmed
so
this.
B
If
you
have
a
model
where
application
security
wants
to
pick
up
on
findings,
rather
than
have
the
developers
triage
them,
you
can
use
this
to
say
all
right.
We
won't
triage
anything
until
the
appsec
team
has
had
a
chance
to
review
the
finding
and
confirm
that
this
is
something
that
needs
addressing.
A
B
That's
a
quick
overview
of
the
security
reporting
and
dashboarding
functionality.
That
gitlab
includes,
and
I
see
cody
you
jumped
off
jumped
onto
video.
So
perhaps
there's
a
few
more
questions
we
want
to
address
live.
If
that's
the
case
feel
free
to
voice
them
over
and
let's
see,
if
we
can
answer.
B
So
I
talked
about
sas
or
static
application
security
testing
and,
if
you're
not
familiar,
what
this
is,
is
a
process
that'll
analyze
your
source
for
known
vulnerabilities,
so
it
looks
at
patterns
that
are
known
to
be
vulnerable
and
gitlab
supports
a
broad
array
of
different
languages
and
frameworks.
So
within
these
slides
that
I'm
sure
will
be
packaged
with
the
recording
you
can
see
here
for
the
type
of
language
you
might
prefer
the
scanner
that
we
wrap
and
we
use.
B
So
in
the
case
of
secret
detection,
we
wrap
git
leaks
in
the
case
of
something
like
go
use
gosek.
If
you're
a
nodejs
developer,
we
use
node.js
scan
eslint
for
javascript.
I
won't
read
the
whole
slide.
I
promise
but
there's
a
quick
overview
of
the
different
types
of
sas
scanners
that
we
support.
B
I
mentioned
container
scanning,
so
what
this
is
is
really
static:
analysis
on
the
docker
images
themselves
to
detect
known
vulnerabilities
in
third-party
dependencies
that
these
images
may
pull
in.
So
this
analyzes
the
image
contents
against
public
vulnerability,
databases,
we
use
trivi
and,
I
think,
formerly
clear
as
part
of
aqua's
offering,
which
is
an
open
source
tool
that
helps
us
analyze
or
scan
any
type
of
docker
or
app
c
image,
and,
like
other
scanners,
these
findings,
these
vulnerabilities,
will
be
presented
inline.
B
B
Let's
talk
briefly
about
license
compliance
so
again
we
offer
license
compliance
scanning
for
a
whole
variety
of
different
languages
shown
here,
and
these
should
search
your
project
dependencies
for
the
respective
licenses
of
those
dependencies.
This
can
help
you
detect
and
on
a
policy
basis.
Disallow
undesired
licenses
like
if
you
don't
want
to
copy
left,
license
that
that
might
infect
your
code
base.
You
can
disallow
certain
types
of
like
agpl
type
licenses.
B
If
that
was
something
your
business
wanted
to
avoid,
you
can
create
a
license
check
manual
approval,
so
I
mentioned
before,
and
I
showed
a
brief
slide
about
the
vulnerability
check.
There's
also
a
license
check
or
a
license
approval
policy.
You
can
set
to
require
approval
from
say
legal
team,
member
or
another
appropriately
credentialed
team
member
to
ensure
that
any
licenses
being
brought
in
as
part
of
new
third-party
dependencies
are
checked
before
they
become
part
of
your
code
base.
B
Dependency
scanning,
so
this
is
a
big
one
right
as
you
try
to
understand
your
bill
of
materials
when
it
comes
to
your
software.
More
and
more
enterprises
are
now
relying
on
third-party
vulnerabilities,
open
source,
sorry,
third-party
libraries
and
open
source
software
to
build
their
products
dependency
scanning
helps
you
analyze
the
third-party
dependencies
you're
pulling
in
for
known
vulnerabilities.
B
You
get
a
dependency
scanning
report.
We
also
offer
a
software
bill
of
materials
report
now
which
can
help.
You
understand
the
different
types
of
dependencies
that
that
you're
pulling
in.
B
Here's
that
s
bomb
bill
materials
view
where
you
get
a
report
based
on
the
on
a
per
project
basis
that
can
show
the
dependencies
this
project
is
pulling
in.
So,
as
mentioned,
this
bill
of
materials
makes
the
information
available
and
accessible.
So
that
say,
a
compliance
team
can
review
and
perform
validation
on
the
app,
and
you
can
understand
your
potential
risk
footprint.
B
We
haven't
talked
much
about
fuzz
testing
yet
which
was
an
acquisition
of
git
labs
a
little
while
ago,
and
this
can
also
help
you
detect
more
vulnerabilities,
other
defects
not
as
easily
uncovered
by
something
like
sassed
or
dast.
So
the
idea
behind
fuss
testing
is
it
helps
you
test
deeper
and
wider
than
than
prior
types
of
scanners
and
can
help
you
find
unknown
or
unanticipated
software
defects
by
doing
things
like
inserting
malformed
inputs.
B
B
All
right,
we'll
skip
past,
to
thank
you
and
we'll
jump
right
into
compliance.
So
we've
got
a
few
more
minutes
and
I
thought
I'd
cover
some
of
get
lab's
compliance
capabilities
which
are
pretty
complementary
to
some
of
the
security
capabilities
I
mentioned
here
today.
B
So
if
you've
got
interest
in
security
and
compliance
and
governance
within
gitlab,
what
I
wanted
to
highlight
here
was
that
givea
can
help
build
security
compliance
into
your
workflow
and
leave
it
within
your
single
application
approach.
It
can
help
you
by
way
of
a
single
application.
You
get
a
single
permission,
model
and
user
model
and
data
model,
which
can
help
simplify
authentic
management
to
ensure
that
you're
enforcing
things
like
separation
of
duties
and
make
audit
of
these
type
of
controls
much
easier,
as
I
mentioned,
expediting
auditing
right.
B
So
you
can
verify
your
compliance
with
your
required
controls
in
far
less
time.
We'll
talk
a
bit
about
audit
logs
and
audit
reporting
throughout
this
process
here,
and
this
gives
you
control.
You
can
act
with
certainty.
You
can
control
how
code
is
deployed
and
eliminate
guesswork
in
how
you
are
building
compliance
into
your
application.
Development
life
cycle.
B
B
The
list
is
quite
long
there
and
I
promise
I
won't
read
it
all,
but
if
you've
got
fsi
pci
socks,
hipaa
gpr
compliance
needs
gitlab
can
almost
certainly
help.
Gitlab
itself
is
a
secure
application.
We
can
help
you
secure
your
sdlc
when
we
talk
about
compliance
management
with
gitlab.
The
aim
here
is
to
help
change
the
current
paradigm
to
create
an
experience,
that's
simple,
friendly
and
as
frictionless
as
possible
by
enabling
you
to
define,
enforce
and
report
on
compliance
policies
and
frameworks.
B
So,
if
you're
still
with
me,
if
you
haven't
fallen
asleep
yet
I'll
talk
a
bit
about
how
we
do
that
through
the
definition
of
policy
management,
so
meaning
you're
setting
rules
and
policies
to
help
adhere
to
the
compliance
frameworks,
you
desire,
you
can
identify,
select
projects
that
you
want
compliant
with
these
controls.
B
You
can
enforce
these
compliance
controls
by
way
of
what
we
call
compliance
pipeline
configuration
and
I'll
talk
more
about
that
in
a
second
and
then
finally,
when
it
comes
time
to
prove
it
right.
On
the
reporting
side,
we've
got
audit
management
capabilities,
including
reporting,
as
well
as
an
audit
stream
that
you
can
send
to
third
party
systems,
if
that's
your
preference.
B
So
when
we
talk
about
rules
and
policies,
there's
a
whole
bouquet
of
different
things.
You
can
use
like
merge,
request,
approvals,
scanning
policies
and
build
materials
and
push
rules,
and
these
different
things
that
can
help
you
create
a
policy
management
control
across
your
org.
So
you
get
very
granular
user
roles
and
permissions
management,
five
different
role,
types
within
git
lab
and
in
our
roadmap
we've
got
all
kinds
of
interesting
role-based
access,
control,
improvements
coming
so
watch
for
that
in
future
releases,
we've
got
compliance
pipeline
configurations.
B
B
So
what
I
mean
by
that
is
you
know
using
something
like
separation
of
duties
and
a
separately
controlled
project
with
maybe
more
selective
access
and
permissions.
You
can
define
a
separate
yaml
file
that
then
you
can
apply
to
certain
projects
that
will
be
run
as
the
only
pipeline
within
that
yaml
file.
You've
got
the
optionality
to
offer
an
include
to
that
project,
webci
file.
So,
for
example,
if
you
just
wanted
to
enforce,
maybe
one
or
two
required
scans
or
reporting
type
activities
that
must
happen
as
part
of
the
pipeline.
B
You
could
certainly
do
so,
but
you
can
still
also
offer
developers
the
the
autonomy
and
the
opera.
The
opportunity
to
operate
with
the
bias
for
action
and
agency
of
their
over
their
own
pipeline
configuration
by
including
the
gitlab
ci
file
as
part
of
that
compliant
project
itself.
So
there's
a
lot
of
optionality
in
how
you
build
this,
but
the
real
takeaway
here
is
that
you've
got
the
ability
to
enforce
required
pipeline
jobs
as
part
of
different
projects.
B
B
Beyond
the
idea
of
you
know,
controlling
the
configuration
pipeline
itself
there's
also
required
approvals.
So
we've
talked
a
little
bit
about
this
in
the
form
of
things
like
vulnerability,
check
and
license
check,
both
of
which
are
evolving
a
little
bit
to
move
towards
things
like
scan,
result,
policies
and
review
our
docs
for
a
bit
more
details
on
that.
But
the
idea
in
a
compliance
context
here
is
that
you're
streamlining
the
approval
process
within
the
merge
request
itself.
B
You
know
the
use
of
a
code
owner's
file
to
control,
select,
folders
or
files
within
a
project
to
require
select
approval
and
there's
also
the
idea
of
status
checks,
which
we
won't
talk
much
about.
But
in
brief,
what
status
checks
are?
Is
the
ability
for
your
pipeline
to
reach
out
to
the
third
party
systems?
B
So
maybe
you
had
you
know
a
third-party
system
for
change
approvals
that
you
wanted
to
make
sure
that
ticket
was
closed
out
before
this
merge
request
could
merge.
You
can
build
that
in
as
an
external
status
check,
which
can
illustrate
within
the
merge
request
itself
whether
the
external
systems
should
suggest
moving
forward
with
a
merge.
B
All
of
this
is
contextualized
within
the
merge
request
itself
right.
So
the
developer
gets
a
single
actionable
view
of
not
only
the
output
of
their
ci
jobs,
but
all
the
security
scanning
license
management.
You
know
test
results,
code,
quality,
performance
testing,
that's
all
shown
within
the
merge
request,
so
the
developer,
maybe
their
code
coding
partner
or
you
know,
code
review
code,
reviewers,
maintainers,
application,
security
professionals.
They
all
get
this
view
before
that
merge,
request
moves
on.
B
Finally,
the
exciting
piece
that
everybody
you
know
dreads,
I
would
say,
but
but
is
also
a
pretty
important
part
of
compliance
posture-
is
auditing
right,
so
satisfying
that
organizational
requirement
to
to
prove
things
like
separation
of
duties,
you
know
and
gitlab
can
give
you
information
about
who
took
action.
What
actually
they
took
what
occurred?
B
B
Gitlab's
audit
event
capability
helps
answer
those
audit
logging
requirements
within
either
the
ui
or
our
api
within
the
last
three
or
four
months.
Git
lab
also
introduced
streaming
audit
events
for
ultimate
licensed
customers,
so
you
can
actually
redirect
a
webhook-based
stream
of
audited
events
to
an
external
logging
tool
like
splunk,
for
example,.
B
Here's
a
quick
view
of
the
compliance
dashboard,
so
within
a
given
group
you
can
click
into
security
and
compliance
and
view
the
compliance
dashboard
which
helps
helps.
You
understand
recent
merge
request
activity
within
that
group,
so
across
all
projects,
what's
changing,
who
is
changing
it
and
what
approvals
were
in
place
when
that
happened.
B
B
A
Great
thanks
jamie
I'm
gonna
go
ahead
and
submit
or
or
launch
rather
a
poll
I
just
did
that-
would
love
to
get
your
feedback
from
from
today's
session.
Just
a
couple
of
couple
of
quick
questions
there
go
ahead
and
and
and
submit
those
that
would
be
greatly
appreciated
and
while
we're
doing
that
jamie,
I
I
think
there
are
a
couple
other
questions
in
in
q,
a
as
as
we
have
a
a
few
more
minutes
here.
A
If
you
wanted
to
to
jump
in
and
go
through
a
couple
of
those
sure.
Happily.
B
The
first
one
I
see
in
the
list
here
is:
how
do
I
know
which
get
that
subscription
our
company
is
using?
We
have
a
customer's
portal,
so
if
you
go
to
customers.gitlab.com,
you
can
create
an
account
there
and
log
in
and
understand
the
subscription
tied
to
your
company's
namespace
in
the
case
of
gitlab.com
or
tied
to
the
subscription
owner
in
the
case
of
a
self-managed
instance.
B
So,
ideally,
the
the
account
owner
that
was
stipulated
as
part
of
the
purchase
order.
If
it
was
a
sales
assisted
order,
will
will
be
able
to
do
that
in
the
case
of
a
self-service
order.
Maybe
you
just
dipped
your
credit
card
and
bought
a
couple
of
seats.
You
should
be
quite
familiar
with
the
gitlab
customers
portal
already.
Additionally,
if
you
go
to
the
fully
qualified
domain
name
of
your
gitlab
instance,
slash
help
you'll
be
shown.
B
If
you
have
administrative
rights,
some
information
about
the
version,
your
instance
is
running
as
well
as
the
license
present
on
that
instance,
and
in
the
case
of
a
gitlab.com
subscription.
If
you
go
to
your
gitlab.com
namespace
go
to
settings
and
then
click
billing
you'll
also
be
presented
with
information
about
the
subscription,
its
renewal
date
and
other
pertinent
information
about
that
about
that
relationship.
You've
got
with
us.
Thank
you
for
your
business
and
thank
you
for
that
question.
B
Last
question
I
see
here
was:
do
we
have
recorded
training
videos
kind
of
crash
course
on
devsecops
with
gitlab's
youtube
channel?
I
think
the
answer
there
is
almost
certainly
yes,
if
you're
not
familiar,
we've
got
the
gitlab
unfiltered
youtube
channel
looks
like
maybe
that
got
answered.
I
haven't
read
the
answer
so
I'll
offer
that
that
caveat,
but
I
will
say
that
beyond
what
was
offered
there,
we
also
have
our
gitlab
learn
portal.
B
So
if
you
google
get
lab,
learn
you
can
land
on
about.gitlab.com
learn
where
we
offer
a
whole
variety
of
different
paid,
as
well
as
free
courses.
So
there's
a
couple
of
free,
gitlab,
101,
gitlab,
102
type
level
courses,
as
well
as
some
information
on
security
scanning
with
gitlab
the
final
resource
that
I'll
point
out
before
I
wrap
for
that
question
would
be
the
field
marketing
webinar,
so
we
advertise
on
our
website
and
I'll
just
google
gitlab
workshops
if
you're
hungry
for
more
information
and
perhaps
some
more
hands-on
experience
with.
B
Oh
actually,
I'm
not
sure
I
can
offer
a
kind
of
an
ad
hoc
link
in
the
q-
a
I
perhaps
can't,
but
if
you
google
get
lab
events,
we
have
a
whole
running
calendar
of
different
either
field,
marketing
or
solutions,
architecture
sponsored
webinars
in
addition
or
workshops.
Rather,
in
addition
to
the
scale
10
webinars,
like
the
one
you're
attending,
currently
there's
a
three
to
four
hour
workshop,
including
hands-on
experience
with
devsecops
pipelines
that
that
our
field
marketing
organization
offers
on
a
regular
basis.
B
B
A
Yeah
thanks
everybody
thank
you
jamie,
but,
like
he
said,
feel
free
to
check
out
future
sessions
like
this.
I
would
love
to
to
host
you
again
and
with
that
hope
you
have
a
good
rest
of
your
day.
Everybody.