Comment protéger le code source des développeurs distants?
Mon entreprise va embaucher un développeur externe pour créer de nouveaux modules et corriger quelques bugs dans notre logiciel PHP.
Nous n'avons jamais engagé de développeur externe à l'heure précédente. Comment protéger le code source? Nous ne sommes pas à l'aise de donner du code source et nous pensions que tout restait sous un VPN activé par la surveillance auquel un développeur externe se connecterait.
Quelqu'un a-t-il déjà résolu ce problème? Si c'est le cas, comment?
Edit: Nous voulons que le développeur voie/modifie le code mais sous surveillance et sur notre machine à distance. Quelqu'un at-il une configuration similaire?
Edit 2: NDA est juste une formalité. IMO, même les gens qui sont en faveur des NDA savent que cela ne fera rien pour protéger leur propriété.
Edit 3: Permettez-moi de préciser que nous ne nous inquiétons pas du fait que le développeur copie un algorithme ou une solution à partir du code. Le code sort de son cerveau, donc naturellement il est le créateur et il peut le recréer. Mais notre code est construit sur plusieurs années avec des dizaines de développeurs qui y travaillent. Disons que j'engage un programmeur incompétent par erreur, qui vole nos années de travail et le revend ensuite au concurrent. Cela peut nous faire perdre notre avantage. Je sais que c'est rare, mais une telle menace doit être prise en considération si vous êtes en affaires. Je ferai des remarques sur mes commentaires afin qu'il soit facile pour tout le monde de communiquer:
Pourquoi NDA suce? Prenez ce scénario, si quelqu'un est capable de suggérer une solution à ce scénario, je considérerai le NDA efficace. Ok, voici: nous embaucher 2 développeurs externes, l'un d'eux vend notre code tel qu'il est à quelqu'un d'autre après un an. Vous n'êtes plus en contact avec aucun des développeurs, comment êtes-vous censé savoir qui vous a arnaqué? NDA fournit un objectif, mais vous ne pouvez pas vous y fier complètement. Du moins, nous ne le pouvons pas.
Je ne voulais offenser personne pendant que je posais cette question, même si c'était involontaire. Mais encore une fois aux personnes qui répondent/commentent comme `` Je ne travaillerai jamais avec vous '' ou ce truc Men-in-black-gadget: il ne s'agit pas de vous, c'est un fil conducteur sur la faisabilité d'une solution technique donnée. Et si quelqu'un dans cette communauté a travaillé dans un tel environnement.
À propos de "Trust", bien sûr, nous n'embaucherons personne à qui nous ne faisons pas confiance. Mais c'est ça? Quelqu'un ne peut-il pas être trompeur au début? Nous avons tous fait confiance à beaucoup de politiciens pour diriger notre pays, ne nous ont-ils jamais fait défaut? Donc, je dis que la "confiance" est une autre couche de protection complète comme la NDA, et ma question ne s'adressait pas à elle. Ma question concerne plutôt les mesures techniques que nous pouvons prendre pour éviter qu'une telle chose ne se produise.
Utilisez le contrôle de source. Il n'y a rien qu'un développeur distant puisse faire qui ne soit pas réversible.
En dehors de cela, selon ce que vous entendez par "protéger", vous devriez avoir le bon contrat avec lui, y compris NDA.
Sur une autre note - pourquoi embaucher un développeur externe en premier lieu, si vous ne lui faites pas confiance?
Mise à jour:
Maintenant que vous avez précisé que par "protéger", vous voulez dire "ne pas permettre d'obtenir le code sensible", mes points ci-dessus sur les NDA et la confiance restent inchangés.
En matière de contrôle de code source, si vous disposez de plusieurs référentiels où vous disposez de différents niveaux de code (passe-partout - non sensible, infrastructure - non sensible, logique métier - très sensible etc ...), vous pouvez sélectionner le référentiel auquel donner accès ce développeur. Bien sûr, cela dépend si vous pouvez séparer comme ça et avoir toujours une application qui fonctionne (pour que cela fonctionne, certains référentiels peuvent nécessiter que les dépendances binaires soient enregistrées - il s'agirait de compiler des artefacts du sensible référentiels). La faisabilité de cela dépend de ce que vous souhaitez que le développeur travaille.
Même avec le schéma décrit ci-dessus, vous devez considérer la décompilation et la rétro-ingénierie du code (c'est toujours possible avec un attaquant suffisamment déterminé) donc l'obscurcissement du code/binaires peut être une autre chose que vous devez considérer ( encore une fois, ce n'est pas parfait - avec suffisamment de savoir-faire et de détermination, les meilleurs obscurcisseurs peuvent être vaincus).
En substance, mon point est que si vous voulez protéger une base de code sensible, vous ne devez donner accès aux parties sensibles qu'aux personnes en qui vous avez confiance.
Il existe deux façons de travailler avec les gens:
- Contrôle:
- suivre toutes leurs actions
- dicter leurs processus
- restreindre leurs libertés
- les garder échangeables
- faire une distinction claire entre eux et vous
- Collaboration
- respecter leur liberté
- fais leur confiance
- construire une relation à long terme dont les deux parties bénéficient
- travailler comme une équipe
Vous allez choisir. Mais à mon humble avis, vous ne devriez pas vous attendre à ce que les gens, que vous traitez ouvertement comme s'ils étaient des criminels potentiels, vous traitent équitablement en réponse. Voici donc une idée folle:
- être à venir et juste
- s'engager activement à créer une confiance et une fidélité mutuelles
- ne soyez pas gourmand et payez à temps
Si vous faites sentir aux gens qu'ils sont dans une relation commerciale satisfaisante, productive et lucrative, ils resteront fidèles à vous. Et c'est exactement la même chose pour les entrepreneurs et les employés. Rien ne peut empêcher vos employés de quitter et de prendre le code source avec eux, sauf une incitation à rester.
Rendez donc votre travail agréable et utile, plutôt que de gaspiller des ressources pour un contrôle effrayant.
Autrement dit: vous ne le faites pas.
Les développeurs professionnels prennent ce genre de chose très au sérieux. Ils sont bien conscients de l'importance du code et des conséquences du vol de morceaux. S'ils sont pris, c'est une tache sur leur réputation en tant que professionnel, et pourrait affecter leur gagne-pain de manière significative.
D'autres ont suggéré un NDA, et bien que ce ne soit pas un moyen technologique de "protéger le code", c'est souvent tout ce qui est nécessaire. Fonctionnellement, il n'y a aucune différence entre les programmeurs internes et externes. Vous devez céder une certaine confiance à chacun d'eux.
Vous ne devriez jamais autoriser l'externalisation ou je dirais que les entrepreneurs temporaires ont accès à tout code hautement propriétaire, extrêmement sensible ou code contenant des algorithmes précieux ou d'autres secrets commerciaux.
Même les faire signer un NDA ou un non-compétiteur est probablement inutile car ils ne tiennent généralement pas devant les tribunaux.
Cette orgie folle de délocalisation de tout développement possible est une vérole sur l'industrie et une stratégie autodestructrice. La délocalisation ou l'externalisation est logique avec des problèmes de développement subalternes, fastidieux ou bien résolus et bien compris. Il n'a jamais été conçu pour économiser de l'argent sur le travail unique et le pain et le beurre.
Lorsque vous mettez à nu le code le plus propriétaire et le plus spécifique à votre entreprise pour que le monde le voie, vous invitez littéralement de futurs concurrents à vous relever et à vous défier.
Cela étant dit, faites une évaluation approfondie de votre base de code et décidez quel code vous ne souhaitez pas qu'ils voient et voyez comment il serait facile de restreindre leur accès à cela via le contrôle de code source. S'il n'y a rien de gênant ou de préoccupant pour votre code, l'application a probablement très peu de valeur substantielle à voler.
De nombreuses entreprises aiment penser que leur base de code est spéciale et hautement propriétaire alors qu'en réalité ce n'est guère plus qu'une simple application CRUD. Dans ce cas, vous pourriez être plus soucieux d'exposer toutes vos exigences commerciales et éventuellement votre modèle de données, où la plupart des connaissances commerciales seraient stockées. Cela peut être atténué en se concentrant sur leur donnant accès au code de présentation et en restreignant l'accès au code d'accès aux données.
Faites un contrat avec le développeur externe pour qu'il ne soit pas autorisé à donner le code source à des étrangers ni à le conserver après la fin de sa location. S'il viole le contrat, c'est un cas légal. Mais vous ne pouvez certainement pas protéger le code source des yeux des développeurs!
Probablement 90% de la valeur du code source est l'équipe de développement, l'équipe de support et la communauté d'utilisateurs que vous construisez autour de lui. À moins qu'il ne s'agisse d'une sorte de start-up ultra secrète qui change la donne, le code source est essentiellement sans valeur pour un tiers. Même Microsoft a publié le code Windows NT sous NDA à un moment donné à certaines personnes en dehors de Microsoft. Mon conseil est d'exiger un NDA et d'être prêt à le défendre avec un litige dans le cas extrêmement improbable où votre adresse IP est utilisée d'une manière ou d'une autre sans votre autorisation.
Un certain nombre de points ici.
Il est hautement improbable que quiconque, sauf vous et votre entreprise, attache une valeur au code source.
Si vous exposez votre php sur un site Web public, à moins que votre ADN d'encodage ou quelque chose d'intrinsèquement complexe, tout développeur compétent puisse inverser l'ingénierie de votre algorithme en quelques jours ou semaines.
Pourquoi un externe poserait-il plus de risques qu'un employé, le nettoyeur de bureau ou toute autre personne qui pourrait accéder au code.
Si le code est vraiment précieux, un contrat indépendant standard vous offrirait toute la protection juridique dont vous avez besoin.
La meilleure façon de vous assurer d'obtenir un mauvais développeur est de le traiter comme un criminel avec chacun de ses mouvements surveillé par un système de surveillance. Personne compétent ne tolérerait cela même pendant quelques secondes.
N'embauchez pas de personnes en qui vous ne pouvez avoir confiance pour aucun poste.
Pourquoi ne pas donner à l'entrepreneur un ordinateur portable d'entreprise qui ne peut se connecter qu'à votre VPN? Ensuite, placez un pare-feu sur le VPN qui bloque tous les sites de type e-mail/bastebin, installez un enregistreur de frappe sur la machine et remplissez les emplacements USB avec de la colle krazy.
Vous pouvez mettre en boîte noire les parties sensibles de votre projet et les séparer du reste. Donnez une interface facile et bien documentée pour interagir avec ces modules sans exposer ce qui se passe à l'intérieur. De cette façon, les programmeurs embauchés peuvent facilement travailler sur votre projet sans même voir ce qu'ils n'ont pas besoin de voir tout en étant en mesure d'utiliser ce dont ils ont besoin.
Comment votre entreprise protège-t-elle le code source de vous et de vos collègues développeurs? Qu'est-ce qui vous empêche, vous et vos collègues, de voler le précieux code source et de le vendre au concurrent?
Tout ce qui fonctionne pour vous devrait fonctionner pour le développeur distant.
Microsot a protégé son code, quelqu'un sait-il comment? Eh bien voici la pensée, Microsoft a payé ses employés si bien qu'ils n'ont jamais pensé à quitter l'entreprise, ceux qui ont certainement laissé le code avec eux, regardez l'exemple de Iron Python et c'est l'équipe de développement, personne ne pouvait rien y faire, il a été pris sur google, en plus vous pouvez simplement obtenir les NDA et les documents qui peuvent dire que vous ne pouvez pas obtenir la propriété intellectuelle, mais encore une fois
a) c'est difficile à prouver, un développeur peut facilement dire qu'il avait le code avant même de lancer votre entreprise, comment prouveriez-vous que ce n'est pas le cas. J'ai lu beaucoup de livres juridiques, ce qui rend impossible de déterminer que le code appartenait à une certaine organisation.
b) Il n'y a pas de loi dans le livre qui interdit d'écrire un logiciel concurrentiel, si cela se produit, il s'appelle antitrust (il y a beaucoup d'avocats en propriété intellectuelle qui traitent des affaires antitrust), ce qui signifie en monopole dans la promotion d'une concurrence ouverte et loyale, en Angleterre, il pourrait être signalé à l'OFT (bureau du commerce équitable), je ne sais pas exactement ce qu'ils font aux États-Unis, d'après ce que j'ai entendu le procureur de la République (procureur général) ou le procureur général traiter de ces cas.
Si vous êtes vraiment impatient d'autoriser un développeur externe à accéder à votre code source, engagez-le simplement pour créer les nouveaux modules et corrigez vous-même les bogues existants.
De cette façon, le seul code que l'outsider voit jamais est le code qu'elle a écrit elle-même.