Проверка безопасности ПО
Объясняем, зачем нужна безопасная разработка ПО, и рассматриваем два подхода к проверки безопасности.
Курс основан на материалах Developing Secure Software, который разработан объединением Open Source Security Foundation (OpenSSF). В нем рассматриваются базовые вопросы, связанные с проектированием ПО, написанием безопасного кода, управлением уязвимостями, а также использованием специализированных практик и инструментов при разработке ПО.
Основные понятия
Безопасность — один из важнейших критериев при выборе корпоративных сервисов. Наравне с функциональностью, высокой производительностью и удобством использования клиент ожидает, что его данные будут надежно защищены с помощью современных практик и технологий. Поэтому уделять внимание безопасности стоит на самых ранних этапах создания любого сервиса и, в частности, на этапе разработки программного обеспечения (ПО).
Безопасная разработка ПО (Secure Software Development, SDL) представляет собой набор процессов и технологий, которые применяются на всех этапах разработки ПО. Они позволяют предотвращать технические недостатки — например, несоответствия заданным требованиям или наличия любых ошибок, допущенных в ходе проектирования и реализации приложения. Такие недостатки могут привести к невозможности выполнения этим приложением каких-либо функций или к его уязвимости.
Подходы к проверки безопасности ПО
Подходы к проверке ПО делят на две основные категории в зависимости от того, запускается ли код в процессе анализа. Каждый из подходов по-своему выявляет дефекты и повышает надежность системы.
Статический анализ — проверка приложения без его запуска. Сюда входят инструменты, которые ищут уязвимости прямо в исходном коде, байт-коде или машинном коде — например, сканеры безопасности кода. Также не стоит забывать и о ручном анализе кода специалистом.
Динамический анализ — проверка приложения в процессе его выполнения на конкретных данных. Классическое тестирование — это тоже динамический анализ. Фаззинг, когда в программу отправляют потоки случайных входных данных, чтобы спровоцировать сбой, — еще один пример динамической проверки.
Существует также гибридный анализ, который сочетает в себе оба подхода, хотя некоторые специалисты относят его к динамическому анализу.
Использование специализированных инструментов (детекторов, сканеров) для определения критических ситуаций — практика, которую применяют давно и не только в разработке ПО. Например, датчик дыма фиксирует признаки пожара. Однако важно понимать, что ни один детектор не работает безупречно.
В области безопасности ПО мы полагаемся на инструменты, которые ищут определенные классы уязвимостей и сигнализируют нам о них. Идеальный инструмент должен сообщать только о реальных уязвимостях и не создавать лишних предупреждений. В реальности это часто бывает не так.
Инструмент может либо сообщить о проблеме, либо не сообщить — каждый из этих исходов может быть как верным, так и ошибочным. Это порождает четыре классические ситуации.
| Реакция инструмента | Верный результат | Ошибочный результат |
| Проблема зафиксирована | Истинно положительный (true positive): верно сообщил об ошибке | Ложноположительный (false positive): сообщил об ошибке, которой нет («Ошибка I рода») |
| Проблема не зафиксирована | Истинно отрицательный (true negative): верно не сообщил об ошибке | Ложноотрицательный (false negative): пропустил существующую ошибку («Ошибка II рода») |
Обычно приходится искать баланс между ложноположительными и ложноотрицательными срабатываниями. Инструменты можно настроить так, чтобы уменьшить количество ложноположительных срабатываний (ошибочных отчетов), но снижение чувствительности обычно приводит к увеличению числа ложноотрицательных срабатываний (пропущенных уязвимостей).
Оптимальный способ настройки инструментов зависит от того, работаете ли вы с готовым проектом или только начинаете разработку.
Интеграция в существующий проект
При добавлении инструмента в существующий проект рекомендуем настроить его так, чтобы он сообщал лишь о наиболее критичных типах уязвимостей. Такой подход позволит освоить работу с инструментом и понять его выводы.
После устранения проблем можно повысить чувствительность инструмента или добавить другие инструменты для выявления большего круга проблем. Нет смысла пытаться обнаружить больше уязвимостей, чем вы способны обработать.
Интеграция в новый проект
При добавлении инструментов в только что созданный проект можете настроить их на максимальную чувствительность. В новом проекте вы не будете перегружены отчетами и сразу получите обратную связь по всем проблемам, которые способны обнаружить инструменты.
Осталось определить, куда добавить эти инструменты. В первую очередь — в пайплайн непрерывной интеграции (CI). Так, система будет автоматически анализировать каждое изменение и на ранней стадии выявлять проблемы безопасности.
