These notes will assume you’re a fairly capable C++ programmer. In particular, you should already know:
Back in the day, 1998 that is, there was MISRA C, coding standards for safety, security, and more, with a focus on embedded systems programmed in C.
Then C++ really started to take off.
In 2005, the JSF C++ Coding Standards, was released, using the MISRA-C:1998 as a starting point.
The idea was to prohibit programmers from doing certain things that were problematic. To follow the JSF guidelines, you must follow 200+ rules. Here are some of them:
errno, offsetof, setlocale, setjmp, longjmp, <signal.h>, <stdio.h>, atof, atoi, atol, abort, exit, getenv, system, <time.h>public section must come before the protected section which must come before the private section.Many of the rules are stylistic only and don’t directly address security concerns. However, the more pristine the source code, the easier it is to spot potential security issues.
Let’s examine some of the rules and look in detail at the rationales provided for each one.We may have some opportunities for a code along!
This video goes over how one can edit code to make it JSF compliant:
But please note: The JSF guidelines are quite old (from 2005) and some of the rules are no longer relevant to modern C++. The guidelines have largely been superseded by more recent and comprehensive standards like CERT C++ and the C++ Core Guidelines. But they are an important part of security history!
MISRA C++:2008 arrived in 2008.
The The SEI CERT C++ Coding Standard is a work-in-progress document from the Software Engineering Institute at Carnegie Mellon. (Before diving into it, you might want to check out this short blog post about the SEI guidelines.)
The Standard is organized into a number of Guidelines, divided into Rules and Recommendations, grouped into sections numbered and titled as follows:
Rules vs. RecommendationsRules are basically requirements that if violated will almost surely result in an exploitable vulnerability. They are generally in principle checkable by static analysis tools (or by a competent human code reviewer). Recommendations basically improve software quality, but violations are not necessarily defects.
The online standard has a page listing all of the rules. As of early 2026, the standard does not have any published recommendations; they were removed in 2019 pending a review. Who knows when they will be back.
We’re going to browse a few of these guidelines!
The Standard C++ Foundation maintains a wiki called the C++ Super-FAQ, and on this wiki there’s a very helpful page on coding standards.
Coding standards are helpful for security.
The foundation recommends:
They also recommend avoiding old or ad-hoc coding standards. Many standards out there just pile some stuff on top of C, or are just so old they don't even understand Modern C++. Interestingly, the foundation did not call out CERT C++ as a recommended guide, nor did they recommend the Google C++ Style Guide.
The sections in the the C++ Core Guidelines cover the usual suspects:
Each section has a number of different items, with rationales, examples, and non-examples. Here’s one of the items from the Philosophy section:
P.1: Express ideas directly in code
This item has examples and non-examples, including:
class Date { public: Month month() const; // good int month(); // bad // ... }; void change_speed(double s) // bad: what does s signify? void change_speed(Speed s) // better: the meaning of s is specified change_speed(2.3); // error: no unit change_speed(23_m / 10s); // meters per second
Wondering about that syntax in the last example?
Sounds familiar right? This is something we’ve been talking about since the beginning of this course. It’s really no surprise that this is the first item in the guide.
Let’s browse these guidelines, and for those that don’t specifically mention security implications, let’s think about how non-examples can lead to vulnerabilities.
In October 2023, MISRA released an updated version of their C++ guidelines, called MISRA C++:2023. It targets C++17, not C++23, since the C++23 was released in 2024, so we’ll have to wait and see what’s next for MISRA.
A couple of interesting frameworks AUTOSTAR (the “the global established standard for software and methodology enabling open E/E system architectures for future intelligent mobility supporting high levels of dependability, especially safety and security”) and JPL’s F Prime (“a component-driven framework that enables rapid development and deployment of spaceflight and other embedded software applications”) have their own coding standards that may be worth a look.
The aforementioned C++ Coding Guidelines, though, will continue to evolve with the language.
Here are some questions useful for your spaced repetition learning. Many of the answers are not found on this page. Some will have popped up in lecture. Others will require you to do your own research.
We’ve covered: