Debunking Myths About Open Source Security

This blog post is an excerpt from GovLoop’s recent guide “7 Open Source Myths Debunked.” We spoke with a dozen government technologists, lawmakers and other experts to debunk common myths and help your agency make fact-based decisions about using open source. To view other myths, resources and facts about the state of open source adoption in government, download the full guide here.

One common myth of open source is that it is insecure. The rumor mill is that proprietary software is always more secure. Releasing source code makes it possible for attackers to construct highly targeted attacks against the software and build malware directly into the code.

Here are the facts.

Some open source software is secure and some is not — just like propriety software. So how do you know if the open source software you want to use is secure?

“You evaluate it,” said David Wheeler, an expert on developing secure software who helped develop the Defense Department’s open source policy. “One advantage of OSS is that you can easily evaluate it in more detail, and others can do the same. That doesn’t automatically mean the OSS is secure, but it does give you a better chance to understand your options.”

One of the big misconceptions is that anyone can change the kernel, or the core of an open source operating system, said Deborah Bryant, who also leads the Open Source Initiative’s public policy working group. “It’s a very disciplined, structured methodology, and there’s a gatekeeper that makes the decision about any code that goes in.”

Because everyone can look at the code, anyone can spot problems with it, including bugs, and report them.

In one DoD analysis of open source, one unexpected finding was the degree to which security depends on open source software. Banning it would remove certain types of infrastructure components that support DoD network security, according to the report. It would also limit the department’s access to and expertise in using powerful open source applications that hostile groups could use to help stage cyberattacks.

DoD is using open source software to support a number of missions, including a NATO mission to help advise Afghan officials on how to rebuild the country. The department’s digital team developed a beta version of the tool in less than four months and released the project on Code.gov. It enables NATO advisers to keep tabs on who has received training.

The DoD team installed the software on a classified secret server in Afghanistan, and then released the self-contained project as open source. Assuming all the information exchanged as part of the NATO mission is classified and confidential, wouldn’t releasing the tool as open source pose a national security risk?

The short answer: no. Open source doesn’t mean releasing personally identifiable information, Alvand Salehi, White House Senior Technology Advisor, said during a keynote at the May 2017 O’Reilly Open Source Convention in Austin. That information shouldn’t be a part of the code, whether it’s open source or not.

Some quick tips:

1. Newer developers are often familiar with open source software and instead of fearing it, they expect to use it.
2. Have a process in place for approving new open source projects, or else your team will be taxed with implementations and forced to support one-off projects.
3. If you’re managing an open source project, make sure to understand any gaps between your department’s needs and what the software can offer.