What additional software engineering means can be taken to improve the security of Gpg4win?
This basically means: How can be make sure that the software products operate as planned and limit the severity of defects. (A 'defect' following Zeller2009 is a situation where the application behaves not like the software engineer wanted it to behave. This is opposed to a problem where the application behaves like 'planned' but the behavior could be better.) All software products have defects, so the idea is to limit the severity of them by using secure software development methods. It is possible to check that no big defects are there and limit the negative effects of the smaller ones.
Given more budget/development power what measures should be taken to rise the level of technical assurance and trust, ranked by effectiveness.
David A. Wheeler wrote an article attempting a general answer to prevent highly severe security defects like the OpenSSL 'heardbleed', ranked by effectiveness: http://www.dwheeler.com/essays/heartbleed.html
More automatic tests
Especially more negative tests, more fuzzing.
Map out the security requirements of the Gpg4win components.
.. the components and their role during usage should be examined. Best would be a fault or attack tree analysis. It will not be feasable to do the same level of security audits on all components, some are big (Qt for Kleopatra), some are quite small like the core implementation of ECC. And it is not necessary. This research should help to identify the components where a higher level of security audition is useful.
Continuous building, packaging, testing
Building, packaging and testing should happen often. Especially when there are so many target platforms as with GnuPG. It would help to build automatic systems that once in a while build, package and run automatic tests. The results should be presented nicely like on a dashboard like https://saegewerk.intevation.org or http://my.cdash.org/index.php?project=akonadi . And the packages would be available for interested users to test, just like nightly builds.