►
From YouTube: Holistic Approach to Securing the Development Lifecycle
Description
In this webinar we go over security and compliance features that are available with GitLab Ultimate, including:
- How to achieve comprehensive security scanning without introducing a multitude of tools and systems that expand attack surface.
- How to secure and protect cloud-native applications and IaC environments within existing DevOps workflows.
- How to use a single source of truth to improve collaboration between development and security.
- How to manage all software vulnerabilities in one place.
- How to set up compliance pipelines to provide consistent guardrails for developers, and ensure separation of duties.
A
Thank
you
for
for
joining
us
this
morning
or
afternoon,
depending
on
where
you're
at
we're
excited
to
to
have
you
on
this
session
today
wanted
to
start
off
with
just
a
couple
of
housekeeping
items.
First
off
this
webinar
is
being
recorded,
so
you
can
expect
to
see
that
recording
sent
to
you
here
in
the
next
day
or
so
looking
forward
to
sending
that
out.
The
slides
will
be
included
in
that
and
a
second
item
of
business.
A
B
Yeah,
thank
you
very
much.
Hopefully
everybody
can
hear
me
okay,
good
morning,
good
afternoon,
good
evening,
wherever
you're
joining
us
from
we're
going
to
talk
about
the
holistic
approach
to
securing
the
development
life
cycle
today.
Part
of
our
methodology
and
Ethos
within
gitlab
is
to
talk
through
this
holistic
approach
that
takes
into
account
more
than
just
vulnerability
scanning
and
talked
about
all
the
different
types
of
governance
and
controls
that
have
to
be
in
place
for
a
secure
development
life
cycle.
B
So
as
part
of
this
webinar
today,
we'll
focus
a
lot
on
the
concept
of
Shifting
left
and
actually
demo,
some
of
the
things
that
we
do
within
gitlab
on
the
platform
to
enforce
some
of
the
controls.
You've
selected
with
your
shift
left
strategy
and
we'll
wrap
up
with
an
overall
view
of
how
we
think
about
concurrent
devops,
which
is
not
a
thing
that
you
do
sequentially.
B
So,
let's
start
with
introductions.
My
name
is
Frances
of
fungu
I'm.
The
global
field
CSO
here
at
gitlab
part
of
my
role,
is
to
help
customers
understand
the
secure
supply
chain,
but
also
establish
a
center
of
excellence
when
it
comes
to
security.
Compliance
within
the
appsec
world
also
will
joining
us
Anthony
Bauer,
who
is
our
solution?
Architect
and
he'll,
be
doing
going
through
the
demo
with
you
today
and
also
talking
through
some
of
the
actual
things
within
the
get
light
platform
that
you
can
Implement
to
secure
your
development
lifecycle.
B
We
believe
that
houses
need
a
concurrent
number
of
things
going
at
the
same
time
to
build
it
efficiently
and
effectively,
but
also
you
need
that
central
point
of
coordination,
typically
in
a
general
contractor
that
can
help
you
Source
the
right
resources,
the
right
people
and
the
right
plans
to
effectively
execute
your
house
building
plans
in
the
right
time
and
the
right
manner.
If
you've
ever
built
a
house,
if
you've
ever
done
any
type
of
construction
work,
you
know.
B
That's
not
always
the
case
doesn't
go
as
smoothly
and
as
on
time
as
you
expect
it
to,
and
that's
because
a
number
of
things
crop
up
like
poorly
sourced
materials
or
different
changes
and
regulations
and
legislations
that
stop
you
from
executing
what
you
want
to
do.
But
what
that
means
is
you
have
to
react
to
those
events?
You
don't
stop
building
the
house,
you
have
to
react
effectively
and
we
think
building
software
is
the
same
way.
Building
secure
software.
B
So
what
we
observe
at
a
program
level
is
there's
typically
this
misalignment
between
devops
governance
objectives
and
what
you're
actually
implementing
so
from
a
compliance
and
audit
standpoint.
You
have
these
governance
objectives
that
have
been
set
out
by
either
an
audit
committee
or
your
audit
leader
or
your
compliance
leader
and
those
specific
objectives,
don't
always
translate
or
communicated
at
the
control
level
when
it
comes
to
your
devops
platform
or
how
you
actually
developing
software.
B
So
those
misaligned
objectives
become
a
surprise
from
an
audit
standpoint
when,
at
the
end
of
the
year,
end
of
the
quarter,
you're
doing
your
socks,
PCI
or
your
general
audits
requirements,
and
you
find
out
what
you've
stated
as
a
control
objective
isn't
actually
implemented.
So
those
misaligned
objectives
always
come
back
and
let's
potentially
bite
you
at
the
end,
because
you
haven't
communicated
how
you
translate
those
specific
objectives
to
controls.
B
The
other
piece
is:
there
is
no
vision
when
it
comes
to
a
strategic
approach
to
reducing
risk.
We
hear
a
lot
of
people
say
things
like
zero
trust
and
shift
left
and
all
the
other
for
lack
of
a
better
description,
marketing
terms
that
exist
from
a
security
standpoint,
but
that
strategy
hasn't
been
translated
into
a
vision
in
terms
of
how
you
want
to
develop
secure
software,
foreign.
B
Over
and
over
again
is
tool
sprawl.
One
of
our
customers
said
it
best
a
few
weeks
ago
that
were
rich
in
tooling
we're
a
porn
workflow.
So
you
have
a
lot
of
tools
out
there
that
are
supposed
to
help
you
with
this
shift,
left
mindset
from
a
scanning
and
vulnerability
management
standpoint,
but
without
that
Central
coordination
of
workflows
and
processes
and
capabilities
to
actually
make
that
Vision
reality.
B
It
just
becomes
a
tool
management
effort
to
make
sure
you
have
the
right
tools
integrated
into
your
secure
development
lifecycle,
but
also
what
you
do
with
those
results
who
gets
to
see
those
results
who
gets
to
pay
down
the
technical
debts
that
are
flagged
by
those
tools?
It
becomes
more
of
a
processing
capability
issue
than
a
tool
issue.
So
with
that
tool
sprawl,
it
creates
more
problems
than
you
initially
try
to
solve
in
the
first
place,
all
right
this
next
one,
this
fourth
one
is
a
big
one.
B
B
Foreign,
so
moving
away
from
the
program
level
for
a
minute
and
as
I
mentioned
earlier,
Anthony
was
going
to
talk
more
in
more
detail
about
these
controls
and
how
gitlab
helps
with
some
of
these
Solutions,
but
at
a
holistic
view
of
the
secure
supply
chain.
You're
thinking
about
secure
supply
chain
at
the
different
phases,
the
different
links
of
software
supply
of
software
developments,
what
that
means
in
practice
is
you're
not
just
scanning
for
security
vulnerabilities
at
the
pre-commit
level
and
that's
shifting
left.
B
So
what
does
that
mean
in
practice?
So
these
are
just
examples.
This
is
not
an
exhaustive
list,
so,
if
you're
thinking
about
source
code
management,
do
your
threat
model
exercise?
Let's
think
of
the
things
that
could
happen
from
a
source
code
management
standpoint
to
compromise
your
development
life
cycle,
so
you
have
unauthorized
users
that
could
introduce
poor
code
or
bad
code.
B
You
have
compromised
code
of
insecure
code
based
on
vulnerabilities,
you've
used
or
that
have
been
introduced
by
either
copying
and
pasting
the
raw
code
or
introducing
those
vulnerabilities
as
part
of
a
poor
development
workflow,
you
have
exposed
secrets
and
passwords
or
hard-coded
Secrets.
These
are
things
that
can
happen
at
the
source
code
level
that
you
need
to
identify.
As
early
as
possible,
so
when
we
talk
about
shifting
left,
it's
really
thinking
about
this
phased
approach
of
detailing.
B
What
are
the
threats
that
could
impact
at
each
stage
of
the
development
life
cycle
and
put
in
those
controls
to
guard
against
or
mitigate
the
likelihood
of
those
threats
being
exploited.
So
the
source
of
the
source
code
level
is
really
your
Version
Control
Systems,
your
quality
scans,
your
stats
or
your
static
scans,
and
also
your
secret
scanning,
but
also
having
a
way
to
control
or
Harden
the
environment
that
you're
developing
on
so
from
a
gitlab
standpoint.
B
That
would
be
making
sure
you
have
the
right
access
controls,
making
sure
you're,
enforcing
two-factor
authentication
and
really
ensuring
that
the
right
things
are
being
done
at
the
platform
level
itself.
To
start
off
your
journey
to.
What's
that
to
your
supply
chain
and
extending
the
house
building
analogy
a
little
further
in
the
dependency
and
build
stages
is
similar
to
how
you
Source
materials
and
put
together
those
materials
when
you're
building
a
house.
B
Are
there.
The
right
separation
of
Duties
are
there
in
terms
of
who
has
access
to
that
build
environments
and
building
that
attestation
and
release
evidence
that
certifies
or
evidences
that
there
has
been
a
level
of
Integrity
throughout
the
bill
chain
and
then,
when
we
come
to
release
management
or
actually
deploying
your
software.
There
are
also
things
that
you
can
do
to
ready
that
runtime
governance
that
you
have
to
think
about
when
essentially
deploying
the
software
to
customers
and
that's
not
just
a
one-time
event.
That's
going
to
be
a
continuous
process.
B
You
repeat
at
every
time
you
release
a
version
of
your
application
software
so
from
a
30
000
foot
view.
That
is
how
we
think
about
the
holistic
approach
to
securing
the
supply
chain
and
we
will
move
on
to
a
deeper
dive
around
the
technical
controls
that
can
be
implemented
within
gitlab
to
talk
through
or
to
essentially
evidence
those
controls
in
practice.
So
I'm
going
to
turn
it
over
to
Anthony
who's.
Going
to
give
us
that
view.
C
All
right,
thank
you
so
much
Francis
for
the
introduction
and
the
overview
of
security
of
gitlab.
Can
everyone
hear
me?
Okay,
yep.
You
can't
see
me
yet
because
I
haven't
put
on
the
video,
but
here
I
am,
as
Francis
mentioned.
My
name
is
Anthony
Barrow
I'm,
a
Solutions
architect
here
with
the
enterprise
West
team
of
git,
lab
I'm
located
in
San
Francisco
California,
very
happy
to
be
here
to
show
you
about
shifting
security
left
within
gitlab
and
a
little
bit
about
compliance
a
little
bit
later
within
the
presentation.
So
let's
go
ahead
and
get
started.
C
We
have
a
pipeline
that
will
run
as
part
of
our
continuous
integration
and,
as
part
of
that
pipeline,
we
can
include
security
scans
to
be
able
to
look
for
any
kind
of
vulnerabilities
that
you
have
Within
in
your
code
that
you're
modifying
this
gives
us
the
ability
to
be
able
to
report
on
any
of
those
vulnerabilities
and
be
able
to
take
action
on
those
vulnerabilities
as
we're
doing
our
development,
thereby
shifting
our
security
effort
left.
We
don't
have
to
throw
it
over
the
fence
to
another
department.
C
If
you
will,
that
needs
to
evaluate
the
application
for
any
kind
of
vulnerabilities,
we
can
take
action
on
those
vulnerabilities
early
within
the
life
cycle
instead
of
having
to
wait
late
into
the
life
cycle,
and
this
helps
us
to
be
able
to
save
money
and
time
in
remediating
those
vulnerabilities
or
fixing
any
of
those
defects.
Another
key
aspect
of
the
gitlab
flow
is
the
review
app
which
allows
you
to
be
able
to
deploy
the
application
to
allow
for
feedback
for
the
folks
that
are
involved.
C
The
stakeholders,
within
the
application
and
collaborate
to
be
able
to
understand,
are
these.
The
changes
that
we
expected
and
intended
is
the
application
still
working
as
we
expect
that
ensues
discussion,
any
kind
of
code
and
Security
reviews
that
we
want
to
take
place
and
then
approving
changes.
As
Francis
had
mentioned.
We
have
controls
that
are
available
within
gitlab
to
be
able
to
set
such
things
as
merge,
request
approvals
that
if
we
have
High
severity
vulnerabilities
that
are
happening
within
our
application
or
within
our
change,
we
could
automatically
trigger
a
merger.
C
Quest
approval
to
have
certain
individuals
approve
that
merge
request
before
it
gets
merged
into
the
default
branch
that
you
see
there
merge
tissue
closed,
and
then
we
run
our
deployment
to
be
able
to
deploy
into
our
environment
and
then
be
able
to
monitor
the
application.
So,
as
I
mentioned
before,
this
moves
our
security
testing
as
close
as
possible
to
the
developer
or
early
on
within
the
life
cycle,
so
that
we
can
remediate
those
vulnerabilities
as
quickly
as
possible
a
little
bit
of
housekeeping
here
too
for
folks
that
are
on
the
live
webinar
today.
C
If
you
have
any
questions
or
any
comments
that
you
would
like
to
make,
please
use
the
Q
a
section
of
the
webinar
to
be
able
to
post
those,
and
then
we
will
be
able
to
answer
within
the
Q
a
section
as
well.
Okay,
so,
let's
get
on
with
the
show,
so
a
little
bit
of
an
overview
of
the
different
security
capabilities
that
we
have
available
within
the
git
lab
devsec
Ops
platform.
C
Is
we
have
overarching
capabilities
that
allow
you
to
be
able
to
have
dashboards
and
reports
to
be
able
to
view
what
types
of
vulnerabilities
you're
experiencing
within
the
application
be
able
to
triage
them
on
the
spot,
track
them
within
your
organization
and
I'll.
Show
you
this
within
a
demonstration,
as
I
mentioned
before
we
have
security,
Mr
approvals
that
will
automatically
trigger
an
approval
for
your
merger
Quest.
Based
on
what
definitions
you'd
like
to
put.
If
it's
for
high
severity
vulnerabilities
as
well
as
critical
medium,
it's
customizable
as
you
need
it.
C
C
Security
testing
that
we
go
through-
and
one
note
to
make
here
as
well-
is
that
a
lot
of
the
security
scanning
capabilities
and
security
capabilities
we
have
within
gitlab
are
geared
toward
open
source
languages
as
well
as
other
languages
that
we
have
available.
So
I
want
to
say,
open
source
languages,
I
typically
think
of
things
like
Python
and
I,
think
of
dot
net
and
looking
at
repositories
like
pipei.org
and
so
forth.
C
But
but
we
support
a
multitude
of
languages
and
if
you
have
questions
about
specific
languages
that
we
support
for
different
types
of
security
capabilities,
we're
happy
to
answer
them
within
the
Q.
A
so
how's
that
we
also
have
infrastructure
as
code
scanning,
to
be
able
to
look
at
any
kind
of
infrastructure
that
you're
setting
up,
because
we
know
that,
according
to
O
wasp,
a
lot
of
the
vulnerabilities
now
are
based
on
configurations
that
are
done
within
the
infrastructure
as
code.
C
So
we
want
to
ensure
that
the
configuration
that
we're
making
within
our
infrastructure
is
code
is
compliant
that
we're
not
leaving
any
vulnerabilities
within
there
dependency
scanning.
Getting
back
to
my
open
source
comment
that
I
had
made
before
so
looking
at
any
kind
of
dependencies
that
we're,
including
within
our
application
or
what
they
call
software
composition
analysis
to
see
if
there's
any
vulnerabilities
that
have
been
reported
as
as
in
using
that
specific
component
and
again
I'll
show
you
this
within
the
demonstration.
C
We
also
have
license
compliance
so,
along
with
those
open
source
components
that
you're,
including
within
your
application.
There
are
licenses
that
are
associated
with
them
and
some
licenses
you
might
not
want
to
adhere
to
what
the
license
compliance
is.
So
they
may
have
a
license
compliance
that
says
that
you
need
to
make
your
code
publicly
available
if
you
use
this
open
source
component,
and
a
lot
of
folks
may
not
want
to
do
that,
we
also
have
post
build
scanning
capabilities
that
are
there
so
container
scanning.
C
So
if
you
have
any
kind
of
vulnerabilities
that
are
listed
against
the
container
image
that
you're
utilizing
for
containerizing
your
application,
we
use
our
container
scanning
capabilities
to
be
able
to
look
for
vulnerabilities
that
are
there.
We
also
have
our
Dynamic
application
security,
testing
or
dast
that
allows
us
to
be
able
to
look
into
the
application
once
it's
deployed
to
see
if
there's
any
vulnerabilities
that
can
be
hacked
in
to
the
application
from
a
dynamic
application
security
testing
point
of
view.
C
So
a
little
bit
of
a
screenshot
from
the
project,
I'm
going
to
be
showing
you
later
is
emerge
request
and
the
reason
why
I
put
this
in
as
a
screenshot
is
because
this
is
where
the
rubber
meets
the
road,
where
you're
able
to
gain
visibility
into
the
code.
Changes
that
you
made
from
a
security
perspective
from
a
compliance
perspective,
as
you
see
here
within
license
compliance
and
allows
the
developers
or
folks
to
be
able
to
take
action
upon
these
vulnerabilities
early
on
within
the
development
process.
C
So
here's
the
merger
quest
in
the
middle
of
the
screen
you'll
see
that
we
have
code
quality,
that's
listed
there.
We
also
have
license
compliance.
That's
there.
Our
security
scanning
is
also
there
with
a
whole
ton
of
different
vulnerabilities.
That
are
there,
because
this
is
a
demonstration
environment
where
we're
able
to
show
you
all
sorts
of
different
vulnerabilities
that
we
have
found
as
a
result
of
developing
within
our
application.
C
Here
is
a
screenshot
that
I
took
from
a
pipeline
that
was
run
within
our
application,
and
here
we
have
all
of
the
different
jobs
that
are
associated
with
the
pipeline
that
are
listed
under
the
different
stages.
So
the
stages
are
build
unit
test,
C,
fuzz
production,
a
dast
in
this
instance
underneath
there
you'll
see
all
of
the
different
jobs
that
are
associated
with
those
stages,
so
build
unit
code,
quality
code,
container
scanning
python
dependency,
scanning
Etc,
then,
and
within
all
of
these
different
jobs
that
we
have.
C
We
can
double
click
on
any
of
these
jobs
to
see
the
output
from
that
job.
So,
for
instance,
s-bomb
is
a
Hot
Topic
to
be
able
to
understand
the
inventory
of
the
different
open
source
components
that
you
have
within
your
application.
If
you
were
to
double
click
in
the
into
the
dependency
scanning
job
that
we
have
here,
you
would
find
that
there's
a
Json
output
of
a
cyclone
DX
formatted
s-bomb.
That
gives
you
a
complete
inventory
list
of
all
the
different
open
source
components
that
you
have
within
the
application.
C
So
the
pipeline
allows
you
to
be
able
to
see
the
output
of
the
jobs
also
that
the
jobs
completed
successfully
foreign,
so
as
it
mentioned
and
kind
of
precursed
for
for
the
s-bomb.
Is
that,
as
part
of
our
security
effort,
we
also
have
a
dependency
list,
that's
available,
which
is
the
s-bomb
for
the
application.
So
this
appears
within
the
gitlab
environment
and
if
I
were
to
go
ahead
and
drop
down
on
any
one
of
these
components,
you'll
see
that
I've
got
several
different
vulnerabilities
on
on
these
components.
C
I
could
see
exactly
the
vulnerability
information
and
be
able
to
take
action
on
it
directly
from
this
dependency
list,
so
that
allows
me
to
be
able
to
remediate
faster
and
also
ship
security
left,
so
I
wanted
to
also
show
you
a
little
bit
of
a
preview
of
our
demonstration
with
our
review
environment.
So
this
is
the
review
environment
for
our
application
that
allows
folks
to
be
able
to
have
feedback
to
our
application.
C
If
they
see
something
in
here
that
was
unexpected,
then
they
could
note
that
within
the
merger
Quest
and
say
this
isn't
exactly
there's
there's
something
missing
here:
I
wasn't
expecting
the
simply
simple
notes:
I
was
just
expecting
notes
Etc,
so
this
gives
us
the
ability
to
be
able
to
review
the
application
even
before
we
deploy
it
again,
saving
time
and
money
all
right.
So
before
I
go
into
enforcing
compliance.
Let
me
give
you
a
little
bit
of
a
demonstration
of
gitlab
itself,
so
many
folks
will
recognize
the
gitlab
environment
that
we
have
here
here.
C
I've
got
a
devsec
Ops
Workshop
project
that
I
have
underneath
a
group
here
called
security,
lunch
and
learn,
and
that's
under
another
subgroup
that
I
have
here,
but
I
won't
go
ahead
and
jump
into,
but
I
wanted
to
give
a
moment
to
be
able
to
explain.
Group
structure
so
groups
allow
us
to
be
able
to
designate
specific
projects
within
different
parts
of
an
organization.
If
you
will,
it
also
allows
us
to
roll
up
the
results
of
those
different
projects,
not
just
from
a
project
level
but
from
an
overarching
level.
C
So
if
I
were
to
do
go
into
the
security
lunch
and
learn,
group
I
could
look
at
my
security
and
compliance
dashboard
there
to
be
able
to
roll
up
our
devsecops
Workshop
project
that
you
see
here
and
any
other
projects
that
you
have
and
similarly
for
groups
above
the
security
lunch
and
learn.
I
could
also
roll
up
the
the
information
from
there.
So
that's
a
quick
introduction
into
groups
and
what
that's
all
about-
and
here
we
have
our
project
information.
C
So
this
will
show
us
exactly
what
activity
is
taking
place
within
our
project,
our
labels
and
our
members
of
the
project
to
provide
visibility
to
the
folks
that
need
to
have
visibility
into
the
project.
This
also
works
within
a
group
level
as
well.
Here
we
have
our
repository.
This
is
where
we
have
our
code
that
we
are
modifying,
and
this
is
the
screen
that
you
see
now
that
has
all
of
our
different
files
that
are
associated
with
building
the
project.
C
Here
we
have
our
issues,
so
this
is
where
we
Define
exactly
the
changes
that
need
to
be
made
within
our
project.
We
can
provide
collaboration
there
for
folks
to
be
able
to
collaborate
on
the
issues.
We
also
have
project
management-
that's
available,
such
as
creating
boards
to
be
able
to
see,
if
you're,
using
Agile
development,
to
see
what
Sprint
is
associated
with
a
specific
issue.
C
Etc
we
also
have
merger
quests,
so
I
had
shown
the
screenshot
for
our
merger
Quest
earlier
that
we
have
our
information,
that's
there
and
we'll
dive
a
little
bit
deeper
into
that
in
just
a
second.
We
also
have
our
continuous
integration
and
continuous
deployment
that
we
have
our
pipelines,
and
that
was
the
screenshot
that
I
showed
you
before
we
have
our
jobs.
C
We
could
also
schedule
pipelines
to
run
at
a
specific
time,
Etc
here's
we
have
security
and
compliance,
so
this
is
where
we
have
our
security
reports
and
dashboards
available
to
be
able
to
look
into
our
application,
as
well
as
at
a
group
level
to
be
able
to
roll
up
that
information
into
our
groups
to
be
able
to
see
across
the
entire
group
what
our
security
is
looking
like
or
our
vulnerabilities
are
looking
like
Etc.
We
also
have
our
deployments
so
as
I
had
mentioned
before
about
the
review
environment.
C
We
also
have
our
packages
and
Registries,
so
this
allows
us
to
be
able
to
store
our
binaries
that
we're
building
within
our
application,
as
well
as
utilize
containers
that
we
build
within
our
application
locally.
Instead
of
having
to
go
out
to
the
outside
world
to
be
able
to
get
those,
we
also
here's
our
infrastructure.
If
we
are
using
utilizing
kubernetes,
we
could
attach
to
a
kubernetes
cluster.
In
this
case.
C
Here's
we
monitor
our
application
to
be
able
to
find
how
our
application
is
doing,
and
then
another
important
part
that
to
take
advantage
of
is
part
of
the
devsecops
Endeavor
is
our
analytics
that
we
have
built
in
to
gitlab,
and
this
is
where
we
can
show
exactly
our
analytics
as
it's
associated
with
our
CI
CD
efforts,
any
kind
of
code
review
how
our
issues
are
being
managed
in
terms
of
how
long
it
takes
to
close
them.
How
our
merger
requests
are
doing
how
long
it
takes
to
have
those
closed.
C
We
also
have
a
Wiki
available
that
allows
us
to
be
able
to
create
a
Wiki
directly
within
the
project
to
be
able
to
document
and
share
with
others
that
are
involved
with
in
the
project,
to
have
something:
that's
not
entirely
within
the
code
base,
but
a
reference
that
we
can
get
to
Snippets
and
finally
settings.
So
let
me
go
ahead
and
dive
into
our
merge.
C
Requests
here
so
here
are
just
two
different
merger:
quests
I'm
going
to
go
ahead
and
open
up
the
one
that
I
had
for
the
screenshot
and,
as
you
see
when
I
opened
up
the
merger,
Quest
I've
got
exactly
what
changes
have
been
made
to
the
the
application
from
a
merger
Quest
perspective.
I've
also
got
the
the
branch
that's
there,
and
then
this
is
their
intended.
Merge
Target,
so
our
main
or
default
branch
that
I've
got
I
also
have
the
pipelines
that
I
have
associated
with
the
project.
C
So
here
I
can
look
into
the
pipeline
status
in
order
to
identify
how
our
pipelines
have
run
as
a
result
of
this
merger
Quest.
What
things
have
changed
and
let
me
go
ahead
and
get
back
to
that
in
a
little
bit.
So
I
also
want
to
show
you
let
me
go
ahead
and
open
this
our
pipelines,
so
this
is
related
to
the
screenshot
that
I
had
shown
you
before.
That
is
our
pipeline.
C
So
here,
as
I
mentioned,
we
have
our
dependency
scanning
that
took
place
within
our
application.
This
gives
us
a
output
of
what
the
job
accomplished.
We
also
have
our
job
artifacts
that
we
have
available
within
our
dependency
scanning
that
allow
us
to
be
able
to
see
what's
there.
So
if
I
go
ahead
and
browse
here,
I
can
see
that
this
is
our
our
s-bomb,
basically
in
Cyclone
DX
format.
That
gives
us
the
ability
to
utilize
this.
C
It's
it's
basically,
a
data
file
that
we
can
input
to
see
what
vulnerabilities
are
there,
so
the
pipeline
becomes
an
important
resource
to
be
able
to
see
exactly
what
jobs
have
completed.
What
jobs
have
not
completed
successfully
be
able
to
see
the
output
of
the
jobs
themselves
again,
giving
you
visibility
into
your
devsecops
process.
So
let
me
go
ahead
and
transition
over
into
our
security
and
compliance,
dashboard,
the
security
and
compliance
or
I'm.
Sorry
yeah.
The
security
dashboard
gives
the
ability
to
see
exactly
what
types
of
vulnerabilities
are
being
reported.
C
Digging
a
little
bit
deeper
I
can
check
into
my
vulnerability
report.
That
gives
me
the
ability
to
be
able
to
see
where
my
vulnerabilities
are
coming
from.
I
can
also
filter
this,
as
I
wish
to
be
able
to
look
at
what
severity
levels
I
have
for
my
vulnerability,
so
that
if
I
only
wanted
to
look
at
critical
vulnerabilities,
I
could
select
this
also,
we
have
a
filter
for
our
tools.
So
what
types
of
security
vulnerability
testing
that
we've
done?
We
could
filter
it
by
those
vulnerabilities.
C
They
also
have
our
cve
information.
That's
included
that
we
could
look
into
to
see
what
type
of
information
we've
got
there.
So
that's
the
vulnerability
report
that
allows
us
to
be
able
to
see
our
vulnerabilities
as
well
as
assign
them
for
as
issues
for
folks
to
be
able
to
work
on
and
also
plan.
Let
me
go
ahead
and
show
you
our
dependency
list.
C
So
here
we
have
our
dependencies
that
are
included
as
as
in
part
of
the
application
and
as
I
had
mentioned
from
the
screenshot
that
we
looked
at
before.
If
I
go
ahead
and
drop
down
within
one
of
the
components
that
we've
identified,
we
can
see
what
types
of
vulnerabilities
have
been
reported
against
these
components.
We
could
also
do
the
same
that
we
had
before
I
can
create
an
issue
to
be
able
to
remediate
this
vulnerability
so
that
I
have
the
ability
to
be
able
to
remediate
these
as
quickly
as
possible
within
our
dependency
list.
C
So
we
also
and
I'll
get
into
this
a
little
bit
later.
We
have
audit
events
that
are
available
as
part
of
our
compliance
that
allow
us
to
be
able
to
see
what
different
audit
events
were
tracked
against
this
project.
But
what
I
wanted
to
show
you
is
this
part
of
the
demonstration
are
the
environments.
So
here
we
have
our
environments
for
our
application
that
allow
us
to
be
able
to
see
the
application
deployed
before
it
goes
into
production.
C
So
here
I
can
make
any
kind
of
comments
that
I
would
like
as
to
I,
was
only
expecting
notes
instead
of
Simply,
simple
notes,
so
that
we
could
be
able
to
collaborate
and
remediate
any
kind
of
defects
that
we
find
within
our
application
just
wanted
to
make
sure
everyone
can
see
my
screen,
okay
and
normally
see
a
border
around
it.
That
shows
that
I'm,
sharing
and
I
don't
see
that
right
now.
So,
hopefully
that
you
guys
I'm
sure
someone
would
have
told
me
by
now,
but.
C
C
Okay,
good,
then
again
our
packages
and
Registries.
So
this
gives
us
the
ability
to
be
able
to
store
any
kind
of
containers
when
I
use
and
then
also
our
infrastructure
to
be
able
to
connect
into
our
kubernetes
cluster
or
terraform
or
Google
Cloud
all
right.
So
let
me
go
ahead
and
go
back
to
the
presentation,
foreign.
C
C
So
getting
back
to
the
analogy
that
Francis
was
painting
before
in
terms
of
our
house
building
here
in
San
Francisco,
as
you
can
imagine
every
once
in
a
while,
we
get
earthquakes.
So
we
need
to
ensure
that
our
houses
that
we
build
comply
with
different
standards
that
we
have
within
our
within
our
state
regulations.
So
we
have
such
things
as
Title
24
that
we
need
to
comply
with.
We
need
to
comply
with
earthquake
standards.
C
Etc
such
that
buildings
can
withstand
those
types
of
issues
and
you
you
can
probably
imagine
you
want
to
live
in
a
house.
That's
compliant
and
not
that's
earthquake
proof
if
you
will
so
license.
Compliance
becomes
important
within
our
application
development,
as
I
mentioned
before,
because
you
want
to
ensure
that
you
don't
have
any
restrictions
in
using
open
source
components
or
any
kind
of
liabilities
for
having
to
publish
your
application.
C
As
an
open
source
project,
it
also
allows
you
to
be
able
to
set
rules
on
what
to
allow
and
deny
within
your
licenses,
and
we
also
have
audit
compliance
to
be
able
to
see
what
types
of
activities
they've
taken
place
within
our
project,
as
well
as
enforced
jobs,
to
run
as
part
of
your
pipeline
that
we
had
seen
earlier
within
our
pipeline
project
foreign.
So
as
part
of
enforcing
jobs
within
our
pipelines.
C
This
is
used
within
organizations
to
ensure
such
things
as
SAS
testing
takes
place
when
a
code
change
is
made
or
dast
testing
Etc,
so
that
we
can
enforce
and
ensure
that
these
types
of
scans
are
taking
place
so
that
we
can
remediate
any
vulnerabilities
as
early
as
possible
and
I'll
show
you
this
within
our
our
project
as
to
how
that
security,
compliance
framework
project
works
and
the
compliance
framework.
That's
associated
okay.
So
let
me
go
back
to
my
demonstration
environment.
C
C
In
this
case,
I
just
have
my
devsecops
compliance
framework
associated
with
the
project,
so
that
affords
me
that
compliance
job
that
is
included
as
my
project
and
where
does
that
come
from
that
comes
from
okay
here
you
see
the
label
as
well.
That
shows
its
compliance
framework
that
comes
from
the
project.
I
have
to
do
a
little
Zoom
shuffling
here.
If
you'll
give
me
a
moment
here,.
A
C
Good
thanks,
Taylor,
no
problem,
it's
hard
to
get
to
those
other
tabs.
They
got
to
do
the
the
dance
here.
So
here's
my
compliance
framework
and
here's
where
we
have
our
compliance
pipeline
defined
that
allows
us
to
be
able
to
include
exactly
what
type
of
compliance
jobs
that
we
want
to
include
as
part
of
our
pipeline.
So
here
we've
got
a
compliance
job
defined
here
and
you
might
have
seen
this
within
the
pipeline.
I'll
show
you
that
a
little
bit
in
a
little
bit
that
where
that
ran,
but
I've
just
got
a
simple
one
here.
C
So
that's
where
a
compliance
framework-
and
this
is
where
you
can
Define-
that
compliance
job
to
run,
go
ahead
and
do
the
dance
again
to
go
back
into
my
project
here,
all
right
go
back
to
full
screen.
Okay.
So
let
me
show
you
that
pipeline
again
to
recall
as
to
what
that
com
that
pipeline
the
compliance
job
that
ran
within
the
pipeline
you'll
see
it
here.
So
this
is
exactly
the
compliance
job
that
we
had
defined
as
part
of
our
pipeline.
C
If
I
go
ahead
and
open
it
up,
I
can
see
that
I've
got
my
message
from
compliance
framework
that
was
included
as
part
of
my
pipeline.
That
was
ran
so
that
I
have
that
there
and
let
me
show
you
actually
as
well
while
I'm
here
is
our
gitlabci.yaml
file
in
order
to
show
you
how
you
include
those
security
testing
steps
within
your
pipeline,
so
gitlab
has
a
mechanism
that's
built
into
the
product
that
allows
you
to
do
such
things
as
include
templates
within
your
project.
C
So
here
I
have
a
template
section,
that's
included
as
part
of
my
pipeline.
That
allows
me
to
Define
what
templates
I
want
to
include
within
our
project.
So
you
remember
that
I
have
SAS
testing
as
part
of
my
project,
I
included
that
by
included
in
the
sast
template
that
gitlab
maintains
that
allows
folks
to
be
able
to
include
within
our
projects.
This
can
also
be
extended
if
I
like
to
be
able
to
define
a
specific
scanner
if
I
want
for
that
either
the
SAS
testing
or
the
dependency
set
testing.
C
So
these
templates
become
a
way
to
be
able
to
include
jobs
within
your
projects
without
having
to
write
the
steps
yourselves
within
your
GitHub
CI
file,
so
that
you
can
immediately
include
these
as
part
of
your
project.
So
you
see
I
have
container
scanning
secret
detection
Etc
that's
available
within
my
project
itself,
so
that
gives
you
the
information
as
to
what
is
included,
there's
also
Auto
devops
available
within
gitlab.
That
allows
you
to
be
able
to
have
these
templates
automatically
included
as
part
of
your
project.
C
What
Auto
devops
does
is
it
takes
a
look
at
your
repository,
be
it
it
identifies
what
language
that
you're
developing
within
and
then
selects
the
appropriate
jobs
associated
with
the
language
that
you
are
creating,
so
that
it
becomes
a
way
to
be
able
to
automatically
build
and
deploy
your
application.
Within
gitlab.
C
A
C
It's
okay.
So,
in
conclusion,
what
we've
seen
already
within
the
demonstration
is
I've
taken
you
on
a
tour
of
gitlab
in
terms
of
the
gitlab
flow
itself,
taking
you
on
a
tour
of
the
repository,
the
issues
that
are
there:
the
merger
Quest
CI
CD
and
the
pipelines
that
are
associated
secured
and
compliance
with
the
security
dashboard,
as
well
as
the
vulnerability
report
and
the
dependency
list.
C
We
also
took
a
look
at
our
different
environments
to
be
able
to
deploy
our
application
within
the
branch
itself
instead
of
having
to
wait
for
it
to
be
merged
into.
Oh,
that's
something
that
I
should
show
you
as
well.
Is
our
emerge
request
approvals
so
going
down
the
list.
It
reminded
me
to
do
that
so
within
our
settings
as
well,
we
can
create
our
merger
Quest
approvals
to
be
able
to
see
exactly
what
types
of
if
we
have
any
kind
of
vulnerabilities
that
we
have.
C
If
we
have
different
vulnerabilities,
that
are
there,
we
can
set
merger
Quest
approvals.
Oh
I
should
show
that,
within
the
merge
request
too,
that
there's
an
approval
section
here
that
you
show
exactly
okay,
who
needs
to
approve
this
change,
but
we
can
create
a
merge
request
approval.
So
we
don't
have
any
any
changes
here.
C
So
we
don't
have
to
worry
about
that,
but
we
can
have
a
merge
request,
approval
that
scans
for
our
different
vulnerabilities
that
we
have
there
and
we
can
create
that
as
a
high
level,
a
medium
or
a
critical
severity
or
any
type
of
level
that
you've
got
that
you
want
to
create
a
merge
request,
approval
for
so
that
was
what
I
wanted
to
show
you
within
the
merger
Quest
approvals
two.
We
also
went
through
our
compliance
and
we
took
a
look.
Oh
this
reminds
me
our
license
compliance.
C
So
if
I
go
into
my
pipelines
again,
I
can
do
this.
Also
within
the
merger.
Quest
I
could
have
done
it
there
too,
but
here
we
have
our
license
compliance
section,
that's
included
as
part
of
the
pipeline
that
we
ran,
and
here
we
have
the
ability
to
be
able
to
set
what
type
of
policies
that
we
want
to
have
within
the
licenses
that
are
identified
as
part
of
our
open
source
components.
So
here
we
have
a
lgpl
license
that
we
want
to
deny
if
I
wanted
to.
C
I
could
include
an
additional
license
policy
in
here
to
be
able
to
deny
for
licenses
that
we
have
here.
So
maybe
if
we,
if
I,
find
an
MIT
license,
they're,
usually
okay,
but
if
I
I
want
to
be
able
to
flag
it.
I
could
also
have
it
be
denied
such
that
I
need
to
ensure
that
an
approval
takes
place
for
this.
So
I
have
okay.
C
Here's
where
I
can
search
for
what
groups
I
want
to
include
within
my
list
of
approvers,
so
maybe
I
just
want
to
select
myself
as
an
approver,
but
I
could
do
that.
So
I
can
add
an
approver
to
this.
So
now
I
have
a
license
approval
that
is
associated
so
again.
This
is
part
of
our
Dev
secops
operations
that
if
we
come
across
a
license
that
we
don't
want
to
have
a
liability
for
or
we
don't
want
to
have
in
our
application.
C
This
will
automatically
put
in
a
license
approval
that
needs
to
take
place
in
order
for
the
merger
quest
to
be
merged.
Okay
and
then
within
our
policies,
as
I
had
mentioned
before
our
scan
policy.
I
don't
have
one
set
right
now,
but
this
is
how
you
do
it.
You
can
create
a
policy
that
will
automatically
run
as
part
of
a
scan
execution
policy
to,
for
instance,
run
a
dash
scan
on
your
application
whenever
A
Change
Is
Made,
it's
okay.
C
So
that's
what
we
talked
about
in
terms
of
security
within
the
compliance
we
talked
about
the
compliance
project.
We
also
talked
about
the
compliance
pipeline,
that's
included
as
part
of
the
Run
itself.
We
also
talked
about
how
to
assign
that
compliance
framework
to
the
project.
We
also
talked
about
groups,
and
we
talked
about
the
Roll-Ups,
so
a
lot
of
information
here
that
we
welcome
your
feedback
on
and
look
forward
to.
Speaking
with
you
more
on
so
with
that
I'll
go
ahead
and
stop
sharing
the
screen
and
go
ahead
and
allow
Francis
to
continue
on.
B
Implementation
of
a
lot
of
these
controls
that
Tony
went
through
will
be
the
recipe
for
Success,
because
without
those
governance
and
program
execution
plans
trying
to
do
all
these
things
in
a
vacuum
will
lead
to
some
of
those
failures
that
we
talked
about
earlier
in
the
presentation.
So
part
of
our
our
conclusion
is,
if
you're
thinking
about
devops
and
this
shift
to
this
new
paradigm-
think
of
the
security
and
compliance
piece
as
moving
away
from
sequential
to
concurrence
sequential
used
to
be.
B
You
want
to
document
those
events
concurrently
as
well.
You
want
someone
within
your
development
life
cycle
to
approve
that
you're.
Accepting
those
vulnerabilities,
so
exception
management
becomes
an
important
part
of
that
concurrent
devops
approach,
which
means
you
need
to
have
people
that
are
there
to
review
those
exceptions
in
real
time,
so
you're
not
delaying
the
velocity
or
reducing
the
velocity
of
your
development
process.
B
Everyone
is
seen
within
the
same
pipeline
exactly
what
is
being
flagged
up
and
what
needs
to
be
remediated
and
developers
are
empowered
to
act
because,
at
your
merge
request
level,
you're,
seeing
what
vulnerabilities
are
being
introduced
and
creating
that
accountability
for
what
needs
to
be
remediated
prior
to
pushing
into
production
and
with
that
accountability,
you're.
Embedding
security
and
training
in
context,
as
opposed
to
doing
a
secure
development
course,
you're
training
in
context
of
the
things
that
you
need
to
do
to
be
a
better,
more
secure
developer.
B
So
with
that
we're
going
to
be
wrapping
up
here,
we
understand
that
this
is
a
significant
lift
for
a
lot
of
companies
that
don't
have
either
the
resources
or
the
availability
or
the
capacity
to
drive
some
of
these
programs
forward,
and
we
have
a
Professional
Services
team
that
is
here
to
help
with
some
of
the
challenges
or
adoption
blockers
that
may
exist
within
your
teams.
Today,
I'm
not
going
to
go
through
this
whole
slide,
but
the
summation
of
this
is
we're
here
to
help.
B
B
We
have
contact
details
of
our
senior
manager
for
Professional
Services
attached
to
the
slide
and
the
recording
and
you
can
reach
out
to
those
individuals
and
then,
lastly,
as
we
wrap
up
for
the
last
last
few
minutes
of
this,
we
will
have
a
feedback
poll
that
is
available
to
you
and
just
general
in
time
real
time
feedback
to
this
session.
Please
use
it
before
you
log
up
from
this
session.
We
appreciate
any
real
time
feedback
and
the
Q
a
that
has
been
going
on
in
the
background
throughout
this
process.
B
So
thank
you
very
much
for
all
those
questions.
Hopefully
you're
getting
answers
to
those
in
the
background
as
well,
but
yeah
as
we
wrap
up.
Thank
you
reach
out.
Let
us
know
if
we
can
be
of
service
or
have
more
one-on-one
conversations
about
your
devsecond
Ops
journey
and
your
whole
secure
in
the
developmental
life
cycle.
B
We'll
take
these
topics
and
chunks
and
do
a
deeper
dive
into
some
of
these
Concepts
and
future
workshops
and
webinars,
and
we
also
have
a
YouTube
channel
that
has
some
detailed
prior
recordings
for
some
of
these
topics
as
well.
So
with
that
we'll
wrap
up,
thank
you
again
for
your
attendee
for
attending
today
and
look
forward
to
talking
to
you
all
soon.