GitHub zapisze, kto naprawdę wypchnął commit — samo nazwisko autora już nie wystarczy

GitHub ogłosił 12 października 2026 r. ograniczoną publiczną wersję testową atrybucji pushy dla klientów GitHub Enterprise. Przy każdym wypchniętym commicie platforma trwale zapisuje uwierzytelnione konto, które dostarczyło go do repozytorium, i pokazuje tę informację w interfejsie oraz API obok danych autora i committera. Zainteresowani klienci mogą poprosić o dostęp swój zespół obsługi konta.

W tej samej wersji testowej pojawił się warunek reguły repozytorium Committer must match pusher. Gdy zostanie dodany do rulesetu, blokuje push, jeżeli adres e-mail committera nie pasuje do żadnego zweryfikowanego adresu uwierzytelnionego konta wysyłającego. Nazwisko lub adres wpisany w commicie pozostaje deklaracją dostarczoną przez klienta Git; zapis konta wykonującego push pochodzi z uwierzytelnienia na GitHubie.

Autor, committer i pusher odpowiadają na różne pytania

Autor to osoba wskazana jako twórca pierwotnej zmiany. Committer jest przypisany do utworzenia danego commita, co ma znaczenie na przykład wtedy, gdy ktoś inny wprowadza przygotowaną wcześniej poprawkę do historii repozytorium. Obie informacje są metadanymi Git: klient wysyłający commit może podać w nich nazwę i adres e-mail. Pusher oznacza natomiast konto, którym uwierzytelniono wysłanie zmian do GitHuba.

Na jednym commicie te role mogą więc wskazywać różne osoby lub systemy. Programista może przygotować poprawkę, opiekun projektu utworzyć commit z tą poprawką, a konto automatyzacji wysłać ją do repozytorium. Taki układ sam w sobie nie świadczy o oszustwie. Nowa atrybucja dodaje do historii odrębną odpowiedź na pytanie, które konto dostarczyło commit, także wtedy, gdy widoczny autor i committer wyglądają wiarygodnie.

Ta różnica ma znaczenie podczas przeglądania zmian po incydencie. Dotychczasowe pola opisują deklarowane pochodzenie commita, podczas gdy nowy zapis odnosi się do operacji przyjętej przez platformę. W omówieniu Dante Company rozdzielono ustalenie konta wysyłającego od dowodu, że ktoś przejrzał poprawkę. Właściciel konta wykonującego push nie musi być autorem kodu ani osobą, która zaakceptowała jego treść.

Kiedy reguła zatrzyma fałszywego committera

Rozważmy hipotetyczny przypadek: napastnik uzyskuje dostęp do konta mającego prawo zapisu w repozytorium, lecz w metadanych commita wpisuje adres zaufanego opiekuna projektu. Historia oparta na samych polach autora i committera może wtedy mylnie sugerować, że zmianę dostarczył opiekun. Atrybucja pushy przypisze operację do konta, którego poświadczeniami uwierzytelniono wysłanie, co pozwoli odróżnić nadawcę od zadeklarowanej tożsamości.

Jeśli administrator włączy nowy warunek, push z takim committerem zostanie odrzucony, gdy jego adres nie należy do zweryfikowanych adresów konta wysyłającego. Porównywany jest adres e-mail committera, a nie samo wyświetlane nazwisko autora. Warunek nie wymaga też, by osoba wskazana jako autor była pusherem. Dlatego może przepuścić commit napisany przez współpracownika i wysłany przez opiekuna, o ile tożsamość committera odpowiada kontu użytemu do pushu.

Kontrola wiąże deklarację committera z uwierzytelnionym kontem dostarczającym zmianę. Nie ustala, kto fizycznie napisał kod, czy zmiana przeszła przegląd ani czy uprawniony właściciel konta osobiście użył swoich poświadczeń. Przy przejętym koncie zapis wskaże konto użyte do pushu, ale sam nie rozstrzygnie, kto siedział po drugiej stronie połączenia. To ważne przy ocenie incydentu, w którym samo uwierzytelnienie również mogło zostać naruszone.

Obserwacja przed włączeniem blokowania

Dla zespołu uczestniczącego w wersji testowej kolejność wdrożenia zaczyna się od sprawdzenia rzeczywistych przepływów commitów. Warto zestawić zapis pushera z polami autora i committera w zmianach wysyłanych przez ludzi, boty oraz automatyzację. Takie obserwowanie danych nie jest nazwą osobnego trybu nowej funkcji: pozwala znaleźć zamierzone rozbieżności, zanim staną się powodem odrzucenia pushu.

W dokumentacji rulesets GitHuba stan „Active” oznacza egzekwowanie reguł, a „Disabled” oznacza brak egzekwowania; tworzenie i edycja rulesetu wymagają uprawnień administratora albo odpowiedniej roli niestandardowej. Administrator może więc najpierw ustalić, jakie adresy committera pojawiają się przy poszczególnych kontach wysyłających, a potem włączyć warunek w wybranym repozytorium. Sam zapis pushera nie włącza blokowania automatycznie.

Przed aktywacją istotne są zwłaszcza operacje, w których jedno konto tworzy commit, a drugie go wysyła. W repozytorium testowym można wykonać dwa kontrolowane, nieszkodliwe wysłania zmian: z adresem committera przypisanym do konta wysyłającego oraz z innym adresem. To propozycja sprawdzenia własnego przepływu pracy, a nie opublikowany wynik testu GitHuba. Pozwala ujawnić, czy używane poświadczenia i zweryfikowane adresy odpowiadają zasadzie, którą zespół zamierza egzekwować.

Po takim sprawdzeniu administrator może dodać warunek do rulesetu i ustawić go jako aktywny. Jeżeli w repozytorium działają inne rulesety, ich wymagania również mogą obowiązywać przy tym samym pushu. Zmiana wymaga więc oceny konkretnego zestawu reguł i sposobu nadawania uprawnień, zwłaszcza tam, gdzie z jednego konta korzysta proces automatyczny.

Co zmieni się przy commitach botów i agentów

W przepływie z agentem kodującym role mogą rozdzielić się jeszcze wyraźniej: poprawkę generuje agent, commit zapisuje narzędzie, a push wykonuje konto usługi. Nowa atrybucja wskaże konto uwierzytelnione przy wysyłce. Nie ujawni na tej podstawie osoby, która zleciła agentowi zadanie, zakresu jej instrukcji ani tego, czy człowiek zaakceptował końcową zmianę.

Aktywna reguła może zatrzymać również zamierzoną automatyzację, jeśli narzędzie wpisuje jako committera adres jednego konta, a używa poświadczeń innego do pushu. Zespół musi więc ustalić, który podmiot ma być committerem w takim przepływie i jakim kontem następuje wysyłka; dopiero zgodność tych danych pozwala ocenić wpływ blokowania. Sama zmiana wyświetlanego nazwiska nie wystarczy, ponieważ warunek odnosi się do zweryfikowanego adresu e-mail.

W ograniczonej wersji testowej sprawdzianem będzie zachowanie reguły w przepływach klientów Enterprise, szczególnie przy botach, kontach usługowych i zmianach przygotowanych przez agentów. Od tego zależy, gdzie zespoły mogą włączyć blokowanie bez zatrzymywania prawidłowych dostaw kodu.

Przeczytaj także:

• KNF każe prześwietlić SaaS: certyfikat dostawcy już nie wystarczy
• Link „każdy, kto go ma” może wyciec — ogranicz dostęp do pliku
• GitHub Actions czy CircleCI? Minuta kosztuje podobnie, kolejka już nie