A great insight from Avi Rubin, who attributes it to California Secretary of State Debra Bowen:
The current certification process may have been appropriate when a 900 lb lever voting machine was deployed. The machine could be tested every which way, and if it met the criteria, it could be certified because it was not likely to change. But software is different. The software lifecycle is dynamic. As an example, look at the way Apple distributes releases of the iPhone software. The first release was 1.0.0. Two minor version numbers. When the first serious flaw was discovered, they issued a patch and called it version 1.0.1. Apple knew that there would be many minor and some major releases because that is the nature of software. It’s how the entire software industry operates.
So, you cannot certify an electronic voting machine the way you certify a lever machine. Once the voting machine goes through a lengthy and expensive certification process, any change to the software requires that it be certified all over again. What if a vulnerability is discovered a week before an election? What about a month before the election, or a week after it passes certification? Now the point is that we absolutely expect that vulnerabilities will be discovered all the time. That would be the case even if the vendors had a clue about security. Microsoft, which arguably has some of the best security specialists, processes and development techniques issues security patches all the time.
Software is designed to be upgraded, and patch management systems are the norm. A certification system that requires freezing a version in stone is doomed to failure because of the inherent nature of software. Since we cannot change the nature of software, the certification process for voting machines needs to be radically revamped. The dependence on software needs to be eliminated.
The Technology Liberation Front is the tech policy blog dedicated to keeping politicians' hands off the 'net and everything else related to technology.