Weighing the pros and cons of open sourcing election software

The same scenario applies to the Equifax breach, where code introduced in 2012 within the Apache Struts project became the attack vector for a major data exfiltration event. Even though the Apache community resolved the issue months prior to the Equifax breach, Equifax failed to take the necessary steps to locate that vulnerability within its codebase, which led to the breach. Similar to Equifax, the Federal Election Commission (FEC) has critical data to protect. If the FEC were to open source its software, there are some lessons to learn from Equifax regarding security.

Why open source doesn’t equal security

While Woolsey and Fox assert that open source components receive more security reviews than proprietary software, relying on the open source community to find and fix vulnerabilities leaves gaps in the application security process. Rather than banking on the open source community to identify and remediate every vulnerability, security efforts should be complimented with dedicated application security tools that automate the process of identifying and remediating vulnerabilities.

Here are three important reasons automated security solutions are necessary additions to the security benefits offered by open source communities.

1) Organizations should know their code

The FEC is currently using Microsoft’s proprietary operating system software, so it knows exactly how Microsoft addresses application security. Microsoft itself has now passed the sixteen year mark for their Trustworthy Computing Initiative, and we can safely state that Microsoft’s efforts have been quite successful. If proprietary election software were open sourced, the security burden then shifts to the FEC, because whoever uses open source software assumes responsibility for any associated security risks.

Assuming election software is like most applications, it is already composed of open source components—many of which contain security vulnerabilities. Simply making proprietary code public to the developer community would not give the FEC visibility into the composition of code within the application. A tool capable of scanning the entire application and mapping the open source components with their associated vulnerabilities would give the FEC a more robust picture of their application security.

The most commonly used database for open source vulnerability data is the National Vulnerability Database (NVD). However, relying on the NVD for open source vulnerability data can be risky because its records are not always complete, nor its data as timely as one might wish. The NVD can become backlogged, preventing it from disclosing timely vulnerability information. Additionally, the NVD doesn’t disclose every vulnerability; there are proprietary databases that have more complete records of open source data. In order to fully understand what is inside their code, the FEC would need a proprietary database to be sure it accounts for every vulnerability.

2) Vulnerabilities should be patched within a week

While open sourcing election software would expose code to more well-intentioned developers, it would open the door for hackers as well. Whenever a new vulnerability is disclosed by the NVD, that disclosure launches a race between hackers and application security teams to find that vulnerability. Whoever wins determines whether the application will be hacked or patched for any given deployment. According to a study done by Recorded Future in 2014: “7.5 is the median number of days it takes for a vulnerability to be exploited as reported by public/web data.” In other words, software users have a week following disclosure to patch a vulnerability; regardless of whether proprietary or open source. Further, IBM conducted a survey with the Ponemon Institute that found, globally, it took 191 days to identify a data breach. When applied to an election cycle such a delay could directly impact election results.

When data as sensitive as election results are on the line, it’s important that election officials win any security race. This is why they need to be alerted of new vulnerabilities before hackers find them. The stakes are too high for the FEC to hope that the well-intentioned developers fix any vulnerability before hackers can exploit it. Implementing a security tool dedicated to continuously monitoring an application for newly reported vulnerabilities would be a far more proactive approach to quickly patching vulnerabilities.

3) Relying on people is dangerous

In 2017 alone, an average of over 30 new vulnerabilities were added to the National Vulnerability Database each day. While the open source community finds many of them, it only takes one vulnerability to cause a breach—which is why the FEC should invest in technologies to catch whatever the developers miss. With an automated security solution, the FEC could set and enforce policies to flag vulnerabilities at scale before they slip through the cracks.

There is a reason enterprises are implementing automated security tools rather than hiring people to track and patch vulnerabilities manually. Software Composition Analysis, SAST, DAST, and IAST technologies can be integrated into development or production environments to identify and remediate vulnerabilities at scale.