As researchers uncover one serious flaw after another in widely used software, it's increasingly clear there are lots of vulnerabilities, everywhere. While there are efforts underway to identify and fix these issues before criminals exploit them, the bigger challenge is stopping
developers from using buggy code. There is no such thing as perfect software, but developers can reduce the number of bugs by following secure coding practices. There are also tools which can analyze individual libraries—both open-source and commercial—included in software projects to ensure they aren't buggy. Many organizations have no idea if the software they are using contains vulnerable components because the application hasn't been thoroughly tested.
Click here to find developer jobs. Application security needs to be viewed as a supply chain, with software developers applying the same rules that the food, automobile, and pharmaceuticals industries already follow, said Josh Corman, CTO of Sonatype. In those industries, organizations vet and update a list of high-quality suppliers, regularly inspect products to maintain quality standards, and recall products when defects are found. That rigor is missing from the software world; no one is vetting the third-party libraries and code components. "We have not yet gotten to the point where we look at the building blocks," Corman said. "We are just starting to wake up." Cleaning up old code is easier said than done. If the code is no longer under active development, it is harder to find somebody willing to make changes to it. The vast majority of organizations still aren't thoroughly testing actively maintained applications, let alone legacy applications, said Chris Eng, vice president of research at Veracode. If the company knows that customers are locked into the platform and are unlikely to switch, even if bugs are not fixed in a timely manner, it may not make bug-fixing a priority, he said: "From a business perspective it comes down to weighing the cost of analysis and patching, versus the risks of turning a blind eye.” Over 90 percent of modern applications come from third-party libraries and other components, according to analyses by
Gartner and Sonatype. This figure doesn't just apply to open-source components, as commercial libraries can be reused, as well. This means just 10 percent of the application is custom code. Yet when organizations conduct code reviews and run analyses, they generally focus on the 10 percent of code and ignore the third-party components, Corman added. Up until this year, developers believed the myth that open-source software did not have any bugs because the code was available for anyone to view. Few people realized that no one was actually looking at the open-source libraries and code segments being used in other applications. "We need to inspect the supply chain," Corman said.
Upload Your ResumeEmployers want candidates like you. Upload your resume. Show them you're awesome.
Does that mean efforts such as The Linux Foundation's Core Infrastructure Initiative, which funds developers to maintain various open-source applications, are a good step forward? Not quite, according to Corman. While finding new bugs is never a bad thing, "finding and reporting vulnerabilities isn't the bottleneck; fixing the issues is.” Most open-source projects have large backlogs of security flaws that have not yet been fixed; OpenSSL has more than 30 open bugs, for example. In a recent analysis of software libraries, Corman found that only 41 percent of flaws ever get fixed. On average, it took 390 days for a vulnerability to be eliminated; for critical bugs with a CVSS score of 10, the mean time to repair was slightly better, at 324 days. "Why are we spending money finding new vulnerabilities, when we haven't even shut the front door?" Corman said. The other problem has to do with developers using out-of-date components. A serious vulnerability in Bouncy Castle, a collection of
Java cryptography libraries, was fixed in April 2008, but developers downloaded the vulnerable, unpatched version more than 4,000 times in 2013. The fix is available, but as long as developers don't use good libraries, applications will remain highly vulnerable. Corman advocates a "bill of materials" for software, where developers list all the third-party components used to build the application. This way, users can tell whether they are affected when a particular vulnerability is disclosed, or whether a software application is using a vulnerable version of the library. The ingredients list will let customers and downstream users make the decision on what software to use or not use. "If we can get better at software development, we can spend less on after-market security," Corman said.
Related Articles
Image: spaxiax/Shutterstock.com 
