Два подхода к анализу ПО на уязвимости: какой выбрать?
Думаю, каждый айти-специалист знает, насколько важно учитывать требования информационной безопасности при разработке и обеспечить защищенность ПО. А как именно обрабатываются уязвимости, и кто несет ответственность за их устранение? Сегодня хочу уделить внимание именно этой теме. Всем привет, меня зовут Денис, я заместитель начальника отдела безопасной разработки (ОБР) в ИТ-компании «СИГМА».
Итак, существует несколько основных моделей обработки уязвимостей. Они зависят от структуры команды, уровня вовлечённости специалистов в процесс и их компетенций в области безопасности. Рассмотрим два ключевых подхода, основанных на том, кто является ответственным за эту функцию:
Обработка уязвимостей специалистом из команды Application Security.
Обработка уязвимостей специалистом из команды разработки (выделенным человеком с обучением по безопасной разработке).
Каждый из этих подходов имеет свои особенности, плюсы и минусы, которые важно учитывать при выборе модели для вашего проекта.
Обработка уязвимостей специалистом из команды Application Security
В этом сценарии уязвимости обрабатываются специалистом по безопасности, который не является частью основной команды разработки. Чаще всего такие эксперты работают в отдельных командах, которые подключаются к проектам для проведения аудитов безопасности, анализа уязвимостей, пенетеста или код-ревью. Этот подход распространен в крупных организациях, где есть отдельные группы, сфокусированные на безопасности.
Плюсы:
Высокий уровень экспертизы в области безопасности. Специалисты из AppSec обладают глубокими знаниями в вопросах кибербезопасности, умеют выявлять сложные уязвимости, анализировать риски и предлагать надежные решения.
Объективный взгляд на продукт. Так как специалист не сильно погружен в бизнес-логику и ежедневные задачи, он может объективно, без эффекта «замыленного глаза», оценить систему с точки зрения защищенности от рисков внешнего нападения.
Минусы:
Недостаточная вовлеченность в продукт. AppSec-специалист может не знать всех тонкостей приложения, его архитектуры и бизнес-логики. Это может усложнять анализ специфических уязвимостей, связанных с особенностями проекта.
Зависимость от внешних экспертов. Команды разработки становятся зависимыми от работы AppSec-специалистов, что может замедлить процесс исправления уязвимостей и сам процесс разработки.
Эксплуатация:
Хорошо подходит для крупных проектов, где есть много внешних и внутренних компонентов, требующих оценки безопасности.
Этот процесс можно реализовать через регулярные аудиты безопасности и интеграцию с DevOps.
Обработка уязвимостей специалистом из команды разработки
В этом случае за обработку уязвимостей отвечает выделенный человек из команды разработки, прошедший обучение по основам безопасности (AppSec, DevSecOps). Такой подход становится всё более распространенным в связи с ростом популярности практики DevSecOps, где безопасность становится частью процесса разработки с самого начала.
Плюсы:
Глубокое знание продукта. Разработчик, погруженный в проект, лучше понимает архитектуру приложения и бизнес-логику. Он способен быстрее выявить уязвимость, связанную с функциональными особенностями продукта.
Быстрое исправление. Так как разработчик находится внутри команды и уже работает над продуктом, исправление уязвимостей происходит быстрее, без задержек на коммуникацию с отдельной командой безопасности.
Минусы:
Ограниченная экспертиза в сфере информационной безопасности. Даже пройдя обучение, разработчик, скорее всего, не будет обладать столь же глубокими знаниями в сфере ИБ, как выделенный AppSec-специалист. Это может привести к тому, что не все уязвимости будут корректно выявлены и исправлены.
Проблема приоритезации. Разработчик может столкнуться с ситуацией, когда задачи по функционалу будут иметь более высокий приоритет по сравнению с вопросами безопасности. Это также может не лучшим образом сказаться на защищенности ПО.
Эксплуатация:
Подходит для проектов со средним и малым уровнем сложности, где можно обучить ключевых разработчиков основам безопасности.
Можно использовать вместе с автоматизированными инструментами (SAST, SCA, DAST) для поддержания безопасности на всех этапах разработки.
Рекомендации по использованию, опыт СИГМЫ
Комбинируйте оба подхода. Так как каждый из них обладает своими преимуществами и недостатками, оптимальная стратегия — баланс между двумя моделями. Используйте специалистов по безопасности для периодических аудитов и внешних оценок, а также выделяйте обученных разработчиков для решения повседневных задач по безопасности.
Инвестируйте в обучение команды. Независимо от того, какой подход вы выберете, обучение команды основам безопасности — это всегда инвестиция в более защищенный продукт.
Автоматизация процесса. Интеграция автоматизированных инструментов для анализа безопасности кода и продуктов (SAST, SCA, CA, DAST, IAST, secret detection) поможет снизить нагрузку на специалистов и ускорить процесс выявления уязвимостей.
В СИГМЕ мы в основном совмещаем 2 этих подхода, хотя приоритезация в сторону одного из них зависит от масштаба проекта. Здесь есть команда Application Security, в которой я как раз работаю. Когда в компании только начинали развиваться практики безопасной разработки, поиском и обработкой уязвимостей в основном занимался наш отдел. Затем мы стали проводить обучение команд разработки по использованию AppSec-инструментов, а также консультировали коллег относительно требований к информационной безопасности и встраивали инструментальные проверки. Постепенно в большинстве случаев удалось реализовать комбинированную модель: в командах разработки есть выделенный специалист, Security Champion, который отвечает за обработку и устранение уязвимостей, а наш отдел контролирует процессы безопасной разработки на всех этапах создания продукта. Подробнее про один из примеров совместной работы специалистов ОБР и команды разработки мы рассказывали в другом материале.
Заключение
Безопасность программного обеспечения — результат командной работы, которая требует вовлечённости всех участников процесса разработки. Важно находить баланс между глубоким пониманием продукта и необходимой экспертизой в области безопасности. Каждая команда должна найти свой уникальный подход к обработке уязвимостей, который будет оптимален для их целей и задач. Независимо от выбранной стратегии, регулярное обучение и автоматизация станут ключом к успешной защите вашего продукта от киберугроз.
P.S. А какой подход к анализу ПО на уязвимости чаще используется в проектах вашей компании?
