Как внедрить процессы безопасной разработки и ускорить time-to-market: кейс компании СИГМА
Задачи проекта
Перед компанией СИГМА стояла задача внедрить процессы безопасной разработки с нуля, чтобы обеспечить максимальную защищенность как собственных продуктов, так и заказного ПО. «Информационная безопасность всегда была в центре нашего внимания, и мы решили перейти на новый уровень, внедрив процесс безопасной разработки, — рассказывает Александр Евтеев, директор департамента информационной безопасности СИГМЫ. — Работа началась два с половиной года назад. На тот момент по безопасной разработке у нас не было ни компетенций, ни регламентов, ни инструментов. Мы начали с консалтинга у сторонней компании, отрисовывали процессы разработки, разрабатывали регламенты, собирали команду, тестировали и сравнивали между собой различные решения, подходящие именно нам».
Повышенные требования к информационной безопасности решений внутри энергетического сектора и группы компаний «ИнтерРАО» также стали еще одним фактором внедрения практик DevSecOps. Энергетические компании входят в ТОП-10 отраслей, подверженных рискам кибератак, при этом цена ошибки и влияние ИБ-инцидентов на устойчивость экономики и качество жизни критичны.
Реализация проекта
«Сначала мы проанализировали все процессы разработки, существующие в нашей компании, — поясняет Александр Евтеев. — У СИГМЫ около 30 продуктов, и нам нужно было пообщаться со всеми командами разработки, понять специфику их работы и определить, как наилучшим образом интегрировать практики безопасной разработки».
Определившись с процессами, компания перешла к формированию задач. Нужно было понять, какие специалисты, компетенции и в каком количестве необходимы, какие инструменты нужно использовать. На первом этапе компания сформировала команду экспертов по безопасной разработке, провела обучение разработчиков и в целом сформировала культуру DevSecOps в компании. По итогам было создано отдельное подразделение, в котором сейчас работает 8 специалистов по безопасной разработке.
Особое внимание СИГМА уделила выбору и внедрению инструментов для анализа и контроля безопасности кода.
На старте был составлен список необходимых инструментов, они были разбиты по категориям, и в каждой категории был выбран наиболее подходящий продукт. Первым инструментом, который был внедрен, стал модуль SAST продукта Solar appScreener. Решающим фактором при выборе решения стала поддержка 36 языков программирования, что было критически важным для компании с учетом широкого спектра разрабатываемого ПО. Кроме того, важным аспектом стала возможность анализировать код 1С, так как СИГМА активно использует эту платформу в своих решениях.
«У нас была обширная модель сравнения продукта c open source и другими платными решениями. Solar appScreener оказался лучшим по нашим критериям. Мы интегрировали Solar appScreener с GitLab, начав с одного-двух проектов. Затем настроили интеграцию с Jira, но в итоге перешли на оркестратор, и Solar appScreener стал нашим инструментом статического анализа. Остальные интеграции, управление уязвимостями, запуск сканирований выполняются через оркестратор. Сам инструмент тесно интегрирован во все процессы безопасной разработки и играет одну из ключевых ролей», — поясняет Александр Евтеев.
Александр отмечает, что один из плюсов Solar appScreener — это быстрый старт. Ни инженерам, ни аналитикам не пришлось долго и сложно разбираться в продукте. Юзабилити как технической, так и пользовательской части позволило внедрить инструмент и сразу начать с ним работать.
Также используются и другие инструменты — анализ компонентов, анализ контейнеров, DAST-анализ, фаззинг-тестирование. Система построена на решениях различных вендоров, чтобы охватить все аспекты безопасной разработки.
«Защищенность приложений еще на этапе разработки снижает риски выявления уязвимостей в ПО после выхода продуктов на рынок, особенно, если IT-команды используют компоненты из open source-библиотек. Поэтому в IT-сообществе сформирован запрос на платформы для комплексного анализа кода, включая инструменты SAST, DAST, SCA и SCS, доступные в одном интерфейсе. Подобные решения также позволяют оптимизировать ресурсы команды ИБ и разработчиков, благодаря автоматизации анализа кода и контролировать работу подрядчиков, которые занимаются разработкой ПО», — подчеркивает Антон Прокофьев, эксперт по контролю безопасности ПО Solar appScreener ГК «Солар».
Чтобы снизить риски выявления уязвимостей программного обеспечения после выхода продуктов на рынок и начала их использования, команды ИБ и разработчики должны позаботиться о защищенности приложений еще на этапе их создания. В этом поможет комплекс проверок, включающий такие виды анализа, как SAST, DAST, SCA, SCS. Такие инструменты есть в Solar appScreener — платформе для комплексной проверки безопасности ПО, поддерживающей тридцать шесть языков программирования. Это единственное на рынке российское решение, которое включает сразу четыре вида анализа кода в одном интерфейсе, а сам интерфейс удобен и понятен всем категориям пользователей — от разработчиков до сотрудников службы ИБ.
Несмотря на то, что добавились дополнительные этапы проверки безопасности, фактически время вывода продуктов на рынок (time-to-market) сократилось потому, что приложения проходят меньше итераций устранения уязвимостей. Сейчас команда разработки СИГМА использует Solar appScreener для анализа 16 групп проектов, которые разрабатываются на более 10 языках программирования.
По словам Александра, весь процесс внедрения практики безопасной разработки занял около полугода. «Внедрение процесса прошло у нас довольно быстро — примерно за 6 месяцев, — говорит он. — Конечно, компания продолжает совершенствовать свои процессы, но фундамент был заложен именно в этот период».
Планы и перспективы
«Сейчас мы работаем над улучшениями, — рассказывает Александр Евтеев, — Оптимизируем настройки внедренных инструментов, постоянно дорабатываем правила, автоматизируем рутинную работу экспертов, расширяем программу внутреннего обучения для разработчиков».
Помимо этого, в компании внедряются дополнительные механизмы, которые позволят минимизировать количество ложно позитивных срабатываний. В планах также развитие других практик, например, безопасность сред контейнеризации.
«Компаниям, которые только начинают свой путь к безопасной разработке, я бы рекомендовал начать с подбора лидеров и опытных экспертов по безопасной разработке, которые смогут выстроить процесс, — советует Александр Евтеев. — Сначала люди, потом процессы, потом инструменты. Важно также наладить взаимодействие с командами разработки – это самый сложный и болезненный для всех этап, но в результате у вас появится команда, создающая не только функциональные, но и безопасные продукты».