РБПО на конвейере: как Hantis избавляет исследователя от рутины

Николай Костригин, руководитель отдела БРПО «Базальт СПО»

Текстовую версию доклада читайте ниже.
Запись доклада смотрите на VK Видео.

Команда направления безопасности разработки программного обеспечения «Базальт СПО» создала инструмент, позволяющий минимизировать рутинные операции при проведении РБПО-исследований.

Конвейер автоматизации Hantis представил Николай Костригин, руководитель отдела безопасности разработки программного обеспечения «Базальт СПО»,
в рамках ТБ Форума 2024.

Команда разработчиков «Базальт СПО» столкнулась с фаззингом в 2019 году. Тогда это было сертификацией, и в то время фаззить в стране еще никто толком не умел. Запускали первые процессы на виртуальных машинах, осваивали первые инструменты, обменивались опытом. Сейчас количество проектов, которые мы исследуем, уже перевалило за три десятка. И оно будет еще расти. Как показали наши собственные исследования и работа в рамках Центра исследований безопасности системного ПО, распутывая взаимосвязи между программным обеспечением и библиотеками, неизбежно натыкаешься на объекты, которые приходится добавлять в область изучения.

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

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

С учетом этого факта в наших исследованиях мы пришли к такому подходу: тестировать не одну версию, а как минимум две — ту, что входит в дистрибутив, и ту, что является самой новой в репозитории. У этого метода, безусловно, есть минус: некоторые разработчики проектов СПО (upstream) не принимают или неохотно принимают патчи в свои старые стабильные ветви. В таком случае исправления приходится разрабатывать и отправлять в мастер-ветку проекта, а у себя соответствующие изменения кода поддерживать самостоятельно.

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

Когда мы начинали заниматься исследованиями, хотелось сосредоточить внимание на поиске уязвимостей, а не на обслуживании виртуальных машин и контейнеров, которые обеспечивали выполнение процессов фаззинга. Поэтому мы последовательно обобщали требования к фаззингу каждого проекта, и вырабатывали подход к тому, как построить набор унифицированных git-репозиториев с инструментальными средствами для каждого исследуемого проекта СПО. Срезы такого репозитория, обозначенные метками (тэгами), должны соответствовать определенной версии ПО, а сам репозиторий — эволюционировать вместе с обновлениями объекта исследований. Так он накапливает в себе базу знаний и при обновлении ПО сможет автоматически  перебазироваться на новую версию программы, перенося на нее уже разработанные обвязки. 

С появлением в области ответственности нашей команды статического анализа и внедрением инструментов поиска поверхности атаки, требования к инструменту автоматизации стали расти. Мы их постепенно обобщали и дошли до текущего вида конвейера. 

Назвали мы его «Hantis». Почему? На самом деле, это название не выдуманное, а заимствованное. Hand Tennis — это теннис, в который играют от двух до четырех человек на четырех столах. Процесс исследований очень похож на этот вид спорта. Проекты, исследуемые разными инструментами, переходят от одного исполнителя к другому, развиваются, возвращаются к своему начальному автору, и так по кругу.

Поскольку начиналось все вокруг фаззинга, а большая часть инструментов успешно запускается в контейнерах, то, когда мы обобщили требования к автоматизации, поняли, что вынуждены будем написать свой собственный Kubernetes. За основу мы решили взять готовый продукт. В качестве CI/CD и хранилища репозиториев у нас используется GitLab, объектное хранилище построено на MinIO.

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

Чтобы, помимо фаззинга, конвейер позволял осуществлять иные типы исследований, мы предусмотрели механизм расширения, который назвали hunter (англ. «охотник») — это что-то «разыскивающее» и созвучно с Hantis. По сути, это отдельные репозитории, в которых описывается процедура работы со сторонними инструментами. Это могут быть статические анализаторы, инструменты поиска поверхности атаки. Опять же, ГОСТ по статическому анализу требует проведения анализа более чем одним инструментом, поэтому механизм расширения возможностей конвейера оказался оправдан.

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

Нужно отметить, что у команды ALT Linux Team есть открытая «сборочница» проекта «Сизиф». Чтобы связать проведение РБПО-исследований с обновлением пакетной базы, мы не стали ничего в ней ломать, а конвейер Hantis пристыковали через уже существовавший механизм оповещения о сборочных заданиях.

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