Gartner Blog Network

Protecting Intellectual Property in Source Code Requires a Two Prong Strategy

by Neil MacDonald  |  August 5, 2011  |  1 Comment

I had a discussion with a client today looking to protect sensitive intellectual property in their source code. I discussed two primary areas of risk: 1) that the developers (some of which were offshored) might take the code and 2) once the code was distributed to customers, it might be reverse engineered or copied

Addressing the first set of risks should start with policy – for example a non-disclosure agreement. Technical controls such as running developer sessions from a hosted virtual desktop session are also possible.

To address the second risk, an entire ecosystem of vendors offers solutions for the obfuscation of source code, tamper-resistance and tamper detection. These are covered in the latest Gartner hype cycle for application security which we just published for clients under a dot labeled “code obfuscation”

The latter is especially true with the shift to managed code and platforms such as Java and .NET which are much more easily reverse engineered.

Category: application-security  applications  information-security  

Tags: application-security  best-practices  defense-in-depth  information-security  

Neil MacDonald
VP & Gartner Fellow
15 years at Gartner
25 years IT industry

Neil MacDonald is a vice president, distinguished analyst and Gartner Fellow in Gartner Research. Mr. MacDonald is a member of Gartner's information security and privacy research team, focusing on operating system and application-level security strategies. Specific research areas include Windows security…Read Full Bio

Thoughts on Protecting Intellectual Property in Source Code Requires a Two Prong Strategy

  1. Andre Gironda says:

    Other people besides app developers touch code. System administrators of repos, software quality engineers, and admins of distribution systems (which are themselves insecure and lead to partner misuse, etc) are just small examples.

    The correct approach is to perform compile-time obfuscation with a primarily self-integrity checking protector based on a code generator, such as Metaforic MetaFortress.

    The second stage would be to provide an additional distribution protector such as Sony Release Control to anyone outside of development.

    When it comes time to ship the product, a full protection mechanism such as MCFACT from Syncrosoft should be provided on top of MetaFortress. Yes, this may require using Metaforic for only its self-integrity check value since adding a protector onto another protector can be problematic.

    Seems more like a three-prong approach to me. In this example, only the build engineers (and build system administrators) would have access to the entire, unobfuscated source code. Even non-build app developers would only have access to their own source code.

    Certainly those highly-sensitive roles should require rotation and separation of duties with accountability provided by internal audits.

    Regardless, there needs to be a IP Protection Lifecycle. Most shops don’t understand the basics of client-side exploits such as Metasploit or application security principles and controls such as OWASP — so going into a purchase of software protection products could be theoretically useless without an all-encompassing information security management program.

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.