Нормативная база SAID

Рабочие материалы для ИБ-специалиста и аудитора: таблица соответствия SAID международным и российским рамкам, разбор ГОСТ Р 56939-2024 и Приказа ФСТЭК России №240, полный маппинг «25 процессов ГОСТ × SAID». Для решения о внедрении методологии эти материалы не обязательны — они нужны на этапах аудита и сертификации.

Соответствие стандартам (crosswalk)

Таблица связывает правила SAID с NIST AI RMF, ISO/IEC 42001, ГОСТ Р 56939-2024 и приказами ФСТЭК России. Прочерк означает отсутствие аналога: домены знаний, окно агента и перестройка ролей (правило 12) — вклад SAID, не имеющий соответствия в существующих стандартах. Соответствие ориентировочное: оно показывает пересечение областей, а не эквивалентность требований.

Правило SAIDNIST AI RMFISO/IEC 42001 (Annex A)ГОСТ Р 56939-2024ФСТЭК России
1. Определи, что надо защищать (классификация данных)GOVERN 1.1 (правовые требования к данным); MAP 1.1 (частично — контекст и воздействия)A.4.3 (data resources); A.7.2 (данные для разработки); A.7.3 (получение данных)5.3 (требования безопасности: классификация данных для AI)№117 п. 60 (частично — исключение НСД к наборам данных и моделям; запрет передачи защищаемой информации разработчику модели); №240 (через ГОСТ 5.3)
2. Размещай ИИ рядом с обрабатываемыми даннымиMAP 1.1 (prospective deployment settings); MAP 3.3 (границы применения)A.6.2.5 (deployment); A.4.5 (system & computing resources)5.6 (архитектура: AI-шлюз, inference); AI-2 «Закрытый контур» (вне ГОСТ)№117 п. 61 (только доверенные технологии ИИ); методика 04.2026 п. 3.18 (изоляция среды разработки в отдельный сегмент)
3. Не доверяй агенту больше, чем он должен знатьMAP 3.3 (целевой scope применения); MEASURE 2.7 (security & resilience)A.9.2 (процессы ответственного использования); A.9.4 (intended use)5.7 (модель угроз: Excessive Agency); 5.14 (доступ и целостность кода); 5.15 (секреты вне зоны AI)№117 пп. 60–61 (исключение НСД к моделям/параметрам; исключение влияния ИИ на функционирование ИС); методика 04.2026 п. 3.18
4. История ИИ должна жить дольше задачи (журналирование)GOVERN 4.3 (выявление инцидентов); MEASURE 2.4 (мониторинг в production); MANAGE 4.1 (post-deployment monitoring, incident response)A.6.2.8 (recording of event logs — прямое соответствие)5.23 (реагирование: логирование промптов, SIEM, ГосСОПКА)№117 п. 61 (контроль каждого взаимодействия с ИИ); методика 04.2026 п. 3.18 (логирование запросов и ответов ИИ, аудит)
5. Проверяй AI-код как чужойGOVERN 6.1; MANAGE 3.1 (по аналогии: AI-код как third-party артефакт)A.6.2.4 (verification & validation); A.6.1.3 (процессы ответственной разработки)5.9 (code review без fast-track); 5.10 (SAST); 5.16 (SCA, галлюцинация зависимостей)№240 (сертификация процессов РБПО: 5.9/5.10/5.16); методика 04.2026 п. 3.18 (SCA-анализ уязвимостей библиотек при разработке)
6. Никаких прямых диалогов пользователей с ИИ (шлюз, DLP)MEASURE 2.10 (privacy-риски); MEASURE 2.7 (security)A.9.2 (ограничения использования); A.6.2.6 (частично — operation & monitoring)AI-1 «DLP для промптов» (вне ГОСТ); 5.8 (правила кодирования: запрет ПДн в промпт)№117 п. 61 (допустимые шаблоны/тематики запросов и форматы ответов); методика 04.2026 п. 3.18 (фильтрация входов/выходов)
7. Защити модель — она знает больше всехMEASURE 2.7 (security & resilience: инъекция промпта, кража); MANAGE 3.2 (мониторинг pre-trained моделей)A.6.2.6 (operation & monitoring); A.10.3 (suppliers — supply chain моделей)5.17 (supply chain: проверка моделей); 5.19 (pentest инъекций промптов, red teaming); 5.25 (вывод из эксплуатации, зачистка)№117 п. 60 (исключение НСД к моделям и параметрам — прямое соответствие); методика 04.2026 п. 3.18 (криптографический контроль целостности весов, квотирование запросов)
8. Прослеживаемость данных в AI-генерацииGOVERN 6.1 (IP-риски третьих сторон); MAP 4.1 (маппинг рисков компонентов, IP)A.7.5 (data provenance — прямое соответствие); A.7.3 (acquisition of data)5.16 (SCA: лицензии); 5.21 (SBOM с AI-маркировкой); 5.17 (supply chain)№117 п. 60 (частично — защита наборов данных); №240 (через ГОСТ 5.16/5.21)
9. ИИ обязан объяснить, человек — понятьGOVERN 3.2 (роли human-AI oversight); MAP 3.5 (процессы человеческого надзора); MEASURE 2.9 (объяснимость моделей)A.8.2 (документация и информация для пользователей); A.9.2; A.9.3 (цели ответственного использования)5.2 (обучение: automation bias, ответственность за AI-код); 5.8 (верификация AI-предложений)№117 п. 61 (частично — контроль соответствия ответов установленным границам)
10. Измеряй и адаптируй (KPI, red teaming, PDCA)MEASURE 1.1 (выбор метрик); GOVERN 1.5 (периодический review); MANAGE 4.2 (непрерывное улучшение)A.2.4 (review of AI policy); A.6.2.6 (operation & monitoring); PDCA — основной текст стандарта (пп. 4–10), не Annex A5.5 (метрики дефектов AI vs human); 5.24 (red teaming AI); AI-3 «Метрики» (вне ГОСТ)№240 (поддержание сертифицированных процессов, периодические проверки); методика 04.2026 п. 3.18 (мониторинг/аудит моделей в эксплуатации)
11. Разрешить и контролировать, а не запрещать и не видетьGOVERN 1.6 (инвентаризация AI-систем — контрмера против теневого ИИ); GOVERN 4.1 (частично — культура safety-first mindset)A.2.2 (AI policy); A.9.2 (процессы ответственного использования)5.1 (планирование РБПО: аудит теневого ИИ)№117 п. 61 (частично — допускаются только доверенные технологии ИИ)
12. Старые роли и процессы = потерянная эффективностьGOVERN 2.1 (частично — документирование ролей); в остальном — (нет аналога)A.3.2 (AI roles & responsibilities); A.4.6 (human resources) — оба лишь частично— (нет аналога)— (нет аналога)
13. Контролируй ИИ каждый шаг, а не на старте (нулевое доверие в реальном времени)MEASURE 2.4 (мониторинг поведения в production); MANAGE 2.2 (sustain value deployed systems; по Playbook — регулярный мониторинг, детекция drift); MANAGE 2.4 (деактивация системы при отклонениях)A.6.2.6 (operation & monitoring)5.13 (частично — безопасность среды: минимальные привилегии AI-агентов, логирование, защита от инъекций через PR); AI-1 (вне ГОСТ)№117 п. 61 (контроль соответствия каждого взаимодействия установленным границам; исключение влияния ИИ на функционирование ИС); методика 04.2026 п. 3.18 (фильтрация входов/выходов, квотирование)

ГОСТ Р 56939-2024 и AI-разработка

SAID — расширение процессов безопасной разработки ПО (ГОСТ Р 56939-2024) для организаций, использующих AI-ассистенты. ГОСТ определяет 25 процессов SDLC. SAID дополняет каждый из них мерами контроля AI-рисков.

Зачем это нужно? ГОСТ Р 56939-2024 — базовый стандарт для сертификации процессов безопасной разработки (Приказ ФСТЭК №240). Ни ГОСТ, ни приказ не учитывают AI-ассистированную разработку: генерацию кода через LLM, AI-агентов в CI/CD, вайб-кодинг. SAID заполняет этот пробел.

25 процессов ГОСТ: группировка

Этап жизненного циклаПроцессы ГОСТКол-во
Организация и планирование5.1 Планирование, 5.2 Обучение2
Требования и управление5.3 Требования безопасности, 5.4 Конфигурация, 5.5 Недостатки3
Проектирование5.6 Архитектура, 5.7 Модель угроз2
Реализация (кодирование)5.8 Правила кодирования, 5.9 Code review, 5.10 SAST, 5.11 DAST4
Сборка и инфраструктура5.12 Сборка, 5.13 Безопасность среды, 5.14 Целостность кода, 5.15 Секреты4
Зависимости / Supply chain5.16 SCA, 5.17 Проверка цепочки поставок2
Тестирование5.18 Функциональное, 5.19 Нефункциональное2
Выпуск и поставка5.20 Выпуск, 5.21 Доставка2
Эксплуатация5.22 Поддержка, 5.23 Реагирование, 5.24 Поиск уязвимостей3
Завершение5.25 Вывод из эксплуатации1
8 новых процессов появились в ГОСТ 2024 (vs 2016): моделирование угроз, безопасность сборочной среды, управление доступом к коду, секреты, SCA, supply chain, нефункциональное тестирование, безопасная поставка.

Приказ ФСТЭК №240 — Сертификация процессов РБПО

Сертификат подтверждает, что ПО создаётся с учётом требований безопасности (SDLC), минимизируя уязвимости. Даёт право самостоятельно испытывать обновления сертифицированных СЗИ.

Что сертифицируется

Процессы безопасной разработки ПО — не продукт, не организация. На соответствие 25 процессам ГОСТ Р 56939-2024.

Срок действия

Сертификат выдаётся на срок до 5 лет (актуальная редакция от 30.06.2025, Приказ №230).

Кому нужен

Изготовителям средств защиты информации (СЗИ) для ГИС, КИИ, ИСПДн. Даёт право самостоятельных испытаний обновлений.

Процедура получения

1

Заявка

Изготовитель подаёт заявку в ФСТЭК России

15 рабочих дней
2

Решение

ФСТЭК назначает аккредитованный орган по сертификации

По результатам рассмотрения
3

Проверка

Орган проверяет процессы на площадке: документация, инструменты, артефакты, компетенции

По договору
4

Сертификат

ФСТЭК выдаёт сертификат соответствия процессов РБПО

до 30 + 10 рабочих дней

Что проверяется при сертификации

АспектЧто смотрятAI-расширение SAID
ДокументацияРуководство по РБПО соответствует ГОСТРаздел про AI-процессы в руководстве
ИнструментыSAST, DAST, SCA реально используютсяAI-шлюз (AI Gateway), DLP промптов, детекция галлюцинаций зависимостей (slopsquatting)
АртефактыОтчёты анализов, логи, записиЛоги AI-промптов, маркировка AI-кода
ПроцессыФактически работают, не только на бумагеCode review AI-кода, изоляция агентов
КомпетенцииПерсонал обучен безопасной разработкеМодуль обучения безопасному AI-кодингу

Связь с другими приказами

ПриказОбластьКак связан с №240
№55Сертификация продуктов (СЗИ)№240 дополняет — сертификация процессов разработки
№17Защита ГИСОбязывает использовать сертифицированные СЗИ
№21Защита ИСПДнРекомендует сертифицированные СЗИ
№239Защита КИИОбязывает сертифицированные СЗИ для значимых объектов

Маппинг: 25 процессов ГОСТ × SAID

Для каждого процесса ГОСТ Р 56939-2024 — что добавляет SAID для контроля AI-рисков.

Процесс ГОСТAI-расширение SAIDКлючевые меры
5.1 Планирование РБПОВключить AI в область процессовАудит теневого ИИ (shadow AI), выбор модели LLM, бюджет GPU
5.2 Обучение сотрудниковМодуль безопасного AI-кодингаAutomation bias, типичные CWE в AI-коде, инъекции промптов (prompt injection)
5.3 Требования безопасностиКлассификация данных для AIЧто можно/нельзя в промпт, политика по категориям данных
5.4 Конфигурация ПОAI-инструменты как элементы конфигурации.aiignore, сегментация репо, версионирование промптов
5.5 Управление недостаткамиКатегория «дефект AI-генерации»Git trailers, метрики AI vs human дефектов
Процесс ГОСТAI-расширение SAIDКлючевые меры
5.6 АрхитектураAI-компоненты в архитектуреAI-шлюз (AI Gateway), inference server, изоляция AI-агентов
5.7 Модель угрозAI-специфичные угрозыИнъекции промптов, Excessive Agency, галлюцинация зависимостей (slopsquatting), data poisoning
5.8 Правила кодированияПравила работы с AI-ассистентамиЗапрет копирования ПДн в промпт, верификация AI-предложений
5.9 Code reviewAI-код без fast-trackМаркировка AI-кода, обучение ревьюеров automation bias
5.10 SASTПаттерны AI-ошибок в правилахSemgrep / Svace / PT Application Inspector, pre-commit hooks (gitleaks)
5.11 DAST / фаззингПриоритет для AI-кодаФаззинг парсеров и сетевого кода, сгенерированного AI
5.16 SCAГаллюцинация зависимостей + лицензииCodeScoring OSA, детекция «галлюцинированных» пакетов, GPL-анализ
5.17 Supply chainAI-модели как элемент поставкиПроверка моделей, data diodes для КИИ, мониторинг аномалий
Процесс ГОСТAI-расширение SAIDКлючевые меры
5.12 Безопасная сборкаAI-агенты в CI/CD изолированыSBOM с маркировкой AI-компонентов, hardening flags
5.13 Безопасность средыЗащита от AI-инъекций в CI/CDМинимальные привилегии, логирование, защита от инъекций промптов через PR
5.14 Целостность кодаBranch protection для AIAI не коммитит в main, подпись AI-коммитов
5.15 СекретыСекреты вне зоны AI.aiignore, short-lived credentials, gitleaks/detect-secrets
5.18 Функц. тестированиеРасширенные тесты для AI-кодаEdge cases, верификация AI-тестов, запрет автодеплоя
5.19 Нефункц. тестированиеТестирование AI-инфраструктурыНагрузка inference, pentest на инъекции промптов, red teaming
5.20 ВыпускМетрики AI-кода в критерии приёмкиCode churn, release gate для AI-кода
5.21 ПоставкаSBOM с AI-маркировкойПодпись артефактов, сертифицированные СКЗИ для КИИ
Процесс ГОСТAI-расширение SAIDКлючевые меры
5.22 ПоддержкаAI-компоненты в документацииКанал обратной связи по AI-проблемам
5.23 РеагированиеAI-утечка = инцидент ИБЛогирование промптов, SIEM-алерты, уведомление ГосСОПКА (24-72ч для КИИ)
5.24 Поиск уязвимостейRed teaming AIИнъекции промптов, data exfiltration, jailbreak, bug bounty
5.25 Вывод из эксплуатацииУдаление AI-моделей и данныхЗачистка fine-tuning данных, отзыв AI-credentials

Дополнительные AI-процессы (вне ГОСТ)

Следующие процессы специфичны для AI-разработки и не имеют аналогов в ГОСТ Р 56939-2024:

AI-1. DLP для промптов

Контроль данных, отправляемых в AI-модели. InfoWatch, AI-шлюз, фильтрация ПДн/секретов, белые/чёрные списки сервисов.

AI-2. Закрытый контур

Физически изолированная (air-gapped) инфраструктура с on-premise LLM для КИИ/ГИС. Однонаправленные шлюзы, сертифицированные СКЗИ, VDI, карантин обновлений.

AI-3. Метрики AI-безопасности

KPI: уязвимости AI vs human, code churn, DLP-блокировки, red teaming. Ежеквартальный review, мониторинг законодательства.

← вернуться к методологии