Om du trodde att säkerhetsproblemet för mjukvaruförsörjningskedjan var tillräckligt svårt idag, spänn på dig. Den explosiva tillväxten i användningen av artificiell intelligens (AI) är på väg att göra dessa leveranskedjeproblem exponentiellt svårare att navigera under de kommande åren. 

Utvecklare, applikationssäkerhetsproffs och DevSecOps-proffs uppmanas att fixa de högsta riskbristerna som lurar i vad som verkar vara de oändliga kombinationerna av öppen källkod och proprietära komponenter som är invävda i deras applikationer och molninfrastruktur. Men det är en ständig kamp som försöker ens förstå vilka komponenter de har, vilka som är sårbara och vilka brister som utsätter dem för mest risk. Det är klart att de redan kämpar för att hantera dessa beroenden i sin mjukvara som de är.

Vad som kommer att bli svårare är multiplikatoreffekten som AI kommer att lägga till situationen.

AI-modeller som självexekverande kod

AI och maskininlärning (ML)-aktiverade verktyg är mjukvara precis som alla andra typer av applikationer - och deras kod är lika sannolikt att lida av osäkerhet i leveranskedjan. Men de lägger till en annan tillgångsvariabel till mixen som avsevärt ökar attackytan för AI-programvarans leveranskedja: AI/ML-modeller.

"Vad som skiljer AI-applikationer från alla andra former av programvara är att [de förlitar sig] på något sätt eller sätt på något som kallas en maskininlärningsmodell", förklarar Daryan Dehghanpisheh, medgrundare av Protect AI. "Som ett resultat är den maskininlärningsmodellen i sig nu en tillgång i din infrastruktur. När du har en tillgång i din infrastruktur behöver du förmågan att skanna din miljö, identifiera var de är, vad de innehåller, vem som har behörigheter och vad de gör. Och om du inte kan göra det med modeller idag, kan du inte hantera dem.”

AI/ML-modeller utgör grunden för ett AI-systems förmåga att känna igen mönster, göra förutsägelser, fatta beslut, utlösa åtgärder eller skapa innehåll. Men sanningen är att de flesta organisationer inte ens vet hur de ens ska börja få synlighet i alla AI-modeller som är inbäddade i deras programvara. Modeller och infrastrukturen runt dem är byggda annorlunda än andra programvarukomponenter, och traditionella säkerhets- och mjukvaruverktyg är inte byggda för att söka efter eller förstå hur AI-modeller fungerar eller hur de är felaktiga. Det är detta som gör dem unika, säger Dehghanpisheh, som förklarar att de i huvudsak är dolda delar av självexekverande kod.

"En modell är designad en självutförande kod. Den har en viss handlingskraft”, säger Dehghanpisheh. "Om jag sa till dig att du har tillgångar över hela din infrastruktur som du inte kan se, du kan inte identifiera, du vet inte vad de innehåller, du vet inte vad koden är, och de körs själv och har externa samtal, det låter misstänkt som ett tillståndsvirus, eller hur?”

En tidig observatör av AI-osäkerheter

Att komma före denna fråga var den stora drivkraften bakom att han och hans medgrundare lanserade Protect AI 2022, vilket är ett av en mängd nya företag som dyker upp för att ta itu med problem med modellsäkerhet och datalinje som hotar i AI-eran. Dehghanpisheh och medgrundaren Ian Swanson såg en glimt av framtiden när de tidigare arbetat tillsammans med att bygga AI/ML-lösningar på AWS. Dehghanpisheh hade varit den globala ledaren för AI/ML-lösningsarkitekter.

"Under tiden som vi tillbringade tillsammans på AWS såg vi kunder bygga AI/ML-system i en otroligt snabb takt, långt innan generativ AI fångade hjärtan och sinnen hos alla från C-suiten till kongressen", säger han och förklarar att han arbetade med en rad ingenjörer och affärsutvecklingsexperter, samt mycket med kunder. "Det var då vi insåg hur och var säkerhetsbristerna som är unika för AI/ML-system finns."

De observerade tre grundläggande saker om AI/ML som hade otroliga konsekvenser för framtiden för cybersäkerhet, säger han. Den första var att adoptionstakten var så hög att de såg hur snabbt skugg-IT-enheter dök upp kring AI-utveckling och affärsanvändning som undgick den typ av styrning som skulle övervaka all annan typ av utveckling i företaget.

Den andra var att majoriteten av verktygen som användes – oavsett om de är kommersiella eller öppen källkod – byggdes av datavetare och kommande ML-ingenjörer som aldrig hade utbildats i säkerhetskoncept.

"Som ett resultat hade du verkligen användbara, mycket populära, mycket distribuerade, allmänt antagna verktyg som inte byggdes med ett säkerhetstänkande", säger han.

AI-system är inte byggda "Security-First"

Som ett resultat saknar många AI/ML-system och delade verktyg grunderna i autentisering och auktorisering och ger ofta för mycket läs- och skrivåtkomst i filsystem, förklarar han. Tillsammans med osäkra nätverkskonfigurationer och sedan de inneboende problemen i modellerna, börjar organisationer att fastna i övergripande säkerhetsproblem i dessa mycket komplexa, svårbegripliga system.

"Det fick oss att inse att de befintliga säkerhetsverktygen, processerna, ramverken - oavsett hur du gick åt vänster, saknade det sammanhang som maskininlärningsingenjörer, datavetare och AI-byggare skulle behöva", säger han.

Slutligen, den tredje stora observationen han och Swanson gjorde under dessa AWS-dagar var att AI-intrång inte skulle komma. De hade redan kommit.

"Vi såg att kunder hade intrång på en mängd olika AI/ML-system som borde ha fångats men inte gjorde det", säger han. "Vad det berättade för oss är att uppsättningen och processerna, såväl som incidentresponshanteringselementen, inte var specialbyggda för hur AI/ML byggdes upp. Det problemet har blivit mycket värre när generativ AI tog fart.”

AI-modeller delas mycket

Dehghanpisheh och Swanson började också se hur modeller och träningsdata skapade en unik ny AI-försörjningskedja som skulle behöva betraktas lika allvarligt som resten av mjukvaruförsörjningskedjan. Precis som med resten av modern mjukvaruutveckling och molnbaserad innovation, har datavetare och AI-experter drivit framsteg inom AI/ML-system genom skenande användning av öppen källkod och delade komponenter – inklusive AI-modeller och den data som används för att träna dem. Så många AI-system, oavsett om de är akademiska eller kommersiella, är byggda med hjälp av någon annans modell. Och som med resten av modern utveckling, fortsätter explosionen i AI-utveckling att driva på ett enormt dagligt inflöde av nya modelltillgångar som sprids över hela leveranskedjan, vilket innebär att det bara blir svårare att hålla reda på dem.

Ta Hugging Face, till exempel. Detta är ett av de mest använda förråden av AI-modeller med öppen källkod online idag - dess grundare säger att de vill vara AI:s GitHub. Tillbaka i november 2022 hade Hugging Face-användare delat 93,501 414,695 olika modeller med communityn. Följande november hade det sprängt upp till 527,244 XNUMX modeller. Nu, bara tre månader senare, har det antalet utökats till XNUMX XNUMX. Det här är en fråga vars omfattning snöar för varje dag. Och det kommer att lägga säkerhetsproblemet för mjukvaruförsörjningskedjan "på steroider", säger Dehghanpisheh.

A färsk analys av hans företag hittade tusentals modeller som delas öppet på Hugging Face kan exekvera godtycklig kod vid modellbelastning eller slutledning. Medan Hugging Face gör en del grundläggande skanning av sitt arkiv för säkerhetsproblem, saknas många modeller på vägen - åtminstone hälften av de högriskmodeller som upptäcktes i forskningen ansågs inte vara osäkra av plattformen, och Hugging Face gör det tydligt i dokumentationen att fastställandet av säkerheten för en modell i slutändan är användarnas ansvar. 

Steg för att hantera AI Supply Chain

Dehghanpisheh tror att nyckeln till cybersäkerhet i AI-eran kommer att börja först med att skapa en strukturerad förståelse för AI-härstamningen. Det inkluderar modelllinje och datalinje, som i huvudsak är ursprunget och historien för dessa tillgångar, hur de har ändrats och metadata som är associerade med dem.

"Det är första platsen att börja. Du kan inte fixa det du inte kan se och det du inte kan veta och det du inte kan definiera, eller hur?” han säger.

Samtidigt, på den dagliga operativa nivån, tror Dehghanpisheh att organisationer måste bygga ut kapacitet för att skanna sina modeller och leta efter brister som inte bara kan påverka systemets härdning utan integriteten hos dess produktion. Detta inkluderar problem som AI-bias och funktionsfel som kan orsaka fysisk skada i verkligheten från till exempel en autonom bil som kraschar in i en fotgängare.

"Det första är att du måste skanna", säger han. "Den andra saken är att du måste förstå dessa skanningar. Och det tredje är att när du har något som är flaggat måste du i princip stoppa den modellen från att aktiveras. Du måste begränsa dess byrå.”

Push för MLSecOps

MLSecOps är en leverantörsneutral rörelse som speglar DevSecOps-rörelsen i den traditionella mjukvaruvärlden.

"I likhet med övergången från DevOps till DevSecOps måste du göra två saker samtidigt. Det första du måste göra är att göra utövarna medvetna om att säkerhet är en utmaning och att det är ett delat ansvar, säger Dehghanpisheh. "Det andra du måste göra är att ge sammanhang och lägga säkerhet i verktyg som håller datavetare, maskininlärningsingenjörer, [och] AI-byggare på spetsen och ständigt förnyar, men låter säkerhetsproblemen försvinna i bakgrunden .”

Dessutom säger han att organisationer kommer att behöva börja lägga till policyer för styrning, risk och efterlevnad och tillsynsmöjligheter och procedurer för incidentrespons som hjälper till att styra de åtgärder och processer som äger rum när osäkerheter upptäcks. Precis som med ett solidt DevSecOps-ekosystem betyder detta att MLSecOps kommer att behöva ett starkt engagemang från affärsintressenter hela vägen upp på ledningsstegen.

Den goda nyheten är att AI/ML-säkerhet drar nytta av en sak som ingen annan snabb teknikinnovation har haft direkt utanför porten – nämligen regulatoriska mandat direkt utanför porten. 

"Tänk på vilken annan teknikövergång som helst," säger Dehghanpisheh. "Nämn en gång som en federal tillsynsmyndighet eller till och med statliga tillsynsmyndigheter har sagt det här tidigt, 'Whoa, whoa, whoa, du måste berätta allt som finns i den. Du måste prioritera kunskap om det systemet. Du måste prioritera en stycklista. Det finns ingen."

Detta innebär att många säkerhetsledare är mer benägna att få buy-in för att bygga ut AI-säkerhetskapacitet mycket tidigare i innovationslivscykeln. Ett av de mest uppenbara tecknen på detta stöd är den snabba övergången till att sponsra nya jobbfunktioner i organisationer.

"Den största skillnaden som den reglerande mentaliteten har fört fram är att i januari 2023 var konceptet med en chef för AI-säkerhet nytt och existerade inte. Men i juni började du se dessa roller, säger Dehghanpisheh. "Nu är de överallt - och de är finansierade."

• 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://www.darkreading.com/cyber-risk/do-you-know-where-your-ai-models-are-tonight