This site graciously hosted
by our friends at




Secure Coding Mailing List Charter

29 January 2004

Introduction

This document describes the mission and use of the Secure Coding mailing list. It is subject to change without notice, and will be maintained for all to see on the SecureCoding.org web site at http://www.securecoding.org/list/charter.php.

Mission

The Secure Coding (aka "SC-L" and "SC-L-DIGEST") mailing list's mission is to further the state of the practice of developing secure software, by providing a free and open, objectively moderated, forum for the discussion of issues related to secure coding practices throughout a software development lifecycle process (including architecture, requirements and specifications, design, implementation, deployment, and operations).

Acceptable Use Policy

SC-L and its digest-mode counterpart, SC-L-DIGEST, may be used to discuss matters directly or indirectly related to the practice of developing secure software. Acceptable topics include the following:
  • Secure software development techniques, processes, tools, etc. These can be throughout the product development life cycle (i.e., architecture, design, implementation, deployment, operations).

  • Questions and discussions of specific good/bad coding practices, with examples. Not sure what procedure to use in your chosen programming language, so as to avoid a buffer overflow situation? you may ask other professionals about it here.

  • Announcements, reviews, recommendations of development tools that can make your life easier. Checklists, open source or commercial products, etc., are all fair game to discuss...within reason (see the Unacceptable use policy below). In general, product/service announcements will be preferred from persons unaffiliated with the vendor, but tasteful vendor announcements will be considered as well.

  • Vulnerabilities. Specific product vulnerabilities may be discussed, but only from the perspective of analyzing the underlying cause and remedy. For example, discussing a design/implementation flaw in a particular product is allowable as long as the discussion stays on track with analyzing the vulnerability itself.

  • Exploits. While code that exploits a particular vulnerability is not acceptable (see below), discussions about how an attacker might exploit a problem in software design/implementation/etc., is acceptable. These should be limited to "clinical" discussions about flaws in software development practices, and not product bashing (see below).
Unacceptable Use Policy

SC-L is NOT to be used for any of the following purposes:
  • Flames. Civility rules; flaming will simply not be tolerated.

  • Vendor bashing. If you want to be the first on your block to announce a new vulnerability, take it somewhere else. You want to "yell" at a vendor for not fixing a vulnerability quickly enough for your liking, take it somewhere else.

  • Product/service advertising. There's a fine line between announcing/discussing the availability of a product or service and advertising it. Please do not cross that line.

  • Full disclosure of exploit code. This is NOT a full disclosure vulnerability list. If you want to post an example of an exploit for a particular product vulnerability, take it somewhere else. Exploit code will not be accepted. (However, as noted previously, discussions about how a design or implementation might be exploited are acceptable.)

  • Attachments and email format. All submissions to the list that contain email attachments will be rejected. Further, all submissions should be "plain" ASCII text -- no HTML or other mark-up languages will be permitted.
List Ettiquette

Above all else, civility will be exercised in the discussions here. If you want to use a tone of discussion that you wouldn't use with your {spouse|parents|high school teacher|best friend|etc}, then don't use it here. You will find that the moderator's patience for incivility is very short.

The two most common problems on large email lists are "user unknown"/"mailbox full" bounce messages and vacation programs that reply to either the mailing list itself or each person that submits an email to the list. PLEASE: If you are going on vacation or will otherwise not be able to get to your email for a while, unsubscribe from the list and then re-subscribe when you return. Further, if you are changing email addresses (e.g., job change), PLEASE change or remove your subscription to the list. It will greatly appreciated by both your moderator as well as your fellow members of the list.

Moderation

SC-L is a moderated list; SC-L-DIGEST is identical in content to SC-L, but is delivered in (more or less) daily digests to the subscribers. All submissions will be reviewed and judged qualitatively against these policy guidelines. Further, submissions are only considered from registered members of this list -- although the list is open to the general public. The moderator is the final decision authority on whether or not to accept any and all submissions.

If you feel that your submission to the list has been unfairly rejected, you may (politely) appeal to the moderator and state your case as to why your submission should be accepted. Nonetheless, as stated, the moderator will make the final determination.

Any list member that violates any of the usage policies will first be warned of the violation. The moderator retains the right to remove (and blacklist) repeat offenders.

Archives

List archives are currently available at http://lists.virus.org/ (Our thanks to the folks at virus.org for graciously providing this free service.)

Copyright

All submissions to SC-L and SC-L-DIGEST are considered to be in the public domain, unless otherwise noted (and accepted by the moderator), and are on an as-is basis with no warranty whatsoever.

Cheers,

Kenneth R. van Wyk
Moderator, SC-L
ken@securecoding.org


Site Contents Copyright (C) 2002, 2003 Mark G. Graff and Kenneth R. van Wyk. All Rights Reserved.
webmaster@securecoding.org