In that case, why is it repeating material out of ISO C instead of just referring to ISO C as a base document for all those points.
You can summarize it all in one item:
"A program fails to conform to the CERT standard for secure coding if it violates any of the following 'undefined behavior' situations explicitly described in ISO C, or implicitly by omission: [give a summary list with brief descriptions and section references]"
I can't answer for the the people who wrote it. What you could do is put together a few questions and send them an email. Or look around the wiki.
Just for future reference when you quote put the page number or section so people can look it up and see the context.
From my experience expert arguments about C end with a reference to the C standard. The C standard is authoritative. If you can quote the standard to back up your argument you win. Arguing C/C++ is different from most other languages in that respect because we have an official ISO standard and expert C/C++ programmers take the standard very seriously.
The language of the C standard is very terse and hard to read for most people. (myself included) And a lot of the issues are very subtle. As a result anyone quoting the C standard starts to adopt the C standard style of language and idiom. So you get some arguments and documents like CERT that end up being kind of hard to read and terse also. I have read some arguments where I have to open the standard to read the argument because its essentially two people quoting the standard arguing about the correct meaning of a particular passage.
If they give a section reference to the C standard the purpose is to be authoritative. So that people reading it can look those up in the C standard and know that they are official undefined behaviors. There are lots of arguments about specific undefined behavior. And the only way to settle the dispute is to refer to the standard to see if the behavior is actually an official undefined behavior or someone who is making there own judgment which is usually wrong if its not backed up by the standard.
I don't mean that they are repeating material verbatim out of ISO C as a quote; they are wastefully reinventing it in their own words.
A secure coding standard form CERT should focus entirely on describing conventions and program properties that do not already follow from the standard as a matter of correctness.
For instance, it's a security problem if, say, we manipulate sensitive data and then don't wipe the memory. That does not violate ISO C in any way.
A perfectly ISO C and POSIX conforming application could have a race condition with regard to a symbolic link. Or some time-of-check-to-time-of-use (TOCtoTOU) race.
A perfectly ISO C and POSIX application could do something stupid with permissions.
Creating a listening socket for local use and not restricting it to the loopback address (like 127.0.0.1 on IPv4) should fail a security review.
There are all kinds of things that either follow from the language and API documents in very non-obvious ways, or not at all.
Not initializing an object and then using it falls into a catch-all bucket of "language violation" that can be covered in a paragraph or two.
> A secure coding standard form CERT should focus entirely on describing conventions and program properties that do not already follow from the standard as a matter of correctness.
from CERT 1.7
"The wiki also contains two platform-specific annexes at the time of this writing; one annex for POSIX and one for Windows. These annexes have been omitted from this standard because they are not part of the core standard."
So while the CERT does use some examples from system interfaces its not a standard for programming the system interfaces for POSIX or Windows. It looks like there trying to limit the standard to ISO C. The examples you gave fall into the system interface category. POSIX is huge and the same for Windows, much bigger then ISO C.
I think in order to explain conventions for a system interface you really need a longer form publication like a book. So you can take 50 pages to describe an interface and how to use it and show examples etc.
The best way that I have found to figure this stuff out is the standard way. You get a copy of all the relevant standards as a foundation, ISO, POSIX, Window and stuff like CERT. Then you you get some of the system programming books (listed below). Then you find get some good reference code that show best practice. usually code from the operating system or utilities. Lastly read all the compiler docs and tool docs to set up the best code analysis framework you can.
These are a few system programming books that I use.
edit: I'm not sure your skill level, you may have seen all of those but I posted them regardless. There is a lot of security and convention in those books.
You can summarize it all in one item:
"A program fails to conform to the CERT standard for secure coding if it violates any of the following 'undefined behavior' situations explicitly described in ISO C, or implicitly by omission: [give a summary list with brief descriptions and section references]"