October 17
34
t
ooLs
& s
oFtwArE
Automatic enforceability:
the ease of creation
of automatic checks for the guidelines that
don’t result in false positives. This is usu-
ally related to how strictly or loosely specific
guidelines are defined.
Coverage:
a qualitative indication of the
breadth of the coding standard scope and the
number of guidelines defined. The broader
the scope, the higher the educational value
of the coding standard, but a broad scope can
also bring complexity in terms of guideline
maintenance and tool coverage.
Market adoption:
the level of usage of the
coding standard for real-world projects, in
terms of formal compliance requirements
(for example in functional safety applica-
tions) and voluntary usage to improve overall
software quality.
Tool availability:
the market availability of
an automated code analysis tool to enforce
the coding standard. This tends to be
linked with the standards level of market
adoption.
Evolution:
a quickly evolving standard adapts
better to feedback from the users and pro-
vides faster introduction of new features.
This can be considered good for consumer
products but bad for other sectors. CERT C
uses two methods for publishing its guide-
lines; a web-based wiki, and a PDF document
freely available. The wiki evolves faster than
the latter.
Resources:
this can include references to the C
language standard, to other standards, papers,
articles or other common knowledge bases
that may be helpful.
Examples:
descriptions to illustrate the issues
related to the violation of a specific guideline
and compliant solutions. The following page
shows a comparison table covering the three
featured coding standards and how they per-
form in the above categories.
There is no single best standard for secure
coding. Selection must consider many differ-
ent aspects, such as the duration of the proj-
ect (where stability of the reference is more
important), the version of the language being
used and the existence of legacy code. The
simple flow chart in figure 1 can help to make
an informed choice.
Scenario 1.
If the requirements dictate com-
pliance with a recognized coding standard
(a typical scenario would be a safety-critical
application) then the choice should be MISRA
C. The latest version of this standard is MISRA
C:2012 Amendment 1. If a previous version
of MISRA is mandated (for example MISRA
C:2004) then the project will benefit from the
addition of the security rules provided by ISO/
IEC 17961:2013 (some work will be required
to match the C version and remove any overlap
– a good footprint would be the Addendum 2
of MISRA C:2012 “Coverage of MISRA C:2012
against ISO/IEC 17961:2012 C Secure”).
Scenario 2.
If the application has no com-
pliancy requirements, and if there are no
high-performance needs that would sacrifice
code portability it is still recommended to
adopt a high integrity perspective. In this case
the recommendation would also be to use
MISRA C:2012.
Scenario 3.
In both previous scenarios CERT
C could offer valuable support from a secu-
rity perspective, and the recommendation
would be to adopt CERT C in parallel with
the suggested standards (in the flow chart
this is indicated by a dashed line). However,
if a high-integrity approach is not taken the
MISRA C:2012 standard could be seen as too
restrictive for the specific application, in this
case the recommendation would be to only
apply CERT C in order to achieve a good level
of code security.
Choosing the right coding standard to adopt
when developing secure code will depend
on many factors, such as an understanding
of the features and benefits of each standard
and how they could meet the requirements of
the current development project. The process
shown in this article focuses on the ability to
perform automated testing with tools such
as PRQA static analyzers QA·C and QA·C++.
Such tools perform deep analysis of software
code to prevent, detect and eliminate defects
and automatically enforce coding rules to
ensure standards compliance.
((Comparison Table))
CERT C
MISRA C:2012
ISO/IEC
17961:2013(E)
1 – Industry
Generic-
agnostic
Embedded
safety-critical
applications
Generic-
agnostic
2 - Reference
Language Version
C11
C90, C99
C11
3 - Automatic
Enforceability
4 – Coverage
5 - Market Adoption
6 - Tool Availability
7 – Evolution
Wiki
Book
8 – Resources
9 – Examples
There is no single best standard for secure coding. Selection must consider many
different aspects, such as the duration of the project (where stability of the reference is
m re important), the version of the language being used and the existence of l gacy
code. The simple flow chart in figure 1 can help to make an informed choice.
Scenario 1. If the requirements dictate compliance with a recognized coding standard (a
typical scenario would be a safety-critical application) then the choice should be MISRA
C. The latest version of this standard is MISRA C:2012 Amendment 1. If a previous
version of MISRA is mandated (for example MISRA C:2004) then the project will benefit
from the addition of the security rules provided by ISO/IEC 17961:2013 (some work will
be required to match the C version and remove any overlap – a good footprint would be
the Addendum 2 of MISRA C:2012 “Coverage of MISRA C:2012 gainst ISO/IEC
17961:2012 C Secure”).
Scenario 2. If the application has no compliancy requirements, and if there are no high-
performance needs that would sacrifice code portability it is still recommended to adopt a
Figure 3. Comparison table of CERT C, MISRA C: 2012, and IEC/ISO 17961:2013
START
Compliancy
requirements
High Integrity
application?
YES
NO
Demonstrate
compliance?
C99 used?
YES
NO
NO
YES
Figure 1. This simple flow chart helps to make an informed choice.
Legend:
high integrity perspective. In this case the recommendation would also be to use MISRA
C:2012.
Scenario 3. In both previous scenarios CERT C could offer valuable support from a
security perspective, and the recommendation would be to adopt CERT C in parallel with
the suggested standards (in the flow chart this is indicated by a dashed line). However, if
a high-integrity approach is not taken the MISRA C:2012 stan ard could be seen as too
restrictive for the specific application, in this case the recommendation would be to only
apply CERT C in order to achieve a good level of code security.
Choosing the right coding standard to adopt when developing secure code will depend on
many factors, such as an understanding of the features and benefits of each standard
and how they could meet the requirements of the current development project. The
process shown in this article focuses on the ability to perform automated testing with
tools such as PRQA static analyzers QA·C and QA·C++. Such tools perform deep
analysis of software code to prevent, detect and eliminate defects and automatically
enforce coding rules to ensure standards compliance.
((Bildunterschriften))
((Bild 1, PRQA-Aufmacher.pptx))
Legend:
Strongly recommended
Loosely recommended
Figure 1. This simple flow chart helps to make an informed choice.
((Bild 2, PRQA-Tabelle.pptx))
Figure 2. Comparison table of CERT C, MISRA C: 2012, and IEC/ISO 17961:2013 €
Strongly recommended
d
and how they could meet the requirements of the current deve
Loosely recommended
