С начала 2022 года ландшафт ИБ в разработке изменился кардинально. Внедрение Safe Board ушло, вендоры SAP ушли, а количество целевых атак (APT) на репозитории и пайплайны только выросло.

Если вы отвечаете за безопасность разработки или внедряете процессы DevSecOps «с нуля» в текущих реалиях, вот на что я рекомендую обращать внимание сегодня.

1. Импортозамещение — это не про «галочку», а про риск
Мы все перешли на российские ОС, СУБД и средства сборки (GitFlic, СберТех и др.).
Главная боль: инструменты новые, багов в них много, а эксплойты под нулевые дни (0-day) для российского ПО уже активно продаются на теневых форумах.
Внедряйте DAST и IAST на этапе тестирования. Не верьте, что «раз российское, значит безопасное». Проверять код придется даже тщательнее, чем раньше, пока экосистема не устаканится.

2. Зависимости (Open Source) стали минным полем
NPM, PyPI, Maven — оттуда мы продолжаем качать библиотеки. Но теперь популярный пакет может внезапно удалить автор (как было с colors.js) или его могут взломать.

Обязательно поднимайте репозиторий-кэш (артефакторий) типа Nexus или JFrog внутри контура.
Никаких прямых go get или pip install с продакшн-серверов. Только через прокси с проверкой.

3. Сдвиг влево (Shift Left) на российский лад
Раньше мы могли купить SaaS-решение и сканировать код в облаке. Теперь многие облака либо недоступны, либо требуют аттестации.
Встраивайте сканеры кода (SAST) прямо в раннеры вашего GitLab CI / GitHub Enterprise. У нас есть достойные инструменты (например, от Solar, Positive Technologies), которые умеют работать в изолированных контурах. Лучше найти ошибку в момент коммита, чем когда код уже упал на стенд.

4. Контейнеризация и безопасность образов
Все на Kubernetes. Все на Docker (или Podman). Но базовые образы мы теперь тянем не из официального Docker Hub, а из Nexus или c Nexus Registry.

Сканируйте базовые образы на уязвимости (CVE) перед сборкой. Часто в «замороченный» образ разработчик докидывает утилиты для отладки, которые превращают подушку безопасности в решето.
Запретите запуск контейнеров от root. Это база, но о ней постоянно забывают.

5. Люди и компетенции
Безопасников, которые понимают и код, и Kubernetes, и российское ПО, — единицы.
Что делать: Растить внутри. Не наказывать разработчиков за найденные уязвимости, а выстраивать процесс так, чтобы найти баг было почетно (Bug Bounty внутри команды). Если разработчик боится безопасника — он будет прятать костыли, а не чинить их.

Руководить безопасной разработкой сейчас — значит быть буфером между требованиями регуляторов (ФСТЭК, приказы Минцифры) и реальностью кода. Нужно уметь объяснять, почему защита конвейера сборки важнее, чем очередной «бумажный» документ.

#DevSecOps #БезопаснаяРазработка #InfoSec #РоссийскоеПО #CICD