Объекты критической информационной инфраструктуры характеризуются высокой значимостью для функционирования государства, экономики, промышленности и социальной сферы. Нарушение работы таких объектов может привести к существенным последствиям, включая остановку технологических процессов, нарушение предоставления критически важных услуг, экономический ущерб и угрозу безопасности персонала.

Одним из факторов риска в современных информационных системах является широкое использование сторонних программных компонентов. При разработке корпоративных приложений, промышленных сервисов, средств мониторинга, внутренних порталов и аналитических систем активно применяются open-source-библиотеки, фреймворки и контейнерные образы. Такой подход позволяет ускорить разработку, снизить стоимость внедрения и использовать уже проверенные программные решения. Вместе с тем он усложняет контроль безопасности, поскольку итоговый программный продукт может включать десятки или сотни прямых и транзитивных зависимостей.

Особую значимость проблема приобретает в системах критической информационной инфраструктуры. Для таких систем недостаточно знать только факт наличия уязвимости в программном обеспечении. Необходимо понимать, какой компонент уязвим, в каком программном продукте он используется, на каком активе развернут, влияет ли он на критический процесс, существуют ли публичные эксплойты и какие компенсирующие меры уже применяются. Без формализованного учета состава программного обеспечения такая оценка становится затруднительной и часто выполняется вручную.

Традиционный подход к управлению уязвимостями основан на регулярном сканировании инфраструктуры, анализе результатов средств SCA и сопоставлении выявленных компонентов с базами известных уязвимостей. Однако данный подход имеет ряд ограничений:

— неполная видимость транзитивных зависимостей;

— сложность определения распространенности уязвимого компонента в инфраструктуре;

— отсутствие единого описания состава программного обеспечения;

— затрудненная оценка влияния уязвимости на критические бизнес- и технологические процессы;

— зависимость от качества данных, предоставляемых разработчиками, подрядчиками и поставщиками.

Для устранения указанных ограничений может применяться Software Bill of Materials — формализованная ведомость состава программного обеспечения. SBOM представляет собой структурированное описание компонентов программного продукта, включая наименование, версию, поставщика, тип компонента, сведения о лицензии, контрольные суммы, связи между зависимостями и иные атрибуты, необходимые для анализа безопасности.

Использование SBOM позволяет перейти от реактивного подхода к управлению уязвимостями к проактивной модели, при которой организация заранее обладает информацией о составе используемого программного обеспечения и может быстро определить, затрагивает ли новая уязвимость ее инфраструктуру.

В системах КИИ SBOM может применяться для решения следующих задач:

1. Инвентаризация open-source-компонентов в прикладных системах;
2. Контроль прямых и транзитивных зависимостей;
3. Оценка влияния уязвимостей на критически значимые активы;
4. Приоритизация мероприятий по устранению уязвимостей;
5. Контроль лицензионных и регуляторных рисков;
6. Повышение прозрачности цепочки поставки программного обеспечения;
7. Интеграция процессов безопасной разработки и управления рисками.

Особенно важным является применение SBOM в организациях, где одновременно используются собственная разработка, заказная разработка, коммерческие программные продукты и open-source-компоненты. В таких условиях единая модель учета состава программного обеспечения позволяет унифицировать процессы анализа рисков и реагирования на уязвимости.

Предлагаемая методика применения SBOM для управления рисками open-source-компонентов в системах КИИ включает несколько последовательных этапов.

Первый этап — определение области применения SBOM. На данном этапе организация формирует перечень программных продуктов, информационных систем и сервисов, для которых требуется ведение ведомости программных компонентов. В первую очередь в область применения должны включаться системы, связанные с критическими процессами, обработкой значимой информации, межсегментным взаимодействием, удаленным доступом и интеграцией с технологическими контурами.

Второй этап — формирование SBOM. Для программных продуктов собственной разработки SBOM целесообразно формировать автоматически в контуре DevSecOps на этапах сборки, тестирования и выпуска релиза. Для программных продуктов поставщиков SBOM может запрашиваться в рамках процедур закупки, приемки и сопровождения. Для уже эксплуатируемых систем возможно использование инструментов Software Composition Analysis, анализа контейнерных образов и репозиториев зависимостей.

Третий этап — нормализация и проверка качества SBOM. Полученные данные должны приводиться к единому формату, проверяться на полноту и актуальность. Важными признаками качества SBOM являются наличие версий компонентов, корректное указание зависимостей, наличие контрольных сумм, описание лицензий и возможность машинной обработки.

Четвертый этап — сопоставление компонентов с источниками информации об уязвимостях. На данном этапе сведения из SBOM сопоставляются с базами известных уязвимостей, результатами SCA-анализа, внутренними реестрами исключений и данными о фактической эксплуатации компонентов. При этом важно учитывать не только наличие уязвимости, но и контекст ее использования.

Пятый этап — оценка риска open-source-компонента. Для систем КИИ оценка риска должна учитывать не только техническую опасность уязвимости, но и критичность программного продукта, расположение актива в архитектуре, доступность уязвимого компонента для эксплуатации и наличие компенсирующих мер.

Предлагается использовать интегральный показатель риска open-source-компонента R, рассчитываемый на основе нескольких параметров:

R = V × E × A × K × M,

где:

V — нормализованная техническая опасность уязвимости;

E — вероятность эксплуатации уязвимости;

A — доступность уязвимого компонента для потенциального нарушителя;

K — критичность актива или системы, в которой используется компонент;

M — коэффициент, отражающий наличие или отсутствие компенсирующих мер.

Показатель V может определяться на основе CVSS или иных технических метрик. Для приведения значения к диапазону от 0 до 1 балл CVSS может быть разделен на 10.

Показатель E отражает вероятность практической эксплуатации уязвимости. Он может учитывать наличие публичного эксплойта, сведения об активной эксплуатации, сложность атаки, доступность технических описаний и актуальность угрозы для конкретной отрасли.

Показатель A характеризует доступность уязвимого компонента. Например, библиотека, используемая во внутреннем модуле без сетевого взаимодействия, имеет меньшую доступность для нарушителя, чем компонент, обрабатывающий внешние HTTP-запросы или данные из недоверенной зоны.

Показатель K отражает критичность системы или актива, в котором используется компонент. В условиях КИИ данный параметр является особенно важным, поскольку одна и та же уязвимость может иметь различное значение в зависимости от роли системы. Уязвимость во вспомогательном сервисе отчетности и уязвимость в компоненте, связанном с управлением технологическим процессом, должны иметь разный управленческий приоритет.

Показатель M позволяет учитывать компенсирующие меры. Если уязвимый компонент изолирован, недоступен из внешних сегментов, контролируется средствами мониторинга и защищен дополнительными механизмами, итоговый риск может быть снижен. При отсутствии компенсирующих мер значение M должно оставаться высоким.

Для практического применения может использоваться следующая шкала:

— R ≥ 0,7 — критический риск;

— 0,4 ≤ R < 0,7 — высокий риск;

— 0,2 ≤ R < 0,4 — средний риск;

— R < 0,2 — низкий риск.

Уязвимости критического риска требуют немедленной реакции. Для них необходимо определить временные компенсирующие меры, оценить возможность обновления компонента, ограничить сетевое взаимодействие, усилить мониторинг и зафиксировать сроки устранения. В отдельных случаях может потребоваться временное отключение функциональности или перевод системы в ограниченный режим эксплуатации.

Уязвимости высокого риска должны устраняться в приоритетном порядке в рамках ближайшего цикла обновлений или регламентных работ. Для таких уязвимостей необходимо назначить ответственных, определить сроки и контролировать выполнение мероприятий.

Уязвимости среднего риска могут устраняться в плановом порядке с учетом технических окон, совместимости обновлений и доступности ресурсов. При этом требуется регулярный пересмотр риска, поскольку вероятность эксплуатации может изменяться при появлении новых эксплойтов или изменении архитектуры системы.

Уязвимости низкого риска могут быть приняты к наблюдению при условии документирования решения и сохранения контроля за изменениями контекста угроз.

Рассмотрим пример применения предложенной методики.

В программном продукте, используемом в корпоративной инфраструктуре, выявлена open-source-библиотека с известной уязвимостью. Для первого случая библиотека используется во внутреннем сервисе формирования отчетов, не имеющем прямого взаимодействия с технологическим сегментом. Значения параметров определены следующим образом:

V = 0,9;

E = 0,8;

A = 0,4;

K = 0,3;

M = 0,7.

Интегральный показатель риска:

R = 0,9 × 0,8 × 0,4 × 0,3 × 0,7 = 0,06048.

Несмотря на высокий технический балл уязвимости и наличие вероятности эксплуатации, итоговый риск оказывается низким, поскольку компонент используется в некритичном контексте, имеет ограниченную доступность и не оказывает прямого влияния на технологический процесс.

Во втором случае аналогичная уязвимая библиотека применяется в сервисе, обеспечивающем обмен данными между корпоративным и технологическим сегментами. Параметры имеют следующие значения:

V = 0,9;

E = 0,8;

A = 0,8;

K = 0,9;

M = 1,0.

Интегральный показатель риска:

R = 0,9 × 0,8 × 0,8 × 0,9 × 1,0 = 0,5184.

В данном случае уязвимость относится к высокому уровню риска. Основное отличие заключается не в технической характеристике самой уязвимости, а в контексте применения компонента. Использование SBOM позволяет быстро выявить, в каких системах присутствует уязвимая библиотека, а риск-ориентированная модель помогает определить, какие системы требуют первоочередного реагирования.

Таким образом, SBOM становится не просто перечнем зависимостей, а основой для принятия управленческих решений в области информационной безопасности.

Внедрение SBOM в процессы управления рисками open-source-компонентов обеспечивает ряд преимуществ.

Во-первых, повышается прозрачность состава программного обеспечения. Организация получает возможность понимать, какие библиотеки, фреймворки и модули используются в конкретных системах, какие версии применяются и какие зависимости являются транзитивными.

Во-вторых, сокращается время реакции на появление новых уязвимостей. При публикации информации о критической уязвимости специалистам не требуется вручную анализировать все системы. Достаточно выполнить поиск по централизованному хранилищу SBOM и определить затронутые программные продукты.

В-третьих, повышается качество приоритизации. Уязвимости ранжируются не только по техническому баллу, но и с учетом критичности актива, архитектурного контекста и доступности компонента для эксплуатации.

В-четвертых, SBOM способствует развитию процессов DevSecOps. Автоматическое формирование и проверка SBOM может быть встроена в CI/CD-конвейер, что позволяет выявлять нежелательные зависимости и уязвимые версии еще до вывода программного продукта в эксплуатацию.

В-пятых, использование SBOM повышает управляемость цепочки поставки программного обеспечения. Организация может предъявлять требования к поставщикам, контролировать состав поставляемых продуктов и снижать риски, связанные с непрозрачностью сторонних решений.

В-шестых, SBOM может использоваться как источник данных для GRC-платформ, систем управления уязвимостями, средств SCA, SIEM и внутренних реестров активов. Это позволяет связать данные о программных компонентах с данными об активах, владельцах систем, критичности процессов и текущем статусе устранения уязвимостей.

Вместе с тем применение SBOM имеет ряд ограничений.

Во-первых, эффективность подхода зависит от качества исходных данных. Неполный или устаревший SBOM может создавать ложное ощущение контроля и приводить к пропуску значимых уязвимостей.

Во-вторых, требуется регулярная актуализация SBOM. Программные продукты изменяются при обновлениях, установке исправлений, изменении контейнерных образов и подключении новых зависимостей. Поэтому SBOM должен рассматриваться не как разовый документ, а как постоянно обновляемый артефакт жизненного цикла программного обеспечения.

В-третьих, сохраняется проблема транзитивных зависимостей. Некоторые компоненты могут подключаться косвенно через другие библиотеки, что усложняет анализ и требует применения специализированных инструментов.

В-четвертых, необходимо учитывать конфиденциальность информации. SBOM может раскрывать сведения о составе программного обеспечения, версиях библиотек и используемых технологиях. В организациях с объектами КИИ такие данные должны храниться и передаваться с учетом требований информационной безопасности.

В-пятых, автоматическое сопоставление компонентов с базами уязвимостей может приводить к ложноположительным результатам. Не каждая уязвимость в библиотеке является практически эксплуатируемой в конкретном программном продукте. Поэтому результаты автоматизированного анализа должны дополняться экспертной оценкой.

Для эффективного внедрения SBOM в организациях, эксплуатирующих объекты КИИ, целесообразно придерживаться следующих рекомендаций:

— определить перечень систем, для которых ведение SBOM является обязательным;

— закрепить требования к SBOM в процессах разработки, закупки и приемки программного обеспечения;

— использовать единые форматы представления данных, пригодные для машинной обработки;

— интегрировать формирование SBOM в CI/CD и процессы релизного контроля;

— создать централизованное хранилище SBOM;

— обеспечить связь SBOM с реестром активов и классификацией критичности систем;

— регулярно сопоставлять компоненты с базами уязвимостей;

— использовать риск-ориентированную модель приоритизации;

— документировать решения о принятии, снижении или устранении риска;

— контролировать актуальность SBOM после каждого изменения программного продукта.

Особое внимание следует уделять организационной стороне внедрения. SBOM должен использоваться не только специалистами по информационной безопасности, но и командами разработки, эксплуатации, закупок и управления рисками. В противном случае он может остаться формальным документом, не влияющим на реальные управленческие решения.

В рамках процессов безопасной разработки SBOM целесообразно рассматривать как обязательный артефакт релиза. Перед передачей программного продукта в эксплуатацию должна выполняться проверка состава зависимостей, анализ известных уязвимостей, оценка лицензионных рисков и формирование заключения о допустимости использования конкретной версии продукта.

Для поставляемого программного обеспечения SBOM может использоваться как элемент контроля цепочки поставки. Наличие структурированного перечня компонентов позволяет заказчику быстрее оценить риски использования продукта, проверить наличие устаревших зависимостей и определить, какие меры сопровождения должны быть предусмотрены в договорных отношениях.

В системах КИИ применение SBOM должно быть связано с общей моделью управления рисками. Сам по себе перечень компонентов не снижает риск, если он не используется для принятия решений. Практическая ценность SBOM проявляется только при его интеграции с процессами инвентаризации активов, управления уязвимостями, контроля изменений, реагирования на инциденты и обеспечения непрерывности функционирования.

В работе рассмотрено применение Software Bill of Materials для управления рисками open-source-компонентов в системах критической информационной инфраструктуры. Показано, что SBOM обеспечивает прозрачность состава программного обеспечения, ускоряет анализ воздействия новых уязвимостей и создает основу для риск-ориентированной приоритизации мероприятий по устранению уязвимостей.

Предложенная методика включает формирование и актуализацию SBOM, сопоставление компонентов с источниками информации об уязвимостях, учет критичности активов и расчет интегрального показателя риска. В отличие от подходов, основанных только на технической оценке уязвимости, представленная модель учитывает контекст эксплуатации компонента и его влияние на критические процессы.

Использование SBOM в организациях с объектами КИИ позволяет повысить управляемость open-source-рисков, улучшить взаимодействие между командами разработки и информационной безопасности, сократить время реакции на критические уязвимости и повысить обоснованность принимаемых решений.

Дальнейшее развитие данного подхода может быть связано с автоматизацией анализа SBOM, применением графовых моделей зависимостей, интеграцией с системами управления уязвимостями и использованием методов машинного обучения для выявления наиболее значимых рисков в цепочке поставки программного обеспечения.

Литература:

1. Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации».
2. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации».
3. ФСТЭК России. Методика оценки угроз безопасности информации. 2021.
4. NIST SP 800–218. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. 2022.
5. NIST SP 800–161 Rev. 1. Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. 2022.
6. CISA. Minimum Elements for a Software Bill of Materials (SBOM). 2025.
7. OWASP Foundation. CycloneDX Software Bill of Materials Standard.
8. SPDX Workgroup. Software Package Data Exchange (SPDX) Specification.