OSV отозвала 157 отчётов о вредоносных пакетах после того, как автоматические детекты ошибочно пометили доверенные npm- и PyPI-пакеты как malicious. Главное здесь не только сама ошибка, а путь распространения: неверные записи попали в публичную базу уязвимостей, а затем дошли до инструментов, которые используют данные OSV для сканирования, политик, SBOM, проверок реестров и CI/CD-гейтов.
Что произошло#
OSV, база уязвимостей при поддержке OpenSSF, 26 мая отозвала 157 отчётов о malicious-пакетах после ложных срабатываний в экосистемах npm и PyPI.
Откат прошёл в репозитории OpenSSF для malware-записей в формате OSV. По данным Socket, pull request начался как отзыв отчёта по FastAPI 0.136.3, а затем вырос в более широкую чистку npm и PyPI. В итоге 157 отчётов OSV получили статус withdrawn.
Список затронутых пакетов не сводился к малоизвестным проектам. Socket называет FastAPI и @tanstack/start-storage-context, а также более длинный хвост: MCP-серверы, AI-инструменты, CLI-пакеты, форки фреймворков, библиотеки компонентов и API-клиенты.
Это важно, потому что OSV — не просто сайт, где исследователи читают advisories. Её структурированные записи рассчитаны на автоматическое потребление. Сканеры безопасности, панели мониторинга, policy engines, SBOM-инструменты, проверки реестров и CI/CD-системы могут использовать данные OSV как входной сигнал. Если запись говорит «malware», нижестоящий инструмент может остановить сборку до того, как человек проверит, верна ли метка.
Кейс FastAPI показывает слабое место#
По данным Socket, запись по FastAPI была озаглавлена как malicious code в PyPI-пакете, а отчёт был атрибутирован Amazon Inspector. Претензия строилась вокруг добавленной недокументированной зависимости или optional dependency group, которая показалась системе детектирования подозрительной.
Сообщается, что запись описывала зависимость как «typosquat-shaped» и как возможный признак dependency confusion или злоупотребления namespace.
Это сигнал, который стоит проверить. Но сам по себе он не доказывает наличие malware.
Socket отмечает, что отозванная запись не указывала на malicious payload в FastAPI. В ней не было ссылки на выполнение кода при установке, кражу учётных данных, command-and-control-поведение, exfiltration или инфраструктуру атакующего. Судя по доступным фактам, переход от подозрительных метаданных зависимости к публичной записи о malicious code был ошибкой.
В этом главный урок. Автоматические системы хорошо находят аномалии. Но они хуже решают, когда аномалия заслуживает метки malware, которая затем разойдётся по enforcement-инструментам.
Amazon Inspector, похоже, был в центре, но атрибуция неоднородна#
Многие отозванные JSON-записи указывают на Amazon Inspector, автоматизированный сервис AWS для управления уязвимостями. Socket пишет, что OpenSSF добавила Amazon Inspector как автоматический источник для репозитория в октябре 2025 года, с аутентификацией в AWS role под контролем OpenSSF, которая могла забирать отчёты о malicious-пакетах из bucket Amazon Inspector.
Так появился путь от автоматических отчётов Amazon Inspector к malware-записям в формате OSV.
В обсуждении отката Chi Tran написал: “We have paused our automation and taking actions.” Фраза короткая, но говорит достаточно: автоматический путь приостановили после обнаружения ложных срабатываний.
При этом атрибуцию нельзя упрощать сверх того, что известно из источника. Socket пишет, что отозванная запись по FastAPI указывала Amazon Inspector как finder и source для версии 0.136.3. Но не все 157 записей были атрибутированы одинаково. Часть явно связана с Amazon Inspector. Другие сохраняют более ранние источники — например, старые подтверждённые компрометации или другие отчёты, — а затем включают новые спорные записи.
@tanstack/start-storage-context — один из таких смешанных случаев в материале Socket. У пакета был более ранний контекст компрометации, а спорная версия 1.167.4 попала в чистку ложных срабатываний 26 мая. Это важное различие: у пакета может быть реальная история компрометации, но при этом более поздняя версия может получить ложную метку.
Метка malware тяжелее, чем CVE#
Ложный advisory по уязвимости раздражает. Ложный malware-advisory может превратиться в инцидент.
Большинство алертов по уязвимостям можно разобрать по диапазонам версий, severity, reachability, exposure и контексту развёртывания. Команда может решить: исправлять, отложить, подавить алерт или задокументировать, почему он не относится к их случаю.
С malware всё иначе. Такая метка подразумевает активную компрометацию. Она может запустить удаление пакета, срочные ревью, обсуждения ротации учётных данных, incident-response-процессы и вопросы к мейнтейнерам ещё до проверки исходного утверждения.
Поэтому этот откат был не просто чисткой метаданных. Если CI-гейт или policy engine зависимостей считал запись OSV авторитетной, доверенный пакет мог быть заблокирован. Если dashboard показывал её security-команде, мейнтейнеров могли вынудить доказывать отрицание: что их релиз не был malicious, хотя публичная запись уже утверждала обратное.
Автоматизация не просто ошибочно классифицировала пакеты. Она переложила работу на мейнтейнеров и потребителей ниже по цепочке.
Что проверить security-командам#
Командам, которые используют данные OSV напрямую или через сканеры, стоит проверить, не были ли алерты от 26 мая связаны с отозванными отчётами.
Практические проверки:
- Просмотрите падения CI/CD и блокировки зависимостей около 26 мая, связанные с malware-записями по npm или PyPI.
- Сверьте все findings вида “malicious package” с текущим состоянием записи в OSV, а не с кэшированным выводом сканера.
- Проверьте, не трактуют ли внутренние policy engines malware-отчёты OSV как автоматические deny rules.
- Отделите реальную историю компрометации от спорных отчётов по конкретным версиям, особенно для пакетов со смешанной атрибуцией.
- Найдите suppressions или аварийные exceptions, созданные в окно ложных срабатываний, и удалите их, если они больше не нужны.
Цель не в том, чтобы перестать доверять OSV. OSV полезна, потому что она открытая, структурированная и легко интегрируется. Эти же свойства позволяют плохим записям распространяться быстро.
Чего не стоит утверждать#
Этот инцидент не показывает, что названные пакеты были скомпрометированы. По данным Socket, записи отозвали как false positives.
Он также не доказывает, что автоматическое обнаружение malware бесполезно. Подозрительные изменения зависимостей, имена в стиле typosquat и паттерны namespace confusion могут быть значимыми сигналами. Проблема в повышении статуса. Сигнал стал публичной malware-записью без проверки, достаточной для операционного веса такой метки.
Более здоровый стандарт прост: автоматические детекты могут быстро попадать в очередь на ревью, но публичные malware-записи, которые питают enforcement-системы, требуют более сильных доказательств, более ясной атрибуции и пути исправления, работающего так же быстро, как распространение.
Открытые security-данные теперь стали инфраструктурой. Их отказ — это уже не просто плохая страница advisory. Это заблокированная сборка, разбуженный responder и мейнтейнер, который объясняет, почему доверенный релиз никогда не был malware.