I am not a software engineer. So I am curious about how a company to make sure the source code of its product is not leaked by its own developers/employees? What method do you use to trace once it's leaked?

+1: Exactly. If a developer wants to screw you, then it is easy to hide nasties in the source code (this can be blocked by good code reviews). If the team as a whole wants to screw you, then it is very hard to stop them.
–
RichardSep 10 '09 at 11:54

+1 absolutely, if you can't trust the people that you're letting in behind the scenes and where they can do what they want with your product, you're already screwed before you even begin.
–
Darth MelkorSep 10 '09 at 11:58

2

@Richard: if the whole team wants to screw your company over, I'd say there are other issues to address than just securing source code from being stolen...
–
Bart SilverstrimSep 10 '09 at 12:20

1

Yes, it was that poisonous. I'd actually been lucky enough to get another job before that happened, but the few remaining developers all had their resumes in the pipeline. We had good people, just a terrible corporate culture - that's what happens when two developers who think they can do no wrong and nobody else can do right try to run a company.
–
Paul TomblinSep 10 '09 at 12:51

I think Paul is right on with the 'If you don't trust them, don't hire them', but two other things to think about:

Is the source code really that special? Often, it is the whole business process, brand name, combined with the code that makes a really good product. The vast majority of code that is written, would probably be easier to for other developers to rewrite then to actually read what your developers wrote.

If it really is that special
Your only really option would be to break the tasks up, and don't let see all the developers see all the code. This obviously has a very large penalty, and will probably result worse code. I think the use for this would be extremely rare, maybe high security government situations.

Occasionally on IP in finance houses like algorithmic trading systems where it really is the keys to the kingdom (think of the arbitrage opportunities if you knew how Goldman Sachs' pricing models worked).
–
ConcernedOfTunbridgeWellsSep 10 '09 at 12:18

Ya, good point, I guess I should have said rare, not extremely rare :-)
–
Kyle Brandt♦Sep 10 '09 at 12:31

I got into a lot of trouble at a company I worked at recently because I'd posted two small snippets of SQL on SO, which between them showed something like 30 lines of code out of millions, and exposed the names of a couple of incredibly cryptically named tables (like pwc_clt_prsn). I googled the names of some of the tables, and found that the guy who was leading the DDL team had posted them on a different site a few years previously!
–
Paul TomblinSep 10 '09 at 13:59

I'd say the only way to secure the source code is to not hire anyone and you're the only developer on the project.

I suppose you could try breaking down the project into modules that are individually linked together later so no one person could completely assemble your product, but I couldn't imagine the politics (or decreased morale) from such an environment...

Otherwise, you would have to talk to a lawyer about options for suing developers who turn on you, enforce a code checkin system that has accountability of who has played with what code when, and use lots of peer review to check for malware hidden in the source. And make sure all your policies (including the sue-your-pants-off clauses) are documented and known to your employees.

Of course, there's a bit of a challenge to doing this and not coming off as a jerk who deserves to have your source code stolen.

I'd say you just have to trust your employees, just as any other employer has to trust his employees aren't using the company car for drag racing and using their cubicles to run a personal Lia Sophia business on the side. Not that you're not going to get burned once in awhile, but you're going to foster a lot more resentment and churn if you treat everyone as a criminal.

There's also the possibility of a change in attitude...as the SO Podcast points out, StackOverflow is being "stolen" periodically and re-purposed but there's obviously a successful original still out there. If your code is stolen and someone else creates a thriving business just based on the source code chances are the company itself is lacking in some areas like customer experience from support, professionalism, etc. It's not right that it's stolen but having something taken is always a risk that comes as a cost of doing business sometimes. Not to mention that it is technically possible for someone to reverse engineer any product (or just steal the product and repackage it themselves, without the source code, a lot easier to do...)

Seems most people worry about that kind of piracy over someone stealing the original source and having to play with updating and altering and compiling it that way.

Another way of handling this problem is to make the source code open source. There is nothing to steal if it is all public anyway. However, the only way that this is possible would be if the source code was not the secret sauce that brings in money. If the company makes money by selling services or hardware, giving away the software would be less of a problem. Ditto, if the software is only one small part of an extremely complex system.

The only way i think you could accomplish this would be to departmentalize everything. Make sure that each team builds their part to spec that way the knowledge is diffused across a variety of people and no one has the entire picture.

You would need to make the computers physically unreachable (no usb/optical writers), and not connect them to the internet.

But beyond that it's a trust thing and really people tend to remember solving problems, and how they solved them. That's what coding is. They will be able to rewrite what they did.

Bien, what if a developer from each department conspired to steal their part of the code, and they put it all back together?
–
Zimmy-DUB-Zongy-Zong-DUBBYSep 10 '09 at 15:07

1

I suppose you could put them in different parts of the country, and never let them talk to one another. But really, if someone really wants to steal it they'll get it. You're better off hiring someone you trust.
–
HighsteadSep 10 '09 at 15:14

Sorry, I missed your answer before I posted mine. However, I believe the word is "compartmentalize" rather than "departmentalize".
–
Dennis WilliamsonSep 10 '09 at 16:04

@Zimmy: You make sure that when put together without a key module the manager has the code phones a master server reporting what is happening, then unleashes a mega virus into the computer that the thief is using and then wipes all the data out. Problem solved.
–
Bart SilverstrimSep 10 '09 at 16:10

For the extremely paranoid, there's always the compartmentalized, need-to-know model that limits knowledge (and access) of the whole to a very few people. I would think it would be a very difficult and unpleasant environment to work in.

Totally agree with the answer above, always better to approach this with a non-technical solution.

But here's my £0.02.

Non-technical solution: Whilst this isn't great for small or simple projects. You could split the application into modules/components so your developers are more like assembly workers in a factory. No one has access to the entire project they only see the part they are working on.

Technical solution: Assuming developers are on-site. Lock down workstations using USB sentry software like Sanctuary. Do not give developers Local Admin to workstations so they can't install 3rd party software to circumvent security (ssh/http proxies etc). Employ some form of Data Loss Prevention software (all Security software firms have their own flavour CA, ClearSwift etc). Block/monitor Email to the Internet and Web access. Work is never taken home no matter what, same goes for teleworking do not allow it.

There are quite a few ways to get around not having admin rights / blocked internet connections. Loads of the tools run in userland and you can use http-proxies in a lot of cases. Other ways to hide data in allowed data streams too.
–
RyanerSep 10 '09 at 12:26

@Ryaner: wow...you'd have to have a boss that carries a pitchfork to want to go through that kind of trouble to get back at him by stealing the software, no?
–
Bart SilverstrimSep 10 '09 at 12:29

You missed "disallow printing", and "disallow having cameras in the office". You may find that implementing such restrictions will encourage most developers to find alternate employment though.
–
Rowland ShawSep 10 '09 at 12:29

@Rowland: You forgot just taking the CPU home one night...
–
Bart SilverstrimSep 10 '09 at 12:38

When you are posed with a security question such as this, always ask yourself, "What would they do in the Movies?"

There is a movie that comes to mind when I think about this problem. How to get someone to write code but ensure they cannot bring the code home with them. Indeed, after watching the movie 'Paycheck' starring Ben Affleck, I think I have the answer. In this rotten tomato, Ben plays an engineer that is locked in a room until he finishes the job. When he is done, his employer simply hands him a check. Oh, and they wipe his memory.

So - lock your developers in a room until the software is finished, then wipe their memory.

Maybe just make it policy that your developers watch the movie and have the understanding that this is what will happen with them if they steal the source code? Either that or Jurassic Park. Works better if the boss has a pet velociraptor.
–
Bart SilverstrimSep 10 '09 at 16:08