Jamais auparavant les organisations n'avaient traité autant d'informations - ou n'avaient été plus préoccupées par la possibilité qu'elles tombent entre de mauvaises mains. Cette préoccupation s'applique à toutes les données, mais surtout au code source sur lequel elles s'appuient pour faire fonctionner leurs processus.
Les entreprises et les particuliers s'appuient sur des plates-formes telles que GitHub, GitLab et BitBucket pour stocker et gérer leur code source et maintenir leurs projets de développement en cours d'exécution. Ces plates-formes sont extrêmement populaires : GitHub a plus que 73 millions de développeurs et 200 millions de dépôts, GitLab estimations 30 millions d'utilisateurs enregistrés et BitBucket rapporté 10 millions d'utilisateurs en 2019.
Si les équipes de sécurité ne s'inquiètent pas du code source stocké sur ces plates-formes, elles devraient l'être car il y a de fortes chances que leurs développeurs aient au moins quelques projets qu'ils y conservent. Certaines attaques de ces dernières années ont mis en évidence la menace : Une attaque de ransomware de 2019 essuyé Git référentiels de code source sur toutes les plates-formes et les a remplacés par une demande de rançon. Il y a aussi le risque de temps d'arrêt, comme c'était le cas lorsque GitHub était en panne pendant au moins deux heures en juin 2020.
Le coût de la perte du code source est élevé, déclare John Bambenek, principal chasseur de menaces chez Netenrich.
« Tout ce qui est essentiel pour une organisation doit être sauvegardé », dit-il. « Une bonne règle empirique est la suivante : « L'entreprise peut-elle continuer à fonctionner sans cela ? » et si la réponse est non, il doit y avoir un plan de secours.
Il existe de nombreuses raisons pour lesquelles une entreprise peut ne pas penser à sauvegarder son code source. Il peut s'agir en partie de vouloir économiser de l'argent et en partie de se sentir invulnérable aux attaques qui compromettraient leur code source. Il y a aussi la réalité que les sauvegardes coûtent de l'argent sans aucun avantage tangible - jusqu'à ce qu'elles soient nécessaires, note Mark Loveless, ingénieur principal en sécurité chez GitLab.
"Pour la plupart, vous faites simplement quelque chose dont vous ne voyez pas de gain immédiat", dit-il. « C'est ainsi que fonctionnent les sauvegardes. Vous ne voyez pas un gain immédiat, et vous ne voulez jamais voir un gain immédiat sur les sauvegardes parce que vous espérez que tout fonctionne et que vous n'aurez jamais à y recourir. Mais vous avez besoin d'un plan pour cela.
La sensibilisation est un autre problème. Certaines personnes peuvent ne pas sauvegarder leur code source parce qu'elles ne pensent pas qu'elles doivent le faire, ajoute-t-il. GitLab, GitHub et BitBucket, tout comme les principaux fournisseurs de cloud, ont un « modèle de responsabilité partagée » dans lequel les utilisateurs et les fournisseurs du service partagent la responsabilité de protéger leurs informations.
GitLab effectue des sauvegardes sur ses propres serveurs "à peu près constamment", explique Loveless, mais beaucoup de gens ont leur propre instance de GitLab exécutée sur leur propre espace cloud privé ou sur un serveur physique dans leur centre de données. Dans ces cas, les utilisateurs doivent tenir compte du fournisseur de cloud qu'ils utilisent, du type de sauvegardes qu'ils conservent et de la date à laquelle ils souhaitent sauvegarder leurs données.
"Git… puisqu'il stocke un historique des enregistrements de code et que vous pouvez effectuer des restaurations vers une version précédente du code, [les utilisateurs] ont tendance à penser qu'il existe une sauvegarde", déclare Loveless. "Il y en a, en ce qui concerne les révisions et les changements de code… mais ceux-ci sont stockés dans une base de données [et] des fichiers de données, et ceux-ci doivent être sauvegardés."
Une copie de travail du référentiel sur chaque ordinateur ne doit pas être considérée comme une sauvegarde car elle ne contient généralement que le code source et non les problèmes, commentaires, demandes d'extraction et autres métadonnées qui lui sont associées. Il est courant de penser qu'un référentiel Git ou un autre contrôle de version est suffisant, ajoute Taylor Gulley, consultant senior en sécurité des applications chez nVisium. Le contrôle de version, bien que très utile, n'a toujours que votre code stocké dans un seul emplacement centralisé.
"À moins que votre plan de reprise après sinistre ne consiste à extraire le code de la machine locale d'un développeur - en supposant qu'il y en ait qui survivent à l'incident qui a détruit le serveur - des sauvegardes appropriées sont essentielles", déclare Gulley.
Ce que les entreprises doivent savoir sur le processus
Les sauvegardes du code source peuvent prendre plusieurs formes. Les entreprises peuvent choisir de gérer leurs propres sauvegardes et de prendre en charge l'infrastructure, les processus et les coûts de réparation associés. Bien que cela leur donne un meilleur contrôle sur leurs données, cela peut coûter plus cher à long terme en raison des ressources consacrées à la maintenance.
Les sauvegardes manuelles impliquent également des défis techniques. Il est difficile de conserver la cohérence de tous les actifs pour les rendre récupérables dans n'importe quel référentiel Git, car chaque fournisseur a sa propre API, son processus, ses commentaires et ses problèmes. Les limites du taux de requêtes de l'API posent un autre obstacle : généralement, la sauvegarde Git est associée à l'envoi de nombreuses requêtes à l'API du fournisseur Git, et elles doivent limiter le nombre de requêtes envoyées dans un laps de temps limité.
Alternativement, ils peuvent se tourner vers un tiers qui gère la gestion des sauvegardes. Dans de nombreux cas, il existe des services cloud qui peuvent aider à cela, note Bambenek. Les organisations peuvent se tourner vers un service tel que GitProtect.io, un outil conçu pour sauvegarder le code sur GitHub, GitLab et BitBucket.
"Le besoin a été trouvé au sein de notre propre entreprise", explique Greg Bak, responsable du développement de produits GitProtect, à propos de la création du produit. «Nous avions des scripts internes pour protéger ces référentiels, mais personne n'était en mesure de garantir que nous pourrons toujours restaurer ces référentiels… qu'ils sont correctement protégés, que nos sauvegardes sont testées. Nous avons donc décidé de le [construire].
GitProtect est disponible en deux modèles : la sauvegarde en tant que service et sur site, afin que les organisations puissent l'installer localement ou le déployer sur le cloud public. L'objectif du produit est non seulement de protéger le code source, mais également toutes les métadonnées associées nécessaires pour maintenir la cohérence d'un référentiel, telles que les commentaires, les problèmes et les tâches CI/CD, explique Bak.
Il existe un certain nombre de menaces susceptibles de compromettre le code source, au-delà des attaques ciblant les référentiels et de la perturbation potentielle de ces plates-formes. Une erreur humaine et des modifications indésirables du code lui-même pourraient nécessiter des sauvegardes pour remettre les processus en marche, ajoute-t-il.
Meilleures pratiques de sauvegarde
Quelle que soit la manière dont vous décidez de sauvegarder votre code source, Loveless de GitLab conseille de faire venir un expert en sécurité dans la pièce.
« Investissez dans des agents de sécurité », dit-il. "Si vous pouvez avoir des gens là-dedans, des gens expérimentés qui savent comment faire cela, investissez dans les gens et vous devriez obtenir de bien meilleurs résultats."
Les experts conseillent également de conserver les sauvegardes stockées dans un endroit sûr et cryptées. Si vous exécutez un environnement multicloud, effectuez une rotation des sauvegardes hors site ou hors système. Gulley recommande de conserver quelques copies sur place et une hors site, au cas où l'emplacement serait compromis. Les sauvegardes précédentes ne doivent pas pouvoir être modifiées ou supprimées par les processus ou les comptes de sauvegarde automatisés.
Tous les experts s'accordent à dire qu'il ne suffit pas de faire des sauvegardes du code source. Il est également important de les tester et de s'assurer qu'ils fonctionnent. S'ils ne le font pas, vous ne voulez pas savoir quand vous en avez besoin. Testez le processus d'accès et d'utilisation des sauvegardes pour vous assurer que vous pouvez les utiliser et que toutes les personnes impliquées comprennent leur rôle en cas d'attaque, de panne ou de compromission.
