This document outlines best practices for delivering secure in-vehicle software. It discusses five practices: 1) Manage and mitigate issues through static code analysis and testing to find vulnerabilities early, 2) Build security into the development workflow by integrating security checks from the start, 3) Enforce standards and ensure compliance with tools to check for adherence to guidelines like MISRA and ISO 26262, 4) Manage open source risk through policies, inventorying, and ongoing governance, and 5) Streamline processes with continuous integration, automation, and security/compliance checks integrated into the pipeline. The presentation emphasizes finding and fixing issues early, making security everyone's responsibility, and using tools to enforce best practices.

1. Top 5 best practices for
delivering secure in-
vehicle software
Embedded World Exhibition & Conference
February 26, 2015

2. Rod Cope, CTO
Presenter
Rogue Wave Software

3. Agenda
• Setting the stage
• Best practices
– Manage and mitigate issues
– Build security into your development
workflow
– Enforce standards and ensure compliance
– Manage open source risk
– Streamline with continuous integration
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

4. Setting the stage

5. Automotive hacks are well documented
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED 5

6. Increasing complexity: Connected cars
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

7. Software is growing fast
0 50 100 150 200 250 300 350
USAF F-22
USAF F-35 JSF
Avg Ford car 2009
Boeing 787 Dreamliner
Avg Ford car 2010
S-class Nav 2009
Avg luxury car 2010
Avg luxury car 2014*
LOC (millions)
*Estimated Sources: IEEE Automotive Designline, IEEE Spectrum
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

8. Open source is great (but has risks)
Benefits
mature libraries
leveraged development effort
massive peer review
little to no cost
Risks
licensing
security
bugs
lack of support
Most organizations
don’t know where and how
OSS is being used
“By 2016, 99% of Global 2000
enterprises will use open source in
mission-critical software”
- Gartner
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED 8

9. Practice #1:
Manage and mitigate issues

10. How do security issues happen?
Data breaches are the result of one flawed assumption
Most breaches result from input trust issues
OWASP Top 10 identifies common vulnerabilities from over 500,000 issues being
researched today
Heartbleed:
buffer
overflow
CWE is a community-driven identification of weaknesses
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED
Cross-site
scripting
SQL injection
Unvalidated
input
Incoming
data is well-
formed

11. Security is not a priority
Survey:
1700 developers,
80% of them incorrectly
answered key
questions surrounding
the protection of
sensitive data
Lack of focus
Lack of time
Organizations have
failed to prevent
attacks
Lack of tools/proper tools
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS
RESERVED

12. Static code analysis and testing
Traditionally used to find simple, annoying bugs
Modern, state-of-the-art SCA
Sophisticated inter-
procedural control and
data-flow analysis
Model-based simulation
of runtime expectation
Provides an automated
view of all possible
execution paths
Find complex bugs and
security issues, such as
memory leaks,
concurrency violations,
buffer overflows
Check compliance with
internationally
recognized standards
MISRA
CWE
OWASP
ISO26262
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED 12

13. Who owns security?
Security is everyone’s
responsibility
Developers
 Focused on making code
functional
 Meeting deadlines
 Developing code faster
 Security is an afterthought
IT
 Cleaning up the aftermath
of breaches
 Preventing system hacks
 Creating a safe structure
 Security is a priority
Tools
 Automate detection of
vulnerabilities
 Fit into existing processes
 Aggregate reports to see
trends
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

14. Practice #2:
Build security into your
development workflow

15. What not to do
• Write a book…
• 1500 pages long…
• Run the spellchecker
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

16. The faster you find a defect, the less costly to fix
1X 3X 5X 10X
100X
Requirements Architecture Construction System Test Post Release $139
$455 $977
$7,136
$14,103
Requirements Design Coding Testing MaintenanceTime Detected
CosttoFix
Specification
Design
Code
Unit Test
System Test
UAT
Release
CosttoFix
Lifecycle Stage
CosttoFix
Development Unit Tests QA Testing Production
Time
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

17. Analysis earlier in the cycle
 Eliminates new defects from being checked back into the team level build
 No extra work for developers
 In-context checking and fixes
 Continuity of development flow
Edit Save
Analyze
& Fix
Compile Test Check In Build
Development Cycle
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

18. All of the supply chain needs to be secure, not just your code but the code of the
packages included in your software
Follow a well-known security standard applicable to your domain
What else can you do?
Need to “bake in” security
Educate the development team, provide security based training
Automate to find flaws as soon as possible!
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

19. Practice #3:
Enforce standards and
ensure compliance

20. ISO 26262
Functional Safety Hazard and Risk Analysis
IEC 61508 IEC 60601 ISO 14971
IEC 62304EN 5012x EN 81IEC 62061ISO 61511ISO 26262
Railways MachineryCars Process Elevators Medical
478 pages
(English Version)
670 pages
(English Version)
Relationship between ISO 26262 and IEC 61508
...
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

21. A certified analysis tool
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED
 Certified results for the Software Verification Report (ISO
26262, section 6)
 Accurate within the definitions and scopes documented for
the tool
Provides dependable, repeatable results
 Tool is pre-qualified with evidence artifacts
 If following usage patterns and requirements defined in the
safety manual, no further qualification work required
 In other cases, the tool qualification package can be
extended to provide necessary qualification evidence
Reduces tool qualification effort (ISO 26262, section 8)

22. MISRA standards
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED
Coding standard, not
functional safety like ISO 26262
Write safer software from the
beginning using a restrictive
subset of the language
C library dynamic memory –
surely the worst possible
thing?
How do we check for
correct usage?
Rule 20.4 (required)
Dynamic heap memory allocation
shall not be used
Example from MISRA C 2004

23. How can SCA tools help?
Prove compliance to coding guidelines and coding rules
Boost overall development productivity
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED
• Nearly all functional safety standards recommend or require use
of language subsets
• SCA tools enforce such rules with feedback to developers and
reports showing compliance or gaps
• Detect security, reliability, maintainability issues as early in the
development process as possible
• No time wasted finding coding errors in texting
• Allows focus on testing functionality, which is likely to generate
better software

24. Practice #4:
Manage open source risk

25. The state of OSS
• 76% of organizations lack meaningful controls over
OSS selection and use
• 80% of developers need not prove security of OSS
they are using
• 20% of the organizations claim to track
vulnerabilities in OSS over time
– 11 million developers worldwide make 13 billion open
source requests each year.
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED
Increased use + few controls = unmanaged risk

26. OSS
standards
team
Step 1: Define policies
Create policies based on needs assessment
Adopt governance based on requirements
Security, maintenance,
support, and training
Internal vs. commercially-
distributed software
Supply chain intake:
- 3rd party software
- Outsourced development
Acquisition and approval
strategies and workflows
Ongoing audits and
compliance documentation
Industry or supply chain
mandates
OSS review
board
OSS
compliance
officer
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

27. Step 2: Know your inventory
What’s in your codeline?
Scan for OSS
Identify embedded projects,
files, or code snippets
Adaptive, real-time updates
Reveal licensing and
copyright/copyleft
information
Internal
policy
compliance
Analyze for
risk
OSS use
Licensing and compliance
permissive & copyleft
OSS within other OSS and
binaries
External
policy
compliance
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

28. Step 3: Promote safe ongoing use
Ongoing governance
Support and maintenance
Baseline and continuous
delta scans
Open source repository that
reflects policy and
compliance
Proactive version and
security update
notifications
Monitor for security risks
and software updates
Continuity regardless of
internal changes or team
realignment
Downstream IT application
use and management
Who supports
your OSS
code?
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

29. Practice #5:
Streamline with continuous
integration

30. The age of consumer demands
“Assembling” vs. “code from
scratch” is the new ethos
Increased need for pipeline
automation to simplify and
streamline delivery
Complexity and size increasing
Security and compliance are
immediate concerns
Open source use increasing
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED 30

31. Automation is key to successful CI
 Scanning to discover open
Automate the discovery of security weaknesses,
compliance violations, defects
 Scanning to discover open
Self-testing frees up developers time
Run as part of Continuous Integration
 Scanning to discover open
Identify areas of bad code
Prove safety and compliance
Continuous Integration and Continuous DeliveryAutomate
the build
process
Continuous Testing and static analysis
Valuable feedback and visible results
Automate
testing
Automate
reporting
© 2015 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED

32. Q&A

33. See us in action:
www.roguewave.com
Rod Cope
rod.cope@roguewave.com