Die meisten Prinzipien, die für die funktionale Sicherheit (Safety) von Code gelten, lassen sich auch auf die Security-Eigenschaften des Codes anwenden, denn gut geschriebener Code ist von sich aus sowohl »safe« als auch »secure«.
Eine häufig ausgenutzte Sicherheitslücke sind sogenannte Pufferüberläufe. Hier übersteigt der Umfang der an einen Speicherbereich geschriebenen Daten die Größe des tatsächlich zugewiesenen Speichers. Hacker können sich dieses Verhalten zunutze machen, um geschützte Speicherbereiche zu überschreiben und dadurch die Programmverarbeitung zu beeinflussen oder selbst entwickelten Schad-Code einzuschleusen. MISRA C trägt diesem Szenario in Abschnitt 8.18 (Pointers and Arrays) mithilfe von Regeln Rechnung, die für Safety und Security gleichermaßen relevant sind.
Zum Beispiel besagt Regel 18.2 in MISRA C:2012: »Ein Zeiger, der aus einer Berechnung an einem Zeigeroperanden resultiert, hat dasselbe Array zu adressieren wie dieser Zeigeroperand.« Hierzu folgt nun ein Beispiel in diesem Kontext.
Dieser Code kann zu einem Pufferüberlauf führen, da die Länge der ankommenden Nachricht pMessage nicht validiert wird.
extern uint8_t buffer[16];
Ein statischer Code-Analyzer würde dies gemäß der gerade angeführten Regel als Verstoß gegen MISRA C melden. Ist dieser Fehler aufgedeckt, können Entwickler das Verhalten durch Bounds-Checking (Überprüfung der Feldgrenzen) und mithilfe eines Error-Handlers für pMessage korrigieren.
Wo immer es sinnvoll ist, enthalten die MISRA‑C-Guidelines auch explizite Richtlinien für sicheres Codieren – sicher im Sinne von »secure« –, um Entwicklern zusätzliche Hilfestellung bei der Vermeidung unsicherer Programmierpraktiken zu bieten. Statische Analyse-Tools wiederum implementieren eine klare Analysemethode zum Aufdecken potenzieller Schwachstellen.
Ein Beispiel für eine Richtlinie dieser Art wäre dies: »Die Gültigkeit von Werten, die aus externen Quellen bezogen werden, ist zu prüfen« (MISRA C:2012, Direktive 4.14). Tatsächlich ist das Validieren jeglicher Daten, die aus einer externen Quelle wie etwa einer RS-232-Schnittstelle, einer benutzerseitigen Eingabe oder einem anderen Bereich stammen, die bei Weitem wichtigste sichere Codierpraxis. Dies impliziert die Notwendigkeit von »defensivem« Code, um fortlaufend nicht nur zu überprüfen, dass die empfangenen Daten innerhalb der erwarteten Grenzen bleiben, sondern auch sicherzustellen, dass die Daten einen Sinn ergeben. Zum Beispiel kann eine Auflistung der über die Zeit empfangenen Befehle Aufschluss über etwaige von der Norm abweichende Nutzungsmuster geben.