►
From YouTube: DevSecOps/Compliance Overview
Description
This webinar was presented by the Scale CSE team and used as a pre-req for CS Skills Exchange.
A
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.
B
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
living
good
I'm,
a
customer
success
engineer
for
our
strategic
Enterprise
accounts
and
I'm
coming
to
you
from
Nashville
Tennessee.
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.
B
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.
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
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.
B
With
gitlab,
all
of
these
tests
are
automated
into
every
merge
request.
You
no
longer
have
to
choose
between
risk
cost
and
Agility,
because
it's
one
tool
for
the
sdlc
you
can
use
it
on
every
code
command.
All
of
the
tests
that
run
automatically
the
gitlab
app
creates
a
review
app.
So
Dynamic
testing
can
be
run
on
this
working
code
as
well
all
very
early
in
the
sdlc.
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
developers
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
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
as
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
fuss,
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
SAS.
B
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
cost
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
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
questions.
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
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
this
acute
some
of
the
security
jobs
to
that
that
are
running
on
the
the
main
branch
and
and
help
to
to
pair
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
a,
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
The
results
are
presented
in
a
single
report.
Gitlab
is
also
able
to
detect
secrets
and
credentials.
So
anything
unintentionally
pushed
to
the
repository,
for
example,
an
API
key
that
allows
right
access
to
third-party
deployment
environments.
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
containers
security
scanning
gitlab
does
The
Following.
We
do
a
static
analysis
on
Docker
images
for
vulnerabilities
in
the
application
environment.
We
analyze
the
image
contents
against
public
vulnerability,
databases,
we're
using
open
source
tools,
trivia
to
to
scan
any
type
of
Docker
images
and
again
the
vulnerabilities
are
shown
in
line
in
the
merge
request.
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,
can
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
request
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
for
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.
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
percent
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
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
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
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
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.
B
And
so
some
of
the
ways
that
gitlab
enables
compliance
without
friction
is
we
address
controls
to
allow
you
the
segregation
of
incompatible
duties?
So
if
you
have
multiple
teams
working
on
multiple
projects
that
shouldn't
have
access
across
those,
you
can
manage
the
permissions
and
the
user
access
across
that
to
to
have
a
strict
separation
of
duties.
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
governed
and
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
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
sampling
implementation.
So
that's
a
really
good
resource
to
have.
B
So
jumping
in
is
more
detailed
information
on
the
compliance
management
with
gitlab,
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.
B
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
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
that
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
were
the
logs
related
retained
and
are
there
any
gaps
so
gitlab
answers
that
question
with
the
gitlabs
auto
defense
aim
to
satisfy
the
organizational
audit
logging
requirements
with
the
UI
or
the
API.
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
A
B
Yes,
yes
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
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.
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
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.
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
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
B
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
compliant
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
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.