dependency management
7 статей с этим тегом
В Ethersphere bee-js 13.3.0 и Swarm Desktop 0.56.2 попала вредоносная программа (ноябрь 2026): затронутые версии и что делать пользователям
В версии 13.3.0 npm-пакета @ethersphere/bee-js от Ethersphere, разработчика децентрализованной сети хранения Swarm, находился вредоносный код. Бюллетень GitHub (GHSA-hh7j-5m3j-23pf), опубликованный 9 ноября 2026 года, называет затронутой только версию 13.3.0 и сообщает, что исправленной версии нет. В нём сказано, что любой компьютер, на котором пакет установлен или запущен, следует считать полностью скомпрометированным, а все секреты и ключи на нём немедленно сменить с другого компьютера. Удаление пакета может не устранить всё вредоносное ПО, которое появилось при установке. Для Swarm Desktop в примечаниях к выпуску Ethersphere сказано, что версия 0.56.3, выпущенная 9 ноября, заменяет скомпрометированную 0.56.2. По анализу компании по безопасности, bee-js 13.3.0 появился в npm около 00:09 UTC 9 ноября (09:09 по японскому времени) и был удалён примерно через 75 минут. Swarm Desktop 0.56.2 был доступен около 8,5 часа, а на Windows x64 и Apple Silicon доставлялся и автообновлением. О том, что bee-js 13.2.0 и более ранние версии, а также Swarm Desktop 0.56.1 не затронуты, сообщается. Тот же анализ говорит, что целью были файл конфигурации узла Bee (в нём пароль в открытом виде) и ключ кошелька, а учётные данные, которыми пользуется официальная автоматизация выпусков, использовались злоумышленником. Наш вывод: пересоберите любую машину или среду CI, где была установлена затронутая версия, перенесите кошелёк на новый ключ и переведите средства, смените учётные данные с другой машины.
В LiteLLM 1.107.0 оказался похититель учётных данных (октябрь 2026): затронутый релиз PyPI и образы Docker, что делать пользователям
21 октября 2026 года (UTC) BerriAI, компания-разработчик LiteLLM, сообщила, что её конвейер выпуска релизов был скомпрометирован и что был опубликован v1.107.0 с вредоносным ПО, которое похищает учётные данные и загружает инструменты удалённого выполнения кода. Затронуты litellm==1.107.0 на PyPI (с 11:39 до 13:23 UTC) и теги v1.107.0, latest, main-latest и main-stable на Docker Hub (с 11:46 до 14:20 UTC) и GHCR (с 11:46 UTC до снятия к 13:51 UTC, около двух часов). Официальный исходный тег v1.107.0 на GitHub не содержит вредоносных файлов; артефакты были собраны из похожего репозитория, контролируемого злоумышленником. Все более ранние версии вне этой компрометации, компания просит закрепить версию 1.106.2 или другую явную более раннюю версию. 24 октября (UTC) компания опубликовала 1.103.8, 1.104.6, 1.105.4 и 1.106.3; начиная с этих релизов образы Docker и Helm-чарты подписываются новым ключом cosign (прежний ключ их больше не проверяет). 23 октября компания опубликовала анализ первопричины и исправила своё первоначальное предположение о том, что токены были взяты из логов внутреннего развёртывания LiteLLM. Согласно анализу, файл конфигурации, ошибочно закоммиченный в публичный репозиторий 27 мая, содержал мастер-ключ внутренней платформы агентов; коммит перезаписали, но ключ не отозвали. 10 октября злоумышленник использовал этот ключ для вызова API платформы и получил токен GitHub CLI владельца организации GitHub, настроенный там. С его помощью злоумышленник вывел секреты CI и получил токены ещё двух мейнтейнеров, а 21 октября отключил защиту веток, изменил рабочий процесс выпуска и одобрил релиз. Вывод этого сайта: пересоберите любую среду, где 1.107.0 был установлен или запущен в течение окна, и замените все ключи, до которых она могла дотянуться, включая ключи провайдеров LLM, мастер-ключ прокси, пароль базы данных и облачные роли.
osv-scanner на практике — pnpm, игнорирование CVE, офлайн-режим и типичные ошибки
Только вопросы второго дня, с ответами по официальной документации. pnpm-lock.yaml поддерживается; исключения задаются в osv-scanner.toml в IgnoredVulns и могут иметь срок действия; офлайн-режим — это три флага с тремя разными задачами. Взгляд этого сайта: сканер сообщает об известных уязвимостях и ничего не говорит о том, что версия, которую вы сами зафиксировали, устарела, — для этого нужен отдельный механизм.
Безопасность Express (Node.js) — референс по продакшн-закалке
Express минималистичен — по умолчанию он почти ничего не защищает, поэтому защиту вы добавляете сами. Это рабочий референс: (1) чек-лист закалки по приоритету (P0–P2), (2) руководство по областям — заголовки безопасности (helmet) + отключение x-powered-by, CVE зависимостей npm, валидация ввода и инъекции (SQL/NoSQL операторная), аутентификация и авторизация по владельцу, ограничение частоты и лимиты размера, сессии/cookie/CSRF, SSRF, продакшн-обработка ошибок (без экспозиции stack), NODE_ENV, и (3) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность Next.js — практическая референс-инструкция по хардненингу продакшна
Значения по умолчанию у Next.js довольно безопасны, но инциденты случаются на границе сервер/клиент. Это рабочий референс: (1) приоритетный чек-лист хардненинга (P0–P2), (2) руководство по областям — граница и переменные окружения (NEXT_PUBLIC_), CVE зависимостей (включая RCE в ядре), авторизация Server Actions / Route Handlers + валидация ввода, SSRF на серверных запросах, заголовки безопасности/CSP, аутентификация/сессия/куки, ограничение частоты, и (3) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность Ruby on Rails — справочник по продакшн-хардингу
Rails поставляется с соглашениями и безопасными значениями по умолчанию (защита от CSRF, Strong Parameters, ORM), но продакшн-инциденты приходят из эксплуатации. Это рабочий справочник: (1) приоритетный чек-лист хардинга (P0–P2), (2) руководство по областям — секреты и credentials (master key/secret_key_base), продакшн-конфигурация (force_ssl, без раскрытия исключений), CVE gem'ов, Strong Parameters/Mass Assignment, авторизация (Pundit, область владельца), инъекции и опасные методы (интерполяция в where/send/constantize), сессии/cookie/CSRF, SSRF/загрузки, и (3) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность Spring Boot — референс по продакшн-закалке
Spring Boot — стабильный фреймворк, но инциденты приходят из зависимостей, конфигурации и авторизации. Это рабочий референс: (1) чек-лист закалки по приоритету (P0–P2), (2) руководство по областям — CVE зависимостей (класса Log4Shell, судите по работающей версии), продакшн-конфиг и вынесенные наружу секреты, авторизация Spring Security (default-deny/method security/проверки владельца), сокращение экспозиции Actuator/управления, небезопасная десериализация, инъекции, заголовки/CSRF/сессия, SSRF, и (3) чек-лист самопроверки. Только защита — без шагов атаки.