Linux Foundation Proposes Open Source Best-Practices Badge

8 Linux Security Improvements In 8 Years

The Linux Foundation is establishing a symbol -- what it calls a best practices badge -- that will be displayed on open source projects that follow recommended security and software stability practices. The badge will act as a Good Housekeeping Seal of Approval for projects that live up to the best practices.

The badge program is the brainchild of the foundation's Core Infrastructure Initiative (CII), which has surveyed key pieces of open source code, such as OpenSSL and Network Time Protocol, to see which projects are worthy of its support. The CII steering committee just announced a $7,000 per month grant for NTP lead maintainer Harlan Stenn and additional grants to two related projects. In June it approved $500,000 over the course of the coming year to support three other Internet security projects.

On Tuesday, Aug. 18, the foundation posted on Github a draft badge plan by David A. Wheeler, a security research expert who works for the Institute for Defense Analyses, and Dan Kohn, a CII senior advisor.

The pair is seeking feedback from open source developers on the requirements for projects to earn the CII badge. The program will be voluntary. Among other things, the code will be subject to a peer review and a static analysis that puts it through an automated inspection, such as a Black Duck, Klocwork, or Coverity scan, that searches for known vulnerabilities.

[For an example of the concerns, see how key Internet timing code can get out of joint. See Leap Second Clocks In On June 30.]

Previously, the CII concentrated on identifying pieces of open source code on which the Internet depends that are barely maintained or underfinanced. The badge program is the opposite approach. Instead of focusing on existing problems, the initiative would try to prevent the next generation of problems from occurring in the first place.

"If we could get a culture of secure coding, everybody would be better off," said Jim Zemlin, executive director of the foundation, in an interview.

"The goal is to eventually create a 'badging' program where open source software projects that meet the criteria can voluntarily self-certify that they meet the criteria and then be able to show a badge," wrote Wheeler in the introduction to the draft.

{image 1}

Many of the criteria will be simple and straightforward. For example, one criterion is that a project have a stable website based on https, not http. The site must describe what problem the software solves in language with a minimum of technical jargon. It must also "provide information on how to get the software, how to send feedback (as bug reports or feature requests), and how to contribute," the draft says.

An open source project must have a public source repository that controls versions and tracks what changes are made, who made them, and when they were made. The site must have a bug reporting process "where developers will respond. There MUST be responses to bug reports," the proposed plan says.

The project should have an automated build system that performs builds with the same steps in the same order each time. When there is no working build system, "potential co-developers will not be able to easily contribute and many security analysis tools will be ineffective," the draft states. Whenever possible, common open source tools, such as Maven, Ant, cmake, make, autotools, and rake, should be used.

A well-run project will have and use an automated test suite that's invoked in a consistent way. The test suite ideally will cover all code branches, input fields, and functionality.

Focus On Security

When it comes to security, the proposed criteria get stricter and more mandatory: Project code must delivered already protected against man-in-the-middle attacks, where an imposter modifies the downloaded code after it's come out of the repository and is on the way to its destination. A digital signature is recommended if the security of the public keys can be assured.

Vulnerabilities must be reportable to project leaders while protecting the privacy of the reporter. An initial reply to a report must be provided in less than seven days, and there may be no unpatched vulnerabilities of medium or high severity that have been publicly known for 60 days or more. The acceptable time period for a public vulnerability to remain unpatched is a subject of debate, the draft notes.

Projects will assess themselves against the criteria to determine whether they meet the standard to show the CII's best practices badge. Security has been a primary concern since the Heartbleed vulnerability was discovered in April 2014 to be affecting the operation of OpenSSL cryptography. The exposure, which affected potentially 66% of the world's websites, was a buffer that would accept more information than necessary, then allow the Transport Security Layer heartbeat function to execute it.

OpenSSL was missing a bounds check on the information put into the buffer, a relatively simple problem to cure. But it was a problem that could have allowed many corrupted processes to proceed if left unpatched. The fact the exposure was in a commonly used open source security measure was a wakeup call on how many vulnerabilities might be embedded in the Internet's everyday operations.