В прошлой статье цикла мы завершили развертывание инфраструктуры будущего РБПО: установили GitLab, Nexus, HashiCorp Vault, Dependency-Track и DefectDojo, подготовили отдельную виртуальную машину с инструментами безопасности и убедились, что все сервисы успешно запускаются.
Однако установка сервисов — лишь половина работы. Теперь их необходимо сконфигурировать и подготовить к взаимодействию. Без этого GitLab останется просто GitLab, Vault — простым хранилищем секретов, а DefectDojo и Dependency-Track — красивыми веб-интерфейсами без практической ценности.
В этой статье займемся базовой конфигурацией. Настроим GitLab и GitLab Runner, подготовим Nexus к приему артефактов, научим Vault доверять GitLab через JWT-аутентификацию и создадим необходимые сущности в DefectDojo и Dependency-Track.
Документация открыта, терминал запущен, банка кваса на месте. Приступаем к настройке инструментов.
Важно сразу договориться, Путник!
Данный цикл статей не заменяет требования ГОСТ, OWASP SAMM, BSIMM и других серьезных методологий безопасной разработки. Это, скорее, практический пример того, как можно организовать конвейер безопасной разработки ПО с минимальными затратами.
Все описанное в цикле — исключительно мой личный опыт, набитые шишки и результаты долгих вечеров за клавиатурой. Это не официальная позиция моего текущего или бывших работодателей.
Воспринимать статью как руководство к бездумному копированию тоже не стоит. Проверяй все на тестовых стендах, делай бэкапы и подходи к экспериментам с холодной головой.
Ошибки возможны, и не нужно бояться их совершать. Главное — делать выводы и постепенно строить процессы, которые будут надежнее вчерашних.
Сразу оговорюсь: HTTPS в рамках домашней лаборатории я настраивать не стал. Причин несколько:
стенд учебный, а не боевой;
мой роутер не поддерживает настройку локального DNS;
для полноценной схемы с внутренним центром сертификации пришлось бы поднимать дополнительную виртуальную машину, а свободных ресурсов осталось немного — текущий стенд уже потребляет 22 ГБ RAM.
Так что пока работаем по HTTP. Но пароли меняем сразу — это святое.
GitLab
«В каждой избе свой порядок», — подумал я и первым делом занялся структурой GitLab.
После первого входа под root-паролем (который подсмотрел командой sudo cat /etc/gitlab/initial_root_password на виртуальной машине с сервисом) сразу меняю пароль на свой.
Потом создаю группу репозиториев для служебных проектов, шаблонов пайплайнов, IaC-конфигов и для разрабатываемых приложений.
Если речь идет не о демонстрационном стенде, а о реальной разработке, проекты лучше разделить по нескольким группам в соответствии с их назначением.
Далее закидываю в репозиторий код нашего уязвимого приложения.
Для выполнения пайплайнов нам понадобится GitLab Runner — агент, который получает задания от GitLab и запускает соответствующие этапы CI/CD-конвейера.
Устанавливать его будем на пятую виртуальную машину (sec-vm), поскольку на ней уже есть Docker и все необходимые инструменты безопасности.
После установки я зарегистрировал два раннера: с исполнителем Docker и с исполнителем Shell. Для них указал теги docker, linux, devsecops и shell, linux, local соответственно. Также включил автозапуск, чтобы после перезагрузки виртуальной машины раннеры автоматически возвращались к работе.
Добавляю репозиторий:
Устанавливаю пакет:
Регистрирую раннер (интерактивно или через параметры):
В процессе регистрации мне потребуется:
URL GitLab — в моем случае http://192.168.0.201:9090/.
Токен регистрации, который нужно получить в GitLab по пути Admin Area → CI/CD → Runners → Register an instance runner.
Описание — произвольное имя раннера, docker-runner или shell-runner.
Теги: docker, linux, devsecops (эти теги потом будут использоваться в пайплайнах).
Executor — тип исполнителя. В нашем случае потребуется зарегистрировать два раннера: один с исполнителем docker, второй — с исполнителем shell.
Образ по умолчанию: alpine:latest
Включаю автозапуск:
Проверяю статус:
После регистрации убеждаюсь, что раннер появился в списке и имеет зеленый статус.
В настройках репозитория запретил пушить в main напрямую — только через Merge Request и только мейнтейнерам.
Переменные CI/CD
Чтобы пайплайн мог взаимодействовать с остальными сервисами нашего конвейера, ему потребуется несколько параметров: адрес Vault, идентификаторы проектов в Dependency-Track и идентификатор продукта в DefectDojo.
Для всех проектов я добавил две глобальные переменные:
Переменная
Значение
Защита/Маскировка
VAULT_AUTH_ROLE
ci-role
Не защищать и не маскировать
VAULT_ADDR
http://192.168.0.203:8200
Маскировать
Добавить их можно в разделе Admin → CI/CD → Variables.
Для каждого проекта потребуется создать собственный набор переменных:
Переменная
Значение
Защита/Маскировка
DEPENDENCY_TRACK_PROJECT_DOCKER_UUID
UUID проекта в рамках которого буду анализировать состав докер контейнера полученный из Dependency-Track
Маскировать
DEPENDENCY_TRACK_PROJECT_UUID
UUID проекта полученный из Dependency-Track
Маскировать
DOJO_PRODUCT_ID
ID продукта полученный из DefectDojo
Маскировать
Эти переменные добавляются в разделе Settings → CI/CD → Variables конкретного проекта.
Nexus
«Хранилище — всему голова», — сказал я и принялся наводить порядок в Nexus.
После входа с паролем из файла /nexus-data/admin.password я сразу его сменил.
Чтобы создать физическое хранилище данных, провожу настройку Blob Stores:
Перехожу по пути Administration → Repository → Blob Stores.
Создаю отдельные Blob Store для разных типов данных. Например, docker-blob, npm-blob, pgsql-dump-blob. Это позволит управлять местонахождением файлов на диске и упростит резервное копирование.
Создаю репозиторий для хранения Docker контейнеров. Путь: Administration → Repository → Repositories → Create repository.
Для Docker (hosted):
Выбираю recipe docker (hosted).
В Storage выбираю созданный ранее Blob Store.
В Repository Connectors я оставляю Path based routing, так как у меня не будет домена и выставить отдельный порт я не смогу. Хранилище будет доступно по адресу http://192.168.0.202:8081/repository/docker/.
В рамках настройки доступа для CI/CD создаю отдельного пользователя для GitLab CI. Для этого:
1. Создаю роль nx-deployment. Перехожу в Security → Users → Roles (выдаю права только на работу с репозиториями).
Для Docker образов нам нужны следующие права:
nx-repository-view-docker-*-read — чтение;
nx-repository-view-docker-*-add — добавление новых артефактов;
nx-repository-view-docker-*-edit — редактирование;
nx-repository-view-docker-*-browse — просмотр содержимого;
2. Дальше перехожу в Security → Users → Create local user и создаю нового пользователя:
Ввожу ID: gitlab-ci.
Ввожу Password: задайте сложный пароль.
В роли добавляю nx-deployment (это наша ранее созданная роль).
Теперь GitLab CI сможет пушить образы и отчеты, не светя паролем в коде.
HashiCorp Vault
Чтобы пайплайны могли безопасно получать секреты из Vault, нужно научить его доверять GitLab. Для этого настроим JWT-аутентификацию.
Root-токен я спрятал подальше — он только для начальной настройки. Важное уточнение про безопасность root-токена: никогда не используйте root-токен в повседневной работе, и тем более в CI/CD! Root-токен нужен только для начальной настройки. После создания политик и ролей доступ к секретам должен осуществляться только через них.
JWT-аутентификация
Перехожу в виртуальной машине vault-vm в контейнер с Vault и логинюсь.
Включаю движок kv-v2 по пути secret, заливаю туда наши секреты (URL и API-ключи DefectDojo, Dependency-Track, Nexus).
Затем создаю политику ci-policy с правами на чтение этих путей.
И самое вкусное — настраиваю JWT-аутентификацию.
Если немного углубиться, то в рамках команды определяется:
auth/jwt/role/gitlab-role — путь к роли.
role_type="jwt" — явно указывает, что роль использует JWT.
bound_audiences — обязательный aud JWT-токена. GitLab выпускает токены с определенным aud, его нужно указать.
groups_claim — поле, содержащее список групп GitLab, чтобы Vault мог сопоставить их с политиками.
policies — политики Vault, которые будут назначены при успешной аутентификации.
ttl — время жизни полученного Vault-токена.
GitLab CI умеет выдавать ID_TOKEN для каждого джоба. Я сконфигурировал Vault так, чтобы он доверял токенам, подписанным моим GitLab'ом.
Вот тут-то меня и ждал затык: авторизация не проходила, пока я не дописал в конфиг JWT правильный jwks_url и default_role.
После этого всё заработало. Конвейер получал токен, обращался к Vault, а Vault выдавал ему секреты. Красота!
DefectDojo
Теперь подготовим DefectDojo к приему результатов сканирования. Именно сюда наши инструменты безопасности будут отправлять найденные уязвимости, поэтому сначала настроим доступ для CI/CD, а затем создадим продукт — по сути, карточку нашего приложения, к которой будут привязываться результаты проверок.
Для начала генерирую API-токен, который позже понадобится пайплайнам GitLab:
В правом верхнем углу жму на иконку пользователя.
Нажимаю кнопку Get API Key.
Копирую сгенерированный токен — это и будет DOJO_API_TOKEN для GitLab.
Затем создаю продукт. В левом меню выбираю Products → Add Product. Заполняю имя и описания продукта, жму кнопку Submit.
И самое главное — включаю глобальную дедупликацию в настройках системы, чтобы дефекты безопасности при новых сканированиях не дублировались. Очень полезная штука, иначе можно утонуть в повторяющихся багах.
В DefectDojo переходим в Settings → System Settings.
Находим опцию Deduplicate findings и Delete duplicates и включаем ее. Это активирует алгоритм дедупликации для всех будущих импортов.
Всё, теперь наши сканеры будут слать сюда отчеты.
Dependency-Track
Теперь подготовим к работе Dependency-Track. Этот сервис будет отвечать за анализ состава нашего приложения и контейнеров, отслеживать уязвимости в используемых компонентах и хранить информацию о найденных проблемах.
«Граф зависимостей — как паутина, запутаешься», — вздохнул я и создал в Dependency-Track проект с версией 1.0.0.
Затем в разделе Administration → Access Management → Teams создал команду Automation с типом Automation и правами: BOM_UPLOAD, PROJECT_CREATION_UPLOAD, VIEW_PORTFOLIO.
Сгенерировал API-ключ и сохранил его в Vault. Теперь GitLab CI сможет загружать SBOM-файлы, а Dependency-Track будет сам обновлять уязвимости и строить красивые графики.
Настроил проекты:
Перешел в Projects → Create Project.
Указал имя и версию. Было создано 2 проекта — один под SBOM самого разрабатываемого ПО, второй под SBOM контейнера. В дальнейшем при загрузке SBOM (Software Bill of Materials) через API Dependency-Track будет автоматически обновлять данные по этому проекту.
Начиная с сентября 2025 года сервис требует аутентификацию для доступа к API, поэтому для работы анализатора необходимо зарегистрировать бесплатную учетную запись на сайте OSS Index и указать полученные учетные данные в настройках Dependency-Track.
Заключение
На этом подготовительный этап можно считать завершенным. Мы настроили основные сервисы будущего конвейера безопасной разработки: GitLab, Nexus, Vault, DefectDojo и Dependency-Track, а также связали их между собой там, где это потребуется для дальнейшей автоматизации.
В следующей статье займемся тем, ради чего всё это и затевалось: напишем главный «свиток» нашего царства безопасной разработки — файл.gitlab-ci.yml, в котором будет описана вся логика конвейера. Также соберем полноценный пайплайн из этапов build, sbom, code-scan и upload, подключим общие шаблоны из репозитория devsecops, научимся получать секреты из Vault через JWT и автоматически отправлять результаты работы в Nexus, DefectDojo и Dependency-Track.
До встречи в следующей части цикла!
Для более глубокого изучения каждой темы, вот прямые ссылки на официальную документацию:
GitLab: GitLab Docs: Security Best Practices — общие рекомендации.
Nexus: Sonatype Support: Nexus Repository Manager — официальная документация.
Vault: HashiCorp Developer: Vault Documentation — полное руководство.
DefectDojo: DefectDojo Documentation — официальная документация проекта.
Dependency-Track: Dependency-Track Documentation — все о конфигурации и использовании.
t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона