Ярослав Александров, 22/07/19
Переход в digital-сегмент банков, ритейла, медицины и других жизненно важных отраслей производства и обслуживания спровоцировал многочисленные угрозы в плане безопасности. Сегодня во всем мире продолжает расти активность злоумышленников, а вопросы защиты пользовательских и корпоративных данных от кражи и намеренного повреждения все чаще становятся предметом обсуждения профессионалов.
Как бизнесу и ИТ правильно интегрировать безопасность в процесс разработки, какие инструменты для этого лучше использовать, как это все ложится на реальную практику внедрения. Делимся подходами Ростелеком, М.Видео-Эльдорадо, DD Planet, AGIMA.
Ярослав Александров, руководитель отдела разработки Solar appScreener в Ростелеком
С ростом компании и увеличением числа разработчиков проверять продукт на уязвимости “вручную” становится все сложнее. Приходится использовать SAST — средства статического тестирования защищенности приложений (Static Application Security Testing). В Solar appScreener информационная безопасность строится на базе внутреннего продукта. Продукт анализирует исходные коды. На сегодня поддерживается 26 языков программирования, исходники которых могут быть проанализированы уязвимость, и поддерживает все популярные форматы и системы управления проектами.
Как выбрать SAST?
Даже простую уязвимость невозможно отыскать при помощи примитивных алгоритмов. Сегодня на рынке представлена масса SAST-решений, как платных, так и бесплатных. Самые популярные из них — AppScan от IBM Security, Synopsys, Veracode, Application Inspector, Micro Focus, Appercut, Checkmarks.
От выбора инструмента зависит эффективность процесса разработки. Главные преимущества платных решений:
- Фокус на безопасность: специфические алгоритмы и большие базы правил.
- Поддержка множества языков программирования.
- Удобный интерфейс.
- Наличие плагинов и API.
- Наличие технической поддержки инструмента.
Бесплатные инструменты и веб-интерфейсы чаще всего уступают платным, ведь в них заложены более простые алгоритмы, а базы правил — менее полные. Их главная задача — поиск ошибок в коде. Специализация и функциональность таких решений обычно очень узкая.
После того как SAST-решение выбрано, нужно интегрировать его в процесс разработки. Возможности интеграции могут быть следующими: встраивание инструмента в репозиторий, среды разработки, серверы CI/CD, системы отслеживания задач. Хороший инструмент способен успешно встраиваться во все перечисленные классы систем.
Примечание: открытый API SAST включает JSON API и CLI и предоставляет широкие возможности по дополнительной интеграции и автоматизации.
Чтобы выбрать инструмент, наиболее полно удовлетворяющий целям и задачам разработчика, нужно провести их функциональное сравнение и сравнение по качеству.
Функциональное сравнение осуществляют по нескольким параметрам: анализируют удобство интерфейса и удобство интеграции с собственными инструментами. При этом важно проводить поверку именно на своих кодах.
Следующим этапом проводят сравнение по качеству: анализируют уязвимости и ложные срабатывания применительно к собственному коду.
Нюансы и тонкости анализа кода
Чем раньше найдена уязвимость, тем дешевле она обходится разработчику и заказчику. Это значит, что продукт нужно периодически проверять на уязвимости в процессе разработки и дополнительно проводить контрольные проверки перед релизом.
Скорость и ресурсы: обычно ожидается, что инструмент будет работать быстро; запускаться на каждое изменение; показывать «на лету», кто и когда внес уязвимость. На самом деле SAST анализирует код не менее 8 часов, его сложно запускать на каждое изменение; трудно определить автора уязвимости; случаются ложные срабатывания. А значит, возникает вопрос: как настроить DevSecOps.
Здесь очень важно:
- Рассчитать время и ресурсы на анализ вашего кода.
- Определить триггеры запуска сканирования по результатам.
- Иметь в виду, что мощность нужно будет периодически пересчитывать.
- Лучше применять инкрементальный анализ, но делать это нужно с осторожностью, поскольку уязвимости могут теряться.
К примеру, можно запускать тестирование с помощью SAST, когда разработчик отправляет задачу на ревью. Можно также запускать сканирование и по окончании рабочего дня.
Еще одна проблема — ложные срабатывания и попадание в отчет информации о множественных уязвимостях. В этом случае разработчика рекомендуется: произвести фильтрацию в статических анализаторах по уязвимостям и по файлам. Можно исключать библиотеки, анализировать критичность, добавлять исключения по определенным параметрам. Такую работу достаточно сделать всего один раз, чтобы в дальнейшем информация о ложных срабатываниях не попадала в отчеты. Важно также убедиться, что не появляется новых уязвимостей и постепенно в фоновом режиме разобрать уже имеющуюся базу уязвимостей.
Работая над интеграцией SAST в процесс разработки, важно внедрять процессы постепенно без блокирования релиза. Последовательность процесса может быть такой:
- Выбор инструмента.
- Описание процесса (создание регламента).
- Описание технических решений.
- Проведение работ по внедрению.
- Опытная эксплуатация.
Начинать лучше с наиболее критичных систем: важно устранить новые уязвимости, провести проектирование, внедрить регламенты и технические решения.
В регламенте нужно обязательно обозначить :
- Шаги проверки кода на уязвимости.
- Ответственного за запуск сканирования.
- Роли и результаты.
- Как будет налажен процесс коммуникации.
- Service Level Agreement.
- Ответственных за контроль процесса.
- Порядок добавления новых систем к процессу.
Данный подход позволяет осуществить внедрение SAST в процесс разработки за один календарный год. При этом важно учесть все изменения и риски.
Итоговые рекомендации:
- Используйте SAST на каждом этапе разработки.
- Адаптируйте интеграцию под ваш код и ваш процесс.
- Начните с устранения новых уязвимостей.
- Постепенно устраняйте старые уязвимости.
- Создавайте процесс на основе SAST.
- Внедряйте постепенно, начиная без влияния на релизы.
