Атаки на цепочку поставок: взлом Bitwarden CLI, Shai-Hulud и выводы

Зачем атаковать хорошо защищённую корпоративную сеть, если можно взломать npm-пакет с миллионами скачиваний в неделю и незаметно проникнуть в тысячи таких сетей?

22 апреля 2026 года именно это и произошло. Стилер учётных данных был встроен в пакет с 250 000 загрузок в месяц. Он запускался в момент установки без какого-либо взаимодействия с пользователем, и автоматически подтягивался CI-раннерами в десятках пайплайнов. К тому моменту, когда пакет удалили, хосты уже были скомпрометированы. По сути, плановое обновление зависимости.

Так и работает атака на цепочку поставок: злоумышленник компрометирует не саму целевую компанию, а её поставщика, подрядчика или программный компонент. Результат: доступ к тысячам жертв через одну точку входа.

Инцидент с Bitwarden CLI — очередное подтверждение, что эта угроза реальна, скоординирована и набирает темп. В этой статье мы разбираем, как именно была устроена атака, какой архитектурный урок она преподаёт и какие меры контроля действительно не пускают компрометации через цепочки поставок в вашу среду.

Главное

• Одна точка входа, неограниченный радиус поражения. Злоумышленник атакует не периметр организации, а доверенный компонент инфраструктуры с максимальным охватом. Вредоносный код распространяется через официальные каналы доставки.
• Доверие становится вектором атаки. Жертва устанавливает артефакт из авторитетного источника с валидной подписью. Для систем контроля доступа и мониторинга это неотличимо от легитимной операции.
• Компрометация происходит в доверенном контексте. Вредонос выполняется с полными правами разработчика или CI/CD-раннера. Традиционные средства защиты, настроенные на внешние аномалии, его не детектируют.
• Масштаб угрозы растёт экспоненциально. Один вредоносный релиз в популярном репозитории заражает тысячи организаций за минуты. В 2025 году 31% организаций столкнулись с атаками на цепочку поставок. В реестрах пакетов выявлено 454 600+ новых вредоносных артефактов — рост на 75% год к году.
• Защита требует архитектурного подхода, а не только процессных мер. Контроль зависимостей (SBOM, SCA), целостность артефактов, zero-trust для CI/CD, управление OAuth-интеграциями и централизованное управление секретами должны работать как единая система.

Что такое атака на цепочку поставок

Атака на цепочку поставок — это кибератака, при которой злоумышленник компрометирует не саму целевую организацию, а доверенный компонент её инфраструктуры: подрядчика, стороннюю библиотеку, инструмент разработчика или внешний сервис. Скомпрометированный компонент затем распространяет вредоносный код среди всех, кто ему доверяет.

Логика выбора цели проста: злоумышленник ищет не самую ценную организацию, а наиболее уязвимое звено с максимальным охватом. В сентябре 2025 года атака Shai-Hulud заразила популярные npm-пакеты — chalk, debug, ansi-styles и другие транзитивные зависимости, встроенные практически в каждый JavaScript-проект. Суммарная аудитория: 2,6 млрд загрузок в неделю (Хакер, 2025).

Главная асимметрия атак на цепочку поставок: одна точка входа, неограниченный радиус поражения.

Резонансные случаи

Приведённые ниже инциденты охватывают разные векторы: компрометацию сборочной среды, SQL-инъекции в широко используемое ПО, внедрение бэкдоров в open-source-проекты и атаки через доверенные плагины и расширения. Каждый случай — отдельный класс угроз.

Типичные векторы атак на цепочку поставок

Атаки на цепочку поставок не привязаны к одному сценарию. Злоумышленники бьют туда, где доверие уже установлено и где его меньше всего проверяют.

• Компрометация сборочной среды. Вредоносный код внедряется на этапе сборки или в CI/CD-конвейер: до того, как продукт подписан и доставлен пользователям. Заражение остаётся невидимым — финальный артефакт выглядит легитимно.
• Вредоносные обновления. Злоумышленник получает контроль над механизмом доставки обновлений и распространяет заражённую версию через официальный канал. Пользователи устанавливают обновление сами, доверяя привычному источнику.
• Инъекции в зависимости. Вредоносный код встраивается в открытые библиотеки или пакеты — через тайпсквоттинг, подмену зависимостей или прямую компрометацию репозитория. Заражение наследуют все проекты, использующие пакет.
• Социальная инженерия против мейнтейнеров. Атакующий месяцами выстраивает доверие внутри open-source-сообщества, получает права на проект и внедряет бэкдор через легитимный коммит. Именно так была скомпрометирована XZ Utils.
• Эксплуатация уязвимостей в стороннем ПО. Уязвимость в широко используемом инструменте — файловом менеджере, библиотеке, платформе — становится точкой входа сразу для всех его пользователей. Патч выходит после того, как атака уже состоялась.
• Компрометация сторонних сервисов и вендоров. Атакующий взламывает не саму организацию, а подрядчика или SaaS-провайдера с легитимным доступом к её данным или инфраструктуре.
• Подделка и кража сертификатов подписи кода. Вредоносный файл подписывается валидным сертификатом — украденным или выданным на скомпрометированный аккаунт. Защитные механизмы пропускают его как доверенный.

Почему это опаснее обычных векторов атак

Классические векторы (фишинг, брутфорс, эксплуатация уязвимостей) требуют преодоления защиты. Атаки на цепочку поставок работают через то, чему вы уже доверяете. Именно поэтому большинство средств защиты их не замечает.

Опасность атак на цепочки поставок кроется в нескольких ключевых факторах:

• Доверие. Жертва устанавливает официальный пакет из проверенного источника. Вредоносный код приходит с той же подписью, с того же реестра, через тот же процесс, что и легитимное обновление. Для системы безопасности это выглядит как штатная операция.
• Масштаб. Традиционная атака компрометирует одну цель. Взломанный пакет компрометирует всех, кто его использует, одновременно. Один вредоносный релиз в популярном репозитории способен заразить тысячи организаций за минуты.
• Скрытность. Вредоносный код выполняется в доверенном контексте. Стандартные средства защиты настроены на аномалии извне. Угрозу, пришедшую изнутри доверенного процесса, они пропускают.
• Автоматизация против вас. CI/CD-пайплайны созданы для скорости: они подтягивают зависимости и деплоят без остановок. Именно эта автоматизация превращает один взломанный пакет в угрозу для всей инфраструктуры.

Масштаб угрозы в 2025–2026 годах

По данным Лаборатории Касперского, атаки на цепочки поставок стали самой частой киберугрозой для бизнеса в 2025 году: с ними столкнулись 31% компаний по всему миру и 35% в России. Цифры Sonatype объясняют почему: за тот же год в реестрах npm, PyPI, Maven Central, NuGet и Hugging Face выявлено более 454 600 новых вредоносных пакетов. Совокупный объём заблокированного вредоносного ПО превысил 1,23 млн пакетов — рост на 75% год к году.

Главной мишенью атак остаётся npm. Именно здесь в 2025 году появился Shai-Hulud — первый самовоспроизводящийся червь для экосистемы пакетов, названный в честь гигантских песчаных червей из «Дюны». После компрометации учётной записи мейнтейнера червь автоматически заражал все пакеты под его управлением через postinstall-хук и распространялся дальше по той же схеме. За время кампании было скомпрометировано более 700 GitHub-репозиториев.

3 самых громких атаки на цепочку поставок в 2025–2026 годах

Период с марта по апрель 2026 года стал беспрецедентным по концентрации атак на цепочки поставок ПО. Аналитики Trend Micro зафиксировали, что злоумышленники одновременно и скоординированно атаковали сразу несколько уровней инфраструктуры: CI/CD-системы, реестры пакетов, OAuth-интеграции и платформы деплоя, каждый из которых раньше считался отдельным вектором риска.

Checkmarx и взлом Bitwarden CLI (апрель 2026)

22 апреля 2026 года в реестр npm была опубликована вредоносная версия Bitwarden CLI (@bitwarden/cli@2026.4.0). Пакет скачивают более 250 000 раз в месяц — это сделало его ценной мишенью. Bitwarden не взламывали напрямую: злоумышленники скомпрометировали сторонний GitHub Action в CI/CD-пайплайне компании, получили доступ к секретам воркфлоу, в том числе к npm-токену, и с его помощью опубликовали вредоносный пакет.

«Команда безопасности Bitwarden выявила и локализовала вредоносный пакет, который был распространён через канал доставки npm для @bitwarden/cli@2026.4.0 с 17:57 до 19:30 (по восточному времени) 22 апреля 2026 года и связан с более широким инцидентом в цепочке поставок Checkmarx», — официальное заявление Bitwarden

Пакет оставался доступен около 1,5 часов — за это время его скачали 334 раза. Строка «Shai-Hulud: The Third Coming» (Shai-Hulud: Третье пришествие), встроенная в код, подтвердила: это третья итерация организованной кампании, а не случайная атака (OX Security, 2026).

Механика вредоносного кода

Вредоносный код был встроен в bw1.js и запускался через хук preinstall в package.json: сначала выполнялся bw_setup.js, устанавливавший среду выполнения Bun, затем основная нагрузка. Никакого взаимодействия с пользователем не требовалось. Последовательность действий:

1. Проверка локали. Вредонос проверял, настроен ли на машине русский язык. Если да, то немедленно завершал работу. Стандартный приём самозащиты, косвенно указывающий на русскоязычного актора угрозы.
2. Кража учётных данных. Целенаправленно собирались токены GitHub и npm, содержимое директорий .ssh, файлы .env, история командной оболочки, переменные окружения GitHub Actions, учётные данные AWS, GCP и Azure, информация о GitHub Runner.
3. Атака на AI-инструменты. Конфигурационные файлы Claude, Kiro, Cursor, Codex CLI и Aider были явно включены в список целей. Это явно отражает, насколько глубоко подобные инструменты встроились в рабочие процессы разработчиков и сколько чувствительного контекста они хранят локально.
4. Зашифрованная эксфильтрация через GitHub. Все похищенные данные шифровались с помощью AES-256-GCM с асимметричным ключом — расшифровать их может только сам злоумышленник, располагающий приватным ключом. Данные загружались в новый публичный репозиторий GitHub, созданный на аккаунте жертвы, в файлы формата results-TIMESTAMP-ID.json. Резервный канал эксфильтрации вёл на audit.checkmarx[.]cx — домен, имитирующий легитимную платформу Checkmarx. Использование GitHub в роли C2-сервера — осознанный выбор: трафик на github.com крайне редко блокируется средствами защиты и не указывает на инфраструктуру злоумышленника.
5. Самораспространение. Именно это превращает Shai-Hulud из стилера в червя. При обнаружении валидных npm-токенов вредонос скачивал один из npm-пакетов жертвы, внедрял в него вредоносный код и публиковал новую версию, автоматически распространяя заражение на пользователей этого пакета.
6. Распространение по пайплайнам. При обнаружении GitHub-токенов вредонос внедрял вредоносные Actions-воркфлоу в доступные репозитории, извлекал CI/CD-секреты и распространял компрометацию на все пайплайны, доступные токену разработчика.

«После взломов Trivy и Checkmarx эта атака бьёт по ещё одному инструменту безопасности, глубоко встроенному в рабочие процессы разработчиков и CI-пайплайны — туда, где доступ к API-токенам, ключам и другим секретам является обычной практикой», — Endor Labs, 2026

@bitwarden/cli@2026.4.0 — один из наиболее технически сложных вредоносных пакетов в истории npm. Он совмещает сборщик учётных данных из шести типов секретных хранилищ, самовоспроизводящегося червя, перезаражающего все пакеты, доступные токену жертвы, C2-канал на базе GitHub-коммитов с RSA-подписью команд, зашифрованную эксфильтрацию, устойчивую к изъятию репозитория, персистентность через shell RC и модуль целенаправленной атаки на AI-ассистентов для разработки (Endor Labs, 2026).

Инцидент Checkmarx: 23 марта 2026 года

Эта кампания началась задолго до апреля. Согласно официальному сообщению Checkmarx, 23 марта 2026 года около 05:53 по московскому времени были опубликованы вредоносные версии двух плагинов OpenVSX — они оставались доступны до 18:41. Параллельно были скомпрометированы два GitHub Actions-воркфлоу: ast-github-action и kics-github-action. Организации, загрузившие эти артефакты в указанный промежуток времени и запустившие их, оказались под угрозой.

Инцидент с Bitwarden CLI воспроизвёл тот же вектор атаки через GitHub Actions, подтверждая, что речь идёт об активной, развивающейся кампании, а не об изолированном случае.

Архитектурный урок

Важная деталь: несмотря на компрометацию CLI-пакета, сами хранилища паролей Bitwarden не пострадали. Пароли шифруются на стороне клиента и хранятся на сервере исключительно в зашифрованном виде — злоумышленник получил токены и секреты из среды разработчика, но не доступ к зашифрованным хранилищам.

Это и есть архитектурный принцип, который индустрия раз за разом открывает заново: процессные средства защиты можно обойти, архитектурные ограничения — нет. Система, в которой компрометация одного компонента не даёт злоумышленнику ничего полезного, принципиально устойчивее той, где надёжность держится на одновременной работе всех средств контроля.

Пассворк построен на том же принципе. Учётные данные шифруются на стороне клиента до того, как покидают устройство — сервер хранит только шифротекст. Утечка базы данных, взлом сервера, действия недобросовестного администратора не дадут результата без клиентских ключей. Публикация Пассворк CLI в PyPI выполняется по полуручному процессу с доверенных машин: компрометация CI/CD не может спровоцировать автоматический выпуск вредоносного артефакта.

Протестируйте бесплатно и убедитесь, что архитектура Пассворка ограничивает радиус поражения при компрометации любого компонента инфраструктуры → passwork.ru

Компрометация пакетов Axios (март 2026)

31 марта 2026 года были выпущены две вредоносные версии Axios — одного из самых популярных HTTP-клиентов для JavaScript с более чем 100 миллионами скачиваний в неделю. Атаку раскрыла и атрибутировала команда Microsoft Threat Intelligence.

Механика атаки

Злоумышленники не трогали исходный код Axios. Вместо этого они внедрили вредоносный код через зависимость — фейковый пакет plain-crypto-js@4.2.1. При установке Axios этот пакет автоматически выполнял post-install-скрипт: подключался к C2-серверу hxxp://sfrclak[.]com:8000 и загружал троян удалённого доступа (RAT). Под удар попали Windows, macOS и Linux — каждая платформа получала свою версию вредоноса.

Схема была выстроена в несколько шагов. Сначала опубликовали «чистый» plain-crypto-js@4.2.0 — чтобы сформировать историю публикаций и снизить подозрения. Затем вышел 4.2.1 с вредоносным хуком. После этого были выпущены axios@1.14.1 и axios@0.30.4 с единственным изменением в package.json — добавлением зависимости от plain-crypto-js@^4.2.1. Исходный код Axios при этом остался нетронутым.

Атаку приписывают северокорейской группировке Sapphire Sleet, специализирующейся на краже криптовалюты и корпоративном шпионаже.

Почему это важно

Атака обнажает системную уязвимость: вы устанавливаете доверенный пакет, но вместе с ним получаете вредоносный код из его зависимости, о которой даже не подозреваете. Проверка только прямых зависимостей принципиально недостаточна: угроза приходит уровнем глубже.

Утечка OAuth-токенов через Vercel и Context.ai (февраль–апрель 2026)

Этот инцидент — наглядная иллюстрация того, как атака на цепочку поставок распространяется не через код, а через доверие между сервисами. Vercel — крупнейшая платформа для деплоя фронтенд-приложений, которой доверяют сотни тысяч команд разработчиков по всему миру. Его не взламывали напрямую. Его скомпрометировали через вендора, о котором клиенты Vercel никогда не слышали.

Цепочка компрометации

В феврале 2026 года сотрудник небольшого ИИ-стартапа Context.ai загрузил скрипты для Roblox, заражённые стилером Lumma Stealer. Вредонос похитил корпоративные учётные данные и OAuth-токены Google Workspace. Через эти токены атакующие в марте получили доступ к AWS-среде Context.ai и эксфильтровали OAuth-токены пользователей — в том числе токен сотрудника Vercel.

Дальше сработала цепочка доверия. Через скомпрометированный OAuth-токен атакующие вошли в Google Workspace аккаунт сотрудника Vercel, оттуда — во внутренние системы компании. Итог: доступ к переменным окружения клиентских проектов, не помеченным как «sensitive».

Что делает этот инцидент показательным

Три структурных урока, которые здесь видны особенно отчётливо.

• OAuth-токены — слепое пятно большинства команд безопасности. Они не требуют пароля, переживают его смену и редко проходят аудит после первоначальной авторизации. Один скомпрометированный вендор открывает доступ ко всем его интеграциям — автоматически, без дополнительных действий атакующего.
• Клиенты Vercel не могли предотвратить атаку на своём уровне. Они не имели никакого отношения к Context.ai. Их данные оказались под угрозой исключительно из-за решений третьей стороны.
• Скорость атаки нарастает. От заражения Lumma Stealer до эксфильтрации данных клиентов Vercel прошло около двух месяцев. Как отметил CEO Vercel Гильермо Рауш, необычная скорость продвижения атакующих объясняется использованием ИИ-инструментов для ускорения операций.

Связь между двумя инцидентами прямая: оба демонстрируют одну и ту же логику атаки — злоумышленник не ломает цель напрямую, а входит через доверенный компонент. В случае axios — через транзитивную зависимость. В случае Vercel — через OAuth-интеграцию вендора. Защита периметра в обоих сценариях не срабатывает: угроза уже внутри доверенного контекста.

Как защититься от атак на цепочку поставок

Защита требует контроля на каждом уровне: от выбора зависимостей до управления секретами в CI/CD.

Уровень 1: Контроль зависимостей

• Фиксируйте версии и проверяйте хеши. Плавающие диапазоны версий в продуктовых пайплайнах — это открытая дверь для автоматического подтягивания вредоносной версии. Фиксируйте точные версии и сверяйте контрольные суммы с эталонным состоянием. Это не защитит от компрометации аккаунта мейнтейнера, но исключит незаметное обновление на заражённый пакет.
• Формируйте и поддерживайте SBOM. Software Bill of Materials — полный реестр каждого компонента вашего ПО, включая транзитивные зависимости. Когда появляется информация об уязвимости или вредоносном пакете (как с Axios или Bitwarden CLI), вы мгновенно определяете, затронуты ли вы.
• Запускайте SCA непрерывно. Статические одноразовые сканирования недостаточны. Инструменты Software Composition Analysis должны работать на каждом пулл-реквесте и при каждом обновлении зависимостей, выявляя новые пакеты, нестандартные preinstall-хуки и неожиданные сетевые вызовы в скриптах пакетов.

Уровень 2: Целостность артефактов

Требуйте подписанных сборок и аттестации происхождения. Подписанный артефакт с верифицируемой цепочкой сборки несравнимо сложнее подменить незаметно. Это создаёт криптографический барьер между вашей инфраструктурой и скомпрометированным реестром.

Уровень 3: Защита CI/CD-инфраструктуры

Здесь находится главный приз для атакующих — секреты и токены. Именно через CI/CD прошли все три инцидента 2026 года.

• Применяйте модель нулевого доверия (zero trust) к CI/CD-воркфлоу. GitHub Actions должны работать с минимально необходимыми правами. Используйте эфемерные токены, ограниченные отдельными задачами, — не долгоживущие персональные токены доступа. Аудируйте файлы воркфлоу на предмет ссылок на сторонние Actions и фиксируйте их на конкретные коммит (SHA), а не на изменяемые теги (как это произошло с Checkmarx и Bitwarden CLI).
• Контролируйте аномальный исходящий трафик. Вредонос в Bitwarden CLI устанавливал соединение с audit.checkmarx[.]cx. Мониторинг исходящего трафика CI-раннеров на сетевом уровне зафиксировал бы это. Составьте белый список ожидаемых исходящих адресов для сборочных сред и настройте алерты на любые отклонения.
• Ротируйте секреты CI/CD регулярно и сразу после любого инцидента. Относитесь к секретам в CI/CD-средах как к краткосрочным учётным данным. Любой токен, API-ключ или SSH-ключ, который мог быть скомпрометирован, должен быть заменён немедленно. Выстроенный процесс управления секретами превращает эту операцию в штатную процедуру, а не в аварийную импровизацию.

Уровень 4: Защита периметра разработчика

• Включите конфигурации AI-инструментов в периметр защиты. Кампания 2026 года явно целилась в конфигурационные файлы Claude, Cursor, Aider и аналогичных инструментов. Эти файлы нередко содержат API-ключи и контекст о кодовой базе. Относитесь к ним как к чувствительным артефактам и включайте в область применения инструментов сканирования секретов.
• Аудируйте OAuth-приложения. Инцидент с Vercel показал: доверенные сторонние OAuth-приложения создают цепочки доверия, которые обходят традиционные средства защиты. Проведите аудит всех OAuth-приложений. Отзовите доступ у неиспользуемых приложений. Ограничьте области видимости (scopes) до минимально необходимых.

Централизованное управление секретами — основа всего

Все перечисленные выше меры требуют одного фундамента: единого хранилища для управления, ротации и разграничения доступа к секретам. Без этого ротация становится хаосом, аудит — невозможным, а ролевая модель доступа — фикцией.

Заключение

Атаки на цепочку поставок в 2026 году — это новая норма. Взлом Bitwarden CLI показал, что инструменты безопасности сами становятся вектором атаки. Axios продемонстрировал уязвимость транзитивных зависимостей — тех, о которых разработчики даже не подозревают. Vercel доказал, что один скомпрометированный OAuth-вендор открывает путь к тысячам клиентов.

Что объединяет все три инцидента? Не сложность атак. Не новые уязвимости. Секреты в незащищённых средах.

Переменные окружения CI/CD с npm-токенами и GitHub PAT. OAuth-токены без ротации. Конфиги AI-инструментов с API-ключами. Они лежат открыто — и именно они становятся главным призом для атакующих.

Защита периметра не срабатывает, потому что угроза уже внутри доверенного контекста. Процессные средства контроля не помогают, потому что вредонос выполняется с полными правами разработчика.

Нужна многоуровневая защита и архитектурное ограничение. Контроль зависимостей (SBOM, SCA), целостность артефактов (подписанные сборки), zero-trust для CI/CD-пайплайнов, аудит OAuth-приложений, централизованное управление секретами. И главное: система, где компрометация одного секрета не открывает доступ ко всему остальному.

Централизованное управление секретами — не опция, а требование. Пассворк обеспечивает хранение API-ключей, токенов и паролей в зашифрованном виде с детальной ролевой моделью доступа и журналом аудита. Протеструйте бесплатно и проверьте, как Пассворк решает задачу защиты корпоративных секретов в CI/CD-инфраструктуре.

FAQ: атаки на цепочку поставок

Чем атака на цепочку поставок отличается от обычной кибератаки?

При обычной атаке злоумышленник атакует целевую организацию напрямую — через фишинг, эксплуатацию уязвимостей или брутфорс. При атаке на цепочку поставок он компрометирует доверенный компонент — библиотеку, CI/CD-систему, OAuth-провайдера. Жертва устанавливает вредоносный код добровольно, считая его легитимным обновлением.

Что делать, если вы скачали скомпрометированный пакет?

Немедленно ротируйте все секреты, доступные в среде, где был установлен пакет: SSH-ключи, токены, API-ключи, переменные окружения CI/CD. Изолируйте затронутые системы, проведите форензику на предмет эксфильтрации данных и проверьте GitHub-репозитории вашей организации на наличие посторонних публичных форков.

Как защитить CI/CD от атак на цепочку поставок?

Используйте точные версии GitHub Actions по SHA-хешу, а не по тегу — это исключает подмену при обновлении. Используйте OIDC-токены вместо долгосрочных секретов. Ограничьте права Actions по принципу минимальных привилегий. Мониторьте аномальное поведение в пайплайнах: неожиданные сетевые соединения, создание новых файлов в нестандартных директориях.

Что такое транзитивная зависимость и почему она опасна?

Транзитивная зависимость — это пакет, который вы не устанавливаете напрямую, но он подтягивается как зависимость вашей зависимости. В атаке на Axios вредоносный код был спрятан в plain-crypto-js — пакете, о котором разработчики не знали. Проверка только прямых зависимостей не защищает от этого вектора: необходим полный SCA-аудит дерева зависимостей.

Почему OAuth-токены — опасный вектор атаки?

OAuth-токены не требуют пароля пользователя, переживают его смену и часто имеют широкие области видимости. После авторизации приложения токен редко проходит повторный аудит. Один скомпрометированный вендор с OAuth-доступом к вашей инфраструктуре открывает атакующему путь в ваши системы — без взлома вашего периметра напрямую.

Что такое Shai-Hulud и почему это важно?

Shai-Hulud — первый в истории самовоспроизводящийся npm-червь, зафиксированный Sonatype в 2025 году. В отличие от обычного вредоносного пакета, он способен автономно распространяться через экосистему зависимостей: заражённый пакет реплицирует себя в npm-проекты жертвы. Вариант этого червя был использован в атаке на @bitwarden/cli в апреле 2026 года.

Импортозамещение ИБ-решений (СЗИ): переход на российское ПО

Переход на российские решения в сфере защиты информации — юридическая обязанность. В статье: сроки, штрафы, пошаговый план миграции и таблицы отечественных аналогов по всем ключевым классам защитных решений.

Блог ПассворкаАнастасия Лебедева

Приказы ФСТЭК и ФСБ №117: в чём разница и как выполнить требования

ФСТЭК и ФСБ выпустили приказы с одинаковым номером 117. Оба обязательны для госорганов, ГУП и госучреждений — но регулируют разное. Рассмотрим, чем отличаются документы, где пересекаются и как выполнить требования обоих.

Блог ПассворкаИлья Шелыгин

11 способов взлома паролей, которые хакеры используют в 2026 году

Больше половины паролей можно подобрать меньше чем за час. Но брутфорс уже не главная угроза. Инфостилеры, AiTM-фишинг, PassGAN и обход MFA — разбираем 11 актуальных методов взлома паролей в 2026 году и даём конкретный чек-лист защиты.

Блог ПассворкаИлья Шелыгин