A new NIST reports details how to rid software of bugs.
A new NIST reports details how to rid software of bugs.

A just-released report from the National Institute of Standards and Technology (NIST) offers advice for how coders could adopt their approaches to make software less vulnerable.

The 60-page publication [pdf] from the measurement standards laboratory, an agency of the U.S. Department of Commerce, gathers intelligence from across industry and other sources on how to rid software of bugs. Paul E. Black, a computer scientist at NIST and co-author of the report, said the content is applicable to any organization looking to rid its coding of flaws.

"The 'new idea' is that software can be produced with orders-of-magnitude fewer bugs at costs similar to today's," Black told SC Media on Tuesday. "It takes discipline and commitment to write solid code, the adoption of existing proven approaches, and investment in training and tools. But the techniques and technologies in the report have already shown their value and aren't new in the usual sense."

NIST assembled ideas from software assurance experts from a variety of private companies in the computer industry, along with several government agencies, including the Department of Defense and NASA.

The conclusion was that vulnerabilities are all-too common in software. By minimizing their presence, the report stated, benefits would include a reduction in the frequency of computer crashes and the necessity of users rebooting systems, as well as freeing users from the need to continually institute patches to update software.

At the core of the report are five sets of approaches, tools and concepts that NIST believes can assist coders:

  • using math-based tools to verify the code will work properly;
  • breaking up a computer's programs into modular parts so that if one part fails, the whole program doesn't crash;
  • connecting analysis tools for code that currently operate in isolation;
  • using appropriate programming languages for the task that the code attempts to carry out; and
  • developing evolving and changing tactics for protecting code that is the target of cyberattacks.   

Additionally, the document offers recommendations for how programmers can further educate themselves in the use of these strategies.

“You as a consumer should be able to write it into a contract that you want a vendor to develop software in accordance with these principles, so that it's as secure as it can be,” Black said.

The report is a response to the White House's 2016 Federal Cybersecurity R&D Strategic Action Plan [pdf]. But Black said the security strategies outlined can be applied throughout the coder community.

“Security tends to bubble to the surface because we've got adversaries who want to exploit weaknesses,” he said, “but we'd still want to avoid bugs even without this threat. The effort to stymie them brings up general principles. You'll notice the title doesn't have the word ‘security' in it anywhere.”

Reducing flaws in software is essential, he said, if the software matters at all to a smooth-running society. "We rely on software so much that the old slam-out-code-and-patch approach is inadequate. I wouldn't be happy if I bought a brand new car that is recalled three times in the first year to fix problems. Why should we put up with code that is inadequately engineered?"

To stress the security implications of faulty software to coders and developers Black said it's necessary to show them a dozen recent stories of security breaches in code like theirs. "Run them through a week-long exercise of cracking software. It won't turn them into cybersecurity experts overnight, but it will give them a healthy caution about how someone figures out a way to exploit their bugs."

Generally, coders are aware of the necessity for software without flaws, he explained, but it is often buried in the pressure to add the latest features or reach next quarter's goal. 

"One gum wrapper is not going to spoil Yellowstone National Park," Black said. "But if everyone threw their trash all over, we would lose a great resource. Our software can be a slapdash collection of stuff that kind of pretty much works, or it can be a legacy that we are proud to leave to those who come after us. The choice is ours."