Про Shift Left вы наверняка знаете — в контексте DevOps или QA об этом часто пишут. А что за зверь такой — Shift Left Security (SLS)? Вроде новый термин, свежий, «хайповый»? Отнюдь, концепция смещения влево процессов безопасности появилась вместе с DevOps. И они друг от друга неотделимы. Процессы идут в контексте исторического развития, а подтверждение этому — отчеты и документация, например, GitLab. Попробую доказать это утверждение. 

Меня зовут ​​Алексей Шарапов, Head of DevOps в Ak Bars Digital. Занимаюсь всем, что связано с процессом DevOps, включая и безопасность, и взаимодействие между отделами. 

Поговорим, что такое Shift Left Security, зачем это нужно и как оптимально встроить проверки безопасности в pipeline. 

Начнём издалека.

Кратко: как строили процесс безопасности раньше?

В далекие времена, когда рыцари на конях защищали замки от драконов, существовали выделенные отделы безопасности, которые занимались какими-то «своими» процессами и строили безопасность контура. Выглядело все это примерно как на скриншоте. 

Источник: https://safe-surf.ru/specialists/article/5269/651173/?sphrase_id=58447 

Мы видим мультивендорную архитектуру, ЦОД, фишки в виде отказоустойчивости через дублирование компонентов. Но, главное, мы видим эшелонированную защиту от внешних угроз. Все это поднимаем, разворачиваем, внутрь к нам не пробиться. Но…

Отдел безопасности сидит в отдельном «замке», настраивает свои инструменты, не спеша смотрит на код, прогоняет по своим процессам контроля качества, аудита. Через «полгода» перекидывает все, что сделали «за забор». Логично, что такая архитектура сильно влияет на поставки, когда разработчики сидят и ждут «Когда же наш код появится и мы его увидим воочию?»

Остановки в работе валидны, может быть, в waterfall, но мы сейчас говорим о современных процессах, аджайл и все такое. Но сейчас у нас везде DevOps и старые подходы не работают — безопасность смещается влево, даже если вы специально над этим не работаете.

Отчёты: развитие DevOps = развитие Shift Left

Puppet. Puppet одними из первых затронули вопрос, что качество и безопасность находятся в общей коллективной ответственности, а безопасность, с какого-то далекого защищенного контура, начала подбираться ближе к разработке. Об этом, начиная с отчета «2013 State of DevOps Report», они говорят в своих ежегодных отчетах, в которых рассказывают, как и в какую сторону двигается DevOps. 

Еще тогда они не говорили о SLS. Первое упоминание о Shift Left появилось в отчетах Puppet в 2015 году.

А первое упоминание того, как Shift Left может влиять на весь процесс DevOps появилось уже на следующий год — в отчете State of DevOps Report 2016 года.

Судя по отчету, в тот момент команды стали тратить на выкатку релиза примерно на 50% меньше времени. Почему? Потому что разработчики стали больше погружаться в вопросы безопасности и общаться со своим отделом ИБ, вопросы стало легче решать. На мой взгляд, это достаточно хорошая цифра. 

Естественно, не могу утверждать, что статистика абсолютно верна, и из 100% компаний все ускорились в 2 раза, но динамику вижу по своему опыту. 

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

Естественно, после отчета опять все позвонили своему DevOps, сказали «Давай, помогай решать эти вопросы». Как обычно)

GitLab. Сейчас первенство по значимым отчетам взял GitLab, как мне кажется. Ссылаюсь на их отчет 2021 года, в котором они опросили 4300 респондентов.

Важные моменты, которые я выделил из отчета.

Основная мысль —  ускорение поставок. В отчете говорится, что «почти 60% разработчиков ускорились в 2 раза быстрее, чем раньше (до пандемии, примерно 2019 год), благодаря DevOps, а 84% разработчиков — что ускорились быстрее, чем когда-либо прежде». Сам GItLab достаточно много делает для продвижения DevOps в массы: пишет инструменты, обогащают свою платформу и ускорение поставок — одна из основных идей (постулатов) направления движения процессов DevOps.

Shift Left в 2021 году у 70% опрошенных команд. Больше 70% специалистов по безопасности сообщили, что их команды сместили процесс влево. Причем это не 100%, не полное покрытие, и вопрос остается актуальным для многих компаний, но в 2016 году таких команд было 50%

Снижение разрыва между Sec и Dev. Команды явно начали отмечать, что благодаря глубокой интеграции между отделами и взаимопониманию удалось избежать разрыва и прийти к какому-то общему решению. Инструменты безопасности, передвигаясь влево, позволяют правильно выстроить цикл поставки приложений. Какая-то часть абстракций, которые были изначально справа, смогли переместиться в сторону разработки. Причем именно благодаря инструментам, которые мы подсветили. Это создает такое симбиотическое отношение.

Увеличение уровня безопасности. С одной стороны, звучит странно — мы убираем какую-то часть с правой стороны и, возможно, уменьшаем security. Но мы увеличиваем security с левой стороны, в области кода, когда уделяем безопасности больше внимания.

Это сильно влияет на весь workflow, потому что появляется новый инструментарий, который валиден. Например, для Kubernetes или сред, близких к облачным. За счет этого безопасность «размазываем» на весь процесс, ускоряя поставку, но снижая количество уязвимостей, а общий уровень безопасности растет. 

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

Перейдем к другим отчетам.

Cloud Architecture Center. Google тоже проводит подобные исследования и выкладывает их на своей платформе Cloud Architecture Center. В одном из последних материалов DevOps tech: Shifting left on security они пропагандируют похожие принципы, что у Puppet и GitLab. 

Процесс Security здесь называется InfoSec. Они рассказывают, как InfoSec начинает входить в сущность проектирования и разработки ПО, и декларируют принцип «Начинаем проектировать безопасность еще раньше, и проектируем не какой-то контур, а на уровне разработки».

И делятся способами измерения качества этого внедрения.

Зачем? Потому что разработчики могут запускать код, например, в AWS или GCP, и мы не можем повлиять на какой-то внешний контур. Можно добавить балансировщиков, сделать какой-то другой контур, но рядом растет и развивается K8S, on-premise облака.

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

Без взаимодействия Dev и Sec нормально доставлять код у вас физически не получится, потому что показывая ИБ какое-то on-premise облако, будет много вопросов «А почему так? А в том же самом Кубере у вас мигрируют IP, а ноды переезжают, поды переезжают, на что мы смотрим, к чему обращаемся?» 

Есть подходы, когда поды оставляем в К8S на нодах, но мы тогда теряем гибкость, скорость.

Как сейчас: пайплайны и инструменты

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

Процессы DevOps позволяют строить пайплайны в зависимости от ваших потребностей, а не от каких-то общепринятых практик. Построив, вы можете спокойно добавлять проверки безопасности на ранних стадиях. Базовый старт защиты возможен с инструментами DevOps стека, который у вас уже есть.

Инструментов много: Aqua, Nexus (проверка безопасности входит в платную версию), есть Harbor, в него встроен Trivy, который уже позволяет собирать контейнер-уязвимости и проверять по базе уязвимостей, которая постоянно пополняется.

Вам остается только это использовать и продолжать работать. 

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

• Стейджи примерно у всех похожи.

• Verify, может быть compile, может быть предварительная проверка.

• Можете попробовать ввести какой-то Code Quality, даже на open source, например, Sonar.

• Можете внедрить Container Scanning, Dependency Scanning, инструментов много, ранее их перечислил. 

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

Изображение из архитектурных принципов Google: 

Добавил сюда, чтобы показать, что этап сканирования мы можем добавлять в любой этап CI\CD пайплайна и дальше обогащать различными активностями. 

И вот, базовое внедрение вы совершили: у вас есть какая-то система хранения артефактов, вы настроили себе пайплайны. Переходим к анализаторам.

Анализаторы кода. В том же отчете GitLab говорится, что значительное увеличение команд, которые сместились влево, частично связано с увеличением числа разработчиков, проводящих статическое и динамическое тестирование безопасности приложений: 53% разработчиков используют SAST-инструменты, а 44% — DAST. Эти инструменты появились где-то в 2012 году, когда как раз начались первые «движения» в сторону DevOps.

SAST — Static Application Security Testing. Фактически отвечает за тестирование «белого ящика». Позволяет находить уязвимости на ранних стадиях разработки ПО.

Есть DAST — Dynamic Application Security Testing, тестирование «черного ящика», позволяет находить уязвимости и слабые места в работающем приложении.

Container Scan — начали развиваться с появлением контейнеров. Популярные вендоры Clair, Trivy, Anchor, Aqua, Qualis. Мы используем Trivy.

Dependency Scans. Я думаю, все вы с ними, в той или иной мере, сталкивались: Nexus, Artifactory, Aquam, Dependency-Check Plugin for SonarQube, WhiteSource.

IAST – Interactive Application Security Testing, интерактивное тестирование безопасности приложений.

RAST – Run-time Application Security Testing, защита безопасности приложений во время выполнения. 

Существует множество различных анализаторов кода: статические, динамические, контейнер-сканы, есть проприетарные, есть open source продукты. Можно использовать любые, под ваши задачи. Главное, что это можно делать на любом этапе.  

Итоги

Мы посмотрели, как строили процесс раньше, как сейчас и отчеты. Удалось ли мне убедить вас, что SLS и DevOps идут вместе, и большая часть инструментария для проверок у вас уже есть? Уже сейчас вы можете получить защищенный контур с уменьшением влияния отдела безопасности, но при этом с увеличением безопасности своего кода и всех процессов.

Статью подготовил на основе моего выступления на митапе «Интегрированная безопасность в разработке, или Соблюдай технику безопасности!».