On Wed,  6 Sep 2006 08:22:22 CST, "kanze" <kanze@gabi-soft.fr> wrote:

>Beman Dawes wrote:
>
>> Naive imperative coding standards like these do a disservice
>> to programmers.
>
>I would agree here only if I found the coding guidelines in
>question naive.  (That was my first impression, but I haven't
>studied it enough to make any real judgement.) In critical code,
>some imperative coding standard is almost a necessity (not that
>it guarantees correct code, but it can greatly improve the
>chances that incorrect code is identified in code reviews and
>such).

Could you please provide some examples? (I think we would better
continue on comp.lang.c++.moderated, by the way; please, consider
following up there)

--
Gennaro Prota

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Wed,  6 Sep 2006 19:02:37 GMT, fwl@sei.cmu.edu (Fred Long) wrote:

>But what you see so far is just a start.

I consider it too bad even as a start :-/ In any case I think that
status quo should be adequately pointed out in a well-visible
disclaimer.

>The point of developing the Secure Coding Standard as a Wiki is that
>the whole community can help to produce something really worthwhile.

Honestly I find that difficult to happen. Your licensing terms aren't
certainly encouraging, and even Wikipedia, which has IMHO a much
fairer license, has grave problems with programming articles in
general.

--
Gennaro Prota

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Fred Long wrote:
> The CERT/CC has just deployed a new web site dedicated to developing
> secure coding standards for the C programming language, C++, and
> eventually other programming language.
>
> We have already developed significant content for the C++ programming
> language that is available at:
>
> https://www.securecoding.cert.org/
>
> by clicking on the link:
>
>       "CERT C++ Programming Language Secure Coding Standard"

Naive imperative coding standards like these do a disservice to
programmers. In the real world, few coding practices apply to every
case. There are always special cases that need to be handled differently.

For example, MSC00-A, Declare data members private, fails to mention any
cases where the guideline doesn't apply. Yet Sutter and Alexandrescu in
their well-considered "C++ Coding Standards", list value aggregates and
testing code as two cases where such information hiding isn't applicable.

--Beman Dawes

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Beman Dawes wrote:
> Fred Long wrote:
> > The CERT/CC has just deployed a new web site dedicated to
> > developing secure coding standards for the C programming
> > language, C++, and eventually other programming language.

> > We have already developed significant content for the C++
> > programming language that is available at:

> > https://www.securecoding.cert.org/

> > by clicking on the link:

> >       "CERT C++ Programming Language Secure Coding Standard"

> Naive imperative coding standards like these do a disservice
> to programmers.

I would agree here only if I found the coding guidelines in
question naive.  (That was my first impression, but I haven't
studied it enough to make any real judgement.) In critical code,
some imperative coding standard is almost a necessity (not that
it guarantees correct code, but it can greatly improve the
chances that incorrect code is identified in code reviews and
such).

> In the real world, few coding practices apply to every case.
> There are always special cases that need to be handled
> differently.

The coding standard in question isn't meant to apply to every
case.  At least I don't think so.  Critical code does have
special requirements, which aren't necessarily applicable in
general.

> For example, MSC00-A, Declare data members private, fails to
> mention any cases where the guideline doesn't apply. Yet
> Sutter and Alexandrescu in their well-considered "C++ Coding
> Standards", list value aggregates and testing code as two
> cases where such information hiding isn't applicable.

This particular coding standard wouldn't apply to testing code,
so that exception isn't relevant.  And I can see some
justification for not accepting value aggregates in critical
code; accessor functions provide convenient control points.
(Obviously, such a rule should be accompanied by a rule saying
that every setter must validate the new value.  If not, there's
no point in making the data private.)

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Beman Dawes wrote:

>>       "CERT C++ Programming Language Secure Coding Standard"
>
> Naive imperative coding standards like these do a disservice to
> programmers.
[...]

This is only part of the problem with this coding standard.
The real problem, as far as I perceive it, is that they didn't really
pushed anything forward. This coding standard looks like a somewhat
selective bunch of good and common-sense advices taken almost literally
from books that everybody should have read anyway, but without any added
value. What hits me most is that they do list some references, but
completely fail to add any new insight to this referenced material.
What's the purpose? Isn't it just Yet Another Me-Too Coding Standard?

The above may sound a bit harsh, but my point is that CERT, with the
whole potential that stays behind its name, really should have done better.

--
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Maciej Sobczak wrote:
> Beman Dawes wrote:
>
>>>       "CERT C++ Programming Language Secure Coding Standard"
>>
>> Naive imperative coding standards like these do a disservice to
>> programmers.
> [...]
>
> This is only part of the problem with this coding standard.
> The real problem, as far as I perceive it, is that they didn't really
> pushed anything forward. This coding standard looks like a somewhat
> selective bunch of good and common-sense advices taken almost literally
> from books that everybody should have read anyway, but without any added
> value. What hits me most is that they do list some references, but
> completely fail to add any new insight to this referenced material.
> What's the purpose? Isn't it just Yet Another Me-Too Coding Standard?
>
> The above may sound a bit harsh, but my point is that CERT, with the
> whole potential that stays behind its name, really should have done better.

But what you see so far is just a start.

The point of developing the Secure Coding Standard as a Wiki is that
the whole community can help to produce something really worthwhile.

 Fred Long.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

The CERT/CC has just deployed a new web site dedicated to developing
secure coding standards for the C programming language, C++, and
eventually other programming language.

We have already developed significant content for the C++ programming
language that is available at:

https://www.securecoding.cert.org/

by clicking on the link:

      "CERT C++ Programming Language Secure Coding Standard"


We are depending on the active involvement of the C++ programming
language community (you) to make this effort a success.  I invite
you to participate in this effort by reviewing content on the web
site and providing comments, or by contributing new rules and
recommendations for secure c coding.  These can be sent to me
directly or to secure-coding at cert dot com.

I am attaching a press-release like article we wrote below to announce
the effort.  There is also a rationale section on the web site that
provides more details as to what we are doing and why.

Thanks,
     Fred Long
     CERT=FF Coordination Center
     Software Engineering Institute

-------------------

The Carnegie Mellon Software Engineering Institute (SEI) CERT=FF Program
has deployed a secure coding Web site at www.securecoding.cert.org to
cooperate with the software development community in codifying a
practical and effective set of secure coding practices for popular
programming languages. These coding practices can then be used by
software developers to eliminate vulnerabilities before software is
operationally deployed.

The purpose of this project is that the practices can be used by
developers for professional development and as the basis for
organizational coding standards supporting the quality of their products.

Jeffrey Carpenter, manager of the CERT Coordination Center, says that
the project is part of a larger secure coding initiative within the
CERT/CC to eliminate dangerous coding practices that can result in
exploitable software vulnerabilities.  According to Carpenter, "CERT is
in a unique position to coordinate development of a set of secure coding
practices because of its long history in analyzing and responding to
software vulnerabilities."

CERT's initial efforts are focused on the development of secure coding
practices for the C and C++ programming languages. CERT senior
vulnerability analyst Robert Seacord is leading the secure coding
initiative. Seacord is a leading authority on secure coding, author of
the book Secure Coding in C and C++ [Seacord 05], and technical expert
for the ISO/IEC JTC1/SC22/WG14 international standardization working
group for the programming language C.

"C and C++ were selected because a large percentage of critical
infrastructures are developed and maintained using these programming
languages," Seacord says. "C and C++ are popular and viable languages
although they have characteristics that make them prone to security flaws=
."

"Today's dependency on networked software systems has been matched by an
increase in the number of attacks against governments, corporations,
educational institutions, and individuals. These attacks result in the
loss and compromise of sensitive data, system damage, lost productivity,
and financial loss," says Seacord. To address this growing threat, the
introduction of software vulnerabilities during development and ongoing
maintenance must be significantly reduced, if not eliminated.

CERT recognizes that there are a number of available resources, both
online and in print, containing coding guidelines, best practices,
suggestions, and tips. The Motor Industry Software Reliability
Association (MISRA) developed guidelines for the use of the C language
in critical systems [MISRA 04], and more recently the U.S. Department of
Homeland Security launched its Build Security In web site
(https://buildsecurityin.us-cert.gov) to promote the codification of
practices and rules. These sources, however, do not provide a
prescriptive set of secure coding practices that can be uniformly
applied in the development of a software system.

"Without secure coding practices, software vulnerability reports are
likely to continue on an upward trend," Seacord says. "At CERT/CC, we
have had nearly 4,000 vulnerabilities reported in the first half of
2006. To stop the threats, we need to develop secure software from the
outset."

The secure coding practices proposed by CERT are based on standard
language versions as defined by official or de facto standards
organizations such as ISO/IEC. CERT is not an internationally recognized
standards body, but plans to work with organizations such as ISO/IEC to
advance the state of the practice in secure coding.  The ISO/IEC
JTC1/SC22 WG14 international standardization working group for the
programming language C, for example, has offered to provide direction in
the development of the C language secure coding practices and to review
and comment on drafts of the informal CERT standard.

According to WG14 convener John Benito, "The secure coding standard is
going in the correct direction, and I have confidence the final product
will be useful to the community."

CERT is also working with standards groups, such as the ISO/IEC working
group on Guidance for Avoiding Vulnerabilities through Language Use
(OWGV).  While the ISO/IEC group is working on providing
language-independent guidance, the CERT effort is working on developing
and consolidating the language-specific guidance that provides the
foundations for the ambitious goals of OWGV.

Jim Moore, convener of OWGV, states that "CERT's efforts in identifying
and documenting secure coding practices for C and C++ will contribute to
the standardization of these practices and advance the goals of the OWGV.=
"

Community Involvement

The success of the secure coding standards depends largely on the active
involvement of members of the secure software and C and C++ development
communities. Rules and recommendations for each coding practice are
solicited from the communities involved in the development and
application of each programming language, including the formal or de
facto standard bodies responsible for the documented standard.

These rules and recommendations are edited by CERT senior members of the
technical staff for content and style, and placed in Secure Coding
Standards Web site for comment and review. The user community is invited
to discuss and comment on the publicly posted content. Once a consensus
develops that the rule or recommendation is appropriate and correct, the
final rule is incorporated into the coding standard.

Once practices are documented, tools can be developed or modified to
verify compliance. Compliant software systems may then be certified as
compliant by a properly authorized certification body. Seacord also
envisions a training and development program to educate software
professionals regarding the appropriate application of secure coding
practices.

The development of secure coding practices is a necessary step to stem
the ever-increasing threat from software vulnerabilities. CERT's goal is
that the enumeration of secure code practices will allow for a common
set of criteria that can be used to measure and evaluate software
development efforts.

The public can review or comment on the existing content at the secure
coding Web site or submit new ideas for secure coding practices by
e-mailing secure-coding@cert.org. Robert Seacord can be reached at
rcs@cert.org.


*******************************
[1] Seacord, R. Secure Coding in C and C++. Addison-Wesley, 2005. See
http://www.cert.org/books/secure-coding for news and errata.

[2] MISRA C: 2004 Guidelines for the use of the C language in Critical
systems. MIRA Limited. Warsickshire, UK. October 2004. ISBN 0 9524156.


-- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work:
412-268-7608 FAX: 412-268-6989

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]