Лид информационной безопасности (Security Lead)

О роли

Twinby — один из крупнейших российских дейтинг-сервисов с миллионами пользователей: реалтайм (лента, матчи, чаты), деньги (подписки, покупки), антифрод и модерация. Под защитой здесь самое чувствительное — персональные данные, переписки, геолокация, фото — и при этом живые деньги. Мы перестраиваем инженерную систему Twinby CIS и хотим встроить безопасность внутрь разработки, а не поставить её сбоку как «отдел запретов».

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

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

За что ты отвечаешь

• Функция безопасности продукта целиком: не «закрывать тикеты аудита», а поставить безопасность как свойство инженерной системы — от дизайн-ревью до продакшена. Ты решаешь, как она устроена, и отвечаешь за результат.

• SSDLC в гейтах и пайплайнах: secret-scanning, SAST/DAST/SCA в CI, контроль зависимостей, security-design-review на новых фичах — встроить так, чтобы разработка это приняла и не обходила, а не устраивать разовую проверку перед релизом.

• Incident response как процесс, которым командуешь ты: contain → оценка масштаба по логам → локализация корня → нотификация по требованиям (в т.ч. 152-ФЗ) → постмортем без поиска виноватого → системная починка, чтобы это не повторилось. Ты — тот, кто ведёт инцидент, а не тот, кому его эскалируют.

• Управление секретами и доступами: секрет-менеджер вместо секретов в коде, короткоживущие токены, ротация, least privilege, аудит доступа — как поставленная дисциплина, а не разовая уборка.

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

• Защита персональных данных в контуре продукта (152-ФЗ как стандартное требование) и смежность с антифродом — боты, скам, фрод-аккаунты: ежедневная боль дейтинга, где безопасность и доверие пользователя пересекаются.

• Рост людей и влияние без формальной власти: растишь security-чемпионов в командах, которые тебе не подчиняются, и добиваешься стандарта аргументом, а не «блокирую всё». Ты держишь общий язык с тимлидами продуктовых команд, архитектором и CTO.

Что мы ждём

• Реальная security-глубина, а не бумага: ты читаешь чужой код ради уязвимостей и видишь конкретную дыру (IDOR, SSRF, логика авторизации, обход 2FA, проблемы с JWT/токенами, race в платеже), а не пересказываешь чеклист. Threat modeling — вживую, дерево атак на реальную фичу, а не квадратики из шаблона.

• Ты ставил функцию, а не только находил баги: поднимал security-функцию с нуля или радикально перестраивал — SSDLC, incident response, secret-management, ротацию — с измеримым результатом. Это ключевое отличие от роли инженера-одиночки.

• Ты командовал инцидентом сам: вёл разбор серьёзной уязвимости или инцидента (утечка секрета/доступа) — локализовал, оценил масштаб, починил корень, написал постмортем, а не передал в чужие руки.

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

• Trade-off с оговорками, а не абсолюты: когда блокировать релиз из-за риска, а когда отпустить с управляемой митигацией; когда WAF — пластырь, а когда разумная мера. Решаешь по связке риск × эксплуатируемость × стоимость фикса — и умеешь договориться, а не воевать с командами.

• Уровень — сильный лид с самостоятельной поверхностью ответственности и горизонтом на 1–2 года и дальше.

Будет плюсом

• Следы реальной эксплуатации: bug-bounty-профиль (Standoff / HackerOne / BugCrowd), публичные CVE, write-up'ы, CTF, доклады на профильных конференциях (OFFZONE / PHDays / ZeroNights), контриб в security-tooling.

• Опыт постановки культуры security-чемпионов и SSDLC с нуля в компании с несколькими командами.

• Опыт с высоконагруженным реалтайм-продуктом и защитой платежей/подписок.

• Близкий бэкграунд (AppSec/Product Security, offensive/redteam, пентест, DFIR, антифрод) — сильный плюс, не требование.

Чего НЕ требуем

Стены сертификатов (CISSP/CEH) самих по себе, заученных определений OWASP/STRIDE наизусть, знания именно нашего набора ИБ-инструментов. Нам важнее, что ты умеешь и ломать, и чинить по-настоящему, ставить процесс и вести за собой людей; конкретный тулинг подберём под наш стек вместе.

Технический стек

Бэкенд — Python/Django (монолит) и сервисы, основное хранилище — PostgreSQL. Безопасность встраивается в CI и merge-gate: secret-scanning, SAST/DAST/SCA, управление секретами и аудит доступа. Контейнеризация, российское облако. Конкретный ИБ-тулинг подберём под стек вместе.

Что предлагаем

• Мандат построить функцию безопасности с нуля: ты задаёшь, как устроена безопасность на продукте с миллионами пользователей, пока нормы ещё не застыли, — а не наследуешь чужие политики и тикеты аудита.

• Реальная поверхность атаки: настоящие ПДн и деньги под защитой, реалтайм и масштаб — задача, которая не прощает поверхностного мышления.

• Рост команды безопасности: ты растишь security-чемпионов по всему продукту и, со временем, собственную команду, а не закрываешь баги в одиночку.

• Настоящая инженерная система, а не лозунги: замкнутый цикл доставки, merge-gate, incident response и постмортемы без вины как часть процесса.

• Высокая автономия и прямой контакт с архитектором и CTO по целям и направлению.

• Формат: удалёнка, РФ.