Угрозы и SSDLC: опережающее предупреждение

Все прошлые уроки учили реагировать на конкретные атаки. Этот урок про смену позиции: тимлид не догоняет инциденты, а встраивает безопасность в процесс так, чтобы целые классы проблем не доезжали до прода. Главные инструменты тут это threat modeling и SSDLC.

Идея: сдвиг влево

Сдвиг влево это главная экономическая мысль зрелой безопасности. Цена бага растёт на порядки по ходу пайплайна: угроза, замеченная на дизайне, это абзац в документе; та же угроза в проде это инцидент с простоем, расследованием и сообщением клиентам.

Из этого следует и культурный сдвиг: безопасность это не роль одного человека в конце, а привычка всей команды на каждом шаге. Тимлид не проверяет код за всеми, он выстраивает процесс, в котором небезопасный код тяжело написать и легко поймать.

Threat modeling по STRIDE

Threat modeling это не аудит готовой системы, а структурный вопрос “что может пойти не так” на этапе дизайна. Рабочий рецепт в четыре шага: что строим, что может сломаться, что с этим делаем, всё ли мы учли.

Начинают с data-flow диаграммы: рисуют процессы, хранилища, внешних акторов и потоки данных между ними. Самое важное на диаграмме это границы доверия, те самые линии из первого урока. Угрозы рождаются там, где поток их пересекает.

Дальше по каждому элементу проходят методом STRIDE, шести классов угроз:

• Spoofing: выдача себя за другого. Контрмера это аутентификация.
• Tampering: подмена данных или кода. Контрмеры это целостность и валидация.
• Repudiation: отрицание действия. Контрмера это accounting из прошлого урока.
• Information disclosure: утечка данных. Контрмеры это шифрование и контроль доступа.
• Denial of service: отказ в обслуживании. Контрмеры это rate limiting и защита от DDoS.
• Elevation of privilege: повышение привилегий. Контрмера это строгая авторизация.

Заметь соответствие: STRIDE это, по сути, обратная сторона AAA и границ доверия, разложенная на классы. Чтобы не утонуть, моделируют не всю систему разом, а одну фичу или один поток за раз, и фокусируются на потоках через границы доверия, а не на каждом внутреннем вызове.

SSDLC и гейты в пайплайне

Threat modeling находит угрозы на дизайне. SSDLC следит, чтобы найденное не вернулось через код. Делается это автоматическими гейтами в CI, и ключевое решение по каждому гейту это блокирует он merge или только предупреждает.

• Secret scanning: блокирующий гейт. Утёкший секрет это всегда инцидент, ложных срабатываний мало.
• SAST (SonarQube, Semgrep, CodeQL): ищет уязвимые паттерны в коде. Обычно блокирует на высоких severity, предупреждает на остальных, чтобы не топить команду шумом.
• Dependency audit: аудит зависимостей плюс frozen-lockfile, прямое продолжение урока про цепочку поставок.
• DAST: динамическая проверка работающего приложения, обычно на стейджинге.

Правило баланса: блокирующих гейтов должно быть немного и они должны быть точными. Гейт, который часто врёт, команда научится обходить, и он перестанет защищать. Лучше один надёжный блокирующий плюс несколько предупреждающих, чем десять блокирующих с шумом.