►
From YouTube: TT211: Verify and Secure
Description
In this session, we go over our product functionality in the verify and secure stages and how to use this functionality in sales conversations.
Tanuki Tech is GitLab's world-class sales/technology enablement program. You may read more about it here: https://about.gitlab.com/handbook/marketing/revenue-marketing/sdr/tanuki-tech/.
Speaker notes: https://www.linkedin.com/in/christopher-wang-0835b226/.
A
All
right
cool
can
all
right.
So,
let's
begin
verify
and
secure
honestly,
the
way
that
I
think
about
this
session
katie
is
that
this
is
our
sixth
session.
A
This
is
the
best
session,
and
if
you
understand
this-
and
if
you
can
articulate
this,
then
it's
basically
going
to
be
like
almost
80
percent
of
all
of
our
sales
motions.
So
everything
was
like
building
it's
like
a
most
karate.
Kid,
like
you
know,
wax
on
wax
off.
This
is
the
one
in
which,
like
you,
learn
how
to
throw
like
a
mean
punch.
So
let's
talk
about
why
right
so
in
terms
of
the
agenda,
what
are
we
doing
today?
Our
goal
is
to
better
articulate,
verify
verifying
secure
functionality.
A
Once
again,
this
is
almost
our
entire
value
proposition.
How
are
we
going
to
do
this?
We're
going
to
understand
what
this
is
from
a
technical
perspective,
I'm
not
going
to
inundate
you
in
terms
of
you
know
like
hey
this
dependency,
blah
blah
and
whatever,
like
everything's,
going
to
be
super
tailored
to
why
customer
cares
about
these
things
and
why
gitlab
can
fundamentally
help
our
customers.
A
The
other
thing
that
we're
going
to
do
is
we're
going
to
see
these
stages
in
action
in
gitlab,
I'm
a
visual
learner,
so
I'm
just
going
to
show
you
how
it
works
in
terms
of
our
product
itself,
all
right.
So
if
you
look
at
command
the
message,
we
basically
list
out
all
of
our
differentiators
in
terms
of
importance,
and
I
literally
copied
and
pasted
this
from
our
handbook,
the
top
three
differentiators
that
we
have
in
the
market
all
have
to
do
with
verifying
secure.
A
This
is
extremely
important
to
understand,
because
this
these
are
unique
value
points
that
our
customers
cannot
easily
replicate.
A
One
of
the
things
that
I
want
to
talk
about
this
and
is
that,
even
though
this
is
these
are
unique
differentiators
for
us
now,
it's
really
not
going
to
be
the
case
in
a
year
to
a
year
and
a
half
because
microsoft's
pouring
all
this
money
into
github
and
if
you
give
them
enough
time,
they're
going
to
catch
up
for
a
lot
of
these
different
areas.
A
A
So
I
think
point
number
three
have
already
driven
home,
but
understanding
these
two
features
is
really
really
really
important
to
our
customer
conversations:
scm
and
plan.
It's
like
tape
measures
when
I'm
in
a
hardware
store
and
I'm
trying
to
select
between
one
and
another.
I
don't
really
care
right
so,
like
one
might
be
a
little
bit
longer
than
another,
but
fundamentally
don't
care.
They
all
fundamentally
do
the
same
thing,
and
why
is
that
part
of
the
reason?
Why
is
because
they
operate
in
crowded
spaces
right?
A
So
I
typed
into
google
best
management
tools,
and
I
got
this.
One
site
is
the
number
one
ranked
site,
but
the
40
best
project
management
software
tools.
Do
you
want
to
compete
against
40
other
tools,
or
do
you
want
to
be
unique
and
talk
about
our
unique
differentiators
and
basically
instantly
separate
yourself
from
every
every
other
tool?
A
That's
out
there
right
so
get
lab
has
unique
differentiators
right
now
they
will
probably
stick
around
for
a
year
and
a
year
and
a
half
because
of
our
first
movers
advantage,
but
we
really
got
to
make
great
use
of
this
next,
the
time
that
we
have
so
that
we
can
use
these
in
our
sales
conversations
and
to
get
like
customers
yeah
so
get
lab
special.
Let's
tell
the
story
one
of
the
things,
and
this
has
to
do
with
that
homework.
A
B
A
Is
just
what
marketing
wants
me
to
say:
gitlab
really
is
special
and
the
idea
of
having
one
unified
tool
for
the
entire
devops
life
cycle.
Basically,
no
one
else
is
doing
this
in
out
of
the
entire
tech
space.
People
don't
fully
understand
the
value
behind
this,
which
is
part
of
the
reason
why,
in
our
conversations,
I
think
that
one
of
the
things
that
we
have
to
do
so
much
is
to
educate
everyone
just
because,
like
literally
they
see
us
as
another
tool,
are
we
a
tool?
A
Yes,
but
like
we
are
different
than
every
other
tool,
all
right,
so
let's
just
dive
right
into
verify.
So
imagine
you're
writing
a
300
page
book
without
your
automated
like
spell
and
grammar
checker,
and
then
you
hand
it
into
an
editor.
Well,
if
you're,
like
most
people,
then
you're
going
to
spell
a
lot
of
stuff
wrong
and
then
the
editor
is
probably
going
to
get
pissed
and
then
they'll
spend
all
this
time.
Editing
everything
hand
it
back
to
you,
then
you
have
to
go
like
and
then
you
basically
would
go
back
and
forth.
A
Like
maybe
10
times.
Each
of
these
times
would
take
a
ton
of
time,
which
basically
is
money
right,
because
time
is
money.
So
if
you
had
an
automated
spell
grammar
checker,
while
you
were
writing
your
paper
or
your
book
itself,
how
would
that
speed
up
your
project
well
being
able
to
edit
this
in
real
time?
It
would
basically
give
you
feedback
and
it
would
save
your
editors
time.
A
A
So
we
got
to
talk
more
about
agile
everyone.
If
you
talk
to
any
director
or
even
like
a
senior
manager
of
implementing
agile,
something
that
people
care
about,
it's
one
of
their
strategic,
it's
on
their
strategic
roadmap
right
and
just
to
you
know
like
as
like
a
reminder
that
that's
the
word,
so
agile
is
basically
a
philosophy
and
ci
cd
is
how
you
implement
agile.
So,
just
as
an
example,
social
justice
is
like
this,
like
theoretical
concept,
and
how
do
we
get
social
justice?
A
Well,
one
way
we
can
get
social
justice
is
giving
everyone
the
right
to
vote
right.
So
this
is
basically
the
takeaway
without
getting
super
much
in
the
weeds,
a
development
team
implementing
agile,
with
a
mature
ci
cd
stack.
So
what
I
basically
mean
by
this
is
like
they
have
really
great
agile
methodologies.
They
have
a
really
great
ccd
system,
is
maybe
10
times
more
effective
than
someone
who
doesn't
have
these
things.
A
So,
like
there's
all
sorts
of
studies
that
validate
this,
this
isn't
just
marketing
talk
and
I've
actually
seen
it
in
my
own
engineering
career
about
how
this
can
really
like
help.
People
develop
better
software
faster.
The
big
takeaway
with
this
is
that
everyone's
trying
to
implement
agile
most
people
are
failing
at
it,
and
the
value
add
that
we
have
as
a
company
is
that
gitlab
makes
this
easy.
A
So
just
also
a
reminder
about
agile
versus
waterfall.
Most
people
develop
software
through
what
we
call
a
waterfall
methodology,
and
so
what
that
means
is
that,
let's
just
say
that
we're
building
a
house
right
so
I'd
meet
with
a
contractor.
A
I
would
write
down
like
a
10-page
document,
exactly
detailing
what
I
want
and
then
I
would
disappear
for
you
know
like
six
months
and
then
come
back
in
and
find
my
house
well.
The
problem
with
this
is
that
there's
always
some
interpretation
in
the
requirements
right.
Are
you
always
like
leave
something
out
or
something
it's
not
as
detailed
as
it
could
be,
and
then
so
the
problem
is
that
your
contractor,
he
might
misinterpret
something,
build
a
room,
the
wrong
way
and
then
build
multiple
other
rooms
on
top
of
that
room.
A
So
it's
it's
not
all
that
simple
and
just
like
updating
this
one
room
on
the
bottom
now,
because
everything
else
is
built
on
top
of
it.
So
when
you
have
a
waterfall
type
of
software
development,
then
it's
very
iterative
at
the
end,
in
a
sense
that,
like
your,
your
stakeholders
come
back
they're
not
happy.
The
developers
have
to
rip
stuff
out
fix
stuff,
that's
super
expensive,
because
so
many
other
things
are
bolted
on
top
of
it
and
it's
very
expensive
and
time
consuming.
So
the
difference.
A
If
you
have
a
waterfall
project,
that's
maybe
four
months
after
the
developers
are
done,
handing
in
everything
it
might
take
them,
maybe
two
months
or
like
50
additional
time
to
get
everything.
Finally,
right
so
contrast
that
with
agile
agile
is
more
iterative,
so
the
idea
with
agile
is
hey.
Let's
lay
the
foundation
now,
let's
bring
in
you
know,
bring
me
back
in
hey:
do
you
like
the
foundation?
Yes
or
no
can
do
we
need
to
update
it?
No
okay,
great
and
then
you
know
put
up
the
scaffolding.
Is
the
scaffolding?
A
What
you
expect
are
these
rooms
to
write
dimensions
and
then
so
the
great
value,
if
you
have
an
agile
approach,
is
that
you
can
you
can
you
can
find
errors
as
they're
happening,
which
allows
you
to
course
correct
way
quicker,
so
the
benefit
of
agile?
Is
that
prevents
you
from
going
down
the
wrong
path
and
as
opposed
to
building
a
room
in
the
wrong
place
and
then
bolting
on
all
these
additional
rooms?
On
top
of
it,
you
have
one
room
that
we
would
catch
a
mistake
as
this
room
is
being
built.
A
You
know
saving
us
time.
Ultimately,
so
everyone
wants
to
implement
agile.
Most
people
are
unsuccessful
and
part
of
the
reason.
Why
is
because
agile
requires
a
lot
more
work
right,
so
you
have
a
lot
more
check-ins.
You
have
to
communicate
more.
Sometimes
people
don't
want
to
communicate.
Sometimes,
communications
like
not
complete,
right
and
get
lab
allows
you
to
automate
a
lot
of
this.
Ultimately
saving
you
time
money
and
allowing
you
to
implement
agile
quickly.
So
another
thing
to
talk
about
is
that
it
eliminates
human
error
right.
A
So
you
know
with
automation,
everything's
standardized,
so
this
should
sound
pretty
similar
to
like
ansible
right
yeah.
A
That's
cool
all
right,
so
let's
actually
just
take
a
look
at
gitlab,
so
this
is
git
lab
itself.
A
People
are
trying
to
implement
all
their
code
changes
and
so
here's
all
the
code
changes
that
are
coming
in,
as
you
can
see
over
here,
every
single
one
of
these
code
changes
that
are
coming
in
we're
actually
running
tons
and
tons
and
tons
of
tests
on
it.
So
the
tier
one
level
of
test
that
we
have
is
just
the
fact
that
other
people
are
looking
at
it.
A
So
this
is
what
we
call
the
code
review
process
and,
as
you
can
see,
this
person's
peers,
there's
people
that
are
questioning
him
on
why
he
did
this
a
certain
way
right,
so
he's
saying:
hey
have
you
thought
about?
You
know
doing
it
some
other
way,
and
then
they
go
back
and
forth,
ultimately
creating
a
better
product
when
you
have
more
people
collaborating
the
other
thing
that
I
really
want
to
point
out
is
pipelines,
so
these
are
basically
where
all
of
our
automated
checks
come
in.
A
In
the
beginning
of
this
presentation,
I
talked
about
how
like
for
word
documents.
You
have
automated
checks,
for
you
have
automated
checks,
for
you
know
like
spelling
and
grammar
for
for
gitlab.
We
have
automated
checks
for
software
and
then
so,
there's
around
like
five
to
six
different
things
that
we
do,
but
it's
extensible,
so
you
could
literally
have
ten
different
things
that
we
can
do
so
every
one
of
these
every
one
of
these
commits
that
are
coming
in.
We
literally
do
for
this
specific,
merge
request.
A
A
It's
a
seven
automated
phases
to
prepare
for
automated
phases
for
building
and
like
test
preparation
in
terms
of
quality
check,
there's
maybe
25
different
phases
that
we
use
for
git
lab
itself
and
then
so.
Ultimately,
this
is
preventing
people
from
going
down
that
wrong
path.
All
of
these
integrated
quality
checks,
so
some
of
these
are
security
related.
Some
of
these
are
just
sort
of
like
verifying
individual
things
in
our
product
itself,
so
this
is
for
gitlab
itself.
A
An
individual
check
could
be
hey.
Does
this
button
work
as
intended?
Does
this
button?
If
I
click
it,
does
it
produce
this
drop
down,
but
there's
other
types
of
tests
as
well
so
like
if
I
log
out
of
gitlab,
does
it
take
me
to
the
right
screen?
If
I
log
back
in,
does
it
take
me
to
the
right
screen?
What
happens
if
I
try
to
log
in
five
times
all
using
the
same
account
true
to
reject
me,
you
know
you
know,
and
so
on
and
so
forth,
so
that
type
of
specific.
A
That
type
of
specific
you
know
like
this
has
to
do
with
what
we
call
software
testing,
and
this
is
actually
what
I
used
to
do
full
time.
I
used
to
write
software
tests
as
my
job
and
how
a
software
test
works.
Is
that
here's
this
house
right
how
I
can
verify
this
house
as
a
whole?
If
it's
structurally
sound,
is,
if
I
like
verify
each
individual
chunk
is
sound.
So
if
I
put
pressure
on
this
window,
does
it
like
fall
out?
Hey
you
know,
like
is
the
concrete
up
for
safety
specifications?
A
Are
there
fire
detectors
in
every
single
in
as
like
many
rooms,
as
required,
so
for
ansible,
which
was
the
last
product
that
I
worked
on,
there
were
probably
there
were
thousands
of
software
tests
for
antsful
itself,
and
each
one
of
these
things
was
could
be
as
small,
as
does
this
button
work
as
intended
to
something
that's
as
big
as
hey.
A
If
I
turn
ansible
tower
off
and
I
have
to
turn
it
back
on,
like
you
know,
does
it
boot
back
up
so
people
the
the
type
of
people
that
like
make
the
software
tests
are
called
test
engineers
and
what
they
do
all
day?
Is
they
write
software
tests
and
they
administer
them?
So
that's
what
gitlab
does
there's
all
sorts
of
different
software
tests
and
the
basic
point
with
this
is
that
gitlab
does
all
of
this
stuff
and
it's
actually
really
good
at
like
integrating
with
all
the
different
types
of
tests
that
people
have.
A
B
Oh
okay,
yes,
you
do.
Okay,
one
of
the
prospects
that
I'm
looking
at
is
qa
team
lead,
and
so
he
mentions
like
all
these
different
things.
So
clearly
he
can
code
code
in
a
lot
of
different
languages.
He
says
different
things
in
his
tool.
Sets
and
stoolstack
would
a
relevant
piece
of
information
to
share
with
him
be
talking
about,
like
the
last
slide
that
you
said
how
gitlab
has
quality
or
it
has
a
software
test
built
in
or
it's.
A
Yeah,
so
the
way
different
is
that,
like
what
they're
doing
is
we
don't
give
you
the
software
test,
but
we
can
run
the
software
test
for
you.
So
let
me
just
explain
it.
So
it's
like
here's.
Here's
like
this
house
right.
You.
A
Individual
pieces
of
code
that
say
hey:
is
there
a
fire
alarm
here?
Is
there
a
fire
alarm
here?
Is
there
a
fire
alarm
here
and
then
you
run
all
these
software
tests
in
some
sort
of
automated
loop.
What
happens
is
that
the
software
testers?
They
come
back.
You
know
every
morning
and
then
they
basically
look
at
the
test
results
and
then
so
that's
how
their
job
works.
So
we
don't
give
you
the
tests
themselves,
but
you
need
some
sort
of
like
server.
A
B
So
is
that
a
conversation
that
you'd
be
trying
to,
I
don't
know,
discover
pain
points
with
jenkins.
A
A
A
A
So
when
we
were
in
college,
we
were
writing
all
sorts
of
papers
and
then
we
had
like
the
chicago
style
guide
or
the
mla
handbook,
and
then
that's
like
how
we
basically
like
determine
how
citations
and
you
know
how
to
basically
write
well,
there's,
actually
an
analogous
thing
for
coding
which
tells
you
how
many
like
spaces
you
need
so.
A
Really
funny
in
python
there's
this
thing
called
pep
8
and
it
tells
you
things
like
hey.
Do
you
indent
one
time
or
two
times
like?
Do
you
use
like
how
long
should
your
lines
be
and
stuff
like
that,
so
this
is
actually
really
important.
I
know
that
it
sounds
really
ridiculous,
but
the
whole
reason
why
there's
linting
is
so
that
coding
is
more
readable
for
the
next
guy
and
you
don't
write
like
your
coding
stuff
in
some
sort
of
crazy
way,
which
is
actually
a
really
big
problem.
A
It's
not
something
that's
super
intuitive,
so
you
might
just
have
to
take
my
word
for
it,
but
just
to
summarize
what
linting
is?
Is
it's
basically
implementing
style
guidelines
for
coding,
just
like
how
mla
handbook?
Theoretically,
if
you
wrote
everything
according
to
mla,
your
papers
would
sound
better,
so
things
like
pepe
allow
you
to
write
your
code
in
a
more
clear
manner
which
helps
out
your
entire
team,
because
obviously
programming
is
like
you
know,
like
a
team
sport
somewhat,
all
right,
so
that's
linting
next
up
is
a
review
apps.
A
A
We
don't
talk
about
them
enough,
so
in
the
merge
request
process,
whether
or
not
you're
using
bitbucket
or
github-
or
you
know,
like
gitlab
or
whatever,
then
fundamentally,
what
you're
doing
as
an
engineer
is,
I
have
to
go
proofread
other
people's
stuff
before
they
get
their
code
merged
right
and
all
I
see
is
the
lines
that
they've
changed
so
over
here.
You
know
this
is
just
sort
of
four
lines
of
change.
A
It's
changing
some
sort
of
authentication
thing
and
then
I
can
ask
a
question,
but
the
big
problem
with
this
is
that
fundamentally,
I'm
only
guessing
at
what
this
code
does
right.
I
don't
fundamentally
know
if
you
have
a
review
app,
then
it
will
actually
create
a
live
version
of
that
application
that
you
can
see
the
changes
and
then,
during
the
review
process,
you
can
know
concretely
what
this
change
does
as
opposed
to
just
guessing
what
this
change
does.
Does
that
make
sense.
A
B
Yeah
also
with
linting
is,
is
a
is
a
sorry,
is
linting
a
functionality
of
gitlab
where,
like,
if
a
developer
put
in
code
that
didn't
match
the
style
guidelines
of
whatever
they
were
writing
and
that
it
would
correct.
While
they
were
writing
it
or
is
it
a
test
that
you
do
after
like
similar
to
a
security
test
where,
like
it'll
kind
of
just
continuously,
run.
A
Yeah
so
it
would,
it
would
lent
during
the
merge
process
the
merge
review
process
itself.
So
if
you
remember
like
that
gigantic,
like
flow
chart,
that
was
like
there's
like
30
stages
in
testing,
that's
when
lenting
would
run
and
then,
if
it
said
like
hey,
you
introduced
four
things
that
don't
make
sense.
Then,
in
the
merge
request
it
would
show
those
four
things.
A
Yep,
so
this
is
lint
ink
once
again
pep
8,
but
like
yeah,
it
will
tell
you
like
hey
how
do
you
do
it?
How
do
you
indent?
How
long
should
your
lines
be
so
like
all
sorts
of
like
different
conventions
for
writing
code
yeah?
So
if
I
didn't
ever
view
apps,
this
is
just
what
I
see.
A
I
have
to
decide
whether
or
not
to
accept
this
merge
request,
based
on
my
understanding
of
what
this
does,
which
ultimately
is
incomplete
right
with
a
review
app,
you
get
a
live
version
of
the
application
and
then
now
you
can
bang
around
on
it
and
see
if
it
works
or
not,
which
is
way
better.
It
will
save
your
developers
a
lot
of
time.
A
Okay,
so
that's
the
verify
stage.
Let's
talk
about
security.
This
is
these
three
things
here
are
command
of
the
message.
This
is
the
last
one,
third
of
command
the
message
and
we're
talking
about
reducing
security
and
compliance
risk.
So
this
is
super
important
to
understand.
Gitlab
is
special
and
that
we
offer
security
scanning
as
part
of
the
development
process.
A
Right
now
we
are
the
only
we
have
the
most
complete
solution
in
the
market,
for
this
github
is
trying
to
catch
up.
They
do
have
some
stuff,
but
in
all
honesty
we
are
way
ahead
right
now,
so
we
gotta
talk
about
the
status
quo
right
for
the
vast
majority
of
development
shops.
They
verify
security
at
the
end
of
projects
and
obviously
that's
not
agile
right.
A
So
in
terms
of
building
the
house
hey,
we
could
have
built
something
that's
incorrect
because,
but
because
we're
testing
this
all
the
way
at
the
end,
we
might
have
to
correct
a
lot
of
things
and
rip
out
a
room.
A
Another
thing
about
the
status
quo
is
that
most
smaller
shops
they
can't
hire
their
own
dedicated
security
people,
so
they
actually
pay
for
security
contracting
and
these
guys
pay
ridiculous
amounts
or
get
paid
ridiculous
amounts
of
money
get
lab
allows
you
to
shift
left,
and
this
is
something
that
our
marketing
talks
about
a
lot.
I
think
that
it's
really
important
to
be
cognizant.
When
we
talk
about
this
in
customer
conversations
that
most
people
don't
know
what
shifting
left
means.
A
I
I
guarantee
you
that,
like
at
red
hat,
if
I
pulled
all
the
engineers
and
said
hey,
do
you
know
what
shifting
left
means
then
less
than
five
I'd
say,
like
less
less
than
10,
for
sure
of
the
engineers
would
know
what
this
means,
but
it's
fundamentally
like
one
of
the
big
problems
that
I
have
with
our
marketing.
Is
that,
like
we
advertise
ourselves
as
shifting
left,
but
no
one
knows
what
shifting
left
means.
So
we
just
need
to
be
careful
when
we're
using
this
term,
but
what
is
shifting
left
means.
A
A
Fixing
it
the
after
with
get
lab
is
that
our
test
will
actually
determine
when
you
know
a
new
security
vulnerability
or
something
that's
not
safe,
is
built
in,
and
then
people
will
comment,
because
all
of
your
security
engineers
are
now
on
this
tool,
whereas
before
they
weren't
people
are
collaborating
across
team,
then
a
security
engineer
could
then
say:
hey
I've
taken
a
look
at
your
test
results.
You
should
fix
it
this
way
and
then
the
developer
is
like.
A
A
So,
let's
just
talk
about
how
much
money
these
guys
make
in
terms
of
just
like
you
know
like
the
qualifying
questions
that
would
really
find
out
pain
points,
so
you
could
ask
like
hey:
how
does
your
security?
You
know,
testing
work,
you
know,
are
you
happy
with
it
like?
Do
you
contract
people
out
or
do
you
have
people
that
are
internal
if
you
contract
them
out?
Are
you
happy
with
the
amount
of
money
that
you
spend
on
this
right?
Security
contractors
make
a
ton
of
money.
A
As
you
can
see,
it's
like
the
more
specialized.
You
are
as
an
engineer,
the
more
money
you
require,
and
these
guys
are
like
elite
engineers.
They
do
not
come
cheap,
so
gitlab
gives
you
the
ability
to
do
all
this
in
an
automated
fashion.
Saving
you
money,
but
it's
also
something
to
be
cognizant
of,
is
that
our
security
testing
only
comes
with
the
highest
tier
of
gitlab,
which
is
five
times
as
much
expensive
as
the
second
tier.
So
we
basically
have
to
justify
the
value
of
that.
A
Well,
how
do
we
justify
the
value
of
that?
Is
that
hey,
you
don't
have
to
hire
these
guys
or
you
can
hire
less
of
these
guys
right
all
right,
so
there's
a
bunch
of
different
phases
with
security
testing
and
each
of
these
phases
matters
a
lot
and
understanding
these
and
articulating.
These
is
really
important
for
our
customer
conversations,
so
something
that
we
talked
about
all
the
time
is
sas
and
das.
These
are
complementary.
A
A
So
that
is
why
it's
called
static
application
security
testing,
so
contrast
that,
with
dynamic
application
security
testing,
this
requires
a
live
running
version
of
your
application
and
what
it
does
is
it's
going
to
try
to
break
your
website,
and
so
what
they
do
is
basically
hey.
If
I
log
in
500
times
within
a
second,
then
can
I
like
break
into
your
website?
A
If
you
know,
if
I
log
in
the
same
account
for
my
phone
and
then
a
macbook,
and
then
you
know
from
russia,
then
like
it
does
like
website
get
confused
like
does
it
handle
all
those
like
requests
in
the
right
way.
So
once
again,
the
difference
between
these
is
that
they're
complementary.
You
really
need
both
sas
is
80
of
what
you
need,
because
it's
faster
but
dash
is
totally
needed
too.
So
sas
is
just
looking
at
the
code
dash.
You
have
a
live
running
version
application
that
you're
trying
to
exploit
in
some
manner.
A
Another
thing
that
people
can
do
is
they
try
to
inject
and
code
here
so
for
like
this
username
field,
if
I
typed
in
like
so
it's
expecting
a
string
like
you
know,
like
c
wang,
or
you
know
something
like
that,
but
if
I
actually
type
in
like
dot
json.inject,
you
know
like
code
here,
then
sometimes
I
can
break
this
application
and
exploit
it.
That's
actually,
fundamentally
how
some
websites
get
hacked
and
I'll
show
you
that
in
a
little
bit,
so
the
other
thing
moving
on
so
one
other
things
that
we
do
is
container
scanning.
A
Everyone
wants
to
move
to
containers
right
now
around
five
to
ten
percent
of
all
workloads
are
in
containers,
and
everyone
understands
that
in
the
next
five
to
ten
years
that
they
want
to
use
containers.
But
one
of
the
big
problems
with
containers
is
that
99
of
them
are
insecure.
It's
a
huge
problem.
A
How
do
we
verify
that
it's
secure
and
simply
because
it
takes
time
to
figure
all
that
stuff
out
security
and
testing,
and
all
that
other
stuff
is
going
to
lag
behind
the
technology
itself?
That's
the
reason
why
container
security
is
a
big
space
right
now
and
what
we
can
allow
you
to
do
is
if
you're
using
any
containers
that
are
insecure,
we'll
actually
let
you
know
that
they're,
insecure
and
we'll.
Let
you
know
why
they're
insecure!
A
So
if,
like
this
container
that
you're
using,
has
these
five
vulnerability
problems
with
them,
then
we
will
let
you
know
those
exact
five
foot
vulnerability
problems.
We
do
this
using
this
thing
called
clear,
so
dependency
scanning
once
again
as
a
reminder,
so
just
like
how
a
car
is
made
up
of
all
these
different
components,
you
know,
and
so
you
have
wheels-
you
have
a
transmission
of
an
engine
and
they're
all
bolted
together.
A
All
of
software
is
made
up
of
different
components.
So
for
a
website
you
have
a
database
that
stores
all
the
user
information.
You
have
a
web
front
end,
you
have
an
api
and
then
they're
all
integrated
together.
So
each
of
those
individual
components
you
can
think
of
as
like
a
dependency,
and
the
problem
is
that
each
of
these
things
can
go
out
of
date
or
may
need
a
safety
recall
from
time
to
time.
So
it's
like,
if
your
car,
you
have
a
problem
with
the
airbags,
you
might
need
to
fix
them.
A
It's
the
same
thing
with
software,
so
we
might
find
out
that,
like
this
version
of
your
your
apis,
actually
like
has
a
problem
with
it,
and
so
you
need
to
update
it,
and
so
what
we
allow
you
to
do
is
we
will
scan
all
of
the
constituent
parts
of
your
application
and,
let
you
know,
hey,
you
know:
j
you're
using
django
3.1.2.
A
Well,
it
has
this
problem.
This
problem,
this
problem,
you
should
consider
upgrading
to
3.2.5
because
that's
when
the
problems
go
away,
so
we
allow
you
to
do
that
in
the
security
scanning
process.
A
Plus
testing
is
something
that
is
on
our
roadmap,
so
over
here
we
just
acquired
two
companies
and
our
goal
is
to
have
it
built
into
git
lab
in
the
fall
and
have
it
like
really
completely
like
where
this
is
like
a
big
part
of
our
value
prop
in
the
early
spring
of
next
year.
So
what
fuss
testing
is?
Is
it's
super
super
advanced
security
testing?
The
vast
majority
of
people
don't
know
about
it,
but
it's
really
important.
A
I
do
not
have
an
instagram
account,
so
it's
basically
requiring
me
to
sign
up.
If
I
go
to
the
signup
field,
then
it's
expecting
a
phone
number
and
email
it's
expecting
by
name
and
then
a
username
and
a
password
right,
but
I'll
just
give
you
an
example
of
a
fuzz
test
so
as
opposed
to
me
typing
in
some
letter,
some
letters
and
then
some
more
letters.
A
A
So
this
is
obviously
fake,
but
you
can
inject
code
into
these
fields
and
hack
websites.
So
there's
all
sorts
of
different
things.
You
have
mysql
injections,
you
have
command
line
injections,
you
have
a
javascript
injections,
but
from
fundamentally
what
these
are
is
that
I'm
exploiting
this
website
by
injecting
code
into
these
form
fields
where
they're
not
intended,
and
so
it's
a
huge
problem
honestly
as
an
engineer,
speaking
firsthand.
A
If
I
had
this
in
my
job,
it
would
have
saved
me
maybe
like
20
30
of
my
time.
So
it's
a
really
huge
deal
and
it's
on
a
road
map
and
once
we
have
it
implemented,
we
should
talk
about
it,
a
lot
all
right.
So
that's
all
the
security
features
that
are
really
important.
There
are
more
minor
ones,
but
just
some
miscellaneous
stuff
that
we
want
to
talk
about
in
terms
of
you
know
just
our
customer
conversations,
because
these
are
things
that
are
gonna,
come
up
in
your
customer
conversations.
A
So
there's
two
things
that
we
need
to
know
about.
What
a
gitlab
runner
is
is
it's
the
machine
that
runs
all
of
the
tests
so
I'll.
Just
give
you
an
example
of
this
there's
a
machine
that
runs
this
website,
but
there's
a
separate
machine
that
actually
performs
all
of
these
tests
and
the
get
lab
runner
is
the
machine
that
performs
all
these
tests.
So
it's
the
one
that
will
spin
up.
You
know
that
will
run
your
unit
tests
and
things
like
that.
A
Our
runners
are
actually
really
really
good,
and
one
thing
that
you
could
do
in
terms
of
gear
jenkins
conversations
is
just
talk
about
how
easy
they
are
to
set
up
and
scale,
so
they
can
scale
up
and
down
the
cloud
that
saves
you
a
lot
of
money.
It's
not
something
that
jenkins
really
does
another
thing
about
them
is
that
they're
super
easy
to
upgrade
jenkins
is
really
difficult
to
upgrade.
So
we
have
a
lot
of
really
great
comparative
things
here.
A
The
other
thing
is
that
there's
this
thing
that
people
customers
are
going
to
ask
you
about
it's
the
gitlab.ci.yaml
file,
and
what
this
is
is.
A
This
is
the
file
that
controls
all
of
these
tests,
so
over
here
you
can
see
that
I
have
seven
phases,
then
two
then
two
then
three
like
around
30
and
then
two
dots
and
then
one
so
there's
one
file
that
controls
what
happens
and
if
you
take
a
look
over
here,
that's
this
file
and
you
can
see
all
the
different
stages
here
and
basically
everything
is
specified
that
we
just
saw
because
of
this
file.
So
it's
like
the
master
settings
file
that
determines
what
happens
in
our
ci.
A
I
know
that
does
a
lot
of
information,
but
just
to
summarize
everything
real
quickly.
A
Yeah,
so
here's
command
of
the
message
and
we
have
a
unique
story
and
our
unique
story
is
that
it
is
one
tool
for
your
entire
devops
life
cycle,
ultimately,
saving
you
time
money
and
we
allow
you
to
implement
agile,
which
will
give
you
transparency
and
better
collaboration
across
your
organization.
So
everyone's
under
pressure,
most
engineering
projects
fail.
A
So
that's
that's
the
verifying,
secure
presentation.