No liftoff, touchdown, or heartbeat shall miss because of a software failure

1© 2019 Rogue Wave Software, Inc. All Rights Reserved. 1
No liftoff, touchdown, or
heartbeat shall miss
because of a software
failure – how do we do it?
Walter Capitani
Director, Product Management

Presenter
Walter Capitani
Director, Product Management
Rogue Wave Software
walter.capitani@roguewave.com
Twitter: @walter_capitani

The problem
• How can we build reliable
and secure safety-critical
software and achieve
standards compliance?
– Use tools that can automate
compliance, quality, and
security checking such as
static code analysis
– Are all static code analysis
tools built the same?
– How can we leverage modern
DevOps tools and concepts to
make this easier?

• Hundreds of checkers for C, C++, C# and Java
• Support for numerous standards
• Customizable:
– Turn checkers on or off
– Change the severity of identified defects
– Add custom checkers
Introducing: Klocwork 2019
• MISRA, DISA, CWE, CERT,
etc.
• Dead code
• Unreachable code Calculated
values that are never used
• Unused function parameters
• And many more…
Coding Standards
& Maintainability
• Memory and resource leaks
• Concurrency violations
• Infinite loops
• Dereferencing NULL pointers
• Usage of uninitialized data
• Resource management
• Memory allocation errors
Reliability
• Buffer overflow
• Un-validated user input
• SQL injection
• Path injection
• File injection
• Cross-site scripting
• Information leakage
• Vulnerable coding practices
Security

Click here to watch
the video

Significantly reduces the cost of reliable, secure software
• Complements existing testing approaches
• Automated and repeatable analysis
Enforce key industry standards
• DISA STIG, CWE, MISRA
• CERT, SAMATE
• OWASP, DO-178B, FDA validation
• ...and more
Klocwork 2019 and compliance

How do we do it?

Klocwork analyzes your source code
• The Klocwork algorithm includes multiple analysis technologies:
– Syntax Analysis
– Data Flow Analysis
– Symbolic Logic Analysis
• Requires source code
– The most accurate tools must be able to compile the code
– No changes to your existing build flow
• Different types of analysis
– Intra-procedural (simplest analysis)
– Inter-procedural
– Inter-file

Build Process Interpretation
• Understand how the
source code is:
– Compiled
– Linked
– Automated code
generation
– Custom build steps

Klocwork Technologies

Syntax Analysis
• Creates a lossless transformation of the source code
• Generates the ‘Abstract Syntax Tree’
• Can be used to find Coding Style Issues and Simple Defects
– Simple security defects (e.g. use of banned encryption API)
– Simple coding style issues (e.g. no dynamic memory allocation)
This function
allocates
memory
Name = “malloc”,
Source Code Abstract Syntax Tree

Example defect
if(i = j) j++;
if(i == j) j++;
Defect: Assignment
operator used in
conditional statement
Assignment operator
replaced with intended
comparison operator
Vulnerable Code
Fixed Code

This seems to work well, but…
• These defects are contained in a single program
statement
• They are not dependent on values from external
functions
• Syntax Analysis can only find a limited set of defects
To find more interesting defects
you need to perform
more sophisticated analysis

Data Flow Analysis
• Monitoring of the lifecycle
of data objects:
– Creation
– Assignment
– Usage
– Deletion
• Must be monitored across all
paths in the Control Flow Graph
– Function calls
– Compilation units
• Can find program crashes across functions and files

Data Flow Analysis - example
• This function a()will cause the program to crash at line 3
• This function g() will cause the program to crash if position is outside
the valid range – how do we know if this will happen?
1 void a(){
2 int buffer[32]; // valid range of 0..31
1 buffer[35] = 5; // buffer access outside valid range (35)
4 return;
5 }
1 void g(int position, int value){
3 buffer[position] = value;
4 return;
5 }
3 buffer[35] = 5; // buffer access outside valid range (35)
Defect: Array bounds
violation

• Data Flow Analysis tracks what potential values are actually used when
function f() calls function g()
4 return;
5 }
1 void f(){
2 g(10,55); // calls function g with position=10, value=55
3 return;
4 }
No defect: values within
valid range
Vulnerable Code

1 void h(){
3 return;
1 }
function h() calls function g()
4 return;
5 }
3 buffer[position] = value; // buffer access outside valid range (35)
Defect: Array bounds
violation (program crash)
Vulnerable Code

1 void h(){
3 return;
1 }
function h() calls function g()
3 if (position < 0 || position >31 0) // Check position is valid
4 return;
6 return;
7 }
No defect
Fixed Code
3 if (position < 0 || position >31 0) // Check position is valid
4 return;

This also seems to work well, but…
• Data Flow Analysis alone can only understand actual
numeric values (or ranges of values)
• What if there are no numeric values at all? How do we
determine valid data flow paths?
To find more interesting defects
you need to augment data flow analysis
with Symbolic Logic

Symbolic Logic
• Define functional behavior between symbols
• Don’t necessarily know what the values will be at runtime
• Used to infer software behavior
1 void f(int i, int j){
3 i = j;
4
5 /* set the value of k */
6 if (i == j)
7 k = get_tainted_data(); // Since i equals j, k is tainted
8 else
9 k = 0;
10
11 /* read the value of k */
12 if (i != j) // Since i = j, k will not be used
13 buffer[k] = 0;
14 return;
15 }
3 i = j;
12 if (i != j) // Since i == j, k will not be used

Symbolic Logic
• Symbolic logic determines that since i = j, there is no use of tainted
data at line 13
• Otherwise a tool must “guess” at the defect
• If we change line 12, then a defect appears!
1 void f(int i, int j){
3 i = j;
4
5 /* set the value of k */
6 if (i == j)
8 else
9 k = 0;
10
11 /* read the value of k */
12 if (i != j) // Since i = j, k will not be used
13 buffer[k] = 0;
14 return;
15 }
12 if (i == j) // Since i == j, k will be used
Defect: Unvalidated input in
array index (program crash)
Vulnerable Code

How can Continuous
Integration make it even
better?

What is continuous integration (CI)?
• In software engineering, CI is the practice of merging all developer
working copies to a shared mainline several times a day. Grady
Booch first named and proposed CI in his 1991 method, although he did
not advocate integrating several times a day.
• Continuous integration – the practice of frequently integrating
one's new or changed code with the existing code repository –
should occur frequently enough that no intervening window remains
between commit and build, and such that no errors can arise without
developers noticing them and correcting them immediately.

Example CI process

Continuous integration and
static code analysis
– better together

Example CI process with SCA

Enhanced SCA process with CI
• For some developers, compiling their code on the desktop is not possible,
so desktop analysis is not an option
• In addition, integration issues may still be detected after check in, even
when using desktop analysis
Edit &
Save
Analyze
& Fix
Compile
& Test
Check In
Developer 1
Edit &
Save
Analyze
& Fix
Compile
& Test
Check In
Developer 2
Time
Integrate
Check In
Compile
& Test
k In
New possible
issues found
here!

Continuous static code
analysis

The future: Continuous static code analysis …
• Continuous static code analysis (CSCA) brings all the benefits of centralised server-
side, deep, inter-procedural control- and data-flow analysis to a near-desktop
feedback timescale!
• Central management of development systems fits well with DevOps movement
• Enables continuous reporting and continuous compliance
Advantages
• Near desktop speed feedback loop
• Server accuracy, centralised configuration
• Visibility of the current status

Klocwork is designed for CI
Automated
Fast(er)
Scalable
Relevant
To reduce feedback time, only
the affected code should be
analyzed
By requiring minimal resources
and deploying across multiple
agents
By reporting only the
information that is required for
the given context (example:
only the diffs since the last
build / build X)
Supporting the most important
CI build management systems

Click here to watch
the video

No liftoff, touchdown, or heartbeat shall miss because of a software failure

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à No liftoff, touchdown, or heartbeat shall miss because of a software failure

Similaire à No liftoff, touchdown, or heartbeat shall miss because of a software failure (20)

Plus de Rogue Wave Software

Plus de Rogue Wave Software (20)

Dernier

Dernier (20)

No liftoff, touchdown, or heartbeat shall miss because of a software failure