The open source development model is based on interactions across communities and among community members – project developers, platform creators, and end users. These interdependent communities constitute a ‘triple fence’ that keeps projects free of malicious and exploitable code in different yet complementary ways. Ideally, the various communities of developers, integrators, and end users work together to monitor, curate, and improve code quality over time – catching security flaws in the process.
The triple fence is an intriguing concept. Unfortunately, it’s not clear whether it’s enough to secure many significant open source projects – Bash, SSL/SSH and glibc, to name a few. In theory, many eyes look at open source code as it’s developed, integrated, and deployed; however, in practice, too many of these eyes are busy elsewhere and too few are security savvy. What’s missing is ongoing curation. Developers and end users take for granted the security of many projects, but the reality is that too few people maintain piles of code that may be months or even years overdue for security review.
The open source software development process, while outwardly straightforward, can be fraught with complexity. Code might be presumed mature, but could rely on technology developed a decade or more ago and might still contain significant vulnerabilities. Open source security vulnerabilities can arise from many causes, including misconfiguration by end users, programming errors, and short-sighted protocol design. Given this reality, a holistic view of security is critical for organizations that rely on open source software.
Plenty of Eyes on Open Source, Yet Few Are Security-Savvy
Clearly, open source project maintainers provide certain critical defenses against malicious contributions, helping to fix bugs and moving projects along. Beyond that line of defense, many (but not all) projects are integrated into open source platform distributions such as RHEL, Android, OpenStack, other domain-specific or horizontal aggregations of open source code. A certain level of purview exists, that comes from the commercial integration and “productizing” of open source projects. Finally, end users, ISVs, and intelligent device manufacturers who integrate code into their portfolios and products all have opportunities for improving code quality, keeping malicious code out, and fixing bugs.
Many of the most notable recent open source security vulnerabilities arose from a lack of open source code reviews, continuous curation or an (optimistic) assumption about code quality in well-established projects. While many security researchers work hard to ferret out such vulnerabilities ahead of black hats, it’s clear that the majority of open source developers are not security experts.
Recently, there has been an uptick in third-party “bug bounty” programs, sponsored by the Linux Foundation and others, motivating the discovery of previously undetected vulnerabilities, but this is only part of the story. Further, not all vulnerabilities (to say nothing of breaches) are addressable by community purview. Many vulnerabilities associated with open source code arise from misconfiguration by end users. The security landscape is full of traps at many levels.
Open Source Hygiene: Visibility and Control
How do you avoid these traps? An enlightened approach lies in the concept of “Open Source Hygiene.” Simply put, this means taking steps to ensure the use of the most current versions of open source project code and applying the most recent patches. Open Source Hygiene procedures provide assurance that your open source software code base comprises the most resilient available code available. Moreover, visibility into where open source code “lives” within your stack goes a long way toward making this level of control possible.
With the size and scope of modern code bases comprising tens of millions of lines of code, automation is key to realizing the benefits of open source hygiene. While human oversight is necessary, effective hygiene comes from orchestrating automated scanning with build engines and continuous integration platforms. With a comprehensive Bill of Materials (BOM) for your organization’s open source code, you can then perform automated scans to supply critical information about security vulnerabilities, licensing conflicts, and version deprecation and proliferation. Armed with this information, your teams can see exactly where vulnerabilities lie and take measures to remediate them by keeping your open source components up to date.
The bottom line? Open source integrated and deployed by today’s development organizations undergoes constant evolution. However daunting, the open source development process over time yields increasingly secure and robust code. Taking steps to maintain code hygiene will help your organization avoid many security risks that accompany open source, as part of a comprehensive security regime.