Статья Как перейти в AppSec из разработки: план на 2025

Три года назад я писал эндпоинты на Django REST Framework и не задумывался, что request.data['user_id'] без проверки авторизации - готовая BOLA-уязвимость (API1:2023). Просто брал user_id из запроса и шёл в базу. Работает? Работает. А то, что любой авторизованный пользователь может подставить чужой id и вытянуть чужие данные - ну, об этом думать было некогда, спринт горит.

Сейчас я провожу security code review тех же паттернов и пишу кастомные правила Semgrep, которые ловят подобные баги до мержа. Переход в AppSec из Python-разработки занял полтора года - и первые полгода ушли на ошибки в приоритизации. Эта статья - roadmap, который я хотел бы получить на старте.

Что делает AppSec-инженер каждый день​

Если представлять AppSec-инженера как человека, который целый день ломает приложения, - картинка неполная. По данным BSG, типичная неделя выглядит прозаичнее: четверть времени - code review и triage находок сканеров (и половина из них - false positive, которые надо закрыть с комментарием "не баг"). Около 20% - threat modeling и design review новых фич, ещё 20% - автоматизация security-проверок в CI/CD. Остальное - обучение разработчиков, разбор инцидентов и координация с другими командами.

Для разработчика тут главное: большая часть работы AppSec - чтение чужого кода, написание автоматизации и разговоры с командой на её языке. AppSec-инженер сидит в тех же репозиториях и пайплайнах, что и вы. Разница - в оптике: вместо "как это работает?" вы спрашиваете "как это ломается?".

По классификации MITRE ATT&CK, типичные угрозы на уровне кода: Exploit Public-Facing Application (T1190, Initial Access), Credentials In Files (T1552.001, Credential Access), Compromise Software Dependencies (T1195.001, Initial Access). Звучит академично, но по сути - это "забыли закрыть эндпоинт", "захардкодили пароль от базы в settings.py" и "подтянули троянизированный пакет из PyPI". Знание этих техник не требует пентест-опыта - достаточно понимать, как данные текут через ваш Django-проект.

Почему Python-разработчик - сильный кандидат в AppSec​

Три года бэкенда на Flask или Django закрывают критичную часть требований к AppSec-позиции. Вы читаете код, понимаете REST API, знаете устройство ORM-запросов, аутентификацию через JWT/OAuth2 и взаимодействие микросервисов. Именно это отделяет эффективного AppSec-инженера от человека со сканером и без контекста.

Вот типичная ситуация: SAST-сканер находит потенциальную SQL-инъекцию (A03:2021) в ORM-запросе. Разработчик-в-AppSec сразу видит - это raw() с пользовательским вводом или ложное срабатывание на параметризованный queryset. Специалист без опыта в коде потратит час на верификацию того, что вы оцените за минуту. И это не фигура речи - разбор false positive съедает до трети рабочего времени. Если вы можете отсеивать мусор быстрее, вы уже ценнее.

Согласно OWASP SAMM (Software Assurance Maturity Model), эффективная программа безопасности строится на интеграции в существующие процессы разработки. Shift-left security работает, когда AppSec-инженер говорит на одном языке с командой. Ваш бэкграунд - конкурентное преимущество, не пробел в резюме.

Secure SDLC: пошаговый план перехода за 9-12 месяцев​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

DAST - OWASP ZAP. Базовый скан через docker run owasp/zap2docker-stable zap-baseline.py -t http://your-app:8080. Научитесь отличать false positive от реальных находок в отчёте - это спрашивают на собеседованиях, причём не в теории, а "вот отчёт ZAP, покажите что тут настоящее".

SCA - Trivy, Snyk или OWASP Dependency-Check для проверки requirements.txt. Это закрывает риски Supply Chain-атак (Compromise Software Dependencies and Development Tools, T1195.001 по MITRE ATT&CK). На одном проекте Trivy нашёл критическую CVE в cryptography==3.4.6 - пакет стоял в requirements полтора года и никого не беспокоил.

К концу шестого месяца у вас рабочий пайплайн с тремя типами проверок - строчка в резюме и артефакт для портфолио.

Месяцы 7-12: специализация и портфолио​

Переход от "нахожу баги" к "проектирую безопасную архитектуру".

Threat modeling по STRIDE - возьмите архитектуру знакомого микросервиса. Для каждого компонента шесть вопросов: Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege. Задокументируйте - это артефакт для портфолио, который показывает системное мышление. На собеседованиях threat model ценится выше, чем очередной write-up по HTB.

Security code review - ревьюйте PR коллег с фокусом на безопасность. Ищите не только инъекции: утечку секретов в логах (T1552.001), обход авторизации, небезопасную десериализацию (Insecure Design, A04:2021). Первые ревью будут неловкими - это нормально. Через месяц глаз начинает цепляться за pickle.loads() автоматически.

Bug bounty - зарегистрируйтесь на Standoff 365 для российского рынка. Даже одна подтверждённая находка низкой критичности - доказательство практического навыка для собеседования.

Навыки для AppSec инженера: что просят и что реально нужно​

Типичная вакансия "AppSec-инженер" на hh.ru содержит 15+ пунктов. На техническом интервью для кандидата из разработки акцент другой.

Hard skills, которые реально спрашивают:

• Найти и объяснить уязвимость во фрагменте кода - руками, не сканером
• Интеграция хотя бы одного security-инструмента в CI/CD
• Базовый Burp Suite - перехватить запрос, поменять параметр, повторить
• OAuth2 / JWT - не "знаю что это", а "где тут BOLA или Broken Authentication"
• OWASP Top 10 с примерами из реального кода, а не пересказ определений

Soft skills, которые недооценивают. По данным Wiz, AppSec - командная работа. Главный навык - объяснить разработчику, почему его код небезопасен, так чтобы он воспринял это как помощь, а не наезд. Вы были разработчиком - знаете как выглядит тикет "fix this vulnerability" без контекста и reproduction path. Пустой тикет без примера запроса и ожидаемого поведения - это раздражение и откладывание "на потом". Используйте это знание.

Зарплатные ориентиры. На американском рынке, по данным BSG и Indeed, вилка для AppSec-инженеров - $138 000-$163 000 в год, senior-роли от $200 000. Российский рынок отличается существенно - актуальные цифры стоит проверять на hh.ru и Habr Career по запросам "AppSec-инженер" и "инженер по безопасности приложений". Грейд, локация (Москва vs регионы) и формат работы сильно влияют на итоговый оффер.

Сертификации: что котируется при переходе в AppSec​

Не все сертификации одинаково полезны для разработчика. Приоритизированный список:

1. BSCP (Burp Suite Certified Practitioner) - практическая, доступная, проверяет навык поиска веб-уязвимостей. Оптимальная первая сертификация. Подготовка - 1-2 месяца, если уже прошли лабы PortSwigger.
2. OSCP (Offensive Security Certified Professional) - золотой стандарт. 24-часовой практический экзамен, подготовка 3-6 месяцев. Кандидаты с опытом разработки проходят быстрее за счёт навыков скриптинга (писать эксплойт на Python - это то, что вы уже умеете).
3. CompTIA Security+ - "входная" сертификация для прохождения HR-фильтра. Не заменяет практику, но решает формальную задачу.
4. CSSLP - для ролей, связанных с Secure SDLC и governance.

Бесплатные ресурсы сопоставимой глубины: PortSwigger Web Security Academy, OWASP Web Security Testing Guide (WSTG), Hack The Box.

Где искать первую AppSec-позицию​

Внутренний перевод - если в компании есть ИБ-отдел. Предложите помощь с security code review или интеграцией SAST в пайплайн. Руководители ИБ охотно берут разработчика, который знает кодовую базу. Вы пропускаете этап "докажи что умеешь читать код" - это самый быстрый путь. На практике: я начал с того, что просто стал добавлять security-комментарии в PR коллег. Через два месяца меня позвали на встречу ИБ-отдела.

Внешний найм - ищите "AppSec-инженер", "инженер по безопасности приложений", "DevSecOps-инженер" на hh.ru и Habr Career. Многие компании рассматривают кандидатов с опытом разработки и базовыми знаниями безопасности - формальные "3 года AppSec-опыта" не всегда обязательны.

Портфолио для собеседования:

• GitHub с кастомными правилами Semgrep под Python
• CI/CD-пайплайн с SAST/DAST/SCA
• Подтверждённые находки на bug bounty
• Документ с threat model для pet-проекта

Это артефакты, которые показывают: вы не просто прочитали книгу - вы сделали руками.

Три года в разработке дали мне одно преимущество, которого я не ожидал: я знаю, как выглядит плохой security-отчёт глазами того, кто его получает. Половина AppSec-инженеров без бэкграунда в разработке пишет "Critical: SQL Injection found" - и на этом всё. Разработчик смотрит и не понимает: это в ORM или в raw-запросе? На продакшн-эндпоинте или на внутреннем healthcheck? Какой приоритет фикса относительно текущего спринта?

Когда вы были по ту сторону, вы автоматически делаете отчёты с контекстом, reproduction path и конкретной рекомендацией. Это главный актив разработчика в AppSec - не знание OWASP Top 10, а способность превратить находку в понятную задачу.

Большинство roadmap'ов по переходу в AppSec из разработки фокусируются на технических навыках - Burp Suite, OSCP, threat modeling. Всё это нужно. Но самая частая причина, по которой разработчики буксуют после перехода, - неумение позиционировать свой опыт. На собеседовании говорят "я три года писал бэкенд на Django" как извинение, а не как ответ на вопрос "почему мы должны вас взять". Ваш опыт - это ровно то, ради чего нанимают. IB Basics для тех, кто перешёл из IT в ИБ и нужна структура за пару месяцев - codeby.academy/landings/ib-fundamentals/.