Streamlining DO-178B Efforts with Klocwork Source Code ... · Streamlining DO-178B Efforts with Klocwork Source Code Analysis (v. 1.3) · A Klocwork Whitepaper · 5 d. Verifiability

Streamlining DO-178B Efforts with Klocwork Source Code Analysis

KLOCWORK WHITEPAPER · MARCH 2009 · V.1.3

Streamlining DO-178B Efforts with Klocwork Source Code Analysis (v. 1.3) · A Klocwork Whitepaper · 1

Introduction

Published by RTCA, Incorporated the DO-178B standard, Software Considerations in Airborne Systems and Equipment Certification, is a set of best practices to ensure the safety and reliability of airborne software systems. Considered a Software Verification Tool by DO-178B, the use of source code analysis (SCA) tools can automate numerous source code inspection requirements, in particular requirements for Software Verification and Software Lifecycle Data. SCA technology does not replace the need for other types of testing but can dramatically reduce a project’s verification costs. Software verification (analysis, review, test) is the largest single development cost for a safety-critical project and through the use of source code analysis, the verification team can focus on verifying the software and its requirements rather than spending resources fixing programming bugs.

The purpose of this white paper is to illustrate how the use of source code analysis tools, specifically Klocwork Insight, can help software development organizations aiming to achieve DO-178B certification streamline their efforts. The paper first introduces source code analysis technology and the benefits it brings to those developing mission-critical software. It then summarizes the core features of Klocwork Insight that can be leveraged in a DO-178B context. Lastly, it explains the areas of the guidance that can be satisfied or partially satisfied through the use of Klocwork Insight.


// STATIC SOURCE CODE ANALYSIS

Automated source code analysis (SCA) technology is designed to locate and describe areas of weakness in software source code. Those weaknesses may be security vulnerabilities, logic errors, implementation defects, concurrency violations, rare boundary conditions, or any number of other types of problem-causing code. The underlying technology associated with SCA is called Static Analysis and the current generation of technology solutions is capable of providing sophisticated, high-value analysis that will identify critical bugs and security vulnerabilities in code that can potentially cause system crashes, hacker exploits or affect the overall reliability of mission-critical software. To identify these types of issues in complex software, modern source code analysis tools apply complex static analysis techniques to source code, including inter-procedural control flow, data flow, value-range propagation, and symbolic logic evaluation.

Source code analysis is distinct from more traditional dynamic analysis techniques, such as unit or penetration tests, since the work is performed at build time using only the source code of the program or module in question. The results reported are therefore generated from a complete view of every possible execution path, rather than some aspect of a necessarily limited observed runtime behavior.

This new level of automated code analysis is bringing tremendous benefits to software development, including: reduced development costs and improved productivity, dramatic reduction in defects found at system test and QA, and ultimately more reliable and maintainable software products. When implemented as a standard part of a team’s development process, source code analysis gives developers the ability to scrub their code of obvious and not-so-obvious weaknesses as they work, before they submit their code for check-in and additional down-stream verification procedures.

// LEVERAGING SCA IN A DO-178B CONTEXT

Section 6.0: Software Verification Process and Section 11.0: Software Lifecycle Data of the DO-178B guidance outline numerous requirements that can be addressed with source code analysis tools. More specifically, the following features provided in Klocwork Insight can assist software development teams in meeting these particular guidance objectives in an efficient and effective manner.

Operational Bugs and Security Vulnerability AnalysisThe number of operational bugs and security vulnerabilities that can be found by Klocwork run into the hundreds and can be organized into the following high-level categories for C/C++.

» Memory and Resource Management » Program Data Management » Buffer Overflows » Concurrency Violations » Platform Support » Un-Validated User Input » Vulnerable Coding Practices » Long-Term Maintenance Issues

See this document’s Appendix for more details on these bug and vulnerability types.

Stack Overflow AnalysisPotential stack overflow errors are calculated by using a special metric (Maximum Acyclic Stack Size) which uses a Directed Call Graph starting from entry functions. The Klocwork Stack Overflow Analyzer allows you to:

» Specify entry functions or use default entry functions (nodes with no calls to them) » Specify a stack size for each entry function » Identify functions with maximum stack size » Identify recursive functions with the minimum number of loops required to overflow the stack » Print information about a selected function » Visualize the call graph of the application focusing on stack usage issues


Architecture Analysis and FlowchartingKlocwork Insight extracts an accurate representation of the structure and organization of your software directly from the existing source code. The Architect graphical interface allows software designers to understand the following aspects of a software system: components and sub-components, interfaces and relationships between components, along with a view of the software’s control flow via a flowchart-based view. This allows software designers to experiment with various optimized models without impacting the system. This automated code discovery capability allows architects to understand and visualize complex code interactions, create what-if scenarios, and re-engineer the code for greater optimization and better organization and consistency.

Additionally, any desired software architecture can be enforced through the use of Klocwork’s architecture rules which ensure that only desired relationships between software entities exist. These can be enforced at both the developer desktop and system build level.

When coupled with Klocwork’s critical bug detection, Klocwork Insight enables development teams to write better, more maintainable code.

Software Metrics Analysis

In addition to the operational bug detection and architecture analysis capabilities, Klocwork provides a robust software metrics solution. Klocwork Insight supports over 100 software metrics, including McCabe Cyclomatic Complexity, coupling, maintainability and risk metrics. Out-of-the-box metrics can be combined into compound metrics to support a large number of custom software metrics programs. Thresholds for metrics can be set at both the developer desktop and system build level through a rich management reporting dashboard.

Klocwork ExtensibilityCustomers have the flexibility to extend the out-of-the-box library of checkers by creating custom checkers to meet their unique organizational, regulatory or code base requirements. The foundations for this capability are two types of high-level declarative language frameworks that are used to generate different types of checkers:

1. Abstract Syntax Tree (AST) checkers are used when the checker doesn’t require runtime state to evaluate an error condition and can be found entirely within the source tree. Example AST checker: Classes must not place calls to virtual member functions within constructors or destructors.

2. Data flow checkers require knowledge of the code’s runtime state and complex data flow across function call boundaries in order to create effective analysis. Example data flow checker: The collection returned by the Arrays.asList() method is immutable and must not be modified - any attempt to modify it will throw a runtime exception.

AST checker development can be done through the Checker Studio product module which provides developers with the following feature set:


» Design support through comprehensive documentation of the available APIs, sample checkers, and tutorials for creating new checkers

» Development support through the availability of a checker development tool chain to navigate the Klocwork-generated AST, allowing developers to more easily implement checkers

» Deployment support through a simplified, “one button” checker deployment that introduces an automated “push model” for deploying custom

checkers to the developer’s desktop.

// SECTIONS OF DO-178B GUIDANCE SUPPORTED BY KLOCWORK INSIGHT

Outlined below are the specific subsections of Section 6.0: Software Verification Process and Section 11.0: Software Lifecycle Data required by the standard that can be addressed or partially addressed through the use of Klocwork Insight. Please note that Klocwork’s summary of various DO-178B objectives is meant as a high-level summary for the purposes of communicating Klocwork’s relevant capabilities. Please refer to the standard and consult your compliance subject matter experts for clarification on any requirements laid out by the DO-178B standard.

Section 6.0 Software Verification Process

6.3.3 Reviews and Analyses of the Software Architecture

This section requires organizations to review their software architecture for potential errors introduced during its development, including satisfying numerous specific objectives. Klocwork may be used with the analysis to support the following five objectives of 6.3.3.

REQUIRED VERIFICATION KLOCWORK CHECKER TYPE OR ANALYSIS FEATURE

QUAL. PACK

a. Compatibility with high-level requirements

Klocwork Architect

b. Consistency Klocwork Architect

c. Compatibility with Target Computer Uninitialized variables checker d. Verifiability Klocwork Architect

e. Conformance to Standards Klocwork Architect, Klocwork Metrics Analysis, and Klocwork Extensibility

a. Compatibility with High Level Requirements – When reviewing the architecture it is important that it be clearly understood. The reviewer can use Klocwork to visualize the architecture and form a deeper understanding of the relationship of the components that comprise the software. This knowledge allows the reviewer to verify the compatibility of the software architecture with the high level requirements.

b. Consistency – This review confirms the correctness of the relationships between the components of the software architecture. The control flow and data flow relationships are analyzed and exposed to the reviewer, who is better able to make a determination of their consistency.

c. Compatibility with Target Computer – Although most of this objective is verified by the engineer, Klocwork is able to determine if the initialization sequences are performed correctly. In particular, use of data before it is initialized is an important property that can be detected by Klocwork.


d. Verifiability – In general, once verification evidence is established then it is clear that the architecture is verifiable, however some subtle control flow paths may exist which are difficult to detect by manual review; for example indirect recursion errors can be isolated for inspection to assess whether they are bounded or unbounded.

e. Conformance to Standards – This depends on the software design standards adopted. If the standards place constraints on the software and these constraints are described through the use of language constructs then Klocwork is able to verify those violations. For example, instances where the complexity exceeds prescribed limits can be detected with the metrics provided by the tool, or the presence of certain language features nested in other language features (e.g. blocking operations inside interrupt driver code) can be detected using Klocwork’s Extensibility to identify specific coding constructs that are disallowed.

6.3.4 Reviews and Analyses of the Source Code

This section requires a review and analysis of the source code to identify errors that could have been introduced during the software coding process. Primary concerns include correctness of the code with respect to requirements and architecture along with conformance to coding standards. Klocwork provides support for three objectives of 6.3.4.

b. Compliance with the software architecture


QUAL. PACK

Compliance with software architecture Klocwork Architect enables data flow and control flow analysis which is exposed to the reviewer allowing the reviewer to check this information against design. The design may be expressed as low level requirements. In addition, the consistency of the data and control flow will be checked automatically by Klocwork.

d. Conformance to standards


QUAL. PACK

Software code standards See Section 11.8

Complexity restrictions McCabe Cyclomatic Complexity, Coupling, and 100+ software metrics

f. Accuracy and Consistency


QUAL. PACK

Stack usage Stack Overflow Analyzer

Use of uninitialized variables or constants

Uninitialized variables Detection of unused variables or constants

Unused code

6.4.3 Requirements-Based Testing Methods

The objective of requirements-based testing cannot be replaced by analysis of the source code, but by analyzing the code with Klocwork the sorts of errors that are typically found during testing can be significantly reduced. Since verification (analysis, review, test) is the largest single development cost for a safety-critical project, the opportunities for cost reduction are significant. Through the use of Klocwork the verification team can focus on verification of the software and its requirements rather than spending resources finding, reproducing, and fixing programming bugs that should have been captured during development.

b. Requirements-based software integration testing


The goal of this section on requirements-based software integration testing is to ensure that software components interact correctly with each other and satisfy the software requirements and architecture. Klocwork provides support through the use of multiple defect detection capabilities listed below.

REQUIRED VERIFICATION KLOCWORK CHECKER TYPE QUAL. PACK

Incorrect initialization of variables and constants

Uninitialized variables Parameter passing errors NULL pointer dereferences, Array bounds violations,

and Use of free memory Data corruption, especially global data Buffer overflow, Unvalidated data Data corruption, especially global data Time-of-check-Time-of-use (TOCTOU), Various

suspicious coding practices

Inadequate end-to-end numerical resolution

Divide by zero, Precision loss

c. Requirements-based low-level testing

The goal of this section on requirements-based low-level testing is to ensure that each component complies with its low-level requirements. Klocwork provides support through the use of multiple defect detection capabilities listed below.


Violation of array limits Array bounds violation Incorrect computation sequence Divide by zero

6.4.4.3 Structural Coverage Analysis Resolution

The goal of structural coverage analysis, as defined by the standard, is to identify code structure that was not exercised during testing. As a static analysis tool, Klocwork can contribute to this goal through the identification of dead or unused code. When dead code is identified and removed at the source code level, it ensures time isn’t wasted writing tests for code that cannot be accessed via coverage analysis.


c. Dead Code Unused code

Section 11.0 Software Life Cycle Data

11.7 Software Design Standards

This goal of this section is to define the methods, rules and tools to be used to develop the software architecture and low-level requirements. Klocwork can support three sub-sections required in this section.


QUAL. PACK

b. Naming conventions to be used Usage of Klocwork Extensibility (KAST) to apply any specific naming convention

e. Constraints on design Usage of Klocwork Extensibility (KAST) to identify design issues

f. Complexity restrictions McCabe Cyclomatic Complexity, Coupling, and 100+ software metrics

11.8 Software Code Standards

This goal of this section is to define the programming language, methods, rules and tools to be used to code the software. Klocwork can support two of the sub-sections required in this section.



QUAL. PACK

a. Programming language, feature subsets, etc

Usage of Klocwork Extensibility (KAST) to apply checks against the code’s Abstract Syntax Tree (AST)

c. Naming conventions for variables and constants.

Usage of Klocwork Extensibility (KAST) to apply any specific naming conventions for variables and constants

d. Conditions and constraints permitted on coding conventions

Coupling metrics

// KLOCWORK INSIGHT TOOL QUALIFICATION

As a static code analysis tool, Klocwork is considered to be a Software Verification Tool according to the DO-178B guidance. This places the qualification threshold for the tool as being able to demonstrate that the tool complies with its Operational Requirements under normal conditions (section 12.2).

If customers wish to qualify the use of Klocwork on their project for credit under DO-178B, Klocwork will license use of the following deliverables for the customer’s specific development configuration:

1. Tool Qualification Plan

2. Tool Operational Requirements

3. Tool Qualification Data

The goal of these deliverables is to enable the customer to achieve qualification of Klocwork Insight by a Certification Authority in a cost effective and efficient manner


// APPENDIX - EXPLANATION OF C/C++ OPERATIONAL BUGS AND VULNERABILITIES FOUND BY KLOCWORK

Klocwork static source code analysis finds the most comprehensive range of complex and critical programming issues for C and C++ software development.

MEMORY AND RESOURCE MANAGEMENTThe C and C++ languages provide significant benefits to developers in terms of direct access to hardware and the resources associated with low levels of machine interaction. The down side of this flexibility, of course, is the requirement on the developer to take complete responsibility for managing the overall lifecycle of each and every resource.

Memory management, in particular, is one of the greatest sources of bugs in software. Allocating and guaranteeing de-allocation is one major problem to deal with, but other problems such as the re-use of memory, inconsistency in usage of allocation APIs, and overall lifecycle management contribute to making this category of checkers one of the most valuable in Klocwork’s arsenal.

Memory and resource leaksWhilst not a concern for a simple test program, leakage of memory and other resources is one of the prime concerns when creating a long-lived application, especially in constrained environments such as embedded software.

The checkers in this family are listed below:

MLK Memory leak detected

SYM.MLK Memory leak specific to the Symbian environment detected

RH.LEAK General resource leak

FREE. INCONSISTENT Inconsistent de-allocation of memory on code paths in function

CL.MLK Weak coding pattern leading to memory leak in destructor

CL.SELF-ASSIGN Weak coding pattern leading to memory leak in operator ‘=’

Note that certain of these checkers will distinguish whether the error occurs on all code paths or only on certain code paths, where appropriate.

Using de-allocated memory

Using de-allocated memory is known to lead to a wide variety of aberrant situations based on operations being performed using memory that has potentially already been allocated to another purpose, or even another process.


UFM.DEREF Attempt to dereference a pointer to de-allocated memory

UFM.FFM Attempt to de-allocate already de-allocated memory

UFM.PARAMPASS Attempt to pass de-allocated memory to a function

UFM.RETURN Attempt to return de-allocated memory from a function

UFM.USE General attempt to use de-allocated memory

LOCRET Attempt to return a local variable’s address from a function

CL.FFM Potential weakness in class construction

Note that all checkers in this family also report whether errors occur on all code paths or only on certain code paths, where appropriate. Incorrect memory de-allocation

Bugs related to incorrect or inconsistent de-allocation can lead to long-term maintenance problems, as well as crash causing scenarios. Of particular harm when occurring in multi-language code (e.g. mixed C and C++), these errors can also occur when mixing debug and retail allocation libraries.



FMM Mismatched allocation / de-allocation

CL.FMM Potential class construction weakness

FNH Attempt to de-allocate non-heap memory

FUM Attempt to de-allocate unallocated memory

Note that all checkers in this family also report whether errors occur on all code paths or only on certain code paths, where appropriate.

PROGRAM DATA MANAGEMENTThe variables used within a program are the backbone of its execution context. Ensuring that these variables are valid under all circumstances is one of the main keys to creating a long-lived, valuable application. Of particular interest to C/C++ developers are the two classes of checkers called out below, namely pointers and situations in which they can assume invalid values, and uninitialized data of any kind.

Dereferencing NULL pointers

Depending on the processor architecture in use, as well as the semantics of the operating environment, dereferencing NULL pointers can lead to segmentation faults and other types of dire scenario. Understanding when and how a pointer may assume a NULL value requires complex data and control flow analysis, resulting in a more fine-grained set of checker types than are present in other families.

The top-level checkers in this family are listed below, each of which are further qualified during analysis to provide context in terms of the error’s actual means of failure:

NPD.GEN Attempt to dereference a NULL pointer

NPD.FUNC NULL pointer returned from a function call will be dereferenced

NPD.CHECK Pointer that is checked for NULL is then dereferenced

NPD.CONST Pointer initialized with a constant NULL value is dereferenced

RNPD Pointer is dereferenced and then checked for NULL

Note that all checkers in this family report additional detail, including:

» Whether the error occurs on all code paths, or only on certain paths » Whether the NULL pointer is dereferenced locally, or by reason of calling a function

Usage of uninitialized data

Making use of data that has not been rigorously initialized is a well known cause of many program errors. Recent exploits have also shown uninitialized data to be the root cause of several key security vulnerabilities.


UNINIT.STACK Stack-resident data is uninitialized

UNINIT.HEAP Heap-resident data is uninitialized

UNINIT.CTOR C++ class member data is not initialized by the constructor

UNINIT.STACK.ARRAY Stack-resident array type is not initialized

UNINIT.STACK.ARRAY.PARTIAL Stack-resident array type is only partially initialized

Note that all checkers also report whether initialization is performed on some valid code paths only, or on no valid code paths.

BUFFER OVERFLOWSTraditionally a quality concern due to the crash causing potential of walking over data not allocated to the buffer in question, overflow flaws have increasingly become associated with security vulnerabilities due to the wide ranging research into code injection exploits.



ABR Buffer overflow

ABV Array bounds violation, or index overflow

NNTS Non-NULL terminated string causing potential overflow

SV.STRBO String library weaknesses that can cause overflows

UN-VALIDATED USER INPUTThe flow of tainted data through an application is core to understanding whether that application is vulnerable to exploit via code injection, string injection, command injection, etc. Equally, tainted data can easily lead to denial-of-service situations, crashes and other undesirable outcomes.


SV.TAINTED Lots of different types of tainted data flow analysis

SV.CUDS Unsafe use of potentially relative path names

SV.STR-PAR Potential string injection in a file path context

Note that the main checker here, SV.TAINTED, provides a variety of sub-categorizations that detail the nature of the risk that the application is under due to tainted data flow, e.g. unbounded allocation size, code or string injection, loop iteration control, etc.

VULNERABLE CODING PRACTICESVulnerable coding practices highlight code constructs or design flaws that can potentially leave the application open to exploit. These bugs need careful manual review in most cases, as the subtleties of any particular vulnerability may well not be obvious at first sight.


SV.WEAK_CRYPTO Known-weak encryption being used for sensitive data

SV.PCC Usage of known-weak system API calls

SV.BFC Code vulnerable to DNS spoofing attacks

SV.PAIRS Return values (and associated system error API) ignored

SV.RVT Function return not checked against known-invalid values

SV.BRM Known-weak system registry manipulation

CONCURRENCY VIOLATIONSCode that can lead to deadlocks can be extremely difficult to debug, especially given that such deadlocks are liable only to occur under certain runtime situations, or under extreme load of the application.


CONC.NO_UNLOCK A lock is taken and never released

CONC.SLEEP A lock is taken and then used to perform a stalling operation

PLATFORM SUPPORTPart of any valuable SCA tool is the ability to validate an application on a particular platform, whether that means O/S platforms like Windows or Linux, or language platforms such as STL, or hardware platforms as embodied by particular compilers or language extensions.

Much of this capability is built into the SCA engine itself, but several notable classes of checkers are worth calling out in this regard, as detailed below.

BSTR data type usage

The purpose of this family of checkers is to validate usage of the BSTR data type within COM code. It is unfortunately common for developers to inadvertently substitute BSTR with zero-terminated C string data types, and vice versa.



BSTR.IA Invalid initialization or assignment of BSTR variable

BSTR.OPS Mismatched, or invalid, types used in operators

BSTR.FUNC Non-BSTR types used in calls to BSTR-specific functions

BSTR.CAST Invalid cast to zero-terminated string using C or C++ semantics

CCOMBSTR.OPS Usage of CComBSTR wrapper class in invalid situations

// ABOUT KLOCWORK

Klocwork is an enterprise software company providing automated static analysis products that automate security vulnerability and quality risk assessment, remediation and measurement for C, C++, Java, and C# software. Over 500 organizations have integrated Klocwork's automated source code analysis tools into their development process, thereby:

» Reducing risk by assuring their code is free of mission-critical flaws » Reducing cost by catching issues early in the development cycle » Freeing developers to focus on what they do best - innovate

Klocwork's focus on customer success is validated by a growing roster of satisfied customers and recognition from the industry; Klocwork won InfoWorld's 2007 Technology of the Year Award in the Application Development category, and has been named to the SD Times 100 for four consecutive years.

IN THE UNITED STATES:25 Burlington Mall RoadSuite 300Burlington MA 01803

IN CANADA:30 Edgewater StreetSuite 114Ottawa ON K2L 1V8

1-866-556-29671-866-KLOCWORKWWW.KLOCWORK.COM

© Copyright Klocwork Inc. 2009 · All Rights Reserved

Documents

Streamlining DO-178B Efforts with Klocwork Source Code ... · Streamlining DO-178B Efforts with Klocwork Source Code Analysis (v. 1.3) · A Klocwork Whitepaper · 5 d. Verifiability