Leverans Medan de har bråttom att förstå, bygga och leverera AI-produkter uppmanas utvecklare och datavetare att vara uppmärksamma på säkerheten och inte falla offer för attacker i leveranskedjan.

Det finns otaliga modeller, bibliotek, algoritmer, förbyggda verktyg och paket att leka med, och framstegen är obevekliga. Resultatet av dessa system är kanske en annan historia, även om det är obestridligt att det alltid finns något nytt att leka med, åtminstone.

Strunta i all spänning, hype, nyfikenhet och rädsla för att missa något, säkerhet kan inte glömmas bort. Om detta inte är en chock för dig, fantastiskt. Men en påminnelse är praktisk här, särskilt eftersom maskininlärningsteknik tenderar att sättas ihop av forskare snarare än ingenjörer, åtminstone i utvecklingsfasen, och medan dessa människor känner till saker som neurala nätverksarkitekturer, kvantisering och nästa- gen träningstekniker, infosec kanske inte är deras starka sida.

Att dra ihop ett AI-projekt skiljer sig inte så mycket från att konstruera någon annan mjukvara. Du kommer vanligtvis att limma ihop bibliotek, paket, träningsdata, modeller och anpassad källkod för att utföra slutledningsuppgifter. Kodkomponenter som är tillgängliga från offentliga arkiv kan innehålla dolda bakdörrar eller dataexfiltratorer, och förbyggda modeller och datauppsättningar kan förgiftas för att få appar att bete sig oväntat olämpligt.

Faktum är att vissa modeller kan innehålla skadlig programvara exekveras om deras innehåll inte är säkert deserialiserat. Säkerheten för ChatGPT-plugins har också kom under noggrann granskning.

Med andra ord kan supply chain-attacker vi har sett i mjukvaruutvecklingsvärlden inträffa i AI-land. Dåliga paket kan leda till att utvecklarnas arbetsstationer äventyras, vilket leder till skadliga intrång i företagsnätverk, och manipulerade modeller och utbildningsdatauppsättningar kan få applikationer att felaktigt klassificera saker, förolämpa användare och så vidare. Bibliotek och modeller med bakdörrar eller skadlig programvara kan, om de ingår i levererad programvara, lämna användare av dessa appar öppna för attacker också.

De kommer att lösa ett intressant matematiskt problem och sedan distribuera det och det är allt. Det är inte penna testat, det finns ingen AI red teaming

Som svar på detta dyker startups för cybersäkerhet och AI fram specifikt för att hantera detta hot; utan tvekan har etablerade spelare koll på det också, eller det hoppas vi. Maskininlärningsprojekt bör granskas och inspekteras, säkerhetstestas och säkerhetsutvärderas.

"[AI] har vuxit ur akademin. Det har till stor del varit forskningsprojekt på universitet eller så har de varit små mjukvaruutvecklingsprojekt som till stor del har avknoppats av akademiker eller stora företag, och de har helt enkelt inte säkerheten inuti,” Tom Bonner, forskningschef på HiddenLayer, en sådan säkerhetsfokuserad start, berättade Registret.

"De kommer att lösa ett intressant matematiskt problem med hjälp av programvara och sedan kommer de att distribuera det och det är allt. Den är inte penntestad, det finns ingen AI red teaming, riskbedömningar eller en säker utvecklingslivscykel. Helt plötsligt har AI och maskininlärning verkligen tagit fart och alla vill komma in i det. De går alla och plockar upp alla vanliga mjukvarupaket som har vuxit ur akademin och se och häpna, de är fulla av sårbarheter, fulla av hål.”

AI-försörjningskedjan har många ingångspunkter för brottslingar, som kan använda saker som typskattning att lura utvecklare att använda skadliga kopior av annars legitima bibliotek, så att skurkarna kan stjäla känslig data och företagsuppgifter, kapa servrar som kör koden och mer, hävdas det. Programvaruförsörjningskedjans försvar bör också tillämpas på utveckling av system för maskininlärning.

"Om du tänker på ett cirkeldiagram över hur du kommer att bli hackad när du öppnar en AI-avdelning i ditt företag eller din organisation," sa Dan McInerney, ledande AI-säkerhetsforskare på Protect AI, till Registret, "en liten bråkdel av den kakan kommer att vara modellinmatningsattacker, vilket är vad alla pratar om. Och en gigantisk del kommer att attackera leveranskedjan – verktygen du använder för att bygga själva modellen.”

Ingångsattacker är intressanta sätt som människor kan bryta AI-programvara genom att använda.

För att illustrera den potentiella faran, HiddenLayer härom veckan markerad vad den är övertygad om är ett säkerhetsproblem med en onlinetjänst från Hugging Face som konverterar modeller i det osäkra Pickle-formatet till det säkrare Säkerhetsskåp, även utvecklad av Hugging Face.

Pickle-modeller kan innehålla skadlig kod och annan godtycklig kod som kan köras tyst och oväntat när de deserialiseras, vilket inte är bra. Safetensors skapades som ett säkrare alternativ: Modeller som använder det formatet ska inte köra inbäddad kod när de deserialiseras. För dem som inte vet, Hugging Face är värd för hundratusentals neurala nätverksmodeller, datauppsättningar och kodbitar som utvecklare kan ladda ner och använda med bara några klick eller kommandon.

Safetensors-omvandlaren körs på Hugging Face-infrastrukturen och kan instrueras att konvertera en PyTorch Pickle-modell som värd Hugging Face till en kopia i Safetensors-formatet. Men den onlinekonverteringsprocessen i sig är sårbar för exekvering av godtycklig kod, enligt HiddenLayer.

HiddenLayer-forskare sa att de fann att de kunde skicka in en konverteringsbegäran för en skadlig Pickle-modell som innehåller godtycklig kod, och under omvandlingsprocessen kommer den koden att köras på Hugging Faces system, vilket gör att någon kan börja bråka med omvandlarboten och dess användare. Om en användare konverterade en skadlig modell, kunde deras Hugging Face-token exfiltreras av den dolda koden, och "vi skulle i själva verket kunna stjäla deras Hugging Face-token, äventyra deras arkiv och se alla privata arkiv, datauppsättningar och modeller som den användaren har tillgång till”, hävdade HiddenLayer.

Dessutom får vi veta att omvandlarbotens referenser kan nås och läckas av kod som är gömd i en Pickle-modell, vilket gör att någon kan maskera sig som boten och öppna pull-förfrågningar för ändringar i andra förråd. Dessa ändringar kan introducera skadligt innehåll om de accepteras. Vi har bett Hugging Face om ett svar på HiddenLayers upptäckter.

"Ironiskt nog var konverteringstjänsten för att konvertera till Safetensors i sig fruktansvärt osäker," berättade HiddenLayers Bonner. "Med tanke på den åtkomstnivå som konverteringsboten hade till arkiven, var det faktiskt möjligt att stjäla token de använder för att skicka ändringar genom andra arkiv.

"Så i teorin kunde en angripare ha skickat in vilken ändring som helst i vilket arkiv som helst och fått det att se ut som om det kom från Hugging Face, och en säkerhetsuppdatering kunde ha lurat dem att acceptera det. Folk skulle bara ha haft bakdörrsmodeller eller osäkra modeller i sina repos och skulle inte veta.”

Detta är mer än ett teoretiskt hot: Devops-butiken JFrog sa att det hittats skadlig kod som döljer sig i 100 modeller på Hugging Face.

Det finns i själva verket olika sätt att dölja skadliga nyttolaster av kod i modeller som – beroende på filformatet – exekveras när de neurala nätverken laddas och analyseras, vilket gör att skurkarna kan få tillgång till människors maskiner. PyTorch- och Tensorflow Keras-modeller "utgör den högsta potentiella risken för att exekvera skadlig kod eftersom de är populära modelltyper med kända kodexekveringstekniker som har publicerats", noterade JFrog.

Osäkra rekommendationer

Programmerare som använder kodföreslagande assistenter för att utveckla applikationer måste också vara försiktiga, varnade Bonner, annars kan de sluta med att inkorporera osäker kod. GitHub Copilot, till exempel, tränades på öppen källkodsförråd, och minst 350,000 XNUMX av dem är potentiellt sårbara för en gammalt säkerhetsproblem involverar Python och tar-arkiv.

Pythons tarfil modul, som namnet antyder, hjälper program att packa upp tar-arkiv. Det är möjligt att skapa en .tar så att när en fil i arkivet extraheras av Python-modulen, kommer den att försöka skriva över en godtycklig fil på användarens filsystem. Detta kan utnyttjas för att kassera inställningar, ersätta skript och orsaka andra bus.

Felet upptäcktes 2007 och markerad igen 2022, vilket fick människor att börja lappa projekt för att undvika detta utnyttjande. Dessa säkerhetsuppdateringar kanske inte har tagit sig in i datamängderna som används för att träna stora språkmodeller att programmera, beklagade Bonner. "Så om du ber en LLM att gå och packa upp en tar-fil just nu, kommer den förmodligen att spotta tillbaka [den gamla] sårbara koden."

Bonner uppmanade AI-communityt att börja implementera säkerhetspraxis för leveranskedjan, som att kräva att utvecklare digitalt bevisar att de är den de säger att de är när de gör ändringar i offentliga kodförråd, vilket skulle försäkra folk om att nya versioner av saker producerades av legitima utvecklare och var inte skadliga förändringar. Det skulle kräva att utvecklare säkrar vad de än använder för att autentisera så att någon annan inte kan maskera sig som dem.

Och alla utvecklare, stora som små, bör göra säkerhetsbedömningar och inspektera verktygen de använder och penntesta sin programvara innan den distribueras.

Att försöka stärka säkerheten i AI-försörjningskedjan är knepigt, och med så många verktyg och modeller som byggs och släpps är det svårt att hänga med.

Protect AI:s McInerney betonade "det är typ det tillstånd vi befinner oss i just nu. Det är mycket lågt hängande frukt som finns överallt. Det finns helt enkelt inte tillräckligt med arbetskraft för att titta på allt eftersom allt går så fort.” ®

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://go.theregister.com/feed/www.theregister.com/2024/03/17/ai_supply_chain/