Как безопасно использовать LLM в работе по безопасности

ИИ-ассистент способен за секунды кратко пересказать запись CVE. Неверную исправленную версию он может назвать тем же спокойным тоном, что и верную. Эта статья о таком разрыве: о четырёх главных рисках в работе по безопасности, о методе, который их снижает, и о лабораторной работе, где вы сверите написанное ИИ резюме с записью NVD, каталогом CISA Known Exploited Vulnerabilities (KEV) и страницей безопасности Apache Log4j.

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

#В чём состоят риски

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

#Уверенно изложенные ложные факты

Языковая модель выдаёт самые правдоподобные следующие слова. Часто правдоподобный ответ оказывается и верным. Иногда это номер версии, который звучит правильно, но неверен. NIST Generative AI Profile, документ NIST AI 600-1, называет это конфабуляцией: «порождение уверенно изложенного, но ошибочного или ложного контента». В том же профиле отмечено, что конфабуляция следует из устройства этих моделей и редким сбоем её считать нельзя.

Сильнее всего страдают идентификаторы. Номера CVE, версии пакетов, даты, имена функций, номера RFC и порты выглядят структурированно, поэтому и ошибочное значение кажется проверенным. Его легко скопировать в тикет и трудно заметить позже.

#Чувствительные данные в промптах

Всё, что вы вставили в промпт, выходит из-под вашего контроля, как только попадает в сервис, которым вы не управляете. Дальнейшее зависит от сервиса, его настроек и условий. Текст могут сохранить, записать в лог или просмотреть. В работе по безопасности рискованный материал хорошо знаком: имена клиентов, внутренние имена хостов и диапазоны IP, токены из логов, неопубликованные находки и персональные данные из инцидента. OWASP относит это к LLM02:2025 Sensitive Information Disclosure, куда входит и то, что раскрывает модель, и то, что выставляет наружу окружающее её приложение.

#Небезопасные действия инструментов

Ассистент с одним текстовым полем может дать плохой ответ. Ассистент с оболочкой, API-токеном или правом записи в репозиторий может сделать что-то плохое. OWASP LLM06:2025 Excessive Agency описывает эту проблему: у системы больше функций, разрешений или автономии, чем нужно для задачи. Когда модель неверно понимает запрос, ущерб зависит от того, к чему ей разрешено прикасаться.

#Prompt injection из недоверенного контента

Prompt injection случается, когда контент, который система читает как данные, содержит инструкции, и модель их выполняет. Это может быть веб-страница, которую вы попросили пересказать, письмо в очереди, строка лога со специально составленным user agent или README в репозитории, который вы попросили проверить. OWASP описывает это как LLM01:2025 Prompt Injection. Профиль NIST описывает непрямой вариант, когда атакующий подкладывает инструкции в данные, которые ассистент, скорее всего, извлечёт. Ассистент может не отличить ваш запрос от текста, который только что прочитал.

#Почему это важно аналитикам

Именно аналитики копируют вывод ИИ в отчёты, правила обнаружения, тикеты и сообщения клиентам. Ошибка переезжает вместе с копией. Неверная исправленная версия в вашем резюме превращается в неверное решение о патче в чужом окне изменений.

NIST AI Risk Management Framework, выпущенный 26 января 2023 года, делит работу на четыре функции: GOVERN, MAP, MEASURE и MANAGE. Чтобы позаимствовать идею, вести программу по ИИ необязательно. Для одного аналитика это означает знать, зачем нужен инструмент, какие данные он видит, как часто ошибается на ваших задачах и кто одобряет действия. Фреймворк добровольный, и это нормально. Вопросы всё равно остаются.

#Метод

Пять правил, каждый раз в этом порядке.

#1. Решите, что может попасть в промпт

Прежде чем что-либо вставлять, разделите материал на три группы:

• Публичное: бюллетени вендоров, опубликованные записи CVE, открытая документация.
• Внутреннее, но не чувствительное: общая процедура, обезличенный шаблон кода.
• Ограниченное: имена клиентов, имена хостов, IP-адреса, учётные данные, неопубликованные находки, персональные данные.

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

sed -E 's/([0-9]{1,3}\.){3}[0-9]{1,3}/10.x.x.x/g; s/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+/user@example/g' incident.log > redacted.log

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

#2. Просите источники и отделяйте утверждения от догадок

Попросите ассистента перечислить каждое фактическое утверждение с источником и писать «нет источника», когда его нет. Каждое утверждение без источника считайте вопросом, на который отвечать вам.

Ссылка на источник в ответе сама по себе ничего не доказывает. Модель способна выдать правдоподобную ссылку или правдоподобную цитату из документа, который никогда не открывала. Откройте ссылку. Прочитайте абзац. Если в абзаце сказано не то, что в ответе, ответ неверен.

#3. Проверяйте по первичным данным

Первичные данные — это запись, о которой идёт речь в утверждении: запись NVD для CVE, бюллетень вендора, запись CISA KEV, текст стандарта, вывод вашего собственного теста. Второй ответ ИИ не считается, потому что второй ассистент способен повторить ту же ошибку с той же уверенностью. Ассистент подскажет, где искать, решать будете по источнику.

#4. Ограничьте возможности инструмента

Начните с доступа только на чтение. Если инструмент может запускать команды, дайте ему учётную запись с минимальными правами, одноразовую виртуальную машину или контейнер и список разрешённых команд. Любой шаг, который пишет, отправляет, удаляет или обращается к работающей системе, должен ждать подтверждения. Сохраняйте лог того, что он запускал. Он понадобится в первый же раз, когда произойдёт что-то неожиданное.

#5. Оставьте решение за человеком

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

#Практика: проверка написанного ИИ резюме CVE

В этой лабораторной работе вы только читаете публичные источники. Вы ничего не запускаете против работающих систем. Три запроса уходят в NVD, CISA и Apache Software Foundation, и больше никуда.

Что нужно: терминал (подойдёт Git Bash на Windows), curl и jq. Если jq не установлен, поставьте его с сайта проекта jq. Команды ниже выполнялись на Windows 11 в Git Bash. На той машине jq не было, поэтому показанный вывод получен командой Node.js, которая читает те же поля JSON. Использовать следует команды jq.

#Образец резюме

Вот резюме CVE-2021-44228, уязвимости, известной как Log4Shell, которое написал ассистент. Прочитайте его до всякой проверки и отметьте то, что считаете неверным.

CVE-2021-44228 is a remote code execution flaw in Apache Log4j2. An attacker who controls a logged value can make the server load code from an LDAP server. NVD published the record on 2021-12-09. The flaw affects Log4j 2.13.0 through 2.14.1, and upgrading to 2.14.1 fixes it. The CVSS v3.1 base score is 10.0. CISA added the flaw to the KEV catalog on 2021-12-10. Attackers began scanning within hours of disclosure. The flaw is in log4j-core only.

В резюме две намеренные ошибки. Найдите их с помощью источников ниже.

#Шаг 1: получите запись NVD

API NVD возвращает запись CVE в формате JSON. Выполните команду:

curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' | jq '.vulnerabilities[0].cve | {published, descriptions: .descriptions[0].value}'

Та же проверка без jq, её вывод показан ниже:

curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' -o nvd.json
node -e "const c=JSON.parse(require('fs').readFileSync('nvd.json','utf8')).vulnerabilities[0].cve;console.log(JSON.stringify({published:c.published,descriptions:c.descriptions[0].value},null,2))"

Полученный вывод:

{
  "published": "2021-12-10T10:15:09.143",
  "descriptions": "Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects."
}

Посмотрите на поле published. В образце указано 2021-12-09. В записи стоит 2021-12-10. Это первая ошибка.

В описании есть и условие, которое образец опустил: загрузка кода происходит, когда включена подстановка через message lookup. Без него кажется, что уязвимость затрагивает любую установку Log4j, а запись этого не утверждает.

#Шаг 2: получите запись KEV

CISA публикует каталог KEV одним файлом JSON. Скачайте его и отфильтруйте по CVE:

curl -s -L 'https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json' -o kev.json
jq '.vulnerabilities[] | select(.cveID=="CVE-2021-44228")' kev.json

Полученный вывод из каталога версии 2026.11.06 с 1769 записями, скачанного 2026-11-08 (фильтр jq выполнялся через Node.js, как и выше):

{
  "cveID": "CVE-2021-44228",
  "vendorProject": "Apache",
  "product": "Log4j2",
  "vulnerabilityName": "Apache Log4j2 Remote Code Execution Vulnerability",
  "dateAdded": "2021-12-10",
  "shortDescription": "Apache Log4j2 contains a vulnerability where JNDI features do not protect against attacker-controlled JNDI-related endpoints, allowing for remote code execution.",
  "requiredAction": "For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. Temporary mitigations using one of the measures provided at https://www.cisa.gov/uscert/ed-22-02-apache-log4j-recommended-mitigation-measures are only acceptable until updates are available.",
  "dueDate": "2021-12-24",
  "knownRansomwareCampaignUse": "Known",
  "forensicTriage": "No",
  "notes": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228",
  "cwes": [
    "CWE-20",
    "CWE-400",
    "CWE-502"
  ]
}

Запись подтверждает попадание в KEV и дату добавления. О том, когда началось сканирование, в ней ничего нет, исправленная версия тоже не названа. Используйте её для факта включения в каталог, срока и требуемого действия, и только для них.

#Шаг 3: откройте страницу Apache и отметьте каждое утверждение

В записи NVD есть ссылка на страницу безопасности Apache Log4j. Откройте её и найдите раздел о CVE-2021-44228. Прочитайте четыре поля: Versions affected, Versions fixed, Components affected и описание. В версии страницы, полученной 2026-11-08, в разделе были такие значения:

• Versions affected: [2.0-beta9, 2.3.1), [2.4, 2.12.2) и [2.13.0, 2.15.0). Скобки обозначают интервал: левый конец включён, правый нет, поэтому сама 2.15.0 находится вне диапазона.
• Versions fixed: 2.3.1 для Java 6, 2.12.2 для Java 7 и 2.15.0 для Java 8 и новее.
• Components affected: log4j-core.

Прочитайте страницу сами, потому что она меняется. На ней есть и отдельный раздел о CVE-2021-45046, последующей проблеме: там сказано, что исправление в 2.15.0 было неполным в некоторых конфигурациях, и указана 2.16.0 для Java 8 и новее.

#Вердикты

Отметьте каждое утверждение образца как подтверждённое, неверное или непроверяемое. Вот результат такой проверки.

Два утверждения неверны, одно непроверяемо, остальные подтвердились. Два неверных утверждения и есть две намеренные ошибки образца.

#Чему учит проверка

Текст NVD и диапазоны версий немного расходятся. В описании сказано «through 2.15.0», а машиночитаемый диапазон заканчивается до 2.15.0. И конфигурация NVD, и страница Apache говорят, что 2.15.0 не затронута этой CVE на Java 8 и новее. Когда источники расходятся, зафиксируйте расхождение и сошлитесь на тот, который определяет диапазон. Не выбирайте версию, которая лучше читается.

Исправленная версия зависит от версии Java и от CVE. Единственный номер «fixed in» скрывает и то и другое. Запрашивайте точную CVE, продукт, компонент и платформу и читайте таблицу вендора.

Вердикт «непроверяемо» полезен. Образец сообщает факт о времени действий атакующих, которого нет ни в одном из ваших источников. Это утверждение может быть верным и может встречаться в источнике, который вы не читали. В отчёте ему нужна собственная ссылка, иначе его придётся убрать.

#Частые ошибки

• Доверять внешнему виду ссылки. Аккуратная ссылка с правдоподобным заголовком может вести на страницу, где сказано другое. Откройте её.
• Вставлять весь инцидент, чтобы «быстро глянуть». Сначала замаскируйте чувствительные данные и вставьте только фрагмент, нужный для вопроса.
• Спрашивать о последней версии без даты. Модель может не знать о релизах, вышедших после окончания её обучающих данных. Дайте ей примечания к выпуску или бюллетень и попросите прочитать их.
• Принимать сгенерированный патч, не запустив тесты и не прочитав дифф.
• Проверять, как ассистент обращается с реальными данными клиентов, «просто посмотреть». Сама проверка и есть утечка.
• Давать агенту продакшен-учётные данные, потому что они понадобились для демо.
• Пересказывать веб-страницу, не думая о том, кто её написал. Страница может содержать инструкции. Относитесь к её тексту как к данным для чтения и не выполняйте его как приказы.

#Что дальше

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

Прочитайте записи OWASP LLM01, LLM02, LLM06 и LLM09. Они дают общий словарь для prompt injection, раскрытия данных, избыточных разрешений и дезинформации. Затем прочитайте раздел 2 NIST AI 600-1, где определены риски, которые охватывает профиль.

Если сначала нужны основы, прочитайте Что такое уязвимость? и Что такое CVSS?. Чтобы потренироваться в описании проверенных находок, прочитайте Как написать первый отчёт по безопасности. Если вы отправляете работу модели через API NotHoly, те же пять правил действуют для всего, что вы отправляете.

#Источники

• NIST AI Risk Management Framework
• NIST AI 600-1, Generative AI Profile (July 2024)
• OWASP Top 10 for LLM and GenAI Applications, 2025
• NVD Vulnerability API documentation
• NVD record for CVE-2021-44228
• CISA Known Exploited Vulnerabilities catalog (JSON feed)
• Apache Log4j Security Vulnerabilities