Әр релиздік жинаққа LLM-шлюзге арналған SBOM қажет

LLM-шлюзді көбіне жұқа HTTP сервисі деп қабылдайды: ол сұрауды қабылдап, модельді таңдап, жауапты қайтарады. Production ортасында бұл тәуелділіктері ең көп компоненттердің бірі. Шлюз сыртқы трафикті қабылдайды, провайдер кілттерін сақтайды, JSON талдайды, аудит жүргізеді, PII маскировкасын қолданады, кезектермен, дерекқорлармен, SDK және контейнерлік платформамен жұмыс істейді. Осы тізбектің кез келген бөлігіндегі қате модельге жасалған әр шақыруға әсер етуі мүмкін.

Сондықтан LLM-шлюзге арналған SBOM аудит үшін жасалған жай ғана бума емес. Ол бірнеше минут ішінде мына жағымсыз сұраққа жауап беруі керек: «Қазір сұрауларды нақты қай жинақ өңдеп жатыр, ол неден тұрады, тағы қай жерде іске қосылған және оны қалай тоқтатуға болады?» Егер жауаптың орнына команда бірнеше репозиторийді ашып, registry ішінен тег іздеп, кластерге қай образ түскенін талқыласа, оның SBOM-ы тек қағаз жүзінде бар.

SBOM команда ниетін емес, релиз құрамын бекітеді

SBOM әзірлеушілер орнатқысы келген нәрсені емес, сіз нақты орнатқан нәрсені сипаттауы керек. Онда компонент идентификаторы, нұсқасы, дереккөзі, хеші немесе тұтастықты тексерудің басқа тәсілі, лицензиясы, басқа компоненттермен байланысы және релиздің өзі туралы мәліметтер болуы қажет.

SPDX SBOM-ды бір пакетті сипаттайтын элементтер жиыны ретінде анықтайды және құрамды, шығу тегін, лицензияларды, сапа немесе қауіпсіздік мәселелері туралы ақпаратты беруге мүмкіндік береді. Спецификацияда элементтер арасындағы байланыстар сәндік өріс емес, модельдің бір бөлігі. Бұл шлюз үшін маңызды: кітапхана образға тікелей, провайдердің SDK-сы арқылы немесе базалық қабаттағы жүйелік пакет ретінде түсуі мүмкін.

Көп команда мұны жеңілдетеді: бастапқы каталогтан JSON жасап, оны релизге тіркейді де, тапсырма аяқталды деп санайды. Мұндай файл multi-stage build қандай тәуелділіктерді алып тастағанын, базалық образ қандай жүйелік пакеттерді әкелгенін, орнату скрипті қандай бинарлық файл қосқанын және соңғы қабатқа шын мәнінде не түскенін білмейді. Ол әзірлеушіге ерте белгі ретінде пайдалы, бірақ жұмыс істеп тұрған образды қайтарып алу туралы шешім қабылдауға жарамайды.

«Құрам» деп жиі аталатын төрт нәрсені ажыратыңыз:

• lock-файл тіл экожүйесінде тәуелділіктердің шешілген нұсқаларын бекітеді;
• бастапқы кодтың SBOM-ы жинаққа дейінгі тәуелділіктер ағашын сипаттайды;
• контейнер SBOM-ы жеткізілетін образдың құрамын сипаттайды;
• provenance образды бастапқы ревизиямен, ортамен және жинақ процесімен байланыстырады.

Бұл артефактілерді шатастырсаңыз, команда жалған сенімге ие болады. Мысалы, requirements.txt ұқыпты болуы мүмкін, бірақ соңғы образда базалық дистрибутивтен келген ескірген openssl бар. Немесе репозиторий сканері кітапхананы тест тәуелділігі ретінде көріп, production образына кірмесе де релизді бұғаттайды.

LLM-шлюздің құрамы lock-файлдан кең

LLM-шлюз үшін бақылау бірлігі бір репозиторий емес, сұрауды орындайтын жол болуы керек. Құрам картасына сұрауларды қабылдауға, өңдеуге, бағыттауға және журналдауға қатысатын компоненттер кіреді.

Алдымен сервистің соңғы образынан бастаңыз. Оның ішінде әдетте тіл runtime-ы, HTTP сервері, TLS кітапханалары, JSON парсері, клиенттік SDK, токенизация кітапханалары, сақтау жүйелерінің драйверлері, телеметрия агенті және жүйелік пакеттер болады. Егер шлюз жергілікті модельдерді қолдаса, тізімге инференс серверін, CUDA немесе басқа жеделдету кітапханаларын, салмақтарды жүктеу құралдарын және модель артефактілерінің өзін қосыңыз.

Содан кейін көршілес артефактілерді қосыңыз, бірақ бәрін пішінсіз бір құжатқа біріктірмеңіз. Мыналарды бөлек жүргізіңіз:

• шлюздің өз образы;
• асинхронды тапсырмаларды өңдейтін болса, worker образы;
• командаңыз шығаратын proxy немесе adapter образы;
• іске қосылған кезде жүктелетін кеңейту пакеті;
• жергілікті модельдің салмақтар файлы мен конфигурациясы.

Модель салмақтарының файлы Python кітапханасы емес, ал токенизатор контейнерге тең емес. Олардың бәріне ұқсас тәртіп қажет: өзгермейтін идентификатор, криптографиялық хеш, дереккөз, лицензия, рұқсат беру процедурасы және иесі. Бірақ модельдерді бөлек түгендеу гигабайттық артефактіні кәдімгі пакет SBOM-ына жасырудан пайдалырақ. Әйтпесе «дүйсенбіде салмақтардың қай нұсқасы жұмыс істеді?» деген сұраққа apk және pip пакеттерінің ұзын тізімін көресіз де, жауап ала алмайсыз.

Шабуыл бетін өзгертетін конфигурацияны да ұмытпаңыз. SBOM ішіне әдетте құпиялар, толық URL мекенжайлары және ережелердің мазмұны жазылмайды. Бірақ релиз конфигурация схемасының нұсқасына және қауіпсіз конфигурация пакетінің digest-іне сілтеме жасауы керек. Бұл TLS тексерісі өшірілген күйде іске қосылған образды дұрыс бапталған дәл сол образдан ажыратуға мүмкіндік береді. Құпиялар мен жеке деректер SBOM-ға ешқашан кірмейді.

Жинақты қайталап құруға болатындай нұсқаларды бекіту керек

Образ тегі, кітапхананың өзгермелі нұсқасы және желіден скрипт жүктеу релизді қайталанбайтын етеді. Кеше бір байттарды пайдаланған жинақ ертең сол атаумен басқа байттарды жинауы мүмкін. Провайдер кілттері мен сыртқы трафигі бар шлюз үшін бұл дұрыс таңдау емес.

Тәуелділіктерді үш деңгейде бекітіңіз. Тіл деңгейінде, экожүйе қолдайтын болса, артефакт хештері бар lock-файлды пайдаланыңыз. Контейнер деңгейінде базалық образды digest арқылы көрсетіңіз. CI деңгейінде SBOM генераторының, сканердің, жинақ образының және пайплайн іске қосатын әрекеттерінің нұсқаларын бекітіңіз.

Нашар Dockerfile мынадай болады:

FROM python:3.12-slim
RUN pip install openai fastapi uvicorn
COPY . /app

Ол образға нақты қай Python және қандай wheel файлдары түскенін көрсетпейді. Тегтер өзгереді, ал pip install тәуелділіктерді жинақ кезінде шешеді. Қолданба бірдей жұмыс істегенімен, инцидентті тергеу сыртқы репозиторийлер журналдары бойынша өткенді қайта құруға айналады.

Production жинағының ең аз дегендегі қағидасы басқаша көрінеді:

FROM registry.example/base/python@sha256:<бекітілген-digest>
WORKDIR /app
COPY requirements.lock ./
RUN pip install --require-hashes -r requirements.lock
COPY . ./

Мұндағы placeholder дайын конфигурация емес. Команда тексерілген ішкі registry-ден алынған нақты digest мәнін қойып, оны бақыланатын pull request арқылы жаңартуы керек. --require-hashes жүктелген пакет рұқсат етілген мазмұнмен сәйкес келмесе, орнатуды тоқтатады. Ол осалдықтарды тексеруді алмастырмайды, бірақ таныс нұсқа атауының астында артефактіні байқатпай ауыстыруға жол бермейді.

«Күн сайын бәрін жаңартыңыз» деген кеңес қауіпсіз естілгенімен, басқаруды қиындатады. Жаңартуға арналған автоматты pull request жасауға болады. Ал өзгерістерді бағаламай, production ортасына тәуелділіктердің жаңа жиынтығын автоматты түрде шығару басқа тәуекел туғызады: маршрутизация қатесіне, кідірістің өсуіне немесе SDK үйлесімсіздігіне қандай өзгеріс себеп болғанын білмей қаласыз. Жаңарту із қалдыруы керек: бастапқы ревизия, ескі және жаңа digest, SBOM айырмашылығы, тест нәтижелері және релиз туралы шешім.

Бір репозиторийге арналған SBOM образ туралы сұраққа жауап бермейді

SBOM-ды соңғы образ жиналғаннан кейін жасап, оны өзгермейтін digest-пен байланыстырыңыз. CVE пайда болғанда кезекші инженерге, аудит кезінде аудиторға және кластерге іске қосар алдында рұқсат беретін контроллерге дәл осы файл қажет.

Syft образдар мен файлдық жүйелер үшін SBOM жасап, SPDX және CycloneDX форматтарына шығара алады. Практикада алдымен сканерлеріңіз бен қоймаңыз өңдей алатын бір форматтан бастаған дұрыс, екіншісін тұтынушы талап етсе ғана қосыңыз. Құралдың өзі де осындай сценарийді көрсетеді: бір образдан SPDX JSON және CycloneDX JSON жасайды.

Жергілікті тексеруге арналған мысал:

IMAGE=registry.example/llm-router@sha256:<digest>
syft "$IMAGE" -o spdx-json=sbom.spdx.json
sha256sum sbom.spdx.json

Екінші команданың күтілетін шығысы мынадай:

8f1c...c92a  sbom.spdx.json

Бұл хешті образ digest-імен бірге сақтаңыз. JSON CI артефактілерінде тұрғаны үшін ғана өзгермейтін болып саналмайды: көптеген жүйе оларды сақтау мерзімі біткенде жояды, ал кейбірі сол атаумен файлды ауыстыруға мүмкіндік береді. Қойма релиз артефактілерін шығарылымды қолдауға немесе тергеуге міндетті болған мерзім бойы сақтауы керек.

CI ішіне SBOM дәл тегтен емес, digest-тен алынғанын тексеруді қосыңыз. Мысалы, пайплайн registry.example/llm-router:build-482 образын жинады делік. Алдымен ол образды жариялайды, кейін registry-ден оның content digest мәнін алады, тек содан соң @sha256:... адресі бойынша SBOM жасайды. Генератор тегті оқыса, параллель push сканерлеуге дейін мазмұнды өзгертуі мүмкін. Мұндай жарыс жағдайы алғашқы инцидентке дейін сирек көрінеді, ал одан кейін өте қолайсыз болады.

Бастапқы код үшін екінші, көмекші SBOM шығаруға болады. Ол контейнер жиналғанға дейін тәуекелдерді табуға және pull request ішіндегі өзгерістерді салыстыруға көмектеседі. Оны, мысалы, source-sbom деп нақты атаңыз да, релиз образының SBOM-ы ретінде қолданбаңыз.

Сканер белгілі нәрсені табады, ал шешімді саясат қабылдайды

Сканер компоненттерді белгілі осалдықтар базасымен салыстырады. Ол сіздің деректер ағыныңызды түсінбейді, кодтың желі арқылы қолжетімді екенін білмейді және релизді тоқтату керек пе, жоқ па деген шешімді өздігінен қабылдай алмайды. Сондықтан «кез келген CVE бәрін бұғаттайды» деген ереже тез арада жалған дабылдар кезегіне айналады, ал «кейін қараймыз» деген ереже қауіпті жинақтардың айлар бойы жұмыс істеуіне мүмкіндік береді.

NIST SSDF қауіпсіздік тәжірибелерін әзірлеу цикліне енгізуді ұсынады. Бұл шығарылған бағдарламалық жасақтамадағы осалдықтар санын азайтып, жойылмаған мәселелердің салдарын төмендетуге және олардың қайталану себептерін жоюға көмектеседі. Бұл бір сканер орнату туралы нұсқаулық емес. Сканер нәтижесіне иесі мен нақты әрекеті бекітілетін процеске қойылатын талап.

LLM-шлюз саясаты табылған мәселенің кемінде мына төрт қасиетін ескеруі керек:

• түзетілген нұсқасы бар ма және API өзгермей жаңартуға бола ма;
• компонент соңғы образда бар ма;
• осал кодқа сыртқы сұраулар, әкімшілік интерфейс немесе файл өңдеу арқылы қол жеткізуге бола ма;
• мәселе құпияларға, tenant оқшаулауына, аудитке немесе код орындалуына әсер ете ме.

Қалыпты ақауды қарастырайық. Сканер базалық образдағы архив кітапханасынан осалдық тапты. Команда «шлюз архив қабылдамайды» деп ерекшелік қосады. Екі аптадан кейін команда пакеттік тапсырмаларды жүктеуге арналған endpoint қосады, кітапхана кіріс ZIP файлын өңдей бастайды, ал ерекшелік сол күйі қалады. Мұнда мәңгілік ignore белгісі емес, себебі, иесі, қайта қарау мерзімі және жою шарты бар жазба керек. Мысалы: «production endpoint архив қабылдамай тұрған кезде ғана ерекшелікке рұқсат етіледі».

Басқа шектен шығу да қауіпті. CI пайдаланылмайтын пакеттегі осалдықтан құлап, ешкім түзетуді шығара алмаса, инженерлер сканерді түгел өшіре бастайды. Шектерді бөліңіз: қолжетімді production компонентіндегі сыни немесе жоғары деңгейлі мәселе кезінде релизді бұғаттаңыз, қалғандары үшін нақты шешім талап етіңіз, ал ерекшеліктерді қайта қарауға автоматты түрде қайтарыңыз. Саясаттың иесі қауіпсіздік қызметіндегі аты-жөні жоқ кесте емес, инженерлік командадан тағайындалған адам болуы керек.

Контейнерді дайын орындалатын артефакт ретінде тексеру керек

Репозиторийді сканерлеу контейнерді сканерлеуді алмастырмайды. Соңғы образ ескі жүйелік пакеттерді мұраға алуы, кездейсоқ көшірілген конфигурация файлын қамтуы, shell утилиталарын, жөндеу серверін немесе қолданбаның бастапқы кодында жоқ бинарлық файлды қосуы мүмкін.

Тексеру жинақтаушы соңғы образды қалыптастырғаннан кейін және осы digest деплойға үміткер болғанға дейін орындалуы керек. Сканерлеу есебін SBOM сияқты дәл сол digest-пен байланыстырыңыз. Сканер SBOM оқи алса, бұл ыңғайлы: осалдықтар базасы жаңартылғаннан кейін ескі образды қайта құрусыз қайта сканерлеуге болады. Бірақ енгізер алдында генератор, формат және сканер нұсқаларының үйлесімділігін тест пайплайнында тексеріңіз. Бір экожүйедегі құралдардың өзі кейде формат қолдауын синхронды өзгертпейді.

Рұқсат берудің орынды ережелерінің бірі мынадай:

1. CI бекітілген кіріс артефактілерінен образ жинап, оны digest арқылы жариялайды.
2. Генератор SBOM-ды дәл осы digest үшін жасайды, содан кейін қойма екі файлды бір релиз жиынтығы ретінде қабылдайды.
3. Сканер образды немесе SBOM-ды өзекті база бойынша тексереді, ал саясат әрі қарай жалғастыруға болатынын шешеді.
4. Пайплайн образға және жинақ туралы деректерге қолтаңбаны тексерулер сәтті аяқталғаннан кейін қояды.
5. Іске қосу ортасы тек сенімді қолтаңбасы және бекітілген мәртебесі бар digest-ті қабылдайды.

Бұл тексеріске промпттардың мазмұнын, модель жауаптарын немесе API кілттерін қоспаңыз. Олар жеткізу компоненттері емес және SBOM-ға да, сканер есебіне де кірмеуі керек. Мұндай деректерге маскировка, журналдау саясаты, қолжетімділікті шектеу және сақтау мерзімі сияқты бөлек шаралар қажет.

Қолтаңба SBOM-ды нақты жинақпен байланыстырады

Образбен байланысы жоқ SBOM-ды ауыстыру немесе шатастыру оңай. sbom.json атауы бірдей екі файлдың бірінің екіншісіне қатысты екенін дәлелдейтін күші жоқ. Тексерілетін тізбек қажет: бастапқы ревизия жинаққа әкелді, жинақ digest-і бар образ шығарды, ал бұл образға нақты SBOM мен сканерлеу есебі берілді.

SLSA provenance-ті артефактінің қайда, қашан және қалай жасалғаны туралы дерек ретінде пайдаланады. Практикалық мағынасы терминнен қарапайым: инциденттен кейін сенімді пайплайн күтілетін ревизиядан жинаған образды біреудің жергілікті жерде жинап, ұқсас тегпен жүктеген образынан ажырата алуыңыз керек.

Қолтаңба авторлық пен тұтастық мәселесін іске қосу ортасы оны тексергенде ғана шешеді. CI ішінде образға қол қойып, кластерге registry-ден кез келген тегті жүктеуге рұқсат беру мағынасыз. Рұқсат контроллері немесе басқа деплой механизмі кемінде мыналарды салыстыруы керек:

• образ өзгермелі тегпен емес, digest арқылы көрсетілген;
• digest-ке сенімді шығарушы қол қойған;
• аттестация дәл осы digest-ке қатысты;
• provenance рұқсат етілген репозиторий мен ревизияны көрсетеді;
• осалдықтар мәртебесі іске қосуға тыйым салмайды.

Манифесттегі version өрісіне digest-тен артық сенбеңіз. Нұсқа адамға түсінікті болу үшін керек, digest автоматтандыруға қажет. Жақсы релиз жазбасында екеуі де болады: 2026.07.23.4 сияқты түсінікті атау және мазмұнның өзгермейтін идентификаторы. Команда қолтаңбадан кейін тегті қолмен өзгертсе, бұрынғы қолтаңбаны «қайта тағайындауға» тырыспай, жаңа релиз жиынтығын жасауы керек.

Жинақты қайтарып алу түнгі инцидент кезінде де жұмыс істеуі керек

Қайтарып алуды registry ішінен тегті жоюмен шектеуге болмайды. Жұмыс істеп тұрған pod образды әлдеқашан жүктеп алды. Автоскейлер ескі нұсқаны ұстап тұруы мүмкін. Инженердің жергілікті көшірмесі қалуы ықтимал. Басқа кластер digest-ті тікелей пайдалануы мүмкін. Инцидент кезінде сізге релиздің таралуы туралы деректер және алдын ала бекітілген әрекеттер реті қажет.

Процедура идентификациядан басталады. Кезекші CVE, провайдердің қатесі немесе бұзылу туралы хабарлама алады. Ол SBOM бойынша зардап шеккен компонентті табады, осы компоненті бар образдардың тізімін, содан кейін digest бойынша деплойлардың тізімін алады. Егер SBOM-нан компонент атауы мен нұсқасы бойынша іздеу мүмкін болмаса, сіз жұмыс құралы емес, архив сақтап отырсыз.

Әрі қарай алдын ала тағайындалған релиз иесі әрекет етеді. Ол үш шешімнің бірін қабылдайды: трафик жолын уақытша шектеу, образды түзетілген нұсқаға ауыстыру немесе сервисті тоқтату. Шлюз үшін бәрін бірден өшіру қауіпті болуы мүмкін: бизнес процестері авторизацияға, өтініштерді өңдеуге немесе ішкі ассистенттерге тәуелді болуы ықтимал. Бірақ бұл белгілі тәуекелді мерзімсіз қалдыруға себеп емес. Тәуекелді уақытша азайту нақты техникалық әрекетке сүйенуі керек, мысалы, осал endpoint-ті өшіру, тіркемелерді жүктеуге тыйым салу немесе қолжетімділікті тек ішкі желімен шектеу.

Образды ауыстырғаннан кейін тек CI мәртебесін емес, қайтарып алу фактісін тексеріңіз:

• әр кластерде іске қосылған workload ішінде зардап шеккен digest қалмады ма;
• deployment, job немесе cron тапсырмасы ескі нұсқаға сілтемей ме;
• рұқсат саясаты қайтарып алынған digest-ті қайта іске қосуға тосқауыл бола ма;
• registry осы релизді жариялау және деплойлау құқығын беруді тоқтатты ма;
• SBOM, есептер және шешімдер журналы инцидентті талдау үшін сақталды ма.

Мұндағы ең жиі кездесетін олқылық техникалық емес, ұйымдастырушылық сипатта болады. Иелердің тізімі, байланыс арнасы және релизді тоқтату құқығы болмаса, кезекші осал шлюз трафик қабылдап тұрған кезде келісім жинай береді. Қауіпсіз тест digest-інде оқу-жаттығу ретінде қайтарып алуды өткізіңіз. Адамдардың уақытын өлшеудің қажеті жоқ. Оның орнына registry-ге кіру мүмкіндігі жоқ екенін, екінші кластер көрінбейтінін немесе рұқсат саясаты тек тегтерді тексеретінін анықтау керек.

Чеклист релиздің шартына айналуы керек

SBOM оны шығару және тексеру қалыпты релиз жолына кіргенде ғана жұмыс істейді. Тоқсанына бір рет орындалатын бөлек тапсырма шұғыл түзетуден, модель миграциясынан және өнім дедлайнынан әрқашан жеңіледі.

LLM-шлюзді мына тізім бойынша тексеріңіз:

• Әр production жинағында immutable digest, соңғы образдың SBOM-ы, сканерлеу есебі және бастапқы ревизия туралы жазба бар.
• Lock-файлдар мен базалық образдар бекітілген, ал CI өзгермелі нұсқалармен тексерілмеген тәуелділіктерді жүктемейді.
• Сканерлеу саясаты пакеттің бар-жоғын, қолжетімділікті, ауырлық деңгейін, түзетуді және уақытша ерекшелікті ажыратады.
• Registry мен кластер қолтаңбасы жоқ немесе қайтарып алынған digest-ті қолмен іске қосуға рұқсат бермейді.
• Команда компонент бойынша барлық зардап шеккен релиздерді, ал релиз бойынша барлық белсенді деплойларды таба алады.

SPDX құрам, шығу тегі және лицензиялар үшін ортақ тіл ұсынатындықтан пайдалы, ал NIST SSDF қауіпсіздікті инженерлік процеске енгізуді талап ететіндіктен маңызды. Бірақ ешбір стандарт пен сканер шешім қабылдау тізбегін сіздің орныңызға құрмайды.

AI Router жүйесінде мұндай бақылау сыртқы провайдерлер мен өз модельдері арасында сұрауларды бағыттайтын шлюздер үшін аса орынды: релиз құрамын, деректерді өңдеу шекараларын және өзгерістер тарихын кейіннен қалпына келтіру мүмкін емес. Жаңа сканер сатып алудан емес, бүгін digest, SBOM, есеп және жұмыс істейтін қайтарып алу процедурасымен байланыстыра алатын бір образдан бастаңыз. Егер мұны бір жұмыс күнінде жасау мүмкін болмаса, келесі инцидент оның себебін тым анық көрсетеді.