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

Безопасность приложения – один из основных критериев качества разраба- тываемого продукта. Проверка безопас- ности программы делается на разных этапах различными методиками и инструментами. Программный продукт в зависимости от специфики обсуждения можно описать по-разному: l с точки зрения задействованных спе- циалистов, это результат труда разра- ботчиков, тестировщиков, менеджеров, инженеров развертывания и сопровож- дения и др.; l с точки зрения задействованных систем программный продукт есть результат вычислений IDE, репозито- риев, сборщиков, CI/CD, баг-трекеров и т.д. Для каждого представления создаются свои регламенты и техники обеспечения безопасности. Если рассматривать про- граммный продукт как совокупность уни- кального кода, заимствованного откры- того кода и логики работы программы в соответствии с ее назначением, то его проверку на уязвимости можно пред- ставить тремя способами: 1. Проверка кода без его выполнения. 2. Проверка поведения программы без сканирования исходного кода. 3. Проверка архитектуры и логики. Проверка кода без его выполнения Имеет смысл проверять код програм- мы уже на этапе написания. Это позво- лит на ранних стадиях выявить закрав- шиеся ошибки и уязвимости, в том числе и наследованные из открытого кода. Компоненты Open Source можно прове- рить на наличие известных уязвимостей еще до включения в программный проект или на стадии сборки. В части открытого кода сфокусироваться на первоочеред- ных уязвимостях достаточно просто, так как продвинутые инструменты анализа композиции программ (SCA) идентифи- цируют фактические вызовы уязвимых методов, проще говоря, указывают на потенциально эксплуатируемые уязви- мости. Этап проверки итогового кода программы обычно бывает трудоемким, инструменты статического анализа кода обнаруживают потенциально опасные фрагменты, и приходится разбираться, какие из обнаруженных проблем реаль- ные, а какие для данного проекта не несут угроз. Сканирование кода и про- верка информации об известных уязви- мостях Open Source – разные по своей сути технологии, но обе критично важны для выявления и устранения уязвимостей на ранних стадиях цикла разработки (SDLC), до развертывания приложения. Проверка поведения программы без сканирования исходного кода После создания программы требуется убедиться, что ее фактическое поведе- ние соответствует ожидаемому. Эту задачу решают инструменты динамиче- ского анализа, фаззинг-тестирование, пентесты и др. Множество атак на при- ложения реализуется путем передачи в программу таких данных, при обработке которых возникает неучтенная разра- ботчиками ситуация, впоследствии используемая хакером в своих интере- сах. На этапе проверки поведения про- граммы необходимо предусмотреть воз- можные нарушения такого рода. Про- верка поведения программы необходима не только перед запуском системы в эксплуатацию, ее нужно регулярно про- водить во время работы программы для выявления не обнаруженных ранее бре- шей. Выявление уязвимостей без сканирования кода и его выполнения Эта сложная и неоднозначная анали- тическая задача решается путем диаг- ностики архитектуры программного про- дукта и оценки выбранных схем логиче- ской реализации. Адекватное составле- ние модели угроз на этапе проектиро- вания продукта позволяет предугадать возможные сценарии атак и методы защиты. Это основополагающая про- верка, требующая значительных экс- пертных усилий, она не может быть заменена проверкой кода или тестом поведения программы. Как правило, в начале разработки модель угроз делают, но вот в ходе развития продукта, при добавлении новых фич и выпуске мажор- ных обновлений даже опытные команды время от времени забывают обновить модель угроз, проанализировать новую логику и ее реализацию. Инструменты анализа композиции кода (SCA) Сканирование кода, анализ компози- ции и проверка поведения не заменяют друг друга. Эти технологии вместе на выходе позволяют создавать безопасные программные продукты, но для получе- ния практической пользы должны быть правильно подобраны инструменты без- опасной разработки. Остановимся на одном из типов оценки исходного кода. Инструменты анализа композиции про- граммы зародились на рубеже тысяче- летий на основе методов сканирования кода, которые выявляли фрагменты кода и сопоставляли его с базами данных Open Source. Такие инструменты при- менялись различными компаниями, но они давали существенное количество ложных срабатываний, замедляли рабо- ту, а самое главное – не подходили для гибких сред разработки. Однако потреб- ность в специализированных инстру- ментах контроля Open Source росла и была обусловлена следующими фак- торами: 44 • ТЕХНОЛОГИИ Методы анализа исходного кода о оценке OWASP, почти треть всех веб-приложений содержит серьезные уязвимости, а в отчете Micro Focus 2019 Applica- tion Security Risk Report отмечается, что практически все веб-приложения имеют проблемы с безопасностью. Зная об этом, передовые компании уже давно проводят анализ исходного кода. Если несколько десятков лет назад ошибки в коде нужно было искать вручную или с помощью предупреждений компилятора, то сейчас в распоряжении разработчиков есть множество методик и инструментов – SAST, DAST, анализаторы композиции кода, фаззинг- тестирование, проверки на проникновение и многое другое. С чего же начать “безопасную разработку", о которой столько говорят в профессиональных сообществах? П Дарья Орешкина, директор по развитию бизнеса компании Web Control Безопасность приложения – один из основных критериев качества разрабатываемого продукта.