В рубрику "Разработка" | К списку рубрик | К списку авторов | К списку публикаций
Реализация рисков на этапе эксплуатации может привести к серьезному финансовому и репутационному ущербу. Финансовый ущерб, как правило, включает в себя затраты на устранение уязвимости и выпуск новой версии программы, а также упущенную выгоду, которая может стать следствием снижения интереса клиентов к небезопасному приложению. Безопасная разработка программного обеспечения (Secure Software Development Lifecycle – SSDL) представляет собой подход, нацеленный на своевременное выявление и устранение уязвимостей в исходном коде. Построение SSDL силами разработчика программного обеспечения является наиболее верным решением, ведь именно разработчик заинтересован в снижении накладных расходов на поддержание продукта.
Стоимость устранения уязвимости на этапе разработки, как правило, сводится к затратам разработчика на проведение аналитики, выполнение необходимых изменений в исходном коде и проведение повторной проверки. Если же уязвимость была выявлена на этапе промышленной эксплуатации, то к указанным ранее затратам могут добавиться:
Учитывая, что выявление критической уязвимости вносит существенные коррективы в расстановку приоритетов по доработке, сроки вывода нового функционала в промышленную эксплуатацию могут существенно измениться.
Стоит отметить, что внедрение SSDL является обязательным при разработке приложений, осуществляющих обработку банковских карт и пр.
В сложившейся практике внедрение SSDL сводится к включению средства статического анализа исходного кода (Static Application Security Testing – SAST) в процесс тестирования приложения. Как правило, тестирование безопасности приложения осуществляется одновременно с функциональным тестированием (Quality Assurance – QA). То есть если приложение успешно проходит все проверки, его можно отправлять в промышленную эксплуатацию.
При построении процесса непрерывной безопасной разработки обязательно используются три основных компонента:
Существуют риски, связанные с уязвимостями, появившимися на этапе разработки программного обеспечения, и проведение статического анализа исходного кода приложения позволяет сравнительно быстро их выявить. Рассмотрим, какие недостатки исходного кода встречаются и к чему приводит их упущение:
Чтобы не допустить присутствие уязвимостей в исходном коде, во время разработки приложения нужно соблюдать несколько условий и придерживаться следующих этапов:
Существует два основных варианта интеграции статического анализа кода (SAST) в процесс разработки:
При проведении проверки возможен как полный, так и инкрементальный анализ кода. Выполнение полного анализа предполагает ревизию всего исходного кода программы, в то время как при инкрементальном анализе поиск уязвимостей осуществляется только в измененных участках кода. Полный анализ исходного кода обычно выполняется за несколько часов, в то время как инкрементальный занимает не более часа.
Необходимо отметить, что средства SAST могут быть встроены в инструментарий разработчика. Однако важным преимуществом использования отдельного сервиса для проверки безопасности исходного кода является возможность централизованного и независимого от разработчиков контроля отсутствия уязвимостей в нем.
Средства контроля исходного кода, встроенные в инструменты разработки, хоть и позволяют решить задачу проверки на отсутствие уязвимостей, но при этом обладают существенными недостатками:
При построении безопасного программного обеспечения обязательным условием является выделение тестовой среды и среды разработки. Среда разработки используется для создания нового функционала. В тестовой среде необходимо осуществлять функциональное тестирование, а в "боевой среде" должно работать приложение. При этом необходимо выполнять следующие требования:
Использование нескольких распространенных статических анализаторов исходного кода показало практически полную идентичность в получаемых данных об уязвимостях. Следовательно, при выборе системы для статического анализа можно ориентироваться прежде всего на стоимость владения и возможность встраивания в текущие процессы.
В заключение необходимо отметить, что построение процесса безопасной разработки в долгосрочной перспективе окажет положительное влияние на качество разрабатываемого приложения и снизит стоимость его поддержки. При этом в условиях отсутствия принципиальной разницы между используемыми инструментами и подходе к сканированию при построении SSDL необходимо ориентироваться на существующие процессы разработки кода и компетенции сотрудников.
Опубликовано: Журнал "Information Security/ Информационная безопасность" #1, 2020