►
From YouTube: Secure::Static Analysis office hours for 2021.01.28
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Happy
thursday,
if
you
intended
to
be
here
for
static
analysis,
office
hours,
then
you've
landed
in
the
right
zoom
room.
So
it's
january
28th
we've
got
a
demo
on
the
agenda
and
ross.
That's
here,
so
take
it
away
when
you're
ready.
Sir.
B
There
we
go
okay,
I've
got
the
the
issue
up
here,
so
we're
we're
migrating
from
the
fast
default
analyzer
ci
variable
to
sas
excluded
analyzers.
It
is
in
progress,
so
using
sas
default.
Analyzers
is
still
supported,
but
we
do
do
handle
both
I'll
just
get
into
the
the
demo
here.
So
this
is
my
test
project
that
I
have.
This
is
the
current
state
of
the
getlab
ciemo
on
the
master
branch.
B
You
can
take
my
word
for
it
that
the
only
analyzer
missing
from
here
from
all
of
our
defaults
is
yes
lent.
So
I'm
gonna
hop
over
to
the
latest
pipeline
that
I
ran
before
this
meeting
and
yes
lent
was,
was
not
ran
again.
You'll
just
have
to
take
my
word
for
it
that
it
should
be
running,
so
I'm
going
to
go
ahead
and
go
to
the
sas
config
ui
to
to
demonstrate
the
new
variable.
B
Oh
you,
people
are
in
the
way.
That's
the
problem.
I
I
couldn't
see
the
configure
button
because
anyhow
all
right,
so
I'm
just
expanding
this
to
show
that
eslint.
You
know
it
recognized
that
yes
line
shouldn't
be
running,
I'm
also
going
to
uncheck
bandit
just
because
it
does
have
python
in
it.
B
So
that
will
exclude
python
from
running
we'll
look
at
the
the
diff
here
and
sorry.
If
there
are
any
questions,
just
please
interrupt
me,
but
but
you
can
see
that
it
got
rid
of
the
sas
default
analyzers
variable
and
switched
over
to
the
sas
excluded.
Analyzers
variable
that's
built
into
the
sas
config
ui
now
so
band
and
eslint
are
excluded
and
here's
the
pipeline
that's
running
for
that.
B
And
you
can
see
that
brakeman
and
node.js
are
still
running,
but
yes
lent
and
banned
it
or
not
so
another.
One
other
thing
that
I
wanted
to
point
out
with
this:
I'm
gonna
go
ahead
and
submit
the
merge
request
just
to
make
this
a
little
easier.
B
B
B
Just
get
rid
of
all
so
we're
you
know
we're
telling
it
to
run
these
bandit
and
break.
Man
are
important
for
this.
I
guess
and
then
we're
also
saying
don't
run
bandit
and
eslant
so
bandit.
Should
this
one
should
win
the
sas
excluded
analyzers
in
the
case
that
people
are,
you
know,
kind
of
maybe
setting
both
of
them
for
a
while,
while
we're
still
supporting
the
other
one.
B
B
I
think
that's
about
all
I
have
to
show.
I
saw
taylor
wrote
some
stuff
down.
Do
you
want
to
verbalize
any
of
that
taylor?
Sure
yeah.
C
What
we
do
today
with
default
analyzers,
is
you
explicitly
say
which
ones
you
want
to
run,
and
the
reason
this
is
particularly
important
is
that
if
you
define
today
your
default
analyzers
and
we
come
out
with
a
new
amazing
analyzer
that
does
something
that
everybody
should
have
on
by
default.
You
won't
get
that,
so
we
have
customers
that
are
using
default
analyzers
today
to
turn
off
analyzers
because
they
make
too
much
noise,
but
they
won't
automatically
get
new
analyzers
in
the
future,
which
could
find
new
vulnerabilities
for
them.
A
A
All
right,
thanks
ross
hearing,
no
more
questions.
I
will
go
ahead
and
throw
it
to
greg
who's
actively.
Writing
something.
So
I'm
going
to
make
him
do
a
multitask,
so
greg
you've
actually
got
next
on
the
agenda.
D
All
right,
so
this
is
kind
of
a
pick,
your
brain
just
general
question.
D
So
in
executive
evp
engineering
office
hours
today,
we
discussed
a
little
bit
how
we're
prioritizing
supply
chain
security
and
it's
a
topic-
that's
become
really
prevalent
in
the
news,
especially
with
the
solar
winds,
breach
from
what
I
understand.
D
Solar
winds,
like
the
the
problem,
was
introduced
in
the
build
stage
which,
like
there,
was
code
being
injected
to
this
software,
which
would
then
be
shipped
out
to
all
of
the
clients,
and
I'm
thinking
that
seems
to
have
like
some
overlap
with
static
analysis
and
like
what.
What
could
we
do
to
ensure
that
there's
not
back
doors
or
trojans
or
viruses
or
problems
being
introduced
in
merge,
requests,
bringing
awareness
and
alerting
on
that,
and
I
was
wondering
what
what
I
guess.
Okay,
the
other
thing
that's
been
coming
up.
D
A
lot
is
crypto
malware
that
we'll
save
that
separate
topic
stick
with
supply
chain
security,
any
any
ideas
on
what
we
might
consider
or
future
advancements
enhancements
that
we
could
use
to
make
sure
both
our
own
software
and
software
produced
with
git
lab
is
secure.
C
C
I
suspect
that's
going
to
be
something
that
we'll
see
prioritized
further.
I'm
sure
thomas
has
more
details
on
this
as
well
and
then
in
terms
of
looking
for,
like
abuse
with
crypto
miners,
that's
definitely
within
the
scope
of
a
new
stage
that
we're
creating,
which
is
get
lab,
learn
which
is
focused
on
machine
learning.
C
We
have
a
category
within
that
that
is
focused
on
insider
threat
and
we'll
be
basically
detecting
abuse
with
some
basic
sort
of
machine
learning
and
data
science,
algorithms,
that's
something
that
we'll
likely
take
on
soon
with
that
I'll
put
some
links
in
here.
So
you
can
follow
that
trail
of
thoughts.
A
I
was
not
at
you
at
evp's
office
hours,
so
it's
I'm
trying
to
respond
in
real
time
as
well,
so
related
issues
that
taylor
was
just
referencing.
Those
are
in
the
agenda,
so
at
least
those
are
the
there's
two
that
I'm
aware
of,
and
so
those
are.
Those
are
that's
what
I
think
is
being
referenced.
A
The
the
interesting
thing
about
the
question
in
the
line
of
inquiry
is
that
it
was
a
product
prioritization
inquiry,
but
at
the
same
time,
if
we're
honest
about
it,
we
are
also
part
of
the
supply
chain
by
the
very
products
that
we
are
building,
so
it's
more
than
product.
It's
also
from
my
point
of
view.
It's
also
securing
the
platform
that
that
we
are
indeed
delivering
to
customers.
A
So
I
think
this
is
a
holistic
feature,
I
think,
or
a
holistic
point
of
view.
I
think
this
is
something
to
be
that
best
practices
in
secure
coding
should
be
top
of
mind
for
all
of
us
as
we're
delivering
products
themselves
and
at
the
same
time,
we
should
make
sure
that
what
we're
doing
what
we're
building
is,
as
actual
provides,
provides
insights
that
are
as
actionable
as
possible.
A
So
I'm
not
trying
to
avoid
your
question,
but
those
are
the
immediate
reactions
that
I
have
to
to
which
brought
forward.
So
hopefully
that
was
useful.
D
C
We
do
not.
It
is
something
that
is
intended
at
this
point.
Given
our
staffing
restrictions,
we
have
removed
it
from
the
plan.
It's
something
that
I
think
will
likely
see.
Parts
of
the
insider
threat
group
that
I
or
category
that
I
mentioned
that's
linked
there
below
may
try
to
take
on
pieces
of
it.
But
at
the
moment
like
we
just
don't
have
the
staffing
for
more
categories.
F
It's
not
related
to
sas,
but
I
know
we
since
the
solarwinds
stuff
and
since
a
red
team
operation
that
showed
just
how
easy
it
is
to
sneak
into
malicious
dependency
in
gitlab,
there
were
some
custom
dependency,
verification
scripts,
introducing
the
ci,
and
I
believe
it's
part
of
the
security
research
team,
fy22
objective
to
kind
of
loop
in
more
with
secure
and
get
more
of
that
custom
stuff
into
actual
product,
not
necessarily
sas.
G
Yeah
yeah,
I
think
dennis,
is
the
one
driving
that
the
one
that
had
opened
the
original
issue
so.
D
D
Particular
to
security
products
at
all,
but
do
we
have
any
guidance
on
enforcing
gpg
signing
for,
merges
or
commits.
E
I
believe
in
the
development
docs
we
have
a
recommendation
to,
but
it
doesn't
really
work
for
most
of
our
workflows,
because
so
much
of
our
so
much
of
the
platform
involves
auto
committing
on
our
behalf,
so
things
like
squashing
commits
and
other
and
using
the
web
id
and
a
lot
of
other
functions,
just
don't
really
support
a
signed
commit
workflow.
So
I
think
that's
what's
prevented
us
from
forcing
us
more
globally.
A
A
Hearing
nothing
thanks,
everybody
for
your
time
and
attention.
We
very
much
appreciate
you
being
here
and
and
your
questions
so
we'll
be
back
here
next
week
same
bat
time
same
bat
channel
and
we'll
see
what
that
conversation
brings
us
so
have
a
good
rest.
Your
week
see.