Методы анализа исходного кода

По оценке OWASP, почти треть всех веб-приложений содержит серьезные уязвимости, а в отчете Micro Focus 2019 Application Security Risk Report отмечается, что практически все веб-приложения имеют проблемы с безопасностью. Зная об этом, передовые компании уже давно проводят анализ исходного кода. Если несколько десятков лет назад ошибки в коде нужно было искать вручную или с помощью предупреждений компилятора, то сейчас в распоряжении разработчиков есть множество методик и инструментов – SAST, DAST, анализаторы композиции кода, фаззинг-тестирование, проверки на проникновение и многое другое. С чего же начать “безопасную разработку", о которой столько говорят в профессиональных сообществах?

Дарья Орешкина
Директор по развитию бизнеса компании Web Control

Безопасность приложения – один из основных критериев качества разрабатываемого продукта. Проверка безопасности программы делается на разных этапах различными методиками и инструментами. Программный продукт в зависимости от специфики обсуждения можно описать по-разному:

• с точки зрения задействованных специалистов, это результат труда разработчиков, тестировщиков, менеджеров, инженеров развертывания и сопровождения и др.;
• с точки зрения задействованных систем программный продукт есть результат вычислений IDE, репозиториев, сборщиков, CI/CD, баг-трекеров и т.д.

Для каждого представления создаются свои регламенты и техники обеспечения безопасности. Если рассматривать программный продукт как совокупность уникального кода, заимствованного открытого кода и логики работы программы в соответствии с ее назначением, то его проверку на уязвимости можно представить тремя способами:

1. Проверка кода без его выполнения.
2. Проверка поведения программы без сканирования исходного кода.
3. Проверка архитектуры и логики.

Имеет смысл проверять код программы уже на этапе написания. Это позволит на ранних стадиях выявить закравшиеся ошибки и уязвимости, в том числе и наследованные из открытого кода. Компоненты Open Source можно проверить на наличие известных уязвимостей еще до включения в программный проект или на стадии сборки. В части открытого кода сфокусироваться на первоочередных уязвимостях достаточно просто, так как продвинутые инструменты анализа композиции программ (SCA) идентифицируют фактические вызовы уязвимых методов, проще говоря, указывают на потенциально эксплуатируемые уязвимости. Этап проверки итогового кода программы обычно бывает трудоемким, инструменты статического анализа кода обнаруживают потенциально опасные фрагменты, и приходится разбираться, какие из обнаруженных проблем реальные, а какие для данного проекта не несут угроз. Сканирование кода и проверка информации об известных уязвимостях Open Source – разные по своей сути технологии, но обе критично важны для выявления и устранения уязвимостей на ранних стадиях цикла разработки (SDLC), до развертывания приложения.

Проверка поведения программы без сканирования исходного кода

После создания программы требуется убедиться, что ее фактическое поведение соответствует ожидаемому. Эту задачу решают инструменты динамического анализа, фаззинг-тестирование, пентесты и др. Множество атак на приложения реализуется путем передачи в программу таких данных, при обработке которых возникает неучтенная разработчиками ситуация, впоследствии используемая хакером в своих интересах. На этапе проверки поведения программы необходимо предусмотреть возможные нарушения такого рода. Проверка поведения программы необходима не только перед запуском системы в эксплуатацию, ее нужно регулярно проводить во время работы программы для выявления не обнаруженных ранее брешей.

Выявление уязвимостей без сканирования кода и его выполнения

Эта сложная и неоднозначная аналитическая задача решается путем диагностики архитектуры программного продукта и оценки выбранных схем логической реализации. Адекватное составление модели угроз на этапе проектирования продукта позволяет предугадать возможные сценарии атак и методы защиты. Это основополагающая проверка, требующая значительных экспертных усилий, она не может быть заменена проверкой кода или тестом поведения программы.

Безопасность приложения – один из основных критериев качества разрабатываемого продукта.

Как правило, в начале разработки модель угроз делают, но вот в ходе развития продукта, при добавлении новых фич и выпуске мажорных обновлений даже опытные команды время от времени забывают обновить модель угроз, проанализировать новую логику и ее реализацию.

Инструменты анализа композиции кода (SCA)

Сканирование кода, анализ композиции и проверка поведения не заменяют друг друга. Эти технологии вместе на выходе позволяют создавать безопасные программные продукты, но для получения практической пользы должны быть правильно подобраны инструменты безопасной разработки. Остановимся на одном из типов оценки исходного кода.

Инструменты анализа композиции программы зародились на рубеже тысячелетий на основе методов сканирования кода, которые выявляли фрагменты кода и сопоставляли его с базами данных Open Source. Такие инструменты применялись различными компаниями, но они давали существенное количество ложных срабатываний, замедляли работу, а самое главное – не подходили для гибких сред разработки. Однако потребность в специализированных инструментах контроля Open Source росла и была обусловлена следующими факторами:

1. DevOps, контейнеры на основе Linux и т.д. привели к значительному росту использования Open Source при разработке.
2. Как и коммерческое ПО, открытый исходный код содержит уязвимости. Недостаток данных о том, как и какие компоненты используются, привел к тому, что компании неосознанно подвергаются значительному риску.
3. Отсутствие полной информации, политик или процессов управления компонентами Open Source привели к тому, что проверка на уязвимости проводится от случая к случаю (или вообще отсутствует), а при публикации информации о найденной уязвимости для исправления затрачиваются большие усилия.
4. Зрелые компании расширяют свои возможности по управлению Open Source и проводят анализ работоспособности всей программы на основе происхождения конкретного компонента и его поддержки.
5. Те, кто профессионально занимаются взломами ИТ-систем, нацеливаются на репозитории компонентов с открытым кодом и инфицируют их, обеспечивая попадание вредоносного кода на раннем звене цепочки поставки ПО.

Три способа проверки на уязвимость:

1.  Проверка кода без его выполнения.
2.  Проверка поведения программы без сканирования исходного кода.
3.  Проверка архитектуры и логики.

Развитый функционал для поиска уязвимых компонентов

Со временем системы проверки Open Source переродились в инструменты непрерывного управления компонентами Open Source, интегрируемыми с различными инструментами разработки – репозиториями, инструментами сборки, серверами непрерывной интеграции. Переход к обнаружению уязвимостей и проблем с лицензированием в режиме реального времени позволил управлять открытым исходным кодом и идентифицировать проблемы на более ранних этапах процесса, когда их легче и быстрее устранить.

Функционал подобных инструментов довольно широк. Инструменты анализа композиции приложения проводят инвентаризацию всех компонентов Open Source в приложении, включая прямые и транзитивные зависимости, и предоставляют информацию о каждом компоненте, в том числе данные о лицензии и наличии уязвимостей.

Инструменты с наиболее развитым функционалом, в частности WhiteSource, способны снизить число уведомлений об уязвимостях в компонентах Open Source на 70% благодаря запатентованным алгоритмам приоритизации по фактическим вызовам уязвимых методов.

Сканирование кода, анализ композиции и проверка поведения не заменяют друг друга. Эти технологии вместе на выходе позволяют создавать безопасные программные продукты.

WhiteSource агрегирует информацию об уязвимостях из разных источников в собственную базу данных и предлагает разработчикам на выбор варианты исправления, от ссылок на обновления до рекомендаций по изменению системных настроек и блокировки различных функций.

Крылатое выражение "время – деньги" как нельзя лучше характеризует ситуацию с разработкой ПО. От разработчиков требуют нереальных, на первый взгляд, вещей: сделать продукт быстро и при этом чтобы он получился безопасным. В таких условиях не обойтись без автоматизации. WhiteSource может автоматизировать весь процесс отбора, утверждения и отслеживания компонентов Open Source, автоматически применять политики для блокировки уязвимого или проблемного компонента.

Лицензионная чистота

Использование Open Source поднимает еще один вопрос, требующий внимания команды разработки, – о лицензионной чистоте. Каждый компонент Open Source, а также любой компонент, от которого он может зависеть, имеет лицензию, условия которой нужно соблюдать. Существует свыше 200 различных лицензий Open Source, у каждой из которых свои условия. Выбор компонента с неподходящей лицензией может привести к самым разным последствиям, от необходимости изменения компонента до судебного иска о нарушении авторских прав. SCA-решение также призвано автоматизировать процесс соблюдения лицензионной чистоты, чтобы освободить разработчиков от несвойственных им задач.

Полный контроль на всех этапах

Сообщество разработчиков Open Source выполняет грандиозную работу в части безопасности проектов, обнаруживая уязвимости и предлагая исправления, но Open Source децентрализован по своей природе. Информация об уязвимостях компонентов публикуется на разных ресурсах, и просто невозможно вручную сопоставлять уязвимые компоненты с используемыми в своей разработке. WhiteSource на всех этапах SDLC, от выбора компонентов с открытым кодом до мониторинга релизов в эксплуатации, позволяет отслеживать уязвимости и лицензионные соглашения Open Source.