О роли
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 по целям и направлению.
-
Формат: удалёнка, РФ.
