Il y a un certain nombre de raisons:

• Si cela est arrivé à une personne, cela peut être arrivé à plus. Ces autres personnes pourraient ne pas être aussi gentilles.
• Qui sait, cette personne pourrait changer d’avis. Lorsqu'ils ont fait l'effort de vous contacter et qu'ils reçoivent juste un "meh" en retour, ils pourraient être un peu agacés et décider de vous punir pour cela.
• Ou peut-être qu'ils veulent juste fouiller un peu pour vous amuser et casser quelque chose par accident.
• Vous voudrez probablement vérifier les journaux pour voir que cette personne dit la vérité. Peut-être qu'ils ont volé silencieusement vos clés de cryptage avant de vous contacter. Vous voulez probablement changer tous vos secrets juste pour être sûr.
• Et surtout, c'est un Big F * cking Deal ™. Quiconque ne réagit pas avec le choc et l'horreur, mais commande à la place une autre piña colada, ne comprend clairement pas la gravité de la situation.

Il y a de très bons points dans les commentaires et cette réponse que tout pourrait bien se passer dans certaines circonstances (par exemple, accès en lecture seule, pas de secrets dans le code, etc.). C'est exact, mais je dirais toujours que cela devrait être pris plus au sérieux. Êtes-vous vraiment sûr à 100% qu'il n'y a pas de secrets dans un ancien commit de votre repo? Le fait même que quelqu'un qui ne devrait pas avoir accès à vos systèmes l'ait de toute façon est en soi un mauvais présage.

Bien qu'il soit impossible de lire dans les pensées des personnes en jeu - je pense que le programmeur indépendant

A) Ne veut pas être accusé d'irrégularité - Il est beaucoup plus difficile d'être accusé Le vol d'IP si vous donnez un coup de pied et criez pour que votre accès soit révoqué après la hâte.

B) Est consterné par la sécurité de l'entreprise qui contrôle le référentiel privé et sait que s'il était responsable, il le voudrait être informé.

Une chose à noter est que donner à un utilisateur supplémentaire l'accès à un référentiel ouvre un tout nouveau vecteur d'attaque possible. Si quelqu'un d'autre avec des intentions malveillantes a accès au compte qui a obtenu l'accès au repo sans que le titulaire du compte d'origine ne le sache, cette personne pourrait facilement télécharger l'intégralité de votre code source.

Pour fournir un point de vue différent de celui de la majorité, cela ne devrait vraiment pas être un risque pour la sécurité ssi le projet est bien géré.

Il y a essentiellement deux choses qui ont doit être remplit. Premièrement,

• Vous ne pouvez pas introduire de code dans les branches de version sans que d'autres personnes aient à le signer. Ceci est généralement réalisé en exigeant des demandes d'extraction et des révisions de code sur tout code entrant dans une branche de publication. Dans ce cas, si la personne n'a obtenu que l'accès en lecture au référentiel, vous n'avez pas à vous en soucier. Mais quand même, vous devriez l'avoir en place de toute façon.

et deuxièmement,

• Personne n'inclut de secrets dans le dépôt. Oui, vous pouvez avoir des clés API secrètes, des certificats de signature de code et autres, mais les vrais ne devraient JAMAIS être dans votre référentiel principal accessible à tous. Si certains secrets sont nécessaires pour que le code fonctionne, incluez des versions factices de développement / test dans votre référentiel. Mais les vrais doivent être conservés séparément avec seulement un petit nombre de personnes ayant accès, de préférence pour que votre système de construction les inclue automatiquement sans intervention manuelle.

Si les deux sont vrais, je ne vois pas vraiment de mal du point de vue de la sécurité. La question de savoir s'il y a des secrets commerciaux précieux dans le code qui pourraient être divulgués à un concurrent est un autre sujet.

Ou une autre façon de penser à cela: la situation ici n'a rien de spécial. Vous devez faire face aux mêmes problèmes à chaque fois qu'un employé quitte ! Si votre référentiel contenait des secrets, une personne externe les connaît désormais tous.

Si des objets sont volés, regardez d'abord quelles personnes ont la clé du coffre-fort.

J'ai donné des coups de pied et crié dans le passé, de ne pas avoir ça key donc si (quand) quelque chose était volé, ils ne me considéreraient pas comme un possible auteur.

Donc, cela aurait pu être la même chose pour ce programmeur. Il ne voulait pas avoir cette clé.

Vous avez raison de dire que la situation n'est peut-être pas du tout urgente et que la réaction laxiste des employés peut être justifiée. Peut-être que l'employé ne s'est pas soucié du problème parce que le code en question n'était plus utilisé ou qu'il n'y avait plus de secrets.

J'ai déjà travaillé pour une startup où tout le monde utilisait les mêmes clés SSH parce que quelqu'un pensait qu'il serait plus facile de supprimer / remplacer une clé si quelqu'un faisait quelque chose de stupide.

Il y a aussi le possibilité que le développeur ait sa clé stockée dans une machine accessible au public comme un ordinateur à l'université. Cela peut sembler très peu sûr, mais convient pour "Hello World" et "Practice Papers".

Dans ce cas, comme vous l'avez dit, l'entreprise peut être relativement sûre que la personne qui a signalé le l'incident n'essaiera pas de nuire à l'entreprise. Mais vous ne pouvez jamais être sûr de qui a accès au compte / aux clés de la personne qui signalait l'incident.

Je ne lis pas le polonais, alors pardonnez tout ce qui a déjà été abordé:

Bitbucket héberge git et mercurial repo's - les deux sont distribués CVS; ceux-ci sont généralement incompatibles avec les contrôles technologiques pour protéger la propriété intellectuelle / empêcher la sortie de propriété intellectuelle; tout clone / fork existant pourrait être cloné sans visibilité centrale de la piste d'audit.

Des contrôles de sécurité appropriés doivent être en place pour modifier n'importe quel dépôt, par exemple.

• Approbation PKI pour tous les commits
• repo en lecture seule avec pull requests

Ainsi, tout dommage possible est déjà fait.

La sécurité, en fin de compte, est un ensemble de processus et de procédures et un état d'esprit. Ce n'est pas un ensemble de règles strictes et rapides. Si vous pensez qu'un système est vulnérable en raison d'une une brèche minable, alors votre état d'esprit en matière de sécurité est au mieux défectueux et ne peut être utile qu'à Henny Penny / Chicken Little.

• Si les informations d'identification ne sont pas exposées, qui s'en soucie? D'après mon expérience en tant que codeur, administrateur de systèmes Linux et responsable du nettoyage et de la réparation de la sécurité, le plus gros problème avec le code être exposé dans un repo est simplement le risque que les informations d'identification soient exposées. La réalité est que la plupart des codeurs sensés savent coder sans coder en dur dans leur code. Mais la plupart des codeurs sont simplement paresseux et savent pourquoi - ou comment - quelqu'un peut concevoir un système avec des informations d'identification séparées du code principal.

  Donc, si ce système a été exécuté par des codeurs sensés, et que le dépôt ne le fait pas exposer les informations d'identification alors vous savez quoi? On s'en fout. Mais - comme beaucoup d’entre nous le savent déjà - il existe des codeurs de niveau "flic de centre commercial" merdiques qui ne font que pousser les informations d'identification dans le code de base et c'est tout. Vous devez y jouer à l'oreille.

• L'exposition au secret commercial est un risque. Cela dépend du secteur et des exigences pour lesquels le code a été créé. Si le code est pour un blog ou un simple site Web? Peu importe. Même s'il s'agit d'un site de commerce électronique, s'il s'agissait d'une copie localisée de quelque chose comme Magneto, ce n'est pas vraiment un risque puisqu'il s'agit d'un logiciel open source. Mais si ce logiciel était quelque chose de propriétaire et risqué à exposer - comme quelque chose qui pourrait exposer des dossiers financiers et peut-être même un nouveau code chaud à un jeu - alors c'est un risque.

Mais en fin de compte, le travail d'un hacker «chapeau blanc» est d'informer les autres sur les problèmes. S'ils vont prendre un "Qui s'en soucie?" attitude face à l'exposition, c'est leur problème. Peut-être ne voient-ils vraiment aucun risque? Peut-être qu’ils ne s’en soucient vraiment pas et que cette exposition blessera les autres? Peut-être sont-ils des idiots? Peut-être sont-ils si intelligents qu'une exposition au code ne signifierait - peut-être - que quelques jours de refactorisation pour limiter les risques? Mais en fin de compte, il y a tellement de choses que l'on peut faire pour empêcher quelqu'un de se blesser.