El mayor riesgo en el lenguaje cualquier es que los desarrolladores no dominen dicho idioma . El desarrollo seguro requiere pensar en todos los "casos de esquina" y no funciona a menos que el desarrollador sepa lo que hace en todos los puntos. Un programador de C competente que no conoce Java hará un código más seguro en C que en Java (y viceversa).
Se puede argumentar que en los idiomas con "garantías sólidas", las consecuencias de algunos errores de programación son menos graves cuando se ven desde un punto de vista de seguridad. Por ejemplo, un desbordamiento de búfer en Java conduce a una excepción y (generalmente) terminación del subproceso ofensivo, mientras que en C puede llevar a un agujero explotable hasta un shell remoto para el atacante. Esto me hace un poco menos preocupado cuando tengo que confiar en los desarrolladores con el código Java que con el código C. Sin embargo, otros errores potenciales relacionados con la seguridad no se modifican entre Java y el código C (si el código crea sentencias de SQL de una manera susceptible a la inyección de SQL, entonces nada en Java protegerá contra eso, hasta cierto punto, fácil manejo de cadenas de caracteres en Java promueve errores de inyección de SQL).
Ofuscación es más sobre el mantenimiento de la propiedad intelectual que de la seguridad. No evitará que los atacantes realicen una ingeniería inversa de su código, pero ayuda a obtener una calificación legal (al usar la ofuscación, usted aclara, o al menos aclara, que no desea que el código tenga ingeniería inversa, por lo que " entrada ilegal más obvia a los ojos de un juez, pero los detalles varían bastante dependiendo de la jurisdicción). El código de bytes de Java es más fácil de aplicar ingeniería inversa que C o C ++ compilado, pero sería erróneo afirmar que la compilación de C o C ++ es inmune a la ingeniería inversa.