IMO it's a security problem in practice - it means that you have a lot of organizational resistance to doing things like regular software updates, because you end up with this one server that's been hand-crafted that people are too scared to touch. Or, analogously, if you want to introduce some new sort of authentication/auditing/etc. protocol to the system, people will worry that they won't be able to find every use of the old thing and won't make the new thing mandatory. It also means that it's a lot harder to test changes, because you don't know what you need to set up to get a full test/QA environment going.
It's not a vulnerability in itself, but the fear/stop energy created by artisanal small-batch infrastructure is a good way to set yourself up for vulnerabilities being exploitable. (See, for instance, Equifax being hacked by a two-month-old Struts vulnerability - you can theoretically argue that Equifax is a big company and should carefully audit their dependencies, but a much more practical argument is that Equifax should have been ready to patch within days, at most, of the vulnerability being announced.)
The actual ToB report identifies another reason which I didn't think of:
> Ensure that all backend infrastructure is re-provisioned between elections and not shared between elections/clients. Each server should also receive its own unique SSL certificate and credentials. Use infrastructure-as-code tools like Ansible and Terraform to automate and manage provisioning.
Apparently there are two concrete problems:
1. All Voatz backend servers share a single wildcard certificate, and they think that automated provisioning would reduce the incentive to do things like this.
2. Every Voatz election uses a custom iOS/Android app delivered via TestFlight / Google Play Beta, because of some design choices in the protocol related to having a single shared backend (S3, MongoDB, etc.). They think that if there were infrastructure-as-code for the shared backends, it'd be easier to provision one instance per election and easier to make the client change to use a single client for each election, blocking potential attacks on the page that links you to the sideloaded app.
It also enhances auditability since you can keep a record of all changes in code and run the tooling to see if resources are changing outside of how they were configured. Without those tools, you'd have to develop your own to meaningful ensure infrastructure is setup correctly (it's not practical to hand inspect hundreds or thousands of small components)
