There are hundreds of articles out there encouraging you to “secure” your software, and several tools that help you find and address security vulnerabilities in your software. No less an authority than CERT publishes a secure coding standard, including such excellent advice as “Ensure size arguments for variable length arrays are in a valid range,” “Allocate sufficient memory for an object,” and “Exclude user input from format strings”. Other lists, such as the CWE/SANS Top 25 and the OWASP Top 10, offer guidance that is language-agnostic, but more targeted to particular types of applications. Secure coding is a fantastic idea, and every organization writing software should adopt a standard and use it rigorously. Doing so substantially reduces the chances that your application will be the source of an attack, and secure coding or ‘hardening’ of your software should be the first step in a complete protection strategy.
Ah, but there’s the rub. Regrettably, secure coding does little to ensure that your application, or the data on which it operates, will not be the target of an attack. One of the reasons the aforementioned vulnerabilities are so dangerous is because exploiting them often allows an attacker to run arbitrary commands and take full control of a system. At that point, they are free to go after the juiciest targets that system has to offer, even if they have nothing to do with the original source of the attack.
What this means is that your software is only as safe from attack as the least secure application on the system it shares. When it comes to the exposure of your software, the question you have to ask is “How much do I trust everyone else to do security right?” Oof.
Software protection, such as code transformation, white-box cryptography, integrity verification, etc., is explicitly designed to keep your software’s most valuable assets (IP, personal data, cryptographic keys) safe from attack. The means by which an attacker gets access to the system is no longer the focus; what matters is limiting what they can do once they are in. To be sure, software protection techniques lose a lot of their value if your application isn’t coded securely – that’s why having and sticking to a secure coding standard is step 1. In conjunction with secure coding, software protection can frustrate the efforts of an attacker to reverse engineer code, extract valuable assets, and tamper with your application, even when the attacker has full control of the system. This is what is meant by multi-layered security-in-depth.
Let’s imagine your software is a car, and the system on which it runs is the highway – of course there are lots of other applications (cars) running alongside you. Securing your software is like driving defensively – always signalling, not following too closely, checking your blind spot before changing lanes. Should you drive defensively? Absolutely. Will it reduce your chances of causing an accident? Enormously so. Will it stop you from being T-boned by a reckless so-and-so? It will not. That’s why most people want seat belts and air bags. That’s software protection.