DevSecOps & Shift-Left

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

В чём, собственно, интерес. Во-первых, я думаю, что основные открытия и изменения нас ждут в междисциплинарных областях. Одни знают, но не могут; другие могут, но не знают. Очевидно, что с этой проблемой активно помогает справляться AI. Во-вторых, разработчики в основном сконцентрированы на архитектуре и функциональности. По данным Positive Technologies 82% уязвимостей обусловлено ошибками в коде. Да, исследование не очень свежее, но я не думаю, что соотношение концептуально поменялось. Иначе говоря, разработчики обычно и не задумываются о том, что их чистый код может быть уязвим, и, как правило, даже не знакомы с инструментами проверки кода на безопасность. В общем, я решил заполнить этот пробел и подготовить несколько постов на тему “DevSecOps глазами разработчика”. Надеюсь, что будет интересно и познавательно, а также создаст предпосылки для обсуждения.

Мало нам всяких XXXOps, появился еще и DevSecOps. :) Суть заключается во встраивании автопроверок безопасности в цикл разработки с целью нахождения уязвимостей на самых ранних этапах. В контексте этого направления существует концепция Shift-Left — сдвиг проверок в левую часть цикла, то есть ближе к его началу. Это позволяет не допустить ошибки или значительно удешевить стоимость их исправления.

Обратите внимание, что техника Shift-Left стала популярной не только в сфере ИБ. Если посмотреть недавние доклады на тему архитектурного контроля, то можно заметить тот же “сдвиг влево”. Многие компании добавляют стадию согласования технического решения до момента его реализации, а некоторые автоматизируют этот процесс. На эту тему рекомендую посмотреть доклад про TDR от Павла Лакосникова (Авито). Аналогичные истории я слышал на прошедшем TechLeadConf.

Таким образом, DevSecOps-конвейер расширяет привычный нам CI/CD и состоит из нижеследующих этапов. Можно считать их “точками расширения”, в которые можно встроить инструменты проверки на ИБ.

Pre-commit — проверка кода до того, как он будет за-commit-чен (pre-commit hook). Как правило, производится сканирование кода на наличие незашифрованной конфиденциальной информации: пароли, токены, API-ключи и т.п. Типы инструментов: Secret Detection.
Pre-build — проверка кода после того, как он был за-push-ен. Производится статический анализ исходного кода и его зависимостей на наличие распространённых уязвимостей (см. OWASP Top Ten) и лицензионной совместимости. Типы инструментов: Secret Detection, SAST, SCA.
Post-build — проверка артефакта, собранного из исходного кода, например, JAR-архива, NuGet-пакета или Docker-образа. Производится анализ окружения и зависимостей приложения, отыскиваются устаревшие версии пакетов и библиотек. Типы инструментов: Binary SCA.
Test-time — проверка приложения, которое запущено с целью тестирования из собранного артефакта. Производится попытка “сломать” приложение, имитируя действия злоумышленников, или обнаружить проблемы в runtime. Типы инструментов: DAST, OAST, IAST.
Post-deploy — обеспечение безопасности приложения после развёртывания в production-среде. Совокупность мер и средств, которые осуществляют мониторинг, анализ, обнаружение и блокировку подозрительной активности. Типы инструментов: RASP, Sandboxing, Self-sandboxing.

Предлагаю сильно не переживать на счёт неизвестных аббревиатур, т.к. в последующих постах я расскажу, что это такое и почему это не так страшно. А пока предлагаю посмотреть на OWASP Cheat Sheet Series — серию практичных рекомендаций, как можно улучшить безопасность своего кода (слева в навигаторе можно выбрать язык или технологию).

Предлагаю делиться историями про свою первую встречу с ИБ. :)

Понравилась статья?