Language agnostic secure coding guidelines/standards?

[peter.werner at gmail.com (Pete Werner)]

Hi All

Thank you for your replies, they have been very useful and will
certainly help identifying things that need to appear in the standard.
We're trying to make the standard something that is easily auditable,
and have decided to further split items into two categories, those that
should checked in development and those that should appear in the
project  documentation (e.g. things like definitions of log
integrity/confidentiality requirements etc).

I'm also happy to say that within our organisation we already have
secure coding training available for developers, support channels for
developers with queries, language specific guidance, automated tools
that can be used to detect software flaws as well as an internal
auditing and pentesting function. Needless to say it's been a big effort
to get all this in place. The policy is an important piece of the puzzle
which will hopefully help ensure the training and tools are utilised by
developers.

These things are all great, but from an organisational perspective one
of the most important things for us is the ongoing risk management of
identified issues. We have a lot of applications in various stages of
development and production, and a lot of developers. Tracking known
issues, remediation timelines, and who is responsible for what is also a
very big part of it, especially in larger organisations. Again I'm happy
to say we have an internally developed system for doing this.

Rather than just giving myself a gold star on a mailing list, I would
say to the vendors here interoperability is a big thing for us, as no
one product does it all to the level we require (and it's unlikely they
ever will). We are far more likely to buy things that play nicely with
what we have already, and so far, most of the tools we use do. Gold
stars all round.

Anyway, thanks again for all the information.

Cheers,
Pete

On Thu, Nov 20, 2008 at 8:00 AM, Gary McGraw <gem at cigital.com> wrote:
> badness-ometer-pedia!  most excellent descriptive phrase.  You guys should change the official name!
>
> Incidentally, one of the best uses data like these can be put to is training.
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
> On 11/17/08 4:49 PM, "Steven M. Christey" <coley at linus.mitre.org> wrote:
>
>
>
> The CWE Research view (CWE-1000) is language-neutral at its higher-level
> nodes, and decomposes in some areas into language-specific constructs.
> Early experience suggests that this view is not necessarily
> developer-friendly, however, because it's not organized around the types
> of concepts that developers typically think in.
>
> http://cwe.mitre.org/data/definitions/1000.html
>
> (click the Graph tab on the top right of the page to see the breakdown)
>
> Obviously the CWE is a badness-ometer-pedia but suggests some areas that
> your guidelines would hopefully address.
>
> - Steve
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> _______________________________________________
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> _______________________________________________