This is one of the situations where you are looking for a technical solution to a social problem.

A social problem should require a social solution, which, in this case, takes two complementary forms and an additional organizational solution which may help:

• Trust. If you don’t trust developers, don’t hire them. Working with people you don’t trust is synonymous of failure. Relations based on mistrust require a lot of formalism, which may severely impact not only the productivity of your employees, but also the number of persons ready to work with you. Chances are, the best developers will avoid your company at all costs.

• NDA. Trusting someone doesn’t mean you shouldn’t take legal precautions. Those precautions can take a form of a contract or a NDA clause with severe consequences for the employee in a case of a disclosure.

  How severe are the consequences depends on who you are. Government organizations, terrorists or mafia can permit some deterrent ones. Ordinary companies may be limited, by law, to financial ones only.

• Slicing. Trust and contracts are a good start, but we can do better. If the sensitive part of the code base can be sliced so that two or more parts are required for the product to function, make sure that the developer from department 1 never sees the source code developed in department 2, and vice versa.

  People from one department shouldn’t be able to meet people from other departments, and ideally, they shouldn’t even be able to guess what other departments are doing, nor how much departments are there. Each person knows only a small part, which is not enough to have an entire picture (and reconstruct an entire product outside the organization).

Those were social and organizational measures.

Now, technically speaking, there is nothing you can do.

You may try to:

• Force the developers to work in a closed room on a machine which is not connected to the internet and doesn’t have USB ports.

• Install cameras which monitor everything which happens in the room, with several security officers constantly observing the developers working.

• Strip-search every developer each time he leaves the room to be sure he don’t have any electronic device which can hold the code.

• Require every developer to have an ankle monitor. The device will listen to what they say, record their position and attempt to detect any electronic device nearby. If the developer was near a device which is not identified and doesn’t have your tracking software installed on it, private investigators and hackers may attempt to check whether the developer wasn’t using the device to leak information.

• Forbid developers to leave your buildings, unless being under heavy surveillance, and to interact in any way with the outside world.

Some or all those measures are illegal in many countries (unless you represent some government agencies), but the worst part is that even with all those measures in place, developers will be able to get the code, for example by discretely writing it on their skin or on a piece of paper and hiding it in their clothes, or simply memorizing it if they have Eidetic memory.

Or they can just globally memorize the data structures and the algorithms—that is the only important thing where intellectual property matters—and create their own product inspired by those two things.

1. Make them sign a non-disclosure agreement.

2. Only hire people you trust.

3. Compartmentalize your code base. Use of dependency injection so you can give them requirements that, when finished, resulting classes would fall right into place into the existing architecture, but they will not have acces to the “complete picture”, only loose pieces. Only senior, trusted people would have clearance to the “architectural glue” that makes all work as a complete whole.

I love the idea there might be a “clever” idea that “we” as developers would be baffled by. Given that every developer tool written was written by a developer and all that.

Your boss’s biggest problem is naivety with a dash of paranoia. I’m being polite there. Really really polite.

If you really want a shopping list of things to keep your code proprietary, just implement the following:

1. Disable USB and other IO on all company computers. This can be done through most enterprise anti virus or similar.

2. All developer machines to be desktops or towers. No laptops.

3. Do not allow any machine to connect to the internet. No web, ftp, email, IM, no internet. Cut the wires.

4. No remote working/access (sort of covered by no internet, but some smart spark might suggest a VPN)

5. No mobile phones or other electronic devices to be taken into the secure “development” room.

6. Configure all printers to print a large visible watermark on every page, front and back.

7. bag searches both in and out. Search for hand written notes, anything printed on company printers (anything, they might have hidden code in an image with steganography!). Any electrical or electronic devices. In fact, probably best to ensure bags are kept out of the secure area and developers should wear clean suits, the sort of thing you’d see in drug dens and chip fab plants.

8. Servers should be equally isolated, back ups should be encrypted and only your boss should know the password to restore from them.

If the people in question can’t be trusted to keep to their employment contracts, then he needs to not hire them.

If he believes NO ONE can be trusted, then he’s being overly paranoid, and he’s ultimately going to damage the company if he keeps it up.

At some point you MUST trust your employees. It’s not really an option to do otherwise. If you don’t trust your employees at all, then they can’t possibly be effective, because you’re spending too much time distrusting them, and wasting a lot of their time jumping through hoops due to trust issues.

Also, when you make it clear to people that you don’t trust them, they tend to get annoyed. And annoyed programmers eventually find another job where they aren’t treated that way.

The right solution is a basic background check, a well-thought out employment agreement, and some trust.

I used to write code for classified computer systems. They had all sorts of ridiculous hoops to jump through to keep it secret. For example, we weren’t allowed to bring music CDs into certain rooms because they could be CD-RWs in disguise.

The thing is, practicalities of the work open up security holes out of necessity. Sometimes you had to transport non-classified data/code into or out of a classified area in order to get the job done. Yes, there were rules and procedures for that, too, but they all eventually boiled down to trusting people. Instead of trusting people not to put classified data on a convenient usb thumb drive, you’re just trusting the exact same people to jump through all the security hoops.

In other words, there are a lot of things you can do to protect from outsiders, but once you let them in, it’s pretty much just a question of how much you want to annoy them.

In short, you need to have a non-disclosure agreement/contract with employees that you are hiring. In addition to this signed agreement hire developers that you can trust.

Technically speaking that code can easily get copied to device and reused somewhere else. What your boss doesn’t want is – access of your competitors to this code. You may only enforce such policies through contracts of employment or partnership.

Another thing that may work is provide training on sensitivity of information, how each employee should be alerted when confidentiality of information is violated. In addition, tracking computer activities within your office network will also raise warning level.

Similar type of training is done annually for employees who deal with PHI related information .

However, getting a trusted people on board and providing training how to protect this information might be the optimal way to go.

Did you see Paycheck with Ben Affleck? I think that’s the only way to guarantee your IP won’t be “stolen”. I can tell you that because of my memory, I could recreate almost every system I’ve worked on for any significant amount of time. If not a line by line recreation, I could produce the significant elements and probably improve on them in the process because of how my skills have grown over the years.

Plain and simple, there are only two things you can accomplish by “locking down” your code:

1. You’ll repulse good developers who are offended by your obvious lack of trust
2. You’ll raise a great big flag that tempts the more unscrupulous developers

If you think your software is that novel and amazing, get a patent.

1. You can’t prevent code from leaking. You can limit the leak to less important code.
2. Normally there is only one part of the application that makes it unique. That would be some algorithm. You can interface this very well, and put this in a separate source control branch. You and only those people who need to work on it should have access to it. You provide only a binary (obfuscated) and the interface to the other developers.
3. Divide your code into more modules and let people only work on a particular module. The other modules are provided in binary (obfuscated). This, however, can be stretched too far that it will be unmanageable, and can lead to duplication of code.

I know someone who worked in an environment like this one.

A few measures that were taken there:

1. No access to the physical computer, all the computers were stored in a locked room with holes in the wall for display, keyboard and mouse.

2. No internet access.

3. Customized operating system that used an in-house-built file system with encryption (in case a computer were to get stolen somehow).

4. Projects were divided in static libraries, no one had access to the whole source code (this of course does not apply for all programming languages).

5. It was a very unpleasant workplace.

Be careful not to overestimate the value of your source code to those outside your company.

Sure – you paid a lot of engineers (Developers, QA, etc) lots of money to develop it, but that doesn’t mean it’s intrinsically valuable to a third party.

What exact attacks exist?

Source code is often leaked from (e.g.) games development or IT security companies. Of course, such leaks make them look bad, but otherwise, cause no real harm.

Ask yourself:

• Are you so embarrassed about the quality of your source code, it would be damaging to your reputation to leak it?
• Does the source code itself contain confidential secrets (e.g. hard-coded encryption keys, details of financial relationships with other companies)? Should it?
• Could a competitor genuinely benefit from using your source code, despite the risk of being discovered?

As far as I know, there was a case where a member of staff at one IT security company tried to sell the source code to a competitor. The competitor immediately reported this to his employer, and he was soon dismissed. No money changed hands, but the staff member can’t work easily in the IT security industry any more.

You have to trust, but sometimes it’s better to just monitor for infractions. For instance, if your code runs it could phone home to some IP address on the internet whenever it’s run, logging the IP address, computer information, perhaps even Geo location of where it’s running. Review that log to look for problems.

Of course there are ways around that, and developers could just be looking at the code, not executing it.

You could configure your firewall to do packet inspection with something like Snort that could a) block the connection immediately if it detects, e.g. your copyright notice, and b) report it to management for follow-up. In order to get around SSL and HTTPS you’d need to be running an HTTPS proxy on your firewall.

Perhaps you could have a system utility on every PC that checks external drives and USB flash drives for specific files or key phrases while they’re plugged in. You could also disable/ban external drives (I heard the US DOD does this). You’d have to require they use your hardware, and not bring in any hardware from home.

There are probably programs available that will log everything someone does with a computer. Just schedule random audits of these logs, and make sure developers are aware of this capability.

Once you’ve found an infraction, hit the developer over the head with the NDA they signed.

A technical solution could be to have all development sessions hosted on a server with no (or severely restricted and monitored) network access beyond that required to serve the RDP (or VNC) sessions. That way, the source is never on a developer’s machine. It would also make it possible to work from home or a client site.

Ultimately, though, I think the whole situation is ripe for failure. If you make it obvious to developers that you don’t trust them, and make their jobs harder, then IMHO you’re creating an environment where developers will find some way to make the source public, just to “stick it to the man”.

You are working for people who simply do not understand how software engineering works. Worse: they don’t value it (only what they can get out of it). It is not going to be possible to work productively for them; ultimately, they will punish you for this. Find another job.

While I do agree that its a recipe for disaster because no programmer will stay there long enough and you will be spending more time trying to understand other people code, some things come to mind:

• Block internet access
• Block any third party access (USB, card readers, etc)
• Encrypt and save elsewhere any finish line of code. Thats it, turn every code into an API so programmers could not access the functions any more.
• That brings: Separate programmers from debuggers.

Anyway… prepare to have some high movement of people and high salaries if you want them to stay there. You are creating a very bad working environment.

Keep in mind you could basically write much code from all the free examples that out there in the Internet. Most programming is actually re-using. You are going to block and delay your workers.