Статическое тестирование безопасности приложений (SAST)

SAST расшифровывается как Static Application Security Testing (статическое тестирование безопасности приложений), но этой аббревиатурой обозначается не само статическое тестирование, а необходимые для его выполнения инструменты. Инструмент SAST может анализировать код, двоичные файлы и даже байт-код на предмет наличия потенциальных проблем, связанных с безопасностью. Каждый инструмент обладает своим набором функций, поэтому перед покупкой следует опробовать выбранный вариант. При оценке кода инструмент SAST разбирает его, как компилятор, но не разбивает его на байты для запуска на сервере, а ищет возможные риски, связанные с обеспечением безопасности: от выявления известного уязвимого класса или функции до предупреждения об отсутствии или неправильной реализации средств контроля безопасности, утечках памяти, неиспользуемых переменных или функциях, низком качестве кода и т. д.

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

Тем не менее многие инструменты SAST выдают очень большое количество ложноположительных результатов.

ПРИМЕЧАНИЕ. Ложное срабатывание инструмента тестирования безопасности означает, что оно сообщило о наличии уязвимости, которая таковой не является. В случае ложноотрицательного результата инструмент пропускает уязвимость. Все инструменты выдают оба типа результатов, но в идеале ожидается как можно больше истинно положительных (инструмент сообщает об обоснованных уязвимостях) и истинно отрицательных (он ничего не пропустил).

Да, вы все правильно поняли. Инструменты SAST выдают самое большое количество ложноположительных результатов среди всех инструментов тестирования безопасности приложений, даже больше, чем при ручной проверке кода. Почему?

Первая причина заключается в том, что можно выбрать довольно строгие настройки инструмента и заставить его показывать только то, что он считает истинно положительным. В таком случае он не покажет уязвимости, в которых не будет почти полностью уверен, и пропустит множество из них, что приведет к огромному количеству ложноотрицательных результатов. Инструмент заметит потенциальную проблему, но не сообщит о ней. Вполне вероятно, что таким образом большинство проблем в приложении останутся незамеченными. Если вы хотите обеспечить безопасность ПО, такое решение будет далеко от идеала.

ПРИМЕЧАНИЕ. Некоторые инструменты SAST выполняют «символическое исполнение», то есть анализируют программы, чтобы определить, какие входные данные вызывают исполнение каждой ее части. Интерпретатор принимает символические значения вместо фактических входных данных, с которыми программа работала бы в нормальных условиях («Википедия»).

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

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

Заменить ручной обзор кода инструментом SAST не получится, так как они подразумевают проведение разных видов анализа и получение разных результатов. Автоматический анализ кода обычно не способен выявить недостатки бизнес-логики: он просто не понимает данное условие. Таким образом, рекомендуется комбинировать два этих подхода, чтобы увеличить охват проверки и найти максимальное количество уязвимостей.

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

Эффективность SAST сильно варьируется в зависимости от поддерживаемых технологий. Необходимо тщательно оценить инструмент, прежде чем решиться на его покупку. Большой список существующих бесплатных и платных инструментов доступен на сайте owasp.org/www.community/Source_Code_Analysis_Tools.

ВНИМАНИЕ. В настоящее время ни один автоматизированный инструмент (любого типа) не может обеспечить 100 %-ную точность при поиске уязвимостей, поэтому ни в коем случае нельзя передавать непроверенные результаты команде разработчиков или регистрировать ошибки в своем баг-трекере. Когда вы тратите время разработчиков на ложные срабатывания, их доверие к вам падает. Всегда проверяйте результаты, полученные с помощью любого автоматизированного инструмента, прежде чем передавать их другой команде.

Анализ состава программного обеспечения (SCA)

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

Лучший способ обеспечить безопасность кода от сторонних разработчиков – это выполнение SCA.

Согласно нескольким интернет-источникам, анализ состава программного обеспечения (англ. Software Composition Analysis, SCA) – это процесс автоматизации контроля использования программного обеспечения с открытым исходным кодом (англ. open source software, OSS) с целью управления рисками, обеспечения безопасности и соблюдения лицензионных требований. Однако данное определение является не совсем полным, так как инструменты SCA сообщают также о несвободных (с закрытым исходным кодом) библиотеках и платформах.

В большинстве крупных компаний с несколькими командами разработчиков в штате нет ни полного реестра веб-приложений (списка всего созданного программного обеспечения), ни соответствующей спецификации материалов программного обеспечения (англ. software bill of materials, SBoM) (перечня всех компонентов и версий) для каждого из этих активов. Инструмент SCA может создать SBoM и автоматизировать процесс его поддержки в актуальном состоянии. SBoM нужен для того, чтобы иметь правильное представление об имеющихся различных компонентах и средствах защиты. Если в платформе А версии Б обнаруживается уязвимость, необходимо как можно скорее узнать, используется ли в производстве эта платформа данной версии. Такую информацию SBoM может сообщить немедленно.

Инструменты SCA работают на основе списка «известных уязвимостей», который может быть составлен различными способами: через сбор информации из публичных списков, через покупку списков других компаний, через наем исследователей безопасности для анализа популярных платформ и компонентов, через использование автоматизированных инструментов для анализа компонентов, через подписку на рассылки по теме обеспечения безопасности от разработчиков компонентов. Некоторые компании-разработчики позволяют производителям инструментов, правительствам или крупным компаниям подписываться на их списки напрямую (обычно за определенную плату).

Инструменты SCA можно автоматизировать так, чтобы они и направляли на репозиторий кода (место хранения всего исходного кода), и запускались при развертывании нового кода (в идеале – автоматизированно в конвейере CI/CD). Планирование регулярного сканирования репозитория кода требует доступа только для чтения и может помочь подтвердить адекватный уровень безопасности всех приложений, включая устаревшие. Даже если приложение очень давно не обновлялось, его компоненты все равно могут находиться под пристальным вниманием злоумышленников и перейти из списка «ОК» в «известную уязвимость». Вот почему очень важно сканировать код инструментом SCA, даже если он не менялся в течение длительного времени. Безопасность кода должна обеспечиваться и на этапе эксплуатации.

Перед релизом код также необходимо просканировать. Можно обновить уже существующий компонент или добавить новый, но есть вероятность, что даже эта новая конкретная версия будет «заведомо уязвимой». Когда выходит новая версия, исследователи безопасности и злоумышленники часто проверяют ее на наличие проблем, связанных с обеспечением безопасности, поэтому в первые несколько дней после релиза в продуктах, патчах и платформах часто обнаруживаются новые уязвимости. Использование инструмента SCA для проверки даже новых компонентов повышает безопасность программного обеспечения.

Некоторые инструменты SCA также предлагают интеграцию с IDE (Integrated development environment – интегрированной средой разработки). Интеграция проксирует IDE и тем самым гарантирует, что разработчики могут загружать пакеты только из своего репозитория предварительно одобренных пакетов. Этой услугой необходимо воспользоваться, если она предлагается в приобретенном офисом инструменте SCA. Она позволяет предотвратить ошибки, связанные с обеспечением безопасности (что даже лучше, чем их поиск и исправление).

Онлайн-список различных инструментов SCA (платных и бесплатных) можно найти на сайте owasp.org/www-community/Component_Analysis#tools-listing.