Проверки при разработке, выпуске и эксплуатации

Три строки кода, меняющие проверку владельца заказа в API, превращают авторизованный эндпоинт в IDOR. На каком этапе это изменение должно быть перехвачено - при коммите, при сборке, перед деплоем или уже в production? Согласно OWASP Web Security Testing Guide, проверки безопасности нужны на каждом из этих этапов, но с разными целями и разными артефактами. Здесь разбираются фазы 3-5 OWASP Testing Framework: что именно проверяется при разработке, при выпуске и при эксплуатации, кто за это отвечает и какой артефакт считается доказательством.

Безопасность жизненного цикла разработки ПО: фаза разработки​

Теоретически разработка - это реализация проекта. На практике масса архитектурных решений принимается прямо в коде: слишком мелких для проектной документации или оставшихся без чёткого стандарта. Если документация и политики недостаточны, разработчик принимает ещё больше самостоятельных решений, и вероятность появления уязвимости растёт.

Проверки безопасности кода на этом этапе делятся на два принципиально разных вида: совместный разбор кода (code walkthrough) и рецензирование кода (code review). Их часто путают, хотя цели и доказательства различаются.

Совместный разбор кода (Code Walkthrough)​

Команда безопасности проводит совместный разбор кода вместе с разработчиками и при необходимости - с архитекторами системы. Это обзор верхнего уровня: разработчик объясняет логику и поток реализованного кода, а проверяющие получают общее понимание структуры, компоновки и ключевых решений.

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

Что зафиксировать во время walkthrough:

• Потоки обработки чувствительных данных - аутентификация, авторизация, платёжные операции
• Отрицательные ветви: что происходит, когда проверка не пройдена, запрос невалиден или внешний сервис недоступен
• Решения, не описанные в проектной документации - именно они содержат неявные допущения о безопасности

Учебный сценарий. В локальной ветке приложения разработчик меняет проверку владельца заказа: вместо сравнения order.user_id == current_user.id новая версия проверяет только наличие активной сессии. На walkthrough разработчик объясняет мотивацию: упрощение кода для нового API-эндпоинта. Проверяющий фиксирует, что исходная защита от чтения чужого заказа потеряна, и помечает эту ветвь для детального рецензирования. Артефакт walkthrough - протокол с зафиксированными чувствительными участками.

Тут важно не пропустить момент: walkthrough - это не формальность и не "созвон для галочки". Это единственный этап, на котором разработчик своими словами рассказывает, почему он сделал именно так. Никакой SAST-инструмент не вытянет из кода мотивацию решения.

Рецензирование кода (Code Review)​

Когда структура и логика кода ясны, проводится рецензирование - независимая проверка кода на дефекты безопасности. Согласно OWASP WSTG, статическое рецензирование кода (static code review) валидирует код по набору чек-листов:

• Бизнес-требования к доступности, конфиденциальности и целостности
• Технические экспозиции по OWASP Top 10 (в зависимости от глубины проверки)
• Специфичные для языка или фреймворка проблемы - например, по PHP Configuration Cheat Sheet или Secure Coding Guidelines for .NET
• Отраслевые и регуляторные требования: ISO/IEC 27002, HIPAA, PCI DSS, а для российских проектов - ГОСТ Р 56939-2024 и требования приказов ФСТЭК

OWASP WSTG подчёркивает: по соотношению результата к затраченным ресурсам (в первую очередь времени) статическое рецензирование кода даёт более высокую отдачу, чем любой другой метод проверки безопасности, и в наименьшей степени зависит от квалификации проверяющего. Но это не серебряная пуля - рецензирование нужно рассматривать как часть полноценного режима тестирования.

Инструменты статического анализа (SAST) поддерживают процесс рецензирования. Semgrep Code, например, умеет делать межфайловый анализ потоков данных (cross-file dataflow analysis) для основных языков - C#, Go, Java, JavaScript, Python, TypeScript и других - с различным количеством правил для каждого языка (согласно документации Semgrep по поддерживаемым языкам). Среди российских SAST - PVS-Studio и Positive Technologies Application Inspector. При этом SAST не заменяет ручное рецензирование: автоматический анализ находит определённые классы уязвимостей (инъекции, XSS, утечки секретов), но не способен оценить бизнес-логику авторизации. Тот самый случай, когда order.user_id == current_user.id заменили на проверку сессии - ни один SAST этого не поймает.

Продолжение учебного сценария. Рецензирующий получает результат walkthrough и знает, что в изменённом эндпоинте убрана проверка владельца. Рецензирование фокусируется на условии доступа в изменённом коде, проверяет обработку ошибок при отсутствии авторизации и оценивает, не нарушено ли бизнес-требование конфиденциальности заказов. Артефакт рецензирования - заключение с перечнем найденных дефектов, привязанное к конкретному коммиту.

Отличие walkthrough от review:

Security gate при релизе ПО: фаза выпуска​

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

Пентест приложения перед релизом​

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

Пентест дополняет, а не заменяет статический анализ и рецензирование. Он обнаруживает проблемы, которые проявляются только в работающей системе: ошибки конфигурации, race conditions, проблемы с управлением сессиями.

Для динамического анализа приложений (DAST) используются инструменты вроде OWASP ZAP. Согласно официальной документации ZAP, активное сканирование - это атака на целевую систему: его нельзя запускать против приложений, которыми тестировщик не владеет. Активное сканирование находит только определённые типы уязвимостей. Логические уязвимости - нарушение контроля доступа (broken access control, A01:2021 по OWASP Top 10) - не обнаруживаются ни одним активным или автоматизированным сканированием. DAST-сканирование не заменяет ручную проверку авторизации и бизнес-логики. Точка.

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

Проверка конфигурации инфраструктуры​

OWASP WSTG включает проверку конфигурации в состав аудита безопасности перед релизом. Все аспекты конфигурации, даже кажущиеся незначительными, должны быть проверены - ни один параметр не должен оставаться в дефолтном значении, потенциально уязвимом для эксплуатации (A05:2021 - Security Misconfiguration).

Что проверяется как самостоятельный предмет:

• Конфигурация сети: правила межсетевого экрана, сегментация, TLS-настройки
• Платформа: версии ОС и middleware, отключение ненужных сервисов
• Секреты: отсутствие учётных данных в конфигурационных файлах, ротация ключей
• Права: принцип минимальных привилегий для сервисных учётных записей
• Журналирование: полнота записей аудита, защита журналов от модификации

Для анализа зависимостей используется SCA (Software Composition Analysis). OWASP Dependency-Check - инструмент SCA, который идентифицирует зависимости проекта и проверяет их на наличие известных публично раскрытых уязвимостей через сопоставление CPE/CVE. Он не выполняет статический или динамический анализ самого кода - только проверку компонентов (A06:2021 - Vulnerable and Outdated Components).

Учебный сценарий: новый reverse proxy. Тестовая среда выпуска получает новый reverse proxy. Проверяющий сверяет конфигурацию: TLS-профиль, заголовки безопасности (X-Content-Type-Options, Strict-Transport-Security, X-Frame-Options), правила маршрутизации. Затем отправляет запрос к чувствительному эндпоинту и проверяет, не раскрывает ли ответ внутреннюю информацию - stack traces, версии серверного ПО. После штатного перезапуска proxy проверка повторяется: настройки и наблюдаемое поведение должны быть согласованы и сохраняться. Одного удачного запуска теста до обновления конфигурации недостаточно - условие допуска выпуска (release gate) включает повторную верификацию после любого изменения среды.

Контроль безопасности при эксплуатации систем​

Выпуск приложения - не конец проверок. Мониторинг безопасности production-среды - обязательная часть SDLC. OWASP WSTG выделяет три вида проверок на этапе эксплуатации.

Эксплуатационные обзоры безопасности​

Должен существовать формализованный процесс, описывающий управление эксплуатационной стороной приложения и инфраструктуры. Обзор включает:

• Реестр владельцев: кто отвечает за каждый компонент (приложение, БД, reverse proxy, CDN)
• Мониторинг: какие метрики безопасности собираются, кто получает алерты, каков SLA на реагирование
• Доступы: актуальный список учётных записей с привилегированным доступом, процедура отзыва при увольнении или смене роли
• Зависимости: изменился ли состав внешних библиотек, сервисов или API с момента последнего обзора

Эксплуатационный обзор - регулярная процедура, частота которой определяется профилем риска системы. Атакующие эксплуатируют именно эксплуатационные пробелы: скомпрометированные зависимости и инструменты разработки (T1195.001, T1195.002 - Compromise Software Dependencies / Supply Chain, Initial Access), дефолтные конфигурации и устаревшие компоненты. Если никто не следит за тем, какие библиотеки тянет проект - рано или поздно в node_modules заведётся что-то интересное.

Периодические проверки состояния​

Ежемесячные или ежеквартальные проверки состояния (health checks) проводятся и для приложения, и для инфраструктуры. Цель - убедиться, что не появились новые риски безопасности и уровень защищённости сохраняется.

Что проверяет автоматизация:

• SAST и DAST анализ по расписанию - обнаружение новых уязвимостей в коде и конфигурации
• SCA-проверка зависимостей - появление новых CVE в используемых библиотеках
• Проверка сертификатов - сроки истечения TLS-сертификатов
• Мониторинг конфигурации - дрейф настроек от эталонного состояния

Где нужна ручная проверка:

• Оценка бизнес-логики: автоматическое сканирование не обнаруживает логические уязвимости - это подтверждено ограничениями ZAP active scan
• Обзор прав доступа: накопление привилегий со временем (privilege creep) требует ручной инвентаризации
• Актуальность модели угроз: изменились ли угрозы для этой системы

Частота health checks определяется уровнем риска. Для систем с персональными данными (ФЗ-152) или объектов КИИ (ФЗ-187) регуляторные требования могут задавать минимальную частоту. NIST SP 800-218 SSDF Version 1.1 (финальная версия) включает группу практик Respond to Vulnerabilities (RV), которая формализует реагирование на новые уязвимости - в том числе обнаруженные в ходе периодических проверок. В российском контексте ГОСТ Р 56939-2024 описывает процессы сопровождения и управления уязвимостями как часть 25 процессов безопасной разработки.

Верификация изменений (регрессионная проверка)​

После того как каждое изменение одобрено, протестировано в QA-среде и развёрнуто в production, критически важно проверить, что уровень безопасности не пострадал. Эта проверка должна быть интегрирована в процесс управления изменениями.

Верификация изменений - не повторение полного цикла тестирования. Это точечная регрессионная проверка (regression test) по затронутым зависимостям:

• Какие компоненты затронуты изменением?
• Какие угрозы из модели угроз связаны с этими компонентами?
• Какие предыдущие доказательства безопасности остаются действительными, а какие нужно обновить?

Для CI/CD-пайплайнов верификация изменений включает защиту самого пайплайна. Документация GitHub Actions рекомендует конкретные меры: привязку сторонних actions к полному SHA коммита (pinning) для защиты от компрометации репозитория действия, использование CODEOWNERS для обязательного ревью изменений в файлах workflow, ограничение разрешений GITHUB_TOKEN по принципу минимальных привилегий. Аналогичные практики применимы к другим CI/CD-платформам - GitLab CI, Jenkins, TeamCity.

Продолжение сценария с reverse proxy. Через месяц после выпуска обновляется конфигурация reverse proxy - добавляется новый upstream. Верификация изменений: проверяющий повторяет тесты заголовков безопасности и чувствительных ответов для нового маршрута. Предыдущие доказательства по остальным маршрутам сохраняются, но для изменённого компонента нужно новое подтверждение. Одного факта успешного развёртывания недостаточно - условие допуска выпуска требует, чтобы наблюдаемое поведение соответствовало ожидаемому после каждого изменения.

Сквозной SDLC-workflow: DevSecOps практики проверки​

OWASP WSTG описывает типовой SDLC Testing Workflow - сквозную цепочку проверок от требования до эксплуатационного исправления. На практике эту цепочку удобно представить через артефакты, владельцев и условия допуска (release gate).


Правило повторного теста: при обнаружении дефекта на любом этапе повторный тест проводится не для всего приложения, а для затронутых угроз и их зависимостей. Новый тест привязывается к конкретной сборке или конфигурации - результаты старого теста не переносятся автоматически.

OWASP SAMM (Software Assurance Maturity Model) предлагает оценку зрелости этих практик по пяти бизнес-функциям и пятнадцати практикам безопасности, охватывающим governance, проектирование, реализацию, верификацию и эксплуатацию. NIST SP 800-218 SSDF Version 1.1 организован в четыре группы практик - Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) и Respond to Vulnerabilities (RV), каждая из которых привязывается к конкретным этапам SDLC. Для российского комплаенса - ГОСТ Р 56939-2024 и требования приказа ФСТЭК № 76, определяющего классы защиты средств защиты информации и соответствие оценочным уровням доверия.

Большинство команд воспринимают проверки безопасности как набор инструментов: запустил SAST, прогнал DAST, поставил галочку. Инструменты решают меньшую часть задачи. Автоматическое сканирование не обнаружит, что из кода убрали проверку владельца заказа - это выявляется только при совместном разборе кода и целенаправленном рецензировании. Автоматика не проверит, что конфигурация reverse proxy сохраняется после перезагрузки - для этого нужна осознанная верификация изменений с повторным тестом.

Распространённая ошибка - приравнивание зелёного пайплайна к безопасности. CI/CD-пайплайн зелёный, SAST без критических находок, DAST прошёл - значит, можно выпускать. Но пайплайн не знает контекст бизнес-требования. Он не знает, что эндпоинт /api/orders/{id} раньше проверял владельца, а теперь не проверяет. Этот контекст приносят люди: через walkthrough, через рецензирование, через ручную часть пентеста.

Вторая типичная ошибка - перенос выводов со старой версии на изменённую конфигурацию. Результаты пентеста, проведённого до замены reverse proxy, не доказывают безопасность системы после замены. Каждое доказательство привязано к конкретной сборке и конфигурации. Без этой привязки security gate превращается в формальность, за которой нет реальной проверки.

Основа: OWASP Web Security Testing Guide - The Web Security Testing Framework, OWASP Foundation, разделы Phase 3 During Development, Phase 4 During Deployment, Phase 5 During Maintenance and Operations, A Typical SDLC Testing Workflow. Снимок: 2026-10-22. Дополнительные источники: OWASP Code Review Guide (PDF v2.0, июль 2017 - исторический справочный материал), OWASP SAMM, NIST SP 800-218 SSDF v1.1, OWASP Dependency-Check, документация Semgrep и ZAP, GitHub Actions Security Hardening. Русский перевод и редакционная актуализация: Codeby. Изменения относительно оригинала: добавлены учебные сценарии с условными результатами, таблица артефактов и владельцев, практические рекомендации по инструментам SAST/DAST/SCA с верифицированными ограничениями, контекст российских нормативных документов (ГОСТ Р 56939-2024, ФЗ-152, ФЗ-187, приказ ФСТЭК № 76). Лицензия перевода и адаптации: CC BY-SA 4.0.

Вся серия WSTG · Предыдущая статья