Безопасность
Supply-chain безопасность: укрепить пайплайн релиза от и до
Читать про supply-chain атаки — не то же, что остановить одну. Возьмите небольшой сервис, проведите его через каждый слой защиты — lockfile, приоритет реестра, SBOM, provenance, подписание — и докажите, что каждый контроль реально ловит подсаженную атаку, а не просто что вы его включили.
Превратите слоистую модель модуля в воспроизводимый цикл укрепления: укрепить шаг установки, убить dependency confusion, описать сборку через SBOM и поставить деплой под шлюз проверяемого provenance — доказав каждый контроль подсаженной атакой, которую он обязан заблокировать.
Возьмите небольшой сервис (свой или свежий create-next-app / NestJS) и укрепите весь его supply chain — шаг установки, приоритет реестра, SBOM и подписанный provenance — затем продемонстрируйте каждый контроль, подсадив атаку, которую он обязан заблокировать.
- Таблица контролей до/после: команда установки, фиксация версий, --ignore-scripts, проверка зависимостей, приоритет реестра, SBOM, provenance, подписание, scope токена — каждый помечен присутствует/отсутствует с diff конфига, что его включил.
- Свидетельство, что каждая подсаженная атака поймана: лог падения `npm ci` по несовпадению хэша, заблокированное разрешение confusion и отклонённый cosign verify — вставленный вывод, не описание.
- Сгенерированный SBOM, приложенный к артефакту, плюс отработанный запрос, показывающий, что вы можете ответить «присутствует ли компонент X версии Y?» по нему.
- Абзац-резюме, сопоставляющий каждый контроль задокументированному инциденту, от которого он защищает (lockfile/хэш → event-stream/ua-parser-js; приоритет → confusion Бирсана; provenance/подписание → xz-utils), и почему одних хэшей было недостаточно.
- Добавьте одностраничный runbook релиза: порядок запуска контролей в CI, что проверяет каждый шлюз, что значит падение на каждом шлюзе и чеклист проверки до того, как релиз разрешён к выпуску.
- Поднимите цель SLSA до L3: собирайте в изолированном, укреплённом раннере с нефальсифицируемым provenance и задокументируйте, что изменилось от вашей L2-настройки.
- Добавьте учение по транзитивному CVE: подпишите SBOM на фид уязвимостей, симулируйте CVE в глубокой зависимости и покажите, что можете перечислить каждую затронутую сборку/сервис по SBOM менее чем за минуту.
- Повторите шлюз подписания + verify на второй экосистеме (например container image и npm-пакет, или Python wheel) и сравните, как provenance и проверка различаются между реестрами.
Это цикл, который вы запустите на каждом реальном сервисе: сначала укрепить шаг установки (lockfile, npm ci, точные пины, —ignore-scripts), убить confusion scoped-именами и приоритетом реестра, описать сборку через SBOM и поставить деплой под шлюз подписанного, проверяемого provenance — с least-privilege токенами CI повсюду. Каждый контроль сопоставлен задокументированному инциденту, и единственное честное доказательство — подсаженная атака, которую контроль реально блокирует. Сделав это раз от и до на небольшом сервисе, вы доведёте продакшен-версию до автоматизма.