1. SCA – что это?
Мой профессиональный путь в сфере информационной безопасности начался на рубеже 2010-х годов. В тот период концепция анализа уязвимостей еще не была распространенной практикой на российском ИТ-рынке. Подобные вопросы волновали, пожалуй, лишь единичных крупных игроков, в то время как абсолютному большинству компаний только предстояло осознать их важность.
Поворотным моментом стал период 2014-2015 годов. В это время проверка сторонних библиотек на уязвимости стала обязательным элементом жизненного цикла разработки. Толчком послужили нормативные требования одного из российских регуляторов: сначала к критическим модулям, а затем и ко всему коду продуктов. Перед специалистами встала сложная задача: им пришлось в срочном порядке искать и осваивать инструменты и процессы для выполнения этих новых стандартов.
Именно тогда у сообщества появилось первое понимание, как можно решить эту задачу. Инженеры принялись активно создавать скрипты и парсеры, которые автоматически выгружали данные из баз уязвимостей (NIST, CVE) и тем самым формально закрывали регуляторные нормы.
Однако со временем требования к анализу эволюционировали, становясь все более глубокими. Это закономерно привело нас к освоению практики Software Composition Analysis (далее по тексту – SCA), известной в России как «композиционный анализ» или «анализ состава программного обеспечения». Таким образом, мы начали внедрять подход, который на Западе стал стандартом еще в начале 2000-х.
Чтобы понять суть SCA, нужно обратиться к основам современной разработки. Сегодня создание сложного программного обеспечения практически никогда не подразумевает написания всего кода «с нуля». Вместо этого разработчики активно используют готовые библиотеки и фреймворки. Зачем заново создавать, к примеру, модуль для парсинга JSON, если можно интегрировать проверенную временем открытую библиотеку? Именно такие сторонние компоненты и называются зависимостями. Чем сложнее продукт, тем больше таких зависимостей он аккумулирует, формируя сложную цепочку поставок программного обеспечения (software supply chain).
Что произойдет, если в одной из этих зависимостей будет обнаружена уязвимость? В этом случае авторы компонента, будь то сообщество энтузиастов или крупная компания, выпускают патч и публикуют исправленную версию, например, на GitHub. Но ключевой вопрос заключается в следующем: как разработчику, использующему эту библиотеку в своем продукте, узнать о возникшей уязвимости? Ведь теперь и его приложение становится уязвимым.
Решением этой задачи является внедрение процесса управления уязвимостями (Vulnerability Management). Этот процесс предполагает регулярный мониторинг баз уязвимостей не только для собственного кода, но и для всего спектра используемых сторонних компонентов. Таким образом, команда должна систематически (ежедневно, еженедельно или ежемесячно – в зависимости от критичности продукта) отслеживать появление новых уязвимостей и патчей для всех зависимостей, чтобы оперативно применять исправления и минимизировать риски.
При наличии в продукте одной-двух зависимостей ручной мониторинг еще возможен. Однако в условиях современных проектов, насчитывающих сотни и тысячи сторонних компонентов, такой подход перестает быть жизнеспособным. Решением этой проблемы является специализированное ПО для композиционного анализа (SCA). Такие системы, получая информацию о зависимостях проекта, автоматически сканируют базы данных уязвимостей и формируют детализированный отчет о выявленных уязвимостях. Это позволяет командам оперативно идентифицировать критические компоненты, требующие обновления, и тем самым поддерживать необходимый уровень безопасности. Но не все так просто, как кажется...
2. Сложности перевода
Мировая экосистема кибербезопасности включает множество баз данных, аккумулирующих информацию об уязвимостях не только в открытом, но и в проприетарном программном обеспечении. Среди международных эталонных источников можно выделить CVE (Common Vulnerabilities and Exposures) и поддерживаемый NIST каталог NVD (National Vulnerability Database). На национальном уровне аналогичные реестры ведут некоторые крупные российские вендоры, а также ФСТЭК России в рамках Банка данных угроз безопасности информации (БДУ ФСТЭК).
Стоит отметить, что механизмы пополнения этих баз далеки от идеала. При детальном изучении записей зачастую выявляются противоречия и неточности, что создает почву для неод��означных трактовок и затрудняет однозначную классификацию уязвимости.
Чтобы проиллюстрировать возникающие на практике сложности, обратимся к конкретным примерам, демонстрирующим характерные «проблемы согласованности» данных в различных источниках.
2.1. Несколько примеров
Рассмотрим на примере библиотеки OpenSSL, с какими несоответствиями можно столкнуться при поиске информации об уязвимостях в популярных базах данных:
БДУ ФСТЭК
Рассмотрим уязвимость для библиотеки OpenSSL с идентификатором BDU:2025-01602. Обратим внимание на перечень уязвимого ПО для версии библиотеки с открытым исходным кодом (см. Рисунок 1).
Возникает закономерный вопрос: какую же информацию следует считать достоверной? Проиллюстрируем проблему на примере: при использовании OpenSSL версии 3.3.4 данные из разных строк противоречат друг другу. Согласно одной записи, уязвимы версии «до 3.4.1», что указывает на уязвимость 3.3.4. В то же время другая запись гласит, что проблема актуальна для версий «до 3.3.3», что, напротив, исключает 3.3.4 из числа уязвимых. Так где же истина?
Очевидно, что в данном случае подразумеваются три отдельных диапазона: 3.2.0 – 3.2.4, 3.3.0 – 3.3.3 и 3.4.0 – 3.4.1. Однако сформулировано это таким образом, что с первого взгляда трактовка неочевидна. Обратимся к описанию этой уязвимости в зарубежной базе NVD – возможно, там представлена более структурированная и однозначная информация.
NVD (NIST)
В базе данных NVD вообще отсутствует информация о конкретных уязвимых версиях. Единственное, что мы можем почерпнуть из этой страницы (см. Рисунок 2), – это формулировка из описания самой уязвимости: «Эта проблема появилась в первоначальной реализации поддержки RPK в OpenSSL 3.2. Модули FIPS в версиях 3.4, 3.3, 3.2, 3.1 и 3.0 не подвержены этой проблеме». Данная формулировка порождает еще больше вопросов к записям в БДУ ФСТЭК... А что если ваш пакет из репозитория Debian или RedHat? Обратимся к базе уязвимостей Security Debian для прояснения ситуации.
Security Debian
Security Debian предоставляет третий вариант данных, который расходится с предыдущими, поскольку оперирует информацией о пакетах, специфичных для разных мажорных версий ОС Debian (см. Рисунок 3).
2.2. Еще немного примеров
Следующий наглядный пример демонстрирует расхождения в описании одной и той же уязвимости между БДУ ФСТЭК и NVD (см. Рисунки 4 – 5).
Как мы видим, сравнение уязвимых версий выявляет многочисленные несоответствия между базами данных. Это закономерно приводит к ключевому вопросу: как эффективно оценивать информацию из разных источников и гарантировать, что ни одна актуальная уязвимость для вашего продукта не останется без внимания?
Именно для решения этой задачи наша команда разработала сервис СКАТмен. Он предоставляет единую платформу для агрегации данных из разнородных источников и организации проектной работы по мониторингу уязвимостей, что существенно сокращает время на анализ. Это достигается за счет применения специализированных алгоритмов, которые минимизируют количество ложных срабатываний и помогают сфокусироваться на реальных уязвимостях.
3. СКАТмен
СКАТмен (skatman.ru) – это сервис, созданный инженерами компании Инферит (кластер «СФ Тех» ГК Softline) для решения задач по композиционному анализу зависимостей разрабатываемого ПО.
Его эффективность подтверждена практикой: сервис используется в конвейере безопасной разработки ОС «МСВСфера» и уже демонстрирует отличные результаты, экономя ценное время специалистов.
Понимая, что такая необходимость е��ть у многих компаний, мы выделили ядро сервиса, убрав специфичные для работы с нашей операционной системой модули, и открыли к нему бесплатный доступ. Теперь этим инструментом может воспользоваться каждый!
Поговорим о ключевых функциях сервиса.
3.1. Окно «Проекты»
После успешной авторизации в системе пользователь получает возможность создавать новые проекты. Интерфейс создания проекта представлен на изображении ниже:
Чтобы начать работу с сервисом, нужно создать проект, для чего необходимо нажать кнопку «Добавить» и заполнить необходимые данные по проекту.
3.2. Добавление проекта
Следующим шагом необходимо добавить в проект перечень зависимостей (пакетов, библиотек, модулей) для анализа. Сервис поддерживает три способа загрузки данных:
3.2.1. Ручной ввод данных. Для этого необходимо нажать кнопку «Добавить пакеты» (см. Рисунок 7), после чего ввести название пакета и его версию в соответствующие поля (см. Рисунок 8).
Данный метод эффективен для анализа уязвимостей в одной или нескольких зависимостях, однако он не масштабируется и становится непрактичным при работе с пятью и более компонентами. Для таких случаев предусмотрен второй или третий способы.
3.2.2. Загрузка текстового файла. Предоставьте системе файл, содержащий перечень зависимостей и их версий. Пример записей файла приведен на Рисунке 9.
СКАТмен автоматически извлечет релевантные данные и загрузит в проект только необходимую информацию. Процесс загрузки текстового файла осуществляется следующим образом:
Перетащите файл в область Drag&Drop (см. Рисунок 10).
Дождитесь завершения обработки данных сервисом.
После успешной загрузки интерфейс обновится: область для Drag&Drop сменится списком добавленных в проект зависимостей (см. Рисунок 11). Для начала анализа останется нажать кнопку «Запустить сканирование».
3.2.3. Третий способ – расширенный. Помимо текстовых файлов, сервис поддерживает загрузку бинарных данных: ISO-образов систем, содержащих deb или rpm пакеты, а также архивов в форматах zip, 7z, xc, tar.gz, rar и tar.
Обработка таких файлов занимает больше времени из-за необходимости их загрузки и распаковки на сервере. Однако этот метод предоставляет значительное преимущество: он активирует дополнительные аналитические алгоритмы, недоступные при ручном вводе.
Вместо простого сопоставления по имени и версии система извлекает и анализирует историю разработки пакетов. Изучая данные о ранее устраненных уязвимостях, алгоритмы могут коррелировать эту информацию с обнаруженными записями об уязвимостях в анализируемых базах данных, что в разы повышает точность проверки и значительно снижает уровень ложных срабатываний.
3.3. Сканирование
После загрузки данных о пакетах в проект для инициации анализа необходимо нажать кнопку «Запустить сканирование» (см. Рисунок 12) и дождаться завершения процесса.
По завершении сканирования система обновит данные о выявленных уязвимостях и предоставит пользователю подробный отчет, содержащий перечень проблем и рекомендации по их устранению (см. Рисунок 13).
3.4. Анализ результатов
При нажатии на элементы интерфейса, отображающие количество уязвимостей, открывается детализированная таблица с полной информацией о каждой обнаруженной проблеме (см. Рисунок 14).
В столбце «ID уязвимости» отображаются идентификаторы из различных баз данных, интерактивные ссылки на соответствующие источники и текстовое описание уязвимости. В поле «Оценка уязвимости» приводятся рейтинги критичности по стандартам CVSS (версии 2, 3 и/или 4), а также векторы атак из разных источников (см. Рисунок 15).
В столбце «Эксплойт» представлены ссылки на существующие эксплойты для выявленных уязвимостей. Столбец «Рекомендации по устранению» содержит интерактивные ссылки, открывающие официальные инструкции по устранению проблем из соответствующих баз данных (см. Рисунок 16).
3.4.1. Обработка результатов
Как и другие решения для SCA, СКАТмен может генерировать ложные срабатывания, что часто связано с противоречиями между различными базами уязвимостей. В таких ситуациях мы руководствуемся принципом «Лучше показать лишнее, чем пропустить уязвимость». Например, если большинство источников указывают на отсутствие уязвимости в конкретной версии ПО, но хотя бы одна база данных содержит информацию о ее наличии, система отобразит эту уязвимость. Следующий пример наглядно демонстрирует подобный случай (см. Рисунок 17).
Обнаруженная уязвимость присутствует исключительно в БДУ ФСТЭК. Хотя теоретически это может указывать на уникальную информацию, доступную только российскому реестру, на практике такие случаи крайне редки. Как правило, уязвимости в БДУ ФСТЭК дублируют записи из международных баз данных (таких как NVD) и имеют соответствующие идентификаторы CVE.
Таким образом, расхождение такого типа в 95% случаев свидетельствует о том, что для данной версии пакета (в данном случае – glibc 2.34) уязвимость актуальна только согласно БДУ ФСТЭК, тогда как в международных источниках (NVD, RedHat, Debian) она отмечена как устраненная.
Обратимся к исходной записи в БДУ ФСТЭК. Для исследуемого пакета glibc версии 2.34 в реестре указано, что он подвержен уязвимости (см. Рисунок 18).
Ниже представлена ссылка на исходную запись об уязвимости (см. Рисунок 19) в базе данных NVD (NIST).
Перейдем по ссылке и увидим, что данная уязвимость была актуальна до версии 2.31 (см. Рисунок 20)
Перед нами классический пример рассинхронизации данных между различными базами уязвимостей. Теоретически, такую запись можно было бы исключить из отчета – детальная проверка с высокой долей вероятности подтвердила бы, что при внесении информации в БДУ ФСТЭК была допущена ошибка, и пакет glibc версии 2.34 на самом деле не уязвим.
Однако во избежание ошибок второго рода (пропуска реальной уязвимости) мы сознательно сохраняем подобные записи в отчетах, если уязвимость присутствует хотя бы в одном авторитетном источнике. Мы не можем быть абсолютно уверены в ошибочности данных, поэтому в спорных случаях рекомендуем проводить дополнительную ручную проверку, включая тестовую эксплуатацию уязвимости.
Этот пример наглядно демонстрирует причину возникновения ложных срабатываний в СКАТмен. Хотя их количество невелико, а фильтрация при понимании логики происхождения не составляет особого труда, мы считаем такой подход оправданным с точки зрения обеспечения максимальной безопасности.
3.4.2. Проектная работа
При регулярной работе с продуктом, имеющим стабильный набор зависимостей, возникает потребность в фильтрации и сохранении результатов анализа СКАТмен для последующего мониторинга появления новых уязвимостей при повторном сканировании проекта. Для решения этой задачи мы реализовали функционал управления записями в проекте.
Вернемся к нашему проекту. Предположим, в ходе анализа вы определили, что уязвимости, присутствующие только в БДУ ФСТЭК, неактуальны для вашего пакета. В данном случае для пакета glibc версии 2.34 таких записей три (см. Рисунок 21).
Для изменения статуса уязвимостей выделите соответствующие записи, выберите целевую категорию из выпадающего списка и нажмите кнопку «Перенести» (см. Рисунок 22).
После выполнения операции выделенные уязвимости будут перемещены в выбранную категорию (в данном случае – «Неактуальные», см. Рисунок 23).
Теперь мы можем нажать кнопку «Сканировать еще раз» и все ручные переносы и изменения сохранятся для этого проекта.
3.5. Использование бюллетеней
Бюллетень – это, по сути, список идентификаторов CVE, которые были устранены в конкретном проекте. Мы можем добавлять такой список к нашему проекту, благодаря чему результаты анализа будут гораздо чище и количество ложных срабатываний будет сведено к минимуму.
Рассмотрим проект, использующий четыре компонента с открытым исходным кодом:
curl_7.76.1;
glibc_2.34;
libxml2_2.9.13;
openssh_8.7.
Предположим, специалисты по безопасности обнаружили уязвимости в этих пакетах и устранили их непосредственно в коде, без изменения версий компонентов. В такой ситуации СКАТмен продолжит детектировать эти уязвимости, поскольку анализ основан на версиях пакетов. Хотя отчет технически корректен с точки зрения исходных компонентов (см. Рисунок 24) , для вашей модифицированной кодовой базы эти результаты становятся ложными срабатываниями.
Для того, чтобы заранее учесть исправления конкретных уязвимостей в пакетах из вашего проекта необходимо воспользоваться бюллетенями.
Для этого необходимо сформировать бюллетень в виде обычного текстового файла и отразить в нем записи об уже устраненных в проекте уязвимостях. Например, созданный бюллетень может иметь записи, представленные на Рисунке 25.
Перейдите на вкладку «Бюллетени» (см. Рисунок 26).
Нажмите кнопку «Добавить бюллетень» (см. Рисунок 27).
Перетащите в область Drag&Drop созданный текстовый файл бюллетеня (см. Рисунок 28).
Проверьте, что все данные распарсились корректно. Если нужно, то можете внести корректировки и нажать кнопку «Добавить» (см. Рисунок 29).
Далее необходимо вернуться в проект и нажать кнопку «Добавить бюллетени» (см. Рисунок 30).
Откроется форма “Добавление бюллетеней в проект”, после чего необходимо выбрать нужный бюллетень, перенести его в колонку «Добавленные» и нажать кнопку «Сохранить» (см. Рисунок 31).
После этого бюллетень будет добавлен к нашему проекту. Для проверки функционала необходимо нажать кнопку «Сканировать еще раз» и вы сможете увидеть результат – бюллетень был применен к проекту и уязвимости, информацию о которых он содержал, были перенесены в колонку «Устраненные» (см. Рисунок 32).
При анализе проектов на основе ISO-образов или архивов с пакетами (RPM/DEB) используются специальные алгоритмы, снижающие количество ложных срабатываний за счет анализа метаданных пакетов. В таких проектах система может автоматически создавать бюллетень и перемещать некоторые уязвимости в категорию «Устраненные».
3.6. Отчеты
Завершающим этапом является формирование отчетности для руководства или контролирующих органов. Система позволяет выборочно включать в отчет только релевантные данные. Для генерации отчета необходимо нажать кнопку «Скачать» (см. Рисунок 33).
Далее необходимо выбрать поля из которых будет формироваться отчет и нажать кнопку «Скачать» (см. Рисунок 34).
Отчет формируется в формате HTML, что обеспечивает его совместимость с любыми электронными устройствами. Сохраняется полная интерактивность документа, включая работоспособные гиперссылки и другие преимущества данного формата.
4. Цель проекта
Цель нашего проекта "СКАТмен" — обеспечить безопасность зависимостей, используемых при разработке российского программного обеспечения, что в конечном итоге должно способствовать повышению качества и защищенности отечественных IT-продуктов.
Мы стремимся предоставить каждому специалисту свободный доступ к полнофункциональному инструменту SCA, который бы охватывал весь спектр задач анализа. Наша цель — создать востребованный продукт, развиваемый в соответствии с реальными потребностями сообщества.
Поскольку сервис распространяется бесплатно, для обеспечения его стабильной работы мы вводим базовые пользовательские ограничения (на количество проектов и анализируемых внутри них пакетов), связанные с оптимизацией эксплуатационных расходов.
Мы ценим мнение каждого пользователя. В сервисе реализована функция «Отзывы и предложения» для сбора ваших идей и предложений по доработке СКАТмен. В ближайших планах — создание публичной площадки, где мы будем размещать наиболее интересные предложения и проводить голосования. Это позволит нам совместно формировать дорожную карту, делая развитие СКАТмена по-настоящему ориентированным на запросы пользователей.
5. Полезные ссылки
URL СКАТмен: https://skatman.ru/
Телеграмм-канал: https://t.me/SKATman_SCA
