83 / 92
83
EMBEDDED
66 • NOVEMBRE • 2017
SAFETY SECURITY |
SOFTWARE
[xU
À
strategia. Tali strumenti eseguono approfondite
analisi del codice software per prevenire, rilevare
ed eliminare i difetti e applicare automaticamente
À
standard.
[
"
À
-
ta manutenibilità del software e quindi della ridu-
zione dei costi complessivi di sviluppo.
7
À
+
_&
critical ottimizzando al contempo anche la sicurez-
richiedono un insieme di strategie, processi, stru-
menti e competenze che possono non sovrapporsi
Á
-
menti di analisi automatizzata del codice sono un
À
À
possono portare a problemi e a vulnerabilità sia
della sicurezza sia della protezione, come parte di
un approccio olistico.
Tabella 1 – Un rapido confronto tra MISRA e CERT C
MISRA C:2012
CERT C
Analisi
Restrizioni (gruppo di lavoro)
Aperto e pubblico (web)
Struttura
143 Rules / 16 Directives
Le Rules sono linee guida per le quali è stata fornita una
descrizione completa dei requisiti.
Le Directives sono linee guida per le quali non è possibile fornire
la completa descrizione necesaria per eseguire una verifica
della conformità.
98 Rules / 178 Recommendations
Le Rules sono definite in base a tre criteri:
1. La violazione delle linee guida è probabile diventi un difetto
della sicurezza.
2. Non si basano su annotazioni al codice sorgente o su ipotesi
di intenti del programmatore.
3. La conformità alle linee guida può essere determinata
mediante analisi automatica, metodi formali, o ispezione
manuale.
Le Recommendations sono definite in base a due criteri:
1. La loro applicazione è verosimile che migliori la sicurezza,
l’affidabilità o la protezione dei sistemi software.
2. Uno o più dei requisiti da indicare come Rule non possono
essere soddisfatte.
Applicazione
La formulazione delle Rules è orientata verso una applicazione
automatizzata.
Es.: Rule 8.14 “i Qualifier riservati non dovranno essere utilizzati”
La formulazione delle Rules è appena più generica.
Es.: EXP43-C: “Nell’utilizzare i puntatori restrict-qualified vanno
evitati i comportamenti non definiti”
Organizzazione
Per settori di linguaggio e ambiente:
“The Implementation”, “Compilation and build”, “Requirements
traceability”, “Code design”, “A standard C environment”,
“Unused code”, “Comments”, “Character sets and lexical
conventions”, “Identifiers”, “Types”, “Literals and constants”,
“Declarations and definitions”, “Initialization”, “The essential
type model”, “Pointer type conversions”, “Expressions”, “Side
effects”, “Control statement expressions”, “Control flow”, “Switch
statement”, “Functions”, “Pointers and arrays”, “Overlapping
storage”, “Preprocessing directives”, “Standard libraries” and
“Resources”.
Per elementi di linguaggio di basso livello:
“Preprocessor (PRE)”, “Declarations and initialization (DCL)”,
“Expressions (EXP)”, “Integers (INT)”, “Floating Point (FLP)”,
“Arrays (ARR)”, “Characters and strings (STR)”, “Memory
management (MEM)”, “Input/Output (FIO)”, “Environment (ENV)”,
“Signals (SIG)”, “Error handling (ERR)”, “Application Programming
Interfaces (API)”, “Concurrency (CON)”, “Miscellaneous (MSC)”,
“POSIX (POS)”, “Microsoft Windows (WIN)”.
Severity
classification
Liberamente collegato alle proprietà di “Category” della Rule:
• Mandatory (nessuna deroga ammessa)
• Required (deroghe consentite)
• Advisory (processi di deroga formale non richiesti)
Approccio basato sulla valutazione dei rischi. Ogni linea guida ha
una priority come prodotto di severity, likelihood e remediation
cost (ciascuno di essi con un valore in una scala da 1 a 3).
La gamma di priorità definisce il legame con uno dei tre livelli
possibili:
L1 -> Priorities 12, 18, 27 (elevata severità)
L2 -> Priorities 6, 8, 9
L3 -> Priorities 1, 2, 3, 4 (bassa severità)
Procedura
di deroga
Formalizzato: richiede l’indicazione della linea guida da cui si
è derogato, le circostanze in cui è consentita la deroga, la
motivazione della deroga, una valutazione del rischio derivante
(dimostrazione di come la sicurezza è ugualmente assicurata,
ulteriori prove richieste ecc.) ed è necessaria una approvazione
formale.
Limitata: è possibile derogare solo da Rules di tipo Advisory e
Required.
Non c’è alcuna descrizione di un formale processo di gestione
per le deroghe, anche se sono menzionati come un modo per
sopprimere i veri e veri-positivi dimostratamente innocui o che
sono in accadimento sulle scelte architetturali non previste dallo
standard.