The SEI CERT C coding standard, SEI CERT C++ coding standard, and the SEI CERT Oracle coding standard for Java are coding standards (or more formally, “language subsets”) that can help to ensure that software does not include potential software security vulnerabilities.
The first of these, CERT C, came from an idea that emerged in 2003 from CERT’s discussions with the ISO/IEC JTC1/SC22/WG 14 committee (WG14) responsible for the C language standard.
SEI (full form Software Engineering Institute) is a federally funded pioneer of programming practices, based at Carnegie-Mellon University and supported by the US Department of Defense.
CERT is an acronym referencing the Computer Emergency Response Team division of the SEI.
SEI’s CERT division was formed in response to the Morris worm incident of 1988 and focuses on improving the security and resilience of computer systems and networks. CERT is well respected for its expertise and works closely with organizations from both private and public sectors.
The CERT organization has developed secure coding standards to support a range of high-level languages, including C, C++, and Java.
Although input into the standards is co-ordinated by CERT via Confluence (wiki) sites, their content represents the collective wisdom of the software development and software security communities. For example, CERT works closely with organisations from both private and public sectors including Cisco, Oracle, and the US Department of Homeland Security.
SEI CERT coding standards consist of rules and recommendations that allow developers to avoid target insecure coding practices and undefined behaviours that can lead to vulnerabilities. The standards are constantly under review, with the latest rules and recommendations available online. Recommendations are not compulsory and are provided for information purposes only.
A constantly evolving set of such guidelines would introduce obvious challenges to a protracted development project looking to apply them. To that end, official releases are periodically published online and as hard copies.
CERT C is a set of C secure coding guidelines. It was the first of the CERT secure coding standards to be created. Its roots go back to an idea mooted in a 2006 meeting of the C Standards Committee (ISO/IEC JTC1/SC22/WG14), with the first official release published in June 2008. CERT C consists of rules and recommendations to help reduce the likelihood of vulnerabilities by disallowing vulnerable C language code constructs. In general, these CERT C rules and recommendations are equally applicable to the C++ language. The SEI CERT Coordination Center (CERT/CC) vulnerability notes database details issues discovered in various software systems. There is correlation between any relevant vulnerabilities and the CERT C guidelines for writing secure code in the C programming language
CERT C++ is a set of C++ secure coding guidelines. It has much in common with CERT C which serves as a basis for it. First published as an official release in 2017, CERT C++ builds upon its predecessor by adding additional specific C++ related rules and recommendations – 83 of them at the time of launch. These rules and recommendations are designed to help reduce the likelihood of vulnerabilities by disallowing vulnerable code constructs.
The SEI CERT Coordination Center (CERT/CC) vulnerability notes database details issues discovered in various software systems. There is correlation between any relevant vulnerabilities and the CERT C++ guidelines for writing secure code in the C++ programming language
CERT Oracle for Java follows the same principles initially established in the development of CERT C. First published as an official release in 2011, it identifies and addresses the coding errors most likely to produce security vulnerabilities in Java programs. Like CERT C, it also provides guidelines for avoiding these mistakes.
Each of the CERT rules has an associated risk assessment to quantify the possible consequences of a violation, using a process based on FMECA principles. The calculation involves three parameters (Severity, Likelihood, and Remediation Cost) each of which is ranked on a scale of 1 to 3. The resulting three values are multiplied together to derive a priority value between 1 and 27. Rules are then categorized as level 1,2 or 3 as illustrated.
Project leaders can therefore opt to begin remediation by implementing all rules at a particular level before proceeding to the lower priority rules.
CERT is not the only standards organization to propose approaches to minimize vulnerabilities in source code. Others address the same issue in slightly different ways. The ideal choice will vary from project to project.
MITRE is a US government-funded organization that publishes standards relating to information security, including CWE and CVE.
CVE (Common Vulnerabilities and exposures) is a database that lists and categorizes specific instances of vulnerabilities within products or systems. It collates information from several different vulnerability databases.
CWE (Common Weakness Enumeration) lists and categorises vulnerabilities that have led to the flaws identified within products or systems and listed in CVE.
CWE is therefore a secure coding standard, but not one that is derived from first principles like the CERT standards. It is therefore reactive to vulnerabilities experienced in the field, rather than proactive according to first principles.
The MISRA standards are designed to be “used to develop any application with high integrity or high reliability requirements”. That has always included security-critical applications. Some of the CERT documentation seems to be in error in that regard.
The C and C++ standards from MISRA, like the CERT standards, are designed from first principles. However, the approach used is subtly different in that CERT focus more on application issues, whereas MISRA rules and directives are more targeted at language issues.
The coding rules, recommendations and guidelines specified by both CERT C and MISRA C are designed for use in secure software development, and the correct application of either will certainly result in more secure code than if neither were to be applied. However, MISRA’s stated aim to “…provide world-leading, best practice guidelines for the safe and secure application of both embedded control systems and standalone software” contrasts with the CERT standards’ wider remit.
Other differences include:
Compliance with CERT coding standards helps to:
There are many rules and recommendations in the CERT standards. In theory it might be possible to check their implementation by inspection, but that would be a highly skilled, labour-intensive, and error-prone job. SEI CERT checkers such as those provided by LDRA automate that process by means of static analysis.
The Capability Maturity Model (CMM) is a framework that defines the key elements of an effective software process. It was initially developed for assessing and improving the software development processes within organizations. The CMM provides a structured approach for organizations to gradually improve their processes, moving from ad hoc and chaotic practices to a more disciplined and mature state.
The most well-known version of the Capability Maturity Model is the Capability Maturity Model Integration (CMMI). CMMI was developed by SEI and extended the original CMM to cover areas beyond software development, including systems engineering, project management, and other disciplines.
CMU established the CMMI Institute with the aim of broadening the application of CMMI still further, extending its advantages to companies providing products or services beyond the realms of software and systems engineering. The institute has since been acquired by ISACA.
There are now multiple adaptations of the maturity model offering different focuses. For example, OWASP SAMM (Software Assurance Security Model) is built upon the core business functions of software development. Practices tied to the reduction of security risks are associated with each.
The structured approach for gradual improvement is also reflected in the OWASP SAMM maturity levels:
It is easy to see how the adoption of an SEI CERT coding standard in the development of embedded systems might correlate with these process improvement levels. One approach might be to initially formally adopt rules that are largely followed in the organisation by default, and then progressively adopt more until full compliance is achieved.
The ability to statically analyse software quickly and easily with reference to CERT coding standards delivers tangible benefits to development teams in terms of code quality, consistency, and reduced time-to-deployment. LDRA is committed to supporting all versions of CERT coding standards for C, C++, and Java, and can help with their application in the development of embedded systems in several ways.
Static analysis can be initiated to ensure SEI CERT standards compliance as code is developed, and automatically applied during unit, system, or integration test to ensure that compliance achieved at the outset is not compromised throughout the software development life cycle. All versions of the CERT rules and recommendations are completely integrated into LDRA tools for efficient CERT checking within a familiar development environment.
LDRA static analysis tools locate and highlight areas of non-conformant code to aid documentation and modification. Extensive reports and graphical displays enhance understanding of the source code, facilitating improvements in testability, understandability, and maintainability in line with CERT rules. LDRA static analysis tools also facilitates structural coverage analysis to ensure that software “testedness” is measured and maintained.
The illustration shows a report created following CERT C++ static analysis performed on example C++ code:
The which tools are right for me? wizard will help to identify the most appropriate option.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707
