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.
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 what they 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.
Sign up for Computerworld eNewsletters.