В прошлой статье цикла мы закончили разворачивать инфраструктуру будущего РБПО: установили GitLab, Nexus, HashiCorp Vault, Dependency-Track и DefectDojo, подготовили отдельную виртуальную машину с инструментами безопасности и убедились, что все сервисы успешно запускаются.

Но установить сервисы — это только половина дела. Теперь их нужно настроить и подготовить к совместной работе. Без этого GitLab останется просто GitLab, Vault — просто хранилищем секретов, а DefectDojo и Dependency-Track — красивыми веб-интерфейсами без практической пользы.

В этой статье займемся базовой конфигурацией. Настроим GitLab и GitLab Runner, подготовим Nexus к приему артефактов, научим Vault доверять GitLab через JWT-аутентификацию и создадим необходимые сущности в DefectDojo и Dependency-Track.

Документация открыта, терминал запущен, банка кваса на месте. Начинаем настройку инструментов.

Сразу оговорюсь: HTTPS в рамках домашней лаборатории я настраивать не стал. Причин несколько: 

1. стенд учебный, а не боевой;

2. мой роутер не поддерживает настройку локального DNS;

3. для полноценной схемы с внутренним центром сертификации пришлось бы поднимать дополнительную виртуальную машину, а свободных ресурсов осталось немного — текущий стенд уже потребляет 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 соответственно. Также включил автозапуск, чтобы после перезагрузки виртуальной машины раннеры автоматически возвращались к работе.

Добавляю репозиторий:

curl -L «https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh» | sudo bash

Устанавливаю пакет:

sudo apt install -y gitlab-runner

Регистрирую раннер (интерактивно или через параметры):

sudo gitlab-runner register

В процессе регистрации мне потребуется:

• 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

Включаю автозапуск:

sudo systemctl enable gitlab-runner

Проверяю статус:

sudo systemctl status gitlab-runner

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

В настройках репозитория запретил пушить в main напрямую — только через Merge Request и только мейнтейнерам.

Переменные CI/CD

Чтобы пайплайн мог взаимодействовать с остальными сервисами нашего конвейера, ему потребуется несколько параметров: адрес Vault, идентификаторы проектов в Dependency-Track и идентификатор продукта в DefectDojo. 

Для всех проектов я добавил две глобальные переменные: 

Добавить их можно в разделе Admin → CI/CD → Variables. 

Для каждого проекта потребуется создать собственный набор переменных:

Эти переменные добавляются в разделе 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 и логинюсь.

docker exec -it vault sh
export VAULT_ADDR=http://127.0.0.1:8200
vault login <root_токен>

Включаю движок kv-v2 по пути secret, заливаю туда наши секреты (URL и API-ключи DefectDojo, Dependency-Track, Nexus).

vault secrets enable -path=secret kv-v2
vault kv put secret/dependency-track url="http://192.168.0.204:8081" api_key=""
vault kv put secret/defectdojo url="http://192.168.0.204:9090" token=""
vault kv put secret/nexus url="http://192.168.0.202:8081" docker-repo="docker" registry="192.168.0.202:8081" username="gitlab-ci" password=""

Затем создаю политику ci-policy с правами на чтение этих путей.

vault policy write ci-policy - <<EOF
path "secret/data/defectdojo" {
  capabilities = ["read"]
}
path "secret/data/dependency-track" {
  capabilities = ["read"]
}
path "secret/data/nexus" {
  capabilities = ["read"]
}
EOF

И самое вкусное — настраиваю JWT-аутентификацию.

vault write auth/jwt/role/gitlab-role \
    role_type="jwt" \
    vault write auth/jwt/config \
    oidc_discovery_url="http://192.168.0.201:9090" \
    bound_issuer="http://192.168.0.201:9090" \
    groups_claim="groups" \
    policies="gitlab-policy" \
    ttl=1h

Если немного углубиться, то в рамках команды определяется:

• 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 write auth/jwt/config \
    jwks_url="http://192.168.0.201:9090/oauth/discovery/keys" \
    default_role="ci-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 будет сам обновлять уязвимости и строить красивые графики.

Настроил проекты:

1. 1. Перешел в Projects → Create Project.

2. 2. Указал имя и версию. Было создано 2 проекта — один под SBOM самого разрабатываемого ПО, второй под SBOM контейнера. В дальнейшем при загрузке SBOM (Software Bill of Materials) через API Dependency-Track будет автоматически обновлять данные по этому проекту.

   

3. 3. Начиная с сентября 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.

До встречи в следующей части цикла!

PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикад

t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона