Security Engineer

Кто это и зачем нужен

Security Engineer защищает продукт, данные и пользователей, чтобы мощь инструментов не обернулась дорогой ошибкой. Его миссия — встроить безопасность в продукт, а не «прикрутить потом»: моделировать угрозы, находить уязвимости до злоумышленника, защищать секреты и данные, держать соответствие требованиям (в РФ — 152-ФЗ о персональных данных и др.). Он мыслит как атакующий, чтобы защищать как инженер.

Боль, которую он закрывает: одна утечка/инъекция = деньги, репутация, юридические последствия. Особенно в эпоху ИИ и вайб-кодинга: код генерится быстро, и небезопасный паттерн так же быстро уезжает в прод. Security Engineer ставит барьер.

Что ломается без него: уязвимости (SQL-инъекции, XSS, IDOR), секреты в коде/логах, утечки персональных данных, отсутствие модели угроз, несоответствие 152-ФЗ, инциденты безопасности без плана реагирования.

День из жизни

Утро. Прогоняет свежие PR через security-взгляд: валидация входа, обработка секретов, права доступа, опасные паттерны. Смотрит алерты сканеров (SAST/зависимости). День. Делает threat model на новую фичу («что может пойти не так, как атакуют, что защищаем»), ревью архитектуры на безопасность, проверяет управление секретами. Консультирует инженеров по безопасной реализации. Вечер. Обновляет чек-лист безопасности и политики доступа, проверяет соответствие (152-ФЗ: какие ПДн, где хранятся, как защищены), фиксирует найденное и план устранения.

Ключевые навыки

Hard: OWASP Top 10 и веб-уязвимости, моделирование угроз (STRIDE), управление секретами, криптография (на уровне применения), auth/authz, SAST/DAST/SCA-инструменты, безопасность данных и приватность (152-ФЗ/GDPR), сетевая безопасность, разбор инцидентов. Soft: мышление атакующего («как сломать»), параноидальная аккуратность, способность объяснять риск бизнес-языком (цена ошибки), баланс безопасность/удобство, коммуникация в инциденте.

Артефакты, которые пишет

• Threat model — угрозы, векторы, меры (STRIDE).
• Отчёт security review — найденные уязвимости + критичность.
• Чек-лист безопасности — что проверять перед релизом.
• Политики доступа — кто к чему, принцип наименьших прав. Работает поверх кода Backend/Frontend; готовность по безопасности — часть Definition of Done; связан с разделом «🛡 Безопасность» базы знаний.

Как ИИ/вайб-кодинг усиливает роль

1. Поиск уязвимостей в диффе. Промт: «Проверь этот дифф <вставить> на уязвимости OWASP: инъекции (SQL/команд), XSS, IDOR/нарушение авторизации, небезопасная десериализация, утечка данных в ответ/логи. Отметь критичность каждой.»
2. Threat model. Промт: «Сделай threat model по STRIDE для фичи <…>: активы, угрозы (Spoofing/Tampering/Repudiation/Info disclosure/DoS/Elevation), векторы и меры защиты.»
3. Проверка секретов. Промт: «Найди в этом коде/конфиге <…> захардкоженные секреты, токены, ключи и небезопасную работу с ними. Как вынести в окружение/секрет-менеджер.»
4. Проверка валидации/авторизации. Промт: «Проверь эндпоинт <…>: валидируется ли вход, проверяются ли права на объект (не только аутентификация), нет ли массового присваивания.»
5. Соответствие 152-ФЗ. Промт: «По фиче <…> определи, какие персональные данные обрабатываются, и составь чек-лист требований 152-ФЗ: согласие, минимизация, хранение, защита, права субъекта.»

Путь развития: Junior → Middle → Senior → Lead

• Junior (AppSec): прогоняет сканеры, помогает с ревью по чек-листу, разбирает типовые уязвимости.
• Middle: самостоятельно делает threat model и security review, ведёт управление секретами, консультирует команды.
• Senior: проектирует безопасность архитектуры, ведёт инциденты, выстраивает SDLC-практики безопасности, наставляет.
• Lead / Head of Security (CISO-трек): отвечает за безопасность на компанию, политики, соответствие, рост команды.

Частые ошибки и как избежать

• Безопасность «потом». → Встраивай в дизайн и ревью с самого начала (shift-left), а не перед релизом.
• Только аутентификация, забыли авторизацию. → Проверяй права на конкретный объект (IDOR — частая дыра).
• Секреты в коде/репозитории. → Только в окружении/секрет-менеджере; сканируй на утечки.
• Доверие клиенту. → Вся валидация и проверки прав — на сервере; клиента можно подделать.
• Параноя без приоритета. → Ранжируй риски по критичности и вероятности; защищай в первую очередь ценное.

Что освоить (мини-программа)

• Концепции: OWASP Top 10, STRIDE, принцип наименьших привилегий, defense in depth, управление секретами, приватность (152-ФЗ/GDPR), secure SDLC.
• Инструменты: SAST/DAST (Semgrep, ZAP), SCA (Snyk/Dependabot), секрет-сканеры (gitleaks), Burp Suite, секрет-менеджеры (Vault).
• Почитать: OWASP (Top 10, ASVS, Cheat Sheets); «The Web Application Hacker’s Handbook»; PortSwigger Web Security Academy (бесплатно).

Зарплатные ориентиры (RU)

• Junior Security/AppSec: ~120–190 тыс ₽/мес.
• Middle Security Engineer: ~190–330 тыс ₽/мес.
• Senior Security Engineer: ~330–550+ тыс ₽/мес.

  Дефицитная роль, оплата выше среднего; зависит от грейда, специализации, города и года — проверяй актуальное.

Маппинг на агента Laskoff

Прямой mapsTo: security. В Quest агент security обязателен на risky/multi-file шагах: ищет уязвимости и небезопасные паттерны в диффе, проверяет обработку секретов и валидацию входа, делает черновик threat model. Дополнительно дом защищён детерминированным hooks/guard-dangerous.sh (блокирует опасные команды) и правилом «.git//.claude/ в обход не трогать». Раздел «🛡 Безопасность» базы — справочник практик.

🤖 Промт-персона

Ты — опытный Security Engineer, мыслишь как атакующий, чтобы защищать как инженер. Помогаешь мне встраивать безопасность в продукт, а не прикручивать потом. Любой код проверяй по OWASP: инъекции, XSS, IDOR/авторизация на объект (не только аутентификация), утечки данных в ответ/логи, небезопасные секреты. Всю валидацию и проверки прав требуй на сервере — клиенту не доверяй. По фичам делай threat model (STRIDE) и для персональных данных — чек-лист 152-ФЗ. Риски ранжируй по критичности и вероятности, объясняй их бизнес-языком (цена ошибки). Секреты — только в окружении/секрет-менеджере.