The Core Infrastructure Initiative revisited

Core Values

© Lead Image © Maxim Kazim,

© Lead Image © Maxim Kazim,

Article from Issue 199/2017

How does the Core Infrastructure Initiative fare three years in?

The Linux Foundation started the Core Infrastructure Initiative (CII) [1] after the discovery of several security vulnerabilities in 2014. As serious as the bugs themselves was the discovery that many core Linux projects were unequipped to respond to them. The CII was started in an effort to alleviate and prevent such bugs in the future. But how is the CII doing three years after its founding? For answers, I talked with Nicko van Someren of the CII.

According to van Someren, 2014 was marked by the discovery of a number of vulnerabilities. They included the ShellShock bug in Bash and a denial of service attack through the Network Time Protocol. However, the bug that received the most public attention was Heartbleed [2], which had infected the OpenSSL cryptography library for two years before its discovery. As Heartbleed was patched, it became obvious that the OpenSSL project, like many other Linux packages, lacked both the funding and the developers to respond adequately to such a threat.

The discovery of Heartbleed – deliberately named to attract attention – marked "the realization as to just how dependent commercial software has become on open source components," van Someren says. "The urgency of Heartbleed meant that vendors needed to fix things immediately and needed to tell people why." However, the CII is not just the software equivalent of a fire department responding to each crisis as it emerges. "Our goal with identifying projects that are at risk is so that we can provide help and resources – before – there is an urgent problem," von Someren says.

Identifying Projects at Risk

What puts projects at risk? As von Someren notes, the answer depends on the definition of risk. "There were a handful that needed urgent attention when we started the CII, and we have already worked with most of these," he says. However, "there are many more, dozens or hundreds of projects that are widely relied upon, but which don't have an active community to support them and which would struggle to respond in a timely manner if a vulnerability was ever found."

With limited resources, the CII must triage. Its first priority is projects "where providing resources will substantially improve the security of the Internet and of the businesses and society that depend on it." Another priority is underfunded projects that are not receiving funds from other sources. In both of these priorities, as I heard at a CII event at the 2015 LinuxCon, the CII is well positioned to help, because the Linux Foundation is often perceived as relatively neutral, and developers who would refuse direct funding from business interests may accept funding from the CII.

These priorities mean likely candidates for CII assistance include:

  • Tools and libraries critical to the functioning of the Internet, such as NTPD or Bash, that are not security tools themselves. Because such packages are widely used, vulnerabilities in them are likely to have a large effect.
  • Security tools and libraries, such as OpenSSL and GnuPG.
  • The development of security testing tools such as the OWASP Zap project, which assists in discovering security issues during development.
  • The development of tools that educate consumers and developers about security and encourage better practices and processes (see below).

"We try to look at all investment from a cost-benefit point of view," von Someren says. "While we do provide funds for maintenance activities, we would rather pay for work that has long-term value to the community rather than preserving the status quo."

Projects looking for CII support must explain how funding them will improve security in free software and describe the milestones they expect to reach. The CII and its Advisory Board members vote on proposals, sometimes setting conditions on support, such as requiring a Git repository. Some funding is by definition for limited duration, but, if necessary, funding can be renewed so long as "there is still work to be done, the team is still making progress, and the project is still a priority." Projects that fail to deliver are not renewed, and at times, shifting priorities means that "we will divert resources to where we think that they are needed the most."

Preventative Programs

As important as triage can be, CII is also attempting to prevent security problems before they emerge – a practice that should be more cost effective both financially and in terms of effort. With this goal in mind, it has used its Census [3] program to try and identify at-risk projects more reliably. The first Census collected data on package usage, bug density, developer response time, and community activity, resulting in a table of more than 170 potentially at-risk projects – many of which are tools that users depend upon on a daily basis. In 2017, says von Someren, "we are hoping to revamp this [program] to be a more continuous process, drawing data from more places, and looking at a larger set of packages."

CII also runs the Best Practices Badge Program [4], whose goal is to encourage projects to operate more securely on a daily basis. "We have found that many projects benefit from having a checklist of steps that they can take to make their process more secure." Many of these steps seem self-evident, but von Someren observes that even well-run projects "often discover things that they should have been doing all along."

Getting Results

CII has not always succeeded in its efforts. In particular, the early decision to fund both the Network Time Protocol project and its hostile fork NTPsec seems to have done little to solve chronic underfunding and staffing, leaving instead two rival projects [5] where only one existed before. Perhaps as a result of this chaos, the funding for neither project was renewed for 2017.

By contrast, von Someren reports that team members of OpenSSL, which was instrumental in the founding of CII, "now feel that they have moved from a firefighting mode to being able to work on developing new functionality" as a result of CII funding. Similarly the Best Practices Badge Program has had more than 600 projects signed up, with more than 60 meeting the standards required to obtain a badge.

"I think that the CII is making a valuable impact," von Someren says, "but there is always more to do. We have moved some projects off of the endangered list, and I think that, like some of our projects, we have moved from fire-fighting to a more forward-looking approach. Right now, we are resource constrained – we have more work that needs doing than money to do it, but I think that where we have been able to apply resources, we have enabled a bunch of open source projects to make themselves more secure."

Looking into the future, von Someren sees more of the same: more pinpointing of at-risk projects, more education of consumers, and more encouragement of developers to make security tools easier to user. "Many people like to say that security is not a feature, it's a process," he says. However, "I think that in open source software, security is a culture as much as it is a process" – and culture can be much harder to change than processes. Evaluating the last three years, the wonder is not that the CII has sometimes been restrained by its budget and the vagaries of projects, but that it has managed to become an effective presence in free software at all.


  1. CII:
  2. Heartbleed:
  3. Census:
  4. Best Practices Badge Program:
  5. "Paving with Good Intentions: The Attempt to Rescue the Network Time Protocol" by Bruce Byfield. The New Stack, March 13, 2017:

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Welcome

    The Linux Foundation launched the Core Infrastructure Initiative (CII) as a bold stroke in 2014. The foundation, which stands astride the FOSS world and mediates between the realm of business and the hacker culture, started the CII as a reaction to the infamous Heartbleed bug, which shocked the open source faithful and left doubts about the security of FOSS technologies. The original goal of the CII was to "fund and support critical elements of the global information infrastructure," which sounded like a good idea. I didn't have high hopes for them doing much besides giving out money, but money is always good. In the business world, where the Linux Foundation keeps one foot, if you can't make a problem go away by denying it, the next best thing is to pounce on it dramatically and say, "We've got this under control!"

  • Financing Crypto Projects

    Although open source crypto software is used virtually all over the world, the projects behind it are often small and chronically underfunded. Heartbleed, however, brings a possibility of improvement.

  • LinuxCon take-aways
  • New Attack Targets Wireless Logins

    A first cousin of the recent Heartbleed attack affects EAP-based wireless and peer-to-peer authentication.

  • Heartbleed Bleeds On

    According to a report, many potential victims of the Heartbleed attack have patched their systems, but few have cleaned up the crime scene to protect themselves from the effects of a previous intrusion.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More