Yandex for Security

💼 «Теневой AI» в компании и новые риски для ИБ AI-инструменты уже стали частью повседневной работы: сотрудники загружают документы в публичные модели, подключают кодовых ассистентов и даже доверяют агентам доступ к корпоративной инфраструктуре. Иногда всё это происходит официально, а иногда — без ведома службы безопасности. ⏩ В новом выпуске «Безопасно говоря» обсуждаем, как компаниям управлять рисками, если внедрение нейросетей опережает обновление процессов безопасности. А также разбираемся, можно ли просто так взять и запретить сотрудникам «неодобренный» AI, как защищать данные и инфраструктуру и почему классических DLP и политик безопасности уже может быть недостаточно. 🎤 Ведущие: 🟣 Антон Черноусов, Developer Advocate Yandex Cloud 🟣 Сергей Нестерук, эксперт по безопасности ML Yandex Cloud 👨‍💻 Гости: 🟣 Евгений Кокуйкин, основатель HiveTrace 🟣 Сергей Голованов, главный эксперт «Лаборатории Касперского» 🎧 Слушайте подкаст: 🟣 Ютуб 🟣 VK Видео 🟣 Яндекс Музыка Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🗺 Как мы защищаем Яндекс Карты Меня зовут Алексей Никифоров, я старший аналитик-разработчик в Яндексе. Хочу поделиться опытом защиты Карт от геоспама. Допустим, у вас сломался ноутбук или телефон. Вы открываете карты, находите ближайший ремонт, звоните туда, а по факту это оказывается несуществующая точка, которую создали специально для сбора заказов. Цена вопроса может оказаться завышенной, а качество услуг — сомнительным. Именно от подобных случаев мы и защищаем пользователей. Наша задача — не просто детектить фрод, а вообще не допускать его до карт. 〰️ Проблема: геоспам и серая зона Геоспам — это создание на картах объектов, которых не существует в реальном мире. Мотивация разная: от повышения заметности бизнеса до прямого мошенничества. Причём распределён геоспам неравномерно и сосредоточен в основном в крупных городах, таких как Москва или Питер. Основная сложность антифрода — это серая зона. В ней наши данные ограничены и нет чётких сигналов, чтобы понять, является ли объект фейковым или нет. 🔎 Давайте рассмотрим три разных подхода постановки задачи для антифрода ♒️ Подход 1: классификация Цель: максимально точно разделить фрод и не фрод, автоматически банить как можно больше мошеннических объектов, но при этом задевать как можно меньше честных. Для этого мы построили golden set из трёх источников: 🟣 Ранее пойманные массовые фродовые атаки 🟣 Вердикты ручной модерации 🟣 Ретроспективная разметка старых объектов, по которым накопилась дополнительная информация: жалобы, маршруты, отзывы С генерацией фич нам помогли графовые методы, где вершинами были объекты, а связями — пользователи (и любые сигналы, указывающие на общего владельца). У новых организаций мало информации, но у их соседей по графу может быть богатая история. На этих фичах и golden set мы обучаем модели, которые классифицируют новые точки на фрод и не фрод. ⏩ Результат: карта стала заметно чище, мы начали ловить свыше 90% фрода на этапе создания и снизили нагрузку на модерацию. Но часть фрода адаптировалась и научилась обходить модель. ♒️ Подход 2: экономика фрода Цель: сделать фрод невыгодным, чтобы мошенники ушли сами. Наша стратегия: 🟣 Ужесточили контроль в самых заметных локациях и ослабили в непопулярных местах 🟣 Начали быстрее банить новые мошеннические телефоны и сайты (их создание стоит дорого, в отличие от аккаунтов) ⏩ Результат: количество показов и кликов по геоспамным точкам стало в несколько раз меньше, как и жалоб на них. Большая часть фрода сдалась и ушла. Но остались те, у кого маржа настолько высока, что они готовы тратить по несколько тысяч рублей на создание одной фейковой точки. ♒️ Подход 3: политика нулевой терпимости Цель: гарантировать отсутствие фрода в серых зонах. В конкретных чувствительных срезах мы готовы отодвинуть бизнес-метрики на второй план ради полного отсутствия геоспама. Что мы делаем: 🟣 Считаем всю серую зону фродом 🟣 Каждый кейс модерируем вручную 🟣 Запрашиваем лицензии у организаций и проверяем их всеми доступными способами 🟣 Строим отдельные мониторинги ⏩ Результат: у нас выросли расходы на модерацию и усложнился вход для новых честных организаций. Но фрода в чувствительных точках на карте практически не осталось, а какие-то единичные кейсы сразу же отлавливаются и блокируются. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🔻 Уже завтра встречаемся на OFFZONE! 20–21 августа пройдёт конференция, в центре внимания которой только хард-корный технический контент по кибербезопасности. Приходите послушать наших спикеров: 🟣 Эльдар Заитов, руководитель службы безопасности общих компонент и платформы 📂 «CTF в новой реальности: чему соревнования научили атакующих и защитников» Откроет Main track и расскажет, почему соревнования Capture The Flag всегда были больше чем игрой. А также объяснит, как эволюция и AI меняют не только их, но и всю индустрию информационной безопасности. ⏰ 20 августа, 10:15–11:00 🟣 Кирилл Ваулин, ведущий инженер по ИБ в команде инфраструктуры SOC, и Илья Крестиничев, старший инженер по ИБ в команде операционной безопасности базовой инфраструктуры 📂 «Оркестр агентов SOC: от первых скриптов до мультиагентной платформы» В рамках трека AI.Zone cпикеры покажут, как в SOC работают no-code LLM. А также расскажут, как доверили агентам разбор реальных алертов и прошли путь от простых скриптов до мультиагентной платформы. Кирилл и Илья поделятся подходами к тестированию и оценке качества, покажут метрики, разберут ошибки и сложности, с которыми столкнулись при внедрении. ⏰ 20 августа, 11:55–12:20 🟣 Артём Ольков, тимлид команды безопасности Лавки, и Сергей Лагов, инженер по ИБ в команде Лавки 📂 «Прости, Дейв, но я не могу это сделать: безопасность платформы AI-агентов» Эксперты выступят на треке AppSec.Zone с докладом про безопасность платформы AI-агентов и расскажут про архитектуру защиты в продакшене: IAM, рантайм-контроль, изоляцию, логирование и реагирование. ⏰ 20 августа, 15:15–16:00 🟣 Андрей Воронков, старший инженер по ИБ в команде Search & Geo Security, и Руслан Махмудов, эксперт-исследователь по развитию сервисов анализа защищённости в BI.ZONE 📂 «Chained Together: безопасность композиций агентских скилов» Совместный доклад на треке AI.Zone с нашим коллегой из BI.ZONE. Спикеры разберут подход к безопасному использованию агентских скилов в инфраструктуре компании и покажут, почему проверок отдельных скилов недостаточно без анализа их композиций. ⏰ 20 августа, 17:10–17:35 🟣 Данила Урванцев, инженер по ИБ в команде Городских сервисов 📂 «Поворот не туда: как мы изучали устройство инерциальной навигации» Расскажет на Fast track о практическом опыте аудита и обеспечения безопасности умного устройства для инерциальной навигации. Эксперт рассмотрит архитектурные решения для защиты BLE-команд и OTA-обновлений, а также баланс между безопасностью и функциональностью в реальном продукте. ⏰ 21 августа, 15:30–16:00 💕 До встречи на OFFZONE! Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🧭 От Week Offer до безопасности AI Меня зовут Максим Гусев, я работаю старшим инженером по ИБ в Яндекс 360. Ещё до компании я прошёл путь от стажёра по информационной безопасности до DevSecOps/MLSecOps-инженера и техлида группы автоматизации в ИБ. Занимался внедрением практик безопасной разработки, надёжностью контейнеров и Kubernetes, автоматизацией проверок в CI/CD, а также исследованием угроз для ML- и LLM-систем. В какой-то момент я понял, что хочу работать над задачами другого масштаба: там, где безопасность нельзя добавить к продукту в самом конце, а нужно встраивать в архитектуру и процессы разработки с самого начала. Так я решил попробовать пройти Week Offer Security в Яндекс. Это дало мне возможность найти среду, в которой можно развиваться на пересечении AppSec, DevSecOps и безопасности AI. ♒️ Как проходил Week Offer У меня было три этапа: два основных технических собеседования по веб- и инфраструктурной безопасности, а также общение с руководителями команд для того, чтобы понять, есть ли мэтч. Мы обсуждали мой опыт, разбирали технические ситуации и говорили о том, как я подхожу к поиску и устранению рисков.

🔎 Главное наблюдение: на секциях проверяют не только знание терминов и инструментов, гораздо важнее показать ход мыслей. Например, недостаточно назвать уязвимость — нужно объяснить: 🟣 Как её можно обнаружить 🟣 При каких условиях она эксплуатируется 🟣 К каким последствиям приводит 🟣 Как исправить первопричину 🟣 Как проверить, что защита действительно работает

Для подготовки к Week Offer я бы посоветовал освежить фундаментальные темы по своему направлению и подробно разобрать собственные проекты. Нужно объяснить не только что вы сделали, но и почему выбрали именно такое решение, какие альтернативы рассматривали и с какими ограничениями столкнулись. А ещё очень полезно развивать инженерное мышление: уметь разложить незнакомую систему на компоненты, определить границы доверия, сформулировать угрозы и предложить защиту, эффективность которой можно проверить. ♒️ Чем я занимаюсь сейчас Одно из наиболее интересных для меня направлений — безопасность систем на базе машинного обучения и больших языковых моделей. Классические практики AppSec здесь важны, но их уже недостаточно, ведь в LLM-приложении уязвимость может находиться не только в исходном коде. Источником риска могут стать данные, системный промпт, RAG, подключённые инструменты, модель, инфраструктура и даже документы, которые обрабатывает система. К примеру, если в LLM-агенте, который умеет читать внутренние документы и обращаться к внешним инструментам, содержится prompt injection, модель может воспринять его как инструкцию и попытаться выполнить нежелательное действие. Обычное SAST такую проблему не обнаружит, поэтому нужен MLSecOps — перенос принципов безопасной разработки на весь жизненный цикл ML-системы. Главное — не подключить слишком много сканеров, а построить процесс, в котором результаты проверок помогают разработчикам принимать решения, а не превращаются в бесконечный поток false positive. Поэтому безопасность сегодня — это ещё и автоматизация, корректная приоритизация рисков, измеримые метрики и тесная работа с командами разработки. 🆕 Я стараюсь делиться опытом с профессиональным сообществом: 🟣 Отдельное направление моей деятельности — научные исследования, публикации представлены в профиле 🟣 А более прикладные материалы об автоматизации, DevSecOps, защите инфраструктуры и современных технологиях безопасности можно прочитать в моём профиле на Хабре ⏩ Если вас заинтересовала моя работа, то я хочу поделиться новостью: 12–18 сентября пройдёт Week Offer Security. Сейчас Яндекс ищет инженеров по информационной безопасности с опытом от двух лет. 📆 Регистрируйтесь до 4 сентября на мероприятие, проходите две технические секции и получите офер, если всё пройдёт успешно. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

👾 Yet Another BugBounty Meetup 2026: как это было 17 июля мы вновь собрались на ежегодном митапе для сообщества багхантеров — и это было круто! Спасибо за ваши вопросы, горячие обсуждения и невероятную атмосферу 🔥 Мы поделились традиционными итогами программы «Охота за ошибками» за год, обсудили, как обнаружить XSS в уже всеми проверенной фиче и раскрутку RCE в одном из крупнейших сервисов. А чтобы мозг не закипел — играли в кикер и ловили падающие палочки. Но главное — мы припасли для вас полезные факты из докладов спикеров. 📖 YNDX BugBounty Timeline. Ваня Чалыкин, ведущий инженер по информационной безопасности в Яндексе: 🟣 С 2025 по 2026 год количество входящих отчётов выросло на 17% (с 2290 до 2700) 🟣 Общая сумма выплат выросла на 40% (с 50 млн до 70 млн рублей) 🟣 Число активных багхантеров тоже растёт: за первые 8 месяцев 2026 года их стало 532 (в прошлом было 520) 🛡️ RCE в полной изоляции. Денис Тимошенко, Security Tech Lead в Яндекс 360: 🟣 Иногда фундаментальные фичи безопасности могут быть отключены вендором — не ленитесь проверить состояние сервиса, особенно если он «коробочный» 🟣 Бывает, что фикс может откатиться по тем или иным причинам — задумайтесь об автоматике, которая будет это перепроверять 🔍 Нетривиальные XSS: кто ищет, тот всегда найдёт. Алексей Черняков, инженер по информационной безопасности в Яндекс 360: 🟣 В разных сервисах одна и та же XSS-уязвимость может иметь разный импакт — в сервисе с чувствительными данными она будет гораздо опаснее 🟣 Большое количество санитайзеров не всегда делает лучше: они могут по-разному интерпретировать одни и те же входные данные. Из-за избыточного количества стыков между санитайзерами возникают уязвимости и опасные мутации данных 🟣 В старых сервисах баги находить сложнее (ведь их уже многие проверили), но неприступных платформ не бывает. Упорство и профессионализм приводят к успеху 📷 Ищите себя на фотографиях 💕 Мы были рады с вами увидеться и уже ждём следующей встречи! Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

⚙️ Как с LLM снимают цензуру и что с этим делать У открытых моделей (open-weights) любой может скачать веса — а значит, может и изменить поведение. Один из самых обсуждаемых способов снять отказы называется abliteration. Он не «уговаривает» модель через промпт, а хирургически убирает из неё сам механизм отказа. 👨‍💻 Меня зовут Вадим Ахметов, я ML-инженер в команде платформы данных и аналитики. В прошлый раз я рассказывал, почему одна и та же нейросеть может быть и помощником, и оружием. А сегодня разберу, как из безопасной LLM за пару часов делают модель без цензуры. 🕵️ Читайте подробности в карточках выше

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

Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🔒 24/7 на страже безопасности Меня зовут Андрей Петриков, я руководитель группы обнаружения и реагирования на угрозы в технологической платформы Yandex Cloud. Хочу рассказать, как устроена работа в команде безопасности. ♒️ Наш SOC делится на три команды Одна отвечает за разработку платформы и развитие AI-инструментов в SOC. Другая — за архитектуру клиентского SOC. Третья, которой руковожу я, — Detection and Response. У нас три основные зоны ответственности: 🟣 Дежурный мониторинг 24/7. Наши аналитики следят за всеми потенциальными угрозами 🟣 Разработка контента. Мы создаём правила экспертизы, по которым система решает, что нашему контуру что-то угрожает 🟣 Реагирование на инциденты. Если нам не удалось их предотвратить (иногда такое случается), инженеры восстанавливают безопасность, устраняют последствия и расследуют произошедшее. Потом мы все вместе анализируем, что нужно сделать, чтобы такое больше не повторилось ♒️ Чем необычна наша безопасность Мы отвечаем за часть инфраструктуры пользователей — они неявно отгружают нам часть задач. Например, управление БД. Для клиента это просто база и работа с ней, а для нас — виртуальные машины, диски и другая инфраструктура, которая нужна для того, чтобы всё работало. Для обнаружения атак мы работаем с метаданными, поведенческими признаками и другими абстракциями. Всё это позволяет распознавать аномальную активность, но не раскрывать конфиденциальную информацию. При этом облачные абстракции многослойнее, чем домены, active directory и другие составляющие операционных систем на классических серверах. Мы должны обеспечить безопасность всех уровней одновременно. 〰️ Большинство метрик, которые мы используем, можно считать классикой SOC: время реакции на инцидент, количество тикетов в работе, процент ложноположительных срабатываний и корреляция этих срабатываний с другими событиями. Мы стремимся уменьшать количество ситуаций, которые требуют обращения к пользователю. То есть больше решаем на своей стороне, чтобы меньше отвлекать тех, кого это может затронуть. ♒️ Как мы автоматизируем нашу работу При расследовании инцидента важно как можно быстрее собрать доказательства. Мы стараемся модернизировать этот процесс так, чтобы дежурному достаточно было нажать пару кнопок, вместо того чтобы сохранять всё вручную через консоль. А недавно мы автоматизировали генерацию отчётов для клиентов и отслеживание наших внутренних метрик. Теперь всё самое важное живёт на одном дашборде. Также мы постепенно приручаем AI. Начинали с довольно наивных вещей: обучали простых ассистентов на уже проверенных алертах. С тех пор прокачались: теперь, когда срабатывает сигнал тревоги, нейросеть автоматически ищет похожие события и предсказывает, как стоит реагировать в текущей ситуации. 📖 Читайте больше подробностей в блоге о работе в Яндексе. Там я поделился, как начинал свой путь в компании и как вырос в руководителя группы. А ещё рассказал, каким вижу будущее команды безопасности Yandex Cloud. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🔍 Почему одна и та же нейросеть может быть и помощником, и оружием LLM — это не «умный ответчик», а модель, которая предсказывает следующее слово. Сама по себе она не знает, что можно, а что нельзя. Безопасность — отдельный пласт, который добавляют поверх сырой модели. Если этот слой слабый или его сняли — модель становится уязвимой. 👨‍💻 Меня зовут Вадим Ахметов, я ML-инженер в команде платформы данных и аналитики. Мы делаем ИБ data-driven: превращаем сырые логи и телеметрию в детекты, метрики и модели, на которые опираются наши команды ИБ. Хочу разобрать, как вообще получаются LLM, откуда берётся «небезопасность» и что реально делает модель защищённой. 🕵️ Читайте подробности в карточках выше

«Безопасность LLM — это не галочка, а слоёная защита. Alignment в весах можно ослабить или снять. Поэтому надёжность строится там, где модель применяется: фильтры, мониторинг, ограничение прав и постоянный red teaming».

Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🔒 MCP-сервер как поверхность атаки для AI-агента Всем привет! Это Денис из команды SourceCraft Security. Я уже рассказывал вам про атаки на веб-приложения и эксплойт за 15 минут и один доллар. А сегодня хочу поговорить о том, как злоумышленники могут использовать MCP-серверы в своих целях и что с этим делать. ♒️ Что такое MCP Model context protocol — это «руки» агента, которыми он меняет состояние каких-либо ресурсов: читает логи, добавляет записи в БД, назначает встречи в календаре, вносит изменения в основную ветку репозитория и делает множество действий. Я нашёл множество открытых MCP-серверов в процессе исследования безопасности AI-агентов, о результатах которого недавно рассказал на конференции Saint Highload. Это значит, что при определённых условиях «руки» в интернете доступны любому, кто знает, где их искать. ♒️ Как это выглядит на практике Злоумышленник может попробовать выдать себя за легитимного AI-агента, подключиться к незащищённому MCP-серверу и получить список его доступных инструментов и возможностей. А там, например, есть функция чтения валюты и информация о количестве денег на счёте, что даёт возможность мошеннику реализовать сценарий перевода этих средств на свой кошелёк. ♒️ Что я сделал в процессе исследования Подготовил несложную систему оценки риска, которая строится на сумме баллов за следующие недостатки конфигурации MCP-сервера: 🟣 Нет аутентификации 🟣 Нет поддержки зашифрованного соединения 🟣 Нет CORS-заголовков 🟣 Есть потенциально опасные инструменты (например, exec) 🟣 Есть возможность получения списка инструментов и ресурсов Затем с помощью поискового движка Shodan я получил список открытых MCP-серверов. Для этого собрал 148 поисковых запросов и их комбинаций вроде:

"port:3000 jsonrpc, port:8080 text/event-stream" "Model Context Protocol", "jsonrpc": "2.0" "html:"mcp server"" "\"capabilities tools resources\"" "port:3000 text/event-stream" "\"workers.dev\" mcp" "\"Bad Request: Mcp-Session-Id header is required\"" "\"Not Acceptable: Client must accept text/event-stream\"" "port:7860 \"langflow\" \"mcp\"" "Bad Request: Mcp-Session-Id header is required"

Каждый из этих запросов является возможным паттерном для MCP. В итоге после дедупликации я получил 1699 уникальных серверов. ♒️ Зачем это нужно Такая методика и инструмент фингерпринтинга позволяют проверить доступность своих MCP-ресурсов в Сети. Если они вдруг нашлись в открытом доступе и по разным причинам их невозможно оттуда убрать, у вас есть возможность снизить вероятность атак за счёт правильной аутентификации, TLS и ограниченного списка инструментов. Также AppSec-инженер может добавить оценку риска, который связан с мисконфигурациями, в проверку на этапе CI/CD и правильно настроить MCP. ⏩ Инструмент для поиска MCP-серверов через Shodan я опубликовал в репозитории. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🚘 Как меняется SIEM в эпоху AI SIEM — это не волшебная коробка, ведь просто купить дорогостоящее решение не равно обеспечить безопасность компании 🧐 Мы начинаем седьмой сезон подкаста «Безопасно говоря». В первом эпизоде обсуждаем, какими должны быть современные SIEM и кому они действительно нужны, а также говорим о зрелости процессов ИБ, использовании больших языковых моделей в SOC и о том, как AI меняет работу защитников и действия атакующих. 🎤 Ведущие: 🟣 Алексей Миртов, руководитель группы продуктовой архитектуры Security & Compliance Yandex Cloud 🟣 Мария Кириллова, менеджер продуктов безопасности Yandex Cloud 👨‍💻 Гости: 🟣 Ринат Сагиров, директор Центра мониторинга и реагирования Инфосистемы Джет 🟣 Сергей Бнятов, руководитель SOC ecom.tech 🎧 Слушайте подкаст: 🟣 Ютуб 🟣 VK Видео 🟣 Яндекс Музыка Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

✅ Все модели Alice AI официально безопасны Мы впервые получили международный сертификат ответственной разработки ISO/IEC 42001 для всех генеративных моделей семейства Alice AI — языковой, картиночной и мультимодальной. Аудит проверил все аспекты управления AI в Яндексе: как мы собираем данные для обучения, мониторим безопасность и этичность ответов, обеспечиваем прозрачность разработки и обучаем сотрудников. Проверка подтвердила, что пользователи всех моделей семейства Alice AI защищены, а возможные ошибки и аномалии непрерывно отслеживаются. 🧬 Кроме того, процессы предоставления моделей внешним клиентам на платформе Yandex AI Studio также прошли аудит на соответствие международному стандарту. Напомним, что в 2025 году мы впервые в России получили такой сертификат — тогда проверку проходила только базовая языковая модель YandexGPT. А ещё наша компания является сооснователем и участником Альянса в сфере AI. ⏩ Принципы, которых Яндекс придерживается при разработке и использовании AI, опубликованы на этой странице. 〰️ А свежий отчёт об AI-технологиях в кибербезопасности можно прочитать здесь. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🥤 Кибербезопасность на открытом воздухе 8 августа в Москве в музее-заповеднике «Коломенское» пройдёт ИТ-Пикник. На него пригласили и наших экспертов из команды информационной безопасности: 🟣 Данила Урванцев, инженер по информационной безопасности шеринговых сервисов в Яндексе Выступит с докладом «Как мы защищаем шеринговые сервисы от хакеров и их IoT-амбиций». Он рассмотрит архитектуру шеринговых сервисов компании, составит матрицу рисков и покажет, как выстроить защиту на всех этапах. А ещё разберёт процессы безопасности, инструменты автоматизации и настоящие IoT-уязвимости. 🟣 Александр Каледа, директор департамента информационной безопасности в Яндексе Примет участие в круглом столе «Сценарии будущего ИБ: пророчества vs реальность». Вместе с коллегами он разберёт, какие громкие заявления 5–10-летней давности прошли проверку временем, и попробует сделать собственный прогноз будущего индустрии. ⏩ Регистрируйтесь на ИТ-Пикник и приходите послушать Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🧠 Как AI меняет багбаунти-программы На связи Андрей Романовский, AI Security Engineer в Яндекс Search & Geo. Недавно на Standoff Talks прошёл круглый стол. На нём вместе с коллегами мы обсудили, как AI влияет на программы багбаунти: от работы хакеров и потока отчётов до триажа и экономики. А в этом посте я поделюсь своими ключевыми мыслями. ♒️ Экономика отчётов может сильно измениться Она может сдвинуться в сторону мотивации самих хантеров проверять то, что выдал агент, прежде чем отправлять сгенерированный AI-отчёт. Такие практики уже существуют — например, депозит за отправку репорта, который возвращается при подтверждении находки и сгорает при отклонении. Такой механизм может стать дополнительным фильтром на входе, ведь бесконечный поток непроверенных AI-репортов не приносит пользы ни компании, ни самому исследователю — он просто нагружает команду триажа. ♒️ Внутренняя безопасность должна использовать те же инструменты, что и исследователи Новые AI-подходы и агенты часто провоцируют ситуации, когда хантеры ломают прод сервиса из-за своей неопытности (или неэтичности). Основной способ снижать этот риск — самим активно применять LLM внутри команды безопасности, чтобы быстрее находить и закрывать уязвимости. ♒️ Невалидных отчётов стало больше Хантеры, которые умеют грамотно работать с AI и встраивать его в процесс, начали вылавливать больше ценных находок и уязвимостей. Но вместе с тем выросло число отчётов, которые полностью сгенерированы AI и ничего ценного в себе не несут. Из-за этого у инженеров, которые занимаются триажем, возникает эффект своеобразной «баннерной слепоты»: доверие к отчётам и желание открывать очередной репорт снижается. ♒️ Но AI-инструменты помогают в анализе Внедрять автоматизацию в оценку отчётов нужно очень аккуратно. Если использовать LLM, чтобы просто отметать все сгенерированные репорты, мы рискуем пропустить ценные находки. Поэтому мы используем AI, чтобы улучшить те пререквизиты, с которыми работает специалист по триажу: предварительно просмотреть отчёт, сопоставить с уже разобранными кейсами, помочь со структурированием, предположить, к какому сервису или уязвимому месту относится находка. Финальное решение при этом остаётся за человеком. ♒️ Порог входа для новичков остался прежним Разделение на опытных и неопытных багхантеров существовало всегда. Результат по-прежнему зависит от подхода: понимает ли исследователь инструмент, умеет ли ставить ему корректную задачу и способен ли критически осмыслить то, что модель выдала на выходе. 📺 А полную запись круглого стола смотрите на ютубе. Мы обсудили, как правильно использовать AI-инструменты для развития навыков багхантинга, имеет ли смысл разделение на массовый и экспертный багбаунти и многое другое. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🛎 Приходите на интенсив AI Agents Security Week от ШАДа AI-агенты всё чаще становятся частью продуктов и рабочих процессов: они пишут код, работают с данными и взаимодействуют с внешними сервисами. Чем больше задач мы делегируем ассистентам, тем важнее становится их безопасность и предсказуемость. На онлайн-интенсиве AI Agents Security Week с 27 по 31 июля вместе с экспертами Яндекса разберём, как защищать персональные и корпоративные данные, безопасно выдавать агентам доступ к инструментам и инфраструктуре, предотвращать утечки информации и устранять уязвимости. Вы узнаете: 🟣 Что такое автономные AI-агенты и чем они отличаются от LLM 🟣 Как защищать системы от взломов, утечек данных, ошибок конфигурации и других угроз 🟣 Какие принципы и подходы лежат в основе защиты агентных AI-систем 🟣 С какими проблемами сталкивались разработчики разных AI-моделей Интенсив будет полезен ML-разработчикам, Dev(Sec)Ops-инженерам, техлидам, архитекторам и студентам старших курсов технических вузов — тем, кто хочет глубже понять, как создавать надёжные AI-системы. Для практических заданий пригодятся понимание жизненного цикла разработки ПО (SDL) и опыт вайбкодинга: базовые навыки промпт-инжиниринга и умение запускать получившийся код. 〰️ Формат: пять онлайн-занятий по вечерам с возможностью задать вопросы. Чтобы получить сертификат, нужно пройти отборочное тестирование и выполнить итоговую работу. 📆 Подать заявку можно до 27 июля включительно. ⏩ Зарегистрироваться Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🚀 Погружаемся в технологии на deep tech night 5 сентября пройдёт deep tech night — масштабная онлайн-конференция Яндекса о технологических вызовах, с которыми IT-индустрия сталкивается в эпоху AI: от изменений в разработке до новых требований к архитектуре и инфраструктуре. Это событие для бэкендеров, фронтендеров, тимлидов, аналитиков, продактов и всех, кто работает в IT-индустрии, внедряет AI в процессы, проектирует сложные системы и ищет новые решения. 〰️ В программе доклады экспертов из Яндекса и международных IT-компаний: 🟣 Мо Гавдат, Former Chief Business Officer Google X 🟣 Алексей Гусаков, CTO Поисковых сервисов и ИИ 🟣 Сергей Мельник, руководитель сервиса Автономного транспорта и роботов И другие спикеры (некоторые из них пока что секретные — расскажем о них в ближайшее время 🤫). ⏩ Зарегистрироваться Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🎙 Почему капча больше не про светофоры В новом выпуске подкаста Podlodka Руслан Сабиргалиев, руководитель группы коммерческих проектов Антиробота, рассказал, как эволюционировала капча, зачем боты атакуют сервисы (и сколько это может стоить бизнесу), а также объяснил, что такое невидимые проверки и что делать, когда обычного пользователя система внезапно считает подозрительным. 🧬 Ещё поговорили про хороших ботов, AI-агентов, DDoS, защиту логина, форм, SMS и API. 🎧 Слушайте все подробности в подкасте на ютубе Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🤔 Как защитить нейросеть до того, как её взломают? Мы запускаем Security Explainer — проект о том, как устроена информационная безопасность в Яндексе. Разберём процессы, архитектуру и нетривиальные угрозы: от промпт-инъекций до Threat Hunting. 👾 Первый выпуск — про AI Это направление, где классическая защита не работает, а пользователи сливают в промпты коммерческие тайны и персональные данные. 🎙 Вместе с Андреем Романовским, руководителем команды Search & Geo Security, и Леонидом Морозовым, инженером по информационной безопасности Поисковых сервисов и ИИ, обсудим, как мы ресёрчим новые уязвимости в LLM. А также поговорим о том, почему безопасность модели нужно закладывать ещё до претрейна, а не вешать костылями сверху, и расскажем, как нам удалось запустить сложнейшую систему независимых AI-агентов без единого репорта на багбаунти. ⏩ Смотрите на ютубе и в VK Видео. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

👾 Приглашаем на Yet Another BugBounty Meetup 2026! Это ежегодный митап для сообщества багхантеров — участников и друзей программы «Охота за ошибками». В ней охотники могут найти уязвимость в сервисах Яндекса и получить за это награду — денежный приз и место в Зале славы. На митапе поделимся традиционными итогами программы за год и обсудим, как найти XSS в фиче, которую уже сотню раз проверили. А также расскажем, как раскрутить RCE в одном из крупнейших сервисов (и ещё кое-что секретное). Митап пройдёт в нашем офисе без записи, без трансляции и почти без цензуры. Когда и где: 📆 17 июля (пятница) 📍 Москва (точный адрес сообщим в письме) Количество мест на площадке ограничено, поэтому все заявки проходят модерацию. ⏩ Зарегистрироваться на митап 〰️ Канал «Охоты за ошибками» Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity

🔒 Как устроена защита от ботов в Яндексе Меня зовут Руслан Сабиргалиев, я руковожу группой аналитиков службы доверия и надёжности. В Яндексе есть сервис для защиты сайтов и приложений от DDoS‑, веб‑атак и ботов — Yandex Smart Web Security, который разрабатывают несколько команд. C помощью схемы защиты с reverse proxy можно обезопасить ресурс даже вне контура Yandex Cloud. В качестве базовой технологии защиты от роботов и DDoS‑атак на уровне приложений (L7 модели OSI) в сервисе мы используем SmartProtection‑модуль на базе сервиса «Антиробот», который защищает в том числе и весь Яндекс. Мы делаем фокус на простых инструментах управления и недавно добавили в сервис новую функциональность по работе с роботами — Bot Management. Пользователям облачной платформы она даёт возможность самостоятельно настраивать правила для выделения роботного трафика буквально с помощью пары бегунков. Хочу рассказать, какая инженерная работа стояла за этими, казалось бы, небольшими улучшениями интерфейса. ♒️ Скоринг запроса Мы присваиваем оценки от 0 (человек) до 100 (бот). Модель обучается на разметке weak supervision и CatBoost с монотонными ограничениями — например, чем больше запросов с одного IP, тем выше скорбалл. Для настройки чувствительности у нас есть шкала: 0–20 (человек), 20–40 (вероятно, человек), 40–60 (зона неуверенности), 60–80 (вероятно, бот), 80–100 (бот). 🤖 Верификация полезных роботов Мы вручную верифицировали более 100 роботов по комбинациям User-Agent + IP/подсети, User-Agent + ASN и обратному DNS. И разбили их на 17 категорий. Наши критерии: принадлежность компании, стабильные идентификаторы, региональная специфика, значительность трафика и известность бота. 🔍 Больше полезных сигналов и резюме Мы расширили возможность борьбы с автоматизированным и подозрительным трафиком и добавили ASN (номер автономной системы) и tls‑fingerprint (JA4 и JA3). Это позволило ещё более гранулярно профилировать трафик защищаемого ресурса и управлять им. Также мы научили сервис поставлять дополнительные сигналы в виде логов и заголовков, которыми обогащается запрос, что позволяет использовать наш скоринг в собственных антифрод-движках, расследованиях инцидентов и очистке логов от роботного трафика. ⏩ Читайте больше подробностей в статье на Хабре. Там я поделился тем, как мы вообще пришли к созданию новых механизмов управления трафиком, и рассказал об устройстве weak supervision и практических сценариях использования. Подписывайтесь: 💬 @Yandex4Security 📹 @YandexForSecurity