Industry:SAFECode Secure Development Practices (update to Oct 2008 version)

Return to Global Industry Committee

Submission Response
Latest first

Draft version
OWASP supports initiatives to increase software visibility. Please find below our comments on the 8 October 2008 version of "Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today."

Are there any best practices you feel should be added to the paper? Please explain.
We recommend the inclusion of the "Software Assurance Maturity Model (SAMM)". This describes a range of practices through the software development lifecycle, across four business practice areas, that help build security into software development. The release-quality version 1.0 was published in March 2009.

OWASP Software Assurance Maturity Model (SAMM) http://www.opensamm.org/

Some of the existing resource link to sections of the OWASP Development Guide. This document and the ESAPI Toolkits, that help software developers guard against security-related design and implementation flaws, span more than one fundamental practice category. We wonder if there is a need for more generic resource links, perhaps in the overview or as a new separate "lifecycle approach" section.

OWASP Guide Project - Guide to Building Secure Web Applications and Web Services http://www.owasp.org/index.php/Category:OWASP_Guide_Project

OWASP Enterprise Security API (ESAPI) http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Or alternatively link to them from multiple resource sections.

Would you make any changes to the practices listed in any of the [Requirements, Design, Programming, Testing, Code Integrity and Handling, Documentation] sections? Please explain.
On page 9, add the resource OWASP Code Review Guide which includes a strong collection of issues, practices and guidance on code review tools:

OWASP Code Review Project - OWASP Code Review Guide http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

On page 11, we suggest the resource "OWASP PHP AntiXSS Library Project" should be removed, and replaced with the more generic, and recent:

OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

On page 16, we recommend mention the OWASP Testing Guide which was updated this year and includes a large number of additional references and links to tools:

OWASP Testing Project http://www.owasp.org/index.php/Category:OWASP_Testing_Project

and the new Application Security Verification Standard, that defines tiered requirements for application security verification processes to establish a defined level of assurance:

OWASP Application Security Verification Standard (ASVS) Project http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

Is there anything else not covered above you would like SAFECode to consider in its second version of the paper?
A minor correction... on page 10, the last resource says "OSWASP Top 10..." - this has an extra S and should be "OWASP Top 10...". On page 15, the resource item "OWASP Error Handling, Auditing and Logging" doesn't need to be SSL i.e. change "https://" to "http://".

Invitation
In October 2008, SAFECode released "Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today." Based on an analysis of the individual software assurance efforts of SAFECode members, the paper outlines a core set of secure development practices that can be applied across diverse development environments to improve software security.

The brief and highly actionable paper describes each identified security practice across the software development lifecycle - Requirements, Design, Programming, Testing, Code Handling and Documentation - and offers implementation advice based on the real-world experiences of SAFECode members.

Due to the overwhelmingly positive response to the paper's publication, as well as the rapidly evolving information security environment, SAFECode will be releasing an updated version of the paper in late 2009.

In our continued effort to make the paper's recommendations as useful and relevant as possible, we would like to offer experts outside of our membership an opportunity to provide input into the paper's next version. To submit your comments, please visit http://www.safecode.org/feedback.php.

We will be accepting comments until July 31, 2009.

Return to Global Industry Committee