Споры на тему «DevOps — это человек или методология?» уже неактуальны: всем надоело. Зато появился DevSecOps. И хотя термин не нов (первая конференция DevSecOps Summit прошла в 2016 году), его точное содержание бывает не до конца понятно и новичкам, и бывалым айтишникам.
Если за бывалых мы не волнуемся (разберутся сами), то новичкам нужен вводный курс. Поэтому я, DevOps-инженер Сергей Печенко (@tnt4brain), собрал коллекцию статей. Поговорим о том, что такое DevSecOps, какие инструменты существуют для внедрения этой методологии на уровне команды, а затем и на уровне компании.
DevSecOps — это что?
Чтобы описать какую-то новую вещь, бывает полезно понять, на что уже известное она похожа и чем точно не является.
Итак, на сцене первая статья коллекции о методологии DevSecOps. Вообще, она могла бы называться «DevSecOps для зумеров», потому что на самом деле это удобный сборник ссылок на записи вебинаров. Главная идея: тем, кто раньше только перекидывался письмами, теперь придётся общаться, договариваться и работать совместно. Вам это, случайно, не напоминает описанную в посте «Кто такие DevOps?» стереотипную методологию? Мне напоминает.
Так, со сходствами разобрались. Переходим к отличиям — о них расскажет статья «Какая разница между DevOps и DevSecOps?» в блоге одного из вендоров. Её стоит прочитать, если есть желание разобраться, что стоит за небезызвестными сокращениями SAST, DAST и менее популярными IAST, RASP.
Бантик вместо замка: в компании SolarWinds на сервере обновлений поставили пароль «Solarwinds123». Взлом привёл к тому, что связанные с SolarWinds компании потеряли в среднем 11% годового дохода.
Дальше очень хочется вставить мем с Вовкой из Тридевятого царства, изображающий сложившуюся в IT практику: «Хоп-хоп — и в продакшен!» Но у нас тут приличный ресурс, так что выскажусь обтекаемо: увы, очень часто безопасность продукта приносят в жертву скорости разработки и простоте сопровождения. Интересно, что получится, если, наоборот, во главу угла поставить безопасность, а всё остальное сделать вторым и третьим приоритетами? А если безопасники настаивают на затаскивании в продакшен ну очень свежих версий? Такая гипотетическая история рассматривается в статье «При создании DevSecOps не забывайте о SRE». Любопытная точка зрения, предлагаю с ней ознакомиться и поделиться соображениями.
Так что же такое DevSecOps? Кат для тех, кто так ничего и не понял.
Для начала предлагаю ещё раз вспомнить, что такое DevOps. В классическом определении это методология, направленная на ускорение разработки и доставки продукта потребителю через облегчение коммуникации между участниками процесса. Мы же помним, что участники преследуют противоположные цели? Dev — разработка, хочет «хоп-хоп — и в прод». Ops — сопровождение, хочет «не трогать, если работает». Они не враги — просто каждый решает свою часть общей задачи.
Где здесь место безопасников? Похоже, его нет: интернет полон статей, которые начинаются словами «сначала отключаем SELinux». Быстро, быстрее, ещё быстрее…
Но стартапами, смело накапливающими технический долг, индустрия не ограничивается. Есть и крупные компании. В них предполагается, что безопасники аккурат перед релизом будут приходить и проверять код на соответствие лучшим практикам. Если эксплуатацию такое задевает не слишком, то разработчики от этого горят, грустят и уходят. Вот слова одного соискателя из российского банка (этого человека я собеседовал): «Около полугода не могли согласовать с безопасниками релиз нашего продукта в продакшен, и я решил уйти».
По мере ускорения процессов в энтерпрайзы пришло понимание, что ни один отдел ИБ попросту не успеет проверить все-все-все релизы, выкладываемые в продакшен. А безопасники — нормальные, не «вахтёры» — исходят из того, что безопасности не бывает слишком много. Тогда коллективный разум пришёл к простому, но гениальному решению: пригласил их участвовать в процессе. Простой вариант — встроить инструменты проверки в пайплайн доставки. Более сложный — добавить безопасника, умеющего читать и писать код, в каждую продуктовую команду. Оцените изящество: раз уж собирается и выезжает на прод «оно само», то и проверки на дыры/баги/уязвимости пусть тоже проходят в режиме «оно само».
DevSecOps — та же методология для ускорения доставки новых функций пользователям, но она обязательно включает элементы ИБ в написание кода, обработку данных, использование сторонних библиотек — в общем, повсюду, где модель угроз указывает места, в которых проблем с безопасностью не должно быть ни в коем случае.
DevSecOps: от малого…
Поговорим о том, как включить DevOps и Sec в повседневную работу. Даже изменения на уровне команды дают результат: надо лишь знать, что менять, и быть последовательным. Статья «Страх и ненависть DevSecOps» позволяет взглянуть на DevSecOps с высоты птичьего полёта — в общем, это карта. На ней обозначены не только начало и конец пути, но и легенда: объяснены понятным языком сокращения SAST, DAST, SSDL, BSIMM и другие — те самые, из-за которых статьи о DevSecOps для непосвящённых выглядят как полная белиберда.
Желающим перейти от рассуждений о процессах к практике адресована статья «Обеспечиваем безопасность в гибкой разработке и CI/CD». Часть описанных в статье инструментов может внедряться в DevSecOps-процесс силами единственной команды, которая при этом ещё и работает над продуктом.
Тем же, кто хочет не просто внедрять безопасность, но и понимать, какие слабые места в процессах это внедрение закроет, поможет статья «Как (вы)жить без отдела безопасности». В ней переход от DevOps к DevSecOps описан вплоть до конкретных шагов, и некоторые из них может делать сама команда разработки. Очевидный плюс этой статьи — она предостерегает от поспешных действий, которые могут превратить работающее IT-решение в бесполезное и неработающее. Также автор объясняет, какие инструменты надо внедрять и почему именно их. Когда DevSecOps-практики переводятся на уровень компании, прозрачное описание процессных решений облегчает взаимодействие всех участников рабочего процесса.
Для нас DevSecOps — это «сдвиг влево» тестирования безопасности приложений. Мы проверяем очевидные проблемы в языковых конструкциях, использование компонент с известными уязвимостями, ищем секреты в коде. В общем, выявляем всё, что можно обнаружить на старте разработки ПО без лишних ложных срабатываний.
Алексей Бабенко
Лидер команды продуктовой безопасности, заместитель руководителя Центра программных решений Мир Plat.Form
…к большему: энтерпрайз
В предыдущей части мы рассмотрели микро-DevSecOps размером в одну команду, но с потенциалом роста. Теперь перейдём к энтерпрайзу — крупным компаниям, у которых уже есть отделы ИБ со сложившимися практиками и процессами. В больших проектах с серьёзным бюджетом и выделенными отделами ИБ набор вариантов шире, но ненамного: кто-то решает привлечь подрядчиков, кто-то выращивает нужные компетенции внутри. Всё сводится к балансу скорости и затрат: обычные инженерные компромиссы, ничего принципиально нового нет.
DevOps помогает проектам расти, но без внимания к безопасности они обречены. В популярных репозиториях иногда содержатся пакеты/образы с «полезной нагрузкой», вот только пользу она принесёт не вам.
Далее — варианты по нарастающей. «Практические ответы на нетривиальные вопросы, или Как внедрять DevSecOps в организации со сложным IT-ландшафтом» — это рассказ о внедрении DevSecOps в масштабах крупного банка своими силами, без подрядчиков, через выращивание соответствующей команды внутри компании. Пожалуй, самый долгий вариант, зато весь наработанный опыт остаётся в команде.
Другие компании переходят к безопасной разработке с помощью подрядчика. И это сюжет другой статьи — «DevOps vs DevSecOps: как это выглядело в одном банке». Понятно, что в этом случае внутренние команды приобретут несколько меньше опыта. Насколько такое решение подходит именно вашей компании — полагаю, вопрос инженерно-финансового компромисса.
Ну и третий вариант: отдать вопросы перехода не подрядчику-интегратору, а напрямую производителю конкретного инструмента. Здесь тоже нет готовых решений, потому что всё зависит от ситуации. Минимум одна такая история на Хабре описана: «Строим безопасную разработку в ритейлере. Опыт одного большого проекта».
Я не представляю, как жить, если перед каждым релизом команда безопасности на две недели уходит изучать код на предмет дыр. В наше время нельзя так затягивать сроки. При этом нам важна продуктовая безопасность, и ею занимается отдельная команда. Как у нас это получается?.. Секрет в том, что мы отошли от классической парадигмы тестирования.
Для нас внедрение DevSecOps стало естественным процессом — DevSecOps-практики пришли с развитием DevOps в компании, и мы растём синхронно с остальными направлениями. Ведь нельзя просто взять и перейти на DevSecOps независимо от других процессов: разработка и DevOps тоже эволюционируют.
Особенность неклассической парадигмы: если из набора «DevOps, разработка, DevSecOps» затормозилось что-то одно, то два других направления тоже застрянут.
Алексей Бабенко
Лидер команды продуктовой безопасности, заместитель руководителя Центра программных решений Мир Plat.Form
Инструментарий
Начинать можно с малого. Доказательство тому — статьи о конкретных инструментах для DevSecOps-практик. Пробежимся по популярным решениям. Они вовсе не страшные — наоборот, полезные.
Сначала уделим внимание процессной части. Пост «Как внедрить статический анализатор кода в legacy-проект и не демотивировать команду» посвящён сохранению боевого духа команды с начала перехода. Его большой плюс в том, что описанный подход не завязан на конкретный инструмент. Соответственно, что бы вы ни выбрали, эти приёмы послужат вам одинаково хорошо.
Разобрались с организационной частью — переходим к инструментам. Что в первую очередь приходит в голову при слове «разработка»? Кому что, а мне — Python! Поэтому продолжает нашу коллекцию статья «Ищем уязвимости в Python-коде с помощью open-source-инструмента Bandit». В ней описаны минимальная настройка и запуск бесплатного инструмента для простейшего анализа кода на Python.
Правда, на Python принято в основном писать бэкенды (так сложилось исторически). Ну, а фронтенд — это, по сути, обычные веб-сайты. Поэтому нашу коллекцию продолжает статья «Используем Zap Baseline Scan для непрерывного сканирования сайта на уязвимости». В ней познакомимся с простейшим бесплатным сканером уязвимостей веб-сайтов. Приятный сюрприз этого текста: автор описал не одиночный инструмент, а целый конвейер. Кроме инструкции по использованию сканера приведены простейший агрегатор отчётов плюс скрипт пересылки результата в любимый многими Telegram.
Мой страшный сон: в офис пришло письмо с выплатами от Илона Маска, и все сотрудники переслали его друг другу. Затем хакеры уводят базу с паролями, но все спокойны: данные пользователей зашифрованы в Base64… Лишь я просыпаюсь в холодном поту.
С Python всё понятно, а можно ли как-то улучшить вопросы с безопасностью кода на C? Пожалуйста, следующий! В статье «DevSecOps: организация фаззинга исходного кода» описывается полный процесс поиска уязвимостей — этот подход позволяет встроить поиск непосредственно в ту самую DevOps-восьмёрку.
Говорим: DevOps, думаем: «контейнер». Ладно. А можно ли чем-то проанализировать контейнеры? Можно: «Dockle — Диагностика безопасности контейнеров». Понятно, что инструмент простой. С другой стороны, он бесплатный, и лучше начать с него, чем не сканировать вовсе. Сам Dockle тоже предлагается запускать в контейнере, поэтому ждём комментариев от читателей с результатами сканирования контейнера Dockle с помощью Dockle — будет повод вспомнить известный мем YO DAWG.
Раз уж речь зашла о запуске контейнеров, следующая статья расскажет об инструменте, позволяющем ограничивать действия, доступные контейнерам в кластере Kubernetes. Если что-то было пропущено на этапе сборки контейнера — во время работы ограничения не позволят «делать странное». Итак, знакомьтесь: «Как автоматизировать безопасность контейнеров в стиле Policy as Code с помощью CRD». Описана не просто автоматизация, а именно встраивание элементов безопасности в пайплайн. К сожалению, одна из особенностей этого инструмента — доступ к его бесплатному варианту какой-то, кхм, непрозрачный: без SMS, но с обязательной регистрацией.
С контейнерами разобрались. Дальше будем рассматривать пару полноценных энтерпрайз-решений: SonarQube и Checkmarx. Первое больше на слуху, плюс есть возможность бесплатного использования — берите, ставьте, тестируйте. Поэтому ограничимся обзорной статьёй «Как мы внедрили SonarQube и осознали его большой потенциал» — MVP по встраиванию бесплатной SonarQube в конвейер GitLab.
Второе же решение — Checkmarx, а точнее CxSAST, то есть «статический анализатор исходного кода», — платное целиком и полностью. Поэтому статья «Hello, Checkmarx!» Как написать запрос для Checkmarx SAST и найти крутые уязвимости» о расширенной настройке анализатора пригодится читателям, у которых есть доступ к инструменту.
Думаю, раздел с инструментами будет неполным, если мы не коснёмся инфраструктуры. Поэтому в завершающей части — «Выбор инструмента для анализа безопасности кода Terraform» — будем рассматривать и выбирать инструмент для анализа IaaC осознанно, с примерами критериев и результатами тестов.
Внедрение DevSecOps сильно осложняет жизнь всем желающим добраться до ваших проектов.
Забавный факт: во время просмотра сайта Checkmarx я наткнулся на доступный бесплатно инструмент этого вендора под названием KICS, предназначенный именно для анализа IaaC и, что ещё более важно, обладающий поддержкой Ansible. Придётся рассказать о нём коллегам, а если из этого получится что-то полезное, попробую оформить свои впечатления в полноценную статью. А пока узнаем впечатления экспертов.
Когда мы начали развивать культуру безопасного написания кода, вскоре заметили результат. Всё реже ловим ошибки в коде, и у сканеров безопасности всё меньше положительных срабатываний. Команда продуктовой безопасности сосредоточилась на более специализированных багах: логических недостатках, ошибках на стыке систем, сложных цепочках недостатков.
Алексей Бабенко
Лидер команды продуктовой безопасности, заместитель руководителя Центра программных решений Мир Plat.Form
Рекомендации экспертов
Похоже, теорией мы запаслись, да и конкретными инструментами тоже. По всем канонам осталось выслушать напутствия мастеров. Так что этот раздел — сборник рекомендаций для тех, кто только присматривается или начал переходить от DevOps к DevSecOps.
Отладка процессов сложнее, чем отладка программ, ведь люди не компьютеры. Поэтому на очереди статья-призыв «Внедряйте статический анализ в процесс, а не ищите с его помощью баги». Она о том, как сделать из статического анализа полезный инструмент для улучшения качества кода. Обычно это генератор обширного спама «эй, тут в коде ошибка». В статье описан интересный способ, позволяющий не ломать идущий процесс разработки.
Статья «SonarQube и IntelliJ IDEA: правильная интеграция» поведает, как получить максимум пользы, запуская сразу несколько плагинов — анализаторов кода прямо в IDE. Правда, этот трюк можно проделать только в том случае, если вам доступен SonarQube. Ведь именно из него предлагается выгрузить настройки для плагинов. Это не позволит потенциально проблемному коду даже попасть в репозиторий. А ещё увеличит скорость обратной связи, поскольку разработчик больше не будет отправлять код в репозиторий для понимания качества и уныло ждать окончания скана.
Однажды злоумышленники взломали Ashley Madison, сайт знакомств для женатых и замужних. Дыры закрыли, но было уже поздно: дальше последовали шантаж, огласка, внезапно закончившиеся браки и жизни.
Статья «Использование сканера уязвимостей в используемых библиотеках Dependency-Check в GitLab CI» также посвящена инструменту, который можно запускать локально. Но у него другое предназначение: не позволить вашему проекту использовать уязвимые версии зависимостей.
Напоследок снова процессные вопросы. (Мы же помним, что процессы в компании отлаживать сложнее, чем код?) «11 способов (не) стать жертвой взлома в Kubernetes» — пошаговое how-to о том, как завести контейнеры в Kubernetes и не наделать массу дыр.
Статьи — вещь, безусловно, ценная. А чем напутствуют нас живые люди?
Инструмент не будет работать самостоятельно, поэтому начните изменения с процессов. Первым делом определите риски, от которых планируете защищаться, и выработайте способы защиты. Также советую обучить разработчиков, как писать безопасный код. Пусть такой код станет постоянной практикой в вашей компании. Проверьте системы в ручном режиме — насколько они безопасны, что стоит доработать. Когда найдутся проблемы (а они, скорее всего, найдутся), обсудите исправления с разработчиками.
Проделав всё это, вы сами поймёте, какие процессы автоматизировать, где и для чего использовать сканеры безопасности, а главное — что делать с результатами их работы.
Алексей Бабенко
Лидер команды продуктовой безопасности, заместитель руководителя Центра программных решений Мир Plat.Form
Рекомендую книги, которые погружают в тему DevSecOps и описывают важные процессы современной разработки:
— Мирко Херинг, «DevOps для современного предприятия». Книга интересно описывает полезные процессы и практики DevOps, поможет взглянуть на ваш проект по-новому. В ней описывается вся важность выстраивания процессов.
— Крис Ричардсон, «Микросервисы. Паттерны разработки и рефакторинга». Если вы разрабатываете микросервисы, эта книга для вас. Автор рассказывает о важных паттернах разработки и архитектуры современных микросервисных решений. Важно, что Крис Ричардсон показывает красивые варианты решения весьма сложных задач.
— Серия книг «DevOps Toolkit» от Viktor Farcic поможет построить качественные пайплайны непрерывной интеграции и доставки. Рекомендую читать самую свежую версию — первые издания несколько устарели. Помимо книг, автор ведёт полезный YouTube-канал.
Игорь Николаев
Тимлид инженеров по автоматизации процессов разработки ПО Мир Plat.Form
Заключение, выводы и финальное напутствие
Попробуем подвести итоги. Что сделал я за время работы над этой коллекцией:
- прочитал десятки статей;
- улучшил понимание процессов в основе DevSecOps;
- ознакомился с простыми и понятными способами построения/внедрения/отладки этих самых процессов;
- узнал о новом инструменте KICS и богатых возможностях локальной проверки кода в инструментах JetBrains;
- понял, что лиса — персонаж деструктивный.
За всё это благодарю хабраавторов. Кстати, хочу поделиться удивившим меня наблюдением. Из статей у меня сложилось впечатление, что DevSecOps — удел сурового энтерпрайза или производителей инструментов. Зачем в эту сторону идёт энтерпрайз — понятно. Зачем об этом пишут производители инструментов — тоже понятно. Но что насчёт средних компаний и аутсорса, интеграторов и консалтинга? Давайте обсудим это в комментариях.
ссылка на оригинал статьи https://habr.com/ru/articles/585496/
Добавить комментарий