Come proteggere il codice sorgente dagli sviluppatori remoti? [duplicare]

Usa il controllo del codice sorgente. Non c'è nulla che uno sviluppatore remoto possa fare che non sia reversibile.

A parte questo, a seconda di cosa intendi per "proteggere", dovresti avere il contratto giusto con lui, inclusa la NDA.

Un'altra nota: perché assumere uno sviluppatore esterno, in primo luogo, se non ti fidi di lui?

Aggiornamento:

Ora che hai chiarito che con "proteggi" intendi "non consentire di ottenere il codice sensibile", i miei punti di cui sopra su NDA e fiducia rimangono invariati.

Quando si tratta di controllo del codice sorgente, se si hanno diversi repository in cui si hanno diversi livelli di codice (boilerplate - non sensibile, infrastruttura - non sensibile, business logic - molto sensibile ecc ...), è possibile selezionare quale repository su dare accesso a questo sviluppatore. Ovviamente, questo dipende dal fatto che può separare in questo modo e avere ancora un'applicazione funzionante (perché funzioni, alcuni repository potrebbero richiedere il check-in di dipendenze binarie - questi sarebbero artefatti compilati dal sensibile repository). La fattibilità di questo dipende da ciò su cui si vuole lavorare lo sviluppatore.

Anche con lo schema sopra descritto, devi considerare la decompilazione e il reverse engineering del codice (questo è sempre possibile con un attaccante sufficientemente determinato) in modo che l'offuscamento del codice / binari possa essere un'altra cosa di cui hai bisogno considerare (ancora, questo non è perfetto - con abbastanza know how e determinazione, i migliori offuscatori possono essere sconfitti).

In sostanza, il mio punto è che se si desidera proteggere una base di codice sensibile, si dovrebbe solo dare accesso alle parti sensibili alle persone di cui ci si fida.

Ci sono due modi per lavorare con le persone:

1. Controllo:
   • controlla tutte le loro azioni
   • dettare i loro processi
   • limita le loro libertà
   • tienili intercambiabili
   • fai una chiara distinzione tra loro e te
2. Collaborazione
   • rispetta la loro libertà
   • fidati di loro
   • costruire una relazione a lungo termine che entrambe le parti beneficiano
   • lavora come una squadra

Scegli tu. Ma IMHO non dovresti aspettarti che le persone, che tratti apertamente come potenziali criminali, ti trattino in modo equo. Quindi ecco un'idea pazza:

• essere disponibili ed equi
• impegnarsi attivamente per creare fiducia e lealtà reciproche
• non essere avido e paga in tempo

Se fai sentire le persone, che sono in una relazione d'affari soddisfacente, produttiva e lucrosa, si attaccheranno a te. E questo è esattamente lo stesso per gli appaltatori e i dipendenti. Nulla può impedire ai dipendenti di smettere e prendere il codice sorgente con loro, tranne un incentivo per rimanere.

Quindi rendi il tuo lavoro piacevole e su cui valga la pena di lavorare, piuttosto che sprecare risorse su un controllo bizzarro.

In parole semplici: non lo fai.

Gli sviluppatori professionisti prendono sul serio questo genere di cose. Sono ben consapevoli dell'importanza del codice e delle conseguenze del furto di frammenti di esso. Se vengono catturati, è una macchia sulla loro reputazione di professionista e potrebbero influenzare il loro sostentamento in modo significativo.

Altri hanno suggerito una NDA, e anche se non è un mezzo tecnologico per "proteggere il codice", spesso è tutto ciò che è necessario. Funzionalmente, non c'è differenza tra i programmatori interni ed esterni. Devi cedere un po 'di fiducia a tutti loro.

Non dovresti mai permettere l'esternalizzazione o direi che gli appaltatori temporanei accedono a qualsiasi codice che sia altamente proprietario, estremamente sensibile o che contenga algoritmi preziosi o altri segreti aziendali.

Anche far firmare loro una NDA o una Non-Concorrenza è probabilmente inutile in quanto comunemente non reggono in tribunale.

Questa folle orgia di delocalizzare tutto lo sviluppo possibile è un vizio per l'industria e una strategia controproducente. Offshoring o outsourcing ha senso con problemi di sviluppo umili, noiosi o ben risolti e compresi. Non è mai stato pensato per risparmiare denaro sul lavoro unico e pane e burro.

Quando metti le tue aziende più codice proprietario e specifico del settore da mostrare al mondo, allora stai letteralmente invitando i futuri concorrenti ad alzarti e sfidarti.

Detto questo, fai una valutazione approfondita del tuo codice base e decidi quale codice non vorresti che loro vedessero e vedi quanto sarebbe facile restringere il loro accesso a questo attraverso il controllo del codice sorgente. Se non c'è nulla di problematico o preoccupante per il tuo codice, l'applicazione probabilmente ha pochissimo valore secondario da rubare.

A molte aziende piace pensare che il loro codebase sia speciale e altamente proprietario quando in realtà è poco più di una semplice app CRUD. In questo caso potresti essere più interessato a esporre tutti i tuoi requisiti di business e possibilmente il tuo modello di dati, in cui verrebbero memorizzate le maggiori conoscenze commerciali. Questo può essere mitigato concentrandosi sul dare loro accesso al codice di presentazione e limitando l'accesso al codice di accesso ai dati.

Stipula un contratto con lo sviluppatore esterno che non gli è consentito distribuire il codice sorgente agli estranei, né tenerlo dopo che il suo noleggio è terminato. Se viola il contratto, allora è un caso legale. Non puoi certo proteggere il codice sorgente dagli occhi degli sviluppatori!

Un numero di punti qui.

È altamente improbabile che qualcuno, tranne te e la tua azienda, attribuisca alcun valore al codice sorgente.

Se esporti a php su un sito web pubblico, a meno che il tuo DNA di codifica o qualcosa di intrinsecamente complesso, uno sviluppatore competente possa decodificare il tuo algoritmo in giorni o settimane.

Perché un esterno potrebbe rappresentare un rischio maggiore rispetto a un dipendente, all'ufficio o ad altre persone che potrebbero accedere al codice.

Se il codice è veramente valido, un contratto freelance standard ti darebbe tutta la protezione legale di cui hai bisogno.

Probabilmente il 90% del valore nel codice sorgente è il team di sviluppo, il team di supporto e la community di utenti che hai costruito attorno ad esso. A meno che non si tratti di una sorta di start-up di gioco super-segreto, il codice sorgente è essenzialmente inutile per una terza parte. Persino Microsoft ha rilasciato il codice Windows NT sotto NDA a un certo punto su alcune persone esterne a Microsoft. Il mio consiglio è di richiedere una NDA e prepararsi a difenderlo con contenzioso nell'evento estremamente improbabile che il tuo IP venga utilizzato in qualche modo senza il tuo permesso.

Il modo migliore per assicurarti un povero sviluppatore è trattarlo come un criminale con ogni sua mossa monitorata attraverso un sistema di sorveglianza. Nessuno competente lo tollererebbe per neanche un paio di secondi.

Non assumere persone di cui non puoi fidarti per nessuna posizione.

Perché non dare all'appaltatore un laptop aziendale che può connettersi solo alla tua VPN? Quindi metti un firewall sulla VPN che blocca tutti i siti di tipo email / bastebin, installa un keylogger sulla macchina e riempi gli slot USB con la colla krazy.

Potresti oscurare parti sensibili del tuo progetto e separarle dal resto. Fornisci un'interfaccia semplice e ben documentata per interagire con quei moduli senza esporre ciò che accade all'interno. In questo modo i programmatori assoldati possono facilmente lavorare al tuo progetto senza nemmeno vedere quello che non hanno bisogno di vedere mentre sono ancora in grado di utilizzare ciò di cui hanno bisogno.

In che modo la tua azienda protegge il codice sorgente da te e dai tuoi colleghi sviluppatori? Che cosa impedisce a te e ai tuoi colleghi di rubare il prezioso codice sorgente e di venderlo al concorrente?

Qualunque cosa funzioni per te dovrebbe funzionare per lo sviluppatore remoto.

Microsot ha protetto il suo codice, qualcuno ha idea di come? beh, ecco il pensiero, Microsoft ha pagato così bene i suoi dipendenti che non hanno mai pensato di lasciare la società, quelli che hanno lasciato con sicurezza il codice con loro, guarda l'esempio di Iron Python e del suo team di sviluppo, nessuno poteva fare nulla è stato portato su Google, inoltre puoi solo ottenere le NDA e i documenti che possono dire che non puoi ottenere la proprietà intellettuale, ma poi di nuovo

a) è difficile dimostrarlo, uno sviluppatore potrebbe facilmente dire di avere il codice prima ancora di aver avviato la tua azienda, in che modo potresti dimostrarlo sbagliato. Ho letto molti libri legali che rendono impossibile determinare che il codice appartenga a una determinata organizzazione.

b) Nel libro non esiste alcuna legge che proibisca la scrittura di un software competitivo, se ciò avviene si chiama antitrust (ci sono molti avvocati della PI che si occupano di casi antitrust), il che significa monopolio nel promuovere una concorrenza aperta e leale, in Inghilterra potrebbe essere segnalato a OFT (ufficio di commercio equo) non sicuro di quello che fanno negli Stati Uniti, da quello che ho sentito il procuratore distrettuale (procuratore generale) o il pubblico ministero si occupa di questi casi.

Se sei davvero così schizzinoso da permettere ad uno sviluppatore esterno di accedere al tuo codice sorgente, allora assumili per creare i nuovi moduli e risolvi da solo i bug esistenti.

In questo modo, l'unico codice che l'estraneo vede è il codice che lei stessa ha scritto.