Many organizations are beginning to implement or have already enacted secure coding methodologies, and they are improving the software security of proprietary code as a result. However, the use of third-party applications or code libraries is prevalent in most organizations as well, and the attention paid to the security of this software often lags behind that devoted to in-house development.
A recent Microsoft study found that only 37 percent of organizations build their software products with security in mind. The company and others are pushing more organizations to follow a coding standard known as ISO 27034-1 that would make it easier to know the level of precaution taken during programming. Until such standards are enacted, however, the onus of ensuring third-party code doesn’t pose a security risk is on the organizations procuring it.
“Ideally, it wouldn’t have to be your responsibility to know the ins and outs of your suppliers’ development practices,” FierceCIO editor Caron Carlson wrote in a recent column. “In a different world, we could presume a safe software production lifecycle, much like we can presume our orange juice is made according to processes that prevent poisoning. But that is not the reality when it comes to software. And nobody can say we haven’t been warned.”
Testing code for safety
Determining whether code bought from third-party vendors is safe enough is a major challenge, particularly since many large organizations may source code from hundreds of separate vendors, all of which are constantly making changes and updates, TechTarget contributor and software security consultant Gary McGraw wrote in a recent column. He advised companies to take two primary approaches when assessing the integrity of a vendor’s code: determine whether they follow a secure coding standard and run tests with tools such as static analysis software.
McGraw highlighted the guidelines laid out by the BSIMM software security initiative as a good test for whether a vendor is being rigorous enough in their coding process. Different standards can also be acceptable, as long as purchasers take time to ask how the software security initiative actually works.
Another way to rule out dangerous code is to use static analysis software to test the application. Such tools allow organizations to gauge whether a program’s quality is too low to use, which McGraw referred to as a “badness-ometer” approach.
“The good news about badness-ometers is they are straightforward and cheap to apply, especially when it comes to measuring third-party code,” he wrote. “Just aim the tests at the application in question and away you go. If the application fails the tests, then let the vendor know the application they built is not good enough to use.”
Leveraging static analysis software and other practices such as code review, organizations can determine whether vendors are providing code worth using and integrating. While ideally vendors would follow a standard that ensures security, application of such standards remains uneven and ultimately involves some level of subjectivity. Automated testing can be a valuable tool to supplement security.
Software news brought to you by Klocwork Inc., dedicated to helping software developers create better code with every keystroke.