Il maggior rischio in qualsiasi lingua è avere sviluppatori che non padroneggiano la suddetta lingua . Lo sviluppo sicuro richiede di pensare a tutti i "casi d'angolo" e non funziona a meno che lo sviluppatore non sappia cosa fa in tutti i punti. Un programmatore C competente che non conosce Java eseguirà un codice più sicuro in C che in Java (e viceversa).
Si può affermare che nelle lingue con "forti garanzie", le conseguenze di alcuni errori di programmazione sono meno terribili se osservate da un punto di vista della sicurezza. Ad esempio, un overflow del buffer in Java porta a un'eccezione e (di solito) alla chiusura del thread offendente, mentre in C può portare a un exploit hole fino a una shell remota per l'attacker. Questo mi rende un po 'meno preoccupato quando devo fidarmi degli sviluppatori con codice Java piuttosto che con codice C. Tuttavia, altri potenziali bug relativi alla sicurezza sono immutati tra codice Java e C (se il codice crea istruzioni SQL in un modo suscettibile all'iniezione SQL, quindi nulla in Java proteggerà contro questo - in una certa misura, la gestione semplice delle stringhe di caratteri in Java promuove bug di SQL injection).
L'offuscamento riguarda più il mantenimento della proprietà intellettuale che della sicurezza. Non impedirà agli hacker di decodificare il codice, ma aiuta ad ottenere la qualifica legale (quando si utilizza l'offuscamento, si rende chiaro, o almeno più chiaro, che non si desidera che il codice sia decodificato, rendendo così " sconfinare "più ovvio agli occhi di un giudice - ma i dettagli variano molto a seconda della giurisdizione). Il bytecode Java è più semplice da decodificare rispetto al C o C ++ compilato, ma sarebbe sbagliato affermare che compilare C o C ++ sia immune da reverse-engineering.