Developing Programmer working on software development showing issue of open source security

New Report Details the Depth of Open Source Security Issues

Organizations of all sizes are increasingly leaning on open source software and components for convenience and financial savings, but they are not really becoming much more secure over time. Open source security continues to be a substantial risk, as a new report from the Information Security Forum (ISF) demonstrates.

The report does not condemn open source software (and in fact strongly supported its use in an official press release), but does encourage IT staff to recognize its unique challenges and vulnerabilities and create a specific program to monitor it.

The state of open source security

There is something of a persistent belief that open source security tends to be better (or at least automatically acceptable) because there are so many eyes on major projects, and because companies can scrutinize and adjust the code themselves at any time.

There are several open source security issues that are often overlooked, however, not the least of which is the fact that the code libraries it draws from do not always face the same level of scrutiny. In some cases, these vulnerabilities are documented but the organization’s staff simply aren’t aware of them. Additionally, very few open source projects have good security documentation and there is almost never a means by which to notify users of older code when security updates are made. Keeping up with patching at the organizational end can take a substantial amount of time, and old code libraries have to be continually monitored for the development of new vulnerabilities.

Entitled “Deploying Open Source Software: Challenges and Rewards,” the ISF report encourages continued use of open source software but stresses accounting for its realities. The ISF feels that these challenges are best managed by establishing a formal OSS program headed by a dedicated program manager.

As the report points out, even organizations that do not put any special focus on OSS are still commonly using a “mixed source software” approach that blends elements of it with closed source software. Open source security issues are thus nearly a universal concern for organizations at this point, but some may not be fully aware of the OSS components they already have in place.

In addition to the previously discussed open source security issues, the report cites a number of other common organizational shortfalls in this area: failure to incorporate proper security in DevOps practices, a lack of specific OSS skills among IT staff and failure to keep up with licensing obligations among them.

The report also points out that concerns about open source security can sometimes be overblown and ill-informed, leading to blanket prohibitions against it that are counterproductive. OSS software can be exceptionally flexible and speed up software development time, but the ISF only sees it as a consistent net gain if it is managed properly.

What an OSS program looks like

The key to a managed OSS program is, of course, the willingness to expend budget and resources. In addition to dedicated program leadership and staff, these programs require specialized tools and the ability to continually monitor and regularly patch all OSS components in use in the system. Taking on these security challenges begins with an initial inventory of all components already in use in the organization, as there tend to be quite a few that are undocumented or may not even be presently known to IT staff.

Training is also critical, as Wei Lien Dang, Co-Founder and Chief Strategy Officer at StackRox, points out: “If an organization is running open source software and uses a central IT model, there should be operators, or someone responsible for IT operations in general, that is responsible for patch maintenance and ensuring that upgrades are made. This could also be handled by someone on the development or DevOps team. While open source software is often a cost conscious choice, that doesn’t mean that it’s not without overhead. This comes in the form of experience and/or training to ensure that OSS code is patched and secured.”

The use of OSS also means committing to the formation of an ongoing patching program, so as to ensure that open source security does not fall by the wayside when the present team moves on from their positions.

The report points out that such a program can not only serve as a business accelerator that recoups its own costs, but may also be critical to securing organizational assets and even proprietary software going forward as market preferences increasingly shift from closed source to OSS implementations.

The importance of regular code checkups

OSS is essentially an expense tradeoff; flexibility and a broad variety of premade assets save money and time in development, but money and time will have to be spent keeping an eye on those assets going forward.

So what do the numbers say? The recent “State of Open Source Security 2020” report from international software security firm Snyk indicates that the number of vulnerabilities in open source software packages fell by 20% in the previous year, but that most organizations are still not adequately inventorying the indirect dependencies in which these vulnerabilities tend to occur.

The report also points out that open source security has to be perpetually vigilant for the possibility of the “rogue developer” attack; that is, an agent of a state-backed hacking group or a criminal outfit joining a project with the intention of introducing a vulnerability.

To some degree, the open source security question is being answered for organizations whether they recognize it or not. Closed source software is able to use open source components so long as the license allows for that use, and organizations may increasingly find that mixed source solutions are the only ones that are available or feasible for their needs.