npm skanuje paczki przed publikacją. Także te od AI

GitHub uruchomił 28 lipca automatyczne skanowanie każdej nowej paczki publikowanej w npm, zanim stanie się ona dostępna do instalacji. To zmiana w miejscu, o którego istnieniu większość osób budujących aplikacje z AI nie myśli, a od którego zależy bezpieczeństwo ich projektu. Aplikacja wygenerowana w narzędziu w rodzaju Lovable, Bolta czy v0 ściąga przy pierwszym uruchomieniu setki cudzych paczek z tego właśnie rejestru. Nikt ich nie ogląda, bo nie da się.

Co dokładnie się zmieniło

Do tej pory paczka opublikowana w npm była dostępna natychmiast, a wykrywanie złośliwego kodu działało po fakcie: ktoś zgłaszał, moderacja usuwała, a w międzyczasie paczka zdążyła trafić do tysięcy projektów. Teraz kolejność się odwraca. Każda nowa publikacja przechodzi skan przed udostępnieniem i kończy się na jeden z trzech sposobów:

• publikacja normalna, jeśli skan niczego nie znalazł,
• wstrzymanie do ręcznego przeglądu, jeśli coś wygląda podejrzanie,
• blokada, jeśli znalezisko jest jednoznaczne.

Kosztem jest opóźnienie. GitHub podaje około pięciu minut w typowym przypadku i piętnaście lub więcej w godzinach szczytu albo przy dużych paczkach, z zastrzeżeniem, że to obserwowane zachowanie, a nie zobowiązanie.

Autor zablokowanej paczki dostaje powiadomienie i może się odwołać. Przy poważniejszych przypadkach konsekwencje mogą sięgnąć samego konta. GitHub pisze uczciwie, że blokuje to złośliwe oprogramowanie, które potrafi wykryć, i pracuje nad poprawą skuteczności. To nie jest gwarancja czystości rejestru, tylko podniesienie poprzeczki.

Osobne zasady dostały narzędzia bezpieczeństwa, które z natury wyglądają skanerowi na zagrożenie, bo służą do testowania cudzych zabezpieczeń. Ich autorzy muszą teraz zadeklarować taki charakter paczki i dołączyć wyjaśnienie, do czego ma legalnie służyć.

Dlaczego to Twój problem, nawet jeśli nic nie publikujesz

Kluczowa liczba w tej historii nie pochodzi z komunikatu. To liczba paczek, które ma Twój projekt. Typowa aplikacja webowa wygenerowana przez buildera pociąga za sobą kilkaset zależności pośrednich, czyli paczek, których nikt świadomie nie wybierał. Wystarczy, że jedna z nich zostanie przejęta albo że ktoś opublikuje paczkę o nazwie łudząco podobnej do popularnej, a model przy generowaniu wpisze tę mylącą nazwę do konfiguracji.

Ten drugi scenariusz jest wart osobnej uwagi, bo dotyczy wprost pracy z AI. Model potrafi wymyślić nazwę paczki, która nie istnieje, co jest jedną z odmian halucynacji. Jeśli ktoś złośliwy zawczasu zarejestruje tę nazwę w rejestrze, wygenerowany kod zainstaluje jego paczkę bez mrugnięcia okiem. Skanowanie przy publikacji nie usuwa tego ryzyka w całości, ale zabiera atakującemu najwygodniejszą ścieżkę, czyli natychmiastową dostępność świeżo wgranego pliku.

Warto zauważyć szerszy kierunek. Tydzień wcześniej PyPI, odpowiednik npm dla Pythona, zaczął odrzucać nowe pliki dodawane do wydań starszych niż czternaście dni. Obie zmiany wychodzą z tego samego założenia: skoro kodu powstaje coraz więcej i coraz mniej osób go czyta, zabezpieczenia muszą wejść w moment publikacji, a nie czekać na zgłoszenie.

Czego ta zmiana nie załatwia

Jest tu jedno ograniczenie, o którym warto wiedzieć, zanim poczujesz się bezpiecznie. Skanowanie obejmuje nowe publikacje, a nie to, co leży w rejestrze od lat i siedzi już w Twoim projekcie. Jeśli Twoja aplikacja powstała pół roku temu, żadna z jej bibliotek nie przeszła przez ten filtr.

Drugie ograniczenie wynika z natury takich zabezpieczeń. Skaner wyłapuje wzorce, które zna, a najgroźniejsze ataki na ten rejestr polegały dotąd na czymś innym: ktoś przejmował konto autora popularnej, całkowicie legalnej biblioteki i wypuszczał jej nową wersję ze złośliwym dodatkiem. Paczka ma wtedy prawdziwą historię, tysiące pobrań i zaufaną nazwę. To jest wciąż najtrudniejszy przypadek i zmiana z 28 lipca go nie usuwa, choć daje moderacji kilka minut, których wcześniej nie miała.

Co zrobić dziś

Dla osoby budującej aplikacje z pomocą AI zostają z tego dwie rzeczy do zrobienia i żadna nie wymaga umiejętności programowania. Otwórz swój projekt w narzędziu, w którym go zbudowałeś, i poproś model o listę wszystkich zewnętrznych bibliotek, z których korzysta aplikacja, wraz z jednozdaniowym opisem każdej. Potem zadaj drugie pytanie: czy któraś z nich wygląda podejrzanie albo ma nazwę łudząco podobną do popularniejszej. To pięć minut pracy i wyłapuje dokładnie ten przypadek, w którym w projekcie siedzi coś, czego nikt świadomie nie dodawał.

Druga rzecz jest jeszcze prostsza. Jeśli Twoja aplikacja stoi od miesięcy nietknięta, poproś o aktualizację bibliotek do najnowszych wersji i wypuść aplikację jeszcze raz. Skanowanie chroni przed nowym złośliwym kodem, ale nic nie zrobi z tym, co trafiło do Twojego projektu wcześniej i wciąż w nim siedzi.