Вы выкатываете новую фичу, и все работает, но потом в продакшене находят уязвимость, которая сливает данные клиентов в открытый доступ. Самое неприятное — вы могли обнаружить это заранее. В статье рассказываем, как выбрать метод AppSec-сканирования, чтобы не потратить время зря.
Что такое AppSec-сканирование
AppSec-сканирование (Application Security Scanning) — автоматизированный процесс поиска уязвимостей в программном обеспечении.
С его помощью можно:
- Увеличить скорость. Человек физически не может проверить миллион строк кода или тысячу сценариев взаимодействия, а сканер сделает это за несколько минут.
- Сэкономить деньги. Исправить уязвимость на этапе разработки стоит дешевле, чем экстренно делать это в уже работающем приложении.
- Легко масштабироваться. Сканеры встраиваются в конвейер разработки CI/CD и проверяют каждое изменение автоматически.
AppSec-сканирование — это не один инструмент, а набор разных подходов: SAST, DAST, IAST. Все они находят уязвимости, но делают это по-разному.
Как работает SAST
Static Application Security Testing (SAST) работает по принципу «белого ящика» — проверяет исходный код, не запуская приложение.
Представьте, что вы пишете сайт для интернет-магазина. SAST-сканер пробежится по коду и найдет:
- Использование опасной функции eval() с пользовательским вводом. Разработчики используют ее для гибких решений, например чтобы на лету вычислять математические выражения. Но, если злоумышленник передаст в eval() не число, а системную команду или вредоносный код, приложение выполнит их с теми же правами.
- Зашитый пароль к базе данных в файле config.py. Разработчик мог вставить пароль прямо в код, чтобы быстрее настроить подключение к базе. Но, если этот код попадет в репозиторий, пароль увидят все, у кого есть доступ.
- Потенциальную SQL-инъекцию. Злоумышленник может вписать вместо имени команду для базы данных. И, если разработчик просто склеивает строки, приложение выполнит эту команду и отдаст чужие данные.
SAST используют в больших проектах на этапе написания кода. Он работает до компиляции и может найти проблему в IDE прежде, чем код попадет в репозиторий.
При этом SAST:
- Может давать ложные срабатывания. Анализатор находит потенциально опасные места, но в реальности участок кода может никогда не выполняться либо быть прикрыт внешним файрволом.
- Не знает, как код ведет себя во время выполнения. Не учитывает реальные условия: какие данные приходят на вход, какие ветки кода исполняются, как настроены окружение, авторизация и интеграции. В результате часть уязвимостей может выглядеть критичной «на бумаге», но не воспроизводиться в системе, а реальные проблемы, наоборот, могут остаться незамеченными.
- Не видит бизнес-логику. Например, неправильные сценарии доступа, когда обычный пользователь может получить права администратора.
SAST хорошо справляется с поиском уязвимостей на уровне кода и показывает, где могут быть проблемы. Но чтобы понять, действительно ли они существуют, нужно использовать другие методы сканирования, которые работают с уже запущенным приложением.
Чем отличается DAST
Dynamic Application Security Testing (DAST) работает по методу «черного ящика». Инструмент не видит код и общается с запущенным приложением через HTTP/HTTPS так же, как это делал бы злоумышленник.
DAST сканирует веб-приложение или API, отправляет вредоносные SQL-инъекции и анализирует ответы сервера. Он может обнаружить даже проблемы, которые не видны в коде, — незащищенные точки входа, устаревшие версии библиотек.
В отличие от SAST, DAST находит не потенциальные, а реальные уязвимости в уже работающем приложении. Но минусы у этого вида сканирования тоже есть:
- Позднее обнаружение. DAST требует рабочей среды (стейджинг или продакшен), поэтому на исправление уязвимостей может требоваться больше времени и ресурсов.
- Ограниченное покрытие. DAST проверяет только те части приложения, которые попали в сценарий сканирования. Если какой-то функционал скрыт, требует авторизации или не был вызван во время проверки, сканер его пропустит.
- Слепое тестирование. DAST не видит код, поэтому не понимает причину уязвимости.
Таким образом, DAST показывает, что можно взломать, но не объясняет, почему.
Гибридный метод IAST
Interactive Application Security Testing объединяет оба подхода — SAST и DAST. Он работает изнутри приложения, но во время его выполнения.
IAST наблюдает за тем, как обрабатываются запросы: видит, какие строки кода реально затронул тестовый сценарий, и может указать конкретный метод, файл и строку, где произошла утечка или инъекция.
Однако, у метода IAST тоже есть ограничения:
- Зависимость от тестов. IAST находит только те уязвимости, которые затронуты тестами, и может пропустить проблемы в непокрытых сценариях (например, редкие пользовательские действия или забытые эндпоинты).
- Нагрузка на окружение. Агенты IAST потребляют ресурсы CPU и памяти, так как требуют постоянного присутствия в тестовых средах.
- Поддержка технологий. IAST привязан к языку программирования в отличие от DAST, который работает везде. Если у вас Python-агент, а микросервис на Go — инструмент не сможет внедриться в процесс.
IAST показывает не просто потенциальную уязвимость, а конкретный сценарий, в котором произошла ошибка. Но лишь в рамках тех проверок, которые вы выполняете.
Как выбрать подход под задачу
На практике методы SAST, DAST и IAST не исключают, а дополняют друг друга. Выбор зависит от конкретной ситуации и контекста:
- Если вы на ранней стадии разработки, используйте SAST. Он легко встраивается в процесс сборки и может обнаружить ошибки до того, как они попадут в продакшен.
- Если вы готовитесь к релизу, добавляйте DAST. Он имитирует поведение атакующего, проверяет уже собранную систему и показывает реальные уязвимости. Также DAST незаменим, если вы тестируете сторонние компоненты и приложения, к коду которых у вас нет доступа.
- Если нужна точность и контекст, используйте IAST. У этого метода меньше ложных срабатываний, и видно, как данные проходят через систему. Поэтому проще понять, в чем проблема, и исправить ее.
В идеале все три метода нужно комбинировать: SAST ловит проблемы на этапе написания кода, IAST подтверждает их во время тестирования, а DAST выступает в качестве финальной проверки. Методы обеспечивают разные уровни защиты и перекрывают слабые места друг друга.
Главное про AppSec-сканирование
- AppSec-сканирование — это автоматизированный процесс поиска уязвимостей, ошибок и слабых мест в программном обеспечении.
- Есть разные виды AppSec-сканирования: SAST, DAST, IAST. Выбор метода зависит от этапа разработки и требований к точности.
- SAST работает с кодом и ищет проблемы без запуска приложения, но может выдавать много ложных срабатываний.
- DAST работает с живым приложением, имитирует действия хакера и показывает реальные уязвимости.
- IAST — гибридный метод, который работает внутри приложения во время выполнения: сочетает точность DAST и контекст SAST.
- Чтобы обеспечить безопасность веб-приложения на всех этапах жизненного цикла, комбинируйте все три метода: SAST + DAST + IAST.
