Безопасность нельзя «добавить» перед релизом. Secure SDLC встраивает её в каждый этап разработки так, чтобы большинство проблем ловились рано и дёшево, а команда безопасности не была узким местом. На собесе AppSec-инженера это центральная тема: как вы построите процесс.
Этапы и практики
| Этап | Практики |
|---|---|
| Требования | Требования безопасности (например по ASVS), классификация данных, регуляторика |
| Проектирование | Моделирование угроз, ревью архитектуры, безопасные шаблоны |
| Разработка | Безопасные библиотеки и фреймворки, обучение, линтеры, pre-commit со сканером секретов |
| Сборка | SAST, SCA, сканирование секретов и образов, SBOM |
| Тестирование | DAST, тесты безопасности, ручное ревью критичного кода |
| Релиз и эксплуатация | Конфигурация, мониторинг, реагирование, пентест, баг-баунти |
Принцип shift left: чем раньше найдена проблема, тем дешевле её исправить. Но «левее» не значит «только слева»: в проде всё равно нужны мониторинг и внешняя проверка.
Инструменты
- SAST (статический анализ): ищет уязвимые паттерны и потоки данных в исходниках без запуска. Semgrep, CodeQL, SonarQube, PT Application Inspector, Solar appScreener. Плюс: рано и на весь код. Минус: ложные срабатывания, не видит конфигурацию и бизнес-логику.
- DAST (динамический анализ): атакует работающее приложение снаружи. OWASP ZAP, Burp Suite, Nuclei. Видит реальное поведение и конфигурацию, но покрывает только то, до чего дотянулся, и не показывает строку кода.
- IAST: агент внутри приложения во время тестов связывает запрос и строку кода.
- SCA: уязвимые и вредоносные зависимости, лицензии.
- Сканеры секретов, IaC и контейнеров: gitleaks, Checkov, Trivy.
Никакой сканер не находит авторизационные ошибки и логику бизнеса хорошо: для этого нужны люди, моделирование угроз и тесты доступа.
Как внедрять, чтобы не возненавидели
- Начать с малого числа правил с высокой точностью и блокировать сборку только по ним. Остальное в отчёт.
- Новые находки блокируют, старые в бэклог (baseline), иначе тысяча старых проблем остановит всех.
- Находки приходят туда, где работают разработчики: комментарий в PR, а не PDF раз в квартал.
- Сроки исправления (SLA) по критичности, например critical 7 дней, high 30, medium 90. Исключения оформляются с причиной и сроком.
- Security champions: разработчик в каждой команде с интересом к безопасности, первая линия вопросов и ревью.
- Безопасные дефолты в шаблонах сервисов и общих библиотеках работают лучше обучения.
- Метрики: время исправления, доля сервисов в SLA, повторяемость классов уязвимостей.
Оценка серьёзности
CVSS (версии 3.1 и 4.0) даёт базовую оценку от 0 до 10 по вектору: вектор атаки, сложность, нужные привилегии, участие пользователя, влияние на конфиденциальность, целостность, доступность. Для своих находок важнее риск в контексте: доступность снаружи, данные, компенсирующие меры.
Пентест
Пентест это ограниченная по времени проверка специалистами с попыткой эксплуатации. Важно:
- Письменное разрешение и рамки (scope): что можно тестировать, когда, какие техники запрещены. Тестирование без разрешения незаконно (в РФ статьи 272-274 УК).
- Тип: чёрный, серый или белый ящик. Серый и белый дают больше пользы за то же время.
- Методологии: OWASP WSTG, PTES, для API отдельные чек-листы.
- Отчёт: находки с шагами воспроизведения, оценкой и рекомендациями, затем ретест исправлений.
Баг-баунти
Программа вознаграждений за найденные уязвимости: внешние исследователи ищут непрерывно, вы платите за результат. В РФ работают платформы Standoff 365 Bug Bounty, BI.ZONE Bug Bounty и другие. Нужны:
- Понятные правила: scope, исключения, запрещённые действия (DoS, социальная инженерия, доступ к чужим данным сверх необходимого).
- Безопасная гавань для исследователей, действующих по правилам.
- Быстрая сортировка (triage), честные выплаты, ответ в срок.
- Готовность команд исправлять: баунти без процесса исправления только копит долг.
Начинают обычно с политики раскрытия (security.txt, адрес для сообщений) и приватной программы.
Частые ошибки
- Купить сканер и считать, что SDLC внедрён.
- Блокировать сборку по всем находкам с первого дня.
- Пентест раз в год вместо процесса.
- Баг-баунти до того, как закрыты очевидные проблемы.
Что спросят на собесе
- Как вы выстроите Secure SDLC в компании с 30 командами.
- Чем SAST отличается от DAST, сильные и слабые стороны.
- Как бороться с ложными срабатываниями сканеров.
- Кто такие security champions и зачем они.
- Как проходит пентест, что должно быть до начала работ.
- Когда компании стоит запускать баг-баунти.