# Безопасная разработка ПО: от процесса к документам

**Практический конспект по материалам занятий курса «Разработка безопасного программного обеспечения» (РБПО)**

Автор и лектор: **Пиков Виталий Александрович** — эксперт технического комитета по стандартизации ТК 362 «Защита информации», автор линейки курсов по безопасной разработке, практик внедрения процессов РБПО на предприятиях-разработчиках.

Материалы, методика и контакты: **pikov.art**

*Сентябрь 2026. Конспект составлен по живым занятиям; нормативные реквизиты и редакции документов сверяйте с официальными публикациями ФСТЭК России и Росстандарта — нормативная база РБПО активно меняется.*

---

## 1. Священная триада: люди — инструменты — процессы

Главная формула курса (по опыту Ивана Шаркова — эксперта, одним из первых в стране проводившего сертификацию предприятий по требованиям безопасной разработки):

> **Люди + инструменты + процессы.** Если триада реально работает — артефакты рождаются сами. Регламент «намазывается сверху, как маслице».

- Безопасная разработка — **не регламент**. Это специалисты, которые ею занимаются; инструменты, встроенные в конвейер разработки; процессы, которые их связывают.
- Живой процесс **не может не оставлять артефактов**: журналы и логи инструментов, разметка (триаж) результатов статического анализатора, задачи в Jira, страницы в Confluence, переписка по найденным дефектам. «Я дышу воздухом — я не могу не дышать».
- Отчётность перед заказчиком **собирается из артефактов процесса**, а не пишется с нуля. Сочинять артефакты не нужно — и опасно: сочинённое не переживёт ни сертификацию, ни серьёзный аудит.

## 2. Почему чужие шаблоны не работают

> «Чужой регламент — как чужие очки: надеть можно, но они вам не подойдут».

- **Идеальных регламентов в природе не существует.** «ГОСТированных» шаблонов внутренних документов по безопасной разработке — тоже: стандартов и правил оформления к руководству по РБПО и регламентам нет.
- Правильная последовательность: **сначала построить процесс — потом описать его документом.** Текст регламента под готовый процесс — техническая задача, которую решает ИИ-ассистент (см. раздел 4).
- Формальный документ «для галочки» не решает проблему, а откладывает её: следующий вопрос будет «оно мне не подошло — что делать?». При формальном подходе **сертификацию процесса вы не пройдёте, и серьёзный аудит — тоже**.
- Регламент, который никто не читает, — мёртвый, даже если в нём 100 страниц и конфигурации до последнего винтика. Детализация не заменяет встроенности документа в реальную работу.

## 3. Карта нормативки: что есть и чего нет

### Что есть

| Документ | Что даёт |
|---|---|
| **ГОСТ Р 56939-2024** «Защита информации. Разработка безопасного ПО. Общие требования» | Базовый стандарт: 25 процессов РБПО; внутренние документы организации — порядка 22 регламентов и 3 планов; п. 4.12 допускает свод регламентов в единое руководство. В каждом процессе прописан минимум содержания регламента: «должен включать следующие положения» — **больше можно, меньше нельзя** |
| **ГОСТ Р 71207-2024** (статический анализ) | Стандарт, которым регулятор особенно дорожит: ФСТЭК долго его готовила и проводила испытания статических анализаторов |
| **Приказы ФСТЭК России с мерами защиты: № 17 (ГИС), № 21 (ПДн), № 31 (АСУ ТП), № 239 (значимые объекты КИИ)** | Таблицы мер в приложениях — источник понятия «функции безопасности» (раздел 7). Требования безопасной разработки прикладного ПО для ЗОКИИ — в приказе № 239. Проверяйте действующие редакции |
| **Приказ ФСТЭК России № 119** (требования безопасности информации к операционным системам) + профили защиты ОС | ОС в глазах регулятора — однозначно средство защиты информации. Профили для несекретных продуктов открыты. Приказ планируют обновлять — следите за редакцией |
| **Приказ ФСТЭК России № 76** (уровни доверия) | Уровни доверия к СЗИ; типовой целевой уровень для прикладных продуктов — 4-й |
| **Сертификация процессов безопасной разработки** (в лекции — «240-й приказ») | Сертификат процессов БР организации; таких организаций в стране — девять. Подразумевает рамочное руководство с границей области действия (раздел 8) |
| **ГОСТ Р ИСО/МЭК 27001** (СМИБ) | Вторая линия, «откуда приходит» безопасная разработка: сертификация систем менеджмента ИБ — путь крупных компаний и участников международной торговли |

### Чего нет — и это аргумент

- **Нет ГОСТа по композиционному анализу (SCA).** Проект разрабатывался, получил более тысячи замечаний, работа приостановлена. Есть проект национального стандарта — на него можно опираться как на фактуру.
- **Нет ГОСТа по динамическому анализу.**
- **Нет стандартов и шаблонов на внутренние документы** организации по РБПО (руководство, регламенты).
- **Не существует сертифицированных инструментов безопасной разработки** — при том что требования к применению инструментов регулятор предъявляет. Честный вопрос, который стоит задавать экспертам и регулятору.

> **Правило свободы методик:** там, где процедура не регламентирована ни ГОСТом, ни методикой регулятора, организация **вправе самостоятельно выбирать методики**, включая мировой опыт (OWASP и другие best practices), — и фиксировать обоснование выбора. По каждому пункту требований заказчика держите наготове аргументацию: «это регламентировано — делаем так; это не регламентировано — применяем выбранную методику, обоснование такое-то».

## 4. Методика: генерация регламентов с помощью ИИ

Отработанный на курсе порядок. Работает с любой сильной языковой моделью (из прозвучавшего на занятиях: Claude Code, «Алиса Про», Qwen; ориентир затрат на профессиональные ИИ-инструменты — порядка 300 $/мес).

1. **Контекст предприятия.** Опишите модели реальную картину: языки программирования, состав и роли команды, устройство конвейера разработки — как разработка происходит на самом деле. Чем подробнее, тем лучше результат. Закрытые сведения — обезличьте.
2. **ГОСТ в контекст.** Загрузите ГОСТ Р 56939-2024 целиком, **обязательно указывая год «-2024»** — иначе рискуете получить документ по устаревшей редакции 2016 года.
3. **Попроцессно, а не всё сразу.** Не просите «сделай все документы»: запрашивайте по одному регламенту за цикл, итеративно. Ориентир объёма — ~22 регламента и 3 плана.
4. **Свод в руководство.** Не начинайте с «сделай руководство» — без готовых регламентов у модели нет контекста. Сначала регламенты, затем свод в единое руководство (п. 4.12 ГОСТа это допускает). На выходе — и регламенты (можно оформить и поставить на учёт), и руководство на подпись руководителю.

Качество на выходе — уровня «пару слов поправлю — и можно идти подписывать» (оценка рецензента из крупной корпорации).

> ⚠️ **Главная оговорка методики:** документ, сгенерированный без реального процесса, — формальность, которая не выдержит ни сертификации, ни аудита. Генерируйте регламент **из действительного состояния** процесса, а не вместо него.

**Кейс о силе инструмента:** двухдневный отраслевой курс (фото слайдов + аудиозапись) языковая модель за одну ночь превратила в полноценный сайт-конспект: ~140 слайдов, практические задания, навигация. Проблемы «изготовить документ» больше не существует — ценность сместилась в реальные процессы и владение инструментами.

## 5. Работа с заказчиком и проверяющим

### Пункт ТЗ «в соответствии с требованиями безопасной разработки»

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

1. Предусмотреть в ТЗ **отдельный этап**: исполнитель направляет заказчику **проект методики оценивания зрелости** реализации процесса безопасной разработки.
2. После согласования методики — **комиссия** с участием представителей заказчика, работающая на территории исполнителя.
3. По результатам — **подписанный акт**, который становится подтверждением выполнения пункта ТЗ.

Каждый пункт ТЗ — деньги заказчика; их надо уметь «списать» доказуемо.

### Требования, вписанные в договор

Формулировки вроде «предоставить руководство по РБПО и N регламентов» в договор обычно вписывает **конкретный человек** на стороне заказчика — при нынешней нормативной неопределённости это его личные пожелания. Тактика:

- **Выйти напрямую на автора требований** — быстро, любыми доступными каналами.
- Спросить прямо: «В безопасной разработке сейчас высокая нормативная неопределённость. Подскажи, как сделать так, чтобы ты был доволен» — и **записывать**: полученные критерии приёмки и есть реальные требования.
- Если заказчик нанимает стороннюю компанию для проверки документов — мнение конкретного проверяющего станет догмой: готовьте документы под его фактические требования, а не под универсальный образец.

### Диалог с проверяющим и регулятором

- Разговаривайте **фактурой**: стандарты; где стандарта нет — проекты национальных стандартов и мировые best practices; позиции отраслевых рабочих групп.
- **«Больше можно — меньше нельзя»**: минимум содержания регламентов задан ГОСТом; при моделировании угроз БДУ ФСТЭК (bdu.fstec.ru) — обязательный минимум, мировые базы (например, база АО «Эшелон») — желательное расширение.
- **Никогда не говорите ФСТЭК «ГОСТ необязателен».** Формально это так (обязательность ГОСТу придаёт решение уполномоченного лица), но регулятор относится к своим стандартам ревностно — особенно к ГОСТу по статическому анализу. Такой аргумент гарантированно портит диалог.

## 6. Как обоснованно сокращать перечень процессов

Критерий один: **исключение процесса не должно влиять на безопасность продукта** — так, чтобы ни один скептик не показал обратного.

- **Нельзя**: «слить» динамический анализ в проекте на C/C++ («у нас не актуален») — язык с ручной работой с памятью без динамики/фаззинга не бывает; испытательная лаборатория такое обоснование не примет. Нельзя исключать процесс потому, что «нет специалистов», — либо обоснование невлияния, либо стройте процесс и учите людей.
- **Можно** (с обоснованием): пример рабочей группы, адаптировавшей ГОСТ к ведомственным работам, — перечень сокращён с 25 до 14 процессов, но каждое исключение обосновано: требования зафиксированы в ТЗ на этапе эскизного проекта и не меняются в ходе ОКР — процесс управления требованиями «подвинут»; динамический анализ приравнен к фаззингу; сопровождение закрыто ведомственным порядком доработки изделий. Важно: у ведомства такой подход опирается на свою нормативную вертикаль — у коммерческого разработчика этой опоры нет, планка обоснования выше.

## 7. Функции безопасности: как найти их в своём продукте

По разъяснению Виталия Вареницы (АО «Эшелон», руководитель направления сертификации, начальник испытательной лаборатории):

- **Функции безопасности — всё, что сформулировано как меры защиты в приказах ФСТЭК** (№ 17, 21, 31, 239 — таблицы в приложениях). Если функция явно реализована в продукте — вы средство защиты информации.
- **Метод**: пройтись по каждому требованию приказов как по чек-листу, зная продукт и в функционале, и «под капотом»: где шифрует, где хеширует, где матрица доступа, где вход по логину/паролю.
- **Ловушка интерфейса**: даже если вы опираетесь на встроенные механизмы сертифицированной ОС (например, Astra Linux), наличие у продукта интерфейса, который умеет эти механизмы применять, **тоже втягивает в сертификацию**.
- Переквалификация («это не идентификация, а назначение роли — пользователь уже вошёл в ОС») испытательной лаборатории, скорее всего, не понравится.
- Собственная ОС — отдельная история без вилок: **ОС сертифицируется как СЗИ** по приказу № 119 и профилям защиты; понятия «сертификация прикладного ПО на ОС» не существует.

## 8. Сертификат процессов безопасной разработки: границы и расширение

- Сертификат процессов БР **не покрывает автоматически всё**, что делает организация: под него подразумевается **рамочное руководство** с перечнем охваченных продуктов, команд и конвейеров. Продукта нет в руководстве — изменения пойдут «в полный рост» через испытательную лабораторию, сертификатом «козырнуть» не получится.
- **Держите руководство актуальным** — это действующая граница области сертификата, а не формальность.
- **Расширение области на новый продукт**: официальное письмо в свой орган по сертификации («ввиду вновь сложившихся обстоятельств просим разъяснить порядок актуализации области действия сертификата…»). Реалистичные ожидания: это новая оценочная процедура и затраты; смягчает то, что орган организацию уже знает — для «своих» действует упрощённый режим.
- Не путайте **сертификацию продукта** (например, ОС как СЗИ) и **сертификацию процесса** — это две разные процедуры.

## 9. Архитектура комплекта документов

> «Всё, что редко меняется, удобно объединять; всё, что часто меняем, желательно разделять».

- **Редко меняемое — наверх**: руководство по безопасной разработке утверждается один раз и фигурирует везде.
- **Часто меняемое — вниз**: регламенты живут как версионируемые внутренние документы.
- Образцовая практика (Дмитрий Шмойлов, «Лаборатория Касперского»): регламенты — живые электронные документы, по которым реально работают; для органа по сертификации — «готовы нажать кнопку, и через пять минут принести весь комплект в бумажном виде».
- Два полюса оформления, между которыми каждый выбирает баланс: «живой документ разработчиков, а не документ ради документа» (Вартан Падарян, ИСП РАН) — против классического документооборота с номерами, подписями и листами ознакомления, дающего ответственность и ссылочность.

## 10. Вопросы с занятий — короткие ответы

**— Обещан шаблон руководства по РБПО. Где его взять?**
Готовые материалы получить можно (включая реально внедрявшееся руководство), но чужой документ не решит задачу — его всё равно придётся переписывать под свой процесс. Стройте процесс, регламент сгенерируете.

**— Зачем руководителю технические темы вроде динамического анализа?**
Спросят обязательно — и «что-то видел, кликал» не ответ. Руководитель должен понимать, что произойдёт при внедрении, чтобы управлять процессом. К лидерам отрасли на курсы по фаззингу приезжают люди совсем не из разработки — это норма.

**— Заказчик (ЗОКИИ 1-й категории) требует через договор десятки регламентов. Что делать?**
Выйти на автора требований и выяснить реальные критерии приёмки; отчётность собирать из артефактов работающего процесса; по нерегламентированным видам работ — своя методика с обоснованием.

**— Существуют ли официальные шаблоны документов?**
Нет. Анонсировано размещение типовых шаблонов на портале сообщества **брпо.рф** (следите за публикацией); там же есть режим экспертного доступа к документам — но на практике его выдают неохотно, планировать внедрение в расчёте на него не стоит.

**— Можно ли вместо 22 регламентов сделать одно руководство?**
Можно (п. 4.12 ГОСТа). Генерировать всё равно попроцессно, потом сводить.

**— Артефакты надо сочинять?**
Нет. Работающий процесс оставляет их сам. Сочинённые артефакты без процесса не переживут проверку.

**— Как оформить процессы документально?**
Каркас — минимум из ГОСТа («регламент должен включать следующие положения»), наполнение — ваше реальное состояние: кто, чем, на каких инструментах, в каком конвейере.

## 11. Ресурсы и ориентиры

- **ГОСТ Р 56939-2024** — настольный стандарт; читать вместе с ГОСТ Р 71207-2024 (статанализ).
- **БДУ ФСТЭК России** — bdu.fstec.ru: обязательный минимум при моделировании угроз.
- **брпо.рф** — портал сообщества РБПО: анонсированы типовые шаблоны регламентов; экспертный доступ к документам.
- **ИСП РАН** — курсы (в т.ч. по фаззингу), орган по сертификации; «законодатель мод» направления.
- **OWASP** и мировые методологии — фактура там, где национального стандарта ещё нет.
- **PVS-Studio** — статический анализ (отдельное занятие курса).
- **pikov.art** — авторская методика подготовки предприятия к внедрению процесса РБПО (проверена на практике на крупном предприятии-разработчике СЗИ), материалы и контакты автора. По вопросам внедрения, документов и подготовки к сертификации — обращайтесь.

---

### Пять тезисов на стену

1. **Люди — инструменты — процессы.** Остальное приложится.
2. **Сначала процесс, потом документ.** Никогда наоборот.
3. **Больше можно — меньше нельзя.**
4. **Артефакты не сочиняют** — их оставляет живой процесс.
5. **С регулятором — фактурой**, и никогда не говорите ФСТЭК, что ГОСТ необязателен.