Подготовка изготовителя к сертификации процессов РБПО

Зачем эта методика и кому она нужна

Методика — это пошаговая «дорожная карта» подготовки организации к сертификации процессов безопасной разработки ПО. Она охватывает работу с документацией, инструментарием, процессами, инструментальным контролем и кадрами — то есть весь объём, который проверяет орган по сертификации в соответствии с пунктом 19 Порядка.

Кому адресована

Что даёт работа по этой методике

Изготовитель получает чёткий перечень того, что должно существовать к моменту приезда экспертов: один утверждённый Руководящий документ, 25 регламентов и планов по процессам 5.1-5.25, набор матриц соответствия, перечень инструментов с привязкой к процессам, RACI-роли, доказательства компетентности сотрудников и набор артефактов в живых системах (VCS, CI, трекер, журналы). Без подготовки по этому списку проверка превращается в догадку «что им нужно показать»; с подготовкой — в формальную сверку.

Нормативная база: что регулирует сертификацию

Сертификация процессов РБПО опирается на стек из четырёх взаимосвязанных нормативных документов: один задаёт область аккредитации органов, второй — Порядок проведения сертификации, третий — собственно требования к процессам, четвёртый — частные требования к безопасному компилятору C/C++.

Хронология последних изменений

Дорожная карта сертификации

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

Шесть направлений оценки (п. 19 Порядка)

Содержание сертификации задано пунктом 19 Порядка. Это шесть параллельных направлений, каждое из которых требует своих доказательств и подготовки.

Руководство по РБПО — основной документ заявителя

Руководство по безопасной разработке программного обеспечения — единственный документ, прилагаемый к заявке в ФСТЭК России. Его соответствие пункту 5.1 Порядка проверяется в первую очередь; от его качества зависит, будет ли заявка принята к рассмотрению.

Семь обязательных разделов (п. 5.1 Порядка)

• Описание области действия — конкретные продукты, классы ПО, версии, исключения.
• Цели организации в области создания безопасного ПО.
• Перечень и описание процессов по РБПО — все 25 процессов 5.1-5.25 с описанием реализации.
• Распределение ролей и обязанностей, связанных с реализацией процессов.
• Перечень документации (регламентов) по РБПО в соответствии с подпунктами 5.1-5.25.
• Правила и требования к внутренним проверкам реализации мер РБПО, сообщения о результатах.
• Описание действий по улучшению процессов, связанных с РБПО.

Руководство должно быть утверждено руководством организации, издано и доведено до сведения всех сотрудников, имеющих отношение к безопасной разработке.

Контрольные вопросы к области действия (скоупу)

Область действия — самая критичная часть Руководства. Размытая или непоследовательная формулировка скоупа делает сертификат бесполезным («сертифицировано всё и ничего»). Перед утверждением проверьте каждый блок:

25 регламентов и планов по процессам 5.1-5.25

ГОСТ Р 56939-2024 устанавливает 25 процессов РБПО. По каждому требуется документация — план или регламент с приложениями. Минимально получается 4 плана и 21 регламент (всего 25 базовых документов); плюс прилагаемые перечни, схемы и описания (для процессов с несколькими артефактами 5.X.3.Y). Список построен из требований 5.1.3.X — 5.25.3.X стандарта.

Регламенты могут быть оформлены как самостоятельные документы или объединены в рамках общего документа (п. 4.12 ГОСТ Р 56939-2024). Требования к оформлению регламентов как таковых не предъявляются — но все они должны быть утверждены, изданы и доведены до работников.

Полный список по процессам

Рекомендации по приоритизации разработки

Матрица соответствия — ключевой внутренний документ

Матрица соответствия — это связующее звено между нормой стандарта, регламентом, системой и конкретным артефактом. Без неё подготовка к сертификации превращается в бесконечный поиск «где у нас лежит подтверждение пункта 5.X.Y.Z». Матрица ведётся как живой документ изготовителя.

Структура матрицы (4 обязательные колонки + 1)

• Требование стандарта — конкретный подпункт ГОСТ Р 56939-2024 (например, 5.12.2.2).
• Регламент / процедура, устанавливающая выполнение этого требования.
• Система, где формируется подтверждение (CI, VCS, трекер, система хранения артефактов).
• Тип и местоположение артефакта — лог, отчёт, запись, журнал, документ, результат инструмента.
• Объекты области действия, для которых артефакт должен существовать, и правила выборки.

Пример строки матрицы

Анализ инструментария и информационных систем

Орган по сертификации проверяет, что у изготовителя есть все типы средств, прямо названные в подпунктах 5.8, 5.9, 5.10, 5.11, 5.12, 5.16, 5.18 и 5.19 ГОСТ Р 56939-2024. Подготовка — это перечень этих инструментов с привязкой к процессам, источнику и месту в жизненном цикле.

Перечень инструментов: что в нём должно быть

• Назначение — какой процесс ГОСТ обеспечивает (например, «5.10 — статический анализ исходного кода»).
• Тип — проприетарное, Open Source, собственная разработка.
• Версия и источник поставки — релиз, дистрибутив, репозиторий.
• Контур использования — рабочее место разработчика, CI, сборочная среда, тестовая среда.
• Ответственный — кто настраивает, кто администрирует, кто отвечает за результаты.

Карта «этап ЖЦ ПО → инструмент → артефакт»

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

Проверка процессов: модели «Д», «Ф» и референтная (IDEF0)

Орган по сертификации использует методологию процессного моделирования IDEF0. Логика реализации процессов у каждого изготовителя своя — поэтому проверяется не «как организовано внутри», а выполнение функций: что на входе, что на выходе, какие управления и какие механизмы.

Три модели и их сравнение

Что показывает сравнение моделей

• «Ф» ≠ «Д» — документация не соответствует реальной работе. Либо процессы выполняются «не по бумаге», либо сотрудники не знают регламентов. Признак низкой зрелости.
• «Ф» = «Д» ≠ «R» — внутренний процесс согласован, но не покрывает требования стандарта. Нужно либо доработать регламент, либо признать пробел и описать его как риск.
• «Ф» = «Д» = «R» — целевое состояние. Документация, реальность и эталон совпадают.

Инструментальный контроль среды разработки и сборки

Инструментальный контроль реализуется представителями ОС на площадке изготовителя. Это «полевой» этап: эксперты подключаются к рабочим системам, запускают анализаторы, смотрят журналы, проверяют целостность среды сборки.

Перечень контуров и окружений

До начала проверки изготовителю нужно подготовить описание всех контуров — где, что и как происходит:

Журналы аудита по сборочной среде (процесс 5.13)

• Регистрация действий — кто и что делал на билд-агентах: вход, выход, выполненные команды, изменения конфигурации.
• Целостность журналов — журналы защищены от модификации, передаются в отдельный SIEM или WORM-хранилище.
• Сроки хранения — определены и соблюдаются (типично 1 год; больше — для продуктов длительного жизненного цикла).
• Регулярная проверка — есть процедура чтения журналов (минимум — выборочные просмотры) с фиксацией в задачах.

Безопасный компилятор C/C++ (ГОСТ Р 71206-2024)

Если в составе разрабатываемого ПО есть код на C или C++, инструментальный контроль включает проверку соответствия используемых компиляторов требованиям ГОСТ Р 71206-2024. Это отдельный, технически самый сложный участок проверки.

Определение и три класса

Безопасный компилятор — компилятор, не вносящий в бинарный код программы ошибки, которых не было в исходном коде (п. 3.6 ГОСТ Р 71206-2024). Стандарт (пп. 4.7, 6) устанавливает три класса по объёму функций безопасности и допустимому замедлению. Самый низкий класс — третий, самый высокий — первый:

Пять функций безопасности (Таблица 1, раздел 5)

• Безопасные преобразования кода — компилятор не «оптимизирует» проверки на null, не сворачивает обнуление памяти, не превращает определённое поведение в неопределённое.
• Оповещение о неопределённых конструкциях — диагностики на UB, переполнения, неинициализированные значения, gотовые к включению в сборку как ошибки.
• Динамический контроль неопределённых конструкций (только 1 класс) — санитайзеры и runtime-проверки, встраиваемые в бинарный код.
• Управление распределением памяти — корректные стратегии аллокации/освобождения, без UB при ошибках выделения.
• Журналирование процесса трансляции — база данных компиляции в формате JSON для последующего аудита.
• Управление механизмами защищённости — поддержка ASLR, stack protector, CFI, FORTIFY и др.

Проверка соответствия (раздел 7)

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

Пять шагов подготовки изготовителя к проверке компилятора

Требования к фиксации использования компиляторов (п. 5.2.5 ГОСТ Р 71206-2024)

Безопасный компилятор должен фиксировать в базе данных компиляции для каждой единицы трансляции: рабочую директорию, имя файла, хэш-код файла, команду компиляции, имя выходного файла, хэш-код выходного файла, имена включаемых файлов и их хэш-коды. Формат — JSON, совместимый с базой данных компиляции clang. Хэширование — функция, определённая ГОСТ 34.11.

Пример: формат базы данных компиляции (Buildography, ИСП РАН)

Buildography — трассировщик Linux-процессов разработки ИСП РАН, собирающий сведения о выполнении сборки для последующего аудита. Один из вариантов реализации требований 71206 к фиксации сборки:

{
  "directory": "/root",
  "input": { "/root/main.c": "<hash>" },
  "commands": [ "gcc", "main.c" ],
  "component_commands": [
    {
      "command": [ "/usr/lib/gcc/x86_64-linux-gnu/11/cc1", "..." ],
      "dependencies": { "/etc/ld.so.cache": "<hash>" },
      "output": { "/tmp/ccUEQNfb.s": "<hash>" }
    },
    ...
  ],
  "utilities": [ { "path": "/usr/bin/x86_64-linux-gnu-gcc-11", "hash": "<hash>" }, ... ]
}

Анализ обеспеченности людьми

Шестое направление оценки — самое неочевидное и одновременно самое уязвимое. Идеальная документация и зрелый инструментарий не пройдут проверку, если у изготовителя нет сотрудников, способных это всё обслуживать. Подготовка строится вокруг штатного расписания, RACI-матрицы и доказательств компетентности.

Что предоставляет изготовитель

• Штатное расписание с должностями специалистов, задействованных в РБПО.
• Кадровая обеспеченность и количество вакантных позиций — особенно по ключевым ролям.
• Текучесть кадров — статистика за период; высокая текучесть ставит под вопрос воспроизводимость процессов.
• Полнота обеспеченности сотрудниками, обладающими нужными знаниями и умениями.
• RACI-матрица по процессам 5.1-5.25 — кто выполняет, утверждает, контролирует, обеспечивает инфраструктуру.
• Доказательства компетентности и обучения — план обучения, факты прохождения, участники, материалы.

Пример строки RACI-матрицы

Пример распределения для иллюстрации — конкретные роли и носители ответственности утверждаются Руководством по РБПО изготовителя.

Практический критерий готовности по людям

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

• Знает регламент — может пересказать своими словами, без подсматривания в текст.
• Может показать артефакт «в системе» — открывает CI/трекер/репозиторий и демонстрирует пример.
• Может объяснить входы/выходы и контрольные точки процесса.
• Понимает, как процесс применяется ко всей области действия — а не только к «любимому» продукту.

Критерии готовности по каждому процессу 5.X

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

• Полнота. Существует утверждённый регламент процесса, определены роли и ответственность, указаны применяемые системы и инструменты.
• Воспроизводимость. Процесс реально выполняется, и это подтверждается артефактами в системах — логами, задачами, отчётами инструментов, журналами.
• Охват области действия. Артефакты и выполнение процесса демонстрируются для любого продукта области действия (или по установленным правилам выборки внутри области действия).
• Управляемость. Определены события и периодичность пересмотра настроек, регламентов и результатов; есть журнал решений.
• Результативность. По результатам процесса принимаются решения, есть фиксация устранения выявленных недостатков и контроль закрытия.

Дополнительные документы, требуемые для сертификации

Помимо Руководства и 25 регламентов, на проверке потребуется набор связующих внутренних документов. Их часто упускают при подготовке — а без них экспертиза превращается в долгую сверку «вручную».

Спорные моменты и подводные камни методики

Несколько мест, где формулировки методики или общепринятая практика расходятся с буквой нормативных документов. Знать эти расхождения — значит быть готовым ответить на каверзный вопрос аудитора и не повторить чужих ошибок.

AppSec.Table.Top — комплементарный инструмент самооценки

AppSec.Table.Top — методология оценки зрелости практик безопасной разработки от Positive Technologies. Распространяется свободно через cyberorda.com. Не заменяет требования ГОСТ Р 56939-2024, но удобно дополняет их там, где стандарт оставляет свободу интерпретации.

Чем полезен в контексте подготовки к сертификации

ГОСТ Р 56939 формулирует требования к процессам как «должно быть»; AppSec.Table.Top формулирует то же самое как «как именно» — с разбиением каждой практики на инициативы и привязкой к уровням зрелости. Это даёт изготовителю понятный разговорный язык для:

• самодиагностики — где вы сейчас по каждой практике, на шкале уровней зрелости;
• планирования развития процессов — какие практики поднимать в первую очередь и до какого уровня;
• обоснования инвестиций — почему именно эта роль/инструмент/процесс должен появиться в этом году.

Структура методологии

По данным самой методологии (Таблица 1): 3 стадии, 9 процессов, 26 практик и 98 инициатив. Стадии соответствуют моментам жизненного цикла безопасной разработки:

Доступные артефакты на cyberorda.com

• PDF с полной методологией — описание всех 98 инициатив, входов, выходов, уровней зрелости.
• Excel-шаблон с примерами заполнения — для понимания того, как должна выглядеть «зрелая» оценка.
• Чистый Excel-шаблон — для самостоятельного заполнения «как у вас».
• Word-памятка v0.2 — короткое руководство по применению.
• Статья на Хабр — авторские пояснения к подходу и примеры из практики.

Связь с процессами ГОСТ Р 56939-2024 (приблизительная)