Protection of code from its own developers [closed]_问答_开发者

Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

Improve this question

Perhaps the most obvious way of protecting a company's intellectual property from its own developers seems to be an NDA - Non Disclosure Agreement. Effectiveness of this approach may vary, depending on many factors, and sometimes or somewhere it may not work as expected.

What other approaches, apart from this purely legal one, exist for protecting software code from the people who develop it? Do they exist at all? Does it make sense in practice?

Maybe, for example, Team Edition of Visual Studio already contains some features related to this problem (for example, levels of access to parts of code, depending of role inside a development team or something like that)?

Reference on the topic:开发者_运维百科

As statistics says, on average, programmers tend to change their job every three - four years.

Try to build a team you can trust.

The first approach is to force programmers to only know interfaces of other components, so that each one can only steal a small part of the whole software. This approach can be borrowed from footwear production. One transnational corporation, to prevent stealing by employees, arranged its factories so that each factory produced only left or only right shoes. You could do the same with your code: some programmers only write lines with odd numbers, and the others--those with even numbers; provided that they can't see the work of each other! That's sometimes referred to as "pair programming".

Some organizations force employees to sign a non-compete agreement. That's the kind of agreement that prevents programmers to work for competitors. This technique is best combined with job postings like "Looking for senior programmer with 5 years of experience in the similar field".

To prevent your programmers from stealing, you can do harm to them as soon as they finish the software. The method proved itself as the most efficient, and has been used for centuries. For example, Russian Tzar Ivan The Terrible burned eyes of the architect that designed a beautiful church at the Red Square, so the one designed remains the most beautiful ever. You can do something like this to your architect. I heard, latest Visual Studio contains some features...

Nowadays, however, it's more humanistic to hire already blind and already dumb people that lost their hands, so that they can't look at your code to memorize it, can't tell anyone about your code and can't type it again. The advantage is that this will help you dealing with labor agency in your country, which watches for balance that your employees are not discriminated.

And yes, this post is a sarcastic joke, which criticizes the idea of any code-stealing-prevention measures. Sorry, couldn't help posting it.

How do you protect a power plant from sabotage by an employee? How do you prevent a boxer from throwing the fight? How do you prevent a brothel from distributing the clap?

Your concern, while valid, is one that can only be properly addressed by personal responsibility and accountability within your team. Any options you employ to secure the code against theft is likely do more harm than good. If you feel a team member is not trustworthy, get rid of them.

If really necessary you can split the application in subapplications. Each team works in a single application and sees all others as "black boxes". Maybe SOA helps here.

It's highly unlikely that your code is the real intellectual property - that is your company's business knowledge and process.

SVN has the ability to limit different users to different folders, so you could split your code up into seperate libraries, and allow only certain people Read / Write access.

The file for this is under conf\authz Here is a sample

[aliases]
# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average

[groups]
# harry_and_sally = harry,sally
# harry_sally_and_joe = harry,sally,&joe

[/
# [/foo/bar]
# harry = rw
# &joe = r
# * =

# [repository:/baz/fuz]
# @harry_and_sally = rw
# * = r

Some documentation can be found here

Under 'Per-directory access control'

Either build a team of developers that you can trust, or entirely lock their system down so they can't access the USB ports, the CD drive, or web mail clients. The only thing they could do is work on the code and possibly browse the web. Also only give them access to the code that they are in charge of.

But with all these security measures chances are your developers will hate working with you and quit their job

There's no straightforward way to do this if your code is within the same project (i.e. you want to allow access to some parts of the code and not others). However, if you have seperate projects that require different security levels, it's possible to allow developers to only have code access to certain projects, and then pull builds from a common build server.

Keep in mind that decompiling of frameworks that work against IL like .NET is relatively straightforward, so preventing access to the code files is not necessarily a silver bullet to protect IP.

I know you said aside from the purely legal one, but I'd just like to add that in addition to the legal one you mentioned, there is also the Non-Compete. Basically says that once you leave your job, you won't be able to compete in any way against your former employer. Stealing code is not as appealing if you won't be able to put it to use for a year or two.

You could make them develop a module that would be seperate from the rest of the application. If you had a plugin/module type system going this would suit well. You could release APIs for the developers to develop against and have them integrate with your DLLs and not the source code.

People seem to be very critical of this but there are legitimate reasons for doing this i.e. partnering with a potential competitor if you gave them all your source you would be shooting yourself in the foot.

It might be worthwhile to spend some brain cell activity on the business model you want to follow. If the core value is embodied in the code, the core value can be stolen by stealing the code. If, however, the core value of your business is embodied in a group of employees, some of them engineers, others sales people, yet others customer support people, and when the software is only the net that keeps these peoples business going, then there's no easy way of stealing the value of your business. And if the software does get stolen, the thieves won't be able to make much use of it.

So, in addition to what cherouvim said, build a team that you can not just trust, but a team that is the core value of your business.

Develop your software in modules.

Have one common module that contains objects that pass back and forth, and utility classes that act on those objects.

Have each group build modules on top of that, without much need to know about other modules.

Have one trusted team of developers do the planning of what goes in each module, and have that team also do the integration of all of the modules into the whole.

Also have a lot of trust in whoever runs your version control server. While it's stable, no one developer can do all that much harm; they can't delete everything, for example, and you'll know exactly what they did and when if that ever becomes an issue.