Безопасная разработка является насущной потребностью для многих компаний, которые создают ПО под заказ или для самих себя. Своевременные поиск и устранение уязвимостей позволяют сократить сроки выхода продукта, сократить ИБ-риски и минимизировать затраты на его доработку.
- Введение
- Основные этапы процесса безопасной разработки
- Инструменты, применяемые в DevSecOps
- Применение Solar appScreener при построении процесса безопасной разработки
- Выводы
Введение
Безопасная разработка, DevSecOps, направлена на автоматизацию процессов информационной безопасности и внедрение контроля защищённости на ранних этапах создания программных продуктов.
Согласно статистике, под угрозой взлома находятся около 90 % российских мобильных программных продуктов, а в ходе одного из экспериментов было успешно взломано 98 % веб-приложений.
В исследовании Ponemon Institute и Rezilion 78 % респондентов отметили, что на устранение уязвимостей высокого риска в их информационных средах уходит более трёх недель, а 30 % сообщили, что работа с уязвимостями занимает более пяти недель.
Уязвимости в приложениях стали основным вектором политически мотивированных атак в отношении веб-ресурсов госорганов РФ и отечественных компаний. Участились попытки внедрения и активации недекларированных возможностей в открытом коде (Open Source) по географическому признаку.
Откуда берутся уязвимости и недекларированные возможности в программном коде приложений? Во-первых, вследствие особенностей разработки: использования небезопасных языковых конструкций, сторонних компонентов (фреймворков, библиотек), встраивания закладок для ускорения разработки. Во-вторых, дефицит времени приводит к тому, что обзор (review) кода проводится быстро, с упором на функциональность, в то время как требуется качественный анализ с большим вниманием в том числе и к безопасности. В-третьих, распространено использование унаследованного (legacy) ПО, содержащего общеизвестные уязвимости, а также такого, которое сложно или невозможно обновить.
Безопасная разработка не остаётся без внимания регуляторов, требования к ней можно найти в приказе ФСТЭК России № 239, ГОСТ № 56939-2016, ГОСТ № 58412-2019, положениях Банка России № 719-П, 757-П, 683-П.
Основные этапы процесса безопасной разработки
Применение DevSecOps позволяет поддерживать необходимый уровень безопасности во время разработки и всего срока эксплуатации программного обеспечения. Также этот подход фокусируется на идентификации рисков и управлении ими. Результатом внедрения процесса безопасной разработки является сокращение количества уязвимостей на 80 %. Рассмотрим основные этапы процесса на примере подхода Security Development Lifeсycle (SDLC), ставшего стандартом для многих крупных корпораций во всём мире.
Рисунок 1. Security Development Lifeсycle (SDLC)
Обучение (Training)
Все сотрудники, а также подрядчики и иные лица, задействованные в разработке ПО, проходят обучение основам кибербезопасности и регулярные тренинги в области безопасной разработки.
Требования (Requirements)
Работа над каждым продуктом, разрабатываемым в компании, начинается с чёткого определения требований к безопасности. Требования определяются на основе таких факторов, как тип данных, которые будут обрабатываться в продукте, известные угрозы, лучшие практики, правила и отраслевые требования, а также выводы по итогам предыдущих инцидентов.
Дизайн (Design)
На этом этапе проектируются модели угроз, которые помогают идентифицировать и классифицировать угрозы в соответствии с существующими рисками. Модели угроз необходимо поддерживать и обновлять на протяжении всего жизненного цикла каждого продукта по мере внесения изменений в программное обеспечение.
Реализация (Implementation)
Этап реализации характеризуется тестированием кода на уязвимости, в том числе с применением инструментов статического анализа.
Верификация (Verification)
На этапе верификации проводится процедура фаззинга, динамического тестирования кода, а также пересмотра потенциальной площади атаки.
Выпуск (Release)
Перед выпуском ПО в продуктив производится финальная проверка того, соответствуют ли фактически реализованные требования по безопасности заявленным на этапе проектирования, готовится план реагирования на случай возникновения инцидента в ИБ.
Реагирование (Response)
Этап реагирования заключается в выполнении плана, разработанного на предыдущем этапе.
Инструменты, применяемые в DevSecOps
Статический анализ кода (SAST)
Статический анализ проводится в режиме «белого ящика» и позволяет находить уязвимости без фактического выполнения базового кода. Этот инструмент характеризуется следующими особенностями: на ранних этапах выявляется максимальное количество уязвимостей за счёт анализа исходного кода, есть возможность встраивания анализатора в конвейер (pipeline), инкрементального сканирования. Имеются у него и недостатки — например, большая доля ложных срабатываний.
Рисунок 2. Особенности внедрения SAST на различных этапах разработки системы
Внедрять статический анализатор кода оптимальнее по концепции Shift Left, т. е. вводя проверки по ходу разработки продукта, а не по её окончании. Это прямым образом будет влиять на стоимость исправления выявленных дефектов. Например, если предположить, что стоимость исправления выявленных уязвимостей на стадии разработки проекта оценивается в X рублей, то закрытие брешей на этапе приёмки проекта будет стоить 10Х, а на этапе функционирования системы — 100Х рублей.
В случае если проект ведётся внешней компанией, SAST не получится внедрить в процесс разработки — придётся анализировать исходный код вручную по мере предоставления его заказчику.
Динамический анализ кода (DAST)
Динамический анализ кода проводится в режиме «чёрного ящика», когда исходный код неизвестен инструменту, а тестирование осуществляется во время выполнения программы. DAST при этом имитирует вредоносные внешние атаки, использующие распространённые векторы для компрометации приложения. Инструмент характеризуется следующими особенностями: его можно использовать при отсутствии исходного кода, он не привязан к языкам программирования, обладает минимальным количеством ложных срабатываний. Из недостатков — большое количество пропущенных уязвимостей и недекларированных возможностей из-за неполного охвата анализируемого кода.
Анализ компонентов с открытым исходным кодом (OSA)
OSA включает в себя несколько составляющих: композиционный анализ (Software Composition Analysis, SCA), проверку лицензионных рисков (License Risks, LR), обеспечение безопасности цепочек поставок (Supply Chain Security, SCS). SCA используется для определения компонентов с открытым исходным кодом, из которых состоит программное обеспечение, и проверки их безопасности. LR применяется для анализа юридических рисков, связанных с лицензированием открытых компонентов. SCS необходим для анализа безопасности компонентов на всех этапах пути, по которому ПО попадает в организацию, от момента их создания или покупки до этапа использования. OSA позволяет также заменить те или иные компоненты, если исправить их недостатки невозможно.
Применение Solar appScreener при построении процесса безопасной разработки
На рынке ИБ не так много продуктов, которые можно было бы комплексно использовать для реализации процесса безопасной разработки. Один из них — Solar appScreener, который включает в себя SAST, DAST и SCS и SCA, позволяет встраиваться в цикл безопасной разработки программного обеспечения и обучать сотрудников основам DevSecOps.
Solar appScreener поддерживает 36 языков программирования. Для минимизации количества как пропущенных уязвимостей в коде, так и ложных срабатываний в продукте реализована запатентованная технология Fuzzy Logic Engine, использующая математический аппарат нечёткой логики и являющаяся технологическим ноу-хау ГК «Солар».
Рассмотрим пример интеграции appScreener в SDLC. Схема процесса разработки ПО изображена на рисунке 3.
Рисунок 3. Интеграция appScreener в процесс безопасной разработки
Как видно, после сборки проекта в CI выполняются плановые статические проверки (SAST / SCA). Результаты верифицируются командой ИБ.
Рисунок 4. Результат анализа средствами SCA
Рисунок 5. Результат анализа средствами SAST
В Jira формируются заявки на корректировку кода. После исправления уязвимостей разработчиками проект снова отправляется в CI, откуда попадает в тестовое окружение. Следующим шагом является динамическое сканирование приложения на уязвимости (DAST).
Рисунок 6. Результаты анализа DAST
После динамического тестирования снова наступает этап верификации полученных результатов командой ИБ и формирования заявок на исправление уязвимостей.
После того как результаты всех сканирований станут удовлетворительными, приложение будет передано на следующие этапы жизненного цикла (предпродуктив, продуктив).
Выводы
Для обеспечения безопасности разрабатываемого ПО оптимальным является внедрение сначала процессов DevSecOps как таковых, а уже потом — конкретных инструментов для анализа кода. При этом целесообразно внедрять инструментарий комплексно: и SAST, и DAST, и OSA. Это необходимо для проверки кода в разных режимах работы и выявления большего количества уязвимостей и недекларированных функций. Если же нет возможности внедрить все инструменты сразу, то рекомендуется в первую очередь включить SAST и OSA. Внедрение и использование продукта с функциональными возможностями SAST, DAST и OSA, представленного на отечественном рынке, мы рассмотрели на примере Solar appScreener.
