software supply chain security - útoky na dodavatelský řetězec s otevřeným zdrojovým kódem - bezpečnost umělé inteligence a softwaru - zabezpečení s umělou inteligencí

Zabezpečení umělé inteligence a rozšiřující se oblast útoků na dodavatelský řetězec softwaru

Open source se stal základem moderního vývoje softwaru. Téměř každá aplikace dnes závisí na komplexní síti knihoven, frameworků, modelů a nástrojů pro tvorbu od třetích stran. Tato skutečnost sama o sobě přináší značné software supply chain security výzvy. Zároveň vstoupila umělá inteligence životní cyklus vývoje softwaru jako výkonný akcelerátor, generující kód, navrhující závislosti, automatizující opravy a dokonce ovlivňující architektonické návrhycisionty. Open source a umělá inteligence společně transformovaly způsob, jakým se software vytváří, a nevyhnutelně i způsob, jakým je na něj útočeno. Průnik bezpečnosti umělé inteligence, bezpečnosti umělé inteligence a softwaru a software supply chain security již není teoretické. Nyní je jedním z dominantních zdrojů rizik v dodavatelském řetězci softwaru, kterým čelí inženýrské organizace.

Tato realita ovlivnila naši nedávnou přednášku SafeDev Talk: Open Source, umělá inteligence a nový útočný povrch: Kód vybavený zbraněmi, chytřejší obrana, kterého se zúčastnili bezpečnostní lídři ze společností Red Hat, TikTok a Xygeni. Diskuse se zaměřila na to, s čím se bezpečnostní a technické týmy již setkávají v produkčním prostředí, zejména v souvislosti s útoky na dodavatelský řetězec s otevřeným zdrojovým kódem, škodlivými balíčky s otevřeným zdrojovým kódem a rostoucím napětím mezi rychlostí a kontrolou při vývoji softwaru řízeného umělou inteligencí. Objevil se jasný obraz: plocha pro útok se rozšiřuje rychleji, než tradiční bezpečnostní modely dokážou udržet krok, a umělá inteligence funguje jak jako multiplikátor síly, tak jako zátěžový test dlouhodobých předpokladů v oblasti bezpečnosti a ochrany s využitím umělé inteligence. software supply chain security.

Pokud se vám tento popis zdá nepříjemně blízký tomu, jak vaše organizace v současnosti vyvíjí software, není to náhoda. Mnoho týmů si uvědomí, kolik důvěry se přesunulo k automatizaci, až poté, co se něco porouchá.

Zabezpečení umělé inteligence a Software Supply Chain Security Jsou teď stejný problém

Opakujícím se tématem v celé diskusi bylo, že bezpečnost umělé inteligence již nelze považovat za samostatnou disciplínu software supply chain securitySystémy umělé inteligence nefungují izolovaně; jsou vytvářeny, trénovány, nasazovány a integrovány prostřednictvím stejného pipelines, závislosti a registry, které již nyní bojují s útoky na dodavatelský řetězec s otevřeným zdrojovým kódem.

Ve vývoji softwaru řízeném umělou inteligencí modely navrhují kód, generují opravy a automaticky vybírají závislosti. Tyto decisionty přímo ovlivňují správa závislostí open source, často bez explicitního lidského záměru. V důsledku toho riziko závislosti již není řízeno pouze volbou vývojáře; je stále více formováno chováním umělé inteligence.

Tato konvergence znamená, že selhání v oblasti umělé inteligence a zabezpečení softwaru se často projevují jako tradiční incidenty v dodavatelském řetězci: ohrožené závislosti, poškozené artefakty sestavení nebo zranitelné... CI/CD procesy. Nástroje sice mohou být nové, ale riziko dodavatelského řetězce softwaru je velmi reálné a stále obtížnější o něm uvažovat.

Pokud vaše modely hrozeb stále oddělují „riziko umělé inteligence“ od „rizika dodavatelského řetězce“, může být vhodné znovu se zamyslet nad tím, kde tato hranice ve vašich pracovních postupech sestavení a nasazení skutečně existuje.

Útoky na open source dodavatelský řetězec rychlostí stroje

Útoky na open source dodavatelský řetězec nejsou nové, ale umělá inteligence mění jejich ekonomiku. Útočníci nepotřebují nové techniky, potřebují škálovatelnost. Umělá inteligence umožňuje rychlou analýzu ekosystému, automatizované odhalování slabých závislostí a rychlé iterace útočných dat.

Z útočného hlediska tato industrializace průzkumu dramaticky zvyšuje úspěšnost útoků zahrnujících škodlivé balíčky s otevřeným zdrojovým kódem. Komponenty, které by dříve zůstaly bez povšimnutí, lze nyní rychle objevit, analyzovat a zneužít, často ještě předtím, než si obránci uvědomí, že jsou používány.

To je důvod, proč software supply chain security Nelze se spoléhat pouze na opožděné signály. Registry, doporučení a následná zveřejnění informací fungují v lidském časovém horizontu, zatímco útočníci stále častěji jednají rychlostí stroje. Výsledné okno expozice přímo přispívá k rostoucímu riziku v dodavatelském řetězci softwaru.

Pokud je vaším primárním detekčním signálem „registr odstranil balíček“, působíte již na časové ose útočníka.

Chcete se hlouběji ponořit do útoků na dodavatelský řetězec softwaru s otevřeným zdrojovým kódem?

Přečtěte si naši sérii blogových příspěvků o škodlivých balíčcích s otevřeným zdrojovým kódem

Riziko závislostí ve vývoji softwaru řízeného umělou inteligencí

Jedním z nejzřetelnějších rizik diskutovaných během SafeDev Talk bylo riziko závislosti, zejména v prostředích, která se silně spoléhají na vývoj softwaru řízený umělou inteligencí. Asistenti kódování s umělou inteligencí jsou optimalizováni pro pohodlí a rychlost, nikoli pro minimalizaci plochy pro útok.

V praxi to vede k agresivnímu zavádění závislostí. Místo opětovného použití stávající funkcionality se přidávají nové knihovny. tranzitivní závislosti tiše se rozšiřovat a využívat otevřený zdrojový kód řízení závislostí stává se reaktivním spíše než úmyslným. Postupem času týmy ztrácejí schopnost uvažovat o tom, co vlastně provozují.

Nejde jen o hygienický problém. Každá nová závislost s sebou nese další riziko dodavatelského řetězce softwaru, nové předpoklady důvěryhodnosti a nové příležitosti pro útoky na open source dodavatelský řetězec. Když se závislost de...cisPokud jsou situace automatizovány a povrchně přezkoumávány, riziko závislosti se stává systémovým spíše než náhodným.

Pokud váš graf závislostí roste rychleji než schopnost vašeho týmu jej vysvětlit, nejedná se o problém s nástroji, ale o problém s důvěrou.

Asistenti AI kódování, bezpečnost a kolaps recenzování

Dalším diskutovaným způsobem selhání bylo narušení vzájemného hodnocení v přítomnosti kódu generovaného umělou inteligencí. Asistenti kódování s umělou inteligencí, bezpečnost se netýká jen rychlého vkládání nebo zneužití modelu; jde o to, kolik nezkontrolované logiky se dostane do produkčních systémů.

Změny generované umělou inteligencí jsou často rozsáhlé, soudržné a obtížně kontrolovatelné pod časovým tlakem. V důsledku toho se vzájemné hodnocení stává povrchním nebo symbolickým. Tento tichý kolaps odstraňuje jednu z nejúčinnějších kontrol v software supply chain security.

Problém není v nedbalosti vývojářů. Je to v nesouladu pracovních postupů. Když je rychlost odměňována a překážky penalizovány, bezpečnostní mechanismy umělé inteligence a softwaru, které jsou závislé na lidské pozornosti, nevyhnutelně oslabují. Útočníci nemusí obcházet kontrolu, pokud kontrola již nefunguje jako bariéra.

Mnoho týmů se domnívá, že kontrola stále funguje, protože proces existuje. Méně se ptá, zda stále funguje jako smysluplná kontrola.

Škodlivé balíčky s otevřeným zdrojovým kódem a mýtus o popularitě

V oblasti správy závislostí open source se obecně věří, že populární projekty jsou bezpečnější. Ve skutečnosti popularita často zvyšuje viditelnost. Široce používané knihovny jsou pro útoky na dodavatelský řetězec s otevřeným zdrojovým kódem, procisprotože kompromis má široký dopad na následné fáze.

Mnoho populárních projektů spravují malé týmy nebo jednotlivci. I když jsou zjištěny problémy, škodlivé balíčky s otevřeným zdrojovým kódem často zůstávají dostupné hodiny nebo dny, než jsou odstraněny. Během této doby je organizace nadále přijímají prostřednictvím automatizovaných sestavení.

Toto zpoždění posiluje potřebu proaktivního software supply chain security kontroly. Spoléhání se pouze na popularitu, reputaci nebo registrační opatření nestačí, pokud čelíme riziku v moderním softwarovém dodavatelském řetězci.

„Široce používaný“ není totéž co „aktivně obhajovaný“ a zacházení s ním jako s takovým je jednou z nejtrvalejších mylných představ o dodavatelském řetězci.

Původ v dodavatelských řetězcích softwaru a zabezpečení umělé inteligence

V průběhu diskuse se opakovaně objevovala potřeba původu v dodavatelských řetězcích softwaru. V prostředích s podporou umělé inteligence se atribuce stává nejasnou. Kód může být generován modelem, upraven člověkem, sloučen automatizací a nasazen bez jasné odpovědnosti.

Bez ověřitelného původu jsou organizace nuceny implicitně důvěřovat artefaktem. Bezpečnost umělé inteligence vyžaduje posun od důvěry k ověřování: podepsané artefakty, build attestationsa sledovatelný původ. I když původ přímo nezabrání škodlivému chování, výrazně snižuje nejednoznačnost a omezuje manévrovatelnost útočníka.

To platí stejnou měrou pro modely, data i kód. V oblasti vývoje softwaru řízeného umělou inteligencí je původ základním požadavkem jak pro umělou inteligenci, tak pro bezpečnost softwaru.

SBOM a zabezpečení umělé inteligence v moderním Pipelines

Role SBOM a bezpečnost umělé inteligence byla dalším implicitním tématem. SBOMposkytují přehled o grafech závislostí, ale samotná viditelnost nestačí. V prostředích s vysokým podílem umělé inteligence, SBOMse musí vyvíjet tak, aby zachytily nejen knihovny, ale i modely, kroky sestavení a automatizovaný vývoj.cisionty.

V kombinaci s analýza chování a původ, SBOM a zabezpečení umělou inteligencí se stávají mocnými nástroji pro snižování rizik v dodavatelském řetězci softwaru. Umožňují organizacím detekovat neočekávané změny, zdůvodňovat jejich dopad a efektivněji reagovat na útoky v dodavatelském řetězci s využitím open source technologií.

CI/CD Pipeline Security Pod tlakem automatizace

Konečně, CI/CD pipeline security se ukázala jako kritická řídicí rovina. Pipelinestále častěji provádějí akce navržené nebo spuštěné systémy umělé inteligence. Pokud tyto pipelineProtože chybí silné kontroly identity, ověřování artefaktů a vynucování zásad, stávají se ideálními vstupními body pro útočníky.

Nedostačující CI/CD pipeline security umožňuje škodlivým balíčkům s otevřeným zdrojovým kódem ovlivňovat nejen produkční systémy, ale i vývojářská prostředí a infrastrukturu pro sestavení. S rostoucí automatizací pipelinemusí být v rámci software supply chain security programy.

Podívejte se na přednášku SafeDev

Chcete-li se o všech těchto poznatcích dozvědět více přímo od odborníků, kteří utvářejí tento obor, podívejte se na celý Diskuse o bezpečném vývoji: Open Source, umělá inteligence a nový útočný povrch: Kód vybavený zbraněmi, chytřejší obrana, Představovat Roman Žukov (Červený klobouk), Leon Johnson (TikTok), a Luis Rodríguez Berzosa (Xygeni).

Praktické důsledky pro bezpečnost a Software Supply Chain Security

Praktické důsledky těchto změn sahají nad rámec nástrojů. Organizace si musí uvědomit, že bezpečnost umělé inteligence, bezpečnost umělé inteligence a softwaru a software supply chain security jsou nyní hluboce propojeny. DecisIony, které byly dříve považovány za nízkorizikové, aktualizace závislostí, generování kódu a automatizace, nyní nesou významné riziko pro dodavatelský řetězec softwaru, zejména pokud se jedná o ty, které...cisIony jsou vytvářeny implicitně nástroji, nikoli explicitně lidmi.

Během prezentace SafeDev Talk byl tento bod stručně shrnut. Jak to vyjádřil jeden z řečníků, Když se systémy umělé inteligence podílejí na vývoji softwaru, bezpečnostní týmy už nezajišťují pouze zabezpečení kódu, ale i zabezpečení...cisionty. Automatizace nezbavuje odpovědnosti, ale ji přerozděluje.

V praxi to znamená obnovení intencionality tam, kde převládla pohodlnost. Správa závislostí open source musí zohledňovat chování řízené umělou inteligencí, spíše než předpokládat lidské uvažování. Riziko závislosti již nelze vnímat jako občasnou kontrolu.cise. CI/CD pipeline security musí vynucovat ověřování, ne předpokládat neškodné vstupy. A původ v dodavatelských řetězcích softwaru se musí posunout od aspirace k základnímu stavu.

Dalším poznatkem z diskuse bylo, že rychlost sama o sobě již není neutrální. Většina selhání dodavatelského řetězce nepochází z jediné katastrofické události.cision, ale z mnoha malých automatizovaných voleb, které nikdo výslovně neschválil. Toto je předemcisproč tradiční modely důvěry selhávají při vývoji softwaru řízeného umělou inteligencí.

Nic z toho neznamená opuštění open source nebo umělé inteligence. Naopak to uznává jejich ústřední roli v moderním inženýrství. Bez vývoje bezpečnostních předpokladů však organizace riskují, že nechají automatizaci automaticky definovat důvěru.

Uzavřít…

Užitečný způsob, jak o tomto posunu přemýšlet, je, že software supply chain security Už nejde jen o ochranu artefaktů. Jde o ochranu decisiontové dráhyVe světě s podporou umělé inteligence nejsou nejdůležitější bezpečnostní otázky jen „Je tato komponenta zranitelná?“, ale „Proč byla zavedena, kým nebo čím a za jakých omezení?“ Organizace, které se tomuto rámci přizpůsobí, riziko neodstraní, ale budou jím mnohem méně překvapeny.

nástroje pro analýzu složení softwaru SCA
Stanovte priority, opravte a zabezpečte svá softwarová rizika
Získejte svůj bezplatný účet.
Nevyžaduje se žádná kreditní karta.

Zajistěte si vývoj a dodávky softwaru

s produktovým balíčkem Xygeni