In primo luogo, devi valutare il rapporto costi / benefici di ciò che stai cercando di ottenere.
Generalmente il furto di codice da parte degli sviluppatori è una battaglia molto dura, ma fortunatamente non penso che sia un problema molto comune. Non riesco a pensare a molti esempi di furto di codice, tranne in alcuni casi in cui sono coinvolti algoritmi proprietari molto specifici, o forse un dipendente che salta la nave verso un cliente e che prende il suo codice con loro.
In termini di restrizioni fisiche all'accesso al codice, l'unico modo praticabile è quello di limitare l'accesso ai repository. Anche in questo caso, ciò sarà efficace solo se l'architettura dell'applicazione in modo tale che interi componenti possano essere gestiti come servizi separati e dipendenti ad alto rischio possano lavorare su componenti a basso rischio che potrebbero interagire con le componenti ad alto rischio come una "scatola nera" senza avere per dare loro l'accesso al codice.
Sembra che un dipendente ad alto rischio che salta la nave con il progetto a cui sta lavorando è la tua più grande minaccia e fondamentalmente hanno bisogno di accedere a quel codice per fare il loro lavoro quindi non c'è molto che tu possa fare al riguardo.
La minaccia di azioni legali o danni alla loro reputazione professionale di solito fornisce un incentivo sufficiente per gli sviluppatori a fare la cosa giusta. La lettura di questi controlli è probabilmente un approccio più pratico. Anche lo sforzo di assumere dipendenti fidati dovrebbe essere ovvio.
Per quanto riguarda specificamente il processo di implementazione, è piuttosto negativo sia dal punto di vista della sicurezza che da quello operativo. Sembra che tu non abbia alcuna forma di controllo della versione, e sarei scioccato se tu non stessi sovrascrivendo frequentemente le altre modifiche casualmente e cercando di capire chi ha cambiato ciò che senza alcun modo di sapere con certezza.
In genere è considerato una buona pratica per:
- Gli sviluppatori non possono accedere direttamente ai server di produzione se non tramite un processo di distribuzione automatizzato che preleva il codice dal controllo di versione in cui le modifiche verranno attribuite a uno sviluppatore specifico
- Per disporre di una distribuzione discreta (in contrasto con i file che cambiano in modo incrementale) proveniente da una versione di controllo della versione esplicita
- Per gli sviluppatori di avere account univoci, e in genere il loro accesso al controllo di versione impone l'accesso ai server di produzione tramite la loro capacità di eseguire il commit del codice che verrà poi distribuito automaticamente
Esistono molte risorse sull'implementazione del controllo della versione e della gestione della distribuzione, quindi non approfondirò ulteriormente.