In its recent GitHub $7.5B acquisition announcement, Microsoft promised to “bring its developer tools and services to new audiences.” “New audiences” in this context mean, quite literally, GitHub’s 28 million developer users. As the “largest open source community in the world,” GitHub audiences will surely also mean new requirements, priorities, and expectations—but these will also come with old biases. And there is no better example of open source bias than code obfuscation.
For the typical open source developer, obfuscation is “like a pearl onion on a banana split”—it simply does not belong (with thanks and apologies to Philip Marlowe in Raymond Chandler’s The Long Goodbye).
The argument is simple enough: there is no reason to prevent the reverse engineering of open-source applications because the source code is already public. It’s like picking an unlocked door.
In addition to the sheer lunacy of the act, the benefits of open source development (access to existing code and limitless engineering resources) far outweigh any advantage that might come from jealously hiding your handiwork from the rest of the world.
The argument is compelling if you only concern yourself with intellectual property (IP) issues and ignore user privacy and safety.
Privacy and security obligations trump IP policy and must drive DevOps practices
No praise or reward for unsafe software exists, no matter how efficiently or innovatively developed.
Runtime application self-protection (RASP), as defined by Gartner, is a security technology built or linked into an application or application runtime environment. It is capable of controlling application execution and detecting and preventing real-time attacks.
Examples of RASP attack “prevention and detection” include Android root detection, application tamper detection, and unauthorized debugger/emulator detection. These scenarios share the following essential qualities:
Increasing the time required for bad actors to dissect RASP prevention and detection algorithms reduces the cost and complexity of RASP controls.
Reducing the requirement for all developers to keep up with these development patterns further reduces the cost of security and streamlines a development organization’s ability to respond quickly.
Including multiple RASP checks throughout an application with multiple detection and response layers can dramatically improve overall RASP effectiveness and extend the lifespan of RASP controls.
Privacy and safety controls typically also require audit records to demonstrate compliance. Privacy and safety compliance steps can also increase cost and reduce overall efficiency unless carefully designed.
PreEmptive Solutions pioneered RASP before it had a name. In 2006, Dotfuscator first included Tamper detection and defense. Anti-debug, (Android) root detection, emulator detection, etc., have all followed.
Over the past 12+ years, we have validated that post-compile injection of RASP controls helps meet each of these requirements.
…and what’s this got to do with obfuscation?
As mentioned above, slowing the discovery (and impeding evasion) of RASP controls improves privacy and safety while simultaneously lowering the cost and complexity of implementing those controls. The PCI Council recommends obfuscation to better secure rooted device detection, Google recommends obfuscation to impede hacks on SafetyNet, and the list goes on and on. Obscuring RASP controls via obfuscation is a recommended (and increasingly required) practice.
Post-compile injection lets you develop in open source while injecting (and optionally obfuscating) your RASP controls after compiling.
Is there a role for obfuscation to play in the open source community?
YES IF,
It’s the inverse of the IP scenario above. Putting your RASP control source inside your project for hackers to see would be “sheer lunacy,” as the benefits of injection (improved safety and privacy for users and lower cost and complexity of security derived from injection) far outweigh any advantage that might come from dogmatically publishing source that actually has nothing to do with the application you’re building.
Like most everyone, we at PreEmptive are energized by Microsoft’s acquisition of GitHub. We look forward to helping new audiences effectively and efficiently protect their apps and the data they process.