Open Source

DHS warns on cyber risks of open source

Shutterstock image for a line of faulty code.

The Department of Homeland Security has suggested striking significant passages from a draft White House policy on open software out of concern that baring too much source code will increase the government's vulnerability to hacking.

Many private security firms don't publish their source code because it allows attackers to "construct highly targeted attacks against the software" or "build-in malware directly into the source code," DHS said in comments posted to GitHub. The comments were attributed to DHS' CIO office.

The DHS feedback reflects an administration that is mapping out the benefits and potential drawbacks of making more government code public.

The draft policy, released for public comment in March, asked agencies to partake in a three-year pilot program requiring that at least 20 percent of custom code be published. The goal is to save money and spur innovation by making the software used by agencies more open, sharable and reusable.

For some open-source advocates, the 20 percent benchmark is too low.

"In a world increasingly dominated by the success of open source, requiring that the world's largest producer of code release only 20 percent of its software is a missed opportunity to modernize government," GitHub project manager Ben Balter wrote in an April 11 op-ed in FCW.

But the DHS comments were rife with concerns about source code-enabled vulnerabilities.

"Government-specific" examples of source code risks listed by DHS include the "mafia having a copy of all FBI system code" and terrorists accessing air traffic control software. "How will this be prevented?" the department asked. The department requested that those drafting the policy provide a rationale for the 20 percent baseline.

DHS, whose mission includes civilian cyber defense, also asked that the policy set clear guidelines for publishing source code used in "inherently government functions," such as law enforcement and security.

"The policy seems to rely on the CIO's best judgement [sic], but does not sufficiently address the procedures necessary for agencies to make proper determinations," the DHS comments said.

DHS also requested an analysis of how publishing source code affects government software development.

The comment period on the draft policy, originally slated to close April 11, has been extended to April 18.

About the Author

Sean Lyngaas is an FCW staff writer covering defense, cybersecurity and intelligence issues. Prior to joining FCW, he was a reporter and editor at Smart Grid Today, where he covered everything from cyber vulnerabilities in the U.S. electric grid to the national energy policies of Britain and Mexico. His reporting on a range of global issues has appeared in publications such as The Atlantic, The Economist, The Washington Diplomat and The Washington Post.

Lyngaas is an active member of the National Press Club, where he served as chairman of the Young Members Committee. He earned his M.A. in international affairs from The Fletcher School of Law and Diplomacy at Tufts University, and his B.A. in public policy from Duke University.

Click here for previous articles by Lyngaas, or connect with him on Twitter: @snlyngaas.

Cyber. Covered.

Government Cyber Insider tracks the technologies, policies, threats and emerging solutions that shape the cybersecurity landscape.


Reader comments

Fri, Apr 15, 2016 Brent Turner

Hopefully DHS conducts an internal education campaign to thwart vendor disinformation Sensitive software is listed as FOUO - For Official Use Only - and that information is restricted internal only. There are review procedures in place. No one is going to publish anything that would be an at risk disclosure.I see this is just drum beating to ensure that there is no rolling back in these areas. it's ironic that DHS provided their comments in the form of an Excel spreadsheet, which is itself a proprietary format that requires Microsoft software to read natively.

Thu, Apr 14, 2016 Pat

Open source is not a new trend, why are they talking about a 3 year pilot? Open source has been piloting for over two decades by now..

Tue, Apr 12, 2016

The only true risk with open source is that a Chinese or Russian agent may be able to sneak in a back door into the source code that is not obvious to the (paid or unpaid volunteer) editors that are responsible for accepting the modification. Any truly secure piece of software will need a full audit of all code. As we are talking about projects, like Linux that are several million lines, it is not possible with the resources we have today. Therefore, we need to develop artificial intelligent auditor agents that can do this for a more reasonable cost. This is perhaps 10 years away. Note that closed source proprietary code has the same problem -- any piece of code that has portions which can be committed by those without a security clearance is susceptible. Unfortunately for closed source, there is no way to validate that the source code is clean of back doors.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group