by clicking on the page. A slider will appear, allowing you to adjust your zoom level. Return to the original size by clicking on the page again.
the page around when zoomed in by dragging it.
the zoom using the slider on the top right.
by clicking on the zoomed-in page.
by entering text in the search field and click on "In This Issue" or "All Issues" to search the current issue or the archive of back issues respectively.
by clicking on thumbnails to select pages, and then press the print button.
this publication and page.
displays a table of sections with thumbnails and descriptions.
displays thumbnails of every page in the issue. Click on a page to jump.
allows you to browse through every available issue.
GCN : May 2016
WHITE HOUSE OFFICIALS want federal agencies to share more of their custom code with one another and 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 better software in the future, but is it also an opening for more bugs and insecure code? The new draft policy, issued in support of the Obama administration’s 2014 Open Government Partnership, seeks to improve the way custom- developed code is acquired and distributed. Before moving forward with the policy, the government has asked for public comments so that it can understand how the approach would “fuel innovation, lower costs, benefit the public and meet operational and mission needs of covered agencies.” Officials also want to know what effect the policy might have on the software development market. One thing the draft poli- cy 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 the experts who has expressed concern. In comments about the draft, he points out that the government’s testing of its own code for vulnerabili- ties “has been minimal and inconsistent.” That has sparked an interesting discussion about the government’s role regarding code released to the open-source com- munity. Pescatore said he believes scanning for vulnerabilities before code is released wouldn’t be a big deal. Others, however, believe that responsibility belongs to the open-source com- munity, which has long maintained that the more eyes the more secure the 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 Heart- bleed bug 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 govern- ment code released to the open-source community, it will be interesting to see which would turns out to bethebestwaytogo— especially considering that some of the code might find its way back into government use at other agencies. So sanitize before release or trust to the community to eventually secure it? Pescatore has his doubts. Software is software, he said, whether it’s open source or proprietary. And if simple vulnerabilities are not removed before it’s released, “it is bad software.” • Should we secure code before or after sharing it? BY BRIAN ROBINSON CYBEREYE 10 GCN MAY 2016 • GCN.COM What feds think of the open-source policy The Obama administration’s draft open-source policy drew more than 200 public comments. Among the highlights: “We submit that the open-source policy should apply across the government equally. It is worth noting that some agencies with a clear intelligence or national security mission are already posting some source code publicly.” — Department of Homeland Security’s National Cybersecurity Assessments and Technical Services “ The denominator of the 20% requirement [for publicly releasing code] should be the number of systems (as defined in the agency ’s system inventory) — not the # of lines of code under the agency ’s purview.” — Noah Kunin, director of delivery architecture and infrastructure at 18F “When managed appropriately, releasing code as [open-source software] and engaging with the community can have extensive cybersecurity benefits. Security through obscurity is not true security.” — DHS CIO Luke McCormack The full list of comments can be found at is.gd/GCN_code_comments. 0516gcn_010.indd 10 4/27/16 3:16 PM
March and April 2016
June and July 2016