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

Вакансия: Лид информационной безопасности (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 по целям и направлению.

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