The Linux Foundation started the Core Infrastructure Initiative (CII) 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, 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 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, 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 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.