CERT Advances Secure Coding Standards

The secure coding movement got a little boost today as CERT and Fortify Software announced that they have teamed up to automate part of the process of building security into software -- specifically, automating compliance with CERT's C and C++ Secure Coding Standard.

CERT is translating its guidelines into a coding format that will run on Fortify's Source Code Analysis tool. The resulting software module will be available for free from CERT, so other tool vendors can convert it to their products, and organizations that do in-house testing can use it with their tools as well.

To date, programmers who wanted to use the voluntary CERT guidelines for writing cleaner and more secure software in C and C++ had to manually sift through CERT's massive checklist of guidelines. "Manual enforcement is extremely error-prone and tedious," says Brian Chess, chief scientist at Fortify. "Quickly you get to the point where you are not able to do any manual review of your millions of lines of code, so you have to automate" that process.

CERT's secure coding initiative gets input from software developers and other organizations to help identify common programming errors that lead to software bugs and provides secure coding standards. (See CERT Seeks Secure Coding Input and Secure Coding Catches Fire.)

"CERT is creating 'signatures' to tell our tool what to spot," Chess says.

But some security experts say setting voluntary guidelines is not the most effective method of making software more secure. "Product teams don't get better by reading secure coding standards. They get better by working with security testers, seeing how their code gets broken by attackers, and learning from the experience," says Thomas Ptacek, principal with Matasano Security. "Before we expect software companies to ship better products, we need to see a top-down commitment to security, just like we saw at Microsoft. Everyone from the board room down to the QA team needs to agree that security trumps feature sets and release schedules."

And not many vendors will be able to pull this off, Ptacek says.

Robert Seacord, a senior vulnerability analyst at CERT and head of the secure coding initiative, says internal buy-in is important, but it won't fly without guidelines on how to ensure software is written with security in mind.

"A well-defined software development process is also important to produce high-quality secure software," he says. "However, it is important that developers can differentiate between software that has these qualities and software that does not, or the process is irrelevant."

It may be a problem of putting the cart before the horse, Ptacek argues. "There's a big need for a common language that security testers and software developers can speak so they can agree on what needs to be done and what needs to be taken seriously," Ptacek says. "I don't see the harm in what CERT is doing, but we should figure out the 'what' before we spend lots of time on the 'how.' "

CERT and Fortify expect the so-called Fortify Rulepack to be completed by year's end, when it then will be tested by Japan's CERT, JPCERT/CC, and Software Research Associates of Japan, on several software development projects. Both CERT organizations will release details on how the tool operated for these projects in the spring of 2008.

Meanwhile, CERT also has a higher-level list of the Top 10 Secure Coding Practices on its site for developers to follow when writing code, which includes tips such as keep it simple, using least-privilege, and validating input from other sources of data, such as network interfaces.

But no one expects any major improvements in software security anytime soon. And although more secure code will definitely reduce the number of vulnerabilities, it certainly won't eradicate them. "There's no conclusion to people breaking into systems," Fortify's Chess says.

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