Гигиена зависимостей и секретов: закаляем сам CI

Пиннинг: тег — это обещание, SHA — факт

Lock-файл твоего приложения (package-lock.json, pnpm-lock.yaml, poetry.lock) пинит точное байтовое содержимое каждой зависимости по integrity-хэшу (хэш содержимого пакета, гарантирующий неизменность), поэтому npm ci ставит одно и то же дерево на каждой машине. Эта дисциплина всем понятна. Слепое пятно — другие зависимости, которые тянет твой пайплайн: сами GitHub Actions. Запись uses: actions/checkout@v4 выглядит как пин версии, но v4 — это изменяемый git-тег, метка, которую мейнтейнер (или любой, кто его скомпрометировал) может силой переставить на другой коммит в любой момент, без единого изменения в твоём репозитории. Ты пинишь не код; ты пинишь обещание и дальше указывать тегом на хороший код.

Полный SHA коммита — противоположность: это контент-адрес точного дерева, и объектная модель git означает, что переставить его без поломки хэша нельзя. uses: actions/checkout@<40-символьный-sha> гоняет одни и те же байты всегда. Это единственный контроль, который нейтрализовал бы радиус поражения tj-actions — вредоносный код жил за тегами, поэтому каждый потребитель, запинённый по SHA, продолжал гонять старый безопасный коммит. Пинь сторонние actions, и самые рискованные из своих, по полному SHA, с хвостовым комментарием, фиксирующим человекочитаемую версию:

# ПЛОХО — изменяемый тег, дефолтный (часто широкий) токен, секреты доступны всему
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4          # @v4 можно переставить на вредоносный код
      - uses: tj-actions/changed-files@v35 # именно тот action, чьи теги переставили
      - run: ./deploy.sh                   # AWS_KEY в env, доступен каждому шагу выше

# ХОРОШО — запинено по полному SHA, least-privilege токен, OIDC только где нужно
on: push
permissions:
  contents: read                           # по умолчанию всё в read-only
jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write                      # выдай OIDC ТОЛЬКО в job, которому он нужен
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1
      - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502  # v4.0.2
        with:
          role-to-assume: arn:aws:iam::111122223333:role/ci-deploy       # короткоживущий, без хранимого ключа
          aws-region: eu-central-1
      - run: ./deploy.sh

Автоматизируй апдейты, иначе пиннинг гниёт в устаревшие CVE

Пиннинг по SHA покупает безопасность ценой рутины: замороженный дайджест никогда не подхватит апстримный багфикс или патч под следующую CVE. Оставленный вручную, «пинь всё» вырождается в «гоняй уязвимые версии вечно». Решение — дать боту делать бампы. Dependabot и Renovate оба открывают pull request’ы, обновляющие запинённые зависимости — включая SHA actions — и при хорошей настройке обновляют SHA и человекочитаемый комментарий версии вместе. Группируй связанные апдейты, чтобы ревьюить один PR вместо сорока; ставь их по расписанию раз в неделю, чтобы они не перебивали продуктовую работу; и резервируй авто-мёрдж только для по-настоящему низкорисковых классов — patch-бамп с зелёным CI и неизменившимся мейнтейнером. У Renovate авто-мёрдж встроен (automerge: true в package-правиле); Dependabot’у нужен небольшой Actions-workflow с dependabot/fetch-metadata, чтобы гейтить gh pr merge --auto по типу апдейта. Принцип один: машина бампит дайджест, CI доказывает, что всё ещё собирается, человек апрувит всё нетривиальное.

Сканирование секретов и push protection: останови утечку на пороге

Пиннинг защищает тебя от чужого скомпрометированного кода; следующий слой защищает пайплайн от ошибок твоей собственной команды. Самая частая утечка прозаична: кто-то хардкодит API-ключ, коммитит его, и он живёт в истории git вечно (и в каждом форке и клоне). Secret scanning сопоставляет запушенное содержимое с большой библиотекой известных форматов кредов — облачные ключи, токены, строки подключения — и алертит на любое обнаруженное. Push protection — проактивная половина: она инспектирует содержимое во время push’а и блокирует коммит ещё до того, как он достигнет remote, когда он совпадает с высокоуверенным паттерном, поэтому секрет вообще не попадает в историю. Автор либо удаляет его, либо, изредка, записывает явное обоснование для обхода. Относиться к заблокированному push’у как к нормальному исходу — а не препятствию, которое надо обойти, — это и есть культурный сдвиг, который держит креды вне репозитория.

Least privilege и короткоживущие креды: ужми радиус поражения

Даже идеально запинённый пайплайн без утечек должен исходить из того, что какая-то зависимость рано или поздно станет вредоносной. Least privilege — это то, что ограничивает ущерб, когда это случится. Важнее всего два рычага. Первый — токен workflow: GITHUB_TOKEN у GitHub по умолчанию read-only с февраля 2023, но многие репозитории всё ещё гоняют с широкими write-скоупами. Объяви permissions: явно в начале workflow, поставь всё по умолчанию в read и выдавай write-скоупы только конкретному job, которому они нужны — так вредоносная зависимость, бегущая в твоём test-job, не сможет запушить в main или опубликовать пакет, потому что у токена в этом job просто нет скоупа. Второй — облачные креды: долгоживущий AWS_SECRET_ACCESS_KEY, лежащий в секретах репозитория, — постоянный приз: утёк один раз (в лог, в скомпрометированный action) — и он работает, пока кто-то не заметит и не ротирует. OIDC (OpenID Connect — протокол федеративной идентичности; вместо долгоживущего ключа раннер получает короткоживущий токен от доверенного провайдера) заменяет его короткоживущим, привязанным к audience токеном, выпускаемым на каждый запуск: workflow запрашивает OIDC-токен (id-token: write), обменивает его у облачного провайдера и получает креды, истекающие за минуты и нигде не хранимые. Красть нечего долговечного.

Четыре контроля защищают в четырёх разных точках отказа. Вместе они означают: даже когда один ломается — зависимость проскальзывает мимо скана, скоуп токена шире нужного — остальные всё равно ограничивают радиус поражения. Без любого одного из них одна брешь разматывает всю цепь.