Статическое тестирование безопасности приложений (SAST) имеет не самую лучшую репутацию. Инструменты SAST могут выдавать огромное количество уведомлений, а команды безопасности, которые часто имеют опыт работы с сетью, не всегда полностью понимают их. Это может привести к ухудшению отношений между командами, поскольку разработчики часто воспринимают эту работу как отвлекающий фактор от работы над своими основными обязанностями.
В этом блоге даны несколько простых советов, которые работают для улучшения безопасности, сохраняя при этом хорошие отношения между службой безопасности и разработчиками.
Как работает SAST?
SAST работает на основе правил кодирования, чтобы найти общие недостатки и слабые места, которые могут привести к уязвимостям. Эти недостатки обычно определяются с помощью фреймворка Common Weakness Enumeration (CWE). Сами по себе недостатки не являются уязвимостями, но они свидетельствуют о низком качестве кода. SAST можно представить как проверку орфографии или грамматики, которая обнаруживает места, где код написан некачественно. Ключевое здесь то, что недостаток может быть, а может и не быть чем-то, что когда-нибудь станет проблемой, и единственный способ узнать это – исследовать его. Хотя инструменты SAST предназначены для выявления уязвимостей, которые приводят к проблемам с безопасностью, они, как правило, также могут в некоторой степени решать проблемы качества кода, которые не связаны с безопасностью.
Надежные стратегии реагирования на SAST-уведомления без перегрузки разработчиков
Даже лучшие из существующих инструментов SAST создают много уведомлений. Реакция на предупреждения SAST, должна включать рассмотрение того, как это будет выполняться в сотрудничестве с другими отделами. Если бессистемно выдавать предупреждения на основе уведомлений от инструментов безопасности, доверие разработчиков и сотрудничество с ними быстро потеряется. Не все уведомления одинаковы, и не все являются уязвимостями.
Вот две стратегии реагирования на SAST-уведомления:
Прекращение реагирования
При таком подходе получается базовый уровень SAST-уведомлений в самом начале, но отсутствует реагирование на эти уведомления. Вместо этого цель – не добавлять новых уязвимостей или проблем с качеством кода. Разработчики будут работать только с новыми уведомлениями. Затем, впоследствии, будет возможность сократить свой бэклог, используя, например, вторую стратегию.
Постепенная проверка
При таком подходе берется один тип CWE (SQL-инъекции, XSS и десериализация ненадежных данных – самые распространенные) и решаются все предупреждения безопасности, связанные с ними. Когда с ними будет завершено, переходят к следующему типу CWE, работая с наиболее критическими типами CWE в первую очередь. В этой стратегии важно убедиться, что разработчики знают план заранее.
Выбор хорошего инструмента SAST
Поиск инструмента, который уменьшает количество уведомлений и в то же время повышает их качество, очень поможет. Нужно искать инструмент, который делает следующее:
- Может быть настроен в соответствии с персональными потребностями
Хороший инструмент SAST можно настроить в соответствии с кастомными проектами, чтобы в результате получать более качественные уведомления.
- Имеет консолидацию потоков данных
Многие SAST-инструменты создают уведомления для каждого потока данных, даже если это означает сотни уведомлений, сгенерированных только для нескольких фрагментов кода, требующих решения. Наличие большого количества уведомлений может быть полезным, когда обосновывается необходимость увеличения ресурсов для команды безопасности, но это преимущество быстро уменьшается, когда разработчикам приходится реагировать на них.
- Поощряет обучение разработчиков
Некоторые инструменты SAST интегрированы с образовательными программами для разработчиков, такими как, например, Secure Code Warrior. Ни один инструмент или настройка не уменьшит количество уведомлений так, как разработчики, пишущие безопасный и качественный код.
- Маскирует качественные уведомления
И последний совет: обращать внимание на контекст приложения. SAST не обладает знаниями о среде выполнения или развертывания, поэтому вы должны самостоятельно решать, является ли уведомление настоящей уязвимостью. Иногда то, что может показаться низкокачественным уведомлением, может иметь огромные последствия в будущем. Например, обход пути CWE в инструменте командной строки может не быть настоящей уязвимостью, но это все равно проблема качества кода. А если эта командная строка когда-нибудь будет развернута как часть облачного приложения, то она станет настоящей потенциальной уязвимостью безопасности.
Целью любого инструмента безопасности приложений должно быть улучшение безопасности приложения. Слишком большое количество незначительных уведомлений будет иметь негативное влияние в долгосрочной перспективе, поскольку разработчики начнут игнорировать команду безопасности и могут пренебрегать безопасным кодированием.
