Micro Focus is now part of OpenText. Learn more >

You are here

You are here

The state of software security: 5 things developers can do now

Rob Lemos Writer and analyst
Padlock icon on computer screen

Of all of the activity and news about software security, three trends stood out in 2016: Software vulnerabilities in Adobe Flash were the most targeted by criminal exploit kits; flaws in a variety of consumer devices allowed a massive botnet to be created that disrupted services on the Internet; and attacks on Web applications were the top source of data breaches.

So what's next? Veracode's State of Software Security report sheds some light here.

Mistakes in software code continue to make both commercial and in-house applications vulnerable to attack, resulting in breaches and network compromises. Nonetheless, companies continue to make missteps in incorporating security into their software development process, according to the software-security firm's report.

More than 61 percent of applications failed to account for the top-10 vulnerabilities on the OWASP Top-10, and 66 percent failed to catch the SAN Top-25 on their first security audit, the report said. But for the first time, there's also good news. Both those failure rates were down from previous years, and Veracode's data shows that top-performing development organizations had vulnerability fix rates that were 68 percent better than average organizations.

The report contains other lessons for companies that want to stay on top of software security. Here are five key takeaways.

1. Educate your development teams

Start by creating a software security program for your applications, and work with your development teams on ways to incorporate educations and training into their workflows. Merely getting serious about software security can have benefits. Companies that created a software security program experienced 46 percent fewer vulnerabilities in their code than companies who did not have a program, the Vericode report says.

Security teams should also make sure that they are creating a ongoing effort while not getting in the developer's way, says Tim Jarrett, director of enterprise security strategy at Veracode.

"If you are going to try to implement a formal education for developers, it doesn't work to bolt those on top of a one-time project. But making the effort part of how developers build software makes it possible to extend those services to developers and create an advantage, rather than a disruption." —Tim Jarrett, Veracode.

Overall, organizations that put a process in place to reduce vulnerabilities saw a 1.45x reduction in flaw density, while companies who made training and online learning part of their efforts saw a six-fold decrease in vulnerabilities, according to the report. The results are often seen in practice, says Dan Cornell, chief technology officer at the Denim Group.

We have seen the benefits of organizations moving the security to the left and making those security tools available to developers, Cornell said.

"Handing a developer a security tool is not a recipe for success, but if you can craft the developer's experience using that tool, and better integrate with the developer tool chain, then you have a real increase in the consumption of security testing." —Dan Cornell, Denim Group

2. Don't rely on a single test

No tool will catch every flaw. Dynamic analysis tools can catch one set of flaws, while static analysis tools catch another. Both are good at catching information leakage and cryptography issues, for example, but results differ in other areas of potential security weakness.

Static analysis identified cross-site scripting issues in 52 percent of applications, where dynamic analysis found XSS issues in 25 percent. On the other hand, dynamic analysis caught deployment configuration issues in 57 percent of the applications tested — a class of security vulnerability that static analysis cannot detect.

If you are not testing your code, quite often security issues are introduced, said Alan Sharp-Paul, co-founder and co-CEO of Upguard.

"[It's] not because someone has introduced a vulnerable piece of software or has a piece code that is poorly written—they are actually introduced because they have poorly implemented and poorly configured an existing security or application setting." —Alan Sharp-Paul, Upguard

Finally, companies should conduct regular manual tests to ensure that they are catching the vulnerabilities and security weaknesses not caught by automated tests, says Cornell.

"What the report does not reflect here is the need for manual testing, especially of those high criticality applications," he says. "There are classes of vulnerabilities that you cannot find without manual testing."

3. Look at your open-source components

Developers should keep a manifest of the components they use to create code, whether it's a framework like Struts, a Java component, or an open source library. If you find a vulnerability, the software should be rebuilt. Yet, often those components are not promptly patched when a vulnerability is discovered, says Sharp-Paul.

"It is so easy to have a problem when you are developing a product, do a quick Google search, and find a Java library or a Ruby gem that can satisfy the requirement," Sharp-Paul says. "What you don't realize is that, under the covers, that one decision to add what may be a single include line to one of your files can easily drag in 20 or 30 other components. This is where the risk comes in."

Managing the components that go into applications is a critically important task, Jarrett says.

"No one seems to have their arms around the right way to address changes to the landscape when a component is found to be vulnerable. No one has that baked into their development process in a repeatable way. People don't think of the carrying cost of keeping that library updated." —Tim Jarrett, Veracode

4. Consider DevOps or agile development

The move toward DevOps and agile development practices is one bright spot for developers and security teams. Veracode, which offers a privately accessible, "sandbox" scanning service, saw many developers scan more often—up to 6 times a day. More than nine percent of companies scanned applications more than 15 times during the 18-month study period, and one application was scanned 776 times in 18 months—a frequency that suggests a DevOps mentality.

The results were impressive:

Companies that used sandbox scanning nearly doubled their fix rate.

Overall, the sense is that integrating developers more tightly with operations, and using automation to continuously test is an idea whose time has come, Jarrett says.

"There [are] a lot of things that make up DevOps in people's minds, where you make the same team responsible for building and deployment and operation of the software. But it is the culture of automation that we associate with the security automation of the deployment, and it's there that we are seeing a lot of impact."

5. Create metrics for success—and use them

Different industries need to focus on different vulnerabilities. Software in the healthcare industry, for example, tends to have major cryptographic issues, with nearly 73 percent of first-time software scans revealing a flaw in such programs. Government software tends to have more cross-site scripting problems: 69 percent of those applications had such a flaw, according to Veracode's report. Each industry should compare itself to peers to judge its progress.

Yet, a major metric that should be tracked as early as possible is the fraction of business-significant applications that are covered by automated testing, said John Dickson, principal at the Denim Group. 

"Even the guys who are good at security do not have  100 percent app portfolio coverage. So the first definition of victory is that you have 100 percent coverage—at least of the important apps." —John Dickson, Denim Group

Baby steps for secure software development

The report found that software security is moving from "bad" to "not all that bad," but there are still major issues. At the same time, the little things are still plaguing security. For example, more than on third of applications had hard-coded passwords, the study showed. Another 39 percent used broken or risky encryption algorithms, and one in six mixed trusted and untrusted data. In addition, many developers are not vetting all of the open-source and commercial libraries built into their software.

Overall, while security problems continue to plague software development, the general trend appears to be slow improvement. And many companies are doing software development right.  

"It can be disheartening for security teams and development organizations to continually hear the ongoing drumbeat of breaches. So we want to give a ray of hope and let them know that there is something that they can do to improve security and protect adjacent those breaches." —Tim Jarrett, Veracode

The best companies did much better at fixing vulnerabilities in their software than average firms. The strongest core developers—those who tested 20 applications or more—fixed 64 percent of vulnerabilities, compared to 38 percent overall. For smaller development programs, the difference was even more stark—high performers fixed 56 percent of their vulnerabilities, versus 13 percent for the median. 

"We continue to see most software passing a common sense policy, and we are also seeing a lot of organizations going in and fixing a lot of the vulnerabilities," says Jarrett. "And so we are seeing how far can you go when you set your mind to improving the quality of your software, and what can help you fix more vulnerabilities."

Image credit: Flickr

Keep learning

Read more articles about: SecurityApplication Security