The Core Infrastructure Initiative last week announced a program that will offer badges to open software developers who follow best practice software development and security procedures. CII announced the free Badge Program at LinuxCon/CloudOpen North America.
The CII, a project of the Linux Foundation, enables technology companies, industry stakeholders and software developers to collaborate on the identification and funding of critical open source projects in need of assistance.
The first phase of the badge program seeks input from the open source community on criteria to determine the security, quality and stability of open source software.
This flushing-out stage involves talking to project maintainers and developers, said Amanda McPherson, VP of developer programs at the Linux Foundation.
The initial activity will involve signing up projects to develop the criteria, she added.
“Once we feel we are at a good level there, we are going to initiate an agreement program to display the badge. The time frame for qualifying projects displaying the badges is the first quarter of next year,” McPherson told LinuxInsider.
Need vs. Ease
Open source expansion is driving the need for better software standards, McPherson observed.
Almost every industry leverages open source and is more interconnected and dependent on it than ever before. Despite the prevalence of open source software, both seasoned CIOs and developers face a complex problem when trying to determine the best-maintained and most secure open source software to use, according to the Linux Foundation.
The self-assessment process and the badges that follow provide a simple way for projects to showcase their commitment to security and quality. The best practices criteria are meant to encourage open source software projects to take positive steps with both security and quality in mind, the foundation explained.
“We are not branding a project in terms of security ratings,” McPherson said. “What we are saying is, these projects have a way of proactively receiving problem notifications and handling bugs in a good way, and proactively looking for adherence to the criteria.”
Questions Ahead
Having a standard for reviewing software quality is good, but it might be hard to implement, noted Alan Canton, managing partner at NewMedia Create.
“The foundation will have to make sure that the solution it proposes and adopts is not worse than the problem it is trying to solve,” he told LinuxInsider.
There are numerous questions about how the criteria would be developed and reliably applied, Canton pointed out. There is no agreement on the criteria for a locked-down program, for example, nor on how the foundation would determine those criteria.
The testing and inspection processes required to earn a badge could be so cumbersome that they would dissuade developers from entering the program, Canton suggested. Uniform testing for all products might not be viable; further, testing that involves competing projects or companies might not be objective.
Building the Standards
The first draft of thecriteria, available on GitHub, includes general best practices combined with questions specific to security.
A questionnaire for open source communities interested in participating asks if a project includes an OSS license, a public version-controlled source repository, a general mailing list, an automated regression test suite, and at least one static analysis tool applied to source code to look for vulnerabilities.
“I talked to a project recently that was developing a vulnerability and security advisory notification product,” the Linux Foundation’s McPherson said. “Its delivery method actually defaulted to an HTTP protocol. A security researcher did notify them, so the many eyes concept did actually work, but this project had been that way for years.”
Challenges and Risks
“If CII and the Linux Foundation can go with the best practices, the result will ensure that everybody is on the same baseline,” McPherson said.
“The goal ultimately is to develop education so that when new developers come along, using best practices will not be an issue,” she explained. “I do not think we are going to have a fight over this. Everybody we have talked to seems to think that this is a good idea. I think the biggest challenge we will have is garnering excitement around it.”
Another challenge could come from people saying this is just a paperwork exercise, McPherson acknowledged. Even projects that have been certified to the highest levels of common criteria still can have security vulnerabilities.
Perceptions might play a role in whether the badge concept can result in better open source software, suggested Tom O’Connor, Linux product engineer at Raytheon | Websense.
Think in terms of video games and social media, he added.
“On the surface, the badging system seems too rooted in video games and social media, where one earns badges for accomplishing tasks,” O’Connor told LinuxInsider. “Building secure software is not really a game, and I worry that a badge system reduces security to checklists. That said, I can certainly see value in having some sort of rudimentary assessments of open source projects to see that they meet some minimal standards.”
Building secure software is a challenge, he continued, and every modification can have far-reaching impacts on security. Badges would have to be earned repeatedly — not just issued once for a project.
For example, the recommendation of a testing tool introduced a bug that ended up reducing the security of OpenSSL on Debian in a very subtle manner, O’Connor noted.
Doing nothing for software security certainly is not the answer, he said. Doing something that brings a culture of security to software development is certainly a good thing. “To me, it depends upon the strength of the evaluation in order to earn a badge.”
Loading ...
