As security is becoming a more important topic for developers of embedded systems – especially connected embedded systems and IoT (Internet of Things) devices – so to are the standards and expectations for those software managers and software developers producing the embedded software.
New cybersecurity standards for embedded systems
This growing focus on secure coding practices and ensuring that code is not susceptible to dangerous software vulnerabilities, is evidenced by the arrival of a host of new industry-specific cybersecurity standards; like ISO/SAE 21434 for automotive embedded systems, IEC 81001 (Part 5-1) for healthcare software, including medical devices, and before those IEC 62443 for industrial automation devices.
Although these new standards – ISO 21434, IEC 81001-5-1 and IEC 62443 – all target their own specific industries and the unique requirements and needs for the cybersecurity landscape in those sectors, they all ultimately have one thing in common when it comes to secure code development: the requirement for secure coding standards to be used.
Secure coding guidelines
Security focused coding standards have been around for some time. Standards like:
OWASP
The OWASP (Open Web Application Security Project) Top 10, is published every four years (last published in 2021 – OWASP Top10 2021) listing the most dangerous or impactful security vulnerabilities affecting web and mobile applications of the time, although the use often also extends to both enterprise and embedded systems. The OWASP coding guidelines are programming language agnostic, though obviously focused on the kinds of languages – like Java and Javascript – that are regularly seen in the web and mobile application space.
CERT
The CERT standards (CERT C, CERT C++ and CERT Java) are a rather more extensive list of key security vulnerabilities that are language specific, as the names imply, and tend to have a more embedded focus. CERT C and CERT C++ were last officially published by Carnegie Mellon University in a 2016 printed publication. However, updates to these standards and the newer CERT Java standard exist on the CERT wiki.
MISRA C:2012
Even the MISRA group got in on the secure coding standard act with the MISRA C:2012 coding standard Amendment 1 (Amd. 1), which added security focused rules to the existing MISRA C standard, originally focused on reliability, readability, and maintainability of the code as a driver to developing safer C code. The modifications and extensions provided by MISRA C:2012 Amd. 1 took MISRA C from a functional safety focused set of coding guidelines to a safety and security focused coding standard.
MISRA C:2012, along with CERT C are the most widely recommended – by functional security standards like ISO 21434 and IEC 81001 – coding standards for secure embedded software development.
CWEs
Lastly, although is it not a coding guideline per-se, the CWE (Common Weakness Enumeration) list of software vulnerabilities is a wonderful catalogue of possible coding defect types that will lead to security risks, across all manner of different programming languages and with a hierarchical structure of vulnerability classes.
The CWE list in full accounts for over a thousand vulnerability types, and not all vulnerabilities apply to all programming languages, so it is a little unwieldy as a coding guideline. However, subsets of CWEs are valuable as coding guidelines, and CWEs are also provided in an annual Top 25 list of the 25 most frequently occurring issue types identified in CVEs () within the NVD (National Vulnerability Database) maintained by NIST ().
CVEs, which represent specific instances of vulnerabilities occurring in specific applications or libraries, should not be confused with CWEs, which define the categories of issues that specific CVEs fall under. And note that it is a many-to-many relationship between the two, since many CVEs will fall under a single CWE category of vulnerability, but also a single CVE may have multiple CWE categories.
Enforcing and reporting coding standard compliance
Deciding on the coding standard or guidelines to use is the first step to creating more secure code. However, the next task then is to ensure that this coding guideline is enforced (consistently) across the development team or organisation.
Enforcing coding guidelines can be an arduous task. Traditionally, coding rules and conventions were enforced as part of the code review process, where developers review one another’s code. However, with standards like CERT or MISRA, which contain hundreds of rules – a lot for a code reviewer to remember – and the likelihood of inconsistencies between reviewers in what is considered an infringement or even relevant, manual code reviews are not really the best mechanism for this task.
Luckily, static code analysis tools – often referred to as SAST (Static Application Security Test) tools when applied in a security context – are VERY good at enforcing rules, consistently and universally, and are also far quicker than a human reviewer.
Static analysis tools – like Understand by SciTools Code check and Klocwork and Helix QAC from Perforce – provide an automated solution for coding standards enforcement, potentially then used as a basis for an assisted code review process.
Finally, it is not only necessary to enforce a coding standard in most cases, but also it is necessary to report the level of compliance and any exceptions for the purposes of proving compliance. So, static analysis tools that are used must also be able to provide this evidence in a format that can then be used externally.
Great! How do I get started?
Please contact us if you would like to have a free trial of Understand by SciTools or Perforce Static Analysis tools to get enforcing your chosen secure coding guidelines today!