En primer lugar, debe sopesar el costo / beneficio de lo que está tratando de lograr.
En general, prevenir el robo de código por parte de los desarrolladores es una batalla cuesta arriba, pero afortunadamente no creo que sea un problema muy común. No puedo pensar en muchos ejemplos destacados de robo de código, excepto en algunos casos en los que están involucrados algoritmos patentados muy específicos, o tal vez un empleado que se lanza a un cliente y se lleva su código.
En términos de restringir físicamente el acceso al código, realmente la única forma viable es restringir el acceso a los repositorios. Aun así, eso solo será significativamente efectivo si la arquitectura de su aplicación es tal que los componentes completos pueden operarse como servicios separados y los empleados de alto riesgo pueden trabajar en componentes de bajo riesgo que pueden interactuar con los componentes de alto riesgo como una "caja negra" sin tener para darles acceso al código.
Suena como si un empleado de alto riesgo que se embarca en el proyecto en el que están trabajando es su mayor amenaza y, fundamentalmente, necesiten acceso a ese código para hacer su trabajo, por lo que no hay mucho que pueda hacer al respecto.
La amenaza de una acción legal o daño a su reputación profesional por lo general proporciona un incentivo suficiente para que los desarrolladores hagan lo correcto. Examinar estos controles es probablemente un enfoque más práctico. Intentar contratar empleados de confianza también debería ser obvio.
En relación con su proceso de implementación específicamente, es bastante malo desde el punto de vista de seguridad y operativo. Parece que no tiene ningún tipo de control de versión, y me sorprendería que no estuviera sobrescribiendo los cambios de forma accidental e intentando averiguar quién cambió qué sin saber de qué manera.
Normalmente se considera una buena práctica para:
- Sus desarrolladores no deben tener acceso directo a sus servidores de producción, excepto a través de un proceso de implementación automatizada que toma el código del control de versiones, donde los cambios se atribuirán a un desarrollador específico
- Para tener un despliegue discreto (en oposición a cambiar archivos de manera incremental) proveniente de una versión de control de versión explícita
- Para que los desarrolladores tengan cuentas únicas y, por lo general, su acceso de control de versión dicta el acceso a los servidores de producción a través de su capacidad de confirmar código, que luego se implementará automáticamente.
Hay muchos recursos para implementar el control de versiones y la administración de la implementación, por lo que no voy a profundizar mucho en ello.