«Считается, что код ревью и тестирование — это чисто техническая практика, призванная ловить баги. На деле, в контексте российского ИТ и регуляторики ФСТЭК, это ключевой барьер на пути формального соответствия требованиям 152-ФЗ, превращающий абстрактные «организационные меры защиты» в конкретный, проверяемый артефакт».
Code Review и тестирование в контексте требований ФСТЭК
Проверка кода и тестирование часто рассматриваются как сугубо технические практики, направленные на повышение качества. Однако в парадигме, заданной 152-ФЗ, ФСТЭК России и другими регуляторами, эти процессы трансформируются в инструмент легитимации. Они предоставляют неопровержимые доказательства того, что организационные меры безопасности, прописанные в политиках, реально реализованы в коде, а не существуют лишь на бумаге.
Code Review как формализованный процесс контроля
Code Review (проверка кода) — это не просто «посмотреть код коллеги». В среде, где итоговый продукт должен соответствовать требованиям защиты информации, это становится обязательной процедурой верификации. Она превращает разработку из творческого процесса в частично регламентированный, что критически важно для прохождения аудитов.
Основные цели code review в регулируемой среде:
- Выявление дефектов, которые могут привести к нарушению конфиденциальности или целостности данных (например, ошибки в функциях шифрования или контроля доступа).
- Соблюдение внутренних стандартов кодирования, которые, в свою очередь, могут быть привязаны к требованиям стандартов ФСТЭК по разработке защищённого ПО.
- Создание артефакта (например, записи в системе code review) для внутреннего аудита и внешних проверяющих.
- Распространение знаний о безопасных методах программирования внутри команды.
Отсутствие задокументированного процесса code review для систем обработки персональных данных (ПДн) может быть расценено проверяющим как недостаток организационных мер защиты информации.
Инспекции Фагана: отраслевая экзотика или практичный стандарт?
Инспекции Фагана часто упоминаются как пример максимально формального подхода. Этот метод, состоящий из шести чётко определённых этапов, идеально ложится на требования регуляторов к документированию любого значимого процесса. Он превращает проверку из дискуссии в повторяемую процедуру с фиксируемым результатом.
| Этап | Описание и выходной артефакт | Ценность для регуляторного соответствия |
|---|---|---|
| Планирование | Определение области, участников, ролей. Создание плана проверки. | Демонстрирует системный подход. План — это первичный документ, подтверждающий намерение. |
| Обзор | Вводное совещание для синхронизации понимания целей. | Протокол встречи (если ведётся) фиксирует, что команда понимает, на какие аспекты безопасности нужно обратить внимание. |
| Подготовка | Индивидуальное изучение кода участниками, составление списка вопросов/замечаний. | Личные заметки ревьюеров (могут быть формализованы в чек-лист) показывают глубину анализа. |
| Инспекция | Коллективное построчное обсуждение кода, ведение протокола дефектов. | Главный артефакт. Протокол инспекции — прямое доказательство проведения экспертизы кода на предмет уязвимостей. |
| Переработка | Исправление дефектов автором кода. | Коммиты, связанные с исправлениями, и их привязка к протоколу дефектов обеспечивают прослеживаемость. |
| Последующее наблюдение | Верификация исправлений, закрытие дефектов. | Финальный акт, подтверждающий, что процесс завершён, а выявленные риски нивелированы. |
Полный цикл Фагана ресурсоёмок и редко применяется целиком в agile-среде. Однако его логика — планирование, фиксация, верификация — является эталонной для построения любого принимаемого регулятором процесса контроля.
SAST и DAST: два взгляда на безопасность кода с позиции ФСТЭК
С точки зрения регулятора, статический и динамический анализ — это не конкурирующие, а взаимодополняющие методы, покрывающие разные аспекты требования «обеспечения безопасности информации при её обработке». Их применение должно быть обосновано в рамках модели угроз.
Статический анализ безопасности приложений (SAST)
SAST (Static Application Security Testing) работает с исходным кодом, байт-кодом или бинарными файлами без запуска программы. Инструменты SAST ищут шаблоны, соответствующие известным уязвимостям (инъекции, XSS, проблемы с криптографией).
Контекст ФСТЭК: SAST напрямую соотносится с требованием о выявлении недекларированных возможностей (НДВ) и дефектов защиты на этапе разработки. Регулярное проведение SAST-сканирований и анализ их отчётов могут быть частью регламента разработки защищённого ПО.
Ключевой нюанс: SAST требует доступа к исходному коду. Для проектов с открытым исходным кодом или использованием сторонних библиотек он выявляет риски на самом глубоком уровне, но для проприетарных компонентов неприменим.
Динамический анализ безопасности приложений (DAST)
DAST (Dynamic Application Security Testing) тестирует работающее приложение, эмулируя действия злоумышленника «снаружи». Он не знает, как написан код, но видит, как система реагирует на атаки.
Контекст ФСТЭК: DAST проверяет итоговый результат — рабочее приложение в среде, приближенной к эксплуатационной. Это позволяет выявить уязвимости, возникающие из-за конфигурации сервера, взаимодействия компонентов или логических ошибок, невидимых в коде. Результаты DAST — прямое свидетельство наличия или отсутствия уязвимостей, эксплуатируемых удалённо.
Выбор между SAST и DAST: практический ракурс
Решение о внедрении SAST, DAST или их комбинации зависит не только от технических возможностей, но и от формальных требований.
| Критерий | SAST | DAST |
|---|---|---|
| Объект проверки | Исходный код / бинарные файлы | Работающее приложение (чаще через HTTP/API) |
| Соответствие требованиям | Требования к безопасной разработке (SDLC), поиск НДВ | Требования к защищённости функционирующей ИС (модель угроз, актуальные атаки) |
| Интеграция в процесс | Ранние этапы, может быть встроен в CI/CD | Поздние этапы, тестирование сборок или готовых стендов |
| Главный артефакт для аудита | Отчёт сканирования с указанием файлов и строк кода, требующих доработки | Отчёт о проникновении с доказательствами уязвимостей (скриншоты, запросы-ответы) |
Итог: от практики к доказательной базе
Внедряя code review и тестирование, команда создаёт не просто более качественный код. Она формирует массив технических артефактов, которые становятся основой для доказательства выполнения регуляторных требований.
- Журналы code review в GitLab, GitHub или специализированных системах показывают, что код проверялся.
- Отчёты SAST/DAST, интегрированные в пайплайн сборки и привязанные к задачам, демонстрируют непрерывный контроль безопасности.
- Политики, требующие обязательного прохождения проверок перед слиянием в главную ветку, формализуют процесс.
Таким образом, code review и тестирование из инженерных практик превращаются в стык между технической и организационной безопасностью, где строки кода, комментарии ревьюеров и отчёты сканеров становятся языком общения с регулятором.