SAFECode Releases Framework For Assessing Security Of Software

The nonprofit Software Assurance Forum for Excellence in Code (SAFECode) today published a framework for companies to use when evaluating the security of software they purchase from third-party vendors.

Howard Schmidt, executive director of SAFECode, says the nonprofit's framework and recommendations offer enterprises a model for assessing the security of software they procure and to better manage risk.

"One of the key parts is to develop a trust of the security reliability of the technology ecosystem," Schmidt says. "This [framework] helps an enterprise become effective in assessing the security of software … and it's a method for assessing software security in a repeatable, scalable format."

The framework and recommendations in part draw from existing assessment models used by Boeing and the FS-ISAC, the financial services industry's threat intelligence-sharing community. The FS-ISAC in 2013 came up with a strategy for rolling out third-party software and services in financial institutions that includes a vendor-focused Building Security In Maturity Model (vBSIMM) assessment, binary static analysis, and policy management for open-source software libraries and components.

vBSIMM is a subset of the BSIMM, which is a study of actual secure software development programs at corporations that other companies can use to measure their own efforts with that of their counterparts. vBSIMM is a way to measure the maturity of software security of vendors selling to the financial industry.

SAFECode's "Principles for Software Assurance Assessment" framework aims to foster more transparency and trust between vendors and buyers, officials there say.

Gary McGraw, CTO of Cigital, which works on BSIMM, says vetting the security of third-party software vendors' wares is important. "How do you know whether the software is any good [security-wise] or not? There needs to be a way to measure vendor stuff," he says. You can't penetration-test all of the hundreds or thousands of vendor software programs running in a business, he says.

There are existing standards that address part of the secure coding issue, such as ISO 27034 for application security and IEC/ISA-62443 for automation and control systems. But SAFECode officials say those take care of specific areas and not the big picture of assessing the security practices of software vendors when enterprises make their purchases.

SAFECode's membership includes some of the biggest software companies in the world:  Adobe, CA Technologies, EMC, Intel, Microsoft, SAP, Siemens, and Symantec. McGraw contends that pedigree poses a bit of a conflict-of-interest question. He says big software vendors "would like to be in control of the measuring stick" for assessing their security, thus the new framework.

Even so, the fact that they are providing a framework is good news. "[The framework] is a good thing for them to do; it needs to happen," he says. "But the question is, who do you want to be policing the vendors. The vendors?"

SAFECode's framework does not fit the bill for software vendors that don't already have mature software assurance programs, however. It's up to the enterprise buyer to vet the software with existing tools or testing services. "For this category, SAFECode recommends a tool-driven approach, such as binary code analysis tools," according to SAFECode.

Software security vendor Veracode, which contributed to SAFECode's paper, weighed in today on that as well. "While it is encouraging that the largest software vendors in the world are beginning to consider the need for communicating about the security of the software products they produce, a focus on only the most-mature vendors sets the wrong expectation for buyers about the overall level of maturity in the market," Veracode's Anne Nielsen wrote in a blog post today about SAFECode's framework.

Nielsen, who is senior product manager for Veracode, which offers binary static analysis services, not surprisingly also called for binary static analysis of these software packages from the non-major vendors; binary static analysis is Veracode's business. "This industry-accepted standard provides a point-in-time assessment of vulnerabilities within the product at the time of purchase which informs the buyer of exactly what they are getting: features, functionality, and risk," she wrote.

What about enterprises that don't fall into the big, Fortune 100 or so category like many of the BSIMM participants, for example? Cigital's McGraw says these smaller enterprises in general are not as focused on third-party software security. "There are not enough companies worried about this … But the big companies have already figured out how to solve this," he says.

Meantime, SAFECode says "Tier 2" software suppliers, which have internal software assurance processes but no international standards driving their programs, can be assessed by buyers in three basic areas:

Secure coding development and integration: Does the vendor deploy, for example, threat modeling, sandboxing, fuzzing, penetration testing, and static code analysis?

Product security governance:  Is security a part of the company's culture and operations? Is the development team required to receive security training/enrichment? Is its security posture reviewed by managers at various levels in the company? Is there a "roadmap" for the next phases of secure development? Does the vendor have a documented process for fixing vulnerabilities in its products?

Vulnerability response: Is the software vendor "transparent" about bug discovery and reporting? Does it work with customers who find vulns?