Should we open source election software?

Late last year, R. James Woolsey and Brian Fox wrote an op-ed piece about the security benefits of open sourcing election software. Woolsey is a former director of the Central Intelligence Agency. Fox is the creator of several open source components, including the GNU Bash shell, and a board member of the National Association of Voting Officials.

Woolsey and Fox assert as a main piece of their argument that open source software exposes the code to the larger developer community, allowing many eyes to comb through that code for security vulnerabilities, transparency that makes it more secure than software developed by commercial organizations.

If the open source model for voting systems gains traction, as the editorial advocates, effective management of open source security will become extremely important. At the 2017 DEF CON 25 convention it took only a few hours for white hat hackers to break into five different voting machines, one via a vulnerability in an open-source component.

The reality is that all software, whether developed in a transparent manner or otherwise, contains defects. Regardless of available resources and expertise, uncovering a defect can be challenging.

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 volunteers within the open source community to identify and remediate every vulnerability, security efforts should be complemented with dedicated application security tools that automate the process of identifying and remediating potential vulnerabilities.

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

Organizations should know their code

The Federal Election Commission (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.

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 National Vulnerability Database, that disclosure launches a race between hackers and application security teams to find that vulnerability. IBM conducted a survey with the Ponemon Institute that found, globally, it took 191 days for a data breach to be identified. 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 process dedicated to continuously monitoring election software for newly reported vulnerabilities would be a far more proactive approach to quickly patching vulnerabilities.

Relying on the kindness of strangers 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 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 are readily integrated into automated development pipelines or production environments to identify and remediate vulnerabilities at scale.

Looking forward

Open source voting applications are already playing a role in elections in New Hampshire. San Francisco, Los Angeles, and Travis County, Texas are allocating funds to move toward open source voting systems, as well. If the FEC does replace proprietary software with open source equivalents, it should consider automated security tools in addition to relying on the open source community to provide a more complete application security picture.

Transparency of development in election systems is something we should all want. Having access to source code and seeing the individuals making changes in the code should increase confidence in the election process. Open source software has a strong role to play in the future of election software. But only with secure systems and policies in place will election officials be able to maximize the benefits of open source while effectively managing its risks.