Open Source: More eyes, fewer vulnerabilities, greater security
BlogFebruary 27, 2015
James Kirkland
Red Hat
The Open Source Way Blog: Welcome to the first in a series of quarterly posts about using open source technologies as a part of your embedded systems solutions to speed up your development efforts, reduce project costs, and create collaborative environments for innovation.
Future posts will dive deep into open source and its relationship to autonomous devices, but first, let's take a few paragraphs to level-set why open source might be an ideal option. First, full disclosure: I'm an advocate of open source software, so I’ve seen proof that a community of shared ideas and projects that can be modified, improved, and distributed freely can be a better way to develop technology. Being able to see the code, learn from it, ask questions, and offer improvements is the open source way.
While it might seem counterintuitive, open does not mean less secure. In fact, the opposite is often true. Because the development process is collaborative, bugs, flaws, and vulnerabilities can be found sooner, and more often, and fixed more quickly. By granting access to the code, more people can work to solve issues. It’s been said about open source that "given enough eyeballs, all bugs are shallow.” More eyes and greater transparency can lead to fewer vulnerabilities and greater security.
As with any system, it's important to only use well-maintained projects and to patch regularly to safe-guard against vulnerabilities. We're all aware that hazards may linger in even the best of code. The fact is, in any system, open or closed, vulnerabilities exist and may actually be exploited by those with knowledge of their existence. It just seems logical that, with open source transparency, it's likely to be more difficult to exploit something while everyone is watching.
With open source, development costs are often dramatically reduced, more development choices are available, and more flexibility is added to the process, all resulting in greater agility and responsiveness. It’s no wonder that open source software is used by innovative giants like Google, Netflix, and Facebook as well as more established institutions like Wells Fargo and yes, the U.S. federal government.
As Open Source for America points out, the U.S. federal government is making great strides in this area. The Department of Defense (DoD) has been clear about their position on the use of open source. The Government Services Association (GSA) states on its blog that one of its key principles is “Open Source First” for new project development, and making GSA-generated code open to the taxpayers who funded it. Additionally, the Office of Management and Budget (OMB) recently announced the U.S. Digital Service and introduced the USDS Playbook, also encouraging the use of open source:
“…digital services teams should consider using open source, cloud based, and commodity solutions across the technology stack, as these solutions have seen widespread adoption and support by the most successful private-sector consumer and enterprise software technology companies.”
So where should you begin with using open source for your embedded solutions? First of all, understand that a great deal of open source software is “commercial” and approved for use by the U.S. government. And, while most open source software has its beginnings as a development project, the collaborative effort actually leads to the project becoming robust enough to be “productized.” For example, my company, Red Hat, along with other commercial entities, academic institutions, government organizations, and private citizens, contribute code to open source projects, sponsoring engineers and developers to work in open technology communities. Once a project becomes a useful technology, commercial software companies extensively test and harden it to ensure that it is safe and reliable. Only then do they incorporate the technology into their product portfolios.
Sometimes, a project may become an integral part of an existing technology, as is the case with Security-Enhanced Linux (SELinux). When looking for multi-level security that enables data with different security classifications to reside on the same machine, the National Security Agency (NSA) initiated SELinux as a proof of concept within its own development organization. To get more “eyes” on the code, the team at the NSA released it as a project to the open source development community. After thorough examination by more developers than would ever have been available on a proprietary software project, SELinux was found to have no backdoors. And, what started out as a set of changes to the Linux operating system became an integrated component of it when it was commercialized by Red Hat at the NSA's request, thus making computer systems safer and less vulnerable to attack.
In future blog posts, I’ll talk more about using open source in embedded systems, its advantages in products with longer lifespans, and the keys to maintaining software in this unique environment.
