Czy jesteśmy gotowi na kod generowany przez sztuczną inteligencję?

W ostatnich miesiącach zachwycaliśmy się jakością generowanych komputerowo twarzy, zdjęć kotów, filmów, esejów, a nawet dzieł sztuki. Sztuczna inteligencja (AI) i uczenie maszynowe (ML) również po cichu wkradły się do rozwoju oprogramowania dzięki narzędziom takim jak GitHub Copilot, Tabnine, Polycode, i inni podjęcie logicznego kolejnego kroku polegającego na umieszczeniu istniejącej funkcji autouzupełniania kodu na sterydach AI. Jednak w przeciwieństwie do zdjęć kotów pochodzenie, jakość i bezpieczeństwo kodu aplikacji mogą mieć daleko idące konsekwencje — a przynajmniej w przypadku bezpieczeństwa badania pokazują, że ryzyko jest realne.

Wcześniejszy badania naukowe pokazał już, że GitHub Copilot często generuje kod zawierający luki w zabezpieczeniach. Wykazała to niedawno praktyczna analiza przeprowadzona przez inżyniera bezpieczeństwa Invicti, Kadira Arslana sugestie dotyczące niebezpiecznego kodu w przypadku Copilot nadal stanowią raczej regułę niż wyjątek. Arslan odkrył, że sugestie dotyczące wielu typowych zadań obejmowały jedynie najprostsze rozwiązania, często obierając najbardziej podstawową i najmniej bezpieczną drogę, oraz że przyjęcie ich bez modyfikacji może skutkować powstaniem funkcjonalnych, ale podatnych na zagrożenia aplikacji.

Narzędzie takie jak Copilot ma (z założenia) autouzupełnianie na najwyższym poziomie i jest przeszkolone w zakresie kodu open source w celu sugerowania fragmentów, które mogą być istotne w podobnym kontekście. To sprawia, że ​​jakość i bezpieczeństwo sugestii jest ściśle powiązane z jakością i bezpieczeństwem zbioru uczącego. Zatem większe pytania nie dotyczą Copilota ani żadnego innego konkretnego narzędzia, ale ogólnie kodu oprogramowania generowanego przez sztuczną inteligencję.

Rozsądnie jest założyć, że Copilot to dopiero wierzchołek włóczni i że podobne generatory staną się powszechne w nadchodzących latach. Oznacza to, że my, branża technologiczna, musimy zacząć zadawać sobie pytanie, w jaki sposób generowany jest taki kod, w jaki sposób jest on używany i kto weźmie odpowiedzialność, gdy coś pójdzie nie tak.

Syndrom nawigacji satelitarnej

Tradycyjne autouzupełnianie kodu, które wyszukuje definicje funkcji w celu uzupełnienia nazw funkcji i przypomina o potrzebnych argumentach, pozwala na ogromną oszczędność czasu. Ponieważ te sugestie są jedynie skrótem do samodzielnego wyszukiwania dokumentów, nauczyliśmy się pośrednio ufać wszystkiemu, co sugeruje IDE. Gdy pojawi się narzędzie oparte na sztucznej inteligencji, nie ma już gwarancji, że jego sugestie będą prawidłowe, ale nadal będą przyjazne i godne zaufania, więc istnieje większe prawdopodobieństwo, że zostaną zaakceptowane.

Szczególnie w przypadku mniej doświadczonych programistów wygoda otrzymania darmowego bloku kodu zachęca do zmiany sposobu myślenia z „Czy ten kod jest wystarczająco zbliżony do tego, co bym napisał” na „Jak mogę ulepszyć ten kod, aby działał dla mnie”.

GitHub bardzo wyraźnie stwierdza, że ​​sugestie Copilota należy zawsze dokładnie analizować, przeglądać i testować, ale natura ludzka dyktuje, że nawet kiepski kod czasami trafi do produkcji. To trochę jak prowadzenie samochodu, patrząc bardziej na GPS niż na drogę.

Kwestie bezpieczeństwa łańcucha dostaw

Połączenia Kryzys bezpieczeństwa Log4j w ostatnim czasie postawiło w centrum uwagi bezpieczeństwo łańcucha dostaw oprogramowania, a w szczególności bezpieczeństwo oprogramowania open source Notatka Białego Domu w sprawie bezpiecznego tworzenia oprogramowania i nowego projekt ustawy o poprawie bezpieczeństwa open source. Dzięki tym i innym inicjatywom posiadanie w aplikacjach dowolnego kodu open source może wkrótce zaistnieć konieczność zapisania go w zestawieniu komponentów oprogramowania (SBOM), co jest możliwe tylko wtedy, gdy świadomie uwzględni się określoną zależność. Narzędzia do analizy składu oprogramowania (SCA) również wykorzystują tę wiedzę do wykrywania i oznaczania nieaktualnych lub podatnych na ataki komponentów open source.

Ale co, jeśli Twoja aplikacja zawiera kod wygenerowany przez sztuczną inteligencję, który ostatecznie pochodzi z zestawu szkoleniowego open source? Teoretycznie, jeśli choć jedna istotna sugestia jest identyczna z istniejącym kodem i zaakceptowana w niezmienionej postaci, możesz mieć otwarty kod źródłowy w swoim oprogramowaniu, ale nie w swoim SBOM. Może to prowadzić do problemów ze zgodnością, nie wspominając o potencjalnej odpowiedzialności, jeśli kod okaże się niepewny i doprowadzi do naruszenia — a SCA Ci nie pomoże, ponieważ może znaleźć tylko podatne na ataki zależności, a nie luki w Twoim własnym kodzie .

Pułapki związane z licencjonowaniem i przypisaniem

Kontynuując ten tok myślenia, aby móc korzystać z kodu open source, należy przestrzegać warunków licencji. W zależności od konkretnej licencji typu open source będziesz musiał przynajmniej podać źródło lub czasami udostępnić własny kod jako open source. Niektóre licencje całkowicie zabraniają wykorzystania komercyjnego. Niezależnie od licencji, musisz wiedzieć, skąd pochodzi kod i jak jest licencjonowany.

Powtórzę jeszcze raz: co się stanie, jeśli w aplikacji znajduje się kod wygenerowany przez sztuczną inteligencję, który jest identyczny z istniejącym kodem open source? Czy w przypadku przeprowadzenia audytu okazałoby się, że używasz kodu bez wymaganego przypisania? A może potrzebujesz otworzyć część swojego komercyjnego kodu, aby zachować zgodność? Być może nie jest to jeszcze realistyczne ryzyko przy obecnych narzędziach, ale tego rodzaju pytania powinniśmy wszyscy zadawać dzisiaj, a nie za 10 lat. (I żeby było jasne, GitHub Copilot ma opcjonalny filtr blokujący sugestie pasujące do istniejącego kodu, aby zminimalizować ryzyko w łańcuchu dostaw).

Głębsze implikacje dla bezpieczeństwa

Wracając do bezpieczeństwa, model AI/ML jest tak dobry (i tak zły), jak jego zestaw szkoleniowy. Widzieliśmy to w przeszłości - na przykład w przypadkach algorytmy rozpoznawania twarzy pokazujące uprzedzenia rasowe ze względu na dane, na których zostali przeszkoleni. Jeśli więc mamy badania pokazujące, że generator kodu często generuje sugestie bez względu na bezpieczeństwo, możemy wywnioskować, że tak właśnie wyglądał jego zestaw uczenia się (tj. publicznie dostępny kod). A co, jeśli niezabezpieczony kod wygenerowany przez sztuczną inteligencję zostanie następnie przekazany z powrotem do tej bazy kodu? Czy sugestie mogą być kiedykolwiek bezpieczne?

Na tym pytania zabezpieczające się nie kończą. Jeśli generatory kodu oparte na sztucznej inteligencji zyskają na popularności i zaczną tworzyć znaczną część nowego kodu, prawdopodobnie ktoś spróbuje je zaatakować. Można już oszukać system rozpoznawania obrazów AI, zatruwając jego zestaw uczący. Wcześniej czy później szkodliwi aktorzy spróbują umieścić wyjątkowo podatny na ataki kod w publicznych repozytoriach w nadziei, że pojawi się on w sugestiach i ostatecznie trafi do aplikacji produkcyjnej, narażając ją na łatwy atak.

A co z monokulturą? Jeśli wiele aplikacji będzie korzystało z tej samej wysoce podatnej na ataki sugestii, niezależnie od jej pochodzenia, możemy mieć do czynienia z epidemią podatności, a może nawet lukami specyficznymi dla sztucznej inteligencji.

Miej oko na sztuczną inteligencję

Niektóre z tych scenariuszy mogą dziś wydawać się naciągane, ale wszystkie one musimy omówić w branży technologicznej. Ponownie GitHub Copilot znajduje się w centrum uwagi tylko dlatego, że obecnie jest liderem, a GitHub zapewnia jasne ostrzeżenia dotyczące zastrzeżeń związanych z sugestiami generowanymi przez sztuczną inteligencję. Podobnie jak w przypadku autouzupełniania w telefonie lub sugestii tras w nawigacji satelitarnej, są to jedynie wskazówki, które ułatwiają nam życie i od nas zależy, czy je przyjmiemy, czy nie.

Dzięki potencjałowi wykładniczego zwiększania wydajności programowania generatory kodu oparte na sztucznej inteligencji prawdopodobnie staną się trwałą częścią świata oprogramowania. Jednak pod względem bezpieczeństwa aplikacji jest to kolejne źródło potencjalnie podatnego na ataki kodu, który musi przejść rygorystyczne testy bezpieczeństwa, zanim zostanie dopuszczony do produkcji. Badamy zupełnie nowy sposób na umieszczanie luk w zabezpieczeniach (i potencjalnie niesprawdzonych zależności) bezpośrednio w kodzie własnym, dlatego sensowne jest traktowanie baz kodu wspomaganych przez sztuczną inteligencję jako niezaufanych do czasu przetestowania — a to oznacza testowanie wszystkiego tak często, jak to możliwe Móc.

Nawet stosunkowo przejrzyste rozwiązania uczenia maszynowego, takie jak Copilot, już budzą pewne wątpliwości prawne i etyczne, nie wspominając o obawach związanych z bezpieczeństwem. Ale wyobraź sobie, że pewnego dnia jakieś nowe narzędzie zacznie generować kod, który działa doskonale i przechodzi testy bezpieczeństwa, z wyjątkiem jednego drobnego szczegółu: nikt nie wie, jak to działa. To wtedy czas na panikę.