Phishing GitHub de Dropbox: un test de responsabilité d'accès au code
L'incident de phishing GitHub de Dropbox en 2022 n'est pas devenu une affaire de responsabilité publique parce que des attaquants auraient prouvé avoir accédé à des contenus clients ou à des systèmes de production. Son importance est plus étroite mais sérieuse: des identifiants GitHub d'employés ont été volés, certains dépôts de code ont été consultés, et Dropbox a dû démontrer que l'identité des développeurs, l'accès aux dépôts, la rotation des jetons, la gestion des secrets
Confirmé:Dropbox a annoncé qu'en 2022, des attaquants ont obtenu par hameçonnage des identifiants GitHub d'employés, pénétré dans certains dépôts de code et copié du code et du matériel associé. Dropbox a déclaré que les dépôts ne contenaient pas de code pour les applications principales ou l'infrastructure, et que l'enquête n'a révélé aucun accès réussi aux comptes clients, mots de passe, informations de paiement ou fichiers clients.
Évaluation de la responsabilité:L'incident relève de la catégorie d'accès au code, non parce que des preuves publiques établissent une compromission en aval des données utilisateur, mais parce que les contrôles d'identité pour les plateformes de développement peuvent devenir des contrôles de confiance produit lorsque le code source, les outils internes, les clés API, les jetons d'automatisation et les références de configuration coexistent derrière le même chemin d'accès.
Test de réparation:La charge de réparation crédible ne consiste pas seulement à « faire tourner les secrets ». Il s'agit de savoir si Dropbox a pu démontrer, après l'hameçonnage, une couverture d'authentification résistante au phishing, une minimisation de l'accès aux dépôts, un inventaire des jetons, un scan des secrets, une restauration des journaux d'audit, des exceptions pour les développeurs et des limites d'incident orientées client.
