Finding the flaws in software

Quote: “If you don’t ask for secure and reliable software, you’re not going to get it,” Stan Wisseman, Booz Allen Hamilton

Everyone agrees that the software quality should be improved -- from the system administrator whose network has been compromised to the home user whose PC has crashed. Major software vendors are on board the software assurance train, too. Microsoft and Oracle, for example, have programs to improve their product development.

So why are there still so many problems in software? Brian Chess, founder and chief scientist of Fortify Software, cited two problems: Technology, which is impossible to solve, and social practice, which is even harder.

On the technology side, no tool will ever be able to completely assure the absence of vulnerabilities, Chess said.

The math is complex, but “from a computer science point of view, it is a provably impossible problem” to solve, he said. “This turns it from a scientific endeavor to an engineering endeavor. We know we can’t be perfect, so how close to perfect can we be?”

On the social side, too many people involved in software development have not been paying attention to security for too long. “People have been writing code for 50 years, and until recently security was not a part of their job description,” Chess said.

Software developers are not necessarily being negligent or incompetent when weaknesses that could lead to malicious exploits creep into their code. Weaknesses in the code often are not readily apparent, and many get propagated as snippets of existing code are incorporated into multiple applications. Tools that analyze code or examine the behavior of an application can help spot these problems, but on their own they are insufficient.

“For several reasons, no tool can correctly determine in every conceivable case whether or not a piece of code has a vulnerability,” the National Institute of Standards and Technology said in the document specifying minimum requirements for source code analysis tools. “First, a weakness may result in a vulnerability in one environment, but not in another.” And theoretical limitations of analysis tools aside, “practical analysis logarithms have limits because of performance and intellectual investment.”

But even the imperfect tools that are available are seldom used to best advantage. In government agencies, security requirements too rarely are priorities in software development, and best security practices are too seldom applied in the development life cycle, said Steve Lavenhar, an associate at Booz Allen Hamilton. Security controls in government regulations focus on network issues, and software development typically is focused on functionality, he said.

“You’re dealing with a security mindset that is not focused on software,” Lavenhar said. “You don’t have a clear and well-defined basis for developing software from the beginning.”

Stan Wisseman, a senior associate at Booze Allen, said most software development still is on the front slope of the awareness curve. “You keep running into folks who just don’t get it,” he said.

However, Lavenhar is not a pessimist about software assurance. “If you look at where we were five years ago, things are a lot better,” he said. In the last two years, tools for evaluating the security and reliability of software have begun to mature, although even at their best, “no one tool is going to find everything.”

The scope of the challenge should not discourage programmers from trying to improve the quality of software, Chess said. “If people don’t have the will to try, you don’t make any progress.”

There are two basic approaches to code analysis: static and dynamic, each with its own strengths and weaknesses.

Static analysis analyzes at the source code, if it is available, and looks for potential problems. “You are going to get complete coverage and examine every line of code,” Chess said of this approach.

The downside is that the tool might not recognize every problem, and not all of the weaknesses it does identify will be significant. Another problem is that static analysis does not identify problems in the architecture of the software, Lavenhar said. A static approach might identify vulnerabilities in the code itself but miss problems with the way the code is put together and executes.

Dynamic testing, on the other hand, examines the behavior of a program while it is running and looks for problems. “You get very tangible results,” Chess said -- when you see a problem, you can be reasonably sure about how significant it is. “The downside is it is hard to get good coverage,” because a test situation cannot duplicate all of the states in which a program will operate.

The best bet is to use a combination of tools, with a variety of static analyses to identify possible problems, and dynamic analysis to prioritize those problems based on the behavior they create in the program.

In its special publication 500-268, “Source Code Security Analysis Tool Functional Specification,” NIST has spelled out the basic capabilities a code analysis tool should have, identifying 21 basic weaknesses -- from the Common Weakness Enumeration database maintained by Mitre -- that each should be able to identify. But the ability to identify a given weakness is not the only measure of how well a tool is working. There is a tradeoff between false negatives and false positives for which each tool must be adjusted.

“Since no tool can be omniscient, a tool may be written to be cautious and report questionable constructs,” the NIST document states. “Some of those reports may turn out to be false alarms or false positives. To reduce wasting users’ time on false alarms, a tool may be written to only report constructs that are (almost) certainly vulnerabilities. In this case it may miss some vulnerabilities,” or produce false negatives.

A tool that produces neither false positives nor false negatives is impossible, even in theory, NIST says. “Tools may use a combination of approaches to balance performance, false alarms and missed vulnerabilities.”

Because tools by themselves will not achieve the goal of reliably secure software, the Homeland Security Department’s Software Assurance Initiative has made technology only one of four main pillars of the program. The others are people, process and acquisition. People must be educated to produce reliable software, and processes must be put in place for developing and testing software to ensure its quality. But some observers say that software assurance is as much an acquisition issue as anything else.

“If you don’t ask for secure and reliable software, you’re not going to get it,” Wisseman said.

“This really is an acquisition problem,” said Jack Danahy, chief technology officer of Ounce Labs, which produces source code analysis tools. Requirements for security functionality and quality have to be spelled out. This is what the Defense Department and some other agencies are beginning to do, and vendors are becoming more proactive about the quality of their programming as they see these requirements in their contracts.

However, controlling the development of software throughout its lifecycle is complicated by the fact that most software written today is actually a patchwork of new and existing code, which interacts with additional code that often lies outside of the application.

“The applications aren’t homogenous,” Danahy said. “They are not one whole. There are a lot of component pieces that feed into it.”

As a result, ensuring the safety and reliability of that code becomes more difficult because it often comes from multiple sources.

“There are few organizations that write everything from start to finish,” said Peter Vescuso, vice president of business development for Black Duck Software. “It’s not competitive. Why reinvent the wheel?”

Back Duck’s Code Center tool is a platform for managing a heterogeneous environment by identifying open-source code that is incorporated in many applications. Open-source projects are gaining popularity as a source of reliable functional components that can be plugged into applications. There are hundreds of thousands of open-source projects and tens of billions of lines of code available for reuse.

A good argument can be made that because of the open nature of the development process and the number of eyeballs scanning the source code, open-source software is more secure and reliable than proprietary software. However, the quality, reliability and licensing requirements vary from one application to another, and from one version of an application to another. Code Center can identify the source of code in an application and back it up with a database with metadata to help manage the different pieces throughout the application’s lifecycle.

This does not guarantee security, but being able to identify the source of the code in an application can help in evaluating it.

Despite improvements in recent years in the quality of software and the ability of developers and users to evaluate it, software assurance remains an elusive goal.

“We’re making a lot of progress, but we’re still at the beginning of having the tool set that will address the problem,” said Booz Allen’s Lavenhar.

For the time being, the best advice for users is caveat emptor, Chess said. “It is up to the customer to assure that the person supplying the code understands the security concerns of the customer.”