Устранение бинарного «слепого пятна»: внедрение доменных знаний для триажа вредоносного ПО в пакетах npm с помощью LLM

Источник: Databricks•

Устранение бинарного «слепого пятна»: внедрение доменных знаний для триажа вредоносного ПО в пакетах npm с помощью LLM

Введение. Атаки на цепочки поставок в реестрах пакетов растут по своему объему и уровню изощренности [1]...

Введение

Атаки на цепочки поставок в реестрах пакетов растут по своему объему и уровню изощренности [1]. В ходе регулярных независимых исследований фиксируется развертывание вредоносного ПО в реестре npm самыми разными злоумышленниками: от спам-кампаний [2] до непрерывного распространения вредоносного ПО из КНДР [3, 4, 5], а также громких атак группы TeamPCP в 2025 и 2026 годах [6, 7]. При этом акторы из КНДР и TeamPCP имеют подтвержденный опыт успешного взлома широко используемых проектов с открытым исходным кодом для максимального охвата нижестоящих потребителей [8].

Чтобы детально изучить эту проблему, мы собираем образцы вредоносного ПО для npm с ноября 2025 года и заметили следующее. Среди 11 413 версий пакетов, которые мы просканировали и подтвердили с помощью бюллетеней безопасности OSV npm malware [9], большинство вредоносных программ в реестре npm скрывают свой полезный нагрузочный модуль в исходном коде пакета или загружают его с внешнего сервера (на их долю приходится 96,2% проверенного набора данных). Оставшиеся 3,8% (432 версии пакетов) содержат завязанный в бандл бинарный файл. Несмотря на малый объем, такие файлы могут нести непропорционально высокие риски при триаже. Зачищенный, непрозрачный бинарный файл, в котором инструменты анализа не могут прочитать исходный код, может быть спрятан за фасадом чистого исходного кода и метаданных, что потенциально способно склонить LLM к вынесению вердикта о безопасности пакета.

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

Предпосылки

Для поддержки широкого исследовательского сообщества мы создали сканер, который отслеживает реестр npm в реальном времени и выполняет статический этап перед триажем с помощью LLM. Он использует YARA [10] для анализа тарбола, Semgrep [11] и API реестра npm для JavaScript и метаданных, а также модуль бинарного анализа для скомпилированного артефакта. Сканер собирает результаты в структурированный промпт, и LLM выдает вердикт с обоснованием, запрашивая дополнительные файлы в течение максимум трех раундов.

Наш анализ показал, что пакеты со встроенными бинарными файлами являются одновременно наиболее редкими и самыми сложными для триажа конвейером. Злоумышленник, распространяющий вредоносный JavaScript, может рассчитывать на то, что у цели уже есть среда выполнения для запуска полезной нагрузки, в то время как бинарный файл должен быть скомпилирован под различные целевые машины. Среди подтвержденных OSV вредоносных пакетов npm пакеты с бинарными файлами не могут получить однозначно вредоносный вердикт более чем в два раза чаще, чем пакеты, состоящие только из исходного кода (14,4% против 6,2%).

В рамках предыдущих работ проводилось обучение открытых моделей с учителем (instruction-tuning) на данных, созданных экспертами, что позволяет заложить эти знания прямо в веса моделей [12]. Такой подход неприменим к закрытым облачным моделям и требует повторного обучения по мере изменения ландшафта угроз. Мы применяем противоположный подход: предоставляем экспертные знания на этапе инференса в виде предварительно вычисленных статических данных, которые помещаются в промпт до того, как модель начнет рассуждать.

Методология эксперимента

Цель

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

Вредоносные полезные нагрузки

Мы создали пять типов полезных нагрузок (Таблица 1), представляющих собой нативные модули Node.js (файлы .node) и охватывающих типичные паттерны атак на цепочки поставок. Используемые импорты варьируются от вполне защитимых (fopen, connect, gethostname) до редко легитимных (execve совместно с dup2). Каждый пакет упаковывает бинарный файл в профессионально оформленные package.json, README, JavaScript-обвязку и binding.gyp.

Стиллер sysmon демонстрирует лестницу обфускации: от читаемой базовой версии до усложненной сборки со удаленными символами и XOR-закодированными строками, в то время как остальные четыре типа представлены на единственном уровне обфускации. Мы намеренно выбрали однобайтовый XOR, поскольку, в отличие от более надежных шифров вроде RC4, он не оставляет в дизассемблированном коде структурных маркеров, которые модель могла бы обнаружить.

Этот набор отражает реальное собранное вредоносное ПО. Среди подтвержденных OSV npm-пакетов, содержащих бинарные файлы, используются форматы PE, ELF (все со удаленными символами) и Mach-O. Их поведение охватывает кражу учетных данных и данных об окружении, закрепление в системе, эксфильтрацию данных и связь с C2, разведку хоста, а также программы-установщики (дропперы).

Таблица 1. Типы вредоносных полезных нагрузок и их профили импорта.

Протестированные модели

Мы оценили девять моделей от семи провайдеров (Таблица 2): семь бюджетных моделей, которые команда может реально использовать для анализа своей кодовой базы (четыре из них имеют открытые веса), и два более мощных варианта в качестве базовых ориентиров поведения при более высокой стоимости. Мы также запустили Claude Opus 4.6 — самую дорогою модель — исключительно в качестве ценового ориентира.

Таблица 2. Оцененные модели и их роли.

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

Архитектура профилей возможностей

Профиль возможностей — это декларативный сценарий, который кодирует одну вредоносную технику (например, сбор учетных данных или закрепление в системе) в виде набора взвешенных условий, основанных на статических данных сканера. Профили охватывают как исходный код, так и бинарные техники для экосистем npm и PyPI.

На рисунке 1 показано, как профиль задействуется при сканировании:

  • Статический этап извлекает данные из пакета.
  • Каждый профиль оценивает эти данные по своим пороговым значениям (подозрительно, вредоносно и критично) по шкале, независимой от собственного вердикта модели.
  • При достижении порога движок внедряет структурированную сводку (~1800 токенов) в промпт перед тем, как модель начнет рассуждать, вместе с любыми результатами этапа анализа статичных данных и метаданных.
  • Модель формирует собственный вердикт на основе совокупности всех данных и в данном эксперименте может полностью переопределить сработавший профиль.

Рисунок 1. Конвейер сканирования с профилями возможностей.

Результаты

Каждая модель была протестирована на всех десяти полезных нагрузках. Успешным обнаружением мы считаем статус HIGHLY_SUSPICIOUS (ВЫСОКОПОДОЗРИТЕЛЬНО) или MALICIOUS (ВРЕДОНОСНО); статусы SUSPICIOUS (ПОДОЗРИТЕЛЬНО) или BENIGN (БЕЗОПАСНО) для заведомо вредоносной полезной нагрузки считаются сбоем. Анализ сбоев сосредоточен на категории из семи бюджетных моделей (70 модельно-полезных тестов); два базовых ориентира (20 тестов) служат исключительно эталонным потолком и рассматриваются отдельно.

Без профилей возможностей

Без профилей бюджетные модели потерпели неудачу в 35 тесты из 70 (50%), причем в 20 случаях вынесли вердикт о полной безопасности, а в 51 случае (73%) не дотянули до порога вредоносности. Два базовых ориентира поведения не дали сбоев ни разу на пороге эскалации и лишь однажды не дотянули до вредоносного уровня (Sonnet, sysmon v3). Внутри бюджетного тира сбои следовали четким, повторяющимся паттернам, специфичным для конкретных моделей (Таблица 3), а не случайным ошибкам; только Gemini не уступила базовым моделям в обнаружении, хотя и за счет галлюцинаций в рассуждениях, а не подлинного анализа. Полная матрица вердиктов и уверенности приведена в приложении (Таблица A1).

С профилями возможностей

При включенных профилях 32 из 35 пропусков обнаружения без профилей (91%) восстанавливаются до обнаружения, и ни одна модель не выдает вердикт о безопасности ни для одной полезной нагрузки. Каждая модель, которая дала сбой без профилей, достигла полного обнаружения с ними, за исключением GPT-5.4-nano, три оставшихся сбоя которой остаются в статусе «подозрительно» на трех полезных нагрузках. В бюджетном сегменте сбои на пороговом уровне эскалации снизились с 50% до 4% (3 из 70), а на уровне вредоносности — с 73% до 34%.

Таблица 3. Уровень обнаружения для каждой модели (вердикт «крайне подозрительно» или выше на известной вредоносной полезной нагрузке) без профилей возможностей и с ними.

Наиболее наглядным отдельным примером является Qwen3-Next на обфусцированном нативном стиллере sysmon: безопасный на 0,98 с рекомендацией добавить в белый список без профилей, вредоносный на 0,98 с рекомендацией заблокировать с ними, на идентичных побайтово входных данных, после срабатывания четырех профилей. Базовые модели, Sonnet и Kimi, уже были корректны без профилей, и свидетельства подкрепляют их вердикты, поэтому профили подкрепляют, а не искажают модель, которая уже рассуждает корректно.

Срабатывания профилей

Специфичные для техник профили срабатывали в соответствии с паттерном атаки каждой полезной нагрузки.

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

Обсуждение

Аналіз режимов сбоев

Эксперимент выявил четыре режима сбоев, каждый из которых охватывает большую часть группы, а не какую-то отдельную модель (Таблица 5). Они не являются взаимоисключающими, так как один и тот же вердикт о безопасности может быть одновременно и отклонением, и рационализацией, поэтому в таблице указана распространенность для каждого режима, а сумма в строке модели может превышать десять. Мы определяем отклонение и уклонение по уровню вердикта, а рационализацию и галлюцинации — по письменному обоснованию.

Два фактора объясняют их. Первый — это доменные знания, которых не хватает бюджетным LLM для интерпретации бинарных структурных данных в контексте пакета [13]. Второй — это исходные возможности. Чтение удаленного, обфусцированного по строкам бинарного файла требует дизассемблирования и декодирования, которые бюджетный уровень не предпринял.

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

Ансамбль, принимающий вердикт большинства, не решил бы эту проблему. На обфусцированном нативном стиллере sysmon (версия 2) девять вердиктов разделились: три безопасных (Gemma, Qwen, Llama), два подозрительных (Haiku, GPT-5.4-nano), один крайне подозрительный (GLM), три вредоносных (Gemini, Kimi, Sonnet): большинство находится ниже порога обнаружения, поэтому голосование дает неверный ответ. Режимы не взаимоуничтожаются; они усугубляются, поэтому ни одна схема голосования не дает надежного покрытия без предварительного устранения пробела в доменных знаниях. Это соответствует известным ограничениям мажоритарного голосования в ансамблях LLM, где скоррелированные ошибки сходятся к неверному ответу, а не взаимно уничтожаются [14, 15].

Рационализация (~37% сканирований, шесть моделей) задействует контекстные подсказки, установочный скрипт, упаковку нативного модуля или описание пакета для построения безопасной интерпретации, которая перевешивает бинарные сигналы. Haiku назвала необфусцированный sysmon v1 ВРЕДОНОСНЫМ с оценкой 0,98, но как только строки были закодированы XOR, ее вердикт упал до ПОДОЗРИТЕЛЬНОГО, рассматривая node-gyp-build как стандартный, а расширение .node — как легитимный аддон, что соответствует документированной постфактум-рационализации [16]. Таким образом, обфускация инвертирует ожидаемое отношение. Чем тщательнее замаскирована полезная нагрузка, тем ниже присвоенная степень опасности, и поскольку обоснование остается внутренне согласованным, оценка на необфусцированных образцах никогда не вызовет его.

Отклонение (22%, четыре модели) выдает вердикт о безопасности без какого-либо анализа бинарного файла. Qwen3-Next выдала вердикт БЕЗОПАСНО для девяти из десяти полезных нагрузок и рекомендовала добавить каждую в белый список, включая обратный шелл netpulse и инструмент персистенции taskd, с заявленным намерением, которое полностью игнорировало импорты бинарного файла. Вердикт нечувствителен к двусмысленности импорта, а единообразная высокая уверенность скрывает сбой от любого последующего порогового значения.

Уклонение (16%, четыре модели) фиксирует подозрения, но никогда не переходит к решительному вердикту. GPT-5.4-nano вернула статус ПОДОЗРИТЕЛЬНО с оценкой 0,55–0,62 для восьми из десяти полезных нагрузок, так и не достигнув уровня «крайне подозрительно» или «вредоносно», причем buildchain-native получила лишь ПОДОЗРИТЕЛЬНО с оценкой 0,62 и рекомендуемым действием «Мониторить». Подозрительный вердикт выглядит как работающий анализ, не добавляя ничего поверх этапов YARA и Semgrep, и в рамках политики, которая блокирует только на уровне вредоносности, эти полезные нагрузки проходят.

Галлюцинации (~23%, шесть моделей) — это особый случай, когда вердикт верен, но его обоснование сфабриковано, поэтому конвейер, записывающий его для аудита, накапливает сфабрикованные индикаторы, которые вводят в заблуждение последующего аналитика или любую дообученную на них модель. Это проявляется даже в обеих базовых моделях, поэтому повторяется независимо от уровня возможностей. Gemini — самый наглядный пример. Она выдала вердикт ВРЕДОНОСНО для всех десяти полезных нагрузок, но выдумала детали, сообщив о «процедуре дешифрования по адресу 0x401490» в taskd и «пользовательском цикле дешифрования XOR по адресу 0x4013b0» в netpulse, хотя ни один из этих адресов не существует во входных данных сканирования, и ни одна полезная нагрузка не содержит шифра. Фабрикация концентрируется там, где доказательная база наименее надежна — в однофункциональных полезных нагрузках x86, сканирование которых обнажает лишь один реальный адрес.

Структурный пробел

Недообнаружения носят структурный характер, а не являются дефектом отдельных моделей. В сбоях бюджетного уровня ниже порога эскалации доминируют рационализация и отклонение, где бинарный файл соседствует с чистым исходным кодом, установочным скриптом node-gyp-build, профессиональными метаданными и правдоподобным файлом README, каждый из которых ничем не примечателен для нативного модуля. Ни один отдельный артефакт не вводит модель в заблуждение. Каждый из 35 сбоев опирается по меньшей мере на два из этих безопасных сигналов, 24 — на четыре одновременно, а 14 переосмысливают собственные импорты бинарного файла как стандартные системные вызовы (Таблица 6). LLM могут анализировать бинарные данные изолированно [17, 18], но здесь сбой носит контекстуальный характер.

Таблица 6. Безопасные контекстные сигналы, упоминаемые в 35 сбоях обнаружения.

Предсказуемость режимов сбоев

Режимы предсказуемы в том смысле, что каждая модель демонстрирует один из них, хотя ни один из режимов не является детерминированным для всего вывода модели, поэтому защитники не могут просто выбрать модель получше. Эти две категории даже дают сбои по-разному: отклонение (dismissal) наблюдается практически исключительно у моделей с открытым весом (18 из 20 доброкачественных вердиктов без профилей от Gemma, Qwen и Llama), в то время как проприетарные модели редко отклоняют запросы и вместо этого рационализируют, проявляют осторожность (hedge) или галлюцинируют (confabulate). Это имеет значение при выборе модели. Тестовый набор из нескольких неоффусцированных пакетов или пакетов с низкой степенью двусмысленности заставляет бюджетную модель выглядеть достаточно эффективной, скрывая при этом ее неспособность обнаружить обфусцированный стилер учетных данных, причем обфусцированность регулярно встречается в реальных вредоносных программах (профиль обфусцированных бинарных строк сработал на 74 из 425 подтвержденных OSV бинарных пакетов, то есть в 17%). Тестирование только на полезных нагрузках с высокой степенью двусмысленности дает противоположный эффект, дискредитируя пригодную к использованию модель и подталкивая команду к перерасходу средств на передовую модель. Правильный вердикт также не означает правильную категорию, так как бюджетные модели часто фиксировали вредоносность, но присваивали неверную категорию, поэтому категория и указанные доказательства служат подсказками для приоритизации, а не абсолютной истиной для атрибуции.

Влияние на стоимость

Базовые модели Sonnet 4.6 и Kimi K3 обнаружили каждую полезную нагрузку без профилей при стоимости за сканирование примерно в 3 раза выше, чем у бюджетного уровня, который с использованием профилей достигает такой же точности при более низкой цене. Профили также изменяют объем работы с токенами, выполняемой каждой моделью (Таблица 7), причем направление изменения зависит от того, насколько тяжело модель работает без посторонней помощи. Бюджетный уровень получает небольшую надбавку к входным данным за счет блока доказательств размером около 1800 токенов (входные данные увеличиваются на 9–34%, а остальной анализ остается прежним), в то время как более мощные модели действуют наоборот. Opus, которая без профилей собирает около 10,5 тыс. входных токенов за сканирование при запросе дополнительных файлов, снижает этот показатель до 7,2 тыс. с профилями (−32%), а Kimi выдает на 13% меньше выходных токенов по той же причине. Профили добавляют небольшие ограниченные затраты входных токенов для дешевых моделей и экономят гораздо больше на дорогих.

Таблица 7. Использование токенов на одно сканирование в разрезе моделей, усредненное по десяти полезным нагрузкам, без профилей возможностей и с ними.

Валидация в продакшене

Вредоносный набор

Публичные рекомендации OSV [9], за исключением отозванных записей, подтверждают 470 версий вредоносных пакетов npm, содержащих нативный бинарный файл, всего 604 бинарных файла. По форматам они распределяются следующим образом: PE (273), ELF (215, каждый из них без отладочной информации) и Mach-O (113), а также 3 неидентифицированных; по компиляторам: 363 написаны на нативных C или C++, 183 на Go и 58 на Rust. 241 бинарный файл на Go или Rust (40% от общего числа) представляют собой те случаи, ради которых существует шлюз движка с учетом среды выполнения, а 50 файлов (все в формате ELF) упакованы с помощью UPX. Из этих 470 элементов 425 попадают в наш сканированный неотзываемый корпус, формирующий оценочный набор в разделе «Обнаружение».

Доброкачественный набор

Доброкачественный набор определяется исключительно на основе внешних сигналов, без опоры на собственный вердикт движка. Пакет считается подходящим, если он содержит нативный бинарный файл, имеет более миллиона загрузок в месяц и никогда не фигурировал в OSV, что дает 2449 версий пакетов в рамках 287 уникальных пакетов. Сканер эскалирует 104 из них до категории «крайне подозрительно» или выше (уровень ложноположительных срабатываний составляет 4,25% от версий пакетов, сосредоточенных в 6 уникальных пакетах, что составляет 2% от 287). По всем 104 элементам также сработали статические плейбуки, а по 33 профиль возможностей бинарного файла достиг порога вредоносности или критического уровня, поэтому эскалация отражала реальные сигналы в бинарном файле, упаковщиках, разделах с высокой энтропией и подозрительных импортах. Оставшийся уровень ложноположительных срабатываний является свойством статической двусмысленности бинарных файлов.

Обнаружение

Оценочный набор состоит из 425 версий пакетов с бинарными файлами из вредоносного набора, которые имеют производственный вердикт (неотозванная подмножество в нашем корпусе с вердиктами). На основе этого и доброкачественного наборов сканер достигает точности 0,77, полноты 0,81 и F1-меры 0,79 на пороге эскалации (Таблица 8). Полнота оценивается по метке уровня пакета OSV, которая не изолирует вредоносный артефакт, причем профиль возможностей бинарного файла обеспечил 74% обнаружений, в то время как остальные были эскалированы на основе JavaScript, метаданных или сигналов исходного кода.

Таблица 8. Эффективность обнаружения вредоносных бинарных программ, подтвержденных OSV, и доброкачественного валидационного корпуса на пороге эскалации.

Сканер восстанавливает 345 из 425 позитивных результатов; 60 переводятся в категорию подозрительных, а 20 очищаются как доброкачественные (уровень жестких пропусков составляет 4,7%). При проверке метаданных 20 очищенных пакетов без открытия самих бинарных файлов обнаруживается, что примерно половина из них без изменений включает в себя узнаваемые сторонние инструменты (ripgrep, node-pty, плагины установщика NSIS), где OSV приписывает вредоносность уровню установки или JavaScript; остальные содержат собственный скомпилированный CLI пакета, помеченный из-за кампании по компрометации учетных записей или рекомендации с низкой степенью уверенности. Таким образом, уровень пропусков на уровне бинарных файлов ниже, чем в заголовке, хотя мы не утверждаем, что каждый очищенный бинарный файл является доброкачественным.

Ограничения

Производственные показатели измеряются относительно меток уровня пакетов OSV, которые помечают весь пакет как вредоносный без выделения ответственного артефакта; некоторые очищенные пакеты имеют неверные метки, их полезная нагрузка содержится в JavaScript или метаданных, а не в бинарном файле. Таким образом, заявленные полнота и уровень ложноположительных срабатываний описывают производительность именно против этих меток, а не конкретно обнаружение бинарных файлов, которое может быть несколько выше или ниже. Кроме того, размещенные модели работают на базе непрерывно обновляемых эндпоинтов, поэтому абсолютные вердикты отражают одну эпоху обслуживания и могут дрейфовать, поэтому наши выводы основаны на внутриэпохальной дельте между условиями без профиля и с профилем для побитово идентичных входов, а не на каком-то отдельном вердикте.

Заключение

Четыре типа сбоев — рационализация, отклонение, проявление осторожности и галлюцинация — повторяются по всей панели, приводя к сбоям обнаружения на 50% тестов бюджетного уровня на пороге эскалации и на 73% на более строгом пороге вредоносности. Профили возможностей, которые внедряют предварительно вычисленные знания о бинарном домене до того, как модель начинает рассуждать, сокращают количество сбоев на пороге эскалации до 4% и устраняют все доброкачественные вердикты, удерживая уровень ложноположительных срабатываний на доброкачественном наборе на отметке 4,25% от версий пакетов (104 из 2449; 2% уникальных пакетов), что достаточно низко для ручной проверки аналитиком. В совокупности это позволяет гораздо более дешевой модели соответствовать точности обнаружения значительно более дорогой модели.

Приложение

Таблица А1. Вердикты без профилей возможностей (вердикт и уверенность) в разрезе моделей и полезных нагрузок. Это полная матрица, обобщенная в Таблице 3 и в разделе «Результаты без профилей возможностей».

Источники

[1] Sonatype. “2026 State of the Software Supply Chain”. 2026. https://www.sonatype.com/state-of-the-software-supply-chain/introduction

[2] SourceCodeRed. “IndonesianFoods spam campaign publishes more than 86,000 malicious NPM packages”. 2025. https://sourcecodered.com/indonesianfoods-npm-worm/

[3] Kieran Miyamoto. “DPRK npm packages”. https://dprk-research.kmsec.uk/

[4] Amazon. “Amazon identifies North Korean hacker group behind open-source supply chain attacks”. 2026. https://aws.amazon.com/blogs/security/amazon-identifies-north-korean-hacker-group-behind-open-source-supply-chain-attacks/

[5] OpenSourceMalware. “PolinRider: DPRK Threat Actor Implants Malware in Hundreds of GitHub Repos” (PolinRider: субъект угрозы из КНДР внедряет вредоносное ПО в сотни репозиториев GitHub). 2026. https://github.com/OpenSourceMalware/PolinRider

[6] Zscaler. “Tracking Shai-Hulud: Inside the ChainDrop NPM Worm” (Отслеживание Shai-Hulud: внутри червя ChainDrop NPM). 2026. https://www.zscaler.com/blogs/security-research/tracking-shai-hulud-inside-chaindrop-npm-worm

[7] CISA. “Widespread Supply Chain Compromise Impacting npm Ecosystem” (Масштабный компрометация цепочки поставок, затрагивающая экосистему npm). 2025. https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem

[8] Unit42. “The npm Threat Landscape: Attack Surface and Mitigations” (Ландшафт угроз npm: поверхность атаки и меры по снижению рисков). 2026. https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/

[9] OSSF. “OpenSSF Malicious Packages” (Вредоносные пакеты OpenSSF). https://github.com/ossf/malicious-packages

[10] VirusTotal. “What is YARA?” (Что такое YARA?). 2026. https://docs.virustotal.com/docs/what-is-yara

[11] Semgrep. “Semgrep: lightweight static analysis for many languages” (Semgrep: легковесный статический анализ для многих языков программирования). https://semgrep.dev

[12] Levi, M. et al. “CyberPal.AI: Empowering LLMs with Expert-Driven Cybersecurity Instructions” (CyberPal.AI: расширение возможностей LLM с помощью экспертных инструкций по кибербезопасности). 2024. https://arxiv.org/pdf/2408.09304v1

[13] Ullah, S. et al. “LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks” (LLM пока не могут надежно выявлять уязвимости безопасности и рассуждать о них: всесторонняя оценка, фреймворк и бенчмарки). 2024. https://arxiv.org/abs/2312.12575

[14] Traad, F.; Chehab, A. “To Ensemble or Not: Assessing Majority Voting Strategies for Phishing Detection with Large Language Models” (Ансамблировать или нет: оценка стратегий мажоритарного голосования для обнаружения фишинга с помощью больших языковых моделей). 2024. https://arxiv.org/abs/2412.00166

[15] Li, Q. et al. “Beyond Majority Voting: LLM Aggregation by Leveraging Higher-Order Information” (За пределами мажоритарного голосования: агрегация LLM с использованием информации высшего порядка). 2025. https://arxiv.org/abs/2510.01499

[16] Sharma, M. et al. “Towards Understanding Sycophancy in Language Models” (К пониманию подхалимства в языковых моделях). 2023. https://arxiv.org/abs/2310.13548

[17] Patsakis, C. et al. “Assessing LLMs in Malicious Code Deobfuscation of Real-world Malware Campaigns” (Оценка LLM при деобфускации вредоносного кода в реальных кампаниях по распространению вредоносного ПО). 2024. https://doi.org/10.1016/j.eswa.2024.124912

[18] Jelodar, H. et al. “Large Language Model (LLM) for Software Security: Code Analysis, Malware Analysis, Reverse Engineering” (Большие языковые модели (LLM) для безопасности программного обеспечения: анализ кода, анализ вредоносного ПО, обратная разработка). 2025. https://arxiv.org/abs/2504.07137

О чём эта статья

Ещё в разделе «Данные и аналитика»

Все →

Ещё от Databricks