I'd like to mention that OWASP is about to release a Beta version of its Application Security Verification Standard (ASVS) - Web Application Edition.
This standard (which is language agnostic) provides a checklist of security requirements that web applications should meet and it is organized into increasing levels of difficulty based on the techniques you use to assess the application. The first level is based on what automated code analysis and external scanning tools can find. The second level is based on what human verifiers can find (who may use automated tools to assist them) doing code analysis and/or application penetration testing. There is also a third and fourth level that add additional requirements in the areas of architecture review, threat modeling, and the avoidance of malicious code. I would think that this document would serve as a great reference to pull from in order to gather a set of language independent secure coding guidelines since this is essentially the list of application security best practices that OWASP believes web applications need to meet in order to provide a baseline level of security. These requirements clearly don't include every security issue a web application may need to address but it defines the foundational requirements that we believe every application should meet. An Alpha version of this standard is already publicly available at: http://www.owasp.org/index.php/ASVS And the Beta release is close to completion and should come out sometime this December. I have cc'd Mike Boberski who is the project lead for this OWASP Summer of Code 2008 project. You can contact either of us (as well as Jeff Williams) if you have any questions about this new OWASP Standard as the three of us are the primary authors of this document. -Dave -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Werner Sent: Friday, November 21, 2008 1:40 AM To: Secure Coding Subject: Re: [SC-L] Language agnostic secure coding guidelines/standards? 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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@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@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@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@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. _______________________________________________