Open Source i AI okiem Red Hata (WYWIAD)

Kamil Dudek, dobreprogramy: Jak Red Hat radzi sobie z potencjalnym "zalewem" nowego kodu generowanego przez sztuczną inteligencję w świecie open source? Względem niego często pojawiają się podejrzenia, że stanowi on "AI slop". Od pewnego czasu np. Linus Torvalds wspomina, że objętość nowych wydań kernela rośnie, podobnie jak liczba zgłoszonych błędów. Powstają zatem pytania, czy jakikolwiek opiekun projektu lub właściciel produktu jest w stanie rzetelnie ogarnąć taki ruch.

Wojciech Furmankiewicz, dyrektor Red Hat ds. technologii i rozwiązań w regionie Europy Środkowo-Wschodniej: Jesteśmy świadomi tej zmiany, bo naszą rolą od 33 lat jest pomoc naszym klientom enterprise i oferowanie im rozwiązań open source, ale w wydaniu bardziej bezpiecznym i wspieranym. Przez te lata wypracowaliśmy sprawdzony mechanizm backportowania, testowania i wprowadzania poprawek usuwających podatności. To zawsze był jeden z głównych wyróżników Red Hata, bo nasz klient nie będzie aktualizował systemów co sześć miesięcy – potrzebuje dłuższego wsparcia. Nasze poprawki zapewniają, w ramach wsparcia, zgodność API i ABI. Umiemy to robić bardzo dobrze. Istotnie, mamy teraz więcej pracy, ale mechanizm pozostaje ten sam. Więcej pracy wymagają nie tylko nasze produkty, ale wszystkie elementy open source.

KD: Jeżeli proces integracji poprawek dalej jest taki sam, czy nie ma więcej pracy przy "wycenie" podatności i długości wsparcia? Wiele CVE z NVD ma swoje odpowiedniki w glosariuszu Red Hat, gdzie są poddawane powtórnemu szacowaniu. Pozwalają one w dość medialny sposób pokazać, jak znane podatności stanowią mniejsze zagrożenie w poszczególnych produktach. Co więcej, patrząc na Red Hat Lifecycle, można zaobserwować, że wsparcie dla niektórych produktów, mimo wzrostu pracy, jest wręcz wydłużane.

WF: Sztuczna inteligencja działa w dwie strony. Rosnącą liczbę znajdowanych przez nią podatności da się badać, szacować i naprawiać także za pomocą AI. Stosujemy zautomatyzowane skanery. Pojawiły się nowe możliwości integrowania poprawek, szybszego reagowania. Pozwala to wydłużać wsparcie i wręcz oferować opcje rozszerzonego wsparcia. Ale w produktach rozwijających się dynamicznie, jak Red Hat OpenShift, ciągłe wprowadzanie innowacji ma pierwszeństwo przed wieloletnim, statycznym wsparciem. Funkcjonalność produktu po prostu zbyt szybko się starzeje, a klient robiłby sobie krzywdę, utrzymując taki dług technologiczny.

KD: Kernel Linuksa zaczyna rozwiązywać problemy z bezpieczeństwem kodu poprzez usuwanie tych sekcji, które nie są utrzymywane. W rezultacie kończy się to usuwaniem wielu starych sterowników. Czy nie przyspieszy to przymusowego zakończenia wsparcia?

WF: Koncentrując się na klientach enterprise, trzeba brać pod uwagę cykl życia ich bazy sprzętowej. Jeżeli kończy się wsparcie dla dwudziestoletniego sprzętu, wpływ będzie ograniczony. Zresztą musi się to kiedyś stać. Red Hat utrzymuje, swoją drogą, ogromną bazę sprzętową, obejmującą zarówno starsze, jak i nowe urządzenia. Współpracujemy np. z firmą NVIDIA, żeby zapewniać obsługę jej nowego sprzętu już w momencie premiery.

KD: Zajmijmy się kwestią ataków na infrastrukturę, które wraz z podatnościami AI są "modnymi" dzisiaj trendami w bezpieczeństwie. Red Hat promuje koncepcję bezpiecznych repozytoriów artefaktów. Jakie dokładnie jest podejście do zapewniania i utrzymania takich repozytoriów? Co się dzieje, gdy następuje atak i powstaje nowa "przejęta" wersja mało znanej, ale powszechnie używanej zależności bibliotecznej?

WF: Ustalmy na początku, że nie ma czegoś takiego jak uniwersalnie bezpieczne repozytorium. Możemy się jedynie zbliżać do stanu absolutnego "zero CVE" i posiadania wszystkich najnowszych poprawek. Działamy tu na kilku płaszczyznach. Pierwszą z nich jest Projekt Hummingbird. To wstępnie zabezpieczone obrazy kontenerowe, przebudowywane pod kątem osiągnięcia całkowitego braku znanych podatności. Nasz zespół Product Security Team pracuje w trybie 24/7, a niedawno wprowadziliśmy usługę o nazwie Lightwell. Wykracza ona poza nasze produkty. Jeżeli klienci pokażą nam, czego używają, przekazując na ten temat zanonimizowane dane, oferujemy backporting poprawek do tych konkretnych wersji. Patrzę na to dość optymistycznie. W pewnym momencie pula obecnego rodzaju luk po prostu się wyczerpie. Wiele z nich to historyczne zaszłości, a nowy proces wytwórczy oprogramowania jest lepszy.

KD: Czy taka usługa nie jest de facto usługą przenoszenia odpowiedzialności? Możliwe, że jakiś menedżer uzna, że nie warto inwestować w bezpieczne projektowanie zależności, skoro zewnętrzna firma "zajmuje się zabezpieczeniami łańcucha dostaw"?

WF: Tu bardziej chodzi o świadomość niż o przenoszenie odpowiedzialności. Świadomy klient jest w stanie użyć naszych narzędzi do tego, by zbudować łańcuch dostaw o podwyższonym poziomie bezpieczeństwa. Wartość Lightwell nie wynika z samego łatania, ale także z tego, że podatności objęte embargiem informacyjnym także są łatane i klient ma czas zaktualizować podatne biblioteki, zanim świat dowie się o istnieniu tych podatności. To nieoceniona wartość i duży wyróżnik dla organizacji i np. banków, z którymi współpracujemy.

KD: Czy zanosi się na wzrost popularności takich usług w świetle odkrywanych przez AI podatności oraz nadchodzących regulacji prawnych, jak EU CRA?

WF: Regulacja to jedna sprawa, ale drugą kwestią jest suwerenność techniczna. Firmy, ale też państwa, nie chcą sobie z problemami bezpieczeństwa radzić w pojedynkę.

KD: Internet w dobie AI to także masowe wdrożenia botów, o różnym przeznaczeniu, w tym takich marketingowych i opiniotwórczych, udających ludzi i napędzających spiskową teorię "pustego internetu". Czy Red Hat zaobserwował takie masowe budowanie kampanii botów w oparciu o swoje produkty i usługi?

WF: Myślę, że dostępność nowoczesnych technologii automatyzacji to dobra rzecz. Inną kwestią jest to, jak są wykorzystywane. To prawda, że duża część dzisiejszego ruchu sieciowego to boty rozmawiające z botami. Widać to na konferencjach branżowych i wśród nowoczesnych start-upów. Trudno powiedzieć, czy da się coś z tym zrobić. Trzeba się na to uodpornić. W branży enterprise, w której działamy, zjawisko to jest jednak mniejsze. Widać tutaj przede wszystkim korzyść w obniżaniu kosztów operacyjnych.