Supply-chain безопасность: тест с множественным выбором
Синтез с множественным выбором по всему модулю supply chain — dependency confusion, typosquatting, целостность lockfile, provenance, подписание и радиус поражения CI.
Шесть вопросов, охватывающих весь модуль. Каждый отражает решение, которое вы принимаете в реальном инциденте — не определение для заучивания, а компромисс, который нужно взвесить, когда поверхностью атаки становится шаг установки.
Убедитесь, что умеете связывать задокументированные паттерны атак с защитой, которая реально останавливает каждую из них — целостность lockfile, приоритет реестра, provenance и подписание — и определять, какой слой защищает данный контроль.
Команда фиксирует точные версии в package.json (без caret-диапазонов) и считает себя защищённой от supply-chain атак. Что эта фиксация на самом деле НЕ гарантирует?
Сборка в крупной компании молча разрешила публичный пакет, названный как внутренний модуль, версии 9.9.9, и выполнила код атакующего. Никаких учётных данных не украдено. Что это позволило, и каков основной фикс?
У бэкдора xz-utils (CVE-2024-3094) исходник в Git был чистым, а выпущенный tarball — вредоносным. Какой контроль поймал бы это, и почему lockfile и audit — нет?
Почему важно добавлять `--ignore-scripts` к установкам, и от чего конкретно это защищает?
CI-воркфлоу выдаёт job сборки широкий токен со scope на запись и запускается на pull_request из форков. В чём supply-chain риск и каков первый фикс?
Выходит CVE в глубокой транзитивной зависимости. Руководство спрашивает «затронуты ли мы и где?». Какой артефакт отвечает за секунды, а не через лихорадочный grep по репозиториям?
Сквозная линия модуля — одна слоистая модель: шаг установки и есть поверхность атаки, и каждый контроль отвечает на свой вопрос. Lockfile + npm ci + integrity-хэши отвечают «получил ли я именно те байты, что ожидал»; точные пины и --ignore-scripts сужают окна авто-обновления и выполнения кода; scoped-имена с приоритетом реестра убивают dependency confusion; SBOM отвечает «что внутри»; а SLSA provenance плюс подписание отвечают «как это собрано и не подменено ли» — тот пробел, что использовал xz. Сам CI в цепочке, поэтому least-privilege токены важны не меньше, чем зависимости, которые они обрабатывают. Теперь, когда встретишь предложенный контроль на реальном ревью, первым делом спроси: какой паттерн атаки это реально останавливает — и какой задокументированный инцидент всё равно прошёл бы мимо?
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.