24

This question already has an answer here:

I am wondering how big companies manage access to their codebase from their developers. In order to make their code safe do they allow their developers to have access to entire codebase or to only particular subprojects to avoid stealing the entire codebase?

For example, if a company has 10 developers, should they set in place access control policies, so each developer will have access only to particular module he/she needs to develop?

If so, please let me know how to achieve this.

[Edited]: As expected the code source has been taken from one of the developers and sold it to somebody, it was done by trusted developers for those who says trust is must.

marked as duplicate by WhiteWinterWolf, Xiong Chiamiov, CaffeineAddiction, Steffen Ullrich, Tobias Kienzler Mar 27 '17 at 5:46

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    It depends on the size and function of the team. Our team (security dev) has access to all of the source code for the applications we write. However, trying to steal it would trip one of many DLP triggers monitoring all exfiltration channels. In larger teams or distributed environments it might make more sense to delegate pieces of the app and assemble it using some sort of continuous integration solution. Having worked in situations where co-workers have freely overwritten my own commits, I would welcome delegation, but every environment is different. – Ivan Mar 25 '17 at 11:57
  • 1
    Symantec DLP, exhaustive firewall/proxy rules, etc. Lots of application- and network-level security controls. For example, I can browse Github, but the corporate proxy blocks POST requests to upload code to it. – Ivan Mar 25 '17 at 12:06
  • 2
    Regardless of how many developers you have, how / if you would go about this hinges on whether / why access restriction is needed. In the case with 10 developers, is the project actually sensitive enough that it needs the extra safety measures, or do you need to question why you can't trust your (relatively small) team sufficiently. – Οurous Mar 25 '17 at 12:08
  • 8
    @Johnny Such technical measures are not worth it. Remember that you are dealing with software developers. They solve computer problems for a living. If they really want to get some information out of your building, they will find a way to do it. If you block github, i'll just upload the code to my own server. If you have application-level firewalls which detect your code on-the-wire, I'll encrypt it. If you block all my internet access, I'll smuggle it out on physical media. – Philipp Mar 25 '17 at 12:48
  • 33
    If you don't trust your developers, then you have bigger problems. – Ave Mar 25 '17 at 15:52
84

In any sanely managed company, a developer usually gets full access to the sourcecode of any project they work on.

The reason is that the benefits of releasing parts of the code on a strict need-to-know basis isn't worth the bureaucratic hassle and the huge work impairment it creates for the developers.

  1. Developers can't work without seeing the whole picture. I am a professional software developer who works in a team which maintains a huge system. Most of the problems I get tasked to fix are bugs which could be in any part of the system. I need the full sourcecode in order to figure out where the bug originates and how to fix it. I wouldn't be able to do that job if I would need to fill out a form and wait for management approval before I can look at some of the modules which could have something to do with it.
  2. Good software developers don't grow on trees. They are hard to replace and they can easily get a job somewhere else. To get and keep the best talent, you need to treat your developers well. If my company would start to hassle me with unreasonable access restrictions to sourcecode, it would frustrate me because I can't work efficiently and it would insult me because it means they don't trust me. I would be gone in a few weeks.
  3. Most code isn't actually that valuable. Most code which gets written in the world is only useful for solving the problem of one specific client. For anyone else, the code is completely worthless.
  4. Even if the code is valuable to a larger demographic, you have the law to protect it. Copyright and non-disclosure clauses in work contracts allow you to sue the pants off of anyone who tries to sell your intellectual property to someone else.

Technical measures to prevent sourcecode leaks on a network layer (like proposed in the comments to the question) are not an effective solution either. Developers are smart. They solve computer problems for a living. If they really want to get some information out of your building, they will find a way to do it. Not even the NSA was able to prevent Edward Snowden from leaking gigabytes of confidential data.

Besides, a malicious developer can do far more harm than just leak your sourcecode. There isn't much you can do about that, because the more you try to monitor and limit your developers, the less efficient they will be and the more unhappy they will become.

So what can you do to prevent your developers from turning against you? It's simple: Don't hire developers you can't trust and treat them well so they won't form a grudge against you. That means if you are a manager suffering from paranoia and trust issues, then software development is not the right industry for you (you might want to give retail a chance).

  • 33
    What a wonderful answer. I whole-heartedly agree. My employer used to outsource to contract agencies and limit what source code contracts got access to. There were 3 results: 1) Poor morale 2) Contractors took forever to accomplish tasks 3) Problems got solved in the wrong component. For example, if component A mysteriously returns 1 less than the answer, but you don't have permission to see or change component A, then you change component B to add 1 to the result of A. Now a developer fixes the bug in component A. Now you have another problem! – Brandon Mar 25 '17 at 15:45
  • 2
    Well said. I would also add that a lot of successful tech companies (Google, Facebook...) are known for giving all of their developers open access to the entire codebase. As far as I can tell the only thing Google restricts access to is their core search algorithm. – tlng05 Mar 25 '17 at 18:15
  • 1
    Technical anti-exfiltration measures might slow down an external attacker who has compromised your network, giving you more time to detect the attack. That may give the measures some value. But if no one's paying attention, the attacker will just find other channels. An internal attacker familiar with the network probably won't be slowed down at all. – Jeffrey Bosboom Mar 25 '17 at 19:16
  • 1
    The recent film Hidden Figures shows how one of the (African American female) characters is tasked with making rocket calculations with all the relevant numbers blacked out because she had no clearance. Needless to say, that is not helpful. – gerrit Mar 25 '17 at 23:48
  • 2
    @PaulWasilewski I think we're just arguing semantics here. The point is, Google tries to make as much of its code available to as many of its developers as possible. Developers are not restricted to only the code that they are "supposed to" be touching. – tlng05 Mar 26 '17 at 17:53
3

It really depends on the type of industry your are supporting/working. I believe that high percentage (90% ? )of projects do not drive their competitive advantage through their software intellectual property. here are some data points to consider:

  1. When someone takes a piece of source code or design/implementation/architecture idea it usually ends up being modified for the common good (main reason open source so great and benefits many).
  2. When companies actually open source their products, they gain competitive advantage synergy drives innovation (tomcat, mysql,php,jquery, sugarcrm, and thousands more).
  3. You can steal a good piece of software only to discover that as soon as you deploy it as your own, the original is already way better than your copy.

Now if you really want to prevent someone stealing your source code without preventing your developers to have access to all source code do the following:

worth notice is the fact that this approach does not interfere with your developer productivity until they ll try to steal your code.

  1. Deploy trusted devices. There are multiple ways to do it, one way is using RDE ( remote desktop environment) it is very mature not and it is not the old fashion remote desktop control.
  2. Deploy perimeter security on your trusted device, basically a encrypted bubble around your trusted device (laptop, desktop, mobile), again there are many way to accomplish this, start your research on data loss prevention (DLP) and information rights management(IRM). I'm not recommending specific product as it would depend on your existing architecture landscape.

Not the answer you're looking for? Browse other questions tagged or ask your own question.