Open Source
Безопасность: supply chain атаки
В 2024 один человек почти встроил backdoor в xz-utils - утилиту, которая есть на каждом Linux-сервере. Он 2 года притворялся хорошим контрибьютором. Как OSS защищается от таких атак?
- xz-utils backdoor 2024: обнаружен случайно из-за 500мс аномалии в SSH — мог затронуть миллионы серверов
- event-stream 2018: 2М+ загрузок/неделю, владелец передал пакет незнакомцу — тот добавил crypto-кражу
- SolarWinds 2020: не OSS, но supply chain — backdoor в обновлении ПО затронул 18,000 организаций включая US Treasury
- npm 2FA обязателен для top-500 пакетов с 2022 года — прямой ответ на компрометации аккаунтов
Supply chain атаки: как это работает
**Supply chain атака** - компрометация не вашего кода напрямую, а зависимостей, которые вы используете. Вместо взлома банка - взламывают SDK, который банк использует. Масштаб атаки: один скомпрометированный пакет → миллионы пострадавших проектов.
**Почему OSS особенно уязвим:** 1) Maintainers перегружены и выгорают - рады передать ownership. 2) Доверие к историческим контрибьюторам. 3) Пакеты ставятся автоматически через CI. 4) `npm install` = выполнение произвольного кода (lifecycle scripts: postinstall).
В чём был главный вектор атаки xz-utils 2024?
Защита пакета: provenance, 2FA, lockfiles
С 2023 года npm поддерживает **provenance** - криптографическое доказательство того, что пакет был собран именно из этого репозитория в этом CI run. Верифицируется через sigstore/OIDC, не требует ключей.
**Dependabot автоматически создаёт PR** при появлении новой версии зависимости или security advisory. Настройка: `.github/dependabot.yml`. Для OSS-проектов это стандарт - вы не следите за зависимостями вручную.
Почему `npm ci` безопаснее `npm install` в CI-пайплайне?
Security advisories, CVE и responsible disclosure
Когда находят уязвимость в OSS, стандартный процесс - **responsible disclosure**: приватно сообщить maintainer → дать время на исправление (обычно 90 дней) → публично раскрыть. Публичное раскрытие без предупреждения (full disclosure) опасно: даёт атакующим время до патча.
**Как maintainer:** никогда не исправляйте security баги в публичных коммитах до релиза. Опытные атакующие мониторят commit history популярных пакетов и используют window между патчем и релизом.
Вы нашли RCE уязвимость в популярном npm-пакете. Что делать первым шагом?
Ключевые идеи
- Supply chain атаки атакуют зависимости, не ваш код — один скомпрометированный пакет = миллионы жертв
- npm provenance — криптографически доказывает источник пакета через sigstore, без дополнительных ключей
- npm ci + lockfile = воспроизводимые билды без возможности dependency confusion
- 2FA на npmjs.com обязателен для любого публичного пакета
- Responsible disclosure: приватный репорт → 90 дней на патч → координированное раскрытие
Связанные темы
Безопасность влияет на финансирование - компании платят за безопасные цепочки зависимостей.
- Следующий урок: Финансирование OSS — Tidelift платит maintainers за security SLA
Вопросы для размышления
- Ваш пакет используется в 10,000 проектах. К вам обратился незнакомый разработчик и предложил помочь с мейнтенансом. Как проверить его? Какие права давать сначала?
- В популярном пакете обнаружен malicious postinstall скрипт. Как быстро оценить масштаб — сколько проектов уже скачали заражённую версию?