Oprogramowanie open source stało się fundamentem współczesnego rozwoju oprogramowania. Niemal każda aplikacja opiera się dziś na złożonej sieci zewnętrznych bibliotek, frameworków, modeli i narzędzi do kompilacji. Sama ta rzeczywistość wprowadza już znaczące zmiany. software supply chain security wyzwania. W tym samym czasie sztuczna inteligencja weszła cykl życia oprogramowania jako potężny akcelerator generujący kod, sugerujący zależności, automatyzujący poprawki, a nawet wpływający na architekturęcisJony. Open source i sztuczna inteligencja razem zrewolucjonizowały sposób tworzenia oprogramowania i, nieuchronnie, sposób, w jaki jest ono atakowane. Połączenie bezpieczeństwa sztucznej inteligencji, bezpieczeństwa sztucznej inteligencji i oprogramowania oraz software supply chain security Nie jest już teorią. Jest to obecnie jedno z głównych źródeł ryzyka w łańcuchu dostaw oprogramowania, z jakim borykają się organizacje inżynierskie.
Ta rzeczywistość ukształtowała naszą ostatnią rozmowę o SafeDev: Oprogramowanie Open Source, sztuczna inteligencja i nowa powierzchnia ataku: uzbrojony kod, inteligentniejsze mechanizmy obronnez udziałem liderów ds. bezpieczeństwa z Red Hat, TikTok i Xygeni. Dyskusja koncentrowała się na tym, z czym zespoły ds. bezpieczeństwa i inżynierii już borykają się w środowiskach produkcyjnych, szczególnie w kontekście ataków na łańcuchy dostaw open source, złośliwych pakietów open source oraz rosnącego napięcia między szybkością a kontrolą w rozwoju oprogramowania opartego na sztucznej inteligencji. Wyłonił się wyraźny obraz: powierzchnia ataku rozszerza się szybciej, niż mogą nadążyć za nią tradycyjne modele bezpieczeństwa, a sztuczna inteligencja działa zarówno jako mnożnik siły, jak i test wytrzymałościowy dla długoletnich założeń dotyczących bezpieczeństwa sztucznej inteligencji. software supply chain security.
Jeśli ten opis wydaje się niepokojąco bliski temu, jak obecnie tworzy się oprogramowanie w Twojej organizacji, to nie przypadek. Wiele zespołów zdaje sobie sprawę, jak bardzo zaufanie przesunęło się w stronę automatyzacji dopiero po tym, jak coś się zepsuje.
Bezpieczeństwo AI i Software Supply Chain Security Teraz mamy ten sam problem
Powracającym tematem dyskusji było to, że bezpieczeństwa sztucznej inteligencji nie można już traktować jako odrębnej dyscypliny software supply chain securitySystemy AI nie działają w izolacji; są budowane, szkolone, wdrażane i integrowane za pośrednictwem tej samej pipelinezależności i rejestry, które już teraz zmagają się z atakami na łańcuchy dostaw typu open source.
W rozwoju oprogramowania opartego na sztucznej inteligencji modele automatycznie sugerują kod, generują poprawki i wybierają zależności.cisjony bezpośrednio wpływają zarządzanie zależnościami typu open source, często bez wyraźnego zamiaru człowieka. W rezultacie ryzyko zależności nie jest już uzależnione wyłącznie od decyzji programisty, ale w coraz większym stopniu kształtowane przez zachowanie sztucznej inteligencji.
Ta konwergencja oznacza, że awarie zabezpieczeń sztucznej inteligencji i oprogramowania często objawiają się w postaci tradycyjnych incydentów w łańcuchu dostaw: naruszonych zależności, zanieczyszczonych artefaktów kompilacji lub podatnych na ataki CI/CD Procesy. Narzędzia mogą być nowe, ale ryzyko w łańcuchu dostaw oprogramowania jest bardzo realne i coraz trudniej je racjonalnie ocenić.
Jeśli Twoje modele zagrożeń nadal oddzielają „ryzyko związane ze sztuczną inteligencją” od „ryzyka związanego z łańcuchem dostaw”, warto ponownie przeanalizować, gdzie faktycznie przebiega ta granica w Twoich procesach kompilacji i wdrażania.
Ataki na łańcuchy dostaw Open Source z prędkością maszynową
Ataki na łańcuchy dostaw open source nie są nowością, ale sztuczna inteligencja zmienia ich ekonomię. Atakujący nie potrzebują nowych technik, lecz skali. Sztuczna inteligencja umożliwia szybką analizę ekosystemu, automatyczne wykrywanie słabych zależności i szybką iterację ładunków ataku.
Z ofensywnego punktu widzenia, industrializacja rozpoznania drastycznie zwiększa skuteczność ataków wykorzystujących złośliwe pakiety open source. Komponenty, które wcześniej pozostałyby niezauważone, teraz mogą zostać szybko odkryte, przeanalizowane i wykorzystane, często zanim obrońcy zorientują się, że są w użyciu.
Dlatego właśnie software supply chain security Nie można polegać wyłącznie na opóźnionych sygnałach. Rejestry, ostrzeżenia i powiadomienia post facto działają w ludzkich skalach czasowych, podczas gdy atakujący coraz częściej działają z prędkością maszyn. Wynikające z tego okno ekspozycji jest bezpośrednim czynnikiem wzrostu ryzyka w łańcuchu dostaw oprogramowania.
Jeśli głównym sygnałem wykrycia jest „rejestr usunął pakiet”, działasz już zgodnie z osią czasu atakującego.
Chcesz poznać dogłębnie temat ataków na łańcuch dostaw oprogramowania typu open source?
Ryzyko zależności w rozwoju oprogramowania opartego na sztucznej inteligencji
Jednym z najwyraźniejszych zagrożeń omówionych podczas SafeDev Talk było ryzyko zależności, szczególnie w środowiskach, które w dużym stopniu opierają się na tworzeniu oprogramowania opartego na sztucznej inteligencji. Asystenci kodowania AI są zoptymalizowani pod kątem wygody i szybkości, a nie minimalizacji powierzchni ataku.
W praktyce prowadzi to do agresywnego wprowadzania zależności. Zamiast ponownego wykorzystywania istniejących funkcjonalności, dodawane są nowe biblioteki. zależności przechodnie rozszerzaj się po cichu i otwieraj kod źródłowy zarządzanie zależnościami staje się reaktywny, a nie celowy. Z czasem zespoły tracą zdolność wnioskowania o tym, co tak naprawdę robią.
To nie tylko kwestia higieny. Każda nowa zależność wprowadza dodatkowe ryzyko w łańcuchu dostaw oprogramowania, nowe założenia dotyczące zaufania i nowe możliwości ataków na łańcuch dostaw open source. Kiedy zależność…cisGdy jony są zautomatyzowane i przeglądane powierzchownie, ryzyko zależności staje się systemowe, a nie przypadkowe.
Jeśli wykres zależności rośnie szybciej, niż umiejętności zespołu w zakresie jego wyjaśnienia, nie jest to problem związany z narzędziami, lecz z zaufaniem.
Asystenci kodowania AI, bezpieczeństwo i załamanie się recenzji
Innym omawianym trybem awarii była erozja recenzji eksperckich w obecności kodu generowanego przez sztuczną inteligencję. W przypadku asystentów kodowania AI, bezpieczeństwo nie polega tylko na szybkim wstrzykiwaniu kodu lub niewłaściwym użyciu modelu; chodzi o ilość niesprawdzonej logiki trafiającej do systemów produkcyjnych.
Zmiany generowane przez sztuczną inteligencję są często duże, spójne i trudne do weryfikacji pod presją czasu. W rezultacie recenzja ekspercka staje się płytka lub symboliczna. To ciche załamanie eliminuje jedną z najskuteczniejszych kontroli w software supply chain security.
Problemem nie jest zaniedbanie programisty. Problemem jest brak spójności przepływu pracy. Gdy szybkość jest nagradzana, a tarcie karane, mechanizmy bezpieczeństwa sztucznej inteligencji i oprogramowania, które zależą od ludzkiej uwagi, nieuchronnie słabną. Atakujący nie muszą pomijać weryfikacji, jeśli ta nie stanowi już bariery.
Wiele zespołów zakłada, że przegląd nadal działa, ponieważ proces istnieje. Mniej osób zastanawia się, czy nadal pełni on funkcję sensownej kontroli.
Złośliwe pakiety Open Source i mit popularności
W zarządzaniu zależnościami w oprogramowaniu open source powszechnie uważa się, że popularne projekty są bezpieczniejsze. W rzeczywistości popularność często zwiększa narażenie. Szeroko używane biblioteki są cennymi celami dla… ataki na łańcuchy dostaw typu open source, dlaciswyłącznie dlatego, że kompromis ma szeroki wpływ na dalsze losy sprawy.
Wiele popularnych projektów jest utrzymywanych przez małe zespoły lub pojedyncze osoby. Nawet po wykryciu problemów, złośliwe pakiety open source często pozostają dostępne przez wiele godzin lub dni, zanim zostaną usunięte. W tym czasie organizacje nadal je wdrażają za pomocą zautomatyzowanych kompilacji.
To opóźnienie wzmacnia potrzebę proaktywnego działania software supply chain security Kontrola. Poleganie wyłącznie na popularności, reputacji lub działaniach w rejestrze jest niewystarczające w obliczu ryzyka związanego z nowoczesnym łańcuchem dostaw oprogramowania.
„Szeroko stosowane” nie jest tym samym, co „aktywnie bronione” i traktowanie tego w ten sposób jest jednym z najbardziej uporczywych nieporozumień w łańcuchu dostaw.
Pochodzenie w łańcuchach dostaw oprogramowania i bezpieczeństwie sztucznej inteligencji
W trakcie dyskusji wielokrotnie pojawiała się potrzeba identyfikacji pochodzenia w łańcuchach dostaw oprogramowania. W środowiskach wspomaganych przez sztuczną inteligencję atrybucja staje się niewyraźna. Kod może być generowany przez model, modyfikowany przez człowieka, scalany przez automatyzację i wdrażany bez jasnego rozliczenia.
Bez weryfikowalnego pochodzenia organizacje są zmuszone do bezwarunkowego zaufania do artefaktów. Bezpieczeństwo sztucznej inteligencji wymaga odejścia od zaufania na rzecz weryfikacji: podpisane artefakty, build attestationsi możliwe do prześledzenia pochodzenie. Chociaż pochodzenie nie zapobiega całkowicie złośliwym zachowaniom, znacznie zmniejsza niejednoznaczność i ogranicza możliwości manewru atakującego.
Dotyczy to w równym stopniu modeli, danych i kodu. W rozwoju oprogramowania opartego na sztucznej inteligencji pochodzenie jest podstawowym wymogiem zarówno dla bezpieczeństwa sztucznej inteligencji, jak i oprogramowania.
SBOM i bezpieczeństwo sztucznej inteligencji w nowoczesnym Pipelines
Rola SBOM a bezpieczeństwo sztucznej inteligencji było kolejnym istotnym tematem. SBOMzapewniają widoczność wykresów zależności, ale sama widoczność nie wystarczy. W środowiskach silnie opartych na sztucznej inteligencji, SBOMs musi ewoluować, aby przechwytywać nie tylko biblioteki, ale także modele, kroki kompilacji i zautomatyzowane decisJony.
W połączeniu z analiza zachowania i pochodzenie, SBOM Bezpieczeństwo sztucznej inteligencji (AI) staje się potężnym narzędziem ograniczającym ryzyko w łańcuchu dostaw oprogramowania. Pozwala organizacjom wykrywać nieoczekiwane zmiany, oceniać ich wpływ i skuteczniej reagować na ataki na łańcuchy dostaw oprogramowania open source.
CI/CD Pipeline Security Pod presją automatyzacji
Wreszcie, CI/CD pipeline security wyłonił się jako krytyczny obszar kontroli. Pipelinecoraz częściej wykonują działania sugerowane lub wyzwalane przez systemy sztucznej inteligencji. Jeśli te pipelineBrakuje silnych mechanizmów kontroli tożsamości, weryfikacji artefaktów i egzekwowania zasad, przez co stają się idealnymi punktami wejścia dla atakujących.
Niewystarczający CI/CD pipeline security umożliwia złośliwym pakietom open source wpływanie nie tylko na systemy produkcyjne, ale także na środowiska programistyczne i infrastrukturę kompilacji. Wraz ze wzrostem automatyzacji pipelinenależy traktować jako aktywa o dużej wartości software supply chain security programy.
Obejrzyj prezentację SafeDev
Aby dowiedzieć się więcej o tych wszystkich spostrzeżeniach bezpośrednio od praktyków kształtujących tę dziedzinę, obejrzyj cały film Dyskusja na temat SafeDev: Oprogramowanie Open Source, sztuczna inteligencja i nowa powierzchnia ataku: uzbrojony kod, inteligentniejsze mechanizmy obronne, Wyposażony Roman Żukow (Czerwony Kapelusz), Leon Johnson (TikTok), Luis Rodríguez Berzosa (Xygeni).
Praktyczne implikacje dla bezpieczeństwa sztucznej inteligencji i Software Supply Chain Security
Praktyczne implikacje tych zmian wykraczają poza narzędzia. Organizacje muszą zdać sobie sprawę, że bezpieczeństwo sztucznej inteligencji, bezpieczeństwo sztucznej inteligencji i oprogramowania oraz software supply chain security są teraz głęboko ze sobą powiązane. DecisJony, które kiedyś uważano za mało ryzykowne, aktualizacje zależności, generowanie kodu i automatyzacja obecnie niosą ze sobą znaczące ryzyko łańcucha dostaw oprogramowania, zwłaszcza gdy tecisJony powstają w sposób niejawny za pomocą narzędzi, a nie jawnie przez ludzi.
Podczas wystąpienia SafeDev ten punkt został zwięźle podsumowany. Jak ujął to jeden z prelegentów: gdy systemy AI uczestniczą w rozwoju oprogramowania, zespoły ds. bezpieczeństwa nie tylko zabezpieczają kod, ale także zabezpieczającisjonów. Automatyzacja nie usuwa odpowiedzialności, lecz ją redystrybuuje.
W praktyce oznacza to przywrócenie intencjonalności tam, gdzie górę wzięła wygoda. Zarządzanie zależnościami w oprogramowaniu open source musi uwzględniać zachowania sterowane przez sztuczną inteligencję, a nie zakładać ludzkiej rozwagi. Ryzyko zależności nie może być już traktowane jako okazjonalne ćwiczenie w zakresie kontroli.cise. CI/CD pipeline security Należy egzekwować weryfikację, a nie zakładać nieszkodliwe dane wejściowe. Pochodzenie w łańcuchach dostaw oprogramowania musi przejść od aspiracji do poziomu bazowego.
Kolejnym wnioskiem z dyskusji było to, że sama prędkość nie jest już neutralna. Większość awarii w łańcuchach dostaw nie wynika z pojedynczej, katastrofalnej awarii.cisjon, ale z wielu małych, zautomatyzowanych wyborów, których nikt wyraźnie nie zatwierdził. To jest precisDlaczego tradycyjne modele zaufania zawodzą w przypadku rozwoju oprogramowania opartego na sztucznej inteligencji.
Nie oznacza to jednak porzucenia rozwiązań open source ani sztucznej inteligencji. Wręcz przeciwnie, uznaje się ich kluczową rolę we współczesnej inżynierii. Jednak bez ewolucyjnych założeń dotyczących bezpieczeństwa organizacje ryzykują, że automatyzacja z definicji zdefiniuje zaufanie.
Podsumowując…
Przydatnym sposobem myślenia o tej zmianie jest to, że software supply chain security Nie chodzi już tylko o ochronę artefaktów. Chodzi o ochronę decisścieżki jonoweW świecie wspomaganym przez sztuczną inteligencję najważniejsze pytania dotyczące bezpieczeństwa brzmią nie tylko: „Czy ten komponent jest podatny na ataki?”, ale także: „Dlaczego został wprowadzony, przez kogo lub co i z jakimi ograniczeniami?”. Organizacje, które dostosują się do tego podejścia, nie wyeliminują ryzyka, ale będą nim znacznie mniej zaskoczone.
