Application developers are getting burnt by security vulnerabilities in the very open source- and third-party frameworks and software components that make up their finished application product.
That's one of the major findings in Veracode's annual State of Software Security 2016 report, published today and based on data from the application security firm's code-level analysis of billions of lines of code the past 18 months. The scans of some 300,000 application security-assessment cases show that 97% of the Java applications tested contained at least one known software vulnerability in one of its components.
Veracode's tests also underscore how an open-source or third-party code flaw can spawn more bugs in the final product: "Third-party vulnerabilities are usually a good warning that organizations should look for the root problem in their own code," Veracode's report says. "The same deserialization vulnerability found in a version of Apache Commons Collections library used in 21% of Java applications was present in developer-authored code used in 25% of Java applications."
It's mainly a matter of developers and development teams paying closer attention to their open-source libraries and other third-party tools, ensuring they are using the most up-to-date – and most secure – versions.
Tim Jarrett, director of product marketing for Veracode, says the study found that one-quarter of the software applications tested used the 2012 version of the Struts library. The framework has undergone about three dozen point releases since that version, he says.
Developers don't always update their third-party libraries, Jarrett says. "There's a cost to the dev team. But this is part of the problem of this massive layer of open-source dependency. Developers pick up frameworks, but they don’t manage it from that point on," he says. "If it's not actively broken, they don’t fix it … But they [then] inherit risk."
The new Building Security In Maturity Model (BSIMM7) also calls out the perils of overly trusting open source modules. "Generic open source software security architectures, including OWASP ESAPI, should not be considered secure by design. Bolting security on at the end by calling a library is not the way to approach secure design," according to the BSIMM7 report, which was published last week.
BSIMM studies how organizations run their software security programs in-house and provides benchmark information that organizations can use to measure their program's maturity against those of other organizations.
But if you don't know where open-source components lie in your applications, you can't manage them. One of the standards & requirements under the BSIMM model is to "identify" open-source components. "It’s not uncommon to discover old versions of components with known vulnerabilities or multiple versions of the same component. Automated tools for finding open source, whether whole components or large chunks of borrowed code, are one way to approach this activity," the BSIMM7 says. "An informal annual review or a process that relies solely on developers asking for permission does not generate satisfactory results. At the next level of maturity, this activity is subsumed by a policy constraining the use of open source."
Internet pioneer Paul Vixie says this ability to inventory open-source code in an organization is increasingly becoming crucial for organizations in this age of Internet of Things devices entering the building. "BYOD is no the only thing that wants to use your WiFi," says Vixie, who is CEO of FarSight Security. "If you get new thermostats or closed-circuit TVs, they go from the loading dock to IT. They have no idea if [these IoT devices] have a bad Java module on it."
Security flaws spilling from open-source code to enterprise apps is the "inevitable phase" of the open-source evolution, Vixie says. "There was a time when open-source was more secure because it was more looked at," he says. "Now there's too much of it and too few of us" to manage it and keep it secure, he says.
Veracode's report also shows that 60% of applications scanned for the first time don't meet basic security requirements.