Ing. Calogero Bono
GitHub przedstawił 20 października 2026 roku package firewall, filtr, który stawia się między komputerami instalującymi pakiety a publicznymi rejestrami, z których je pobierają. Obecnie jest dostępny w publicznej wersji testowej dla wszystkich klientów GitHub Enterprise Cloud i obsługuje wyłącznie npm. Celem jest zatrzymanie malware, który atakuje w momencie instalacji, co jest szczególnie groźne dla agentów AI i systemów build instalujących zależności bez nadzoru. Jeśli tworzysz oprogramowanie albo zarządzasz zespołami, które to robią, to sygnał, dokąd zmierza bezpieczeństwo łańcucha dostaw.
Kilka pojęć, zanim przejdziemy do faktów. Rejestr (registry) to internetowe repozytorium, z którego pobiera się pakiety, na przykład npm dla JavaScriptu. Zależność to fragment cudzego kodu, którego używa twój projekt. CI/CD to automatyczne procedury, które kompilują i publikują oprogramowanie. Attestation SLSA to weryfikowalne oświadczenie o tym, jak i przez kogo pakiet został zbudowany. Metadane to informacje o pakiecie, na przykład lista dostępnych wersji.
Czym jest package firewall GitHub?
Według oficjalnego changelogu GitHub, w ostatnim czasie nastąpiła prawdziwa fala ataków malware, które wykorzystują moment instalacji pakietów. Szczególnie narażeni są agenci i runnery CI, ponieważ instalują zależności, by wykonać zadanie albo build, bez udziału człowieka.
Firewall znajduje się między endpointami lub wewnętrznymi rejestrami a upstreamowymi repozytoriami pakietów. Jak podaje The Hacker News, GitHub opisuje go tak – „The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate”, czyli jako bramka z regułami stosowana w momencie instalacji.
Temat nie jest czysto teoretyczny. Serwis The Register napisał o kampanii, w której atakujący mieli zamienić issue na GitHubie w atak na łańcuch dostaw przeciwko 61 publicznym repozytoriom w mniej niż godzinę. Ze strony, którą mamy do dyspozycji, nie wynikają dalsze szczegóły, więc nie możemy powiedzieć, czy obie informacje są ze sobą powiązane.
Jak działa i jakie ma kontrole?
Działanie opiera się na dwóch krokach. Najpierw administratorzy ustawiają reguły dla swojego enterprise. Następnie agenty kodowania i hosty CI/CD kierują się do firewalla zamiast bezpośrednio do publicznych rejestrów. Zarówno żądania metadanych, jak i pobrania pakietów przechodzą przez firewall, który ocenia je zgodnie z polityką.
Dostępne kontrole
Z zestawienia The Hacker News wynikają następujące kontrole.
- Blokada znanego malware, z sprawdzaniem aktywnych ostrzeżeń w GitHub Advisory Database.
- Blokada według wagi podatności, także na podstawie tej bazy. Domyślnie blokowany jest tylko poziom „Critical only”, ale można wybrać „High or higher”, „Medium or higher” albo „Any severity”.
- Blokada obniżenia wersji attestation. Firewall porównuje attestation żądanej wersji z attestation wersji wcześniejszych i zatrzymuje pobieranie, jeśli brakuje attestation SLSA.
- Blokada nowych skryptów instalacyjnych, czyli tych uruchamianych przez hooki preinstall lub postinstall, które mogą służyć do kradzieży wrażliwych danych.
- Okres oczekiwania (cooldown), który uniemożliwia instalację wersji nowszych niż skonfigurowany minimalny wiek.
Cooldown może trwać od 1 do 365 dni. Wartość domyślna to 1 dzień, a wyłącza się go, ustawiając 0.
A jeśli zablokuje dobry pakiet?
Jeśli pakiet zostanie zablokowany omyłkowo, użytkownik może poprosić o wyjątek. Według GitHub proces jest podobny do tego w innych funkcjach GitHub Advanced Security. Jak podaje The Hacker News, wniosek mogą zatwierdzić administratorzy i osoby odpowiedzialne za bezpieczeństwo w enterprise.
Ile kosztuje i kto może z niego korzystać?
Usługa jest dostępna w publicznej wersji testowej dla wszystkich klientów GitHub Enterprise Cloud, także w wariancie z rezydencją danych. W czasie wersji testowej jest bezpłatna. Gdy nastąpi dostępność ogólna, GitHub zapowiada płatność według zmierzonego zużycia, podobnie jak w przypadku rozliczeń Actions.
GitHub tłumaczy, że wersja testowa służy do rozbudowy infrastruktury i dodawania funkcji zgodnie z prośbami klientów. Instrukcje konfiguracji znajdują się w dokumentacji „Zabezpieczanie endpointów za pomocą package firewall”.
Dlaczego tyle mówi się o okresach oczekiwania?
Cooldown to najprostsza i być może najbardziej rozpowszechniona reguła. The Hacker News przypomina, że w ostatnim roku podobne okresy oczekiwania wprowadzono w npm, Pythonie, Visual Studio Code, Ruby, Bunie, pnpm i Yarnie. Zasada polega na zmniejszeniu prawdopodobieństwa, że świeżo opublikowana, jeszcze niesprawdzona wersja od razu trafi do builda.
Pomaga przede wszystkim przeciwko osobom, które przejmują konto maintainera i publikują zatrutą wersję popularnego pakietu. Oczekiwanie hamuje szybkie rozprzestrzenianie się, ręczne lub automatyczne.
Ten sam artykuł zaznacza, że Rust 1.100, którego premiera zaplanowana jest na 12 listopada 2026 roku, ma dodać konfigurowalny minimalny wiek publikacji dla crate’ów. Opcja nazywa się „global-min-publish-age” i znajduje się w pliku cargo/config.toml. Jeśli nie zostanie określona, obowiązuje domyślny okres oczekiwania wynoszący siedem dni.
Drugą stronę medalu wskazuje Socket, cytowana przez The Hacker News. „The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception”, mówi firma. Dodaje, że wydanie, które przeszło przez kontrole, może po prostu przetrwać cooldown. Według Socket wartość tego rozwiązania polega na tym, że daje czas badaczom, maintainerom i rejestrom na reakcję.
Ograniczenia, o których warto wiedzieć
- Firewall obsługuje obecnie tylko npm. Osoby pracujące z PHP, Pythonem czy innymi ekosystemami nie są objęte ochroną, a źródła nie podają terminów dla innych rejestrów.
- Jest zarezerwowany dla klientów GitHub Enterprise Cloud. Źródła nie wspominają o mniejszych planach.
- Jesteśmy w wersji testowej. Funkcje, infrastruktura i ceny mogą się zmienić, a koszt zależny od zużycia nie został jeszcze określony.
- Nie mamy niezależnych danych o skuteczności. Źródła przytaczają deklaracje GitHub, a nie testy na prawdziwym malware, i nie podają liczb dotyczących fałszywych alarmów.
- Jak przypomina Socket, cooldown nie czyni złośliwego kodu nieszkodliwym. Niewykryta wersja może pozostać ukryta dłużej niż okres oczekiwania.
Co zmienia się dla osób pracujących w świecie cyfrowym
Praktyczny wniosek jest taki, że bezpieczeństwo przesuwa się z kontroli po fakcie na kontrolę przed instalacją. Dla zespołów, które rozwijają oprogramowanie z agentami AI samodzielnie piszącymi i instalującymi kod, oznacza to centralną regułę zamiast zaufania pojedynczemu agentowi. Jeśli używasz narzędzi programistycznych wspieranych przez AI, warto przeczytać o ryzykach, które opisaliśmy w artykule o vibe codingu dla małych firm.
Dla włoskich firm temat dotyka także zgodności z przepisami. Bezpieczeństwo łańcucha dostaw oprogramowania jest częścią tego, o czym piszemy w przewodniku po rejestrze dostawców NIS2. Możliwość wykazania, że pakiety przechodzą przez filtr z zapisanymi regułami, to konkretny argument, choć żadne źródło nie łączy firewalla z NIS2.
Kto intensywnie korzysta z open source, powinien pamiętać, że każda zależność to dostawca. Piszemy o tym w materiale o open source w firmie. Nawet osoby bez planu Enterprise mogą skorzystać z tej idei dzięki dostępnym narzędziom, na przykład okresom oczekiwania oferowanym przez niektórych menedżerów pakietów.
Dla serwerów build i produkcyjnych liczą się także aktualizacje i izolacja. Jeśli wolisz infrastrukturę prowadzoną przez innych, dostępna jest nasza usługa hostingu i zarządzanych serwerów. Jeśli natomiast rozważasz projekt szyty na miarę, ścieżkę znajdziesz w tworzeniu oprogramowania na zamówienie.
Nasza opinia
Pomysł jest słuszny. Zatrzymanie pakietu, zanim uruchomi się na komputerze, jest skuteczniejsze niż wykrywanie problemu po fakcie, a zrobienie tego w jednym punkcie pozwala nie polegać na dyscyplinie każdego programisty czy każdego agenta. Fakt, że GitHub zaczyna właśnie od agentów działających bez nadzoru, uważamy za uczciwe spojrzenie na problem.
Mamy dwie wątpliwości. Pierwsza jest komercyjna. Tak użyteczne zabezpieczenie, dostępne na razie w planie Enterprise i płatne według zużycia po wersji testowej, może zostawić bez ochrony małe zespoły, które są często najbardziej narażone. Druga jest techniczna. Wiele kontroli opiera się na bazie danych GitHub i na upływie czasu, a czas nie jest gwarancją, co sama Socket przyznaje.
Dlatego nie traktujemy tego jako ostatecznej tarczy. To dodatkowa warstwa, przydatna, jeśli towarzyszy jej przegląd zależności, blokowanie wersji i minimalne uprawnienia dla agentów. Jeśli myślisz, że wystarczy włączyć firewall, dajesz sobie fałszywe poczucie bezpieczeństwa.
Najczęstsze pytania
Czy package firewall GitHub jest bezpłatny?
Tak, ale tylko w czasie wersji testowej. GitHub zapowiada, że po dostępności ogólnej będzie pobierana opłata według zmierzonego zużycia, podobnie jak w Actions. Ceny nie zostały jeszcze podane.
Czy działa tylko z npm?
Tak, na razie obsługuje wyłącznie pakiety npm. Źródła nie podają terminów dla innych ekosystemów. Jeśli używasz innych języków, na razie musisz szukać innych zabezpieczeń.
Kto może z niego korzystać?
Wszyscy klienci GitHub Enterprise Cloud, także w wariancie z rezydencją danych. Źródła nie wspominają o innych planach. Administratorzy konfigurują reguły dla całego enterprise.
Co się stanie, jeśli zablokuje prawidłowy pakiet?
Użytkownik może poprosić o wyjątek. Według The Hacker News wniosek mogą zatwierdzić administratorzy i osoby odpowiedzialne za bezpieczeństwo. Proces, jak podaje GitHub, jest podobny do tego w innych funkcjach Advanced Security.
Czy okres oczekiwania wystarczy, by zatrzymać malware?
Nie. Pomaga zyskać czas wobec świeżo opublikowanych wersji, ale Socket przypomina, że złośliwy kod nie staje się nieszkodliwy z upływem czasu. Niewykryte wydanie może przetrwać okres oczekiwania.
Na co zwracać uwagę do dostępności ogólnej
W najbliższych miesiącach warto obserwować trzy kwestie. Cenę za zużycie, którą ustali GitHub, ewentualne rozszerzenie poza npm oraz wprowadzenie minimalnego okresu oczekiwania w Rust 1.100, zaplanowanego na 12 listopada 2026 roku. Już teraz możesz działać w następujący sposób.
- Zestaw zależności używane przez CI i agentów oraz zdecyduj, kto może instalować co bez nadzoru.
- Rozważ okres oczekiwania dla nowych wersji, pamiętając, że opóźnia on także uzasadnione poprawki.
- Przygotuj procedurę wyjątków, w której odpowiedzialna osoba zatwierdza wnioski szybko, ale z pisemnym śladem.
