►
From YouTube: 12.4 Kickoff - Secure Static & Dynamic Analysis & Defend
Description
Kickoff for the GitLab 12.4 release, for the Defend stage and the Static Analysis and Dynamic Analysis groups for Secure stage
A
All
right,
so
thanks
everyone
for
joining
this
is
going
to
be
the
kickoff
call
for
12.4
and
the
secure
and
defense
stage.
So
what
we're
going
to
do
during
this
meeting
is
review
the
directional
items
that
we
as
a
group
are
marking
deliverable
in
the
foe
for
release,
so
we'll
talk
through
each
of
the
individual
feature
cards
here.
Talk
about
the
problem
that
we're
trying
to
solve,
as
well
as
the
proposal
that
we're
currently
going
to
be
working
towards
as
part
of
the
next
iteration.
A
So
with
that,
let's
start
with
the
the
top
one,
which
is
going
to
be
sassed
for
kubernetes
manifests
so
SAS
for
kubernetes
manifests
the
problem.
We're
going
to
be
trying
to
solve
with
this
one.
Is
that
it's
possible
when
writing
a
kubernetes
manifest
when
writing
those
files
that
define
how
your
cluster
is
going
to
work
and
operate,
bonor
abilities
could
potentially
be
introduced.
A
That
may
be
inside
of
a
user's
project
so,
similarly
to
how
we
can
do
SAS
scanning
for
other
languages
being
able
to
scan
kubernetes
manifests
for
vulnerabilities
as
well
will
help
to
resolve
any
issues
that
are
identified,
especially
as
we're
going
to
see
more
and
more
of
our
users
using
kubernetes
to
deploy
containers
inside
of
cluster
environments.
This
is
going
to
be
even
more
impactful
any
questions
on
this
one.
B
Real
quick
just
to
clarify,
so
this
is
sassed,
we're
not
I
mean,
and
you
could
argue
about
the
nomenclature.
Whether
or
not
secret
detection
is
separate
from
sassed
itself
whoo,
but
the
the
problem
to
solve
kind
of
hints
at
a
secret
detection
kind
of
approach
as
well.
Are
we
looking
to
get
that
or
are
we
limiting
our
ambition
to
just
a
SAS
scanner
or
a
mine?
Is
this
a
distinction
without
a
difference.
A
For
the
first
iteration,
we're
essentially
going
to
be
using
what's
available
in
cube
Seck
today
and
servicing
those
results.
So
if
there
are
more
secret
detection
capabilities
as
part
of
cube,
Seck
we'll
expose
those,
but
certainly
there's
going
to
be
more,
we
can
do
with
secret
detection
as
a
whole
beyond
just
the
kubernetes
SAS
scanning.
A
Secondly,
we're
going
to
be
offering
SAS
support
for
the
react
framework,
which
is
a
framework
that
is
used
to
build
JavaScript
applications.
We're
starting
to
see,
reacts
become
more
and
more
popular
in
the
market.
More
developers
and
more
users
are
using
it
so,
similarly
to
how
we
can
do
SAS
game
for
other
languages,
we
want
to
offer
this
for
projects
written
with
react
as
well
to
be
able
to
identify
any
of
those
potential
issues
that
may
arise
and
introduce
a
vulnerability
into
the
code.
A
And
thirdly,
we're
going
to
be
focusing
on
making
sass
compatible
with
private
dependencies
and
the
problem
we
want
to
focus
on
solving
like
this
is
that
we
know
that
not
every
dependency
in
a
project
is
going
to
be
open,
source
or
publicly
available.
So
we
are
want
to
work
on
making
that
experience
better
for
those
projects
that
do
have
private
dependencies
that
are
going
to
be
hosted
in
a
repo.
That's
not
public!
A
A
Okay,
so
that
is
the
set
of
three
items
that
are
going
to
be
focusing
on
secure
for
static
and
dynamic
analysis
that
are
deliverable
in
this
release
will
switch
forwards
and
look
at
defend
now,
and
so
the
capability
we're
going
to
be
focusing
on
defend
for
12:4,
is
allowing
blocking
mode
for
the
Web
Application
Firewall.
So
the
Web,
Application,
Firewall
or
whack
that
we
introduced
in
12:3
is
currently
configured
with
the
default
set
of
rules,
and
it's
currently
configured
to
only
report
potentially
malicious
traffic
that
it's
identified,
which
is
great
because
you
get
that
visibility.
A
You
need
to
see
what
types
of
attacks
you're
under,
but
in
twelve,
four
we're
gonna.
Let
you
go
and
take
the
next
step
and
actually
block
that
potentially
malicious
traffic.
That's
been
identified
that
way,
anything
that
the
web
identifies
never
even
hits
your
application
where
it
could
potentially
cause
damage.
A
Now
that
said,
this
will
be
done
in
a
way
that
fits
our
security
paradigm,
as
well
as
our
defend
guiding
principles,
specifically
that
this
is
going
to
be
an
opt-in
capability.
So
you
can
enable
the
blocking
mode
on
the
web
when
you're,
confident
it's
not
going
to
have
an
impact
on
any
of
your
good
traffic
and
when
you're
ready
to
enable
that
that
blocking
setting,
as
opposed
to
the
visibility.
Only
setting.
C
A
Good
question:
it's
probably
a
little
bit
too
detailed
for
this
call
since
we're
talking
mostly
about
the
high
level
problems
we
want
to
solve,
but
Andy
you
and
I
will
certainly
need
to
collaborate
and
work
on
this
one
in
the
coming
weeks.
I'm
right
now
kind
of
thinking
that
this
will
be
a
config
file
of
sorts,
but
there's
certainly
some
conversations.
We
could
probably
have
about
what
works
best
here.
Definitely.
D
I
have
a
question
for
you
in
talking
with
customers
and
prospects
around
defend
and
and
that
the
direction
that
we
want
to
go.
One
of
the
things
that
they're
really
interested
in
is
the
ability
to
take
the
insight
that
we
learn
in
dev
and
apply
it
to
protection
in
Prague
and
so
I'm
curious
about
you
know
in
terms
of
that
story.
How
much
of
that
will
we
be
able
to
claim
with
this.
A
This
one
I,
don't
think
relates
directly
to
that
story
so
much
this
is
going
to
be
primarily
about
things
that
are
happening
in
production
only
in
identifying
them
in
production
and
defending
against
them.
At
that
moment,
I
think
the
the
use
case
you're
talking
about
Cindy
is
when
we
get
several
iterations
down
the
road
and
we're
allowing
custom
rule
sets.
That's
when
we'll
start
to
be
able
to
say
development
identified.
This
update
the
rule
set
in
production
to
do
that.
Okay,
that's
not
really
what
this
one
is
focused
on:
okay,.
B
I
think
there's
another
cat,
I
think
there's
another
feature
was
in
a
defense:
space
that'll
speak
more
directly
towards
that.
When
we
get
into
vulnerability
management,
because
then
we
can
leverage
the
knowledge
that
we
have
of
what
has
been
deployed
to
be
able
to
then
answer
the
question
of
where,
within
your
production
ecosystem,
are
you
vulnerable
against
specific
threats,
so
I
think
there's
another
feature
of
this
target
at
that
use
case
as
well.
The
Sam,
please
correct
me
if
you
think
I'm
wrong
there.
B
A
Know
that's
a
good
add-on,
and
so
with
that
those
are
the
the
four
key
capabilities
that
we're
going
to
be
focusing
on
as
part
of
12
for
the
the
blocking
mode
for
the
laughs
and
the
three
that
we
just
reviewed
on
the
secure
board
as
well.
So
these
are
the
high-level
directional
items
that
we're
focusing
on
and
the
deliverable
items,
which
means
that
we're
confident
we're
going
to
be
able
to
deliver
them
and
they
are
the
key
things
for
the
release.
A
There
will
be
other
things
that
get
delivered
as
part
of
the
release
feel
free
to
go
to
this
board.
Remove
these
filters
and
look
at
some
of
the
other
things
that
were
prioritizing
and
working
on
during
this
iteration
and
as
we
get
closer
to
the
actual
release
date
on
the
22nd
you'll
start
to
see
those
issues
getting
closed
as
completed
and
then
move
to
the
release
post.
If
they're
complete
with
that
I
think
we
can
wrap
up
today's
meeting
appreciate
the
time
everyone
in
the
discussion
talk
soon.