SAFECode Issues Best Practices For Writing Secure Code

The nonprofit Software Assurance Forum for Excellence in Code, a.k.a. SAFECode, today published a best practices guide for the software community based on techniques and processes used by its high-profile membership.

The new "Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today" details secure development best practices used by members Adobe, EMC, Juniper, Microsoft, Nokia, SAP, and Symantec. This is the second edition of the report, which the nonprofit first published in 2008.

"The scope of this paper is focused on design, development, and testing. The big difference between what we have here now and what we had done before is that we have the benefit of more than two years of experience working together and understanding best practices," says Paul Kurtz, executive director of SAFECode. While the report isn't meant to be a comprehensive guide, it does contain much more detail than the first edition, according to Kurtz.

SAFECode recommends using threat modeling, least privilege, and sandboxing techniques for the software design process. It also recommends minimizing the use of unsafe string and buffer functions; validating input/output; using robust integer operations for dynamic memory allocations and array offsets; using anti-cross site scripting (XSS) libraries; using canonical data formats; avoiding string concatenation for dynamic SQL statements; using strong cryptography; using logging and tracing; testing recommendations to determine attack surfaces; using appropriate testing tools; fuzzing and robustness testing; penetration testing; and using a current compiler toolset, and static analysis tools.

Kurtz says verifying that software development teams follow these best security practices is key. And the report includes verification tools and methods to ensure the recommended practices are deployed. "Verification is a great step forward for the software assurance community," he says. "Customers have said [they] understand these practices and they are helpful, but how do [they] verify that these practices are being followed by those who are putting the code together for you?"

SAFECode's report is a living document, he says, and is more about sharing what its members do to ensure secure software development. "SAFECode isn't saying that this is a standard that all have to adopt. We're saying, 'This is what we do' ... we want to see these practices make a difference," Kurtz says. "This is not abstract. This is in use today."

The full report is available here from SAFECode.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.