PGPro руководство по безопасной разработке ПО. Шпаргалка для методолога

Основные термины и определения

Регулятор – Федеральная служба по техническому и экспортному контролю (ФСТЭК России).

Аудиторы – представители органа по сертификации, проводящие проверку соответствия процессов безопасной разработки программного обеспечения.

Разработчик – компания-изготовитель ПО.

СЗИ – средства защиты информации.

Введение: Документ, который все ищут, но никто не хочет писать

Если вы методолог или отвечаете за внедрение процессов разработки безопасного ПО (РБПО), вы эту боль знаете не понаслышке.

Слева — жёсткие требования ФСТЭК России и ГОСТ. Справа — желание выстроить по-настоящему безопасные процессы. А посередине — пропасть, которую нужно заполнить ключевым документом компании: Руководство по безопасной разработке программного обеспечения (Руководство).

Это не просто «еще одна политика из папки департамента информационной безопасности». Это конституция всего вашего цикла разработки с учетом безопасности:

• Документ, который потребуют на старте для подачи заявки на сертификацию соответствия Регулятору.
• Его будут досконально изучать Аудиторы.
• На него должны будут опираться Разработчики.
• Это документ способный превратить набор разрозненных практик в цельную и управляемую систему.

Приказ ФСТЭК России от 26.04.2024 № 240 (с изм. от 30.06.2025) лишь перечисляет, что должно быть в Руководстве, но главный вопрос — как это написать, чтобы документ не пылился на полке, а стал реальным рабочим инструментом.

Давайте попробуем исправить это. Перед вами — практическая шпаргалка.

И главное!

Руководство по РБПО — это не отчет для Регулятора. Это интерфейс между миром стандартов и реальностью ваших команд. И от того, насколько он удобен и понятен, зависит, будет ли безопасность «встроена» в процесс или останется «пристроенной» к нему в виде множественных и болезненных доработок.

1. Зачем и как: превращаем формальность в рабочий инструмент

Зачем? Чтобы систематизировать разрозненные практики, донести единые правила до всех (включая новых сотрудников) и иметь основание для требований к командам и подрядчикам. Это ваш главный аргумент в споре «почему и как мы должны это делать».

Как? Пошаговый план для методолога:

1. Берите требования ФСТЭК/ГОСТ как чек-лист, а содержание пишите под свои GitLab/Jira, свои CI/CD, свои команды.
2. Не пытайтесь описать 25 процессов идеально за раз. Начните с уже готового: например, управление требованиями безопасности, правила безопасного кодирования, управление уязвимостями.
3. Утверждение Руководства — сигнал всему бизнесу о важности темы.
4. Недостаточно документ выложить во внутреннем портале компании или локальную папку на рабочем месте. Проведите семинар для сотрудников, сделайте лаконичную памятку для разработчиков, включите ознакомление с документом в программу адаптации.

2. Что требует регулятор: структура документа по ФСТЭК России

Согласно актуальному приказу ФСТЭК России от 01.12.2023 № 240 (ред. от 30.06.2025), Руководство по безопасной разработке ПО должно содержать семь обязательных информационных блоков (разделов). Это не рекомендация, а жесткое требование к документу. Однако даже если вы не планируете сертификацию соответствия процессов РБПО, эта структура — лучший готовый каркас. Давайте попробуем разобрать каждый пункт не как формальность, а как возможность решить реальную проблему.

Аннотация и содержание (оглавление)

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

1. Общие положения

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

1.1. Назначение документа (краткий ответ на вопрос «зачем это нужно?»).

1.2. Основные термины и определения (для однозначного толкования ключевых понятий).

1.3. Нормативные ссылки (полный список ГОСТов, приказов ФСТЭК России и внутренних документов компании, на которые есть ссылки в тексте).

🔐 Лайфхак для методолога:

Идеальным шаблоном для структуры этого раздела могут послужить вводные части самих ГОСТов — вы точно не ошибетесь.

2. Область действия

Этот раздел прямо закрывает требование №1 Регулятора:

✅ "Описание области действия руководства по безопасной разработке программного обеспечения".

Необходимо четко очертить границы применимости документа. Это не про «всех программистов компании».

Что важно определить:

• Продукты/проекты: какое ПО попадает под действие? (Все коммерческие продукты / только СЗИ / внутренние сервисы?).
• Жизненный цикл: какие этапы жизненного цикла охвачены и какие процессы внедрены?
• Аудитория: на кого распространяются требования? (Свои разработчики, тестировщики, архитекторы, аутсорсеры, подрядчики?).
• Важно не упустить: явно указать, что требования распространяются и на сторонние компоненты (open-source библиотеки), используемые в продуктах.

🔐 Лайфхак для методолога:

Начните раздел с краткого и недвусмысленного утверждения по модели: «Настоящее Руководство обязательно для применения всеми сотрудниками отдела Х и распространяется на все этапы жизненного цикла коммерческих продуктов компании Y». Избегайте расплывчатых формулировок.

3. Цели изготовителя

Раздел прямо закрывает требование №2:

✅ "Цели изготовителя в области создания безопасного программного обеспечения".

Избегайте абстракций вроде «повысить безопасность». Цели должны быть измеримыми, достижимыми и привязанными к бизнес-ценности.

Примеры конкретных целей:

• Раннее выявление: обеспечить систематическое выявление уязвимостей на этапах проектирования и разработки (реализация подхода Shift Left).
• Снижение рисков: снизить плотность критических и высоких уязвимостей в релизных версиях ПО.
• Управление ущербом: минимизировать потенциальный ущерб и издержки от инцидентов безопасности, связанных с дефектами ПО.
• Эффективность процессов: сформировать управляемый и документированный процесс исправления уязвимостей со средним временем закрытия не более N дней.

4. Принципы внедрения безопасной разработки ПО

Хотя этот раздел явно не перечислен в приказе ФСТЭК России № 240, он является критически важным и берет свое начало в разделе 4 «Общие требования к разработке безопасного ПО» ГОСТ Р 56939-2024.

Внедрение РБПО в Компании базируется на системном подходе, при котором информационная безопасность становится неотъемлемой частью жизненного цикла ПО, а не разовой проверкой перед релизом (реализация подхода Shift Left).

В этом разделе Руководства следует описать основополагающие подходы Компании к безопасности разработки, общую архитектуру защищенной среды, используемый инструментарий и ключевые меры защиты информации.

4.1. Ключевые принципы РБПО в Компании

• Shift Left («Сдвиг влево»): интеграция практик безопасности на самых ранних этапах (анализ требований, проектирование архитектуры).
• Комплексная защита инфраструктуры: создание и поддержание безопасной DevSecOps-среды, включая защищенные репозитории, доверенные конвейеры CI/CD и контролируемый инструментарий ("секретик": включая регламентацию требований к его обновлению).
• Автоматизация контроля безопасности: обязательное и регулярное использование инструментов статического (SAST) и динамического (DAST) анализа кода, а также анализа зависимостей (SCA).
• Управление зависимостями (SCA): строгий контроль сторонних библиотек и компонентов. Внедрение политик, исключающих попадание компонентов с известными уязвимостями (CVE) в сборки.
• Культура безопасности: регулярное обучение и повышение осведомленности всех участников процесса разработки (разработчиков, тестировщиков, аналитиков).
• Риск-ориентированный подход: проведение моделирования угроз и определение поверхности атаки для приоритизации мер защиты на основе оценки реальных рисков.
• Формализация и непрерывное улучшение: закрепление процессов, ролей и требований в организационно-распорядительных документах (основные - это регламенты процессов) и их планомерное совершенствование на основе метрик и обратной связи.

4.2. Интеграция в процессы и результаты

Ключевые принципы РБПО реализуются путем интеграции в существующие процессы разработки и CI/CD-конвейеры, что обеспечивает:

• Регулярность и обязательность: проверки безопасности инициируются автоматически при каждом коммите или сборке.
• Полная прослеживаемость: каждая обнаруженная уязвимость регистрируется в системе управления задачами (например, Jira) и сопровождается до полного устранения.
• Эффективность и скорость: автоматизация рутинных проверок не замедляет, а ускоряет поставку, позволяя быстрее выпускать безопасный продукт.

4.3. Инструментальный минимум

Для реализации указанных принципов в Компании используется инструментальная среда, обеспечивающая как минимум:

• Контроль версий исходного кода и артефактов (Git).
• Конвейер непрерывной интеграции и поставки (CI/CD).
• Система управления задачами и инцидентами.
• Набор инструментов для автоматизированного анализа безопасности кода (композиционный, статический, динамический анализ).

4.4. Меры защиты информации

Для защиты конфиденциальных данных (исходный код, секреты, отчеты тестирования) в рамках процессов РБПО реализуется комплекс мер, включающий:

• Разграничение прав доступа на основе ролей (принцип наименьших привилегий).
• Использование защищенных хранилищ для управления секретами (secrets management).
• Обязательное протоколирование и аудит значимых действий (регистрация событий).
• Регламентированное резервное копирование критичных артефактов.
• Действующие процедуры реагирования на инциденты ИБ.
• Регулярное обучение и проверка знаний сотрудников в области ИБ.

Успешное внедрение РБПО — это сочетание организационной культуры безопасности, автоматизированных процессов, защищенной инфраструктуры и их интеграции в ежедневную практику каждой команды разработки.

🔐 Лайфхак для методолога:

Не ограничивайтесь разделом 5 ГОСТ (требования к процессам). Внимательно изучите Раздел 4. Там заложены фундаментальные принципы организации работ, требования к безопасности инфраструктуры и инструментарию. Аудиторы проверяют не только документы и реализации процессов, но и соответствие вашей реальной практики этим базовым требованиям.

5. Перечень и описание процессов

Этот раздел прямо закрывает ключевое требование №3:

✅ «Перечень и описание реализованных процессов по безопасной разработке программного обеспечения».

Это сердце документа. Здесь нельзя ограничиться простым перечислением 25 подпунктов из раздела 5 ГОСТ Р 56939-2024. Задача — кратко показать, как эти общие требования реализованы и работают в вашей компании, с вашими инструментами, командами и регламентами.

🔐 Лайфхак для методолога:

Для удобства сопоставления в вашем Руководстве этот раздел можно также пронумеровать под номером «5» как в ГОСТ. Это создаст прямую визуальную и логическую связь между пунктами стандарта и вашим описанием, что оценят как разработчики, так и Аудиторы.

Для каждого процесса используйте единую структуру — «карточку процесса». Это обеспечит ясность, полноту и простоту проверки.

• Наименование процесса: лучше, чтобы полностью соответствовало названию из ГОСТ Р 56939-2024 (например, «Экспертиза исходного кода»).
• Цель процесса: зачем мы это делаем? Берите формулировку цели напрямую из соответствующего пункта стандарта - п.5.х.1 (например, «Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям»).
• Функции процесса: процесс нужно декомпозировать на функции (например, функция 5.x.1.1, функция 5.x.1.2 и т.д.).
• Входы, выходы, механизмы контроля (нормативная база, организационно-распорядительные документы компании), ресурсы, необходимые для реализации процесса.
• Основные требования и практики: это адаптированное описание того, как требования стандарта реализованы у вас. Опишите ключевые действия, ответственных, используемые инструменты. Рекомендуем для наглядности представить процесс в виде верхнеуровневой схемы. Нотация IDEF0 является отраслевым стандартом для этого и рекомендуется Аудиторами.
• Выходные артефакты (результаты): что является материальным доказательством выполнения процесса? (например, отчет экспертизы исходного кода, запись в системе управления задачами, заведенный баг).

Важные принципы описания:

• В Руководстве не нужно приводить детальные пошаговые инструкции. Достаточно «карточки процесса» и ссылки на соответствующий внутренний регламент процесса (например, "Регламент проведения экспертизы исходного кода ПО"), где описаны все тонкости, роли, шаги и т.п.).
• В перечне должны быть описаны все процессы, упомянутые в разделе 5 ГОСТ, которые реализованы в компании. Если какой-то процесс не внедрен, это должно быть явно обосновано в разделе «Область действия» или в данном разделе, с указанием планов по его внедрению.
• Визуализация общей картины: рекомендуется добавить в раздел общую схему, показывающую взаимосвязь всех процессов РБПО между собой и с этапами жизненного цикла ПО. Это поможет увидеть систему целиком.

Пример распределения процессов в нашей компании представлен на рисунке ниже. В вашей компании структура может отличаться.

Пример схем процесса в общем и внедрения процесса 5.9 "Экспертизы исходного кода".

Как итог, Раздел 5 превращает Руководство из сборника требований в рабочую карту вашей системы безопасности разработки. Каждая «карточка процесса» — это точка входа для сотрудника, чтобы понять суть, и для Аудитора — чтобы проверить соответствие.

🔐 Лайфхак для методолога:

Создайте таблицу - некий чек-лист внутреннего аудитора.

6. Распределение ролей и обязанностей

Раздел закрывает требование №4:

✅ "Распределение ролей и обязанностей, связанных с реализацией процессов по безопасной разработке программного обеспечения".

Кто за что отвечает? Это та часть, которая оживляет процессы. Безопасность разработки — это коллективная ответственность, а не задача исключительно службы ИБ. Каждая роль вносит свой вклад.

• Типовые роли: Методолог РБПО (это Вы, ответственный за РБПО), Техлид РБПО, Специалист по процессному управлению, Архитектор, Разработчик ПО, Тестировщик, DevSecOps-специалист, Специалист службы ИБ.
• Для каждой роли укажите основные процессы, в которых она принимает участие (включая частности).

🔐 Лайфхак для методолога:

Не ограничивайтесь текстовым описанием. Создайте наглядную таблицу (матрицу) распределения ответственности. Это лучший способ структурировать информацию и сделать её понятной для всех.

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

7. Система документации по РБПО

Раздел закрывает требование №5:

✅ "Перечень регламентов по безопасной разработке программного обеспечения в соответствии с подпунктами 5.1 - 5.25 пункта 5 требований по безопасной разработке".

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

Система документации в области РБПО выстраивается на двух уровнях:

1. Корпоративные регламенты процессов.

Это внутренние стандарты компании, описывающие требования к процессам (например, что требуется для проведения экспертизы исходного кода). Они едины для всех продуктов.

2. Специальные (продуктовые) документы.

Это документация, специфичная для конкретного ПО: архитектурные решения, описание поверхности атаки, отчеты тестирования, эксплуатационная документация для пользователя.

Практические рекомендации по построению системы:

• Связь с процессами: детальные требования к содержанию каждого регламента логично вывести в разделе 5 вашего Руководства. Каждому процессу — свой регламент (или группа регламентов).
• Гибкость, а не бюрократия: количество документов не догма. Несколько смежных процессов (например, композиционный анализ и контроль цепочек поставок) можно описать в одном регламенте. Главное — покрыть все требования.
• Электронный вид — норма: Документы могут и должны существовать в электронной системе при условии обеспечения контроля версий, значимости и доступности.

Раздел 6 Руководства показывает прямую связь между высокоуровневыми принципами, конкретными процессами и реальными документами, которые ответственные сотрудники должны знать.

🔐 Лайфхак для методолога:

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

8. Правила внутренних проверок

Раздел закрывает требование №6:

✅ "Правила и требования, относящиеся к планированию и проведению внутренних проверок реализации требований по безопасной разработке программного обеспечения".

Если предыдущие разделы описывают, как должно быть, то этот — механизм, который отвечает на вопрос: «А так ли это на самом деле?» Это ваша система самодиагностики и главный инструмент непрерывного улучшения.

Цель внутренних проверок (аудитов) — провести независимую оценку для ответа на три ключевых вопроса:

1. Эффективность: достигают ли процессы РБПО своих целей.
2. Результативность: выполняются ли все запланированные действия?
3. Соответствие: соблюдаются ли требования ГОСТ и внутренних регламентов?

Опишите четкий и прозрачный процесс, который нельзя будет трактовать двояко.

• Периодичность.

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

• Методика проведения.

Как именно проходит проверка? Нужно проверить не только бумаги, но и реальную практику. Например, интервью с сотрудниками, наблюдение за рабочими процессами, анализ отчетов инструментов.

• Ответственные.

Кто проводит? Методолог РБПО или назначенная внутренняя аудиторская группа. Для большей объективности можно привлекать сторонних аудиторов.

Кому отчитываться? Результаты с выводами и рекомендациями направляются руководству компании (например, Техническому директору).

• Итоговый результат.

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

Проверка ради проверки — пустая трата времени. Пропишите в Руководстве, что результаты являются основой для развития всей системы:

1. Совершенствование Руководства по РБПО.
2. Актуализация рабочих инструкций и регламентов процессов.
3. Обновление учебных программ и материалов для сотрудников.
4. Все значимые изменения, внесённые по итогам проверок, согласовываются и в обязательном порядке доводятся до сведения всех заинтересованных сотрудников.

Прописанные в этом разделе правила превращают внутренний аудит из формальности в двигатель прогресса. Они создают замкнутый цикл: «Планируем -> Внедряем -> Проверяем -> Улучшаем», который и является признаком зрелого процесса Security by Design.

9. Действия по улучшению

Раздел закрывает требование №7:

✅ "Описание действий, направленных на улучшение процессов, связанных с безопасной разработкой программного обеспечения".

Процессы не статичны. Этот раздел показывает зрелость.

9.1. Источники для улучшений

Откуда брать идеи? Улучшения не возникают из воздуха. В Руководстве следует прописать каналы, по которым поступают сигналы для изменений. Например:

1. Результаты внутренних проверок (раздел 6 Руководства). План корректирующих действий из акта аудита — это прямой и главный вход для улучшений.
2. Анализ инцидентов безопасности. Каждый инцидент, связанный с уязвимостью в ПО, должен анализироваться не только для «закрытия дыры», но и для ответа на вопрос: «Как изменить процесс, чтобы это не повторилось?».
3. Обратная связь от команд разработки и тестирования. Разработчики и инженеры — главные пользователи процессов. Их предложения по оптимизации — бесценны.
4. Изменения в нормативной базе. Появление новых приказов регуляторов, ГОСТ, отраслевых стандартов.
5. Появление новых угроз и уязвимостей. Анализ тенденций (например, рост атак на цепочки поставок) должен приводить к пересмотру соответствующих процессов (композиционный анализ и контроль цепочек поставок).
6. Внедрение новых технологий и инструментов. Переход на новый фреймворк или платформу требует адаптации требований безопасного кодирования и тестирования.

9.2. Процедура

Кто инициирует изменения в руководстве? Как они согласуются и утверждаются?

9.3. Участие в экспертных сообществах

Данный пункт раздела 9 Руководства носит рекомендательный характер.

Для обеспечения проактивного (опережающего) развития процессов РБПО и адаптации к изменяющемуся ландшафту угроз компаниям рекомендуется активно участвовать в работе ключевых профессиональных площадок. Например:

1. Центр компетенций ФСТЭК России и ИСП РАН (включая проекты «Центр исследований безопасности системного ПО» и «Унифицированная среда разработки безопасного отечественного ПО»).
2. Проектный комитет №2 «Безопасная разработка» на базе Технического комитета по стандартизации ТК 362 «Защита информации».
3. Профильные конференции и форумы (например, ТБ Форум, открытая конференция ИСП РАН, Positive Hack Days и др.).

Задачи участия могут быть следующими:

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

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

🔐 Лайфхак для методолога:

Создайте в этом разделе простую блок-схему (например, в нотации BPMN), которая наглядно покажет путь улучшения: от «Источника» через «Инициацию» и «Согласование» к «Утверждению» и «Внедрению». Это сделает процедуру кристально понятной для всех.

3. Где живет руководство и как им пользоваться?

<>Руководство по РБПО — это стратегический и обязательный к исполнению документ.

Его статус и область влияния:

✅ Обязательно для всех участников разработки. От архитектора и тимлида до стажера-разработчика. Его требования — не рекомендация, а стандарт работы.

✅ Распространяется на подрядчиков и open-source компоненты. Это критически важно! Требования рекомендовано формально закрепить в договорах с подрядчиками: «Исполнитель обязуется соблюдать требования Руководства по безопасной разработке ПО Заказчика при выполнении работ». Анализ безопасности сторонних библиотек и контроль цепочек поставок — прямое следствие этого принципа.

✅ Интегрируется во все смежные процессы. Руководство не существует в самостоятельно. Оно становится источником требований для регламентов процессов и инструкций по настройке инструментов проверок безопасности в CI/CD, матриц ответственности в проектах, чек-листов внутренних проверок, критериев код-ревью (внедрение правил безопасного кодирования), политик информационной безопасности компании (конкретизируя их применительно к разработке).

Заключение: Итоговая шпаргалка методолога

Руководство по безопасной разработке ПО (РБПО)– обязательный локально-нормативный документ Компании, требуемый в соответствии с приказом ФСТЭК России от 01.12.2023 № 240 (с изм. от 30.06.2025) при внедрении процессов разработки безопасного ПО в соответствии с ГОСТ Р 56939-2024.

1. Структура — священна. Семь (7) обязательных пунктов требований из приказа ФСТЭК России равно 7 обязательных разделов Руководства — ваш бесплатный и идеальный план.

2. Суть — в адаптации. Не переписывайте абстрактные формулировки из ГОСТ. Опишите, как каждая практика реализована именно в вашей компании, с вашими инструментами и в ваших процессах.

3. Не забыть про людей. Распределите роли и обязанности (методолог по РБПО, разработчик ПО, специалист по процессному управлению, специалист по тестированию и т.д.). Без персональной ответственности даже лучший процесс не живет.

4. Единообразное описание процессов. Для каждого создайте «карточку процесса» по шаблону:

• Название и цель (Зачем мы это делаем?)
• Ответственные роли (Кто владеет, кто выполняет?)
• Требования/Практики (как) (Конкретные действия на основе ГОСТ)
• Выходные артефакты (результат) (Что должно получиться в итоге?)

Рекомендация: Визуализируйте процессы в нотации IDEF0.

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

6. Интеграция в инструменты. Требования должны быть вшиты в CI/CD, чек-листы код-ревью и тикет-системы. Если процесс не автоматизирован, он будет нарушаться.

7. Внедрение, а не только публикация. Разработка документа — лишь 50% работы. Вторые 50% — это его активное внедрение: обучение, воркшопы, включение в программы адаптации.

Итого, Руководство по безопасной разработке ПО — это не финальный отчет, а отправная точка. Создав живой, релевантный и встроенный в процессы документ, вы закладываете фундамент не для формального compliance, а для настоящей культуры Security by Design.

Коллеги, удачи в построении вашей системы.

Автор:
Матвейчук Мария, старший инженер по информационной безопасности.

Ключевые слова