
The CERT C Secure Coding Standard - jfe
https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Coding+Standard
======
khaki54
Some of these are pretty interesting though. For instance, "avoid using
repeated question marks". How is this a problem? Well you can pretty easily
turn something as harmless as a comment into something that absorbs the next
line of code. Good luck debugging that one.
[https://www.securecoding.cert.org/confluence/display/seccode...](https://www.securecoding.cert.org/confluence/display/seccode/PRE07-C.+Avoid+using+repeated+question+marks)

~~~
jacquesm
I've been programming C for 3 decades+ and that would have _so_ bitten me, I
had no idea about that. Luckily I avoid double question marks in code comments
anyway (question marks in comment are more like mental notes to yourself
during the phase where you try to make sense of some codebase, if things work
out they should disappear anyway).

Learn a new thing every day.

------
c0rtex
You might also be interested in the MISRA C coding standard, which is geared
towards reliability and safety rather than security. The MISRA C standard is
fairly strict and mostly (but not entirely) machine checkable.

There was a Usenix talk on developing code for Mars rovers in which Gerard
Holzmann pointed out that for large projects coding standards are much more
effective when you have automated compliance checking.
[https://www.usenix.org/conference/hotdep12/workshop-
program/...](https://www.usenix.org/conference/hotdep12/workshop-
program/presentation/holzmann)

I note that there is a tool for checking the CERT rules called Rosecheckers:
[http://www.cert.org/secure-
coding/tools/rosecheckers.cfm](http://www.cert.org/secure-
coding/tools/rosecheckers.cfm)? It looks like it might be incomplete and/or
outdated.

And the CERT pages include a reference to a deleted summary of other automated
checkers such as Coverity and Klockwork:
[https://www.securecoding.cert.org/confluence/display/seccode...](https://www.securecoding.cert.org/confluence/display/seccode/VOID+Automated+Detection+Tools)

------
azurezyq
Actually it's hard to obey them all. And C makes it so easy to create
pitfalls. Is there a language specially designed for secure programming?

~~~
borplk
Ada and SPARK power many safety critical things like airplanes fighter jets
space rockets railways and so on.

I've been recently trying to learn Ada and it's a beauty. Many people have
misconceptions or think it's obsolete so they miss out.

~~~
hga
As I understand it having looked into Ada and SPARK (an Ada subset), there are
no good free runtimes for them, i.e. ones to do serious projects with, vs.
learning and open source development. That came from my investigation of this
kernel: [http://muen.codelabs.ch/](http://muen.codelabs.ch/)

------
jokoon
Can C code be linted according to those rules?

I wonder if that kind of coding standards can be part of ISO standards.

~~~
rcseacord
We did actually produce ISO/IEC TS 17961:2013 Information technology --
Programming languages, their environments and system software interfaces -- C
secure coding rules
[http://www.iso.org/iso/catalogue_detail.htm?csnumber=61134](http://www.iso.org/iso/catalogue_detail.htm?csnumber=61134)

The rules specified in this Technical Specification apply to analyzers,
including static analysis tools and C language compiler vendors that wish to
diagnose insecure code beyond the requirements of the language standard. All
rules are meant to be enforceable by static analysis.

I wrote an article putting all this in some context at:
[http://www.informit.com/articles/article.aspx?p=2088511](http://www.informit.com/articles/article.aspx?p=2088511)

------
mkpankov
I investigated this Standard once.

See
[https://www.securecoding.cert.org/confluence/display/seccode...](https://www.securecoding.cert.org/confluence/display/seccode/EXP05-C.+Do+not+cast+away+a+const+qualification)
and exception EXP05-EX3 in particular.

Exception promotes non-standard-compliant (undefined) behavior because it
"usually works".

~~~
rcseacord
BudVVeezer and bgtnhz have already made some of my points for me. "EXP05-C. Do
not cast away a const qualification" is a recommendation largely because
casting away constness isn't undefined behavior. There is a also a rule
"EXP40-C. Do not modify constant objects" which defines a normative
requirement not to modify constant objects which would result in undefined
behavior. The intent of the exception to EXP05-C is to let authors of API
constrain how objects of types they expose can be used by users without
forcing the same constraints on the implementation. In C++, this can be done
by making class members private and providing inline member functions. In C,
the options are using opaque types (which has a performance cost because they
can only be accessed by non-inline functions defined in the implementation's
.c files), or making the struct pointer members const and casting the const
away in inline functions. This is safe because the implementer knows that the
objects the const pointers do not point to const objects (because the
implementation initialized them). We're considering getting rid of the
exceptions and risk assessments for recommendations because it suggests that
conformance to recommendations is required.

------
pjmlp
Should be compulsory reading for any developer.

Not only C, but the other CERT standards as well.

~~~
tormeh
Having a CERT standard seems to speak poorly of a language. I'm a little
surprised Java has one.

~~~
pjmlp
Perl and Python are also getting one.

Java luckily doesn't suffer from use after free, out of bounds, stack
corruption, return oriented programming, dangling pointers.

A memory safe language is still open to parameter validation, races to data
access in external resources, validation of external data, incorrect use of
security certificates, configuration exploits and many more.

Getting rid of C style bugs is only the tip of the iceberg in security.

------
skrebbel
I'm well aware this is full-on "middlebrow dismissal", but still, I feel that
in 2015 this standard isn't complete without a chapter saying

    
    
        just don't.
    

somewhere.

I understand why a standard like this is necessary, but really it's like a
CERT Safe Highway Cycling Standard or a CERT Healthy Smoking Standard. If
security is an important enough goal to want to apply this entire standard in
detail, maybe there are better options than C.

~~~
JulianMorrison
Two use cases where C is often the only choice are OSes and micro-controllers.

~~~
demiraven
Indeed. C (and, to a limited degree C++) are natural choice(s) for embedded
and low-level development.

In embedded, there may be other language choices for coding "close to the
metal", but they are rarely used, time-costly to work with, and often not
well-supported for all platforms. Most micro-controller vendors supply their
board-support packages (BSPs) in C, and choosing some other family of (higher
level than assembly) language can result in some rather high development costs
with few if any benefits in terms of code space or system efficiency.

Not to mention many higher-level languages (and, at least, their compilers or
interpreters) are implemented in C (or C++) - Ruby, Python, Lua, etc. Even if
one works on desktop applications or web development, C has importance, very
likely, at some level in the technology stack.

Those that dismiss C either misunderstand the importance and ubiquity of it as
a language and/or inadvertently expose their prejudice towards development at
higher levels of abstraction. In any case, C is very likely here to stay, good
to know well, and good to know how to code more securely.

