Вакансия на удалёнке.
В дейтинг-приложение Twinby требуется Лид информационной безопасности.
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 по целям и направлению.
- Формат: удалёнка, РФ.