Два подхода к анализу ПО на уязвимости: какой выбрать?

Думаю, каждый айти-специалист знает, насколько важно учитывать требования информационной безопасности при разработке и обеспечить защищенность ПО. А как именно обрабатываются уязвимости, и кто несет ответственность за их устранение? Сегодня хочу уделить внимание именно этой теме. Всем привет, меня зовут Денис, я заместитель начальника отдела безопасной разработки (ОБР) в ИТ-компании «СИГМА».

Итак, существует несколько основных моделей обработки уязвимостей. Они зависят от структуры команды, уровня вовлечённости специалистов в процесс и их компетенций в области безопасности. Рассмотрим два ключевых подхода, основанных на том, кто является ответственным за эту функцию:

1. Обработка уязвимостей специалистом из команды Application Security.

2. Обработка уязвимостей специалистом из команды разработки (выделенным человеком с обучением по безопасной разработке).

Каждый из этих подходов имеет свои особенности, плюсы и минусы, которые важно учитывать при выборе модели для вашего проекта.

Обработка уязвимостей специалистом из команды 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. А какой подход к анализу ПО на уязвимости чаще используется в проектах вашей компании?