For years, security experts and thought leaders have railed against the concept of “security through obscurity” – the notion that you can keep vulnerable software secure just by preventing others from understanding how it works. Corporate executives worried about relying on open source operating systems and software like the Linux operating system – whose underlying source code was managed by volunteers and there for the whole world to see. The answer to such doubters was the argument that open source was more secure (or, at least, no less secure) than closed source competitors precisely because it was open. Open source packages– especially widely used packages– were managed by a virtual army of volunteers. Dozens or even scores of eyes vetted new features or updates. And anyone was free to audit the code at any time. With such an active community supporting open source projects, developers who submitted sub-par code or, god forbid, introduced a bug, vulnerability or back door would be identified, called to task and banished. That was a comforting notion. And there are certainly plenty of examples of just this kind of thing happening. (Linux creator Linus Torvalds recently made news by openly castigating a key Linux kernel developer Kay Sievers for submitting buggy code, suspending him from further contributions.) But the discovery of the Heartbleed vulnerability puts the lie to the idea of the ‘thousands of eyes’ notion. Some of the earliest reporting on Heartbleed noted that the team supporting the software consisted of just four developers – only one of them full time. “The limited resources behind the encryption code highlight a challenge for Web developers amid increased concern about hackers and government snoops,” the Wall Street Journal noted. OpenSSL Software Foundation President Steve Marquess was later asked about security audits and replied, “we simply don’t have the funding for that. The funding we have is to support food and rent for people doing the most work on OpenSSL.” So does Heartbleed mean a shift away from reliance on open source? Is it a final victory of security-through-obscurity? Not so fast. As I noted in my post last week, vulnerabilities aren’t limited to open source components – any third party code might contain potentially damaging code flaws and vulnerabilities that escape detection. Akamai learned that lesson the hard way this week with a proprietary code the company had been using to do memory allocation around SSL keys. The company initially claimed the patch provided mitigation against the Heartbleed vulnerability and contributed it back to the OpenSSL community. But a quick review found a glaring vulnerability in the patch code that, combined with the Heartbleed vulnerability, would have still left SSL encryption keys vulnerable to snooping. “Our lesson of the last few days is that proprietary products are not stronger,” Akamai’s CSO Andy Ellis told me in an interview. “So, ‘yes,’ you can move to proprietary code, but whose? And how can you trust it?” Rather than run away from open source, Ellis believes the technology community should ‘lean in’ (my words not his) and pour resources – people and money - into projects like OpenSSL. But how? Casey Ellis over at the firm BugCrowd has one idea on how to fund improvements to- and a proper audit of OpenSSL. He launched a crowd-funded project to fund bug bounties for a security audit of OpenSSL. “Not every Internet user can contribute code or security testing skills to OpenSSL,” Ellis wrote. “But with a very minor donation to the fund, everyone can play a part in making the Internet safer.” A paid bounty program would mirror efforts by companies like Google, Adobe and Microsoft to attract the attention of the best and brightest security researchers to their platform. No doubt: bounties will beget bug discoveries, some of them important. But a bounty program isn’t a substitute for a full security audit and, beyond that, a program for managing OpenSSL (or similar projects) over the long term. And, after all, the Heartbleed vulnerability doesn’t just point out a security failing, it raises questions about the growth and complexity of the OpenSSL code base. Bounties won’t make it any easier to address those bigger and important problems. As I noted in a recent article over at ITWorld, even companies like Apple, with multi-billion dollar war chests and a heavy reliance on open source software are reluctant to channel money to the organizations like the Apache Software Foundation, Eclipse or the Linux Foundation that help to manage open source projects. This article over at Mashable makes a similar (albeit broader) argument: if companies want to pick the fruit of open source projects, they should water the tree as well. In the end, there’s no easy solution to the problem. Funding critical open source code is going to require both individuals and corporations to step up and donate money, time and attention – whether through licensing and support agreements, or as part of a concerted effort to provide key projects with the organizational and technical support they need to maintain and expand critical technology platforms like OpenSSL.