GitLab 14.10: SAST, dependency scanning и Sigstore-подпись Docker-образов

GitLab 14.10 вышел в конце апреля, и на этот раз акцент в релизе заметно смещён в сторону безопасности. Для нас это хорошее совпадение по времени: клиенты на managed-сопровождении после цепочки supply chain инцидентов начали реально интересоваться верификацией артефактов, а не просто кивать на слайде. Обновляем инсталляции и разбираем что нового.

Что изменилось в SAST и dependency scanning

Статический анализ в GitLab работает через набор анализаторов - каждый под свой стек. В 14.10 несколько из них обновились, самое заметное - Semgrep-анализатор для Python и JavaScript. GitLab переводит SAST с самописных правил на Semgrep как основной движок для этих языков, что даёт больше правил из сообщества и меньше false positive на типичных паттернах.

Dependency scanning стал аккуратнее работать с транзитивными зависимостями в Go-проектах. Раньше go.sum обрабатывался достаточно грубо, теперь вытаскивается более полный граф. Насколько это повлияет на реальный catching уязвимостей - покажет практика, но направление правильное.

На уровне интерфейса - Security Dashboard получил фильтрацию по severity и статусу, что позволяет не тонуть во всём что нашлось, а работать очередями. Мелочь, но при большом количестве проектов это ощутимо.

Sigstore: почему вовремя

Главная новинка с практической точки зрения - интеграция с Sigstore для подписи артефактов. GitLab добавил поддержку cosign в Container Registry: образы можно подписывать в рамках пайплайна и верифицировать подпись перед деплоем.

Sigstore - это проект с прозрачным журналом (Rekor) и сервисом выдачи краткосрочных сертификатов (Fulcio). Идея в том, что подпись привязывается к OIDC-идентичности (CI-джоба, человек через GitHub/Google), сертификат живёт несколько минут и записывается в публичный лог. Никаких долгоживущих ключей подписи, которые надо хранить и ротировать.

После того что произошло с GitHub Actions и Heroku в начале апреля (мы разбирали механику), разговор с клиентами о подписи образов стал значительно проще. Уже не «зачем это вообще нужно», а «как именно включить».

Как включаем в пайплайне

Базовая схема, которую мы раскатываем на клиентских инсталляциях:

stages:
  - build
  - sign
  - verify

build-image:
  stage: build
  image: docker:20.10
  services:
    - docker:20.10-dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    reports:
      container_scanning: gl-container-scanning-report.json

sign-image:
  stage: sign
  image: gcr.io/projectsigstore/cosign:v1.8.0
  id_tokens:
    SIGSTORE_ID_TOKEN:
      aud: sigstore
  script:
    - cosign sign
        --identity-token="${SIGSTORE_ID_TOKEN}"
        $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

verify-image:
  stage: verify
  image: gcr.io/projectsigstore/cosign:v1.8.0
  script:
    - cosign verify
        --certificate-identity-regexp=".*"
        --certificate-oidc-issuer="https://gitlab.com"
        $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

Ключевой момент - id_tokens. GitLab 14.10 добавил нативную поддержку OIDC-токенов для джоб: токен выдаётся под конкретную джобу, живёт несколько минут, привязан к issuer'у инсталляции. cosign принимает его через Fulcio и выдаёт краткосрочный сертификат для подписи. Всё записывается в Rekor.

На стороне деплоя - verify перед kubectl apply или аналогичным. В связке с admission controller (например, Kyverno или OPA Gatekeeper) можно сделать так, что в кластер вообще не попадёт образ без валидной подписи.

Нюансы обновления инсталляций до 14.10

Мы обслуживаем self-managed GitLab у нескольких клиентов, большинство на Omnibus. Обновление с 14.9 до 14.10 в целом штатное, но несколько вещей стоит проверить заранее.

PostgreSQL версия. GitLab с 15.x начнёт требовать PostgreSQL 13+. Сейчас 14.10 ещё терпит 12-ю, но если клиент на 12 - лучше запланировать апгрейд базы сейчас, пока он не стал блокирующим.

Runner конфигурация и OIDC. Чтобы id_tokens работали в пайплайне, Runner должен быть версии 15.0+ - да, именно Runner, не GitLab. Это немного контринтуитивно. Проверяем версии Runner'ов на всех shared-executor'ах перед тем как включать Sigstore-пайплайны.

Container Registry и cosign. cosign пишет подписи как отдельные теги вида sha256-<hash>.sig в тот же registry. Убеждаемся, что политики cleanup в registry не вычищают их раньше времени - такое бывает если настроен агрессивный GC по тегам без защиты.

Где находимся

SAST и dependency scanning уже включены у большинства клиентов - это часть стандартного шаблона пайплайна который мы поддерживаем. Sigstore-подпись пока раскатываем как opt-in: предлагаем тем, у кого есть внутренние требования по верификации цепочки поставки или КИИ-контекст.

Удивительно, что supply chain атаки сделали за несколько месяцев то, что лекции про best practices не делали годами. Spring4Shell, GitHub Actions, SolarWinds-послесловие - и вот клиенты сами спрашивают про подпись образов. Жаль, конечно, что повод такой.