GitHub usunął 12 285 kont EMU zamiast je zawiesić: lekcja z błędu SCIM

GitHub poinformował o błędzie w procesie deprovisioningu przez SCIM, przez który część kont Enterprise Managed Users (EMU) została usunięta zamiast zawieszona i zanonimizowana. Problem występował od 1 do 13 czerwca 2026 roku i objął około 12 285 kont w wielu przedsiębiorstwach. W zgłoszeniach, pull requestach i logach audytowych autorzy mogli pojawiać się jako użytkownicy ghost.

Według GitHuba większość kont była już zawieszona albo poddana trwałemu deprovisioningowi, ale 76 kont było aktywnych w chwili usunięcia. Firma przywróciła rekordy w październiku do oczekiwanego stanu zawieszonego i zanonimizowanego, aby zachować identyfikowalność i historię audytową. GitHub podaje, że klienci nie muszą wykonywać żadnej czynności.

Wniosek Breachroad: brak wymaganej naprawy po stronie klienta nie oznacza braku pracy z ryzykiem. Organizacja powinna udokumentować, czy błąd dotknął jej tenant, sprawdzić kompletność śladów oraz upewnić się, że odejście pracownika lub zmiana roli kończy się przewidywalnym stanem we wszystkich połączonych usługach.

Co się wydarzyło

Enterprise Managed Users pozwala przedsiębiorstwu zarządzać tożsamościami GitHub poprzez zewnętrznego dostawcę tożsamości. SCIM automatyzuje między innymi zakładanie kont i ich deprovisioning po zmianie statusu użytkownika.

GitHub wyjaśnia, że nowa ścieżka deprovisioningu nie sprawdzała prawidłowo, czy konto jest kontem EMU. W rezultacie wykonywała operację usunięcia zamiast właściwego dla EMU zawieszenia i anonimizacji. Firma wyłączyła wadliwą ścieżkę 13 czerwca, a następnie naprawiła mechanizm i odtworzyła rekordy w październiku.

Klient może rozpoznać potencjalny wpływ po zdarzeniach user.delete dotyczących kont EMU w logach audytowych z okresu od 1 do 13 czerwca. GitHub zaznacza też, że konta poddane wcześniej trwałemu deprovisioningowi zgodnie z projektem nie mogą zostać ponownie aprowizowane.

Dlaczego ghost w historii jest problemem

W codziennej pracy wpis ghost może wyglądać jak niedogodność interfejsu. W dochodzeniu, audycie albo sporze o zmianę produkcyjną brak jednoznacznego autora staje się jednak problemem biznesowym.

Historia pull requestu pomaga odpowiedzieć, kto zaproponował zmianę, kto ją omawiał i jaki był kontekst decyzji. Zgłoszenia dokumentują akceptację ryzyka, wyjątki, błędy i ustalenia z klientami. Log audytowy ma łączyć działanie z kontrolowaną tożsamością. Jeżeli te elementy tracą powiązanie z kontem, trudniej odtworzyć sekwencję zdarzeń, przypisać odpowiedzialność i wykazać działanie kontroli.

Przywrócenie rekordów przez GitHub ma właśnie odbudować tę identyfikowalność. Firma powinna jednak sprawdzić efekt we własnym kontekście, szczególnie jeśli w okresie błędu prowadziła dochodzenie, eksportowała logi do SIEM albo tworzyła raporty zgodności zawierające już wpisy ghost.

Kogo i jakie procesy mógł dotknąć błąd

Bezpośrednio problem dotyczy klientów GitHub Enterprise Cloud korzystających z EMU i deprovisioningu SCIM w wskazanym przedziale czasu. Pośrednio wpływ może objąć:

• właścicieli aplikacji i repozytoriów, którzy analizują historię zmian;
• zespoły SOC i reagowania na incydenty, jeśli korzystają z eksportowanych logów;
• audyt wewnętrzny i compliance, gdy raport powstał przed odtworzeniem rekordów;
• HR i IAM, jeżeli proces odejścia pracownika uznawał status w dostawcy tożsamości za jedyny dowód zamknięcia dostępów;
• zespoły prawne lub bezpieczeństwa produktu, które potrzebują wiarygodnego przypisania wcześniejszych działań.

Nie każde przedsiębiorstwo z EMU musiało zostać dotknięte. Najlepszą podstawą jest własny log audytowy, a nie sama informacja, że organizacja używa SCIM.

Co firma powinna sprawdzić teraz

1. Wyszukaj zdarzenia z okresu błędu

Przejrzyj logi GitHub Enterprise pod kątem user.delete dla kont EMU od 1 do 13 czerwca 2026 roku. Zachowaj wynik zapytania, zakres czasu, strefę czasową i datę wykonania kontroli. Jeżeli logi są przesyłane do SIEM, porównaj dane źródłowe z kopią zewnętrzną.

2. Rozdziel stan kont od historii działań

Potwierdź, że wskazane konta są obecnie zawieszone i zanonimizowane zgodnie z oczekiwaniem. Oddzielnie sprawdź, czy wcześniejsze zgłoszenia, pull requesty i zdarzenia audytowe ponownie pokazują właściwe powiązanie. Poprawny bieżący status konta nie gwarantuje automatycznie kompletnej historii w każdym eksporcie i raporcie.

3. Oceń 76 aktywnych kont w swoim kontekście

GitHub podał łączną liczbę aktywnych kont usuniętych przez błąd, ale nie oznacza to, że należały do każdej organizacji. Jeśli znalazłeś wpływ, ustal, czy konto było aktywne i czy usunięcie przerwało pracę, integrację albo dostęp do zasobów. Zapisz też, czy użytkownik otrzymał konto zastępcze i czy nie powstały duplikaty tożsamości.

4. Zaktualizuj wcześniejsze dochodzenia i raporty

Jeżeli między czerwcem a październikiem wykorzystano wpis ghost w analizie incydentu, raporcie zgodności lub przeglądzie zmian, zweryfikuj wnioski po odtworzeniu danych. Nie chodzi o przepisywanie wszystkich raportów, lecz o korygowanie tych, w których przypisanie autorstwa miało znaczenie.

5. Udokumentuj decyzję o zamknięciu

GitHub nie wymaga działań naprawczych od klienta. Mimo to wewnętrzny zapis powinien wyjaśniać, czy organizacja była dotknięta, jakie dowody sprawdzono i dlaczego nie są potrzebne dalsze kroki. Taki ślad jest bardziej wartościowy niż samo oznaczenie komunikatu dostawcy jako przeczytanego.

Jak wzmocnić proces SCIM i offboardingu

SCIM automatyzuje decyzję o dostępie, ale nie powinien być jedynym źródłem pewności, że proces zadziałał. Dla krytycznych usług warto stosować kontrole potwierdzające:

• oczekiwany stan konta w dostawcy tożsamości i aplikacji docelowej;
• odebranie sesji, tokenów i dostępu do organizacji oraz repozytoriów;
• zachowanie wymaganej historii działań po deprovisioningu;
• zgodność liczby operacji wysłanych przez IdP i przyjętych przez usługę;
• obsługę błędów, ponowień oraz nietypowych zdarzeń usunięcia;
• test reprezentatywnego scenariusza odejścia po istotnej zmianie integracji.

Właściciel IAM powinien wiedzieć, czym różni się zawieszenie, anonimizacja, miękki deprovisioning i trwałe usunięcie w każdej usłudze. Te pojęcia nie są uniwersalne. Ta sama komenda SCIM może prowadzić do innego skutku biznesowego zależnie od implementacji dostawcy.

Pytania do GitHuba lub partnera wdrożeniowego

Jeśli wyniki są niejednoznaczne, warto poprosić o:

• potwierdzenie, czy konkretne enterprise znalazło się w grupie dotkniętej problemem;
• listę identyfikatorów kont i oczekiwany stan po odtworzeniu;
• wyjaśnienie, które widoki, interfejsy API i eksporty odzyskały przypisanie autora;
• sposób odróżnienia celowego trwałego deprovisioningu od błędnego usunięcia;
• datę przywrócenia rekordów i zakres kontroli wykonanej po naprawie.

Nie należy żądać od dostawcy pełnych danych osobowych w zwykłym zgłoszeniu. Wystarczą identyfikatory, które organizacja może bezpiecznie powiązać we własnym systemie IAM.

Fakty źródłowe i wnioski Breachroad

GitHub potwierdza okres od 1 do 13 czerwca, około 12 285 usuniętych kont, 76 kont aktywnych w chwili usunięcia, przyczynę w nowej ścieżce deprovisioningu, wyłączenie jej 13 czerwca oraz październikowe odtworzenie rekordów. Producent wskazuje zdarzenie user.delete jako sposób identyfikacji i podaje, że klienci nie muszą podejmować działania.

Niezależna weryfikacja logów, przegląd raportów, kontrola efektu SCIM i testy offboardingu są rekomendacjami Breachroad. Można je osadzić w zarządzaniu dostępem uprzywilejowanym oraz planie reagowania na incydenty. Zespoły IAM, HR, IT i bezpieczeństwa powinny przećwiczyć wspólne decyzje podczas szkoleń cyberbezpieczeństwa dla organizacji, a działanie kontroli potwierdzić przez audyt bezpieczeństwa IT.

Źródło pierwotne: GitHub Changelog — Enterprise Managed Users deprovisioning incident.