OpenDaylight is implementing a "world-class" security process, after an embarrassing faux pas left a security hole unpatched for months, an OpenDaylight security team member says.

The OpenDaylight Security Response Team published its first new vulnerability report January 22 through the new process, coordinating disclosure with vendors and stakeholders with proper embargoes.

"From my perspective, the security response function is done," says team member David Jorm, product security engineer for IIX, an Internet peering provider. "It needs to be properly maintained. Obviously it can't be left to rot. We just have to keep it ticking along in the way it's set up."

The team and new process comes after OpenDaylight took four months to patch a serious vulnerability, reported by a security consultant over the summer and virtually ignored until the OpenDaylight Project finally patched the hole in December. (See OpenDaylight Patches 'Serious Vulnerability' – After Four Months.)

Although the security flaw never made it into production code from vendors, it underscored the need for a formal security process and team, set up in December. (See OpenDaylight Establishes Security Team.)

The team includes representatives of major OpenDaylight vendors, including Chris Wright, technical director of SDN at Red Hat Inc. (NYSE: RHT) and member of the OpenDaylight board; Ed Warnicke, principal engineer in the Research and Advanced Development group at Cisco Systems Inc. (Nasdaq: CSCO) and member of the OpenDaylight Technical Steering Committee; Ryan Moats, senior software engineer at IBM Corp. (NYSE: IBM) and TSC member; and Cisco's Robert Varga.

The OpenDaylight security process is roughly based on the procedure used by the OpenStack Security Vulnerability Management Team.

The next step is to set up a proactive security process. "What we have now is a world-class security response function," Jorm says -- to respond to vulnerability in published code. A proactive process will reduce security vulnerabilities in code before it ships. "It turns out that's really hard. It's something that proprietary software and open source projects have struggled with."

Tools to automate finding security vulnerabilities are coming to the fore, Jorm says. Ten years ago, the tools were not so great. "You could point a scanner at a network and get a list of 10,000 theoretical vulnerabilities," he says. That wasn't useful. Now, static analysis tools can parse code and highlight potential vulnerabilities without a high false positive rate. "It's ripe for us to automate that."

Also, currently available build tools have static analysis tests built in. When developers build the code, if the security test fails the build fails. Jorm would like to implement those kinds of tools for OpenDaylight.

Want to know more about SDN? Visit Light Reading's SDN technology content channel.

OpenDaylight also needs automated tools to scan for vulnerabilities in dependent packages in OpenDaylight -- prepackaged code developed outside the OpenDaylight process. "You can't expect the developers to subscribe to all those those mailing lists. Nobody does that," Jorm says. The process of finding vulnerabilities in dependent packages has to be automated.

Other steps include documenting security best practices, and eliminating default credentials for OpenDaylight that users might not change, leaving vulnerabilities, Jorm says.

Security in open source software like OpenDaylight becomes more important as more network operators move to directly connect their networks to cloud providers to improve performance and availability, says IIX CTO Paul Gampe. Those network connections and the cloud platforms are built using open source, therefore open source security is criical. "If we're going to make open source networking of value to the network, it needs to be more secure," Gampe says.

— Mitch Wagner, , West Coast Bureau Chief, Light Reading. Got a tip about SDN or NFV? Send it to [email protected].