Many agencies in the federal government use approved public repositories for open source software development. According to the General Services Administration (GSA) GitHub dashboard, there are 236 federal organizations using a combined 5,254 project repositories.
More federal agencies are increasing their use and creation of open source software to achieve their IT objectives. In order to best prepare for the implementation of even more open source projects, federal agencies need to understand the facts among the many misconceptions and myths surrounding public repositories.
What's mainly driving the increased use of open source in federal agencies is the reduced costs of a shared platform; however, Jay Jaiprakash, director of technology, Sapient Government Services said, "The shift to open source requires looking at several factors, such as culture, innovation, and architecture to be able to successfully employ the software."
Security practitioners in federal agencies shouldn't be bamboozled by the bandwagon effect of propaganda. Before making the jump simply because everyone else is doing it, it's important that they know their agency.
[ ALSO ON CSO: Your open source security problem is worse than you think ]
"Specific to culture and innovation, an agency must develop the right environment from how new ideas are rewarded to having the right policies. The governance and security teams should collaborate as the combined expertise benefits everyone from the latest ideas to the new enhancement," Jaiprakash said.
In addition to the cost benefit, Jaiprakash said, "Open source provides agencies the opportunity to seek the best solution as they are not tied down to a vendor, their products or upgrade paths."
Because the security ecosystem is forever changing, shared platforms allow for unforeseen circumstances, so Jaiprakash said, "As the agency evolves, this flexibility allows for switching out technologies that don’t work or moving towards a loosely coupled or decoupled architecture, enabling even more flexibility to take advantage of open source components."
According to 18F's "Facts about publishing open source code in government," written by Britta Gustafson and Will Slack, one myth about open source specific to federal agencies is that, "Public repositories are an emerging technology without widespread government use. The people using them are probably not paying full attention to compliance.”
Jaiprakash said, "Although the security risk profile for open source can be considered higher than with propriety software, open source actually includes more testing and reacts quicker with fixes due to the community participation and volume of users."
Another myth Gustafson and Slack challenged is the notion that, "“Public repository hosting services are social networking tools with dubious collaboration features; using them would lead to our projects getting unreliable external code mixed into our official work.”
The truth, said Gustafson and Slack, who referenced the specific policies of 18F as an example, is that federal agencies are actually able to fully control access and permission for their shared repositories.
Establishing controls and policies is critical for protecting these official repositories. said Jaiprakash. "Overall, federal agencies should use caution bringing in any open source software and have the right set of governance deployed as security is always a concern with any product," he continued.
[ RELATED: Open source security is not as big of a concern as it once was ]
Still many remain tentative about making a shift to open source. Mike Pittenger, vice president of security strategy at Black Duck, said, "It becomes a religious argument at some point. It's neither more or less secure."
Instead, what is most important about open source is the characteristics that make it attractive to an attacker. "It's used everywhere. If you're an attacker, you try to find the path of least resistance. The target has to be worthwhile, so you go after a target rich environment," Pittenger said.
Most of the risk from open source is when they don't manage it well. "They have no support model unless it's paid support. There is no [service-level agreement] that you would have with the vendor," Pittenger said.
Because most organizations really don't know what they are using in their open source projects, they have no controls. "If we purchase a license from a vendor, we have an SLA, they are required to push out a patch. Open source has the exact opposite," Pittenger said.
When an agency elects to use code from a public library, the onus of responsibility is then on them to monitor that code. "It's only risky if you aren't keeping track of what you are using," Pittenger said, "but if I didn't use open source, I'd have to write everything from scratch."
While many agencies are reliant upon open source, those who make the investment in tracking use are in the minority, said Chris Eng, vice president of research at Veracode.
"Most people are using open source somewhere. Nobody is writing a completely new piece of software from scratch. They are always using libraries, or sometimes it's a mix of commercial and open source," said Eng.
The risk is that most of those people have little visibility into exactly what they are using. "Developers use a library for this and a library for that. No one is keeping track of what all those things are, which makes it tougher to track, especially when a Heartbleed comes out," said Eng.
When security practitioners or even developers don't know whether what they are building has a particular component, they can't properly monitor. This lack of visibility of what is going into the software is the security risk for both commercial and open source, said Eng.
"Large development teams don’t want to reinvent the wheel, so they grab from a library to do that. If I want to add a feature that will upload profile photos, I'm not going to write new code that will let me, I’m going to use an image processing library to do that," Eng explained.
The problem is that there is no centralized place where people keep track of all the different versions of the library. "Once it's working, they don’t go back and keep those up to date. When a vulnerability is found, they update with new versions. Your product becomes more and more vulnerable because it's inheriting all those vulnerabilities," Eng said.
Not keeping track of what they are using or keeping their products up to date is more a function of the lack of a centralized process rather than a technical challenge.
Eng said, "Adding open source doesn’t make this problem any better or worse. There is an old myth that because open source projects are freely available and anybody can look at the source code that so many eyes means bugs will get patched."
This myth has shown time and time again not to be true. "Even a lot of eyes are not necessarily equipped to find security issues. I would caution anybody looking to go more toward open source because they think it’s more secure because it is not," Eng said.
It's important to know who is backing it, how many developers are behind it, and how widespread is its use. "Understand what is going into your software. Keep track of what vulnerabilities are being discovered. There are a lot of known vulnerabilities out there," Eng said.