Securing Source Code

Second time this question came up: How to protect source code from theft by developers during software development.

My first reaction is a blunt "you can't" - they wrote it so it is in their heads already. And anyway, if you could give the developer amnesia, they could write code that leaks itself to the user while the application is in use. But having given it some more thought, I can see the point of the question: how does one mitigate the risk?

The most I can simplify this is to think of a two-directional channel that needs to be secured:

• Inbound: changes by the developer to existing source code
• Outbound: visibility of source code and other project artifacts to developers

There is a lot of existing discussion on the first point: from pair programming to various degrees of code review and testing.

I think the second point is what the question is about, though in my mind there is little point in addressing the second if the first is not appropriately dealt with. My short, perhaps biased response to that first requirement: use Team System :)

In the second case, a tool is not the answer. Also, as with all security, no approach will be perfect and undefeatable. Plus it will get in the way and likely frustrate legitimate, well intentioned developers.

Here is one extreme that addresses one mechanical aspect: make all developers use Remote Desktop from workstations and disable the ability to map drives through RDP or use the clipboard. Assuming the developer has no physical access to the machine on which they're actually using and writing source code and the network is carefully isolated, the only way to get the source out would through screenshots and subsequent OCR. Possible, but not practical for large amounts of code if done by hand. But then, you are dealing with developers. And presumably the source is valuable enough to justify significant effort to obtain, so you can assume someone, in some extreme case will write some automation code...

From a source control perspective, consider the military approach of working on a "need to know" basis. When I write code for Assembly 001, I do not necessarily need source for assemblies it depends on and with unit testing, perhaps also not the assemblies dependent on 001. This will take careful planning, a degree of obfuscation and a fairly mature Process that allows for well defined boundaries, contracts, etc. This is where Team Foundation Server would help a lot: automated Build to produce the assemblies needed by those without source-level access, Branching to isolate priviledge and Auditing to enforce accountability.

With .NET's ability to sign assemblies and deal with component licensing, the disclosure of a .NET Assembly (DLL) would not mean the general availability of said component, so allowing developers access to Assemblies (DLLs) seems reasonable to me. And besides, those Assemblies (DLLs) are going to be distributed to customers, right? If you're building a web application, that'll be one less thing to worry about :)

Your last resort is of course the law (I am not a lawyer): many legal jurisdictions have Copyright, Patent and Trade Secret mechanisms for establishing the concept of "Intellectual Property". Regardless of who got their hands on what source code, only the Copyright holder can legally distribute copies of an application and under the relevant laws there would be remedies like fines, injunctions, etc.

I would like to hear about steps taken by those out there with similar requirements - especially if those steps were circumvented :)

[Update] Also worth looking at SLP