One of my clients runs a small software development company (15 employees) with PHP as their sole server side development language. They are having a networked environment with all the computers connected to a central server via LAN. The server also runs a FTP server.

Their hardware setup is as follows:

Individual developer Environment: Windows 7 x64 Professional + XAMPP + Netbeans

Central Development Server Environment: CentOS 7 + Apache + PHP + mySQL

Their current workflow is as follows:

  1. When multiple developers are involved in a same project they create a new directory in the central server under a /projects folder using a FTP client (with a common FTP credential that everyone knows).
  2. Then they use GoodSync(http://www.goodsync.com/) to sync their files from their local machine to server and vice versa.

Also they are planning to install and use Git in the main server.

Everything works fine but the organization wants to tighten the code security so as to disallow the access of all code of all the projects to all the developers.

So how can they create a simple easy to manage but a secure system for multiple developers?

  • Once they have Git, each developer can have their own credentials and explicit permissions to access the projects as needed.
    – Adi
    Mar 18, 2015 at 7:28
  • 1
    What kind of threats are you actually trying to prevent? A developer adding a back door? Code theft? Unintentional changes? A lack of attribution for changes?
    – thexacre
    Mar 18, 2015 at 7:40
  • @thexacre: Code theft mainly. In addition to that, Unintentional changes by junior developers, a lack of attribution for changes Mar 18, 2015 at 10:41
  • @Adi: Any other server side security measures ? Mar 18, 2015 at 10:45
  • @MithunJohnJacob You can't control code theft.. ever.. ever. If someone has access to the code, and they want to steal it, they will steal it. Hire people you trust, and make them sign NDAs. That's all you can do.
    – Adi
    Mar 18, 2015 at 11:14

1 Answer 1


Firstly, you need to weigh up the cost/benefit of what you're trying to achieve.

Generally preventing code theft by developers is a very steep uphill battle, but fortunately I don't think it's a very common problem. I can't think of many prominent examples of code theft except in some cases where very specific proprietary algorithms are involved, or perhaps an employee jumping ship to a client and taking their code with them.

In terms of physically restricting access to code, really the only viable way is to restrict access to repositories. Even then, that will only be significantly effective if your application architecture in such that entire components can be operated as separate services and high risk employees can work on low risk components which might interact with the high risk components as a "black box" without having to give them access to the code.

It sounds like a high risk employee jumping ship with the project they're working on is your biggest threat and fundamentally they need access to that code to do their job so there's not much you can do about that.

The threat of legal action or damage to their professional reputation usually provides enough incentive for developers to do the right thing. Perusing these controls is probably a more practical approach. Endeavouring to hire trustworthy employees should also be obvious.

With regard to your deployment process specifically, it's pretty bad from both a security and operational standpoint. It seems you're without any form of version control, and I'd be shocked if you weren't frequently overwriting each others changes accidentally and trying to figure out who changed what without any way to know for sure.

It's typically considered good practice for:

  • Your developers not to have direct access to your production servers except via an automated deployment process that takes code from version control where changes will be attributed to a specific developer
  • To have a discrete deployment (as oppose to incrementally changing files) sourced from an explicit version control version
  • For developers to have unique accounts, and typically their version control access dictates access to the production servers via their ability to commit code which will then be deployed automatically

There's plenty of resources on implementing version control and deployment management so I won't go into it too much further.

  • The company was using Goodsync because of its simplicity and also it was easy to train junior developers with Goodsync than with Git. Also only two of the employees are having access to production servers. But all the employees are having access to all the projects and they want to stop that practice. Mar 19, 2015 at 3:57
  • Related: stackoverflow.com/questions/28401926/prevent-other-git-authors Git needs signed commits and pre-receive hooks coupled with changes to the SSH .config Feb 7, 2016 at 14:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .