As part of our research commitment, I went to teach a few classes to students of the Master of Security Management course at the Brandenburg University of Applied Science, following an invitation from Professor Friedrich Holl.
The first lecture focused on security engineering and the different ways professional security verification services are performed. We also went into discussions on how software audits are done, including source code review as well as binary code audits.
It is interesting to talk to people with solid education on the subject but less practical experience in the field. What I found most astonishing was that they had little to no preference for a specific programming language. This caused some discussions about which programming languages are better fit for security verification. I had to argue about my point that more modern languages should be used for quite a while. What I think finally drove the point home was the effort needed for testing, especially unit testing and code verification. If your language and especially your runtime environment (for example .NET) does not allow you to play fancy tricks with pointers or address indices outside of the array bounds, neither testing nor automated code verification needs to cover those topics and deal with the problems inherent to such actions. If nothing else convinces you to stop writing your programs in C, it should be the fact that the less flexibility on the lower levels of machine interpretation you have, the less things can go wrong and be turned against you with an exploit.
Of course higher level languages have plenty of their own issues. But given the fact that the fault density actually directly relates to the number of lines of source code, a language in which you write less code allows for a smaller chance to introduce faults. This is why I cringe every time I hear or read someone stating that the prototype is written in Python and works well but the release version is going to be rewritten in C. Please, don't.