VP Cybersecurity Brief

Вы бы хотели видеть на канале новости про самые опасные критические уязвимости в популярном ПО? Например Обнаружена критическая уязвимость CVE-2026-16723 с оценкой 9,0 по шкале CVSS 3.1 в библиотеке Java Fastjson 1.x. В уязвимых версиях 1.2.68–1.2.83 внешний злоумышленник при определённых условиях эксплуатации Spring Boot (выключен safemode и запущено как executable fat-JAR) Опубликован эксплойт, уже фиксируются попытки эксплуатации. Экспертно, площадь атаки около 1% от всех инсталяций Java. Нужно проверить используете ли вы уязвимую библиотеку и если да у язвимой ли конфигурации.

🧠 ФЗ о поддержке развития ИИ ➤ Официально опубликован Федеральный закон от 26.07.2026 № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации».

А вот и закон, теперь в РФ закрепили термины ИИ. Ждем подзаконных актов которые определят когда нужно использовать суверенные ИИ модели, а когда национальные. Вероятность меньше процента не сработала, как я и прогнозировал, закон подписали в конце июля. Увы в плане сроков закон по ИИ не отличился от других законов.

Появилось чуть больше деталей по поводу инцидента со взломом HuggingFace агентом OpenAI. Reuters постарались установить таймлайн событий, по их источникам внутри компаний выходит так: — Агент пытался вырваться из изолированной тестовой среды OpenAI примерно c 9 июля. — Вторжение в системы Hugging Face началось через два дня, 11 июля, и продолжалось до 13 июля. — OpenAI потребовалось еще несколько дней, чтобы понять, что за взломом стоит её агент, и обе компании впервые связались по этому поводу лишь примерно 20 июля. — По ходу работы агент оставлял записи для своих будущих копий. Скорее всего речь про простые текстовые инструкции на случай, если другие инстансы модели смогут выйти из окружения (чтобы им было легче получить доступ к интернету). — Пресс-секретарь OpenAI заявила, что в публикации Reuters допущено "несколько неточностей", но не пояснила, каких именно. — Где-то между этим HuggingFace подали обращение в ФБР для расследования инцидента. То есть агент буянил в интернете неделю или даже больше. Что ж, зато compaction (инструмент сжатия контекста для долгих задач, которые не помещаются в контекстное окно LLM) работает хорошо 👨‍🦳 CEO HuggingFace съездил в офис OpenAI и обсуждал дальнейшие шаги. Он просит: — Радикальной прозрачности: опубликовать логи «вышедших из-под контроля» агентов, чтобы всё исследовательское сообщество смогло изучить, что произошло. — Больше возможностей для защитников, например, чтобы OpenAI выделили $100 миллионов, чтобы помочь сообществу разработать мощные средства киберзащиты с использованием лучших открытых и закрытых моделей. OpenAI буквально пару часов назад выпустили обновление к своему заявлению: «Мы понимаем, что вокруг инцидента с Hugging Face циркулирует множество вопросов и неподтвержденных домыслов. Это беспрецедентный случай, и мы считаем, что он знаменует собой важный момент для сферы безопасности ИИ. Мы все еще проводим тщательное расследование совместно с внешними консультантами. Как только проверка будет завершена, в ближайшие недели мы планируем опубликовать технический отчет с извлечёнными уроками». Хорошо, что к аудиту привлечены внешние консультанты. Но я сомневаюсь, что в ближайшие недели мы увидим точное описание обнаруженных уязвимостей — это бы означало угрозу для всех пользователей затронутых программ, которые не обновились до версии с исправлением. Однако вот тут в твиттере два эксперта по кибербезопасности выражают уверенность, что смогли найти софт + указание на уязвимость в JFrog Artifactory.

Совет PCI выпустил документ транслирующий требования PCI DSS 4.0.1 в NIST CSF 2.0. Полезный документ для комплаенса финсектора если их внутренний стандарт построен на NIST CSF 2.0

Логичный ответ на нейрослоп в отчётах дают заказчики bugbounty - расширение частных программ. Пример - github.

Вышел новый Опус 5.0 от Антропика. По заявлениям - ищет уязвимости в исходном коде на уровне Мифов, но вот эксплойты писать все равно не должен =)

Несмотря на, то что нельзя отрицать вероятность, что все недавние побеги из песочниц и непроизвольные атаки моделей в ходе тестирования это пиар перед IPO, есть один важный момент. Придется пересмотреть риск и реализовывать митигирующие меры для такого сценария как "атака вашей моделью третьей стороны" или иные действия которые могут повлечь за собой юридические последствия в силу действий ваших ИИ агентов. Почему это вызов? В большинстве организаций защита строится исходя из нахождения злоумышленника за периметром защиты или как минимум нахождения его со стороны внешних интерфейсов. В модели угроз внутренних нарушителей часто рассматривают с заметно меньшим потенциалом, чем внешних. Например, сколько вы знаете организаций которые проверяют на вирусы свой исходящий почтовый трафик? А просто интернет трафик? А в ваших правилах межсетевого экрана ограничивается подключение к сторонним сервисам по привилегированным портам? Следующий вопрос, пока ещё будущего, в ваших средствах должны использоваться как минимум разные семейства моделей, в силу того, что модель сама себя любит необъективно оценивать (self bias). И отдельно стоит оценить риск, того что можно назвать segregation of models. Например, если у вас одна и таже модель помогает в составлении платежных поручений и помогает в их проверке перед оплатой или составляет заявки на получение доступов и согласовывает - логично, что и тут будет как минимум 2 разных семейства моделей. Эти вопросы должны себе задать все использующие ИИ модели, особенно разработчики SOTA моделей.

Отличный пример специализированной модели для поиска известных уязвимостей в коде от Cisco - Antares. Напомню, по мнению gartner за специализированными моделями лежит возможность заметного повышения экономической эффективности средств ИИ. Выложено 2 модели на 0.3 и 1 млрд параметров. Планируется релиз на 3 млрд параметров. По оценке самой Cisco, разница в стоимости может достигать до 172 раз если сравнивать с gpt 5.5. Антарес можно запускать на обычных компьютерах от 8 ГБ ОЗУ на модель. Для запуска сравниваемой ближайшей по бенчу Cisco glm- 5.2 модели потребуется минимум сервер с кластером H200.

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

Одним из основных сценариев ряда экспертов отвечающих за безопасность ИИ моделей является замедление разработки новых ИИ моделей. Меры по кибербезопасности и общей безопасности ИИ моделей и агентов сильно отстают от прогресса самих ИИ моделей и агентов. Одним из фундаментальных факторов для прогнозов по замедлению разработки ИИ моделей является исчерпание объема данных для обучения новых ИИ моделей. Что с одной стороны приводит к резкому спросу на покупку компаний банкротов, где ничего нет кроме данных, а с другой стороны создает новый тип угрозы - кражи любых структурированных данных с целью дальнейшего использования для обучения ИИ моделей. Другой попыткой решить эту проблему является создание разных средств трекинга для записи действий - от разработчиков Meta до ручных операций работниками развивающихся стран. Ситуация с исчерпанием данных для обучения новых версией модели стала широкоизвестна около 1 года назад, но сильных признаков резкого замедления разработки моделей ИИ пока не видно. За 11 календарных дней июля вышло 9 (девять!) новых передовых моделей ИИ: 3 модели GPT 5.6 (Sol, Terra, Luna), Meta Muse Spark 1.1, GigaChat 3.5 Ultra, Thinking Machines Inkling, Grok 4.5, Kimi K3, Alibaba Qwen3.8-Max-Preview. На замедление не сильно похоже, у всех моделей значительный рост по их возможностям, снижению стоимости за токен или скорости. У GPT, Muse, Grok, Thinking Machines Lab Inkling - есть публичные системные карточки и публичная информация о тестировании разработчиками вопросов кибербезопасности и общей безопасности. По опыту прошлых релизов, от GigaChat, Kimi, Qwen - стоит ждать максимум технический отчет, без полноценной карточки модели и без полных отчетов тестирования на безопасность. p.s. Thinking Machines Lab Inkling - новая модель с открытыми весами из США.

Самый близкий эквивалент этой рекомендации CISA в России это регламент включения уязвимостей в БДУ ФСТЭК России.

Американский регулятор CISA в партнерстве с другими регуляторами выпустил рекомендации по созданию своей программы ответственного раскрытия уязвимостей. Это полезно в первую очередь компаниям со своей разработкой или компаниям предоставляющим услуги bugbounty. Само руководство больше про общие подходы, есть полезные ссылки на материалы других регуляторов, где уже есть чуть больше технических примеров. Напоминаю, что в России действия по поиску уязвимостей со стороны третьих лиц могут быть классифицированы как деяние по статье 272 УК РФ (Неправомерный доступ к информации). Законопроект о легализации действия белых хакеров был отклонен в 3 чтении госдумой в 2025 году. Поэтому в Российских программах раскрытия должен быть блок с "явным заявление владельца системы/программного обеспечения о том, что при соблюдении исследователем правил действия считаются санкционированными и организация не обращается в правоохранительные органы". Это снимает часть рисков. Самый близкий эквивалент этой рекомендации CISA в Росс

Вот именно по следам этих кейсов и не только авторы статьи выше предлагают подход к оценке пользы от внедрения ИИ. OpenAI предлагает перейти к инженерному подходу - измерять не затраты на ресурс, а эффективность преобразования ресурса в полезный завершённый результат. В центре стоит метрика "полезный интеллект за доллар", которая раскладывается на четыре вопроса. Каждый вопрос - это не просто пункт в отчёте, а целая система сбора данных и принятия решений: 1. Выполняет ли ИИ действительно важную работу? Первый шаг - перестать измерять активность и начать измерять результат. Ценность создается не количеством сгенерированного текста, а завершенными полезными действиями. Важно  "определение завершенности" для каждого бизнес-процесса. Тот самый эффект который я называл ещё в 2019ом value в бизнес ноде. Например, для отдела продаж полезной работой будет не "сгенерировать 100 писем", а "отправить клиенту финальное письмо, которое утверждено руководителем". Это меняет фокус с процесса на результат. 2. Сколько стоит одна успешно выполненная задача? Это самый технический и важный пункт. Забудьте про цену за токен, она обманчива. Нужно считать полную стоимость одного принятого результата. И тут как раз вы можете фиксануть ROI, как я говорил выше. Формула простая: (Стоимость API-вызовов + Время персонала на промпты и правки + Время на проверку + Стоимость инфраструктуры) / Количество задач, принятых без доработок. Дешевая модель может давать много ошибок, требовать постоянных правок и в итоге обойтись дороже, чем более дорогая, но точная. Именно поэтому OpenAI выпускает GPT-5.6 с тремя моделями: Sol (для сложных задач, где ошибка дорога), Terra (золотая середина) и Luna (для рутинных операций). Выбор модели - это всегда поиск баланса между ценой и качеством конечного результата. Снова привет fusion или Fugu оркестрации. 3. Можно ли доверять результатам? Этот вопрос напрямую влияет на стоимость. Чем выше доверие к ИИ, тем меньше времени тратится на проверку. OpenAI выделяет тут три уровня зрелости: · Черновик. ИИ предлагает вариант, человек все перепроверяет. · Поиск и рассуждение. ИИ находит информацию и строит цепочки, но решения принимает человек. · Автономное действие. ИИ выполняет операции сам (отправляет письма, вносит данные). Для перехода на новый уровень нужно измерять доверие. Классифицируйте каждый ответ ИИ: · Зеленый –принят без изменений. · Желтый – требует легкой правки. · Красный – полностью переделан. Если доля "зеленых" ответов растет, значит, доверие повышается, а стоимость контроля снижается. 4. Растет ли ценность при масштабировании? Последний вопрос – про динамику. Даже если сегодня все хорошо, нужно следить, не ухудшается ли экономика при росте объемов. Ключевая метрика: Эффективность = Объем полезной работы / Совокупные затраты на ИИ Неплохая замена ROI в моменте, этакий аналог биржевого индикатора. Если вы увеличиваете использование ИИ в два раза, а затраты растут тоже в два раза - вы на месте. Если затраты растут медленнее - вы в выигрыше. OpenAI утверждает, что их модели постоянно улучшаются, а стоимость снижается. Но компаниям все равно нужно вести собственный счёт – собирать данные по каждому процессу и регулярно пересчитывать эффективность. Вот вам и новые задачи вашим аналитикам. 👍 Практический чек-лист для внедрения от OpenAI: 1. Выберите 3–5 ключевых процессов, где используется ИИ. 2. Для каждого четко определите «завершенную задачу». 3. Начните собирать данные о всех затратах (не только API, но и время сотрудников). 4. Ведите классификацию ответов (зеленый/желтый/красный). 5. Пересчитывайте стоимость за задачу и сравнивайте разные модели. 6. Раз в квартал оценивайте динамику эффективности. А как вы оцениваете вклад ИИ в своих проектах? Делитесь опытом в комментариях 👇👇👇

Время на "мы просто пробуем ИИ" уже закончилось. Как измерять реальную ценность от внедрения ИИ? Именно с этого отрезвляющего тезиса стартует статья от OpenAI. Теперь вы не можете как в 2023-2024, а кто-то все ещё сейчас просто экспериментировать ради любопытства, сегодня ИИ - это реальная производственная мощность, и нужно её измерять также, как электроэнергию или выч ресурсы. 📦 помнится, как оценивали качество от автоматизации ручных процессов или поддержки с ИИ: 1. Общий трафик DAU, MAU, WAU и тп. 2. Интерес, через возвращаемость ака retention rate. На самом деле, не так важно, что в первый день запуска вы вывалили большой трафик, как то, что если сервис полезен к вам будут возвращаться снова и снова. 3. Число принятых подсказок с ИИ - ака acceptation rate. К примеру, вы работаете с ИИ суфлером или код агентом копайлотом и вот число принятых подсказок по ответу оператора или коду можно было измерить так. 4. Польза в конечной бизнес ветке или ноде. Если вы работали с сценариями поддержки, на самом деле, автоматизация должна считаться не только числом закрытых вопросов в чате без перевода на оператора, но и измеряться закончился ли диалог на самом деле решением проблемы пользователя или он через час снова придёт с этой темой в чат (а тут уже retention rate работает против вас). Да это можно проксироват через CSI, NPS, но в век LLM и агентов можно верифицировать и без оценки человека, достигнуто ли было намерение юзера и решена проблема с которой он придёт. А ещё у нас была система штрафов за возвращаемость юзера по проблеме ещё раз в чат или к оператору. 5. Фин эффекты в лице ROI. Тут просто (на самом блин деле, ни фига не просто) отношение прибыли к затратам на ИИ сервис, фичу, решение, проект и тп. - скок заработали к тому сколько потратили на разработку, аммортиазцию железа и токены на эксплуатацию. Обычно измеряется в %, умножаетсы естественно на 100. Однако помимо этого, мало посчитать таким образом потенциал, ещё нужно посчитать срок окупаемости. ROI показывал, что мы имеем такой потенциал, а срок окупаемости за какое время мы его можем достичь. 6. Рост эффективности труда. Вот моё "любимое", что над именно считать на сколько уменьшится время на выкатку фичи, сервиса, продукта или нового кода/программы, ускориться принятие решения и тп. Ака Lead Time, Time to Market и аналоги. И да современный ИИ тут помогает. Почитали? Интересно? А теперь забудьте все не так радужно. Начну с ROI прям сразу - компании не умеют, а некоторые оунеры решений и не хотят считать это честно (не в смысле врут, а в смысле не все переменные учитывают). Часто в текущей реальности заканчивается оценкой скорости а-ля ТТМ, но никто не хочет посчитать деньги в конечной бизнес ноде. К примеру, вы смогли автоматизировать аналитику, сказали что ускоритель на К%, но почему-то не получаете оценку оборачиваемости капитала или out-of-stock (упущенные продажи) в денежках, на которые и повлияет ускорение принятия решения от внедрения ИИ. Но окей, вы посчитали это, но в знаменатель забудете положить кроме фот на разработку, ещё токен экономику и аммортизацию ваших мощностей (если они онпрем). Почти все не понимают, сколько токенов они будут кушатс. На самом деле, ну и не должны, вопрос ж в динамическом изменении этого, особено с МАС под капотом. Но раз тут у нас динамический показатель, то ROI не будет фиксой, как и поправки в срок окупаемости придётся вносить. Ну и мякотка, все хотят на старте это посчитать, а в вводных выше мы понимаем, что посчитать можно только по факту в начале (порой пальцем в небо) или за период (на конец отчетного), а без этого даже стартовать порой отказываются. Второе любимое это про экономию на ФОТ через автоматизацию. Ну тип дали людям огонь Claude Code и ща кааак начнём сокращать разрабов и экономить на дорогих манки кодерах. В итоге хороший agent developer с инструментом на max подписке кушает за себя и за Сашку. Те вы почти не экономите на ФОТ, тк сопоставимо тратите на токены.

В рамках вечера пятницы

Сегодня получилось попасть на Summer Camp от Jet. У коллег получилось довольно ламповое мероприятие на воде. Много было интересных докладов от известных спикеров, но я бы хотел поделиться парой фото из доклада Андрея Левкина, владельца продукта Bugbounty от Bi.Zone. По его экспертной оценке есть количественное увеличение находимых уязвимостей выше обычного органического роста, но тысяч корректно принятых уязвимостей пока нет. Т.е. на текущий момент можно предположить, что ИИ точно помогает находить корректные уязвимости, но ситуация далека от драмы которую ставят Мифом и GPT 5.6. А вот количества спама с которым теперь триажерам приходится бороться выросло в 14 раз. Одними из решений этой проблемы стало введение талонов/квот на сдаваемые отчёты и использование ИИ при анализе сдаваемых отчётов. Пара фото из презентации ниже.

OpenAI признала, что GPT-5.6 может случайно удалить ваши файлы Из-за стремления любой ценой закончить задачу GPT-5.6 может обойти ограничения, использовать чужие учётные данные или удалить важные файлы. Это происходит редко и по ошибке, а не потому, что модель хочет навредить пользователю. https://www.theregister.com/ai-and-ml/2026/07/16/openai-admits-gpt-56-occasionally-deletes-files-but-its-an-honest-mistake/5274008