GitHub Agentic Autofix jest już ogólnodostępny: od alertu bezpieczeństwa do sprawdzonej poprawki

Alert bezpieczeństwa informuje, że coś wymaga uwagi. Niekoniecznie podpowiada jednak, jak zmienić aplikację, nie psując jej przy tym. Dla nowej osoby utrzymującej małą aplikację ta luka może zatrzymać poprawkę, zanim się zacznie; dla programisty oznacza niekiedy rosnący stos dobrze znanych ostrzeżeń.

15 października 2026 r. GitHub ogłosił ogólną dostępność Agentic Autofix dla alertów skanowania kodu. Przypisz alert do Copilota, a agent zbada kod, zaproponuje zmiany, spróbuje je zweryfikować i otworzy szkic pull requestu. Przydatna zmiana zaczyna się od konkretnej propozycji naprawy do sprawdzenia, zamiast pustego edytora. Ogłoszenie GitHub o GA, 15 października 2026 r.

Ten przewodnik prowadzi od repozytorium spełniającego warunki do pierwszej sprawdzonej poprawki, a następnie omawia powiązane alerty, własne skanery, koszty i nieudane próby. Nasza rekomendacja: traktuj agenta jak autora poprawki, a nie osobę zatwierdzającą wydanie. Zanim zmiana trafi do aplikacji, nadal musisz ją rozumieć.

Diagram otwierający oddziela proponowaną przez agenta naprawę od decyzji człowieka o scaleniu.

Zacznij od jednego alertu, nie całego zaległego stosu

Pierwszy sukces powinien być niewielką zmianą, którą potrafisz wyjaśnić, przetestować i przejrzeć. Pull request to propozycja włączenia zmian do głównej gałęzi projektu; oznaczenie draft sygnalizuje, że propozycja nie jest jeszcze gotowa. CodeQL to silnik analizy kodu GitHuba, który tworzy alerty o potencjalnie podatnym kodzie.

Zanim podejmiesz się dużego porządkowania, wykonaj następujące kroki:

1. Wybierz repozytorium, którym administrujesz. Przed uruchomieniem sesji agenta potwierdź, że repozytorium kwalifikuje się do funkcji, uzyskano zgodę na dostęp i ustalono właściciela rozliczeń.
2. Najpierw sprawdź analizę CodeQL. Jeśli repozytorium ma już działającą analizę, zachowaj tę konfigurację i sprawdź ostatnie udane uruchomienie. Aby skonfigurować nową, w ustawieniach repozytorium przejdź do Settings > Advanced Security > Code Security, znajdź CodeQL analysis, wybierz Set up > Default, sprawdź konfigurację i naciśnij Enable CodeQL. Poczekaj na poprawne zakończenie analizy. Instrukcje GitHuba, sprawdzone 18 października 2026 r.
3. Włącz Agentic Autofix zgodnie z obowiązującymi zasadami. Przełącznik na poziomie repozytorium nie może obejść zakazu organizacji lub przedsiębiorstwa.
4. Wybierz jeden istniejący alert z gałęzi domyślnej. Otwórz Security and quality > Code scanning, wybierz alert, a następnie kliknij Assign to Copilot w sekcji Assignees. Procedura obsługi alertu w GitHubie, sprawdzona 18 października 2026 r.
5. Sprawdź szkic pull requestu i log sesji. Przeczytaj diff, uruchom odpowiednie testy i ponownie wykonaj skanowanie konfiguracją, która wykryła problem.
6. Scal dopiero po weryfikacji przez człowieka i wymaganych kontrolach. Następnie sprawdź stan alertu po analizie zaktualizowanej gałęzi domyślnej.

Zobacz oficjalną demonstrację interfejsu GitHuba w ogłoszeniu GA. Korzystaj z niej jako punktu odniesienia obok własnego repozytorium, a nie zakładaj, że ilustracja odtwarza każdy aktualny ekran.

Czy funkcja działa w twoim publicznym lub prywatnym repozytorium?

Ogłoszenie premierowe podkreśla klientów korporacyjnych. Aktualna dokumentacja dostępu GitHuba ma szerszy zakres: obejmuje publiczne repozytoria w GitHub.com i repozytoria należące do organizacji, które mają GitHub Code Security lub GitHub Advanced Security. Licencja Copilot nie jest wymagana. Dokumentacja dostępu GitHuba, sprawdzona 18 października 2026 r.

Publiczny dostęp nie oznacza, że sesje agenta są bezpłatne. Zanim zaprosisz współpracowników do testów, osobno sprawdź kwalifikację repozytorium i opłaty za użycie.

Włączaj dostęp od najwyższego poziomu zasad w dół

W organizacji należącej do przedsiębiorstwa właściciel przedsiębiorstwa lub menedżer ds. bezpieczeństwa musi najpierw zezwolić na funkcję w Policies > Advanced Security > Agentic Autofix. Samo zezwolenie nie włącza funkcji. Następnie właściciel organizacji lub menedżer ds. bezpieczeństwa włącza ją w Settings > Advanced Security > Global settings; kwalifikujące się repozytoria dziedziczą to ustawienie. Administrator repozytorium może wyłączyć funkcję lub włączyć ją ponownie tylko wtedy, gdy pozwalają na to nadrzędne zasady. Organizacje samodzielne pomijają etap przedsiębiorstwa; kwalifikujące się publiczne repozytoria osobiste używają bezpośrednio ustawienia repozytorium. Osoby korzystające z preview muszą włączyć funkcję ponownie. Procedura zasad GitHuba, sprawdzona 18 października 2026 r.

Schemat dostępu: zezwolenie, włączenie i wybór repozytorium to odrębne decyzje. Źródło: dokumentacja dostępu GitHuba, sprawdzona 18 października 2026 r.

Przed wdrożeniem w całej organizacji wskaż repozytoria, które powinny pozostać wyłączone, i ustal, kto sprawdza wygenerowane poprawki. Rozsądny pilotaż łączy opiekuna jednego repozytorium z recenzentem ds. bezpieczeństwa. Zapisz alert, oczekiwane zachowanie, osobę sprawdzającą i właściciela budżetu, aby niezaopiekowany szkic nie stał się niewyjaśnioną odpowiedzialnością kogoś innego.

Upewnij się, że CodeQL rzeczywiście przeanalizował kod

Konfiguracja domyślna wymaga GitHub Actions i publicznej widoczności albo Code Security. Sprawdź wybrane języki i zestaw zapytań, a nie tylko przełącznik informujący o włączeniu. Jeśli istniejąca konfiguracja zaawansowana działa, nie przełączaj jej pochopnie: konfiguracja domyślna zastępuje dotychczasowe ustawienia, wyłącza istniejący workflow i blokuje przesyłanie analiz przez API CodeQL. Dokumentacja domyślnej konfiguracji GitHuba, sprawdzona 18 października 2026 r.

Przed wybraniem alertu sprawdź wynik ostatniej analizy. Ustal, czy uwzględniono zmienioną usługę i czy kompilacja albo zależności nie spowodowały błędu analizy. Ustawienie oznaczone jako włączone nie dowodzi, że właściwe pliki zostały poprawnie przeanalizowane. Zanim poprosisz agenta o naprawienie wyników niewiarygodnej analizy bazowej, rozwiąż problem konfiguracji.

Na pierwszą próbę wybierz lokalny problem z jasnym oczekiwanym zachowaniem, na przykład wyszukiwanie w bazie danych lub konkretną ścieżkę renderowania danych wyjściowych. Nie zaczynaj od szeroko zakrojonego przeprojektowania autoryzacji. Jeśli nie ma odpowiedniego alertu, nie wprowadzaj celowo luki w zabezpieczeniach do działającego repozytorium tylko po to, by przeprowadzić demonstrację.

Co dzieje się między przypisaniem a szkicem pull requestu?

GitHub opisuje agenta, który bada odpowiednie pliki, generuje poprawkę, ponownie uruchamia CodeQL i iteruje przed otwarciem szkicu pull requestu. Propozycja zawiera podsumowanie naprawy i szczegóły walidacji. To przepływ Agentic Autofix, a nie automatyczne scalanie z gałęzią domyślną. Przepływ pracy opisany przez GitHub, 15 października 2026 r.

Po przypisaniu alertu przeprowadź następującą kontrolę:

1. Ponownie przeczytaj pierwotne ustalenie. Wskaż niezaufane dane wejściowe, wrażliwą operację i oczekiwaną ochronę. Zapisz identyfikator alertu i konfigurację, która go zgłosiła.
2. Przeczytaj każdy zmieniony plik. Szukaj niepowiązanych zmian, usuniętych kontroli, wyłączonych testów, nowych zależności i zmienionego zachowania obsługi błędów.
3. Sprawdź dowody z sesji. Odróżnij zakończone skanowanie od nieudanego polecenia lub komunikatu o niedostępnej walidacji. Możesz poprosić o kolejną iterację w sesji lub przez wzmiankę Copilota w komentarzu do pull requestu. Wskazówki GitHuba dotyczące sesji, sprawdzone 18 października 2026 r.
4. Uruchom testy aplikacji i odpowiedni skaner. Użyj udokumentowanych poleceń projektu w stosownym środowisku programistycznym. Zanim uruchomisz nieznany kod, sprawdź skrypty konfiguracji i zmiany workflow.
5. Poproś o akceptację człowieka. Pozostaw szkic zablokowany, dopóki zachowanie, pokrycie skanem lub odpowiedzialność pozostają nierozstrzygnięte. Oznacz go jako gotowy dopiero wtedy, gdy dowody nadają się do oceny.

Pętla weryfikacji: szkic utworzony przez agenta jest etapem pośrednim, a nie dowodem bezpieczeństwa aplikacji. Źródło: ogłoszenie i dokumentacja rozwiązywania alertów GitHuba.

Pull requesty GitHuba pokazują diff w Files changed i wyniki automatyczne w Checks. Korzystaj z obu widoków: zielone podsumowanie nie wyjaśnia, czy zmieniona kontrola uprawnień nadal egzekwuje zasady twojej aplikacji. Opis pull requestów GitHuba, sprawdzony 18 października 2026 r.

Przepływ 1: napraw małe zapytanie do bazy, nie zmieniając jego znaczenia

Wyobraźmy sobie fikcyjną usługę Pythona, która wyszukuje w bazie pozycję magazynową według etykiety. Obecna implementacja wstawia podaną etykietę do SQL przez formatowanie ciągu, a alert skanowania kodu wskazuje konstrukcję zapytania. Użyteczna poprawka oddziela instrukcję SQL od wartości, zamiast usuwać pojedyncze znaki interpunkcyjne.

Przykładowa, bezpieczniejsza implementacja z interfejsem sqlite3 Pythona:

def find_item(connection, label):
    return connection.execute(
        "SELECT id, label FROM inventory WHERE label = ?",
        (label,),
    ).fetchone()

Placeholder wiąże wartość oddzielnie od tekstu SQL, zgodnie z oficjalnymi wskazówkami Pythona dotyczącymi wiązania parametrów, sprawdzonymi 18 października 2026 r.. To fikcyjny wzorzec naprawy, a nie wynik Agentic Autofix ani opis przeprowadzonego testu. Rzeczywiste zapytanie, schemat i reguły autoryzacji w prawdziwej usłudze wymagają osobnej weryfikacji.

W tym przykładzie poproś o testy zwykłej etykiety, etykiety z apostrofem, takiej jak Maker's Kit, oraz nieznanej etykiety. Sprawdź, czy funkcja zachowuje oczekiwany zwracany wiersz albo None. Potem przetestuj dotychczasowe reguły dostępu wywołującego endpointu; parametryzowane zapytanie nie decyduje, kto może odczytywać dane magazynowe.

Przydatny komentarz do przeglądu mógłby brzmieć: „Zachowaj dotychczasowe zachowanie wyszukiwania, przekaż etykietę jako dane i dodaj testy regresyjne dla apostrofów oraz nieznanych pozycji”. Opisuje kontrakt zamiast jedynie nakazywać agentowi usunięcie ostrzeżenia. Przed zaakceptowaniem poprawki ponownie przeskanuj rzeczywisty diff.

Przepływ 2: grupuj powiązane alerty, nie przypadkowe ostrzeżenia

Załóżmy, że fikcyjna usługa internetowa ma trzy alerty związane z tym samym pomocniczym mechanizmem renderowania odpowiedzi. Przejrzyj je razem i oceń, czy właściwa jest jedna wspólna poprawka. GitHub pozwala zaznaczyć do 25 zaległych alertów na liście alertów lub w kampanii bezpieczeństwa; jedno przypisanie tworzy jedną sesję i jeden pull request. Instrukcje zbiorczego przypisywania w GitHubie, sprawdzone 18 października 2026 r.

Limit to maksymalna pojemność, nie zalecana wielkość partii. Trzy powiązane ustalenia z jednym właścicielem bywają łatwiejsze do przejrzenia niż dwadzieścia niepowiązanych alertów dotyczących uwierzytelniania, plików i dostępu do bazy. Przed przypisaniem wypisz każdy dotknięty endpoint i zwykłe zachowanie, które należy zachować.

W tym przykładowym przepływie przejrzyj wspólny mechanizm i przetestuj każdego jego użytkownika. Jeśli proponowana poprawka zmienia escapowanie danych wyjściowych, sprawdź właściwe konteksty wyjścia, zamiast akceptować zmianę tylko dlatego, że jeden przykład wygląda teraz dobrze. Podziel pracę, jeśli różne ustalenia wymagają odrębnych recenzentów lub harmonogramów wydania. Nie pozwól, by jedno nierozwiązane ostrzeżenie przesłoniło to, które naprawy rzeczywiście mają potwierdzenie.

Przepływ 3: własny skaner wymaga odrębnego potwierdzenia

Agentic Autofix obsługuje tylko zaległe alerty z gałęzi domyślnej. Alerty pojawiające się wyłącznie w pull requeście lub innej gałęzi nie należą do tego przepływu przypisywania. Jeśli nowy pull request wprowadza problem, napraw go tam, zamiast scalać podatny kod tylko po to, by alert można było przypisać. Opis zakresu GitHuba, 15 października 2026 r.

Jest też inne ograniczenie: GitHub informuje, że walidacja agenta nie może potwierdzić napraw dla własnych zapytań CodeQL, zestawu security-extended ani alertów skanowania kodu pochodzących od firm trzecich. Wbudowana walidacja ponownie uruchamia zestaw zapytań skanowania kodu w trybie best effort. Ograniczenia walidacji GitHuba, sprawdzone 18 października 2026 r.

Wyobraźmy sobie fikcyjną organizację, której własne zapytanie sprawdza wewnętrzną regułę przetwarzania danych. Nawet jeśli agent zaproponuje wiarygodną poprawkę, recenzent musi uruchomić tę własną analizę i sprawdzić wynik. Zapisz wersję zapytania, konfigurację, analizowaną rewizję i rezultat. Pomyślne uruchomienie domyślnego zestawu nie zastąpi zapytania, które zgłosiło problem.

Pozostaw silniejszy skaner włączony. Ograniczenie pokrycia w celu uzyskania zielonego statusu zmienia pomiar, a nie bezpieczeństwo aplikacji. Jeśli nie potrafisz odtworzyć wymaganej analizy, pozostaw propozycję w oczekiwaniu na walidację i wskaż osobę, która może ją przeprowadzić.

Brak licencji Copilot nie oznacza braku opłat

Agentic Autofix zużywa kredyty AI Code Security i minuty GitHub Actions. Dokumentacja rozliczeń GitHuba wyraźnie stwierdza, że kredyty AI są pobierane również w publicznych repozytoriach, które nie wymagają licencji dla aktywnych współtwórców. Jeśli konto rozliczeniowe ma odpowiednie uprawnienie, w pierwszej kolejności zużywane są wliczone kredyty AI; dalsze użycie jest rozliczane według zużycia, a na kontach bez puli wliczonej opłaty naliczane są od początku. Rozliczanie kredytów AI w GitHubie, sprawdzone 18 października 2026 r.

W repozytoriach organizacji opłaty obciążają płacącą organizację lub konto przedsiębiorstwa. Przed szerszym włączeniem sprawdź limit tego konta i budżet kredytów AI Code Security. Ogłoszenie wymaga też skonfigurowanej metody płatności Copilot; to odrębne od wymogu posiadania licencji Copilot przez każdego użytkownika. Wymagania rozliczeniowe z ogłoszenia GitHuba, 15 października 2026 r.

W pilotażu zapisuj zużycie sesji i Actions, czas recenzentów oraz to, czy poprawka została przyjęta. Nie obiecuj stałej ceny za naprawiony alert: partia, iteracja lub nieudana propozycja również wymagają rozliczenia. Porównuj koszt zaakceptowanych napraw z dotychczasowym procesem, zamiast liczyć wygenerowane pull requesty jako zakończone działania naprawcze.

Klasyczny Copilot Autofix działa inaczej: proponuje jednostopniową zmianę zamiast przepływu agenta obejmującego analizę i szkic, a jego sugestie nie zużywają kredytów AI. Tam, gdzie jest obsługiwany, pozostaje opcją, gdy Agentic Autofix nie jest włączony. Porównanie GitHuba, sprawdzone 18 października 2026 r.

Zanim scalasz, odpowiedz na siedem pytań

Nasza lista kontrolna obejmuje zachowanie działania aplikacji, a nie tylko usunięcie zgłoszonej słabości:

• Przyczyna źródłowa: Czy poprawka naprawia niebezpieczną operację, zamiast ukrywać ostrzeżenie?
• Zakres: Czy niepowiązane refaktoryzacje, nowe zależności i zmiany konfiguracji są uzasadnione?
• Zachowanie: Czy poprawne i błędne dane wejściowe, błędy oraz uprawnienia nadal działają prawidłowo?
• Testy: Czy istnieje test regresyjny, który wykryłby pierwotny problem?
• Analiza: Czy skaner zgłaszający problem przeanalizował proponowaną rewizję przy wymaganej konfiguracji?
• Zatwierdzenie: Czy odpowiedzialna osoba przejrzała diff i nierozstrzygnięte uwagi agenta?
• Po scaleniu: Czy analiza gałęzi domyślnej potwierdziła oczekiwany stan alertu bez nowych ustaleń?

Komunikat „walidacja niedostępna” oznacza niedokończoną pracę, a nie zgodę. GitHub informuje, że agent może zgłosić brak możliwości walidacji lub podejrzenie fałszywego alarmu w pull requeście. Żaden z tych komunikatów nie zastępuje oceny opiekuna projektu. Zachowanie best effort opisane przez GitHub, sprawdzone 18 października 2026 r.

Co zrobić, gdy brakuje przycisku albo wynik jest błędny?

Dlaczego widzę alert, ale nie mogę go przypisać? Sprawdź, czy jest to zaległy alert z gałęzi domyślnej, kwalifikację repozytorium, włączenie funkcji i swoje uprawnienia. Przypisywanie wymaga dostępu do zapisu. Jeśli ustawienie jest zablokowane, zapytaj właściwego administratora zamiast wielokrotnie przełączać ustawienia repozytorium. Wymagania wstępne przypisania w GitHubie, sprawdzone 18 października 2026 r.

Czy czysty skan dowodzi, że aplikacja jest bezpieczna? Nie. Odpowiada na pytania objęte daną analizą i konfiguracją. Reguły biznesowe, autoryzacja, działanie w czasie wykonywania i nieobsługiwane ustalenia nadal wymagają odpowiednich testów i oceny.

Czy po nieudanej sesji mam ponawiać próbę? Najpierw sprawdź log i proponowany diff. Ustal, czy brakuje konfiguracji analizy, wykonania testów, kontekstu projektu czy samej poprawki. Podaj precyzyjną korektę albo napraw konfigurację przed kolejną próbą; ponawianie przypisań bez nowych informacji nie jest strategią naprawczą.

Czy mogę zaakceptować podejrzenie fałszywego alarmu? Zbadaj ustalenie niezależnie i udokumentuj uzasadnienie. Nie myl odrzucenia alertu z naprawą podatnego kodu i nie pozwól, by pewność agenta przesądziła o wyjątku od zasad ryzyka.

Konkluzja: propozycja poprawki to początek przeglądu

Agentic Autofix przesuwa użyteczną pracę na wcześniejszy etap: analiza, kandydat na poprawkę i dostępna walidacja pojawiają się razem. Praktyczna korzyść to krótsza droga od rozpoznania podatności do oceny konkretnej naprawy. Zacznij od wąskiego zakresu, zachowaj skanery i uzależnij akceptację od dowodów, a nie od tego, kto napisał zmianę.

Źródła

Źródła pierwotne sprawdzone 18 października 2026 r.

Linki w tym przewodniku prowadzą do ogłoszenia GA z 15 października, aktualnych zasad dostępu, koncepcji i ograniczeń Autofix, procedur rozwiązywania alertów, konfiguracji CodeQL i dokumentacji rozliczeń. Dokumentacja stanowi migawkę zasad dostępu w określonym dniu, a nie gwarancję konfiguracji każdego konta. Trzy przepływy są przykładami, nie wynikami testów praktycznych.

Miejsce na notatki z przeglądu: Zachowuj razem linki do źródeł, identyfikatory alertów, wyniki testów i podjęte decyzje w Telli.sh. Może porządkować notatki; nie skanuje repozytoriów ani nie zatwierdza poprawek. Utwórz konto Telli.sh.