24

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.

Petr
  • 665
  • 6
  • 12
  • 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
  • For example they can push the code to their own Github account or copy it into their USB, how this can be monitored ?, Thanks. – Petr Mar 25 '17 at 12:00
  • 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
  • @Johnny, I cannot block POST request beacuse again the company use Github to a private repository, If there is away to whitelist repositories this will be helpful. – Petr Mar 25 '17 at 12:13
  • 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
  • 1
    Here's how it's done at Google: https://arxiv.org/ftp/arxiv/papers/1702/1702.01715.pdf – JonathanReez Mar 25 '17 at 15:04
  • 33
    If you don't trust your developers, then you have bigger problems. – ave Mar 25 '17 at 15:52
  • @Avery, Its not about the trust, but its about the control, if you are especially in IT company you should set control in place, and not let things going on spot! – Petr Mar 27 '17 at 05:46

2 Answers2

86

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).

Philipp
  • 49,017
  • 8
  • 127
  • 158
  • 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
  • That said, it's usually worthwhile *for completely different reasons* to break large systems into distinct modules. – chrylis -cautiouslyoptimistic- Mar 26 '17 at 02:56
  • @tlng05 I don't think that's true. Also the big tech companies limiting the access to source code and specifications of R&D projects. – Paul Wasilewski Mar 26 '17 at 07:25
  • @PaulWasilewski It seems to be true for Google. See [this paper about software engineering at Google](https://arxiv.org/ftp/arxiv/papers/1702/1702.01715.pdf), section 2.1. – Philipp Mar 26 '17 at 11:12
  • If OP takes anything away, I sincerely hope it's that doing this would force their best and brightest out the door. – RubberDuck Mar 26 '17 at 12:01
  • @Philipp the paper says that google are using for *most* code one repository this doesn't mean that every developer has access to the whole code. – Paul Wasilewski Mar 26 '17 at 15:26
  • 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
  • This isn't even just true for software development. Your comparison to retail is interesting-- I worked for Target for a bit and they have a policy of given their employees almost unlimited access to everything and discretion as to what to do with that access. We were ok-ed to literally grab cash from the register and hand it to customers to solve their problems if we thought that was the best solution and the cash amount was small (and you note it in the transaction history etc.). – Please stop being evil Mar 26 '17 at 21:21
  • This explains much about the time I worked in software development for a supermarket chain. (Although they did give us access to the code base. And pretty much the entire countries credit card numbers, but I'm not sure that was by design. We had to apply in triplicate to get access to evil extrenal websites like this one). – Rich Mar 27 '17 at 03:54
  • I have edited the post, the source code got stolen and sold out. – Petr Jan 10 '18 at 08:14
  • This is a beneficial response. I came here because I want to collaborate with another dev on an Android app project I've been mostly working on alone. I've been guilty of paranoia and trust issues, which have negatively impacted my productivity in the past. I think what helps me relax much better now is knowing I have other income streams (currently have a job that I didn't previously). We get so attached to stuff when we think it's all we have. – danmaze Oct 17 '22 at 09:34
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.
Hugo R
  • 177
  • 2