Безопасность
Supply-chain безопасность: тест с множественным выбором
Суть Синтез с множественным выбором по всему модулю supply chain — dependency confusion, typosquatting, целостность lockfile, provenance, подписание и радиус поражения CI.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, охватывающих весь модуль. Каждый отражает решение, которое вы принимаете в реальном инциденте — не определение для заучивания, а компромисс, который нужно взвесить, когда поверхностью атаки становится шаг установки.
Цель
Убедитесь, что умеете связывать задокументированные паттерны атак с защитой, которая реально останавливает каждую из них — целостность lockfile, приоритет реестра, provenance и подписание — и определять, какой слой защищает данный контроль.
Викторина
Completed
Команда фиксирует точные версии в package.json (без caret-диапазонов) и считает себя защищённой от supply-chain атак. Что эта фиксация на самом деле НЕ гарантирует?
Heads-up Точная фиксация лишь не даёт caret-диапазону автоматически прыгнуть на новый релиз. Она ничего не говорит о реальных байтах tarball, о provenance сборки или о компрометации реестра — всё равно нужны integrity-хэши и `npm ci`.
Heads-up Транзитивная фиксация — реальный пробел, но lockfile уже фиксирует всё транзитивное дерево по версиям и хэшам. Более глубокий пробел фиксации версии — целостность байтов, а не покрытие транзитивных.
Heads-up Свежесть патчей — отдельный вопрос. Здесь речь о целостности: даже точно зафиксированная версия может оказаться другим артефактом, чем вы аудитировали, если форсируется только версия, а не хэш.
Викторина
Completed
Сборка в крупной компании молча разрешила публичный пакет, названный как внутренний модуль, версии 9.9.9, и выполнила код атакующего. Никаких учётных данных не украдено. Что это позволило, и каков основной фикс?
Heads-up Токен не нужен. Атакующий опубликовал в ПУБЛИЧНЫЙ реестр под внутренним именем; порядок разрешения — предпочтение бóльшей версии между реестрами — сделал остальное.
Heads-up Typosquatting рассчитан на опечатку разработчика. Confusion опечатки не требует — настоящее внутреннее имя разрешается в публичного самозванца с более высокой версией.
Heads-up Принудительный lockfile здесь — защита, а не причина. Confusion бьёт по сборкам, которые разрешают заново по нескольким реестрам без строгого приоритета.
Викторина
Completed
У бэкдора xz-utils (CVE-2024-3094) исходник в Git был чистым, а выпущенный tarball — вредоносным. Какой контроль поймал бы это, и почему lockfile и audit — нет?
Heads-up Хэш фиксирует полученные байты, но эти байты И БЫЛИ бэкдоренным tarball. Хэширование подменённого артефакта лишь закрепляет подмену — оно никогда не сравнивает с чистым исходником.
Heads-up Это был zero-day-бэкдор без advisory, а xz — C-библиотека, поставляемая через дистрибутивы, не npm. Audit ловит лишь известные, раскрытые CVE постфактум.
Heads-up Все, кто устанавливал, получали одну и ту же зафиксированную бэкдоренную версию. Фиксация вредоносного артефакта лишь гарантирует, что вы продолжите получать вредоносный.
Викторина
Completed
Почему важно добавлять `--ignore-scripts` к установкам, и от чего конкретно это защищает?
Heads-up Это делает `npm ci`. `--ignore-scripts` ортогонален: он блокирует выполнение произвольного кода из lifecycle-хуков, а не дрейф lockfile.
Heads-up Проверка хэшей не зависит от скриптов. `--ignore-scripts` ни усиливает, ни ослабляет проверки целостности; он убирает вектор выполнения кода во время установки.
Heads-up Приоритет реестра и scoping управляют тем, откуда разрешаются пакеты. `--ignore-scripts` управляет лишь тем, может ли полученный пакет выполнять код при установке.
Викторина
Completed
CI-воркфлоу выдаёт job сборки широкий токен со scope на запись и запускается на pull_request из форков. В чём supply-chain риск и каков первый фикс?
Heads-up CI напрямую в supply chain: он собирает и подписывает артефакты, доходящие до продакшена. Утёкший там токен может опубликовать отравленные релизы, которым доверяют ниже по цепочке.
Heads-up Audit ловит известные advisory; он ничего не делает с переразрешённым токеном, который недоверенный код может украсть. Фикс — least-privilege scoping и изоляция секретов от запусков из форков.
Heads-up Ресурсы не связаны с радиусом поражения. Проблема в том, что недоверенный код выполняется с учётными данными, которых он не должен видеть — вопрос прав и изоляции триггеров.
Викторина
Completed
Выходит CVE в глубокой транзитивной зависимости. Руководство спрашивает «затронуты ли мы и где?». Какой артефакт отвечает за секунды, а не через лихорадочный grep по репозиториям?
Heads-up Lockfile перечисляет разрешённое дерево одного репозитория, но по многим сервисам и образам нет консолидированной, запрашиваемой описи. SBOM — стандартизированный, агрегируемый артефакт ровно для этого вопроса.
Heads-up Provenance удостоверяет, КАК артефакт собран и что он не подменён — а не ЧТО внутри. Вопрос состава — это задача SBOM.
Heads-up Подпись доказывает подлинность и целостность артефакта, а не список ингредиентов. Чтобы узнать, присутствует ли уязвимый компонент, читают SBOM.
Итог
Сквозная линия модуля — одна слоистая модель: шаг установки и есть поверхность атаки, и каждый контроль отвечает на свой вопрос. Lockfile + npm ci + integrity-хэши отвечают «получил ли я именно те байты, что ожидал»; точные пины и --ignore-scripts сужают окна авто-обновления и выполнения кода; scoped-имена с приоритетом реестра убивают dependency confusion; SBOM отвечает «что внутри»; а SLSA provenance плюс подписание отвечают «как это собрано и не подменено ли» — тот пробел, что использовал xz. Сам CI в цепочке, поэтому least-privilege токены важны не меньше, чем зависимости, которые они обрабатывают.