Fresh advice on building safer software

SAFECode updates best practices for secure development

An industry group promoting reliability in commercial software has updated a set of guidelines for secure software development, with a focus on validating the results of recommended practices.

The second edition of “Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today,” written by the Software Assurance Forum for Excellence in Code, is based on real-world tools and reflects advances in secure software development since the original report was published in 2008.

“The process of building secure software has continued to evolve and improve,” said SAFECode Executive Director Paul Kurtz. “The second edition of the paper aims to disseminate the new knowledge SAFECode has gathered and provide new tools and improved guidance for those implementing the paper’s recommended practices.”


Related coverage:

SAFECode framework addresses software supply chain integrity


The new edition contains additional information on each best practice, using Common Weakness Enumeration (CWE) references to identify specific software weaknesses addressed by each practice and offer verification guidance.

“It wasn’t always obvious how to tell if you are doing it right,” SAFECode board member Brad Arkin said of the original guidelines. The new notes on verification allow users to ensure that recommended practices have been followed during development of software.

CWE is an identification scheme created by Mitre Corp. to provide a common way of identifying and talking about software weaknesses. “By mapping our recommended practices to CWE, we wish to provide a more detailed illustration of the security issues these practices aim to resolve and a more precise starting point for interested parties to learn more,” the document states.

Two sections from the original publication on training and supply chain security, which have since been addressed in separate reports, have been eliminated in the second edition.

The guidelines are not meant to be a comprehensive blueprint for secure software development but to provide a foundation of practices, already in use by member companies, that have been shown to be effective.

Basic secure coding practices identified in the report include:

  • Minimizing the use of unsafe string and buffer functions.
  • Validating input and output to mitigate common vulnerabilities.
  • Using robust integer operations for dynamic memory allocation and array offsets.
  • Using anti-cross scripting libraries.
  • Using canonical data formats.
  • Avoiding string concatenation for dynamic SQL statements.
  • Eliminating weak cryptography.
  • Using logging and tracing.

Arkin, who also is senior director of product security and privacy for Adobe, said the quality of commercial software is becoming more of an issue for developers and vendors.

“People who are developing software are paying a lot of attention to this,” he said, adding that he now has difficulty recruiting developers because of the increased competition for people who have the necessary skills. “I feel like the investment in security has been increasing. As an industry there is awareness that security really is a priority.”

But despite progress, security remains a challenge, he said.

“I think we’re gaining,” he said. “But the bad guys aren’t standing still. Unfortunately, the other side of the coin is that offensive techniques are advancing as well.”

 

Reader Comments

Tue, May 15, 2012 John Richardson

One aspect of software assurance that doesn't get talked about is for applications to make themselves easy to identify, easy to patch, easy to understand what the revision/patch level of the application is. Typcially the application development processes are geared toward what is most efficient for the engineering team (minimum build times, re-usable components, etc.), not what will make the application more manageable via automation by asset management tools. Application deploy many shared libraries, executable files, install components, etc. with no clear way to map these artefacts to the application. This makes it pretty difficult to secure a system. One the best practice suggestions on every security check list is to keep your system up to date. Well, in today's world where there are many postings to the NIST National Vulnerability Database monthly, it is critical that large organizations have the ability to automate the identification of vulnerable appliications and the verification that the remedies are in place. There was a recent conference just outside of San Jose, CA sponsored by TagVault.org that discussed the use of ISO 19770-2 Software ID Tagging as one of the ways to enable the level of autonmation required. A DHS Deputy Director from their Cyber Security Division focused on Software Assurance gave the keynote address. Microsoft recently announced support for ISO tags as well. I think designing applications to be effectively managed and patched by asset management tools needs to be a fundamental aspect of delivering world-class, secure software.

Mon, Feb 14, 2011 Sadler

Please remove the word "Safer" from the title. This article is NOT about software safety. The "SAFE" in SAFECode is an acronym for "Software Assurance Forum for Excellence". The updated document is "A Guide to the Most Effective SECURE Development..." Many, many people are under the impression that if their software is SECURE, it is also SAFE. Not true.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above