SBOM деген не және компанияға неге қажет

SBOM (Software Bill of Materials, «бағдарламалық жасақтама спецификациясы») — қосымша жиналған компоненттердің тізбесі: кітапханалар, олардың нұсқалары, жеткізушілер, лицензиялар және тәуелділіктер. CISA оны құрамдас бөліктер тізіміне теңейді. Компанияға SBOM «жаңа осалдық бізге қатысты ма» деген сұраққа бірнеше минутта жауап беру және бағдарламалық жасақтама жеткізушілерінен ашықтық талап ету үшін қажет.

SBOM туралы неге бәрі айта бастады

Заманауи қосымша дерлік әрқашан көптеген open-source компонентті қамтиды, оның көбі жинаққа тікелей емес, транзитивті тәуелділік ретінде түседі. Танымал кітапханадан сыни осалдық табылғанда, бірінші сұрақ: «бізде бар ма және қайда?». SBOM болмаса, жауапты қолмен күндер бойы іздейді; SBOM болса, инвентарь бойынша іздеу жүргізеді.

Көрнекі мысал — Log4Shell (CVE-2021-44228): Log4j кітапханасы әртүрлі вендорлардың өнімдерінде қолданылады, ұйымдар оның нақты қайда бар екенін шұғыл анықтауға мәжбүр болды. Бұл тәуекел туралы толығырақ бағдарламалық жасақтама жеткізу тізбегіне шабуылдар материалында.

Жеткізу тізбегіне жасалған шабуылдардан кейін SBOM-ға қойылатын талаптар реттеуде пайда бола бастады. АҚШ Президентінің 2021 жылғы 12 мамырда қол қойылған 14028 «Improving the Nation's Cybersecurity» Жарлығы бағдарламалық жасақтама жеткізу тізбегінің қауіпсіздігін жеке бөлімге бөліп, SBOM-ның ең аз элементтерін анықтау міндетін қойды; 2021 жылғы шілдеде NTIA «The Minimum Elements For a Software Bill of Materials» есебін жариялады. АҚШ-тың нормативтік талаптары Орталық Азия елдерінде тікелей қолданылмайды, бірақ SBOM-ды халықаралық вендорлар, ірі тапсырыс берушілер және банктер жиі сұрайтын болды.

SBOM құрамына не кіреді

• Әр компоненттің атауы мен нұсқасы
• Жеткізуші немесе автор
• Бірегей идентификаторлар (purl, CPE) және хэштер
• Тәуелділік байланыстары, транзитивтілерін қоса
• Лицензиялар

Деректер неғұрлым толық болса, осалдықтар базаларымен салыстыру соғұрлым дәл болады. Нұсқалары мен идентификаторлары жоқ SBOM автоматты талдау үшін пайдасыз.

Форматтар: CycloneDX және SPDX

Екі негізгі ашық стандарт — CycloneDX және SPDX.

• CycloneDX: OWASP Foundation және Ecma International әзірлейді; ECMA-424 стандарты ретінде бекітілген (2025 жылғы 10 желтоқсанда жарияланған). SBOM-нан бөлек SaaSBOM және HBOM-ды сипаттайды, форматтары — JSON, XML және Protobuf. Тарихи тұрғыдан қауіпсіздікке бағытталған.
• SPDX: Linux Foundation жобасы, ISO/IEC 5962:2021 халықаралық стандарты. Шығу тегін, лицензияларды және қауіпсіздік деректерін сипаттайды; дәстүрлі түрде лицензиялық комплаенсте күшті.

Құралдардың көпшілігі екі форматпен де жұмыс істей алады, сондықтан тапсырыс берушілеріңіз сұрайтын форматты таңдаңыз, ал ең дұрысы — екеуін де бере біліңіз.

SBOM-ды қалай жасау керек

Қолмен жасау жарамайды: тәуелділіктер әр жинақпен өзгереді. SBOM CI/CD-де SCA класындағы құралдармен автоматты түрде жасалады. Мысалы, Sonatype Lifecycle және SBOM Manager әр жинақта SBOM жасайды, компоненттерді осалдықтар базасымен және компания саясаттарымен салыстырады, өнімнің барлық нұсқасына арналған SBOM-ды сақтауға мүмкіндік береді. Таңдау үшін балама шешімдердің шолуы SCA-шешімдерін салыстыру мақаласында.

Жасаудың практикалық ережелері:

• SBOM-ды репозиторий бойынша «артынан» емес, жинау кезеңінде жасаңыз, сонда оған артефактілердің нақты нұсқалары түседі.
• Әр релиз үшін SBOM сақтаңыз: осалдық баяғыда продакшнда тұрған нұсқадан табылуы мүмкін.
• SBOM-ды осалдықтар базасымен бір рет емес, үздіксіз салыстырыңыз: жаңа CVE релизден кейін де пайда болады.

SBOM-ды қауіпсіздік үшін қалай пайдалану керек

1. Жаңа CVE-ге жауап беру: зардап шеккен қосымшаларды лезде іздеу.
2. Саясаттар: сыни осалдықтары бар немесе тыйым салынған лицензиялы компоненттерге тыйым салу.
3. Бағдарламалық жасақтаманы қабылдау: мердігерлер мен вендорлардан SBOM талап етіңіз.
4. Аудит және комплаенс: жеткізу тізбегі бақыланатынының дәлелі.

CISA SBOM-ның VEX-пен жұптасып жұмыс істейтінін атап өтеді: VEX — нақты өнімнің белгілі осалдыққа қатысы бар-жоғы туралы мәлімдеме. Бұл сіздің өніміңізде қолжетімсіз компоненттердің осалдықтарын сүзіп тастауға және бос тикеттерге уақыт жоғалтпауға көмектеседі. SBOM-ды AppSec құралдарының басқа кластарымен үйлестірген де ыңғайлы: SCA құрамға, ал SAST пен DAST өз кодыңа және қосымшаның жұмысына жауап береді.

Frontend үшін SBOM

Жеке соқыр аймақ — браузерде сыртқы CDN-дерден жүктелетін клиенттік JavaScript. Жинау кезінде құрылған классикалық SBOM оны көрмейді: скрипт рантаймда қосылады. Осы үшін Frontend SBOM бар, оны, мысалы, DPA FAST Analyzer жасайды.

SBOM-мен жұмыстағы типтік қателер

• «Тік қою үшін» жасалған SBOM. Файлды аудитке бір рет жасап, ұмытып кетеді. Ескірген SBOM оның болмауынан да қауіпті: ол бақылау бар деген жалған сезім тудырады.
• Тек тікелей тәуелділіктер. Мәселелердің көбі транзитивті компоненттер арқылы келеді, сондықтан тәуелділік байланыстары жоқ SBOM аз ақпарат береді.
• Әрекет ету процесі жоқ. Инвентарьдің өзі осалдықтарды жаппайды: қосымша иелері, түзету мерзімдері және осал кодтың нақты қолжетімділігі бойынша басымдық қою қажет.
• Әртүрлі командаларда әртүрлі форматтар. Әр команда SBOM-ды өзінше жасаса, деректерді бір бейнеге жинау мүмкін емес. Формат пен сақтау орнын келісіп алыңыз.
• Контейнерлер мен образдарды елемеу. Операциялық жүйе мен базалық образдардың компоненттері де жеткізілетін өнім құрамына кіреді.

SBOM енгізуді неден бастау керек

Барлық қосымшаны бірден қамтудың қажеті жоқ. Практикалық әрекет тәртібі:

1. Бірнеше маңызды қосымшаны таңдап, олардың жинағында SBOM-ды автоматты жасауды қосыңыз.
2. Форматты (CycloneDX, SPDX немесе екеуі де) және АҚ қызметіне қолжетімді сақтау орнын келісіңіз.
3. Осалдықтар базасымен салыстыруды қосып, жаңа олжалар туралы хабарландыруларды бапталыңыз.
4. Саясаттарды анықтаңыз: қандай осалдықтар мен лицензиялар жол берілмейді және ерекшеліктер туралы шешімді кім қабылдайды.
5. Шарттарға және мердігерлерден бағдарламалық жасақтаманы қабылдау процесіне SBOM талабын қосыңыз.
6. Қамтуды қалған қосымшалар мен контейнер образдарына біртіндеп кеңейтіңіз.

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

SBOM және жеткізу тізбегі

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

SBOM-ға кім иелік етуі керек

Формалды түрде SBOM автоматты жасалады, бірақ оның иесі болуы тиіс. Әдетте бұл АҚ қызметі немесе әзірлеу платформасының командасы: олар формат, сақтау орны және саясаттарды анықтайды, ал өнім командалары өз қосымшаларындағы олжаларды түзетуге жауап береді. Жауапкершілікті нақты бөлу маңызды: онсыз SBOM қоймада жинала береді, бірақ ешкім хабарландыруларға әрекет етпейді. SBOM-ды сыртқа, яғни тапсырыс берушілерге, реттеушілерге, серіктестерге кімге және қандай түрде беретінін, оның ішінде қандай деректерді ашуға болатынын алдын ала шешкен де пайдалы.

Практикалық мысал: жаңа CVE шыққанда не істеу керек

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

1. АҚ қызметі барлық сақталған SBOM бойынша осал компонент пен нұсқаны іздеп, зардап шеккен қосымшалар мен релиздер тізімін алады.
2. Тізім маңыздылығы бойынша сараланады: интернет-сервистер мен құпия деректері бар жүйелер бірінші болады.
3. Әр қосымша үшін осал кодтың қолжетімді-қолжетімсіздігі анықталады; мұнда «зардап шеккен / шекпеген» VEX-мәртебесі көмектеседі.
4. Иелері көшу керек нұсқасы мен түзету мерзімі көрсетілген тапсырмалар алады.
5. Жаңа жинақ саясат арқылы тексеріледі: осал нұсқалы компонент релизге енді өтпейді.

«Бірнеше күн іздедік» пен «бірнеше минутта тізім алдық» арасындағы айырма осалдықты шабуылдаушылардан бұрын жаба алатын-алмайтыныңызды жиі айқындайды.

Жиі қойылатын сұрақтар

Дереккөздер

• CISA: Software Bill of Materials (SBOM)
• CycloneDX: Specification Overview
• SPDX: About the specification
• CISA: Apache Log4j Vulnerability Guidance