►
From YouTube: Secure::Static Analysis office hours for 2020.12.17
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).
B
All
right,
happy
thursday,
so
hope
everybody's
having
a
good
week
and
that
everything
is
wrapping
up
nicely
in
advance
of
family
and
friends
day.
That's
tomorrow.
So
this
is
the
third
iteration
of
office
hours
for
static
analysis
and
we're
going
to
continue
to
follow
the
same
kind
of
script
that
we've
been
using
for
the
past
couple,
where
we're
starting
off
with
demos
and
daniel's
got
one
that
we
helped
him
last
week.
So
we
want
to
show
multi-project
support
and
spot
bugs
for
java.
A
Awesome,
thank
you
I'll,
go
ahead
and
share
my
screen
here,
and
then
we
can
dig
into
it.
So
let
me
get
these
controls
out
of
the
way,
so
I
can
see
what
I'm
doing
so.
First
off
I
wanted
to
show
off
that
there
we
now
have
a
test
project
for
mono
repo
support
for
spot
plugs,
it's
located
in
our
group
tests,
which
is
where
we
store
our
downstream
qa
dependencies,
and
so
when
spotbugs
gets
ran
as
a
test
as
a
part
of
its
pipeline.
A
It
executes
tests
on
this
now
so
this
is
this
support
should
be
locked
and
loaded
for
the
future,
and
so
what
I
had
done
was
I
actually
took
all
of
our
different
qa,
downstream
projects
that
have
vulnerabilities
and
we
assert
that
they
are
found
for
spot
bugs,
which
supports
multiple
languages
and
put
it
all
into
one
without
any
connective
glue
with
regards
to
the
jbm
or
java
or
maiden
or
any
of
those
saying
hey.
A
All
these
projects
are
here:
it's
just
these
projects
in
in
reality,
they
could
be
seen
as
disparate
jvm
language
projects
here,
and
so
I
created
this
and
then
here
I'll
show
off
the
gitlab
ci
real
quick
when
we
create
a
downstream
qa
dependency,
there's
a
little
bit
of
extra
glue
here,
but
it's
it's
your
basic
sas
gitlab
ci,
which
kicks
off
the
sas
jobs.
But
then
we've
got
a
couple.
A
Other
configuration
values
for
us
testing
this
as
a
downstream
test
project
for
spot
bugs,
and
so
that's
what
some
of
this
is
regarding
and
one
thing
to
note,
all
of
the
we
have
a
default
value
for
sas,
excluded
pass
and
test
is
included
in
that
and
with
that
being
included
and
these
being
test
projects,
we
have
another
issue
to
remove
that
out
of
the
class
path.
A
But
right
now
some
of
these
vulnerabilities
wouldn't
be
found
because
they
would
fall
under
that
test
exclusion
so
to
speak,
and
so
I'm
setting
that
to
to
empty
right
now,
and
so
that's
why
this
is
working.
And
then
this
is
the
sas
job
to
assert
that
our
expected
list
of
vulnerabilities
matches.
A
What
actually
is
shown
up
and
then
now
I'm
gonna
go
ahead
and
go
over
jump
over
to
a
pipeline
that
ran,
and
we
can
see
here,
here's
the
actual
sas
job
and
then
here's
that
qa
sas
job,
asserting
that
our
two
expected
and
results
match
and
when
I
click
into
the
actual
sas
job,
we
can
see
let's
scroll
up,
because
it's
kind
of
long
we
can
see
that
it
actually
found
a
maven
project,
a
gradle
project,
maven
project
in
the
the
multi
there's
a
multi-modules
test,
repo
or
test
folder
in
there
there's
scala
and
it
found
all
these
projects.
A
And
then
you
can
see
it
goes
ahead
and
does
its
thing
I
have
debug
turned
on.
So
all
of
these
blue
lines
would
not
show
up
in
just
a
generic
import
of
the
sas
or
inclusion
of
that
sas
template.
So
just
to
know
this
would
be
a
little
bit
shorter
for
most
customers
using
this,
and
then
we
could
see
that
the
job
succeeded.
A
I
think
I
saw
there
was
a
fancy
way
to
pull
up
the
the
security
vulnerabilities
it
found.
I
remember
seeing
thomas
do
that.
The
other
day.
A
I'll
go
back
to
the
pipelines;
okay,
that's
what
it
was.
So
if
I
go
back
here
now,
we
can
see
security
here
and
we'll
see
that
it
found
a
number
of
issues
and,
most
importantly,
though,
we'll
see
that
it
found
in
a
scala
directory
the
gradle
directory
groovy,
maven,
gradle,
groovy,
maven
and
then
eventually,
maven
multi-modules
should
be
yep.
Here
we
go
so
it
found
issues
in
each
and
every
one
of
those
directories
that
are
just
subdirectories
inside
of
this
repo
and
are
multiple
projects
that
should
each
be
scanned.
A
I
think
I
think
that
concludes
my
demo.
Are
there
any
questions.
B
I'm
going
to
add
in
a
couple
of
notes
on
this,
so
what
you,
what
you
saw,
who
demonstrated
in
here,
also
included
the
ciemo
file.
It's
not
that
everything
needs
to
include
all
of
this.
C
B
A
No,
that's
absolutely
right
and
that's
good
to
highlight
really
technically
all
that
would
be
needed.
Is
this
these
these
two
lines
in
a
con?
The
comments
not
needed,
but
basically
you
just
need
to
include
our
sas
vendor
template
and
it
should
work.
The
rest
of
these
configurations
have
to
do
with
the
fact
that
we're
using
this
as
a
downstream
test
project.
B
A
D
A
question
over
here
this
is
awesome
daniel.
I
actually
had
a
conversation
with
a
customer
yesterday
with
monorepo
scanning
and
their
maven
projects.
They
were
running
into
a
scan
situation
where
it
was
taking
around
an
hour
because
they
had
maybe
30
services
in
the
repository.
D
So
the
suggestions
I
gave
to
him
were
looking
at
the
pre-compile
options
for
maven
with
spot
bugs.
The
other
suggestion
I
gave
to
him
was
looking
at
changes
specifically
on
the
directory
and
only
running
on
scans.
When
changes
occur.
What
was
the
other
suggestion?
I
think
cg
ci
project
directory
was
another
one.
If
that
was
another
variable,
they
wanted
to
take
advantage
of
and
leverage
would
you
do
you
have
any
other
suggestions
or
best
practices
on
speeding
up
those
build
times
when
you're,
when
you're
dealing
with
the
mono
repo
in
spot,
bugs.
A
Yeah,
I
have
a
couple
thoughts,
then
I'll
also
see
if
lucas
or
thomas
have
anything
to
add
one.
I
think
you're
absolutely
right
with
the
pre-build.
A
The
pre-compile
flag
is
key,
because
I
would
expect
as
a
part
of
any
pipeline,
you
would
want
to
do
a
build
and
so
might
as
well
reuse
that
step
in
terms
of
time
savings,
but
in
terms
of
also
simplicity,
like
it
eases
a
lot
of
problems
that
can
be
caused
with
the
fact
that
we
are
trying
to
provide
an
environment
that
has
all
the
java-
and
you
know,
jvm
languages
installed
and
configured
in
such
the
way
that
your
project
would
compile,
and
I
think,
with
the
jvm
languages.
A
Particular
there
is
quite
a
variance
in
terms
of
project,
setup
and
environment
needed
to
build
so
that
pre-compilation
solves
that,
so
that
also
kind
of
gets
two
birds
with
one
stone
so
to
speak.
Yeah.
I
think
the
other
options
too,
I
wouldn't
have
necessarily
thought
of,
but
are
are
great
suggestions
as
well
lucas,
thomas
anything
else.
A
C
No,
I
I
think
that
covered
it
pretty
well,
unfortunately,
I
don't
have
a
a
silver
bullet
for
that.
B
Thank
you,
there's
yeah
pre-compilation,
that's
that's!
That's
it!
There
are
two
sassed
analyzers
that
we
have
where
building
the
project
is
a
concern.
Spot
bugs
is
one
security
code
scan
is
the
other
spot.
Bugs
is
the
one
that
gives
us
this
pre-compilation
escape
hatch
where
we
can
reuse
the
build
security
code
scan
operates
as
an
as
a
dependency
that
is
injected
into
a
build,
so
we
can't
kind
of
get
rid
of
around
that
at
least
that's
the
way
that
I
would
characterize
it.
B
So
as
long
as
we're
in
this
particular
analyzer
itself,
where
we
do
have
where
this
is
needed,
pre-compilation's
way
to
do
it
because
spot
bugs
itself
doesn't
look
at
the
source
code.
It
looks
it's
the
generated
java
byte
code,
and
so
that's
that's
why
this
is
a
necessary
step
and
because
we're
doing
our
best
to
make
this
turnkey
we're
not
going
to
be
able
to
adequately
support
optimizations
in
the
build
steps
that
the
customers
may
need
or
may
desire.
So
so
yeah,
that's.
That
was
a
spot
on
recommendation.
D
A
You
great
questions
anything
else.
B
D
Yeah,
so
let
me
share
my
screen
here.
D
Yeah
so
a
little
background
on
this
question,
so
we're
certainly
have
customers
ask
about
just
general
kotlin
support
right
now.
We
know
we
have
mob.
Is
it.
D
So
we
have
modbus
for
android,
but
there's
been
questions
around.
How
can
we
do
general
scanning
on
our
kotlin
classes
or
files
or
objects
pojos,
whatever
you
want
to
call
them
and
and
from
my
understanding
with
mobe
sf
is
that
it
might
be
restricted
to
just
android
files.
So
with
an
android
class,
you
have
android
framework
and
it's
a
scan
specific
android
entities
relating
to
sas,
where
spot
bugs
will
actually
go
to
generic
classes
and
do
generic
scanning.
D
So
for
this
customer
specifically
there
and
what
we're
hearing
from
a
lot
of
customers
is
they're
migrating
from
job
over
to
kotlin
for
the
back
end
applications.
So
I
looked
into
fine
tech
bugs
I
think
another
person
suggested
it.
So
I
did
some
digging
and
scanned
locally
with
this
and
actually
had
some
results
that
were
positive.
Take
it
with
a
grain
of
salt,
as
I'm
a
noob
to
some
of
the
these
scanners
here.
So
certainly
would
love
some
feedback
on
this.
D
The
the
approach
I
took
here
was
baking
in
the
spot,
bugs
into
the
project
and
specifically
into
gradle
and
then
also
including
the
findset,
bugs
into
that
now
to
pick
up
those
kotlin
files,
I
had
to
include
within
the
spot,
bugs
tasks
to
actually
look
for
the
the
compiled
files
there,
which
was
able
to
give
me
out
a
report.
D
So
looking
into
this,
I
got
the
results,
so
it
looks
like
so
spot
bugs
or
I'm
sorry,
findset
bugs
picks
up
both
kotlin
and
also
android,
so
they
have
rules
for
both.
So
I
had
two
classes
to
find
these
were
just
generic
kotlin
classes
that
were
able
to
pick
that
up
where
these
are
all
android
related
vulnerabilities
that
were
picked
up
as
well.
So
this
was
the
the
report
output
which
is
available
on
this.
D
So
I'm
just
curious
questions
around
this.
It
seems
like
we
have
the
the
analyzer
there
I'm
curious
to
see.
If
maybe
I
haven't
tested
with
our
existing
analyzer,
it
might
be
available
already,
maybe
with
just
some
some
fine
tuning
I'd,
be
curious
to
hear
your
feedback
on
this
and
maybe
like
a
path
forward
on
and
maybe
supporting
this
it
looks
like
luke
has
already
commented,
so
I'll
stop
jabbering
here.
C
Should
have
sent
that
earlier,
I
realized
I
had
this
big
typed
thing
that
I
now
sent
three
minutes
ago,
but
just
to
vocalize
what
I
wrote.
C
So
we
on
on
an
unrelated
issue,
which
I
linked
there.
There
is
and
that's
a
security
issue,
so
we
we
started
looking
into
the
find
stackbugs
version,
spotbooks
version.
I
can't
actually
quite
figure
out
how
this
works,
because
to
find
sex
bugs
releases,
the
cli
tool
and
the
cli
tools,
what
we
use
within
our
analyzer
directly
within
the
release.
Notes
for
that
the
most
recent
version
of
find
second
bugs.
C
It
says
that
support
for
spot
bugs
four,
but
as
far
as
I
can
tell
it's
using
a
pretty
old
version
of
spot
bugs
anyway,
so
I
think
that
within
it,
fine
stack
bugs
can
work
with
spot
bugs
in
the
way
that
you
are
using
it
here
as
a
like
a
plug-in,
but
the
way
that
we
are
actually
using
find
stack
bugs
as
the
ci
tool.
I
think
it's
it's.
C
It's
currently
pinned
to
a
fairly
old
version
of
spot
bugs
within
our
analyzer,
because
of
that
I'm
not
sure
if
it
would
work
out
of
the
box.
It's
definitely
worth
trying
just
let's
run
and
see
what
happens.
C
But
beyond
that,
I
I
think
that
I
think
that
we
might
have
to
update
that
just
to
see
if
the
newer
support
works.
I've
seen
mention
of
kotlin
there,
but
I
don't
really,
as
as
you
pointed
out,
I
don't
really
know
when
they
said
that
they
started
supporting
this.
If
that's
a
new.
D
D
C
Yeah,
so
I
in
my
work
we
should
definitely
run
in
and
just
see
what
happens.
I
think
that
the
biggest
culprit
for
that
would
be
our
older
version
of
spot
bugs.
I
don't
quite
know
what
that
will
do
since
find
sec
bugs
we
pretty
much
only
need
spot
bugs
there
for
well
the
the
basic
framework
and
then
there's
like
a,
I
think,
there's
like
four
spot
bugs
rules
in
addition
to
the
fine
sex
bugs
ones,
which
is
the
majority
of
the
security
rules
there
yeah
I'm,
I'm
not
sure.
C
E
I
appreciate
the
the
exploration
here
because
there's
a
lot
to
unpack
so
when
you
think
about
android
projects,
or
actually,
let's
just
say
java
in
general,
we've
got
two
analyzers
that
can
potentially
scan
java
in
kotlin.
We've
got
spa
bugs
and
we've
got
mob
sf.
E
E
So
that's
something
we're
going
to
have
to
think
about
long
term,
but
I
do
think
there
it's
probably
worth
trying
to
modify
our
sassed
ci
template
to
just
add
kotlin
to
our
detection
rules
for
spot
bugs
and
just
see
what
happens.
I'm
not
sure
if
we've
actually
tried
that
or
not
I
do
know
a
customer
has
played
around
with
that.
I
linked
that
in
the
document
or
in
the
the
notes
for
this
meeting
feel
free
to
look
at
their
sample
ci.
E
I
think
this
is
one
where,
like
you
said,
we've
just
got
to
try
a
few
things:
let's
try
getting
our
existing
spot,
bugs
analyzer
running
and
detecting
kotlin.
I
do
think
mob.
Sf
has
the
potential
to
do
more
general
scanning.
Today
we
focused
it
on
only
detecting
ios
and
android
projects
to
avoid
the
duplicate
problem
so
yeah,
I
encourage
anyone
who's
interested
to
definitely
look
into
this
and
report
back
to
us
if
it's
as
easy
as
updating
our
sas
ci
template.
That
certainly
is
something
that
we
could
quickly
push
through.
E
I
will
mention
that
mobile
scanning
mast
is
a
key
capability
for
gartner
in
the
magic
quadrant
for
2021.
So
any
additional
development
we
have
here
is
certainly
going
to
be
beneficial.
D
Yeah
thanks
taylor,
and
I
was
I
was
thinking
that
too,
is
if
you
do
have
an
android
project
and
both
of
our
analyzers
pick
up
that
that
language.
What
what
do
you
go
with
and
how
do
you
handle
the
duplicates
and
I
think
that's
a
good
point
to
raise.
E
Yeah
and
I
think
you're
also
detecting
an
interesting
shift
too,
that
we
are
starting
to
see
companies
move
to
kotlin
outside
of
mobile.
I
think
we'll
continue
to
see
that
I
think
the
same
thing
is
happening
with
ios
with
swift,
so
it's
definitely
something
for
us
to
watch
and
I
definitely
think
it's
it's
worth
any
effort
if
anyone's
digging
into.
E
B
B
Silence
means
no
okay.
Well,
thank
you
very
much
for
everybody
for
your
time
and
attention.
We
appreciate
it.
We
appreciate
your
questions
and
we
hope
that
this
is
a
useful
forum.
What
is
going
to
happen
now
is
this
is
going
to
be
our
last
office
hours
for
2020.,
I'm
going
to
go
ahead
and
cancel
the
next
two.
I
will
resume
this
back
in
january.