Gartner calls In-App Protection “crucial” in their July 2019 Market Guide for In-App Protection In-App Protection. The guide’s summary advises security and risk management leaders to “take due care in protecting their application clients” in order to avoid “security failure.”

This raises the question – what constitutes “due care?” Obviously, no development organization looks to recklessly expose their applications or sensitive data to attack or compromise. On the other hand, over-engineered (or poorly engineered) security controls can quickly lead to excessive development costs, performance and quality issues, and, ultimately, unacceptable user experiences. While terms and terminology may vary, there is broad consensus on how to best define “due care” for any given application/user scenario.

If you don’t follow application security closely, you might think of application obfuscation and symbol renaming as being synonymous – and with good reason. Many platforms and languages, like .NET, Java, and JavaScript have popular obfuscators that do little else--our own Dotfuscator Community Edition for .NET and ProGuard for Java are good examples. However, obfuscation is far more than symbol renaming – and in-app protection is far more than obfuscation. Much of this expansion has been driven by new security requirements, shifting attack vectors, the rise of mobile and IoT computing and, lastly, the growing recognition inside regulations and legislation of the exposure that can result from inadequately protected software.

Can you tell the difference? Exception or the norm?

Of course, everyone is “for security” in principle. The hard question that each organization has to answer for themselves is “how much is enough?” Over-engineering is (by definition) excessive, and over-engineering application security can, in fact, be devastating as overly-complex algorithms, architectures and processes can compromise user experience, degrade performance and slow development velocity. On the other hand, punishment is swift for organizations that cut corners and do not effectively secure their applications, their data and, most importantly their users and business stakeholders. Finding and maintaining that balance can be time consuming and, because you can never be sure you’ve gotten it exactly right, it can also be a thankless job.

JavaScript is everywhere. It’s currently the world’s most popular programming language; as noted by GitHub, JavaScript has the highest number of contributors and repositories, handily outpacing other alternatives such as Python, PHP and Ruby.

The problem with all this popularity? Massive amounts of great open-source code create opportunities for both in-house development teams and malicious actors. The sheer volume of JavaScript-based services means it’s not enough just design apps with security in mind — businesses must actively mitigate emerging threats by obfuscating critical code to frustrate hacker efforts.

Not sure where to start? Here’s what you need to know about the brewing storm of JavaScript attacks and the simplest ways to reduce your total risk.

Organizations can’t afford to leave apps unprotected. Attackers are growing more sophisticated, leveraging targeted malware campaigns and advanced evasion tactics to compromise applications and cause long-term damage. And according to Forbes, even antivirus tools designed to protect devices and software can increase overall risk: recent research found that more than 28 million Android phones were subject to security vulnerabilities thanks to insecure virus protection apps.

As a result, many companies looking to boost application protection and security without breaking their budget or introducing unexpected risk are considering in-house builds of better defenses using a combination of IT talent and publicly available tools.

The challenge? Homegrown solutions introduce the potential for DIY disasters. Let’s dig in and discover why they can’t measure up.

Earlier this month, I had come across Scott Hanselman’s excellent blog post, What's better than ILDasm? ILSpy and dnSpy are tools to Decompile .NET Code where he had shared his insights on the strengths and limitations of a laundry list of reverse engineering and debugging tools. In the comments that followed, someone had asked for an obfuscation recommendation for those times when a developer wants to protect their code against reverse-engineering (a reasonable question to be sure).

Unfortunately, comments had been disabled by that point, and so I had sent an email to Scott that mapped Dotfuscator’s anti reverse-engineering/tamper/debugging capabilities to the collection of developer tools that he had covered.

On June 11, NIST released Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework. While a solid piece of work in its own right, this document is noteworthy because it stands as one more proof point - in an already long list of proof points, that development processes, the developers themselves, and the organizations they belong to, ALL share some degree of responsibility (liability) for:

Untrusted Environments, Valuable Apps? Put the Protection in the App.

IT environments are evolving. Disappearing are the days of in-house, fixed-endpoint, limited access server stacks — replaced instead by a combination of private and public cloud solutions, mobile applications and IoT devices.

As noted by research firm IDC, public cloud spending now outpaces all other IT infrastructure with a growth rate topping 10 percent year-over-year, while Statista reports that users downloaded more than 178 billion apps in 2017 alone — and are on track to break 250 billion over the next few years.

What does this mean for organizations? That application environments are quickly moving beyond the purview of in-house IT, exposing both apps and network services to steadily growing risk. It creates a paradox: Companies can’t deny the benefits of third-party environments and application partnerships, but also can’t ignore the threat of app and data compromise or reverse-engineering and tampering.