CyberEye

Secure code before or after sharing?

The White House wants federal agencies to share more of their custom code with each other, and also to provide more of it to the open source community. That kind of reuse and open source development of software could certainly cut costs and provide more able software in the future, but is this also an opening for more bugs and insecure code?

The new draft policy, issued in support of the administration’s 2014 Open Government Partnership, is aimed at improving the way custom-developed code is acquired and distributed in the future. Before moving forward with this new policy, the government wants to know just how it would “fuel innovation, lower costs, benefit the public and meet operational and mission needs of covered agencies” as well as what effect it could have on the software development market.

One thing the draft policy doesn’t address directly is what impact government code could have on the security of any open source software that results. John Pescatore, director of emerging security trends at the SANS Institute, is one of those who has expressed concerns. In comments about the draft, he points out that government’s testing of its own code for vulnerabilities “has been minimal and inconsistent.”

That’s sparked an interesting back and forth about the government’s role regarding code released to the open source community. Pescatore believes scanning for vulnerabilities before code is released wouldn’t be that big of a deal. Others, however, think that responsibility belongs to the open source community, which has long maintained that “the more eyes, the more secure” open source code is.

Well, yes and no. That was the argument behind OpenSSL, for example, and yet a vulnerability that went unnoticed for years led to the global Heartbleed scare and fears of widespread data leaks and breaches.

However, it’s also true that open source code has consistently been found to be more secure than most proprietary code, though it’s not infallible by any means. In the case of government code released to open source, it will be interesting to see which would be the best way to go -- especially considering that some of that code may find its way back into government use at other agencies. So, sanitize before release, or trust to the community to eventually secure it?

Pescatore, at least, has doubts. Software is software, he believes, whether open source or proprietary. And if simple vulnerabilities are not removed before releasing it, “it is bad software.”