Привет! Я Никита, инженер-инсталлятор в Selectel. Представьте ситуацию: вы нашли уязвимость и понимаете, что ее можно воспроизвести. Цель — помочь владельцу сервиса закрыть дыру быстро и безопасно. Но до контакта важно остановиться и взвешенно проанализировать собственные действия. Чтобы вам было чуть проще сориентироваться «на месте», собрали ключевые советы и рекомендации в этом тексте. 

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

Важно держать в голове и юридическую сторону вопроса — никаких ультиматумов в духе «заплатите или опубликую». Разговор о вознаграждении уместен только в рамках политики раскрытия владельца или багбаунти. Если PoC может навредить системе — остановитесь, зафиксируйте результат и переходите к уведомлению владельца.

Ранее мы рассказывали, как появилась практика багбаунти. Внутри — история развития и подробности о том, как она работает сегодня.

Мы в Selectel поддерживаем подобные инициативы и запустили спецпроект OpenFix, благодаря которому можно получить вознаграждение за найденные баги, рефакторинг и пакетизацию. После публикации решения пакет будет распространяться как open source по пермиссивной лицензии. А значит, все права останутся у вас.

Вкратце о вредных и полезных советах

✅ DO — что делать

• Покажите факт, а не эффект. HTTP-кода, отличия в заголовках, контролируемого ответа сервера — достаточно, если это однозначно демонстрирует проблему.

• Используйте тестовый аккаунт или воспроизводимую среду, если возможно.

• Делайте один запрос или короткую цепочку действий, которая повторима и не наносит вреда.

• Логируйте время с таймзоной, точные запросы, версии клиента и сервера, скриншоты и контрольные суммы артефактов — это заменяет громоздкий PoC.

• Если нужны данные — создайте синтетические (фиктивные) записи, не работайте с реальной PII/платежами.

• Перед любыми «рисковыми» проверками предупредите команду и согласуйте канал/время, если это допустимо.

❌ DON’T — чего не делать

• Не извлекайте реальные пользовательские данные, не скачивайте чужие документы, не просматривайте платежные транзакции.

• Не запускайте массовые/агрессивные сканирования и не повышайте нагрузку (DoS-паттерны).

• Не пытайтесь получить доступ в привилегированные зоны для «доказательства», даже ради проверки.

• Не оставляйте креды/токены/ключи в PoC или в черновиках отчета, а также в логах, Git-репозиториях, скриншотах и буферах обмена.

Несколько безопасных альтернатив. Воспроизведите баг локально на зеркале/контейнере или попросите тестовый доступ у владельца. Если невозможно — опишите поведение подробно и запросите согласование канала для полнофункционального PoC.

Как готовить отчет, который воспроизведут с первого раза

Отчет должен быть полезным, а не эффектным — разрушать инфраструктуру не нужно. Дайте специалистам «кнопки», на которые можно сразу нажать.

1. Краткое описание: что именно сломано и к каким последствиям это ведет.

2. Оценка влияния: аккуратно, без драматизации — какие компоненты под угрозой, какие данные рискуют быть затронуты.

3. Описание среды: домен, роль пользователя, важные HTTP-заголовки, версии ПО и конфигурационные параметры, которые имеют значение.

4. Шаги воспроизведения: последовательные, детальные шаги (стандартных утилит должно быть достаточно), минимальный PoC — один запрос или короткая цепочка действий, которая надежно показывает проблему и не ломает систему.

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

6. Рекомендации по фиксу: где добавить проверку, какие права сузить, что вынести в конфигурацию. Это не учебник, а вектор движения.

7. Таймлайн и контакты: когда проблема замечена, когда готовы передать детали. Укажите контакт и способ шифрования при необходимости.

Несколько советов по тону и точности: 

• избегайте эмоциональных слов в описании влияния — факты и конкретика важнее;

• минимизируйте PoC, ведь ваша цель — доказать наличие уязвимости, а не эксплуатировать ее;

• заранее проверьте применимое законодательство и политику безопасного раскрытия у владельца сервиса (если сомневаетесь — укажите, что вы можете приступить к раскрытию только после согласования).

Security Center

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

Исследовать →

Первый контакт и безопасная передача деталей

Начинайте с официальных каналов. У компании может быть электронный адрес команды ИБ, страница с политикой ответственного раскрытия или файл в духе /.well-known/security.txt, где указаны контакты и ключи. Если ничего не нашли — напишите на общий адрес и попросите передать сообщение команде информационной безопасности. 

Стиль письма — спокойный, с ориентиром на пользу. В теме укажите «Возможная уязвимос��ь: <домен/сервис>». В теле кратко опишите, что обнаружили, какой риск видите, и предложите удобный и безопасный способ для передачи деталей. 

Подробности (полный отчет и PoC) отправляйте только после согласования канала передачи. Если у компании есть публичный ключ — шифруйте архив (PGP/S/MIME). При наличии защищенной формы для инцидентов — используйте ее. 

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

Рабочий процесс, сроки, коммуникации и эскалация

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

Несколько наблюдений из практики

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

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

Поделитесь своим опытом взаимодействия с командами безопасности — какие сроки реакции встречались чаще всего? Были ли случаи особенно быстрого или, наоборот, затянутого ответа?

Если команда демонстрирует прогресс — корректируйте сроки совместно. При отсутствии реакции — одно напоминание → альтернативный канал (security.txt / форма) → контакты из публичных источников → эскалация в отраслевые CERT или центры реагирования. Если впервые слышите эти термины, объясним чуть ниже. 

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

Что за CERT и центры реагирования

RU-CERT — центр реагирования на компьютерные инциденты (АНО «ЦРКИ»). 

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

Как обращаться: есть почта и контакты на сайте, можно приложить минимальный PoC и предложить защищенный канал для передачи деталей. 

Что включать в минимальный PoC? Опишите тип уязвимости, затронутые компоненты и общую логику атаки, но не включайте рабочий код эксплуатации, конкретные payload или автоматизированные скрипты. Например, для SQL-инъекции достаточно указать уязвимый параметр и показать, что он позволяет выполнить запрос, однако не нужно прикладывать полный дамп базы данных. Полный PoC с эксплуатационным кодом передавайте только после согласования защищенного канала связи.

НКЦКИ — национальный координационный центр по компьютерным инцидентам, составная часть сил Государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы РФ (ГосСОПКА).

Когда подходит: критические/государственные ресурсы, объекты КИИ или случаи, требующие национальной координации. Поскольку НКЦКИ является частью ГосСОПКА, обращение сюда автоматически включает взаимодействие в рамках государственной системы. 

Как обращаться: на сайте есть форма и почта для уведомлений об инцидентах. При отправке укажите время с таймзоной, краткий PoC и просьбу о защищенном канале.

ФСТЭК России — регулятор по защите информации. Актуален для инцидентов, где важно соответствие нормативным требованиям (ПДн, КИИ). ФСТЭК разрабатывает методики по категорированию объектов, оценке угроз и требованиям к защите информации. При оформлении отчетов учитывайте эти методики: структурируйте описание уязвимости согласно классификации угроз, указывайте потенциальное влияние на защищаемые активы и соответствие (или нарушение) действующим требованиям.  

Коммерческие SOC/JSOC (например, Solar JSOC от «Ростелеком-Солар») — подходят для оперативного платного отклика, когда требуется профессиональное расследование и сопровождение инцидента в коммерческой инфраструктуре. Взаимодействие обычно требует заключения договоров на оказание услуг и подписания NDA для защиты конфиденциальной информации.

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

Финальная стадия, фиксация, публикация и кредиты

Когда уязвимость закрыта, запросите подтверждение, что исправления развернуты в продуктиве, и уточните критерий «завершено». Согласуйте дату и формат публикации. Публикация должна фокусироваться на пути исследования, минимальном PoC и уроках — без приватных данных и реальных ключей. Спокойная техническая история воспринимается лучше, чем драматичный рассказ.

Если у компании есть страница благодарностей — заранее пришлите корректное написание ника и ссылку. Вопросы вознаграждения решаются по правилам программы (если она есть). Частые ошибки: преждевременная публикация, спор о сумме вне правил программы и случайно оставленные токены в тексте — поэтому финальную проверку делайте внимательной.

Не торопитесь закрывать канал: после деплоя фикса или при повторном аудите часто появляются уточняющие вопросы, замечания к описанию или необходимость пересборки заметки и проведения post-mortem. Оставьте в отчете контакт для связи и укажите, в течение какого срока вы готовы отвечать (например, 7–14 дней). Это упростит закрытие оставшихся вопросов.

Особые частые случаи

С открытыми проектами удобно работать через приватные тикеты или прямой контакт мейнтейнеров. Полезно подготовить короткий pull request с исправлением и тестом — даже черновой вариант ускорит верификацию. С облачными платформами процессы обычно чуть более формализованы: страницы безопасности, формы и SLA. В финтехе и медицине сразу предлагайте шифрованный канал и точные формулировки — в этих сферах особенно ценят аккуратность и понятные рамки.

Заключение

Ответственное раскрытие работает, когда процесс остается простым и уважительным. Достаточно минимального PoC, я��ных шагов воспроизведения и спокойного тона. Приоритеты такие: сначала безопасность пользователей, затем — скорость фикса и лишь далее — публикация. Если держать эту последовательность и не усложнять, уязвимость закрывается быстрее, команда на той стороне охотнее благодарит, а итоговая заметка выходит полезной и для них, и для сообщества.

Прозрачность процесса выгодна всем: владелец сервиса получает предсказуемый сценарий устранения угрозы без паники и утечек, а исследователь минимизирует юридические риски и укрепляет профессиональную репутацию. Четкие договоренности о сроках и каналах коммуникации защищают обе стороны от недопонимания и потенциальных конфликтов — это основа доверия между security-сообществом и бизнесом.

Присоединяйтесь к OpenFix — проекту от Selectel для тех, кто хочет делать open source безопаснее, чище и надежнее. Выберите задачу, отправьте заявку и определите комфортный ритм решения. За выполнение работ получите гарантированную оплату.

Участвовали в багбаунти или отправляли репорты об уязвимостях?

Поделитесь опытом, что помогло быстрее наладить контакт с вендором, а что создавало лишние барьеры. Живые истории из практики помогут дополнить шпаргалку реальными кейсами!