Dirbtinio intelekto medžiagų sąrašo paaiškinimas „DevSecOps“ komandoms #
Diskusija apie dirbtinio intelekto duomenų bazę (DI BOM) kilo ne iš akademinio smalsumo. Ji iškilo dėl to, kad saugumo komandos pradėjo prarasti savo matomumą. Kuriant mašininio mokymosi modelius, pamatinius modelius ir AI padedamas kodo generavimas patekus į gamybines sistemas, tradicinių programinės įrangos inventorių nebepakako. Galėtumėte išvardyti paketus, konteinerius ir bibliotekas, tačiau vis tiek nežinotumėte, kurie modeliai buvo įterpti, iš kur gauti mokymo duomenys ar kurios išorinės API formavo veikimo laiką. Tai yra preliminaruscisŠią spragą turėtų užpildyti dirbtinio intelekto medžiagų sąrašas.
Kai buvo gauti skaičiai, poreikio ignoruoti tapo neįmanoma. Šiandien 40 % dirbtinio intelekto sugeneruoto kodo turi saugumo spragų, dirbtinio intelekto nukreiptų kredencialų vagysčių skaičius nuo 2025 m. 4 ketvirčio iki 2026 m. 1 ketvirčio išaugo 376 %, o ES dirbtinio intelekto įstatymo techninės dokumentacijos reikalavimai... didelės rizikos dirbtinio intelekto sistemos įsigalioja 2026 m. rugpjūčio 2 d.Organizacijos, kurios negali sudaryti struktūrizuoto savo dirbtinio intelekto komponentų inventoriaus (DI-BOM), vienu metu susiduria su trimis pavojais: saugumu, atitiktimi ir DI tiekimo grandinės vientisumu. Prieš tęsdami toliau, nustatykime aiškų pradinį lygį.
Išsamiai susipažinkite su dirbtinio intelekto medžiagų sąrašu #
Kas yra dirbtinio intelekto medžiagų sąrašas? Dirbtinio intelekto medžiagų sąrašas (angl. AI Bill of Materials) yra struktūrizuotas inventorius, kuriame dokumentuojami visi sistemoje naudojami su dirbtiniu intelektu susiję komponentai. Tai apima modelius, duomenų rinkinius, mokymo sistemas, išvadų variklius, trečiųjų šalių API, atvirojo kodo priklausomybes ir konfigūracijos artefaktus, kurie daro įtaką dirbtinio intelekto elgesiui kūrimo ir vykdymo metu. Jei Programinės įrangos medžiagų sąmata (SBOM) atsako į klausimą „koks kodas yra šioje programoje“, o DI medžiagų sąrašas atsako į sudėtingesnį klausimą: koks intelektas čia įterptas, iš kur jis atsirado ir kokią riziką jis kelia? DI medžiagų sąrašas nepakeičia SBOMJis išplečia jį į sritis, kuriose tradicinis priklausomybių stebėjimas neveikia, ypač kalbant apie neskaidrius modelius, išorines dirbtinio intelekto paslaugas ir nuolat besikeičiančius artefaktus.
Kodėl dirbtinio intelekto BOM egzistuoja kaip atskira koncepcija? #
Iš pradžių apsaugos komandos bandė pasitempti SBOMs, kad apimtų DI išteklius. Toks metodas greitai nepasiteisina. Modeliai nėra bibliotekos. Mokymo duomenų rinkiniai nėra paketai. Raginimų šablonai nėra statiniai konfigūracijos failai. DI medžiagų sąrašas egzistuoja todėl, kad DI sistemos įveda rizikos matmenis, kurie SBOMniekada nebuvo sukurti gaudyti.
Kai komandos klausia, kas yra dirbtinio intelekto specifikacija (DI), jos dažnai reaguoja į vieną iš šių realijų:
- Modelis buvo ištrauktas iš viešojo registro su nežinoma kilme
- Mokymo duomenyse buvo licencijuotos arba neskelbtinos medžiagos
- Išorinė LLM API pakeitė savo veikimą be įspėjimo
- Modelio atnaujinimas sukėlė šališkumą, nuotėkį arba nesaugius rezultatus
Dirbtinio intelekto medžiagų sąrašas užtikrina šių scenarijų atsekamumą, todėl jis vis dažniau minimas diskusijose apie dirbtinio intelekto saugumą, valdymą ir atitiktį.
Pagrindiniai komponentai, dokumentuoti dirbtinio intelekto medžiagų sąraše #
Dirbtinio intelekto medžiagų sąrašas naudingas tik tuo atveju, jei jis yra konkretus. Nors įgyvendinimo būdai skiriasi, brandžios dirbtinio intelekto medžiagų sąrašo struktūros nuosekliai dokumentuoja šias kategorijas.
Modeliai ir modelių artefaktai #
Tai apima modelio pavadinimą, versiją, architektūrą, šaltinio saugyklą arba tiekėją, kontrolinę sumą arba maišos kodą ir diegimo kontekstą. Be šios informacijos incidento atsakas tampa spėlionėmis.
Mokymo ir tikslinimo duomenys #
Dirbtinio intelekto medžiagų sąrašas (DIB) fiksuoja duomenų rinkinius, naudojamus mokymui ar tikslinimui, įskaitant kilmę, licencijavimo apribojimus ir jautrumo klasifikaciją. Tai labai svarbu reguliavimo poveikiui ir intelektinės nuosavybės rizikai.
Karkasai ir įrankių grandinės #
Čia įtrauktos „TensorFlow“, „PyTorch“, išvadų vykdymo aplinkos, optimizavimo bibliotekos ir modelių keitikliai. Saugumo požiūriu tai yra vykdomosios priklausomybės, keliančios tokią pačią kenkėjiškų programų ir pažeidžiamumų riziką kaip ir tradicinis kodas.
Išorinės dirbtinio intelekto paslaugos ir API #
Bet koks trečiųjų šalių dirbtinio intelekto paslaugų naudojimas turi būti nurodytas dirbtinio intelekto medžiagų sąraše, įskaitant teikėją, naudojimo apimtį, duomenų srautus ir atnaujinimo dažnumą.
Konfigūracijos ir raginimų ištekliai #
raginimai, guardrails, o politikos sluoksniai daro didelę įtaką dirbtinio intelekto elgsenai. Dirbtinio intelekto medžiagų sąraše (DI BOM) jie traktuojami kaip pirmos klasės ištekliai, o ne kaip komentarai saugykloje.
Kaip dirbtinio intelekto BOM palaiko saugios kūrimo praktikas #
Saugumo specialistai dažnai daro prielaidą, kad esamos kontrolės priemonės natūraliai taikomos ir dirbtiniam intelektui. Taip nėra. Šis klaidingas įsitikinimas atspindi ankstesnes klaidas, padarytas su atvirojo kodo tiekimo grandinės.
Dirbtinio intelekto medžiagų specifikacija įgalina valdiklius, kurie kitaip dėl sudėtingumo sugestų:
- Rizikos vertinimas, susietas su konkrečiais modeliais ir duomenų šaltiniais
- Greitesnis izoliavimas, kai pažeidžiamas dirbtinio intelekto komponentas
- Priverstinis šešėlinio dirbtinio intelekto naudojimo valdymas
- Aiškus DI valdomo funkcionalumo nuosavybės teisės pripažinimas
Kai komandos klausia, kas yra dirbtinio intelekto medžiagų specifikacija (DI BOM), praktinis atsakymas yra paprastas: tai minimalus artefaktas, reikalingas norint DI sistemas laikyti audituojamais programinės įrangos komponentais, o ne juodosiomis dėžėmis.
Dažni klaidingi supratimai #
1 klaidinga nuomonė: „Mes jau sekame priklausomybes, todėl turime dirbtinio intelekto medžiagų sąrašą.“
„Python“ paketų stebėjimas nenurodo, kurie modelio svoriai buvo įkelti, kokie duomenų rinkinio formos rezultatai ar ar išvados galinis taškas kreipiasi į išorinį teikėją. Dirbtinio intelekto medžiagų sąrašas nėra išvedamas; jis turi būti aiškiai sugeneruotas ir prižiūrimas.
2 klaidinga nuomonė: „DI medžiagų sąrašai skirti tik reguliuojamoms pramonės šakoms.“ #
Reglamentavimas spartina diegimą, tačiau saugumo incidentai skatina būtinybę. Modelių užkrėtimas, skubus įterpimas, duomenų nutekėjimas ir kenkėjiški modelių atnaujinimai paveikia kiekvieną DI diegiančią organizaciją. DI medžiagų sąrašas yra gynybinė kontrolės priemonė, o ne tik atitikties artefaktas.
3 klaidinga nuomonė: „Modelių teikėjai tvarko šią riziką už mus.“ #
Išoriniai tiekėjai mažina veiklos naštą, o ne atskaitomybę. Jei jūsų sistema naudoja dirbtinio intelekto išvestis, jūs prisiimate riziką. Dirbtinio intelekto medžiagų sąraše (DI BOM) dokumentuojama ši priklausomybė, kad ją būtų galima valdyti, o ne ignoruoti.
DI BOM ir SBOM: Kodėl reikalingi abu? #
Šis palyginimas yra svarbus „DevSecOps“ komandoms, bandančioms išvengti įrankių išsibarstymo, todėl verta būti iš anksto.cisapie tai, kur baigiasi kiekvienas artefaktas ir prasideda kitas.
An SBOM inventorizuoja programinės įrangos komponentus, paketus, bibliotekas, konteinerius ir jų versijas bei licencijas. Tai atsako į klausimą: koks kodas veikia šioje programoje? Dirbtinio intelekto medžiagų sąrašas (DI BOM) inventorizuoja intelekto komponentus, modelius, duomenų rinkinius, mokymo sistemas, išorines API ir raginimų konfigūracijas. Tai atsako į kitą klausimą: koks DI formuoja šios sistemos elgseną, iš kur jis atsirado ir kokią riziką jis kelia?
Akloji zona tampa aiški konkrečiu pavyzdžiu. Tarkime, trečiosios šalies pagrindinio modelio teikėjas tyliai atnaujina API galinio taško svorius. Nesikeičia paketo versija. Neatnaujinami priklausomybių grafiko įrašai. Jūsų SBOM nieko nerodo. Tačiau modelis, kurį iškviečia jūsų programa, dabar elgiasi kitaip, su skirtingais rezultatais, skirtingais gedimų režimais ir potencialiai skirtingomis saugos savybėmis. Dirbtinio intelekto medžiagų sąrašas seka modelio versiją, teikėją, atnaujinimo dažnumą ir susijusius duomenų srautus. Jis tiksliai fiksuoja tai, ką SBOM negali matyti.
Antras pavyzdys: konfigūracijos faile saugomas raginimo šablonas yra modifikuojamas, kad būtų pašalintas apsauginis turėklas. Tai nėra kodo pakeitimas, ne priklausomybės atnaujinimas ir ne konteinerio perkūrimas. Jis niekur nerodomas. SBOMTačiau tai iš esmės pakeičia dirbtinio intelekto sistemos elgesį vykdymo metu. Dirbtinio intelekto medžiagų sąraše (DI BOM) raginimo ištekliai traktuojami kaip pirmos klasės komponentai, kurie yra versuojami, stebimi ir audituojami.
Tarp dviejų artefaktų yra persidengimas. Dirbtinio intelekto sistemos, tokios kaip „PyTorch“, „TensorFlow“ ir „LangChain“, pasirodo abiejuose. SBOM ir dirbtinio intelekto BOM, nes tai yra vykdomosios priklausomybės, turinčios realų pažeidžiamumą ir kenkėjiškų programų riziką. Tačiau šis persidengimas yra nedidelis. Modelio sluoksnis, duomenų sluoksnis, raginimo sluoksnis ir išorinis API sluoksnis yra visiškai už jo ribų. SBOM aprėptis.
Kartu, SBOM ir dirbtinio intelekto medžiagų sąrašas pateikia išsamų programinės įrangos tiekimo grandinės rizikos vaizdą. Atskirai kiekvienas palieka kito akląsias zonas nevaldomas. Štai kodėl pramonės gairėse dirbtinio intelekto medžiagų sąrašas vis dažniau pateikiamas kaip papildoma priemonė SBOM, nėra pasirenkamas ir nėra pakaitalas.
Dirbtinio intelekto medžiagų sąrašo (DIB) įdiegimas „DevSecOps“ aplinkoje #
Dirbtinio intelekto medžiagų sąrašas neturėtų būti statinė dokumentacija. Jis turi būti integruotas į SDLCEfektyvus diegimas jį sukuria ir palaiko trimis kūrimo ciklo etapais:
- Modelio adaptacija. Kai į aplinką įvedamas naujas modelis, duomenų rinkinys arba išorinė dirbtinio intelekto API, tuo metu sukuriamas dirbtinio intelekto medžiagų sąrašo įrašas, kuriame užfiksuojama kilmė, versija, licencijavimas, duomenų srautai ir rizikos klasifikacija, kol komponentas nepasiekia bet kokio lygio. pipeline arba gamybos sistema. Tai yra taškas, kai nežinomas DI nustoja būti šešėliniu DI.
- CI/CD vykdymas. Kiekvienas pipeline paleidimas yra galimybė patikrinti, ar naudojami dirbtinio intelekto komponentai atitinka dirbtinio intelekto medžiagų sąrašo įrašus. Automatiniai patikrinimai CI/CD „catch swift“ – modelio versija, kuri pasikeitė siųstuvėje, modifikuotas raginimo failas, API galinis taškas, kuris dabar kreipiasi į kitą teikėją. Šių aptikimas kūrimo metu kainuoja daug mažiau nei aptikimas incidento metu.
- Diegimo ir vykdymo laiko pakeitimai. Kai DI komponentai atnaujinami, pakeičiami arba išjungiami gamyboje, DI medžiagų sąrašas atnaujinamas, kad atspindėtų pakeitimą, o ankstesnė būsena išsaugoma pakeitimų žurnale. Taip sukuriamas audito takelis, nuo kurio priklauso reagavimas į incidentus, reguliavimo institucijų peržiūra ir valdymo ataskaitos – laiko žyma pažymėtas įrašas apie tai, kas, kada ir kokia konfigūracija veikė DI.
Šis nuolatinio atnaujinimo modelis ir skiria veikiantį dirbtinio intelekto medžiagų sąrašą nuo atitikties dokumento. Atitikties dokumentas atsako į klausimus audito metu. Veikiantis dirbtinio intelekto medžiagų sąrašas atsako į klausimus incidento metu, kai atsakymai iš tikrųjų yra svarbūs.
Kodėl AI BOM yra svarbios reaguojant į incidentus? #
Kai DI modelyje ar sistemoje aptinkamas pažeidžiamumas arba kenkėjiška elgsena, laikas yra svarbus. Be DI medžiagų sąrašo komandos negali patikimai atsakyti:
- Kurios programos yra paveiktos
- Kokios aplinkos yra veikiamos
- Ar buvo susiję neskelbtini duomenys
Šio neapibrėžtumo kaina yra išmatuojama. „PromptMink“ tiekimo grandinės atakos metu (kai Šiaurės Korėjos valstybės remiama grupė sukūrė kenkėjiškus npm paketus, specialiai skirtus apgauti dirbtinio intelekto kodavimo agentus) komandos, neturinčios dirbtinio intelekto inventoriaus, neturėjo greito būdo nustatyti, kurie agentai ištraukė pažeistą priklausomybę, kurios aplinkos buvo paviešintos arba ar piniginės prisijungimo duomenys ir... CI/CD žetonai jau buvo išfiltruoti. Tyrimas pradėtas nuo nulio, o ne nuo žinomos pradinės padėties.
Dirbtinio intelekto medžiagų sąrašas sutrumpina reagavimo laiką, paversdamas nežinomus duomenis ieškomais faktais. Kai inventorius yra ir yra aktualus, į pirmąjį incidento klausimą (kas paveikta) atsakoma per kelias minutes, o ne per kelias dienas.
Dirbtinio intelekto specifikacijų (BOM) vaidmuo AI-First AppSec sistemoje #
Dirbtiniam intelektui tampant integruotu į visą kūrimo procesą, saugumo įrankiai turi vystytis. Platformos, kurios jau teikia SBOMs, kenkėjiškų programų aptikimasir priklausomybės intelektas dabar plečia dirbtinio intelekto komponentų matomumą. Būtent čia tokios platformos kaip Ksigeni natūraliai dera su dirbtinio intelekto medžiagų specifikacijų koncepcija. Susiejant su dirbtiniu intelektu susijusius artefaktus su kodu, priklausomybėmis, pipelineir vykdymo laiko elgseną, dirbtinio intelekto medžiagų sąrašai nustoja būti teorinėmis diagramomis ir tampa veiksmingais saugumo valdikliais.
Dirbtinio intelekto medžiagų rinkinys kartu su kenkėjiškų programų aptikimas realiuoju laiku, SCA, CI/CD saugumasir ASPM leidžia komandoms valdyti dirbtinio intelekto riziką nesulėtinant teikimo. Tai yra praktinis tikslas: matomumas be trinties.
Baigiamosios mintys: kodėl klausimas „Kas yra dirbtinio intelekto BOM“ yra tinkamas #
Klausimas, kas yra dirbtinio intelekto medžiagų sąrašas, nėra susijęs su apibrėžimais. Svarbu pripažinti, kad dirbtinio intelekto sistemos dabar yra programinės įrangos tiekimo grandinės dalis ir kad nevaldomos tiekimo grandinės neveikia. Dirbtinio intelekto medžiagų sąrašas suteikia „DevSecOps“ komandoms tokį patį svertą dirbtinio intelekto atžvilgiu, kaip ir... SBOMperkelta į atvirojo kodo infrastruktūrą, ne visiška kontrolė, bet pakankamas matomumas, kad būtų galima priimti pagrįstą sprendimącisjonus, greitai reaguoti ir sumažinti išvengiamą riziką.
Komandoms, valdančioms dirbtinio intelekto inventoriaus atitiktį DI pagrindu veikiančioje sistemoje SDLCAI-BOM nėra ateities reikalavimas. Tai yra minimaliai įgyvendinama kontrolės priemonė, leidžianti dirbtinį intelektą laikyti programinės įrangos tiekimo grandinės dalimi šiandien. Štai kodėl tai nėra tendencija. Tai korekcija.
DUK #
Didelės rizikos dirbtinio intelekto sistemų teikėjams – taip. ES dirbtinio intelekto įstatymo 11 straipsnis ir IV priedas reikalauja techninės dokumentacijos, apimančios sistemos aprašymą, mokymo metodiką, duomenų rinkinių charakteristikas ir stebėsenos procedūras, ir ši dokumentacija turi būti nuolat atnaujinama ir pateikiama reguliavimo institucijoms paprašius. Pagal dabartinį įstatymą įgyvendinimo terminas yra 2026 m. rugpjūčio 2 d. AI-BOM yra operacinė struktūra, kuri nuolat generuoja ir tvarko šią dokumentaciją, o ne kaip konkretų laiko tarpą atliekamą užduotį.cise. Organizacijoms, nepriskiriamoms didelės rizikos klasifikacijai, vis dar taikomi dokumentacijos reikalavimai pagal NIST AI RMF ir enterprise viešųjų pirkimų reikalavimai, kai pirkėjai vis dažniau prašo pateikti AI-BOM kaip tiekėjo išsamaus patikrinimo dalį.
Be aukščiau aptartų pagrindinių komponentų, išsamus AI-BOM taip pat apima: patvirtinimo istoriją ir pakeitimų žurnalą, vertinimo rezultatus ir žinomus gedimų režimus, atitikties patvirtinimus, žmogaus priežiūros reikalavimus ir rizikos vertinimo dokumentaciją. Skirtingai nuo statinio dokumento, AI-BOM yra gyvas artefaktas, jis atnaujinamas, kai modeliai yra perkvalifikuojami, tikslinami ar pakeičiami, taip pat kai keičiasi API ir integracijos. Pats pakeitimų žurnalas yra artefakto dalis.
Atsakomybė priklauso nuo vaidmens dirbtinio intelekto tiekimo grandinėje. Tiekėjai (organizacijos, kurios kuria arba tobulina dirbtinio intelekto sistemas) yra atsakingos už dirbtinio intelekto rinkinio (AI-BOM) generavimą ir priežiūrą bei jo pateikimą tolesniems diegėjams ir reguliavimo institucijoms. Diegėjai (organizacijos, kurios integruoja trečiųjų šalių dirbtinį intelektą į savo produktus ar darbo eigas) yra atsakingos už AI-BOM gavimą iš savo tiekėjų ir savo pačių inventoriaus, kaip šie komponentai naudojami, tvarkymą. Praktiškai dauguma organizacijų vienu metu yra ir teikėjos, ir diegėjos, o tai reiškia, kad AI-BOM nuosavybė turi būti aiškiai priskirta saugumo, inžinerijos ir atitikties komandoms, o ne palikta bendrai atsakomybei.
