Heartbleed, the OpenSSL vulnerability discovered last week that allows the exploit of SSL heartbeats, had many IT administrators scrambling to determine the extent to which their infrastructure and apps were at risk.

Most stories focused on the potential impact to the Internet, with high estimates claiming more than 65 percent of web servers could be vulnerable. (If you consider both Apache and nginx use OpenSSL and have a combined active site market share of more than 66 percent, it actually may not be such an outlandish number.)

But more troubling, in my mind, are all the other underlying components of our communications infrastructure that were put at risk and what this means in software-defined networking (SDN) and network functions virtualization (NFV) environments. It has been widely reported the networking biggies acknowledged their routers and switches were infected. From a SDN and NFV standpoint, the implications could be great and inherently more difficult to identify.

For example, most OpenFlow environments use some version of SSL to secure communications between the switches and routers, many of which are using OpenSSL. In the typical case of using an OpenFlow connected by Open Vswitch (OVS), OpenSSL is used. Vendors need to take into account not only which of their solutions use the affected OpenSSL versions (1.0.1a through 1.0.2beta), but also whether their underlying software environment is at risk.

Given the complexity, it’s not surprising we are still seeing updates on a daily basis since the April 7 exposure of the vulnerability.

Cisco has a long list of offerings it is still investigating, including the Cisco OnePK All-in-One VM. Meanwhile, HP issued an advisory (PDF) saying “the vast majority of HP networking hardware and software platforms and packages… are not vulnerable due to the either using a version of OpenSSL that is not vulnerable or not using OpenSSL.” (HP's emphasis.) However, while HP's VAN SDN controller itself wasn’t vulnerable, the “Ubuntu host operating environment and certain versions of Ubuntu (including version 12.04 LTS that is compatible with with HP VAN SDN controller) have been identified as vulnerable.”

It should be noted that NOX uses OpenSSL, as does the Beacon controller [Update 11PM PT: Correction — Beacon is not impacted, per Dave Erickson in the comments below the post] and its subsequent derivatives (e.g. Opendaylight (ODL)'s controller, Floodlight, etc.) may run on systems using OpenSSL, which means that these solutions may need to be assessed, potentially patched and then tested.

In looking at the implications of Heartbleed, it’s not merely the security risks the vulnerability poses that should give us pause. It’s the ease with which a flaw with far-reaching implications can be introduced to our communications ecosystem. The OpenSSL Project is made up of volunteers, with only one full-time employee, according to the Wall Street Journal.

Much of what we have today in the SDN and NFV market gets its roots from open-source software and engineering. There are great benefits to open-source, but there can also be risks, as we have learned with Heartbleed — a volunteer coder unintentionally introduced the vulnerability while working on some bug fixes. As we go forward re-imagining the architecture and possibilities of the underlying network, we need to consider its safety every step of the way. We need to test with rigor and be open to criticism and review to ensure we are doing our utmost to minimize risks. The future of our networks depends on it.