C'est pas une question de langage.
On peut très bien faire du reverse-engineering sur un produit dont on ne possède "que" l'exécutable (et ce même à distance, etc.), et quel que soit le langage utilisé pour le développer, s'il y a des failles, elles sont exploitables. (le tout étant de mesurer la "difficulté d'exploitation", même si normalement en bon puriste on devrait considérer les failles "comme des failles", indépendamment de leur gravité)
La question est surtout dans la complexité du logiciel (et/ou du hardware, car ce dernier entre aussi en jeu dans certains cas).
Les facteurs qui induisent des failles éventuelles sont nombreux: utilisation de bibliothèques externes de code (car même si elles sont "rodées", elles ne doivent pas être considérées comme sans failles...), ampleur du projet (développé par plusieurs personnes, il suffit que celui qui se charge de tel ou tel module n'ait pas l’œil assez vif, si les autres ne passent pas derrière pour vérifier que son truc est sécurisé en plus de fonctionner, c'est foutu), nature de l'environnement dans lequel le soft est censé tourner (là, ça se rapporte à la sécurité de l'OS dans le cas d'un soft "classique", la sécurité du noyau dans le cas d'un pilote, et dans une moindre mesure, pour les plus paranos, la "sécurité du hardware", vu qu'un type bien outillé peut aussi s'en prendre au matériel pour ausculter un système...)
Ma conclusion personnelle est classique (vue et revue même...), "il n'y a rien de pire en sécurité informatique, que de considérer une entité comme sûre à 100%".
L'entité, ça passe du petit bout de code chopé dans une lib, au middleware employé pour relier un serveur web à un SGBD dans un parc... tout composant utile quoi.