Использование статического анализа безопасности SAST (Static Application Security Testing) в качестве Quality Gate – не просто тренд, а необходимость для разработчиков, заинтересованных в создании надежных и безопасных приложений, утверждают эксперты. Такой точки зрения придерживается и Антон Третьяков, разработчик Tools&DevOps (компания PVS-Studio), который рассказал о преимуществах подхода в рамках вебинара.
В начале вебинара эксперт дал определение SAST как автоматической проверки кода. Статический анализ является Static Application Security Testing, когда проверяется наличие не только потенциальных ошибок, но и уязвимостей.
Потенциальные уязвимости – тоже ошибки, но для них характерны некоторые отличия. Общеизвестно, например, что на ноль делить нельзя. Последствия такого деления в коде не всегда очевидны (в зависимости от языка программа может «упасть»). В базе данных потенциальных уязвимостей есть деление на ноль. При его наличии в программе злоумышленник может предпринять действия, которые приведут к отказу в обслуживании и т. д. Потенциальная уязвимость – это ошибка, последствия которой понятны.
Вероятная уязвимость становится реальной, когда просачивается в конкретный проект и обнаруживается злоумышленниками или сотрудниками службы безопасности, пентестрами и т. п. Например, в базе данных CVE зафиксировано несколько случаев наличия деления на ноль в ряде проектов, в частности, в Microsoft Windows Graphics Device Interface.
Инструменты статического анализа SAST нацелены на поиск потенциальных, а не реальных уязвимостей. SAST обеспечивает поддержку стандартов безопасной разработки: OWASP ASVS, MISPA и т. п.
Нет худа без добра
Для SAST, как и для иных статических анализаторов как технологии, характерен недостаток – ложные срабатывания. По словам эксперта, относиться к ним следует как к своего рода математической неизбежности.
Прибегая к использованию статического анализатора, команда разработчиков соглашается с наличием некоторого «шума». К слову, создатели таких инструментов работают над тем, чтобы его уменьшать.
В то же время статические анализаторы не применялись бы в индустрии настолько широко, если бы не их весомые преимущества. Первое – полный охват кода по умолчанию. На анализ можно подавать все или часть исходников, например, только измененные файлы. Для анализа всего проекта можно пользоваться инструментами фактически «из коробки».
Второе преимущество – простая интеграция статических анализаторов. Для их внедрения не нужно создавать дополнительное окружение (например, тестовые стенды). Запуск статического анализа происходит прозрачно.
И третье – с внедрением статического анализа обеспечивается раннее исправление ошибок. Это важно потому, что исправлять «на проде» дорого. Кроме того, это может привести не только к финансовым, но и репутационным потерям. Никто не любит, когда сервисы «падают», особенно надолго.
В ходе вебинара шла речь и о ЧП с фатальными последствиями. Один из наиболее широко известных случаев – шаттл, запускаемый Европейским космическим агентством. В считаные минуты после старта корабль взорвался. Причина – софтверная ошибка в бортовом компьютере, допущенная в процессе преобразования 64-битного числа в 16-битное. В результате забарахлила система навигации. Такую ошибку, по словам эксперта, легко обнаруживает любой статический анализатор.
Капризы программистов
Как известно, программисты не любят корректировать код, который уже сохранили, и он оказался в репозитории. Им очень не хочется исправлять потенциальный баг. А в большой компании, где есть текучка кадров, в принципе сложно найти ответственного. Если и удается это сделать, то убедить программиста исправить готовый код непросто.
Проверить соответствие продукта заданным критериям качества поможет Quality Gate. В системе мониторинга качества кода отражаются результаты проверки. На Quality Gate можно «навесить» различные метрики. Например, такие как цикломатическая сложность (чем меньше независимых путей в коде, тем проще поддерживать), покрытие кода (чем выше процент кода, охваченного тестами, тем лучше тестирование).
Среди других метрик – среднее время между отказами (сбоями), отражающее устойчивость ПО, плотность уязвимостей (их количество на 1000 строк кода), что определяет уровень безопасности.
Метрика для Quality Gate
SAST ищет потенциальные уязвимости. Информацию, полученную в отчете SAST-инструмента, можно применять как метрику для Quality Gate.
Эксперт продемонстрировал, как на практике SAST можно использовать в качестве Quality Gate. Для этого он показал отчет анализа одного из проектов. В отчете примерно 60 тыс. предупреждений.
В таких случаях специалисты задаются вопросами. Что с этим делать – бросить все силы на исправление, чтобы ПО было безопасным, либо обратиться за помощью к Quality Gate? Настроить метрики инструмента на 60 тыс. срабатываний и постараться не привнести дополнительных уязвимостей в проект?
Оптимальный вариант – воспользоваться таким инструментом, как храповик. Заложенный в него принцип (движения в одну сторону) можно реализовать при внедрении SAST в Quality Gate.
Идея подхода состоит в следующем. Проект анализируется первый раз, информация об ошибках и потенциальных уязвимостях сохраняется (например, в хранилище артефактов).
Затем выполняется регулярный (!) анализ проекта, при этом контролируется, стало ли ошибок больше. Если их число увеличивается, то заведение ПО в репозиторий не допускается. Если ошибок меньше (либо количество не изменилось), новый отчет сохраняется вместо старого, а изменения запускаются в репозиторий (проходит сборка).
Таким образом удается, с одной стороны, контролировать количество ошибок в коде, не допускать их увеличения, с другой – планомерно работать над уменьшением количества ошибок в проекте.
Эксперт показал, как данный подход реализован на примере SonarQube – системы, позволяющей анализировать безопасность проекта, настраивать и контролировать различные метрики. Этот инструмент предоставляет возможность видеть общее описание проблемы, просматривать предупреждения, определять ответственных за исправления.
