Secure coding standards (security)

The table "Designs and Coding Standards of IEC 61508-3" lists software design techniques that are recommended (Recommended - R) or strongly recommended (Highly Recommended - HR) for certain SILs. © Parasoft

Writing secure code means that the written code is not vulnerable, i.e. it does not have any potentially exploitable vulnerabilities or security gaps. In addition, the written code must have certain secure patterns (in the sense of "safe") and avoid insecure patterns. These patterns differ from one programming language to another. There is no set of "golden rules" that, if followed, guarantee the security of the software. Some widely used coding standards take the safety aspect into account:

• For the C language: MISRA C and SEI CERT C coding standard,
• For the C++ language: MISRA C++ and JSF AV C++ coding standards, SEI CERT C++ coding standard, AUTOSAR C++ coding guidelines (see glossary at the end of the article).

Proven procedures

When it comes to securing the code, it is important to make the right choice. If the software must be certified according to a specific functional safety standard (e.g. ISO 26262 for automotive or DO-178C for aviation applications), the first decision has already been made. Regardless of this, however, a decision must be made on the coding standard(s) or subset of the standard that the developed software must comply with. This can (but does not have to) be one of the standards mentioned above.

The next step is to select a suitable static analysis tool because it is not possible to verify compliance with all these rules manually. Both open source and commercial static analysis tools are available. Here are some selection criteria:

• Is the selected coding standard(s) fully or partially supported by the tool?
• If the functional safety standard in question requires tool qualification, ask if the tool is certified and if it provides the qualification kit?
• Can the tool provide the analysis reports in the form required for the conformity analysis?
• Can it generate the analysis reports in a form that is easy for developers to read?
• Does the tool integrate smoothly with the IDEs, build and CI systems used?
• Does it allow selective analysis of new, changed or existing code?
• Does the tool support flexible configuration of the analysis?
• Does the tool use risk scoring algorithms to help prioritize the defects found?

In addition, the CWE community runs the CWE Compatibility and Effectiveness Program, a formal testing and evaluation process for a product or service. The list of products and services that are classified as "Officially CWE-Compatible" currently comprises 55 entries. If the selected tool is on this list, this ensures that it has reached the final stage of the MITRE organization's formal CWE Compatibility Program.

Once you have defined the coding standard and the necessary tools, the rest of the work for software projects started from scratch should be easy: Just integrate the tool into the CI system and make sure that no defect is left unconsidered.

The individual standards sometimes contain a large number of rules. To facilitate an overview, the rules in the standards are normally divided into several categories. © Parasoft

As a rule, however, coding standards must also be enforced for software that is already under development. Then blindly running the analysis with the entire code base can lead to hundreds of defect messages that are difficult to handle in their entirety. Fortunately, the market offers several techniques to simplify this process.

It is advisable to concentrate on the newly written or modified code first. This prevents new defects from arising after the coding standard has been set up. Another tried and tested procedure is to classify the reported defects according to their importance, so that the most serious defects are processed first.

There is a risk assessment for the CERT-C and CERT-C++ rules, which enables a simple prioritization of the errors found. © Parasoft

A prioritized list of defects in combination with the configurable list of rules to be enforced is helpful to focus on the rules with the highest severity first and expand the number of rules after the most serious defects have been fixed.

The best static analysis reports are useless if the developers do not use them to fix the code. That is why it is most important to ensure that the development team follows up the analysis with appropriate measures - as a prerequisite for better software in terms of safety and security.

Michal Rozenau, Project Lead Engineer at Parasoft / ag

Literature

[1] Hicken Arthur, Parasoft, Embedded Cybersecurity Through Secure Coding Standards CWE and CERT

1. MITRE Corporation, Common Vulnerabilities and Exposures (CVE)
2. MITRE Corporation, Common Weakness Enumeration (CWE)
3. IEC, IEC 61508-3:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements
4. ISO, ISO 26262-6:2011(en) Road vehicles - Functional safety - Part 6: Product development at the software level
5. Carnegie Mellon University, SEI CERT C Coding Standard
6. Carnegie Mellon University, SEI CERT C++ Coding Standard

Glossary:

CVE Numbering Authorities (CNAs) are various organizations (including vulnerability researchers, product vendors, and bug bounty programs that offer a bounty for the discovery of bugs) around the world that have the authority to assign CVE IDs to identified issues.

MISRA C and MISRA C++ were developed by the MISRA (Motor Industry Software Reliability Association), while the AUTOSAR C++ coding guidelines were developed by the AUTOSAR (AUTomotive Open System ARchitecture) development partnership. Lockheed Martin Corporation is responsible for the development of the JSF AV C++ coding standard. The SEI CERT C and C++ coding standards contain general rules designed to ensure the safety, reliability and security of software systems developed in the C and C++ programming languages.