Static analysis is a proven defect prevention development practice, so why do so many organizations undervalue and underuse it—even when they've already invested in it? The key to broad adoption of static analysis across your organization is giving developers and software engineers proper guidance on how to leverage the software quality activity on a daily basis in real-world settings. This presentation explores how to turn static analysis from a disruptive task into an integrated process that actually boosts software quality and team productivity across the SDLC. It covers best practices for integrating static analysis into your workflow, as well as how to avoid the everyday mistakes that discourage adoption.

1. Paraso&
Copyright
©
2014
1
Real
World
Sta,c
Analysis
Boot
Camp
Part
1
2014

2. GoToWebinar
Housekeeping
Your
Par6cipa6on
Paraso&
Copyright
©
2014
2
Open and hide your control panel
Join audio:
• Choose “Mic & Speakers” to use
VoIP
• Choose “Telephone” and dial
using the information provided
Submit questions and comments via
the Questions panel
Note: Today’s presentation is being
recorded and will be provided within
a week.

3. Paraso&
Copyright
©
2014
3
Why
sta6c
analysis
Prevent
Problems
Target
Problems
Learning

4. Paraso&
Copyright
©
2014
4
Defects
Types
of
Sta6c
Analysis
Pattern Based
Flow Analysis
Metrics

5. Paraso&
Copyright
©
2014
5
What’s
it
for?
Review
Sta6c
Value
Bugs
Prevent
Standards
Behavior
Mentor

6. Paraso&
Copyright
©
2014
6
Selec6ng
a
tool
§ Types
of
analysis
§ Languages
covered
§ IDE
integra6on
§ Number
of
rules
/
standards
covered
§ Ac6ve
development
§ Supported
workflows
§ Repor6ng

7. Paraso&
Copyright
©
2014
7
PaYern-­‐Based
Sta6c
Analysis
What:
• Iden6fy
specific
paYerns
in
the
code
Why:
• Find
dangerous
prac6ces
• Prevents
defects
• Ensure
inclusion
of
required
items
• Security
• Branding

8. Paraso&
Copyright
©
2014
8
Data
Flow
Analysis
What:
• Simulate
execu6on
to
find
paYerns
• Analyze
paths
• Analyze
data
usage
Why:
• Find
real
bugs
• Find
security
vulnerabili6es

9. Paraso&
Copyright
©
2014
9
Results
within
IDE
2 Directly access line of code to fix
1 Results delivered as uniform view within IDE
3 Check-in

10. Paraso&
Copyright
©
2014
10
Workflow
Integra6on
§ Has
to
work
with
your
development
UI
§ Same
configura6on
for
desktop
and
server
§ Minimize
nega6ve
impact
§ Minimize
6me
to
find
/
fix
viola6ons

11. Paraso&
Copyright
©
2014
11
Repor6ng
Historical
trends
Drill-­‐down
for
detail
Cri6cal
info
• Developer
• Project
• Severity
• Category
“Without
the
right
informa6on,
you’re
just
another
person
with
an
opinion.”
-­‐
Tracy
O’Rourke,
CEO
of
Allen-­‐Bradley

12. Paraso&
Copyright
©
2014
12
Sample
Report

13. Paraso&
Copyright
©
2014
13
Selec6ng
a
rule
configura6on

14. Paraso&
Copyright
©
2014
14
Being
Successful
Choose
rules
carefully
Implement
progressively
• Fewer
to
more
rules
• Extend
date
backward
Suppressions
to
manage
noise

15. Paraso&
Copyright
©
2014
15
Choosing
rules
§ Things
happening
in
the
field
§ Things
you
worry
will
happen
§ Things
happening
in
the
news
§ Standards
you
must
comply
with

16. Paraso&
Copyright
©
2014
16
Don’t
Get
Run
Over
Same
set
of
rules
for
everyone
Small
set
of
rules
Less
rules
that
are
followed
is
beYer
than
more
that
are
not
If
you
wouldn’t
fix
it,
don’t
check
for
it

17. Paraso&
Copyright
©
2014
17
Configura6on
Op6ons
Configura,on
affects
adop,on
Rules
for
new
code
vs
legacy
code
Cut-­‐off
dates
The
right
rules
Avoid
“we
want
to
comply
with
this
later”

18. Paraso&
Copyright
©
2014
18
Refining
the
Rules
Check
the
rules
on
real
code
Reduce
rules
if
there
are
too
many
viola6ons
Rules
that
have
too
many
viola6ons
may
not
be
a
good
candidate
Suppress
files
that
have
too
many
viola6ons
Spot-­‐check
rules
with
developers
Run
on
second
code
base

19. Paraso&
Copyright
©
2014
19
Workflow

20. Paraso&
Copyright
©
2014
20
Tackling
Sta6c
Analysis
Output
§ Avoid
old-­‐fashioned
model
“automated
build
and
email”
§ Avoid
complicated
manual
assignment/triage
process
§ Avoid
having
results
outside
of
the
development
IDE

21. Paraso&
Copyright
©
2014
21
Implementation of Static Analysis
1 Chose Rulesets and workflow
3 Cross-reference with source
2 Scan Code
4 Deliver Results

22. Paraso&
Copyright
©
2014
22
Everything
is
a
Task
§ Everything
a
developer
does
is
task
§ Quality
tasks
§ Coding
tasks
§ Code
review
tasks
§ Tes6ng
tasks
§ …
tasks
§ Tasks
in
the
UI
are
easier
than
email

23. Paraso&
Copyright
©
2014
23
Fixing
Viola6ons
§ Mul6ple
methods:
§ Suppress
§ Quick-­‐fix
§ Change
the
code
§ Code
review
§ Check
the
docs
for
info

24. Paraso&
Copyright
©
2014
24
NOISE

25. Paraso&
Copyright
©
2014
25
What
is
Noise?
Incorrect
messages
Unhelpful
messages
Irrelevant
messages
Anything
I
don't
need
to
hear
Anything
I
don't
want
to
hear

26. Paraso&
Copyright
©
2014
26
Common
nega6ve
misconcep6ons
It’s
a
pain
I
don’t
like
it
It’s
wrong

27. Paraso&
Copyright
©
2014
27
It’s
Too
Much
Sta6c
Analysis
is
about
process
It’s
incremental
Star6ng
with
too
many
rules
Avoid
bi6ng
off
more
than
you
can
chew
Avoid
any
rule
you
won’t
stop
the
build
for

28. Paraso&
Copyright
©
2014
28
Tips
and
Traps

29. Paraso&
Copyright
©
2014
29
False
posi6ve
misconcep6ons
False
posi6ves
are
the
big
problem
Manual
review
&
priori6za6on
is
the
way
Suppressions
should
be
outside
the
code

30. Paraso&
Copyright
©
2014
30
Expecta6ons
§ Why
do
sta6c
analysis?
§ Because
it’s
the
right
thing?
§ Increase
quality?
§ Decrease
costs?
§ Reduce
development
6me?
§ Flow
analysis
is
enough
§ When
will
it
pay-­‐off?
§ How
can
I
tell
it’s
paying
off?

31. Paraso&
Copyright
©
2014
31
The
Right
Approach
§ Running
SA
on
all
your
code
(Don’t)
§ It’s
all
about
the
reports
(Or
is
it?)

32. Paraso&
Copyright
©
2014
32
Sta6c
Analysis
for
Preven6on
It’s
quicker
to
deal
with
false
posi6ves
than
bugs
Flow
analysis
finds
complicated
problems
Run6me
analysis
should
match
flow
analysis
Rules
should
be
chosen
based
on
real
problems

33. Paraso&
Copyright
©
2014
33
SA
for
Process
Improvement
Flow
analysis
won’t
find
everything
Flow
rules
have
corresponding
paYern-­‐based
rules
Prevent
the
poten6al
rather
than
chase
paths

34. Paraso&
Copyright
©
2014
34
Policy
IS
Important
§ What
teams
need
to
do
SA?
§ What
projects
require
SA?
§ What
rules
are
required?
§ What
amount
of
compliance?
§ When
can
you
suppress?
§ How
to
handle
legacy
code?
§ Do
you
ship
with
SA
viola6ons?
§ Which
ones?

35. Paraso&
Copyright
©
2014
35
Q&A
§ Web
§ hYp://www.paraso&.com/jsp/resources
§ Blog
§ hYp://alm.paraso&.com
§ Social
§ Facebook:
hYps://www.facebook.com/paraso&corpora6on
§ TwiYer:
@Paraso&
@MustRead4Dev
@CodeCurmudgeon
§ LinkedIn:
hYp://www.linkedin.com/company/paraso&
§ Google+:
+Paraso&
+ArthurHickenCodeCurmudgeon
§ Google+
Community:
Sta6c
Analysis
for
Fun
and
Profit

36. Paraso&
Copyright
©
2014
36
Coming
up
Oct
9th
–
Sta6c
Analysis
Boot
Camp
Part
2
Oct
15-­‐16th
-­‐
StarWest
Oct
17th
–
Sta6c
Analysis
for
DevOps
Oct
24-­‐25th
–
Southland
Tech
Conf
Oct
29-­‐30th
–
Cloud
Expo
Asia