►
Description
Jeff Thompson outlines the use of find-sec-bugs in Jenkins core and Jenkins plugin development. The find-sec-bugs plugin for spotbugs can help developers detect issues related to security while they are developing.
A
Welcome
everyone
I'm
mark
weight
where
I'm
here
with
Jeff
Thompson
he's
going
to
present
the
fine
sec
bugs
and
how
we
can
use
it
to
identify
and
help
us
prevent
security
issues
in
jenkins,
core
and
in
jenkins,
plug-in
development.
This
meeting
is
being
recorded.
It
will
be
posted
to
the
YouTube
Jenkins
channel
in
the
online
meetups
playlist
Jeff
go
ahead.
Okay,.
B
Thank
you.
So
yes,
I'm
Jeff,
Thompson
I've,
been
using
Jenkins
for
many
years
currently
worked
for
cloudBees,
as
you
can
see
here,
I've
been
contributing
to
as
as
part
of
this
Jenkins
core
jinkin
security
for
a
few
years
now
and
I'm
also
the
remoting
maintainer
make
sure
they're
remoting
and
the
agent
stuff
all
works.
So
that's
some
of
my
background.
What
I'm
gonna
be
talking
about
here
today
is
another
project
I'm
working
on
in
Jenkins
community
in
general
to
try
and
improve
our
quality
and
our
security
stuff
about
addy
Jeff.
A
B
A
A
Question
and
answer
during
this
session,
if
you'd
like
to
type
them
you're,
also
welcome
to
unmute
yourself
and
ask
questions
verbally.
We
don't
mind
if
you,
if
you
interrupt
this,
is
we
expect
it
to
be
a
rather
smaller
group
and
we
want
to
be
it
to
be
conversational.
Go
ahead,
Jeff,
sorry
for
the
interruption,
yep!
That's.
B
Fine
so
been
working
on
this
project
to
add
the
fine
SEC
bugs
tool
into
our
existing
spot,
bugs
tool
and
spread
this
throughout
the
community
to
catch
problems
or
potential
problems
earlier
and
help
improve
code
quality.
So
we
chose
this
platform
cig
just
because
it
seemed
like
a
good
place
to
dump
this
conversation.
B
So
a
little
bit
of
background
here
spot
bugs
many
people
are
probably
familiar
with
it,
but
if
you're
relatively
new
to
Jenkins
or
Java
or
other
things,
you
might
not
be
it's
a
static
code
analysis
tool
for
Java
that
you
can
hook
into
the
build
process.
It
runs
it
analyzes
class
files
and
has
pattern
matching
rules
to
try
and
detect
certain
classes
of
problems
that
are
fairly
common
and
may
cause
issues
in
in
your
java
code.
B
Now,
in
a
way
it's
been
around
for
a
long
time
because
it
originally
started
as
fine
bugs,
which
is
almost
as
old
as
Jenkins
and
fine,
bugs
then
kind
of
collapsed
a
few
years
ago,
and
it
relaunched
a
spot
bugs
and
I
mentioned
that,
because
you
see
references
to
both
in
the
Jenkins
palms
and
all
sorts
of
stuff.
Current
usage
references
spot
bugs,
but
fine
bug
settings
in
Jenkins
apply
the
same
way
it
was.
B
It
was
hooked
in
to
move
forward
cleanly,
so
it's
standard
spot
bugs
is
standard
in
many
or
all,
Jenkins,
parent
palms,
so
I
plug
in
core
the
library.
As
many
other
places,
it's
been
used
there
for
a
long
time
and
builds
tail
now
if
you've
ever
submitted
something
and
contributed
something
built
fail
because
of
a
spot
bugs
there,
you
go
clean
it
up
and
get
it,
and
that
gives
us
a
little
better
gives
us
some
better
quality
and
some
cleaner
code
moving
forward
and
may
help
us
eliminate
some
actual
errors.
B
One
of
the
things
to
know
on
this
as
a
developer
is
that
it's
configurable
and
the
easiest
way
to
look
at
this
is
if
you're
working
in
a
project.
If
you
look
at
the
effective
pom
and
look
in
the
properties
or
looking
things
related
to
either
find
bugs
and
spot
bugs,
you
can
see
some
configurable
elements
of
this
there's
how
hard
a
tries,
how
the
threshold
for
whether
or
not
a
report,
it's
a
reporting
threshold.
B
So
it
says
you
know,
I'm
only
going
to
tell
you
about
things
that
I'm
fairly
confident
in
or
I'm,
going
to
tell
you
about
everything,
whether
or
not
I'm,
confident
in
it.
Well,
there's
some
other
configurations
on
that
that
you
can
see
so
find
security
bugs
or
find
sec
bugs
is
a
plugin
for
spot
bugs,
so
it's
actually
integrated
into
spot
bugs
and
what
it
does
is
I
adds
another
135
rules
or
vulnerability
types,
and
these
are
all
target
around
security
issues,
unlike
the
spot
bugs
rule
set,
which
is
just
more
general.
B
Some
of
those
could
be
security,
but
this
is
a
set
of
ones
that
are
specifically
about
things
that
come
up
as
security
concerns.
One
of
the
things
to
be
aware
of
it
with
it
is
that
it's
it's
by
design.
The
rules
are,
are
written
to
be
about
Java
web
applications.
So
a
lot
of
its
rules
are
things
that
might
be
okay.
If
you
were
running
a
local
console
application
of
some
sort,
but
in
a
security
application
may
be
a
problem.
B
It
does
a
few
things
differently,
so
there's
some
oddities
and
some
places
where
we
need
to
kind
of
tune,
find
sec
bugs
maybe
but
like
with
the
remoting
side
and
the
agent
there's
some
things
where
it's
like
yeah,
that
doesn't
matter
because
it's
agent
and
the
administrator
is
launching
it
than
these
sort
of
things.
So
you
do
see
that
that
focus
on
Java
web
applications
in
it,
which
is
a
reasonably
good
fit.
It's
also
focused
on
a
lot
of
these
things
in
the
security
community.
B
A
wasp
is
one
of
the
big
repositories
of
information
about
it.
They
publish
a
top
10
list
of
what's
the
biggest
vulnerabilities
and
so
find
sec
bugs
tries
to
fit
into
that
includes
references
to
Olas
in
their
descriptions
and
to
the
CW
the
common
weakness
enumeration
in
in
the
descriptions
and
the
explanations.
So,
there's
really
a
lot
of
a
lot
of
stuff
to
help
you
figure
out
what
the
issues
are,
although
some
of
them
are
still
quite
complicated
to
understand
and
there's
the
URL
for
fine
sec
bugs
project.
It's
also
on
its
it's
on
github.
B
B
So
what
I
want
to
get
to
here
coming
up,
not
not
immediately,
and
it's
kind
of
piece
by
piece
is
to
add
the
fine
sec
bugs
configuration
into
the
parent,
poms
and
Jenkins
and
I
had
some
stages
coming
along
for
that
which
I'll
show
you
later
in
preparation
for
this.
But
I
want
to
put
the
configuration
into
the
parent
pom
for
plugins
into
the
parent
pom
for
Jenkins
into
the
stapler
module
parent
pom.
Any
other
places
that
we
find
it
like
that.
B
B
When
I
first
posted
about
this
on
wanting
to
move
forward
on
this
idea
in
the
Jenkins
developer
email
list,
we
got
some
some
good
good,
healthy
discussion
and
some
concerns
were
raised
and
I've
distilled
some
of
those
concerns
along
with
some
other
concerns.
Other
people
have
had
and
other
things
under
this
page
I'm
calling
them
analysis,
conundrums,
they're,
kind
of
paradoxes
or
conflicts,
they're,
they're
things
where
there's
a
reason
to
do
X
and
there's
also
a
reason
to
do
Y
and
so
I'm
gonna
go
through
and
talk
about
some
of
them
and
why?
B
What
we
need
to
do
with
them?
So
one
that
comes
up
a
lot
is
what
is
the
best
time
to
add
new
analysis
capabilities
like
fine
set
books
when
the
answer
is
always
that
a
long
time
ago
is
the
best
time
to
do
it
from
project
start
is
always
the
best
time,
but
at
any
point
where
it's
now
the
longer
it
goes
that
it
was
was
always
better
and
doing
it
now
is
always
more
difficult,
because
then
you
have
legacy
code.
B
You're
gonna
have
findings
that
you
can't
change
or
that
are
difficult
to
change
and
maybe
then
may
not
be
an
issue,
but
you
could
have
fixed
them
very
easily
long
ago
and
now
introducing
it
at
this
point,
it's
more
things
that
you
have
to
suppress
and
deal
with.
That's
that's!
Not
that's
not
an
issue
with
fine
SEC
books.
Specifically,
that's
that's
an
issue
with
these
sort
of
tools,
these
sort
of
analysis,
these
sort
of
detections,
so
the
other
alternative.
When
you
get
to
this
point,
which
was
kind
of
the
conundrum
of
it,
is
you
say?
B
Oh
it's
too
difficult
to
add.
Now
we
won't
do
it
so
we'll
just
delay
but
of
course,
a
year
from
now
the
best
time
to
have
added
them.
Well,
a
much
better
time
to
have
added
them
would
have
been
right
now
than
a
year
from
now.
So
it's
it's!
You
always
kind
of
pay,
this
price,
unless
you
did
it
right
from
the
beginning,
but
the
more
that
you
wait,
the
worse
it
is
so
proceeding
forth
and
doing
it.
It's
still
better
than
saying
well
yeah.
It's
too
much
work.
We
can't
do
it
now.
B
The
next
one
that
I
want
to
talk
about
that
always
comes
up
with
these
sort
of
things
is
issue
detection,
and
this
largely
comes
into
into
two
categories
that
I've
listed
here.
Tools
like
this
don't
find
everything
and,
as
a
matter
of
fact,
in
Jenkins,
we
have
some
specific
types
of
problems
that
crop
up
a
lot
that
this
tool
doesn't
find,
and
so
it's
like.
B
It's
always
difficult
with
legacy
outdated
code
to
introduce
these
sort
of
things,
and
you
always
get
to
this
kind
of
well,
it's
not
finding
anything
on
my
legacy,
outdated
code
that
I
can
do
about.
So,
what's
what's
the
value
of
it,
but
in
reality
most
of
the
value
from
these
sort
of
things
isn't
necessarily
in
finding
things.
That's
already
there,
like
with
spot
bugs
when
I've
added
spot
bugs
or
find
bugs
predecessor
before
to
projects
I've
done
it
several
times.
B
It
rarely
finds
things
that
are
valuing
tidge
of
actual
interesting
hits
is,
is
low,
but
what
it
does
is.
It
starts
planing
out
areas
where
you
can
improve
the
code,
so
you
don't
introduce
regressions
and
then,
as
you're
introducing
a
new
thing,
and
it
says:
okay,
md5
is
a
really
outdated,
algorithm,
don't
use
it,
you
go
I,
don't
have
to
use
md5
right
now.
I
can
use
something
better
and
you
don't
add
even
more
of
that
that
no
technical
debt
into
it.
So
that's
kind
of
that
issue
of
existing
code.
B
So
if
we
run
fine
SEC
bugs
it's
possible
that
by
running
that
on
Jenkins,
we
will
find
real
issues
and
by
doing
that,
people
will
become
more
aware
to
attacker
could
learn
something
about
how
to
attack
Jenkins
from
running
fine,
sick
bugs
and
so
that's
a
concern
with
especially
the
security
beside
of
it.
But
there's
also
this
other
side
of
it
in
that
being
open
source.
A
Well,
on
that
one,
even
since
fine
sec
bugs
is
doing
bytecode
level
analysis
right,
it's
not
even
so
much
that
we're
open
source
is
the
fact
that
our
bike
code
is
available
because
I
assume
fine
set
bugs,
could
analyze
byte
code
from
any
that's
fed
to
any
Java
Virtual
Machine.
Therefore,
we
have
not
increased
the
threat
profile
simply
by
by
admitting
that
fine
SEC
bugs
could
be
run
on
our
bike
code.
Of
course
it
can
I
would.
B
Imagine
that
would
be
true.
I've
never
tried
it,
except
as
in
it
was
in
a
pom
file
as
part
of
a
build
step
and
since
all
of
our
source
code
and
all
of
our
pom
files
and
everything
are
there,
it's
not
hard
to
stick
in
the
half
dozen
or
something
lines
run.
You
know,
Jenkins
build
and
see
yeah.
This
is
an
interesting
area,
so
yeah
it's
it's
not
really
a
terribly
meaningful
argument.
B
It
again
is
the
argument
that
we
need
to
learn
as
developers
more
about
this
and
make
it
more
part
of
our
stuff
and
then
in
work
through
it
and
add,
add
the
improvements
everywhere
that
we
can
and
if
we
find
any
real
security
issues
to
address
those
so
yeah.
Those
are
some
of
the
comments
that
have
come
up
in
pull
requests
and
discussions
and
such
and
other
times
that
I've
done
this
so
now
we're
on
to
the
part
of
it,
okay
of
where
I'm
a
developer.
What
do
I
need
to
do
about
this?
B
I'm,
a
Jenkins
developer,
I'm,
a
core
developer,
I'm,
a
plug,
Jenkins
plug-in
developer,
and
this
even
applies.
You
know
if
you
develop
in
other
spheres,
so
this
is
focused
towards
Jenkins.
So,
like
I
said,
my
plan
is
to
update
to
update
the
palme
version
of
each
of
these
areas
at
some
point
to
add
the
fine
SEC
bugs
as
a
plugin,
and
when
you
do
that,
then,
when
you
next
update
to
that
pom
in
your
plugin
in
the
Jenkins
library,
whatever
it
will
then
include
fine
SiC,
bugs
analysis
when
it
does
the
spot
bugs
analysis.
B
B
You
can
it's
a
little
hard,
sometimes
to
add
something
like
this
in
right
in
a
child
pom,
and
sometimes
you
get
like
two
instances
of
spot
bugs
that
runs
one
with
this
and
one
without
it's
a
lot
easier
to
just
add
it
where
the
thing
is
defined
in
the
top
parent
pom
and
to
get
that
to
line
up
correctly
now.
Is
it
a
problem?
If
you
don't
get
that
to
line
up
tripping,
not
really
I
mean
it
might
add
a
few
seconds
to
your
run.
B
B
One
item
that
we've
seen
that
you
you
should
know
about.
You
may
see
this.
This
message,
the
following
class
is
needed
for
analysis.
We're
missing!
You
can
see
an
instance
example
of
it
from
the
platform
label
or
plugin
in
the
the
other
text
below
as
to
what
it
looks
like
tests,
apply
and
accept
missing
classes.
3
just
ignore
this,
there's
a
spot
bugs
issue
on
it.
Where
there
it
doesn't
mean
that
things
are
not
running
fine,
SEC
bugs
isn't
running
the
spot.
Bugs
really
has
a
problem.
B
It's
the
spot,
bugs
engine
plug-in
something
that
is
logging
stuff
at
a
higher
level
than
it
should
be,
and
so
it's
it's
providing
information
that
you
can't
make
any
use
of
here
where
it's
kind
of
something
where
maybe
the
spot
bugs
developers
could
improve
things
at
some
point
on
their
area
most.
It
means
that
it
may
not
be
able
to
test
some
things
as
well
as
it
could,
but
I
mean
it's
doing
what
it
can.
B
So
this
is
what
you
really
need
to
do
is
to
include
it
in
the
palm,
get
it
via
the
upcoming
future
version
or
get
it
by
adding
it
in
yourself.
I
know,
mark
merged
it
into
the
platform
label
or
plug
in
directly
and
I've
done
that
and
the
other
places
where
I've
already
done
it
and
like
when
I
did
that
in
Jenkins
and
once
I
get
it
up
to
the
chain.
Comes
parent,
pom
I
intend
to
remove
it
back
out
of
the
chain,
cancel
on
itself
and
just
use
that
one.
B
So
this
is
what
you
may
need
to
do
as
a
developer,
maybe
maybe
not
I've
seen
cases
where
fine
SEC
bugs
found
nothing,
sometimes
in
plugins.
So
it's
like
oh
I
know
this
plug-in
has
a
lot
to
do
with
security
and
it's
a
fairly
big
plugin
and
it
must
have
some
issues
and
it
runs
as
it
doesn't.
It's
fairly
clean
and
other
ones
that
are
pretty
small
and
you
go.
Oh
yeah,
that's
one!
B
B
I'm
gonna
point
out
that
these
two
in
item
number,
one
crlf
injection
logs
and
information
exposures
through
an
error
message,
aren't
really
ones
that
Jenkins
cares
about
you're,
welcome
to
try
and
fix
them
if
you
want,
but
in
Jenkins
core
and
remoting
I
just
set
those
to
be
ignored
to
be
excluded,
and
it's
it's
never
something
the
Jenkins
project
has
made
an
effort
to.
So
that's
a
very
reasonable
thing
to
do
on
those
ones.
I
wouldn't
do
it.
B
B
Item
number
two:
you
can
disable
all
of
fine
set
bugs
by
putting
in
the
exclude
file
this
this
directive
as
part
of
a
you,
can
look
up
the
the
full
path
of
it.
I
just
booked
the
one
line
in
there,
but
you
can
disable
find
SEC
bugs
in
this
exclude
file
by
excluding
all
security
bugs
labeled
all
of
all
of
theirs.
Under
this
category.
This
means
you
won't
get
any
use
of
fine
SEC
bugs.
My
recommendation
is
to
only
do
this
temporarily
when
you
really
need
to
find
SEC
bugs
provides
value.
B
It
helps
us
create
better
code
that
are
better
product
for
our
users,
so
I
really
encourage
using
it.
But
if
you
have
some
thing,
you've
really
got
to
do
or
you're
doing
some
testing
or
something.
This
is
one
way
to
turn
it
off.
It's
going
to
be
opt
out
because,
with
the
wave
maven
works,
it's
very
very
high,
very,
very
difficult,
if
at
all
possible
to
make
it
up
to
in,
and
we
do
want
to
spread
this
throughout
the
community.
B
More
commonly
what
you
need
to
do
is
item
number
three,
so
this
it
uses
the
old
findbugs
warnings.
Annotation
spot
bug
still
uses
that
the
same
it
hasn't
redefined.
Any
of
that
part,
you
add
this
suppress,
find
bugs
warnings
with
the
value
being
the
the
error
name
like
the
crlf
injection,
logs,
etc,
and
there's
an
optional
parameter
that
justification
equals
I
strongly
encourage
you
to
do
the
justification
when
also
to
leave
traces
as
to
why
this
is
not
a
security
issue
and
I
also
encourage
you
to
do
narrowly.
B
So
if,
if
it
finds
something,
don't
put,
the
suppress
warning
on
the
whole
class
I
found
some
classes
where
there
isn't
a
there,
isn't
an
alternative.
You
have
to
put
it
on
the
whole
class,
because
it's
testing
things
at
a
class
level,
but
try
and
put
it
very
narrowly
put
it
on
only
the
method
that
needs
it
and
what
I
did
in
a
number
of
cases
in
Jenkins
itself
is
I,
did
extract
method.
B
A
That
technique
of
admitting
that
we
want
to
narrow
this
thing
as
much
as
part
of
the
use
of
this
as
much
as
possible
and
extracting
a
relatively
few
lines
into
a
separate,
dedicated
private
method.
Just
so
it
can
be
annotated,
is
perfectly
acceptable.
That's
worked
well
for
me
as
well.
I've
had
that
with
spot,
bugs
warning,
where
it's
just
cleaner
to
be
able
to
say,
I
want
this
thing
excluded
just
exactly
this
segment,
I'll
extract
it
to
its
own
private
method
and
off.
It
goes
yeah
and.
B
Most
of
what
I'm
saying
here
in
this
is
not
different
for
sign
fine,
sick
bugs
than
for
spot
bugs
in
general.
There's
a
couple
of
pieces
where
you
know
it
is
a
little
bit
different,
but
yeah
it's
a
lot.
It's
largely
the
same
thing
extract
that
private
method
and
or
put
it
you
know
if
it's
a
small
method,
go
ahead
and
use
that
and
you
have
to
usually
add
a
number
of
these.
It's
like
I,
said
it's
the
downside
to
put
using
this
in
legacy
code
a
lot
of
times.
B
If
we're
writing
the
new
code,
we
can
do
number
four.
When
we
hit
this
sort
of
a
find
bugs
I
find
sick,
bugs
warning,
we
can
improve
the
code,
it's
a
harder
to
do
on
the
legacy
code,
and
that's
this
this
balancing
that
we
have
to
try
and
do
to
move
forward.
So
number
four
is:
when
possible:
don't
suppress
just
improve
the
code
so
that
it
does
something
better
and
the
one
example
I
gave
her
I
mentioned
before.
Md5
is
used
a
lot
of
places
in
Jenkins,
it's
okay!
B
If
it's
not
used
for
security,
so
like
it's
used
for
fingerprinting
in
some
places,
but
even
there
it's
an
outdated
protocol,
it's
known,
problematic
and
then
it's
hard.
You
know,
as
you
get
looking
through
stuff
like
this
Oh
md5
is
used
here.
Is
that
really
a
security
case,
or
is
that
not
you
kind
of
have
to
reconsider
that
in
the
future
deal
with
those
sort
of
things?
So
if
we
can
improve
these
things,
we're
much
better
off
going
forward,
sometimes
there's
just
no
option
because
we
do
have
legacy
code.
B
B
Please
follow
the
security,
reporting
processes
and
report
them
to
the
Jenkins
security
team,
and
then
we
will
work
with
you
to
do
this
through
a
Jenkins
security
advisory.
Let
everybody
know
about
it,
it's
better
to
do
it
that
way
and
to
be
open
and
upfront
about
it
at
the
appropriate
time
when
we
can
get
it
give
everybody
the
warning,
then,
to
kind
of
just
quietly
fix
it
or
something
like
that.
Just
quietly
fix
that
people
may
not
know
how
much
they
need
to
upgrade
things
along
those
lines.
They'll
follow
the
process.
B
Reporte
security
team
will
work
with
you,
and
sometimes
you
know.
We
find
that
there's
a
new
class
of
issue
that
people
have
discovered
that
we
need
to
look
in
other
areas
too,
and
so
that's
another
aspect
of
reporting.
That's
very
helpful
number
six
is,
is
a
follow
on
basically
number
four.
Sometimes
it's
like
yeah.
We
could
improve
something
here,
but
I,
don't
it's
beyond
the
scope
of
what
I'm
trying
to
get
done
right
now,
and
so
you
can
create
JIRA
tickets
or
tasks
and
whatever
your
task
tracking
mechanism
is
for
improvement.
B
So
if
you
look
at
the
changes
that
I
did
in
Jenkins
when
I
introduced
fine
sick,
bugs
some
of
mine
have
comments
relating
to
a
Jenkins,
you
know
number
JIRA
ticket
of
something
where
yeah
we
can
improve
this.
Let's
work
towards
doing
this,
I
put
one
in
for
md5.
Let's
improve
decrease
or
eliminate
usage
of
md5.
That's
gonna
be
a
big
effort.
There's
no
way
we
could
do
it
and
that
same
that
same
ticket.
B
Okay,
let
me
then
go
on
I'm.
Gonna
show
some
examples
of
three
place
there
will
there
there
are.
There
are
examples:
I'm
not
necessary,
going
to
show
all
of
these,
but
I
will
show
some
in
a
minute
here,
some
places
where
it's
already
integrated
some
places,
where
I
put
in
some
demo
PRS
of
what
it
would
look
like,
because
it's
integrated
and
then
I
just
wanted
to
come
to
this
one
too
a
lot
out
of
this
and
some
other
comments.
I'm
not
some-
are
also
in
a
blog
post
that
I
I
wrote
here
recently.
B
B
So
here
this
is
in
Jenkins,
and
you
can
see
where
this.
This
is
an
example
of
where
I
did
the
extract
method
to
get
us
a
smaller
method
in
order
to
put
the
annotation
there.
Now
here
was
a
little
tiny
method
and
I
could
just
add
the
suppression
there,
but
in
this
other
place,
I
extracted
the
get
file
from
arguments
method
and
if
we
look
down
here,
I've
got
these
and
I've
got.
B
So
there's
like
what
was
the
21
files
that
I
had
to
update
here
to
get
this
to
work.
Here's
another
example
of
doing
a
narrow
one
justification,
some
other
things.
So
this
one
has
been
merged.
It's
been
in
Jenkins
for
a
month
or
so
now.
I
think
at
this
point,
you're
welcome
to
go.
Take
a
look
at
it.
You
can
see
how
I
did
it
there
than
what
it
looks
like,
which
one
is
this
one?
B
This
is
the
remoting
one,
and
so
you
know
you
can
see
this
one
too,
like
I,
said
remoting,
since
it's
not
a
web
application.
It's
the
piece
that
runs
between
them
and
a
significant
portion
of
it
runs
on
the
client
side
I'm
the
agent
launched
by
something
that
the
administrator
sets
up.
Possibly
a
number
of
these
are
not
there's
more
issues
in
here.
B
Remoting
also
runs
at
a
level
where
it,
whereas
pews
out
all
findings,
whereas
Jenkins
runs
at
a
level
where
only
excuse
out
the
most
prominent
findings,
and
so
that
was
part
of
the
difference
way.
There's
more
files
here
in
remoting,
so
yeah,
there's
sin,
there's
just
some
different
ones
on
here.
This
path,
traversal
in
you
know
this
is
loaded
on
the
on
the
agent
side
or
from
the
server
that's
sort
of
a
thing.
B
Let's
see
the
platform
labeler
one
I
just
wanted
to
point
out
two
things
on
it.
As
an
example.
Mark
used
actually
a
little
bit
different
one
when
he
did
it,
but
this
was
my
demo.
Here's
an
example
of
using
an
exclude
file
and
in
order
to
prove
that
it
was
actually
working.
I
introduced
this
line,
which
creates
a
fine
fake
finding
it's
one
of
those
two
that
I
recommended
reasonable
to
exclude.
B
So
let's
see
another
one
here.
Oh,
this
one
is,
is
the
credentials
plugin
and
this
one
is
interesting
because
it
really
did
find
a
a
meaningful
catch
now,
we'd
already
fixed
it
by
the
time
it
found
it,
but
if
I
had
run
fine
SEC
bugs
on
the
credentials
plug-in
a
year
ago,
it
would
have
found
this
issue
before
anybody
else
had
reported.
So
this
is
at
least
one
sample
of
it
really
finding
an
issue,
and
it
was
arbitrary
file
right
issue.
I
think,
is
what
what
we
ended
up,
calling
it.
B
It
was
included
in
the
may
21
advisory
of
last
year.
So
this
shows
that
it
can
find
some
now
I
just
suppress
them,
because
this
deprecated
mechanism
can't
be
used
from
the
user.
It
doesn't
take
user
input,
it
can
only
be
used
on
the
server
for
migrating
existing
data
and
so
we'll
keep
that
in
for
a
little
while
longer
here's
an
example
of
where
the
md5
hash
is
just
used
in
memory
and
is
never
stored.
B
A
B
Think
it's
important
in
this
case.
You
know:
I
haven't
gotten
this
approved
yet
so
maybe
somebody
else
will
be
concerned
about
that,
but
I
don't
think
so.
What
it's
doing
in
this
particular
case
is
it's
computing,
a
hash
of
the
agent
jar
to
see
whether
or
not
it
needs
to
update
it.
Ok,
so
it's
very.
A
B
And
so
I
don't
know
how
frequent
maybe
what's
purcha,
maybe
once
per
connection,
probably
more
likely,
so
the
cost
is
probably
pretty
negligible,
and
this
one
is
an
example,
one
from
ec2,
where
there
are
some
things
here,
which
would
be
quite
a
bit
of
concern
in
a
server-side
process,
but
it
doesn't
look
like
they're
used
and
so
just
removing
them
is
the
cleanest
way
to
do
it.
In
this
case,
the
md5
is
actually
stored.
So
it's
harder
to
next.
B
To
just
change
it
I
think,
eventually
the
project
Jenkins
project
needs
to
get
to
that
point,
but
that's
not
what
we're
doing
at
the
moment.
So
those
are
just
some
examples.
They're
available
to
look
at
I
pointed
out
some
of
the
things
that
I
found
interesting
in
them
as
we
move
this
forward,
we'll
have
more
cases,
but
these
kind
of
conserve
as
some
examples
of
how
to
how
to
deal
with
some
of
this.
So
the
remoting
and
the
remoting
ones
been
in
recent
versions
of
remoting
for
a
couple
of
I.
B
Think
since
December
not
positive
on
that
the
Jenkins
ones
been
in
for
a
month
or
two
platform
label
or
market
index
in
the
last
few
weeks,
these
ones
are
drama
or
draft
PRS
to
demonstrate
that
they're
available
and,
like
I
said,
there's
some
more
or
some
other
capture
of
much
of
this
stuff,
also
in
the
blog
post.
So
people
can
go
back
and
look
at
that
and
see
some
of
these
comments
and
some
of
the
things
that
I
thought
were
interesting
in
the
various
examples.
B
That's
what
I
have.
If
there's
any
further
questions,
please
ask
them,
but
I
think
that
the
fine
SEC
bugs
is
a
very
valuable
thing
to
include
in
Jenkins,
there's
more
and
more
interest
in
security
with
regards
to
computer
software,
these
days
and
the
Jenkins
project.
We
certainly
see
that
that
increasing,
and
so
we
want
to
get
that
out,
closer
and
closer
to
the
developers.
The
more
that
we
can
so
that
we
can
get
the
things
corrected
more
quickly,
I'm
not
introduced
in
the
first
place,
which
is
really
the
goal
of
a
lot
of
this.