Shift-Left Security: как сделать разработку безопасной и эффективной?

Можно ли предупредить появление уязвимостей еще на этапе проектирования и, таким образом, сделать разработку и безопасной, и эффективной одновременно? Об этом рассказывает Сергей Володин, директор по продуктам Start X.

Уязвимости на этапе релиза VS уязвимости на этапе проектирования

Shift-Left Security – это подход, при котором проверки безопасности внедряются так рано и так часто, как это возможно. В теории, такой подход позволяет предупредить появление уязвимостей и других проблем с безопасностью приложения еще на этапе проектирования, когда продукт только начинает создаваться или меняться по функциональным требованиям.

Чем раньше появляются актуальные требования – тем дешевле и быстрее их выполнить и исключить предпосылки появления уязвимостей:

Относительная стоимость устранения уязвимостей и других дефектов ПО на разных этапах разработки. Устранять баги и уязвимости еще на этапе разработки требований — самое дешевое и быстрое решение.

К сожалению, возможности команд безопасности и технических средств защиты в процессах DevSecOps ограничены.

Процесс, в котором не применяется DevSecOps-подход

На рисунке выше – структура DevSecOps-пайплайна с основными контролями безопасности. Что проходит проверку на каждом из них:

• Проверка безопасности исходного кода в системе контроля версий — включает проверки SCA, SAST, Secret Detection, работает по методу White Box Testing.

SCA – анализируются open source компоненты на предмет выявления зависимостей , содержащих уязвимости. Также могут определить лицензионную совместимость компонентов и риски нарушения лицензионных прав.

SAST – сканеры проверяют исходный код на наличие частых уязвимостей, например, OWASP Top Ten. Причем, SAST находит и саму уязвимость, и подсвечивает фрагмент кода, исправление которого будет оптимальным решением.

Secret Detection — это автоматизированная проверка, которая обнаруживает незашифрованную конфиденциальную информацию, например, пароли, токены и т.д.

• Проверка безопасности приложения, которое запущено из собранного артефакта — в этой фазе пытаются «сломать» приложение, имитируя действия злоумышленников.

DAST (Dynamic Application Security Testing) — динамическое тестирование безопасности приложений. DAST-сканеры работают автоматически и проверяют приложения, имитируя внешние атаки через различные уязвимости.

или OAST (Out-of-band Application Security Testing) — техника разработана компанией PortSwigger и является расширением DAST, находит уязвимости, не обнаруженные DAST.

• Проверка безопасности приложения после деплоя — мониторинг безопасности артефактов и приложения приложения в целом, проводится с помощью инструментов WAF и RASP.

Web Application Firewall (WAF) — межсетевой экран для веб-приложений. Фильтрует трафик и защищает приложения по HTTP/HTTPS.

RASP (Runtime Application Self-Protection) — инструменты в реальном времени обнаруживают и блокируют атаки на ПО, даёт приложению возможность самозащиты в автоматическом режиме.

Перечень применяемых инструментов, как правило, зависит от критичности приложения для бизнеса, наличия исходного кода приложения (без которого не возможно проведение статического анализа), зрелости процессов производтва ПО в организации.

Если процесс выстроен неэффективно это приведет к тому, что на каждом Quality Gate команда будет вынуждена возвращаться на один из предыдущих этапов, то каждая непройденная проверка отбрасывает команду на несколько этапов назад, и вынуждает их проходить несколько итераций проектирования – с поиском альтернативных компонентов. Когда у разработчика нет компетенций по безопасной разработке, то такие поиски он производит вслепую.

Решение класса DAST могут выявить некоторые, уже известные проблемы с кодом, который написан, собран и развернут на тестовом контуре. Но спроектировать продукт и написать код изначально правильно и безопасно могут только сами разработчики.

Процесс разработки с применением подхода DevSecOps

Поэтому ключевые компоненты подхода Shift-Left — понимание продуктовыми командами угроз и мер, которые необходимо предусмотреть, чтобы их исключить или минимизировать, а также мотивация команд учитывать вопросы информационной безопасности.

Как помочь командам получить эти знания, навыки и мотивацию?

Как помочь продуктовым командам работать по подходу Shift-Left Security

1. Дать понятные и актуальные требования по безопасности для их продуктов или проектов

Обычно требования по безопасности продуктов выглядят очень сложно, написаны специфичным языком регламентов или нормативных документов по безопасности и выглядят как цитаты из них. Если передать их в продуктовую команду в таком виде, даже самые мотивированные разработчики не смогут понять, что конкретно им нужно делать:

Пример исходного требования по безопасности на языке нормативных документов и его перевода на язык, понятный продуктовой команде.

Задача команд безопасности – дать четкие, конкретные и адаптированные под особенности каждой команды и проекта требования по безопасности. Такие же или даже более понятные, как функциональные требования в их проекте.

Понятные и актуальные требования позволят разработчикам и продуктовым командам еще на этапе проектирования учесть требования по безопасности в разработке их продукта.

2. Обучить продуктовые команды писать и поддерживать безопасный код

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

Мы не рекомендуем строить обучение от уязвимостей — есть риск, что получится очередное изложение “OWASP TOP 10”, которое не оценят разработчики.

Мы рекомендуем разбирать конкретные, практические задачи, актуальные для ваших продуктовых команд, с примерами кода и безопасной реализации на их языках программирования. Оптимально структурировать такое обучение через “контексты” — рабочие ситуации и сценарии, актуальные для продуктов, с которыми работают команды, например:

• Работа с посетителями и пользователями
• Обработка входных данных в формах ввода
• Хранение данных
• Работа с браузерами
• Внешние зависимости
• Работа с файлами и каталогами
• Хранение ключей и секретов
• Использование Docker
• Работа с внешними ресурсами и сервисами: запуск внешних программ и другие.

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

Хорошая идея — интегрировать обучение с реальными задачами, например, через трекер, а также с выявленными уязвимостями — например, через существующую платформу автоматизации DevSecOps-процессов.

3. Мотивировать продуктовые команды и вовлечь их в тему безопасной разработки

Мотивированные сотрудники продуктовых команд — лучшие союзники команды безопасности. Они сами будут изучать нужные курсы, разбирать требования и принимать правильные, безопасные продуктовые решения для их реализации.

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

1. Свяжите понятия качество и безопасность кода. На конкретных примерах покажите, какие проблемы для продукта и клиентов возникают, если продукты небезопасны, а код содержит уязвимости.
2. Покажите, что ресурсы и усилия, которые требуются на пентесты, оценку защищенности и другие мероприятия по безопасности, имеют ценность для ваших пользователей и клиентов.
3. Наглядно, лучше — на личном опыте покажите разработчикам принцип действия самых актуальных уязвимостей, угроз и практик безопасной разработки.

Провести свои продуктовые команды по этому алгоритму можно, например, с помощью специальных CTF-соревнований, адаптированных под специфику продуктовых команд, их знания, навыки и мотивацию.

Мы подробно рассказывали о таком формате в нашем докладе на недавнем Positive Hack Days: CTF для команд разработки: как найти и воспитать секьюрити чемпионов.

Как Shift-Left подход поможет ускорить релиз продуктов

Многие продуктовые команды и заказчики понимают важность требований по безопасности и преимущества подхода Shift-Left Security, однако в рабочей рутине могут не учесть критичные требования или не разобраться, как правильно их реализовать с учетом специфики своего продукта. А у команд безопасности не всегда бывает возможность выделить квалифицированных экспертов на работу с продуктовой командой.

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

По самым скромным оценкам, подход Shift-Left Security в разработке программного обеспечения ускоряет выпуск продукта на 10—17%.

Другой важный результат применения Shift-Left-подхода — активное сотрудничество между отделами безопасности и продуктовыми командами, которое помогает прийти к общим решениям и повышает уровень защищенности для продуктов, всей компании и ее клиентов.