State casino control boards have long solved this problem. Solution is straight forward.
The Nevada and New Jersey Gaming Commissions require the gaming manufactures to provide the source code, build environment, and final binary result (firmware running in the machine) to them of ANY MACHINE that runs in a casino.
This came about after several instances of the machine manufacturers software developers sneaking in back door jackpot triggering code.
The tech types at the gaming commissions examine the source for “bad code” (click the upper button 3 times within 2 seconds, lower button 6 times in 2 seconds, pull slot arm down half way, trigger jackpot...), then compile the code and the checksum MUST MATCH what is in the machine, else it DOES NOT GET USED, CAN’T BE CERTIFIED for use.
Same thing needs to be done for voting machines. And of course that also means absolutely no outside connectivity of any type.
Some of the commentary here on about the Dominion source code is foolish. You can’t checksum the source code since any change in the build environment could result in a different binary result, so no way to know if one version of source code produced the binary that will be executing.
All of which is why both software and hardware would be developed and provided solelyy by the FEC AND openly available for examination by anyone.