Post-Compromise Secret Exposure Scope Estimator
Оценить, какие секреты из .env были в зоне риска при компрометации конкретного npm-пакета.
Как это работает
Узнав, что один из установленных пакетов был скомпрометирован в одном из инцидентов 2026 года, первый практический вопрос — не "что теперь делать вообще", а конкретно: какие именно секреты были доступны процессу во время установки или импорта этого пакета, и какие из них теперь стоит считать скомпрометированными. Post-Compromise Secret Exposure Scope Estimator online помогает построить этот список по вашим .env файлам и типу инцидента.
Вредоносный код, выполняющийся при установке или импорте пакета, технически имеет доступ ко всем переменным окружения процесса Node.js в этот момент — а значит, потенциально скомпрометированным стоит считать не только секреты, напрямую связанные с этим пакетом, а весь набор переменных окружения, доступных в тот момент выполнения сборки или приложения.
Инструмент принимает список .env файлов, участвовавших в затронутой сборке или запуске, и тип атаки (install-time или import-time, что определяет разницу в моменте exposure), и выдаёт полный список переменных, которые стоит считать в зоне риска и запланировать к ротации.
Частые вопросы
Почему секреты, не связанные напрямую со скомпрометированным пакетом, тоже считаются в зоне риска?
Вредоносный код, выполняющийся внутри процесса Node.js, технически имеет доступ ко всем переменным окружения этого процесса, а не только к тем, которые логически относятся к самому пакету — изоляции по умолчанию между разными частями одного процесса не существует.
В чём разница между install-time и import-time для оценки зоны риска?
Install-time payload выполняется во время npm install, обычно до старта самого приложения, и видит переменные окружения сборочного окружения (CI, локальная машина разработчика), а import-time payload срабатывает при реальном использовании пакета в коде, то есть видит переменные окружения уже работающего приложения, включая продакшн.
Достаточно ли просто обновить пакет до безопасной версии, не ротируя секреты?
Нет, обновление версии останавливает дальнейшую угрозу, но не отменяет тот факт, что секреты уже могли быть переданы командному серверу атакующего в момент exposure, ротация остаётся обязательным шагом вне зависимости от того, обновлён пакет или нет.
Как понять, какие .env файлы участвовали в затронутой сборке?
Стоит проверить, какие окружения (dev, CI, staging, production) использовали уязвимую версию пакета за период между её публикацией и обнаружением, и включить .env файлы именно этих окружений в оценку зоны риска.