Benchmark dla AI i bezpieczeństwo kodu. Co nowy standard oceny narzędzi zmienia dla instytucji publicznych

Coraz więcej zespołów programistycznych, także w sektorze publicznym, sięga po narzędzia AI do pisania i przeglądania kodu. Problem: przez długi czas nie było dobrego sposobu, żeby sprawdzić, czy takie narzędzia naprawdę potrafią wyłapać błędy bezpieczeństwa, czy tylko sprawiają wrażenie, że to robią. Odpowiedzią jest benchmark skupiony na CWE, czyli skatalogowanym zbiorze typowych słabości w oprogramowaniu, od przepełnień bufora po błędy autoryzacji. Jego druga wersja znacząco poszerza zakres testowanych podatności, poprawia jakość przypadków testowych i udostępnia metodologię w sposób, który pozwala niezależnie zweryfikować wyniki.

Chodzi o to, żeby ocena była uczciwa: model AI dostaje fragment kodu i musi wskazać konkretny problem albo zaproponować poprawkę. Wyniki różnych narzędzi można porównać na jednej skali. Poprzednia wersja obejmowała stosunkowo wąski zestaw kategorii i zdarzały się przypadki, gdzie poprawna odpowiedź była możliwa do odgadnięcia bez głębszego rozumienia kodu. Wersja druga to inna liga.

Co to oznacza dla polskich urzędów i instytucji publicznych

Polskie instytucje publiczne zamawiają lub tworzą oprogramowanie. Rejestry, systemy obsługi obywatela, platformy raportowe, integracje z ePUAP. Przy każdym z tych projektów pojawia się pytanie: czy mamy pewność, że kod jest bezpieczny? AI wchodzi tu coraz częściej jako narzędzie wspomagające programistów albo jako element automatycznego przeglądu kodu przed wdrożeniem. Benchmark taki jak ten pozwala odpowiedzieć, które narzędzia rzeczywiście warto w tym celu używać.

Transparentność metodologii to szczególnie istotna sprawa przy zamówieniach publicznych. Gdy instytucja wybiera narzędzie AI do wspomagania bezpieczeństwa oprogramowania, powinna móc zadać dostawcy konkretne pytanie: jakie wyniki osiąga Wasze narzędzie na CWE-bench? Bez otwartego benchmarku to pytanie nie ma sensu. Teraz ma. To zmienia rozmowę z „zapewniamy wysoką jakość" na „oto liczby, sprawdźcie sami".

• Ocena narzędzi do code review: instytucje korzystające z AI przy przeglądzie kodu mogą wymagać od dostawców wyników na tym benchmarku jako kryterium wyboru.
• Audyt wewnętrzny: zespoły IT mogą przetestować używane narzędzia samodzielnie, bo metodologia jest jawna i odtwarzalna.
• Świadomość ograniczeń: benchmark pokazuje też, gdzie AI sobie nie radzi. Wiedzieć, gdzie nie ufać narzędziu, to połowa bezpieczeństwa.
• Argument w przetargu: wymaganie udokumentowanej skuteczności na standardowym benchmarku to rozsądny zapis w SIWZ dla projektów, gdzie bezpieczeństwo kodu jest priorytetem.

Warto też zauważyć, że lepsza pokrycie kategorii CWE oznacza, że benchmark odzwierciedla rzeczywiste zagrożenia, a nie tylko te, które były łatwe do przetestowania. Instytucje przetwarzające dane osobowe obywateli powinny traktować to jako sygnał: standard oceny AI w obszarze bezpieczeństwa kodu właśnie dojrzał.

Jeśli Wasza instytucja korzysta z AI przy tworzeniu lub przeglądaniu oprogramowania i chcecie wiedzieć, jak to wpisać w politykę bezpieczeństwa, zapraszamy na bezpłatny audyt.