Современные информационные системы всё чаще строятся на основе сложной совокупности собственно разработанного кода, сторонних библиотек, открытых программных компонентов, фреймворков, контейнерных образов и служебных модулей. Такой подход позволяет ускорять разработку и повторно использовать готовые решения, однако одновременно увеличивает количество потенциальных источников уязвимостей. Особенно значимой данная проблема становится для организаций, эксплуатирующих объекты критической информационной инфраструктуры, поскольку ошибки в программном обеспечении могут влиять не только на отдельные информационные системы, но и на устойчивость важных организационных или технологических процессов.
Для контроля безопасности программного обеспечения применяются различные классы инструментов. Одним из наиболее распространённых является SAST — статический анализ кода. SAST позволяет выявлять потенциальные дефекты безопасности в исходном коде без запуска программы. Данный подход используется для поиска небезопасных функций, ошибок обработки пользовательского ввода, нарушений правил работы с памятью, некорректной проверки прав доступа, небезопасной криптографии и других дефектов, которые могут привести к возникновению уязвимостей.
Другим важным направлением является SCA — анализ состава программных компонентов и зависимостей. В отличие от SAST, который ориентирован преимущественно на собственный код проекта, SCA позволяет выявлять риски, связанные со сторонними библиотеками, пакетами, open-source-компонентами и их версиями. Такой анализ помогает определить, используются ли в программном продукте компоненты с известными уязвимостями, устаревшие зависимости, библиотеки с неподходящими лицензиями или неподдерживаемые версии.
Третьим элементом является SBOM — Software Bill of Materials, или спецификация состава программного обеспечения. SBOM представляет собой формализованный перечень компонентов, входящих в программный продукт. В него могут включаться сведения о названии компонента, версии, поставщике, лицензии, контрольной сумме, зависимостях и иных характеристиках. По сути, SBOM выступает как «ведомость состава» программного продукта, которая позволяет понимать, из каких элементов он состоит и какие риски могут быть связаны с каждым элементом.
Каждый из перечисленных инструментов решает важную задачу, однако на практике их разрозненное применение может снижать эффективность процесса управления уязвимостями. SAST может выявлять дефекты в собственном коде, SCA — проблемы в зависимостях, а SBOM — фиксировать состав программного продукта. Если результаты этих инструментов хранятся отдельно, используются разными подразделениями и не связываются между собой, у организации возникают сложности с приоритизацией, отчётностью и контролем устранения уязвимостей.
Например, SCA-инструмент может обнаружить уязвимую библиотеку, но без связи с SBOM и реестром активов будет сложно определить, в каких программных продуктах она используется. SAST может показать потенциальную ошибку в модуле, но без информации о критичности данного модуля невозможно корректно оценить приоритет устранения. SBOM может содержать перечень компонентов, но без автоматического сопоставления с базами уязвимостей он не даёт полной картины риска. Поэтому для организаций КИИ особенно важно объединять данные SAST, SCA и SBOM в единый процесс управления уязвимостями.
Интеграция результатов SAST, SCA и SBOM позволяет перейти от набора отдельных технических отчётов к целостной системе принятия решений. В такой системе каждое срабатывание рассматривается не изолированно, а в контексте программного продукта, его компонентов, зависимостей, назначения, критичности и условий эксплуатации. Это особенно важно для критической информационной инфраструктуры, где устранение уязвимостей должно быть не только оперативным, но и обоснованным, контролируемым и документируемым.
Основными целями интеграции результатов SAST, SCA и SBOM являются:
– формирование единого представления о рисках программного продукта;
– повышение точности приоритизации уязвимостей;
– снижение количества дублирующих и разрозненных задач;
– обеспечение прослеживаемости от уязвимости до программного компонента;
– контроль использования сторонних и open-source-компонентов;
– поддержка процессов безопасной разработки;
– повышение качества отчётности для специалистов по информационной безопасности;
– обеспечение контроля изменений в программных продуктах КИИ.
Для построения единого процесса управления уязвимостями необходимо определить роль каждого источника данных. SAST отвечает за анализ собственного кода и выявление потенциальных дефектов реализации. SCA отвечает за анализ сторонних компонентов и известных уязвимостей в зависимостях. SBOM отвечает за фиксацию состава программного продукта и позволяет связать результаты анализа с конкретными версиями компонентов. Вместе эти три источника формируют более полное представление о состоянии безопасности программного обеспечения.
Процесс интеграции можно представить в виде нескольких этапов:
– инвентаризация программных продуктов и компонентов;
– формирование SBOM для каждого программного продукта;
– выполнение SAST-анализа собственного кода;
– выполнение SCA-анализа зависимостей;
– нормализация результатов анализа;
– сопоставление результатов с реестром активов КИИ;
– формирование единой карточки уязвимости;
– приоритизация уязвимостей;
– постановка задач на устранение;
– контроль исправления и повторная проверка;
– формирование отчётности и накопление базы знаний.
На первом этапе проводится инвентаризация программных продуктов. Для каждого продукта необходимо определить его назначение, владельца, ответственную команду, используемые технологии, окружение эксплуатации, связь с объектами КИИ, критичность обрабатываемых данных и влияние на бизнес- или технологический процесс. Без такой инвентаризации результаты технического анализа будут оторваны от реального контекста эксплуатации.
На втором этапе формируется SBOM. Он может создаваться в процессе сборки программного продукта, при анализе репозитория, контейнерного образа, пакета поставки или установленного программного обеспечения. Важно, чтобы SBOM формировался не один раз, а регулярно обновлялся при изменении состава продукта. Для корпоративной разработки целесообразно связывать SBOM с конкретной версией программного продукта, номером сборки, коммитом, релизом или поставочным комплектом.
SBOM должен содержать сведения, достаточные для последующего анализа рисков. К таким сведениям относятся:
– наименование программного компонента;
– версия компонента;
– тип компонента;
– поставщик или источник получения;
– лицензия;
– контрольная сумма;
– сведения о зависимостях;
– путь или место использования в проекте;
– дата формирования SBOM;
– версия программного продукта;
– формат представления SBOM.
На третьем этапе выполняется SAST-анализ. Его результаты должны быть связаны с конкретной версией исходного кода. Для каждого срабатывания необходимо сохранять идентификатор правила, описание проблемы, уровень критичности, файл, строку кода, фрагмент кода, категорию уязвимости, а также статус экспертной проверки. Важно учитывать, что результат SAST сам по себе не всегда является подтверждённой уязвимостью. Он требует проверки, анализа контекста и возможной корректировки приоритета.
На четвёртом этапе выполняется SCA-анализ. Он позволяет определить, какие зависимости используются в продукте и связаны ли они с известными уязвимостями. На данном этапе результаты SCA желательно сопоставлять с данными SBOM. Если SBOM показывает, что определённый компонент входит в состав продукта, а SCA обнаруживает для него известную уязвимость, такая информация должна автоматически попадать в процесс управления уязвимостями.
На пятом этапе проводится нормализация данных. Разные инструменты SAST, SCA и SBOM могут использовать разные форматы, названия полей, уровни критичности и классификации. Для интеграции необходимо привести результаты к единой модели данных. Это может быть реализовано через внутренний формат, в котором каждому срабатыванию присваиваются единые атрибуты: источник обнаружения, тип проблемы, компонент, версия, критичность, вероятность эксплуатации, влияние на систему, статус обработки и ответственный.
Единая модель данных может включать следующие поля:
– идентификатор уязвимости или срабатывания;
– источник обнаружения: SAST, SCA или SBOM;
– программный продукт;
– версия программного продукта;
– компонент или модуль;
– версия компонента;
– тип проблемы;
– связанный идентификатор CWE, CVE или внутреннего правила;
– уровень критичности;
– описание проблемы;
– возможное влияние;
– статус проверки;
– ответственный исполнитель;
– срок устранения;
– ссылка на задачу;
– дата обнаружения;
– дата закрытия;
– результат повторной проверки.
На шестом этапе результаты анализа связываются с реестром активов КИИ. Это один из ключевых элементов процесса, поскольку одинаковая уязвимость может иметь разный приоритет в зависимости от того, где она обнаружена. Уязвимость в тестовом внутреннем инструменте и уязвимость в программном компоненте, связанном с критичным процессом, не должны рассматриваться одинаково. Поэтому при оценке необходимо учитывать не только техническую критичность, но и значимость актива.
Для организаций КИИ приоритизация должна учитывать следующие факторы:
– критичность программного продукта;
– связь с объектом КИИ;
– роль компонента в архитектуре системы;
– доступность компонента из внешних или смежных сетей;
– тип обрабатываемых данных;
– наличие известных способов эксплуатации;
– наличие компенсирующих мер защиты;
– возможность обновления или исправления;
– влияние исправления на устойчивость системы;
– требования внутренних регламентов и нормативных документов.
На седьмом этапе формируется единая карточка уязвимости. Она должна объединять сведения из SAST, SCA, SBOM и реестра активов. Такая карточка позволяет специалисту видеть не только техническое описание проблемы, но и её практический контекст. Например, если SCA обнаруживает уязвимую библиотеку, карточка должна показывать, в каких продуктах она используется, какие версии затронуты, есть ли связь с критичными компонентами, доступен ли компонент нарушителю и какие варианты устранения возможны.
Единая карточка уязвимости может иметь следующую структуру:
– краткое наименование проблемы;
– источник обнаружения;
– описание уязвимости;
– затронутый программный продукт;
– затронутый компонент;
– версия компонента;
– сведения из SBOM;
– результаты SAST или SCA;
– связанный CWE или CVE;
– техническая критичность;
– критичность актива;
– итоговый приоритет;
– рекомендуемый способ устранения;
– ответственный за исправление;
– статус обработки;
– результаты повторной проверки;
– комментарий специалиста по информационной безопасности.
На восьмом этапе выполняется приоритизация. В традиционном подходе приоритет часто определяется только уровнем критичности, который выдал инструмент анализа. Однако для КИИ такого подхода недостаточно. Необходимо учитывать контекст эксплуатации. Например, уязвимость с высоким техническим баллом может иметь низкую практическую значимость, если компонент недоступен извне и используется только в изолированном тестовом контуре. В то же время уязвимость среднего уровня может быть приоритетной, если она затрагивает критичный компонент, связанный с важным процессом.
Для расчёта итогового приоритета можно использовать риск-ориентированный подход. В простейшем виде итоговый приоритет может определяться на основе следующих групп факторов:
– техническая критичность уязвимости;
– вероятность эксплуатации;
– критичность программного продукта;
– критичность затронутого компонента;
– наличие публичной информации об эксплуатации;
– наличие исправленной версии;
– сложность обновления;
– наличие компенсирующих мер;
– влияние исправления на стабильность системы.
Такой подход позволяет не просто сортировать уязвимости по уровню «низкий», «средний», «высокий» или «критический», а учитывать реальный риск для конкретной организации. Для КИИ это особенно важно, поскольку не все обновления можно устанавливать немедленно. Иногда исправление требует тестирования, согласования, проверки совместимости и планового окна обслуживания.
На девятом этапе создаются задачи на устранение. Каждая задача должна быть связана с карточкой уязвимости и содержать достаточную информацию для разработчика или администратора. Если задача сформирована на основе SAST, в ней должен быть указан проблемный фрагмент кода и рекомендация по исправлению. Если задача сформирована на основе SCA, должны быть указаны уязвимая зависимость, безопасная версия, возможные ограничения обновления и продукты, в которых компонент используется. Если задача связана с SBOM, необходимо указать, какие компоненты требуют проверки или замены.
На десятом этапе выполняется контроль исправления. После внесения изменений необходимо повторно запустить SAST и SCA, а также обновить SBOM. Это позволяет подтвердить, что уязвимость действительно устранена, зависимость обновлена, а состав программного продукта изменился корректно. Закрытие задачи без повторной проверки может привести к формальному устранению проблемы, при котором реальный риск сохраняется.
Особое значение имеет прослеживаемость. Для каждой уязвимости должна быть возможность восстановить путь от обнаружения до закрытия: каким инструментом она найдена, в каком компоненте, в какой версии продукта, кто принял решение, как был определён приоритет, какое исправление выполнено и каким анализом подтверждено устранение. Такая прослеживаемость важна для внутреннего контроля, аудита, расследования инцидентов и повышения зрелости процесса безопасной разработки.
Интеграция SAST, SCA и SBOM также позволяет решать задачу повторного поиска уязвимых компонентов. Если в базе уязвимостей появляется новая информация о проблеме в определённой библиотеке, организация может быстро определить, где используется соответствующий компонент. Для этого необходимо сопоставить новую уязвимость с имеющимися SBOM. Такой подход особенно полезен для крупных организаций, где один и тот же компонент может применяться в нескольких программных продуктах и командах разработки.
Важным преимуществом единого процесса является снижение дублирования. Без интеграции одна и та же проблема может попасть в разные отчёты: как уязвимость зависимости в SCA, как компонент в SBOM и как небезопасное использование в SAST. Если эти сведения не объединяются, специалисты могут создавать несколько задач на одну и ту же первопричину. Единая карточка позволяет связывать такие данные и рассматривать их как один управляемый риск.
При внедрении процесса необходимо определить роли участников. Специалист по информационной безопасности отвечает за методологию, настройку правил, анализ критичности и контроль устранения. Команда разработки отвечает за исправление кода, обновление зависимостей и проверку совместимости. Владелец программного продукта определяет допустимые сроки исправления и принимает решения по рискам. Администраторы и специалисты эксплуатации участвуют в проверке возможности обновления в конкретной среде. Для объектов КИИ также важна роль ответственных за соблюдение внутренних регламентов и требований защиты информации.
Организационно процесс может быть закреплён во внутреннем регламенте управления уязвимостями программного обеспечения. В таком регламенте целесообразно определить:
– какие программные продукты подлежат анализу;
– на каких этапах выполняются SAST и SCA;
– когда формируется и обновляется SBOM;
– кто отвечает за обработку результатов;
– какие сроки устранения применяются для разных уровней риска;
– как фиксируются исключения и принятые риски;
– как проводится повторная проверка;
– какие отчёты формируются для руководства и специалистов;
– как пересматриваются правила анализа и критерии приоритизации.
Для оценки эффективности интегрированного процесса можно использовать набор метрик. Они должны показывать не только количество найденных уязвимостей, но и качество управления ими. Например, можно оценивать среднее время устранения уязвимости, долю уязвимостей с подтверждённым исправлением, количество продуктов с актуальным SBOM, долю зависимостей с известными уязвимостями, количество повторно появившихся проблем, долю ложноположительных SAST-срабатываний и количество критичных уязвимостей без назначенного ответственного.
К числу полезных метрик относятся:
– процент программных продуктов с актуальным SBOM;
– количество уязвимых компонентов по данным SCA;
– количество SAST-срабатываний по уровням критичности;
– доля подтверждённых уязвимостей;
– среднее время обработки уязвимости;
– среднее время устранения уязвимости;
– количество просроченных задач;
– количество повторно открытых уязвимостей;
– доля уязвимостей, закрытых после повторной проверки;
– количество исключений и принятых рисков.
В организациях КИИ необходимо особенно осторожно подходить к использованию внешних сервисов анализа. Исходный код, SBOM и сведения о зависимостях могут содержать чувствительную информацию о структуре программного продукта. Поэтому при выборе инструментов необходимо учитывать требования к размещению данных, возможности локального развёртывания, контроль доступа, журналирование действий и защиту отчётов. В ряде случаев предпочтительно использовать решения, работающие во внутреннем контуре организации.
Отдельной проблемой является качество SBOM. Формальное наличие файла SBOM не гарантирует его полезность. Если в нём отсутствуют версии компонентов, сведения о транзитивных зависимостях или связь с конкретной сборкой, его сложно использовать для управления уязвимостями. Поэтому SBOM должен быть точным, актуальным, машинно-читаемым и связанным с процессом сборки. Желательно, чтобы его формирование было автоматизировано и не зависело от ручного заполнения.
Также важно учитывать транзитивные зависимости. Программный продукт может напрямую использовать одну библиотеку, которая, в свою очередь, использует другие компоненты. Уязвимость может находиться не в прямой зависимости, а в компоненте более низкого уровня. SCA и SBOM должны позволять выявлять такие связи, иначе часть рисков останется незамеченной.
Интеграция SAST, SCA и SBOM может быть реализована в рамках DevSecOps-подхода. При каждом изменении кода выполняется статический анализ, при сборке проверяются зависимости, а при формировании релиза создаётся актуальный SBOM. Результаты автоматически передаются в систему управления уязвимостями, где обогащаются данными о критичности активов и требованиями внутренних регламентов. Такой подход позволяет выявлять проблемы раньше и снижает вероятность попадания уязвимого кода или компонента в промышленную эксплуатацию.
Вместе с тем автоматизация не должна исключать экспертную оценку. Инструменты могут ошибаться, выдавать ложноположительные результаты или не учитывать особенности конкретной архитектуры. Поэтому важные решения, связанные с принятием риска, переносом срока устранения или исключением срабатывания, должны подтверждаться ответственными специалистами. Для КИИ это особенно важно, поскольку формальный подход к управлению уязвимостями может привести к накоплению скрытых рисков.
В качестве примера можно рассмотреть ситуацию, когда SCA обнаруживает уязвимость в open-source-библиотеке, используемой в нескольких внутренних программных продуктах. При наличии SBOM организация может быстро определить все продукты и версии, где используется данная библиотека. Далее сведения сопоставляются с критичностью активов. Для продукта, связанного с важным процессом, задача получает высокий приоритет. Для продукта, находящегося в тестовой среде, срок устранения может быть менее срочным. Если SAST дополнительно показывает, что уязвимая функция библиотеки действительно вызывается в коде, приоритет может быть повышен.
Другой пример связан с SAST-срабатыванием. Инструмент обнаруживает потенциальную SQL-инъекцию в модуле обработки данных. Если этот модуль входит в программный продукт, связанный с критичным процессом, и имеет внешний интерфейс, срабатывание должно быть проверено в первую очередь. Если же анализ показывает, что модуль не используется в актуальной версии продукта, а SBOM и данные сборки подтверждают его отсутствие в поставке, приоритет может быть снижен или задача может быть закрыта после экспертной проверки.
Таким образом, основная ценность интеграции заключается не только в объединении отчётов, но и в создании связей между кодом, зависимостями, составом продукта и активами организации. Именно эти связи позволяют принимать обоснованные решения. Без них управление уязвимостями превращается в обработку большого количества несвязанных технических сообщений.
Для успешного внедрения интегрированного процесса можно выделить несколько практических рекомендаций:
– начинать с пилотного проекта и постепенно масштабировать подход;
– использовать единый реестр программных продуктов;
– автоматизировать формирование SBOM;
– связывать результаты SAST и SCA с конкретной версией продукта;
– нормализовать уровни критичности и статусы обработки;
– учитывать критичность активов КИИ при приоритизации;
– фиксировать все исключения и принятые риски;
– проводить повторную проверку после исправления;
– регулярно пересматривать правила анализа;
– формировать отчёты не только по количеству уязвимостей, но и по динамике их устранения.
Интеграция результатов SAST, SCA и SBOM является важным шагом к повышению зрелости процессов безопасной разработки. Она позволяет объединить анализ собственного кода, контроль сторонних компонентов и управление составом программного продукта. Для критической информационной инфраструктуры такой подход особенно актуален, поскольку помогает обеспечить прослеживаемость, контроль изменений и риск-ориентированное принятие решений.
Таким образом, единый процесс управления уязвимостями должен строиться не вокруг отдельных инструментов, а вокруг программного продукта и его роли в инфраструктуре организации. SAST, SCA и SBOM являются взаимодополняющими источниками данных. Их совместное использование позволяет быстрее выявлять уязвимости, точнее определять приоритеты, эффективнее планировать устранение и снижать риски эксплуатации уязвимого программного обеспечения в системах КИИ.
Литература:
- OWASP. Source Code Analysis Tools. — Текст: электронный // OWASP Foundation: [сайт]. — URL: https://owasp.org/www-community/Source_Code_Analysis_Tools (дата обращения: 28.06.2026).
- OWASP. Static Code Analysis. — Текст: электронный // OWASP Foundation: [сайт]. — URL: https://owasp.org/www-community/controls/Static_Code_Analysis (дата обращения: 28.06.2026).
- Souppaya M., Scarfone K., Dodson D. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication 800–218. — 2022. — URL: https://csrc.nist.gov/pubs/sp/800/218/final (дата обращения: 28.06.2026).
- CISA. 2025 Minimum Elements for a Software Bill of Materials (SBOM). — Текст: электронный // Cybersecurity and Infrastructure Security Agency: [сайт]. — URL: https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom (дата обращения: 28.06.2026).
- CISA. A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity. — Текст: электронный // Cybersecurity and Infrastructure Security Agency: [сайт]. — URL: https://www.cisa.gov/resources-tools/resources/shared-vision-software-bill-materials-sbom-cybersecurity (дата обращения: 28.06.2026).
- ГОСТ Р 56939–2024. Защита информации. Разработка безопасного программного обеспечения. Общие требования. — М.: Российский институт стандартизации, 2024.
- Банк данных угроз безопасности информации ФСТЭК России. — Текст: электронный // БДУ ФСТЭК России: [сайт]. — URL: https://bdu.fstec.ru/ (дата обращения: 28.06.2026).
- MITRE. Common Weakness Enumeration. — Текст: электронный // MITRE: [сайт]. — URL: https://cwe.mitre.org/ (дата обращения: 28.06.2026).
- FIRST. Common Vulnerability Scoring System Version 4.0: Specification Document. — Текст: электронный // FIRST: [сайт]. — URL: https://www.first.org/cvss/specification-document (дата обращения: 28.06.2026).
- OWASP CycloneDX. CycloneDX Bill of Materials Standard. — Текст: электронный // CycloneDX: [сайт]. — URL: https://cyclonedx.org/ (дата обращения: 28.06.2026).
- SPDX. The System Package Data Exchange. — Текст: электронный // SPDX: [сайт]. — URL: https://spdx.dev/ (дата обращения: 28.06.2026).
