Журнал "Information Security/ Информационная безопасность" #1, 2020

6. Неиспользуемые участки кода, которые могут содержать логические бомбы или бэкдоры. В рамках слож- ных атак неиспользуемые участки кода могут быть незаметно изменены злоумышленником и использованы для манипуляции приложением. Как создать безопасное ПО? Чтобы не допустить присутствие уязви- мостей в исходном коде, во время раз- работки приложения нужно соблюдать несколько условий и придерживаться следующих этапов: 1. Разработка. На данном этапе создается новый функционал, про- веряется корректность его работы и сохраняется в основной проект (Сommit) в GIT. Хорошим тоном считается регулярное создание резервных копий репозитория, что позволяет снизить риск утраты важ- ного актива. 2. Сборка. После накопления необхо- димого количества изменений по реше- нию руководителя проекта в CI осу- ществляется сборка нового релиза про- екта. 3. Контроль. На данном этапе собран- ный релиз отправляется на функцио- нальное тестирование и проверку без- опасности. Все испытания должны обя- зательно выполняться в тестовой среде и с использованием тестовых данных. По результатам испытаний формиру- ется заключение о возможности про- мышленной эксплуатации новой версии программы. 4. Промышленная эксплуатация. Если проект успешно прошел все про- верки, тогда он передается в промыш- ленную эксплуатацию, т.е. выпускается новая версия программы. В свою оче- редь, сборка и внедрение новой версии программы обеспечивается системами CI/CD (Сontinuous Integration/Either Con- tinuous Delivery or Continuous Deploy- ment). Наиболее распространенные системы данного класса обладают всем необходимым функционалом для обеспечения хранения исходного кода, сборки новых версий, запуска задач тестирования и внедрения новых вер- сий программы. Роль SAST в создании безопасного приложения Существует два основных варианта интеграции статического анализа кода (SAST) в процесс разработки: 1. Наиболее правильным является выполнение статического анализа сразу после сборки релиза приложе- ния. В данном случае CI передает собранный релиз на функциональное тестирование и на проверку безопас- ности. Если в приложении не выявле- ны функциональные нарушения или уязвимости, CI осуществляет выпуск приложения в промышленную экс- плуатацию. 2. Если процесс непрерывной раз- работки уже выстроен и функциони- рует исправно, то есть смысл в реа- лизации параллельной проверки исходного кода. При таком подходе сканер исходного кода осуществляет регулярную проверку репозитория приложения (как правило, ветки Мaster) на наличие уязвимостей. Чаще всего сканирование осуществляется по рабочим дням в часы наименьшей нагрузки, как правило ночью. Отчет о результатах такого исследования направляется ответственным сотруд- никам, которые могут принять реше- ние о необходимости оперативного устранения уязвимости. При проведении проверки возможен как полный, так и инкрементальный анализ кода. Выполнение полного ана- лиза предполагает ревизию всего исходного кода программы, в то время как при инкрементальном анализе поиск уязвимостей осуществляется только в измененных участках кода. Полный анализ исходного кода обычно выполняется за несколько часов, в то время как инкрементальный занимает не более часа. Необходимо отметить, что средства SAST могут быть встроены в инструмен- тарий разработчика. Однако важным преимуществом использования отдель- ного сервиса для проверки безопасности исходного кода является возможность централизованного и независимого от разработчиков контроля отсутствия уязвимостей в нем. Средства контроля исходного кода, встроенные в инструменты разработки, хоть и позволяют решить задачу про- верки на отсутствие уязвимостей, но при этом обладают существенными недостатками: l невозможно провести сопоставле- ние выполненной проверки с кон- кретными релизами программы в GIT; l при большом количестве разработчи- ков нет возможности осуществить опе- ративный контроль, чтобы отследить, проверялся ли исходный код и каков был результат. Тестирование при разработке безопасного ПО При построении безопасного программ- ного обеспечения обязательным условием является выделение тестовой среды и среды разработки. Среда разработки используется для создания нового функ- ционала. В тестовой среде необходимо осуществлять функциональное тестиро- вание, а в "боевой среде" должно работать приложение. При этом необходимо выпол- нять следующие требования: 1. Запрещается использовать одни и те же данные в процессах разработки, тестиро- вания и эксплуатации. При нарушении этого требования возможны риски несанкциони- рованного доступа к "боевому приложению" через тестовые учетные записи, а также риск разглашения конфиденциальной инфор- мации, используемой для тестирования. 2. Необходимо обеспечить техниче- скую идентичность всех сред функцио- нирования приложения для обеспечения релевантности результатов. 3. Необходимо обеспечить версиони- рованность приложения для четкой иден- тификации результатов разработки и тестирования. Использование нескольких распро- страненных статических анализаторов исходного кода показало практически полную идентичность в получаемых дан- ных об уязвимостях. Следовательно, при выборе системы для статического анализа можно ориентироваться прежде всего на стоимость владения и возмож- ность встраивания в текущие процессы. В заключение необходимо отметить, что построение процесса безопасной разра- ботки в долгосрочной перспективе окажет положительное влияние на качество раз- рабатываемого приложения и снизит стои- мость его поддержки. При этом в условиях отсутствия принципиальной разницы между используемыми инструментами и подходе к сканированию при построении SSDL необходимо ориентироваться на суще- ствующие процессы разработки кода и ком- петенции сотрудников. l • 43 РАЗРАБОТКА www.itsec.ru Рис. 2. Процесс разработки безопасного программного обеспечения Ваше мнение и вопросы присылайте по адресу is@groteck.ru