Some security experts, including myself, thought that implementing financial software using dynamic languages would create a security threat for the “company” or the account holder. However, as I sit here this morning contemplating an open source payment platform delivery system I realize that it’s a silly hypothesis.Forgoing all of the traditional attack/fraud vectors I’m thinking about the code. The PCI-DSS covers the production hardware and database(s) but it also covers the developer’s computers, build machines, staging and QA, and the code repository. The “processor” is expected to treat the securely and equally. (this highest priority goes to the encryption keys and devices).So if an attacker can get to any of these systems and inject code then you really have a bigger problem than whether the code was Python, perl or Ruby. Of course since Java can be executed anywhere then it can also be compiled anywhere. Reverse engineering Java and then recompiling is no more or less difficult. Of course injecting code into a Java or C based system is more complicated if the attacker is already in… regardless of the programming language, you’re cooked.As I continue to consider my open source project it’s just a matter of selecting the right dynamic language for it. I want to be productive enough that the extra time can be spent on physical security instead of the false hopes of obfuscation.