DO-178C Software Compliance for Aerospace and Defense

Static code analysis is the analysis of code without actual code execution. Static analysis exposes safety and security vulnerabilities in the code by applying a comprehensive set of code analysis techniques including:

• Pattern-based analysis
• Data flow analysis
• Control flow analysis
• Abstract interpretation
• Code metrics and more

These methods identify memory buffer overflows, divide by zero, use of insecure libraries, organization coding rules, directive violations, and so forth.

In D0-178C, the objectives for static analysis fall under Section 6 related to software verification processes. The objectives of static analysis focus on ensuring that the software code is free from certain types of defects and follow good coding practices.

For example, Section 6.3.4 Review and Analysis of Source Code, provides an overview of the software verification activities required to review code in terms of compliance, verifiability, and traceability. However, this section also specifies the need to inspect the code for conformance to standards, accuracy, and consistency, all of which are good applications for static analysis.

While D0-178C does not have a specific requirement for static analysis, the guidelines and objectives related to static analysis are spread across sections within Chapter 6. It’s crucial to interpret and apply these guidelines appropriately in the context of the project to ensure compliance with D0-178C for the certification of airborne software.

Requirements in DO-178C

Some typical requirements for static analysis in D0-178C may include the following.

Most of these verification activities are supported through the automation of static analysis using modern advanced tools like Parasoft C/C++test. In addition, Parasoft provides code metrics on maintainability, clarity, testability, portability, robustness, reusability, complexity, and support for team code peer reviews. Dynamic analysis, unit testing, and other runtime error detection is also provided.

Early Defect Detection

Early defect detection with static analysis tools can significantly improve compliance with D0-178C by addressing potential coding issues and vulnerabilities in the software development process. Static analysis analyzes source code without executing it, identifying defects and potential issues based on predefined rules.

Static analysis tools can detect coding errors and bugs in the source code early in the development process. By identifying and fixing these errors early on, the development team can prevent such defects from propagating into later stages of development, where they might be more difficult and costly to fix.

Safety-critical software used in airborne systems must be protected from potential security vulnerabilities. Static analysis tools can identify potential security weaknesses in the code, such as buffer overflows, input validation issues, and other security-related defects. Addressing these vulnerabilities early in the development process enhances the security posture of the software.

D0-178C requires comprehensive verification activities throughout the software development life cycle (Chapter 6). Static analysis, being a form of static verification, allows for early verification of the source code. By finding and addressing defects early on, the software can progress through subsequent verification stages with greater confidence, saving time and effort in the long run.

By adopting static analysis early in the software development process, in conjunction with other verification and validation methods, teams can proactively address defects and security vulnerabilities. This leads to a more streamlined certification process and a higher likelihood of producing reliable and safe software for use in airborne systems.

Some of the common types of defects that Parasoft C++test static analysis can detect include:

These are just some examples of the types of defects that Parasoft C++test static analysis can detect. Additionally, static analysis tools like Parasoft C++test can be customized to include or exclude certain types of checks based on the project’s specific requirements and coding standards.

Coding Standards

Regarding coding standards, D0-178C does not prescribe a specific set of coding standards that must be followed. Instead, it provides guidelines and objectives for establishing and adhering to coding standards appropriate for the development of safety-critical airborne software.

The relevant sections in D0-178C that pertain to coding standards are primarily found in Chapter 6 Software Verification Process and Chapter 11 Software Lifecycle Data. Here’s what D0-178C typically requires regarding coding standards.

D0-178C recognizes that different projects may have different coding standards (for example, MISRA C/C++, CERT C/C++, CWE, OWASP, DISA ASD STIG, and so on) depending on factors such as the complexity of the software, the criticality of the system, and the development environment.

Therefore, the specific coding standards and rules are determined by the development team while still satisfying the guidelines outlined above.

A vital part of the certification evidence required for D0-178C compliance is the documentation collected during these reviews and the verification process. It’s important that the coding standard support the inspection and the documentation processes required.

MISRA C:2023

MISRA C is a set of coding guidelines for the C programming language, versions C89/C90, C99, C11, and C18. The focus of the standard is increasing safety of software by pre-emptively preventing programmers from making coding mistakes that can lead to runtime failures (and possible safety concerns) by avoiding known problem constructs in the C language.

MISRA C can help satisfy the requirements of D0-178C, which is the software standard used for the certification of airborne systems. Here’s how MISRA C can fulfill the requirements.

1. Checks all the boxes of the coding standard requirements listed in the previous section.
2. Provides a well-defined and widely recognized coding standard that can be adopted by the development team to create consistent and reliable code.
3. Involves regular code reviews to ensure compliance with the standard.

The adoption of MISRA C helps minimize the potential for coding errors and ambiguities, leading to improved safety, security, and reliability of the software. The coding standard’s focus on robustness and code correctness aligns well with the objectives of D0-178C to ensure the development of high-integrity software for airborne systems.

It’s important to note that MISRA C is not a guarantee of certification compliance by itself. It’s one of the tools and processes that contribute to the overall software development and verification activities required for D0-178C certification. Additionally, each project may have specific requirements and constraints, so the MISRA C standard may need to be tailored or supplemented with project-specific coding rules and practices.

Over the years, many developers of embedded systems were-and still are- complaining that MISRA C was too stringent of a standard and that the cost of writing fully compliant code was difficult to justify. Realistically, given that MISRA C is applied in safety-critical software, the value of applying the standard to a project depends on factors such as:

• Risk of a system malfunction because of a software failure
• Cost of a system failure to the business
• Development tools and target platform
• Level of developer’s expertise

Programmers must find a practical middle ground that satisfies the spirit of the standard and still claim MISRA compliance without wasting effort on non value added activities.

Proof of MISRA Compliance

A key problem that developers of safety-critical software encounter is how to demonstrate and prove compliance at the end of the project. There’s a tendency to add more information into the reports than is required. It can become a contentious issue resulting in wasted time and effort if the evaluation criteria are based on subjective opinions from the various stakeholders.

A recommended approach to improving the evaluation of compliance readiness is to use existing templates for both the final compliance and tool qualification report. If the information is not required by the standard, avoid adding it. Combining extra information is not only a waste of time, but also introduces a risk of delaying an audit process. Having the documentation auto-generated as Parasoft does is the ultimate solution.

The MISRA Compliance: 2020 document is also helping organizations to use a common language articulating the compliance requirements by defining the following artifacts:

• Guidelines Compliance Summary
• Guideline Enforcement Plan
• Deviations Report
• Guideline Re-categorization Plan

The following Parasoft’s screenshots show auto-generated reports with links to other records and/or expansion of information on the page.

SEI/CERT

The Software Engineering Institute (SEI) Computer Emergency Response Team (CERT) has a set of guidelines to help developers create safer, more secure, and more reliable software. Started in 2006 at a meeting of the C Standard Committee, the first CERT C standard was published in 2008 and is constantly developing and evolving.

There’s a book version published in 2016, but it doesn’t include the latest updates. This standard doesn’t have specific frozen releases like CWE Top 25 and OWASP Top 10. The standard arose from a large community of over 3,000 people with a focus on engineering and prevention. So the CERT secure coding standards focus on prevention of the root causes of security vulnerabilities rather than treating or managing the symptoms by searching for vulnerabilities.

The CERT coding guidelines are available for C, C++, Java, Perl, and Android. They fall into two main categories.

Rules are guidelines that are detectable by static analysis tools and require strict enforcement, while recommendations are guidelines that have a lower impact and are sometimes difficult to analyze automatically.

CERT includes a risk assessment system that combines likelihood of occurrence, severity, and relative difficulty of mitigation. This helps developers prioritize which guideline violations are the most important to investigate. The inclusion of mitigation effort to the guideline priority is an important addition to the CERT secure coding standards, which many other standards lack.

The cost factor allows for the creation of the CERT bullseye diagram in which the center bullseye is the highest severity guidelines that are more difficult to fix. The benefit of this prioritization is focusing on the most critical violations that provide the biggest bang for the buck in security improvement while helping the development team filter out less important warnings.

SEI CERT C/C++ Conformance

According to the SEI CERT C documentation, conformance “requires that the code not contain any violations of the rules specified in this standard. If an exceptional condition is claimed, the exception must correspond to a predefined exceptional condition, and the application of this exception must be documented in the source code.”

Although conformance is less specific than standards such as MISRA, the principles remain similar. Rules should be followed, and deviations should only occur rarely and be well documented. Recommendations should be used when possible and those that aren’t needed should be documented.

Violations that persist in the source code need to be documented. However, no deviation is acceptable for performance or usability and the onus is on the developer to demonstrate that the deviation will not lead to a vulnerability.

Parasoft C/C++test provides comprehensive CERT compliance dashboard and reports. Individual compliance reports are available on demand based on the latest build of the software or any previous build.

These reports can be sorted and navigated to investigate violations in more detail. A conformance test plan is available to correlate the CERT guideline with the corresponding Parasoft static analysis checker, which is an important tool if conformance documentation is needed for audit purposes. In addition, all the interesting reports, as specified by the team, are in a single PDF available for download by auditors.

Support for CERT C/C++ in Parasoft C/C++test

Parasoft provides comprehensive support for CERT C and CERT C++ secure coding standards with complete coverage of all the CERT C/C++ guidelines including rules and recommendations that are detectable by static analysis. Checker names, dashboards, and reports use the CERT naming convention to make conformance and auditing easier. A CERT conformance dashboard, which includes the CERT risk score, helps developers focus on the most critical violations.

CWE

CWE (Common Weakness Enumeration) is a list of discovered software weaknesses based on the analysis of reported vulnerabilities (CVEs). The collection of CVEs and CWEs is a U.S. government-funded initiative developed by the software community and managed by the MITRE organization. In its entirety, the CWE list contains over 900 different software and hardware quality and security issues.

These 900+ items are organized in more usable lists such as the well- known CWE Top 25. The Top 25 lists the most common and dangerous security weaknesses, which are all exploits that have a high chance of occurring and the impact of exploiting the weakness is large. The software weaknesses documented by a CWE are the software implicated in a set of discovered vulnerabilities (documented as CVEs) when analysis was performed to discover the root cause. CVEs are specific observed vulnerabilities in software products that have an exact definition of how to exploit them.

The current version of CWE Top 25 is from 2023 shown in the table below. An updated Top 25 is currently in process with improved linking to CVEs and the NVD. Ranking considers real world information so that it truly represents the Top 25 application security issues today. As soon as it is released, Parasoft will have updated support for the latest version.

For software teams that have a good handle on the Top 25, there’s another grouping of the next most common and impactful vulnerabilities called the CWE CUSP. Another way to think of these are the top 25 honorable mentions.

The CWE uses a risk scoring method to rank the Top 25 and on the CUSP. This score takes into consideration the technical impact of a software weakness (how dangerous an exploit of the weakness is in the real world) as measured by the CWSS (Common Weakness Scoring System).

Examples of technical impacts from vulnerabilities may include:

• Denial of service (DoS)
• Distributed denial of service (DDoS)
• Read or write access to protected information
• Unauthorized access and more

The details of these methods aren’t too important, but the sorted list is useful in understanding which vulnerabilities to be concerned about the most. As an example, it’s possible that your application is purely internal, and DoS issues aren’t critical for you. Being able to prioritize on the most important weaknesses for your own application can help overcome overwhelm with static analysis violations.

CWE Top 25 and On the Cusp Compliance

Introducing the coding standard compliance process into the team development workflow isn’t an easy task. As such, it’s important to select a tool that will help in achieving compliance without imposing too much overhead and without the requirement for additional manual procedures. The following points are important decision-making factors when selecting the solution for static analysis.

The CWE Top 25 and its lesser known sibling, on the Cusp, are not coding standards per se but a list of weaknesses to avoid to improve security. To be CWE compliant, a project should be able to prove that it has made reasonable efforts to detect and avoid these common weaknesses.

Parasoft’s advanced static analysis tools for C, C++, Java, and .NET are officially compatible with CWE, providing automated detection of both Top 25 and on the Cusp weaknesses and many more. CWE-centric dashboards give users quick access to standard violations and current project status. A built-in CWE Top 25 configuration is available for C, C++, .NET, and Java with full coverage of all the 25 common weaknesses.

The Parasoft tools include information from the Common Weakness Risk Analysis Framework (CWRAF), such as technical impact, so you can benefit from the same type of prioritization based on risk and technical impact and weaknesses found in your own code.

Parasoft also supports detailed compliance reporting to streamline audit processes. The web dashboards provide the link to compliance reports for a complete picture of where a project stands. In addition, the CWE Weakness Detection Plan maps the CWE entry against the checkers that are used to detect the weakness. This helps illustrate how compliance was achieved to an auditor, and the audit reports are available to download as PDFs for easy reporting.