This month marks the three year anniversary of the formation of the Core Infrastructure Initiative. It’s also the third anniversary of the Heartbleed vulnerability that served as a wake up call for the industry and which was a catalyst for the creation of the CII. For those not immersed in the security or technology industries, that bug revealed just how widespread and critical open source software is to the Internet’s infrastructure. The simple yet damaging security vulnerability uncovered in the hugely popular OpenSSL software had an enormous impact, in some cases allowing attackers to steal passwords, private keys, credit card numbers, financial information and more. At the time, it was estimated that almost one in five secure web servers were vulnerable to attack.
That episode also exposed limitations to Linus’s Law “many eyeballs make bugs shallow.” While in theory the openness of open source allows for huge numbers of people to get involved in checking the source, when software lacks an investment commensurate with its importance, we’re all at greater risk.
To help correct this, the Linux Foundation mobilized to form the Core Infrastructure Initiative. Twenty industry giants, including many of the world’s largest software companies, joined us in our initial mandate to secure the projects that are most critical to businesses on the Internet. To achieve this we set out to identify projects at risk, understand their needs and provide them the resources necessary to both make them more secure in the short term and stay more secure in the long term. As reportedat the time in The Economist, “OpenSSL, with its single main developer scraping by without a fair salary, was highlighted as a project that needed most attention.”
Less Fire-Fighting, More Strategizing
So three years in, are open source software vulnerabilities still as big a problem? Has the awareness raised by Heartbleed had a positive impact on online security and open source management? What have we been able to to do the make things better?
Firstly, of course software vulnerabilities are still a problem, in open source and in closed source. Sadly this is likely to be the case for quite some time. As long as software is specified by and written by humans this isn’t changing anytime soon. That said, we have made tremendous progress in the last few years.
Heartbleed uncovered a major gap in how we protect and secure the technology we use everyday. It showed us there is a major need to build a pre-emptive and collective system, absent of any one company’s individual priorities, to safeguard the Internet today and into the future. Quantitative and qualitative analysis of security of software, both closed and open, helps safeguard corporations and individuals.
I’m proud to say CII has made real progress and achieved many of our initial objectives, including our goal to make OpenSSL significantly more secure. Funding from CII has facilitated the fixing of many of its bugs and importantly reduced the chance of introducing new bugs. The OpenSSL team has indicated that it has moved from being in “firefighting mode” and are now more actively able to pursue strategic approaches to securing the project. Static and dynamic analysis are regularly performed as well using dynamic fuzz testing tools like AFL. In a few weeks time, we will be releasing results from an external audit of the OpenSSL code base that CII funded. The OpenSSL project now has a well-defined and published approach for how it will informs all interested parties of security advisories. The project is more secure than it was three years ago, both in terms of the code and the process, and we are delighted to have been instrumental in helping this happen.
Beyond OpenSSL, the CII has provided direct funding for architectural, development and testing work for dozens of other projects, relieving some of the financial pressure felt by many of their developers and allowing them to reduce technical debt and make structural improvements that will pay dividends into the future. Details of many of the successes from 2016 can be found in our most recent annual report.
Early on we recognised that we needed to apply quantitative and qualitative measures to find where risks lay. Our first CII Census project used a variety of metrics around bug density, developer community engagement, the number of security vulnerabilities and download and usage statistics to help identify open source components might be sources of risk and help target these for support. I am pleased to say that the CII members recently voted to extend funding the Census project to allow it to expand the number of packages under consideration, draw more detailed usage data from more sources and provide more continuous updates so that we can track projects as they improve (or, hopefully rarely, get worse).
Another success is the CII Best Practices Badge, which uses a qualitative self-assessment approach whereby open source project participants can grade themselves against a set of Best Practices for Open Source Development. Since formally launching in May 2016, more than 700 projects have signed up for the process and more than 70 projects have earned the badge.
We specifically reached out to both smaller projects, like cURL, and bigger projects, like the Linux kernel, to make sure that our criteria made sense for many different kinds of projects. The list of projects that proudly display the badge continues to grow — GitLab, Node.js, OpenBlox, OpenSSL, OpenStack, OPNFV, and Zephyr. The CII Badges program continues to evolve with work underway to introduce new badge levels to provide more sophisticated criteria.
Going forward we see the CII needing to do less fire-fighting and being able to apply more strategy. While we don’t expect to see an end to the need for supporting important maintenance work and to underwrite “orphaned projects,” many of our most successful initiatives have been the ones that have allowed us to help hundred or thousands of open source projects, rather than supporting them one at a time. The Best Practice Badge has helped hundreds of projects review and improve their security process. The Fuzzing Project has also applied dynamic fuzz-testing tools to hundreds of projects, while the Reproducible Builds project has helped enhance the build systems of tens of thousands of projects. We are also supporting the ongoing development of open source security testing tools ranging from the OWASP ZAP project to the Frama-C static analysis tools
Maintaining the code that we depend upon is still very important but we also need to build systems that allow us to help a much wider open source community. Thus, while our initial mandate was to target the projects that are most critical to businesses on the Internet, the CII is targeting the broadest range of projects possible within this remit — established and new, large and small, infrastructure and front-facing — in order to make the biggest impact possible. Below is a chart that shows our spending pattern over the last year. As time has gone by, the CII funding is moving up and to the right as we assign more funding to projects with continued high impact. We expect this trend to continue.
The first graphic titled “Annual Investment in Project” shows the current state of confirmed spending through 2017. The second one, titled “Total Investment in Project,” illustrates CII spending since our start three years ago.
New Structure Expedites Funding Decisions and Grant Dispersal
As we enter our fourth year, the CII has also made some changes to its membership structure. We need to be able to expand our membership, and we need to be able to make decisions quickly. To that end, earlier this year we updated our charter and and introduced new membership levels, creating a smaller, elected Steering Committee (SC) and a new Investment Committee (IC). With these changes, CII’s committees are more empowered to make swift decisions related to the organization’s operations and distribution of funds. Additionally, the CII charter now explicitly calls out the Steering Committee’s role to provide governance, oversight and audit of the CII and the role of a separate Investing Committee that will determine funding of specific projects.
Having two committees with more distinct areas of focus also means CII members are able to nominate someone from their legal and/or Open Source teams to work on governance issues, and appoint someone with domain expertise to vote on grants and funding decisions.
CII also introduced Platinum and Gold membership levels. The only difference between them is whether the member gets automatic representation on the CII Steering Committee (for Platinum members) or gets to vote to elect SC representatives (for Gold members).
Aside from now having an elected steering committee rather than direct representation, CII has also changed the way in which we vote on which projects we want to fund. Previously we needed to have a majority of members vote in favor of a project. Now we open voting for a period of three weeks and require a majority of votes cast in that window in order to accept the proposal. Voting can also close early once more than 50 percent of members have voted one way or the other. With these changes, all members are able to have their say, but never hold up the voting process. We believe that these streamlined procedures will allow us to get the resources where they are needed more quickly and also ensure that when great open source developers are available we can snatch them up quickly before they take a job elsewhere.
We’re proud of the progress we’ve made in the past three years. We took on a huge and open-ended challenge. By its very nature we will likely never be “done,” but it is clear that
we have already made a significant impact. Going forward we will continue to build better open source security tools, drive better security processes and support the communities that are building the technology on which we all depend. We will also continue to support many of the teams that toil to maintain the old foundation stones of the Internet, some of which go back decades.
We look forward to the next three years!
