DevSecOps: как понять, что вашему бизнесу это нужно?

Привет! Меня зовут Алексей Антонов, я управляющий партнер в Swordfish Security. Мы занимаемся безопасной разработкой уже почти 10 лет. Сегодня я хочу поговорить о DevSecOps.

Почему это важно? Уязвимости в ПО сегодня - один из немногих оставшихся злоумышленникам путей для проникновения в крупные системы. А там - хищение информации и денежных средств, репутационные потери и ущерб бизнесу. Очевидно, что уязвимостей должно быть меньше, но процесс создания безопасного ПО - непрост, требует времени, знаний и определенных затрат. В этом материале я расскажу о том, зачем вообще нужен DevSecOps, как понять, что он необходим вам и что делать, чтобы запустить эту практику в компании.

Содержание

⁃ Что такое DevSecOps и зачем он нужен

⁃ Безопасность в контексте разработки ПО

⁃ Автоматизация всего

⁃ В чем польза для бизнеса

⁃ DevSecOps

⁃ Триггеры внедрения и рекомендации

Сегодня множество компаний занимается разработкой своих продуктов. Подходы разные, но суть одна - программисты пишут тысячи, сотни тысяч и миллионы строк кода. При этом, по нашему опыту, каждые 1000 строк содержат 50–60 критичных дефектов. У зрелых команд показатель 10–15 / 1000 строк. Именно в снижении количества дефектов в готовом продукте и состоит смысл внедрения DevSecOps процесса, Secure by default.

Говоря в общем смысле, DevSecOps - это подход к созданию продуктов, который уже на начальном этапе включает в себя безопасность. Его суть - в том, чтобы не бороться с последствиями проблем и слабостей, которые уже есть в продукте, а не допускать их появления. Можно провести простую аналогию: когда вы строите дом, вы еще на этапе проекта думаете о том, как сделать его теплым (пол с подогревом, специальные материалы, конструкции окон), а не утепляете его после того, как приходит зима и выясняется, что внутри очень холодно. И здесь: вы не ликвидируете последствия уязвимостей и разных слабостей, а заранее стараетесь их не допускать и заботитесь об этом на всех этапах разработки ПО.

Если еще пару лет назад история DevSecOps была актуальной только для крупных компаний с десятками своих продуктов и сотнями разработчиков в команде (тот же Яндекс, банки, включая Сбер, Тинькоф и другие), то сегодня постепенно она обретает актуальность и для более мелких игроков.

Раньше разработка всеми силами стремилась «сколотить» пилотную версию и вытолкнуть ее в прод, а с безопасностью уже разбирались позже. Но сейчас те же инвесторы понимают важность отсутствия “дыр”, и задают свои вопросы. Поэтому тема становится все более актуальной для широкого круга. Тем не менее, пока еще для команд, в которых менее 50 разработчиков, вопросы безопасности стоят менее остро и решаются более простым и стандартным путем (то есть по факту). Их цель – бизнес, функциональность, и все ресурсы уходят туда. Безопасность обеспечивается фрагментарно и уже после создания продукта, например, в готовых продуктах ищутся дефекты с помощью бесплатных сканеров и тестирования на проникновение, и затем они исправляются. Но постепенно бизнес растет, рынку нужно лучшее качество, гарантии, безопасность становится сложнее и глубже проникает в цикл разработки.

И так компания переходит на новый уровень. На котором свои требования. Рынок просит: “Быстрее, еще быстрее”. Чтобы бизнес рос, нужно быстрее отвечать на запросы рынка, и это сказывается на разработке. Растет значимость показателя Time To Market, который является одним из основных. Он стимулирует автоматизировать все, что можно и нельзя. Пишем код, собираем, разворачиваем все максимально быстро. И здесь уже DevOps проявляется во всей красе. Автоматизация процессов сборки, доставки, развертывания. Вот уже по 3-5 релизов в неделю, и это мы только начали. В нашем обиходе эта штука называется конвейер, как в автопроме, кстати, далее постараюсь приводить аналогии с ним, чтобы максимально упростить понимание некоторых вещей. Вот как раз в этот момент, в момент появления конвейерной разработки, область безопасности и приобретает критическое значение, и мы уже в DevSecOps.

Индустрия знает большое количество практик, которые помогают на разных этапах разработки обеспечить ее безопасность. А что такое безопасность? Когда нет уязвимостей? Как говорят в нашей области, их не может не быть, они появляются очень быстро, постоянно кто-то находит новые, о них оповещают, приходится проверять, нет ли их в нашем их софте. И так постоянно. Состояния «я абсолютно чист» нет, к сожалению.

И главная задача – минимизировать количество “дыр”, находить их максимально оперативно, быстрее, чем другие, а главное - исправлять до того, как «черные шляпы», «скрипт кидди» и просто всякие «ресерчеры» начнут их использовать. Как это делать? Здесь как раз помогают практики. Для иллюстрации вернемся к конвейеру сборки автомобилей и проведем аналогию с созданием ПО. Как это выглядит без безопасности. Мы хотим сделать машину, например, черный джип, крутой очень, премиум класса. Готовим чертежи (создаем архитектуру), заказываем детали (берем готовые компоненты), делаем каркас (пишем основной код), вешаем на него все детали (этап Build), заводим готовое авто и катаемся на нем (тестирование), выпускаем в производство (продакшен).

Если в каждом этапе учитывать практики (не только безопасность), то мы должны пошагово контролировать и оценивать правильность наших действий:

Чертеж: если у нас вообще джип, то почему его длина 13 метров и у него нет лобового стекла, и заводится он сам, когда захочет?

В разработке - это этап дизайна, построения архитектуры, тут мы как раз проверяем, насколько предложенная нами архитектура ПО корректна, есть ли необходимые элементы авторизации, базы данных, выбрана ли правильная платформа и т.д. (Практика Архитектурный анализ).

Детали: почему у нас дверь от грузовика, а колеса от велосипеда?

В разработке это этап выбора сторонних библиотек: мы начинаем их себе загружать, и необходимо проверять их как на соответствие функциональности, так и на отсутствие уязвимостей, лицензионных проблем (Практика анализа сторонних компонент – OSA/SCA).

Каркас: а почему вот эта труба просто лежит, не приварена?

В разработке это этап, на котором появляется наш собственный код. Нам нужно быть уверенными, что при его создании мы соблюли все правила безопасного написания кода, позаботились о сохранности, шифровании и других способах работы с данными (Практика статического анализа исходного кода - SAST).

Установили детали: почему у нас вместо крышки багажника капот?

Этап сборки ПО. Мы уже можем проводить базовые динамические тесты, смотреть корректность сборки, использование библиотек и то, как мы все это связали между собой (практика динамического анализа и ранее применяемая практика анализа сторонних компонент – DAST, OSA/SCA).

Тестирование – почему руль крутится, а колеса нет?

Это уже полноценный этап тестирования, и мы можем видеть и анализировать, как наше ПО работает на инфраструктуре, как с ним будут взаимодействовать пользователи и так далее (Практика динамического анализа, анализа контейнерных сред – DAST, CA).

Продакшен – хм, мы проехали 5 км, и кончился полный бак бензина…

Для ПО - это последний этап, когда мы уже вышли в мир, начинаем работать с пользователями, и постоянно мониторим свое ПО, чтобы понимать, как оно функционирует в боевом режиме под нагрузкой (Практика динамического анализа, мониторинга контейнерных сред, веб защиты и тд – DAST, CA, WAF).

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

И все эти проверки должны быть своевременными, а не когда мы приварили капот вместо лобового стекла. Иными словами, на каждом этапе разработки есть свои типы проверок.

Мы уже упомянули о том, что разработка значительно ускоряется с развитием бизнеса. Так вот, безопасность тоже должна не отставать, а желательно работать на опережение. В этом как раз может помочь DevSecOps. Когда практики безопасности отлажены и встроены в конвейер, и все работает на автомате. Если мы отлавливаем багу еще на этапе создания продукта (видим, что по спецификации у нас капот вместо лобового стекла) и исправляем, нам не нужно в дальнейшем исправлять сотни таких проблем (во всех машинах, которые сошли с нашего конвейера), не нужно переделывать целый процесс. Мы значительно сократим затраты на исправление различных дефектов.

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

Временной и финансовый ресурсы - ключевые показатели, которые оценивает бизнес. Именно поэтому можно сказать, что DevSecOps - штука, безусловно, полезная. На описанном выше примере мы видим, что встраивание безопасности в процесс создания продукта - необходимое условие, которое не мешает, а наоборот помогает бизнесу.

При создании ПО у нас есть основные этапы проверки:

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

анализ сторонних компонент – одна из важнейших практик, с помощью которой анализируются все внешние используемые библиотеки на наличие в них уязвимостей и лицензионных ограничений. При разработке собственных продуктов количество внешних библиотек составляет порядка 60-80% от общего объёма продукта. Поэтому можно себе представить, сколько может быть нюансов, угрожающих безопасности;

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

динамический анализ – производится, когда ПО уже эксплуатируется на какой-то инфраструктуре, связанной с ним. Здесь могут появляться новые типы дефектов, связанные с некорректной конфигурацией этой инфраструктуры;

анализ контейнеров и т.д.

Для каждого из этих этапов есть свои средства для проверки, они внедряются и автоматизируются для того, чтобы быстрее и эффективнее искать уязвимости (неправильные колеса и капоты). Есть бесплатные инструменты, есть платные, хорошие и не очень. Я в этой области уже около 10 лет, и на практике видел много случаев мнимой защищенности. Это как если обратиться к врачу с сильной простудой, а он диагностирует только насморк и выпишет капли, но не измерит температуру, не предложит другие нужные лекарства. Идите сразу к хорошему доктору – используйте лучшие инструменты, если позволяет бюджет. На ранних этапах можно применять и бесплатные, с ростом и усложнением процессов лучше не экономить.

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

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

Все зависит от вашей области и вашего позиционирования на рынке, требований вашей аудитории, хотя сложно сказать, кто сегодня готов потреблять небезопасные продукты. Основные драйверы безопасности – это регуляторы и ваши риски. Первые обязывают, вторые вынуждают. Регуляторы действуют превентивно, выполнение их требований гарантирует минимизацию рисков. Вам остается выбирать, в каком формате вы будете это реализовывать.

Конечно, главная область применения практик DevSecOps - финансовые институты, в последние годы также активно начала подключаться сервисная разработка ПО. Сегодня их используют большие компании, со штатом разработки более 200-300 человек. К сожалению, внедрять данный процесс при активной разработке гораздо сложнее, чем делать это на старте, когда изначально можно выстроить все корректно и расставить приоритеты.

Основываясь на практике, могу привести следующие триггеры на внедрение DevSecOps:

- Количество разработчиков более 50 человек

- Внедрение автоматизации процесса разработки (CI/CD, DevOps)

- Ориентация на микросервисную архитектуру

- Необходимость улучшения после внедрения практик обеспечения безопасности приложений

Если вы уже обладаете большим штатом разработки и у вас много продуктов, внедрять DevSecOps нужно постепенно, согласовывая шаги с командой. Вначале многим сотрудникам придется сложно: у них будет больше и новых, и стандартных задач, нужно подготовиться к трудностям. Но после того, как все начнет эффективно функционировать, и разработчики, и сотрудники иных подразделений, а также инвесторы и другие, причастные с созданию продукта, ощутят выгоду от этих изменений.

В любом случае, перед тем как приступить, стоит обратиться к успешному опыту внедрения, пообщаться с экспертами, оценить преимущества, которые получили компании, внедрившие DevSecOps. И принять взвешенное решение с цифрами в руках;)