# EP01 — История SDL и создания ГОСТ: PDF, полный транскрипт и проверка редакции 2016

Доработка от **6 сентября 2026 года**: первоначальный разбор двух PDF дополнен полным транскриптом вебинара 02.07.2025, проверкой локального текста ГОСТ Р 56939-2016 и повторной проверкой официальных карточек. Основной исторический блок расширен до слайдов 7–13; выпуск рассчитан на **29 слайдов и 53:00**. Ниже сохранены исследование методологий и разбор прежних расхождений, а также добавлены сведения, которые не были раскрыты на слайдах архивного доклада.

## 1. Что дают эти источники

Обзор методологий показывает несколько параллельных способов организации безопасной разработки и позволяет обсуждать содержание подходов, а не только даты. Доклад об истории ГОСТ даёт предпосылки, последовательность подготовки редакций и сведения о публичном обсуждении. Вместе они существенно укрепляют исследовательский вопрос серии: какие инженерные задачи общие, как различается организация работ и какие свидетельства ожидаются?

При этом сходство практик и заявленная совместимость с международными документами ещё не доказывают прямого заимствования, полной эквивалентности или уникальности ГОСТ.

### Источники

**MLR — 27 страниц.** Arina Kudriavtseva, Olga Gadyatskaya, *Secure Software Development Methodologies: A Multivocal Literature Review*. В файле указаны arXiv:2211.16987v2, 4 July 2023 и статус **In submission**. Не называем эту копию окончательной рецензируемой журнальной публикацией. [Публичная версия v2](https://arxiv.org/html/2211.16987v2).

```text
V:\Yandex.Disk\_МАСКОМ\2025 Вебинары по РБПО с PVS-STUDIO\2025.07.02 Вебинар1 по РБПО с PVS-STUDIO\2025.07.02 Вебинар1 по РБПО с PVS-STUDIO (РАЗДАВАТЬ)\Secure Software Development Methodologies. A Multivocal Literature Review - 2023.pdf
```

**GOSTH — 26 страниц.** Титульное название: *«История создания и актуальное состояние РБПО в России. ГОСТ Р 56939-2016/24»*. На титуле — **Вареница Виталий**, оформление НПО «Эшелон». Метаданные фиксируют экспорт PDF 02.07.2025; это дата файла, не доказанная дата первоначального выступления. Техническое поле Author в метаданных не подменяет автора на титуле.

```text
V:\Yandex.Disk\_МАСКОМ\2025 Вебинары по РБПО с PVS-STUDIO\2025.07.02 Вебинар1 по РБПО с PVS-STUDIO\2025.07.02 Вебинар1 по РБПО с PVS-STUDIO (РАЗДАВАТЬ)\История+создания+РБПО+ГОСТ+Р+56939-202x.pdf
```

В этой доработке точные файлы из подпапки «РАЗДАВАТЬ» доступны и изучены. Прежнее ограничение чтения других облачных файлов не распространяется на эти копии. Видео по-прежнему не просматривалось: выступление изучено по предоставленному тексту. Номера страниц ниже — физические страницы PDF, начиная с первой.

**TRANS — полный предоставленный транскрипт.** Файл `Транскрипция 2025.07.02 Вебинар 1 по РБПО с PVS-STUDIO.mp4.txt` находится непосредственно в EP01; временные метки идут от 00:00:05 до 02:07:28. Исследование истории опирается на полные блоки 00:08:01–00:40:46, 00:49:47–00:54:46 и 01:03:58–01:13:48, а не на автоматическое резюме. Все реплики помечены «Участник 1»: имена говорящих определяются по представлению и передаче слова, автоматическая диаризация не подтверждена. Это расшифровка устного источника с ошибками распознавания, не официальный протокол разработки стандарта.

```text
V:\pikov.art\56939-lections\EP01\Транскрипция 2025.07.02 Вебинар 1 по РБПО с PVS-STUDIO.mp4.txt
```

**G16 — текст редакции 2016.** В архиве найдена отдельная копия на 24 PDF-страницах. Извлечён текст всех страниц; для исторических выводов проверены предисловие, оглавление, разделы 1, 2, 4 и структура раздела 5, приложение А. Предисловие, оглавление и пп. 4.2–4.8 дополнительно просмотрены визуально. Это рабочая архивная копия; даты и организация-разработчик сверены с [официальной карточкой Росстандарта](https://protect.gost.ru/gost/details/286a588e-4a6a-4899-88f7-3c370dea1e1d).

```text
V:\Yandex.Disk\_МАСКОМ\2025 Вебинары по РБПО с PVS-STUDIO\2025.07.02 Вебинар1 по РБПО с PVS-STUDIO\2025.07.02 Вебинар1 по РБПО с PVS-STUDIO (РАЗДАВАТЬ)\ГОСТ Р 56939-2016 (редакция 2016).pdf
```

## 2. Карта 28 методологий: какую дату мы показываем

MLR, Table II, PDF-с. 5: 14 отраслевых, 6 государственных, 8 академических позиций — подсчёт строк по классификации авторов. Это выборка исследования. Она не устанавливает общее количество методологий или распространённость подходов в мире.

**В таблице ниже записаны годы публикаций, рассмотренных обзором.** Они не являются автоматически датами возникновения методов. Различие прямо пояснено на PDF-с. 4. Шкала слайда 5 использует шесть отобранных и явно подписанных вех: 2004, 2006, 2012, 2017, 2020 и 2022 годы.

| Группа обзора | Рассмотренный подход / публикация | Год в Table II |
|---|---|---:|
| Industry | Microsoft SDL, книга / описание в выборке | 2006 |
| Industry | McGraw / Touchpoints, книга в выборке | 2006 |
| Industry | CLASP | 2006 |
| Industry | Microsoft SDL guidance v5.2 / SDL-Agile | 2012 |
| Industry | SAFECode, рассматриваемая редакция | 2018 |
| Industry | Google, Building Secure and Reliable Systems | 2020 |
| Industry | BSA framework | 2020 |
| Industry | SAP Secure Software Development Lifecycle | 2020 |
| Industry | ReBIT Application Security Framework | 2020 |
| Industry | OWASP SAMM v2.0 | 2020 |
| Industry | Cisco SDL, white paper | 2021 |
| Industry | Citrix SDL, white paper | 2021 |
| Industry | BSIMM12 | 2021 |
| Industry | GE SDL | 2022 |
| Government | Grip on Secure Software Development | 2015 |
| Government | CSA Singapore Security-by-Design | 2017 |
| Government | SSDLC guidelines Malaysia | 2020 — расхождение со ссылкой [35], см. §5 |
| Government | Security in SDLC Romania | 2021 |
| Government | NIST SP 800-218 / SSDF 1.1 | 2022 |
| Government | NIST SP 800-160, публикация в выборке | 2022 |
| Academia | Jones & Rastogi, Secure Coding: Building Security into the Software Development Life Cycle | 2004 |
| Academia | Apvrille & Pourzandi, Secure Software Development Life Cycle Process | 2005 |
| Academia | The Secure Software Development Model (SSDM) | 2006 |
| Academia | The Integrated Security Development Framework (ISDF) | 2010 |
| Academia | Secure Software Development Model: A Guide for Secure Software Life Cycle | 2010 |
| Academia | Secure Software Development: a Prescriptive Framework | 2011 |
| Academia | Framework for Development of Secure Software | 2013 |
| Academia | Methodology for Enhancing Software Security During Development Processes | 2018 |

Проверки отдельных вех: Microsoft подтверждает внедрение SDL в процесс разработки с **2004** года, что совместимо с датой книги **2006**, но требует разных подписей. [История Microsoft SDL](https://www.microsoft.com/en-us/securityengineering/sdl/about). Выпуск SAMM v2 подтверждён объявлением **31.01.2020**. [OWASP SAMM release](https://owaspsamm.org/blog/samm2-release/). SSDF 1.1 опубликован как NIST SP 800-218 в 2022 году; это версия, выбранная в серии. [NIST final](https://csrc.nist.gov/pubs/sp/800/218/final).

## 3. Разные способы организации работы

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

| Подход | Что выделено в обзоре | Вопрос для нашей команды | PDF-с. |
|---|---|---|---|
| Microsoft SDL | Координация инженерных практик, поддержка руководства и обучение | Кто поддерживает программу и обеспечивает её выполнение? | 10 |
| Touchpoints | Управление рисками, архитектурный анализ, анализ кода и накопление знаний | Какие риски связывают архитектуру и реализацию? | 10 |
| CLASP | Связь действий с ролями, метрики, рабочие листы | Кто выполняет конкретную практику и как выбирается улучшение? | 10, 17 |
| SDL-Agile | One-time, every-sprint, bucket | Что делается один раз, в каждом спринте и периодически? | 9, 16 |
| SAFECode | Внедрение программы в существующую культуру и разработку | Как согласовать практики с действующим способом работы? | 11, 18 |
| Grip on SSD | Требования заказчика, риски, взаимодействие сторон | Как согласуются ожидания заказчика и разработчика? | 13, 21 |
| NIST SSDF | Организационная готовность, люди, процессы, инструменты и критерии проверок | Что должно быть подготовлено до регулярного выполнения работ? | 14 |
| SAMM | Развитие организационных возможностей и уровни зрелости | Как определить следующее улучшение программы? | 2, 12 |
| BSIMM | Практики, наблюдаемые в организациях | Что показывает наблюдение за отраслью и что из этого применимо здесь? | 12–13 |

На слайде 6 оставлены четыре короткие характеристики; остальные — материал для подготовки и ответов на вопросы. SAMM и BSIMM не превращаются в одинаковые предписывающие lifecycle-процессы. Число перечисленных активностей не используется как рейтинг безопасности.

## 4. Что даёт анализ практик и эффективности

MLR распределяет технические практики между **уровнем организации**, **сквозной работой в жизненном цикле** и **конкретными стадиями проекта** (PDF-с. 4, Tables III–IV, с. 6–9). Это полезнее для нашей серии, чем одно лишь перечисление инструментов: один процесс требует подготовленных людей, другой — повторяемого исполнения, третий — связей между стадиями.

Раздел IV, PDF-с. 16–22, рассматривает девять связанных нетехнических категорий: управление рисками; измерение безопасности; культура; человеческое поведение; политики и стратегии; обработка инцидентов и уязвимостей; коммуникация и обязанности заказчика; этика; privacy. Это классификация обзора, а не новые девять процессов ГОСТ.

В обсуждении на с. 23 авторы отмечают значительное пересечение базовых практик и устойчивость многих идей; эволюция включает детализацию и организацию внедрения. В отношении эффективности полных методологий база гораздо менее однородна: есть ограниченные исследования случаев, авторские оценки и корпоративные сообщения, которые трудно сравнивать напрямую (с. 22–23, ссылки на с. 25).

В академической части авторы нашли один case study всей предлагаемой методологии и два случая с ограничением на требования/проектирование. Это характеристика отобранной литературы, а не доказательство, что остальные методы не работают.

Рабочая английская формулировка для выступления: **“The review identifies substantial overlap in practices, but much less consistent evidence for comparing the effectiveness of complete methodologies.”** Это пересказ вывода обзора с явной границей, а не результат нашего собственного эксперимента.

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

## 5. Расхождения и ограничения обзора

| Наблюдение в MLR | Как обработано в EP01 |
|---|---|
| Figure 2 ставит SDL и Touchpoints у 2004, Table II — у 2006, PDF-с. 5 | Разделены внедрение / ранняя публикация и книга; рисунок не перенесён как готовая хронология |
| Romanian SSDLC в Figure 2 у 2020, Table II и ссылка — 2021 | В полной таблице сохранён год Table II; в короткую шкалу не включён |
| Grip on SSD в Figure 2 окрашен как Industry, Table II относит его к Government; год 2015 совпадает | При описании выборки используется классификация Table II; цвет исходной схемы не копируется |
| Malaysia: 2020 в таблице/тексте, first edition 2015 в ссылке [35], с. 25 | Расхождение отмечено; первичная дата отдельно не установлена, в слайд не включена |
| GE SDL: 2022 в Table II, «Last access 2023» в Table IV | Год доступа не подменяет год выбранной публикации; позиция не включена в короткую шкалу |
| DevSecOps: 2012 в тексте с. 2 при ссылке [45] на источник 2016, с. 26 | Эта ссылка не используется как доказательство года возникновения DevSecOps |
| Классификация Waterfall по умолчанию, если agile явно не описан; с. 3–4 | Соотношение 26/2 не выдаётся за распространённость моделей разработки в индустрии |
| Англоязычные доступные полные тексты; ограничение Google Search первыми пятью страницами; ISO/IEC 27034 исключён из-за доступа; с. 2–3 | Нельзя говорить о полном охвате всех стран, стандартов и источников |
| Сильные утверждения о нехватке доказательств соседствуют с обсуждением Microsoft retrospective 2023; с. 22–23 | Говорим об ограниченной и неоднородной доказательной базе, не об абсолютном отсутствии сведений |
| Копия маркирована In submission; с. 1 | Статус указан как arXiv-препринт v2, без вымышленного рецензирования |

Рост числа CVE не используется как доказательство неэффективности SSDLC: такую причинную связь этот материал не устанавливает.

### Применение к новой графике EP01

Содержание новой шкалы задаётся в [EP01-visuals.md](EP01-visuals.md), записи `slide-05` и `ru-sdl-timeline`. За основу взяты публикации Table II, а не механическая копия Figure 2. Шесть вех: Jones и Rastogi — 2004; выбранные публикации SDL, Touchpoints и CLASP — 2006; SDL-Agile guidance v5.2 — 2012; CSA Singapore Security-by-Design — 2017; SAMM v2.0 — 2020; SSDF v1.1 — 2022. Это выборка для объяснения разных подходов, без заявления о полноте истории.

Рядом с рисунком сохраняется пояснение: дата издания не обязательно является датой появления метода. Поэтому включение Microsoft SDL в разработку с 2004 года совместимо с книгой 2006 года; эти факты имеют разные подписи. Румынская и малайзийская позиции, требующие оговорок о расхождениях, в короткую шкалу не включены. Все несогласованности остаются видимыми в таблице выше; новая иллюстрация не исправляет первоисточник молча.

Повторная визуальная сверка PDF-с. 5 подтверждает Singapore Security-by-Design **2017** одновременно в Table II и Figure 2; оба элемента относят его к Government. Для этой вехи источник — предоставленный обзор, дополнительная проверка первичного сингапурского документа не заявляется. Дата SAMM v2 подтверждена [официальным объявлением 31 января 2020 года](https://owaspsamm.org/blog/samm2-release/), дата SSDF v1.1 — [карточкой NIST от 3 февраля 2022 года](https://csrc.nist.gov/pubs/sp/800/218/final), внедрение SDL с 2004 года — [историей Microsoft SDL](https://www.microsoft.com/en-us/securityengineering/sdl/about). Шкала представляет авторскую перерисовку по Table II с учётом проверки Figure 2; она не выдаётся за исходный рисунок авторов обзора.

Шкалы создания ГОСТ (`slide-08`, `ru-gost-timeline`) отделяют проектные этапы из доклада Вареницы от формальных дат утверждения и введения в действие. Шкала `slide-11` сопоставляет публикационные даты ГОСТ и SSDF, но не содержит утверждения об их происхождении друг от друга. `slide-12` сравнивает структуру и модальность редакций; число заголовков не используется как количественный показатель безопасности.

Весь визуальный комплект содержит 16 английских схем и 7 русских рисунков. Сборка выполняется последовательно: `build-visuals.py` → `build-content.py` → `build-review.py`; подписи и ссылки должны оставаться согласованными в Markdown и HTML. Каталог фиксирует источники каждого рисунка и учебный характер примеров. Этот раздел документирует содержание и источники, а не результат браузерной проверки.

## 6. История создания ГОСТ по докладу Вареницы

Предпосылка на GOSTH, PDF-с. 2: развитие анализа уязвимостей и оценки продуктов при отсутствии специальных требований к процессу разработки в рассматриваемом российском контексте. В речи это атрибутировано докладу; не утверждается отсутствие безопасной разработки вообще.

На с. 3 описаны учитываемые связи: лучшие практики, совместимость с Common Criteria / ГОСТ Р ИСО/МЭК 15408, возможность интеграции со СМИБ / 27001 и согласованность с lifecycle-процессами 12207. На с. 22 показана схема связей версии 2016, включающая также 27034. Это историческое свидетельство замысла совместимости, не доказательство прямого копирования SDL и не перечень нормативных ссылок финального 2024.

| Событие | Дата / значение | Основание и степень подтверждения |
|---|---|---|
| Предварительные обсуждения | Примерно с 2009 года; подготовка около 2010 года | TRANS 00:08:56 и 00:17:33–00:18:19; воспоминания участника, не официальная дата начала проекта |
| Начало разработки / НИР | Апрель 2013 | GOSTH с. 4; TRANS 00:17:33–00:18:19 уточняет, что это начало НИР после подготовительной работы |
| Первая редакция проекта | Август 2013 | GOSTH с. 4 |
| Окончательная редакция проекта | Май 2014 | GOSTH с. 4; это ещё не дата утверждения стандарта |
| Уточнённая окончательная редакция | Сентябрь 2015 | GOSTH с. 4 |
| Апробация в НИР и публичное обсуждение в ТК 362 | 22 организации, около 200 замечаний и предложений | GOSTH с. 4; отдельный протокол и состав всех участников не изучались |
| Утверждение ГОСТ Р 56939-2016 | **1 июня 2016**, приказ 458-ст | [Официальная карточка Росстандарта](https://protect.gost.ru/gost/details/286a588e-4a6a-4899-88f7-3c370dea1e1d); заменяет ошибочное «май 2016» на архивном слайде |
| Введение редакции 2016 | **1 июня 2017** | Та же официальная карточка |
| Последующие рабочие редакции | В устном рассказе: 2018, 2019, 2020, 2022 | TRANS 00:18:19–00:19:00; наличие опубликованных ГОСТ с этими годами не подтверждается |
| Подготовленная версия для пересмотра | 2022, по воспоминаниям докладчика | TRANS 00:29:25; причины задержки до 2024 — объяснение докладчика, не установленный официальный протокол |
| Утверждение / введение редакции 2024 | **24 октября / 20 декабря 2024**, приказ 1504-ст | [Официальная карточка 2024](https://protect.gost.ru/gost/details/f3818925-a96f-4f55-96e9-46b44720ee64) |

Карточка и предисловие редакции 2016 называют **ЗАО «НПО «Эшелон»** разработчиком, **ТК 362 «Защита информации»** — вносящим комитетом. TRANS 00:19:00–00:20:19 добавляет воспоминание: небольшая группа в «Эшелоне» готовила текст, другие организации преимущественно обсуждали его и давали замечания. Такое разделение ролей объясняет, как один указанный разработчик сочетается с широким обсуждением. Полный список 22 рецензировавших организаций и протоколы здесь не проверены.

В предисловии и [официальной карточке 2024](https://protect.gost.ru/gost/details/f3818925-a96f-4f55-96e9-46b44720ee64) перечислены десять организаций: ФСТЭК России, АО «Лаборатория Касперского», ИСП РАН, АО «ИнфоТеКС», АО «Позитив Текнолоджиз», ООО «РусБИТех-Астра», АО «СберТех», ООО НТЦ «Фобос-НТ», ООО «ЦБИ», АО НПО «Эшелон». Вносит стандарт также ТК 362. Организационно-правовая форма «Эшелона» в двух предисловиях различается; историческое ЗАО не заменяется нынешним АО задним числом.

На с. 5 доклада разработчики и производители названы основной аудиторией. Это поддерживает прикладную подачу серии. При этом финальный стандарт также адресован организациям, оценивающим соответствие процессов; историческая характеристика аудитории не исключает их из области применения.

## 7. Что в архивном докладе не становится текущим требованием

| Архивный фрагмент | Проверенная обработка |
|---|---|
| GOSTH с. 4: май 2016 как утверждение | На шкале и в речи — июнь 2016 по официальному приказу |
| С. 8/23: состав нормативных ссылок; на с. 23 явно показан проект первой редакции | Требования и ссылки сверяются по финальному локальному ГОСТ; раздел 2 содержит ГОСТ Р ИСО/МЭК 12207 и ГОСТ Р 50922 |
| С. 7/20/21: критерии положительного заключения в структуре процесса | Финальный п. 4.8: наименование → цели → требования → артефакты; именно эта структура объясняется в блоке перехода к редакции 2024 |
| С. 9/14–18: неточности пересказа, включая «статистический анализ» | Используются точные названия процессов окончательной редакции |
| С. 24–25: перспективы сертификации, лицензирования и развития документов | Исторические планы не объявляются действующими универсальными обязанностями |

Финальный нормативный источник и его происхождение зафиксированы в [EP01-sources.md](EP01-sources.md). Текст доклада ценен для истории, но не заменяет стандарт.

## 8. Что впервые становится понятнее из полного рассказа

### Зачем понадобился национальный документ

TRANS 00:08:56–00:14:32 раскрывает переход от обсуждения безопасности отдельных продуктов к общим правилам работы разработчика. Докладчик описывает желание создать документ, применимый за пределами одного крупного вендора: для команд разного масштаба и для оценки процесса. Это соответствует области применения G16, раздел 1, PDF-с. 5: документ адресован разработчикам, производителям и организациям, оценивающим соответствие. Однако утверждение, что до этого нигде не существовало общих подходов, из этих свидетельств не следует.

TRANS 00:20:19–00:24:25 показывает спор о первичной аудитории и о привязке к сертификации. В рассказе приоритет отдан разработчику, качеству продукта, поддержке и взаимодействию с пользователем. Это исторический замысел. Он не означает, что оценщики исключены из области применения, или что сегодняшняя применимость стандарта определяется личным намерением одного автора.

### Замысел семейства и статус рабочих текстов

В TRANS 00:09:41–00:10:19 и 01:03:58–01:05:17 говорится о нескольких задуманных документах: общих требованиях, угрозах, рекомендациях по внедрению и оценке. Число запланированных «книг» в обсуждениях менялось. Рассказ о подготовленном руководстве и приостановке его обсуждения сохраняется как воспоминание, без присвоения неутверждённому тексту статуса действующего ГОСТ.

ГОСТ Р 58412-2019 обсуждается как продолжение работы над угрозами при разработке; выражение «вторая книга» описывает замысел семейства, а не официальное обозначение «часть 2 ГОСТ Р 56939». GOSTH, PDF-с. 24, связывает дальнейшие рекомендации по оценке с ГОСТ Р 58975-2020. Наличие родственных документов не делает их автоматически частями одного номера и не доказывает завершение всех задуманных работ.

Рабочие версии 2018, 2019, 2020 и 2022 в TRANS 00:18:19–00:19:00 надо отличать от утверждённых национальных стандартов. В изученной последовательности конкретного номера подтверждены редакции **2016** и **2024**. Предполагаемая задержка рассмотрения версии 2022 — объяснение участника; точные причины и решения комитета не реконструированы по документам.

### Международные связи: есть проверяемый текст, а не только воспоминание

Связи G16 с международными подходами подтверждает сам стандарт: раздел 1, PDF-с. 5, допускает его использование для формирования мер в контексте ГОСТ Р ИСО/МЭК 27034-1 и для конкретизации или расширения компонентов доверия ГОСТ Р ИСО/МЭК 15408-3. В п. 4.6, PDF-с. 8, и справочном приложении А, PDF-с. 22, описана взаимосвязь мер и требований доверия Common Criteria. Раздел 2, PDF-с. 5–6, содержит также ссылки на 12207 и 27001. Это достаточно конкретные основания говорить об осознанной совместимости.

Фраза «самостоятельная национальная разработка» в лекции означает собственный документ с разработчиком, проектной работой и обсуждением, учитывающий более широкую практику. Она не означает создание всех инженерных идей с нуля. Утверждения «это перевод Microsoft SDL», «это первый такой стандарт в мире» и «NIST заимствовал ГОСТ» имеющимися источниками не подтверждаются.

## 9. Хронология NIST SSDF и предел сравнения по годам

| Событие | Подтверждённая дата | Первичный источник |
|---|---|---|
| Анонс public draft SSDF | 11.06.2019 | [NIST: Draft White Paper on SSDF](https://csrc.nist.gov/News/2019/draft-white-paper-on-ssdf) |
| Финальный white paper, SSDF 1.0 | 23.04.2020 | [NIST: опубликован SSDF](https://csrc.nist.gov/news/2020/mitigating-risk-of-software-vulns-ssdf), [полный white paper](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04232020.pdf) |
| Финальный NIST SP 800-218, SSDF 1.1 | 03.02.2022 | [NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final) |
| Initial public draft SSDF 1.2 | 17.12.2025; на дату проверки отмечен Draft | [Реестр NIST SSDF](https://csrc.nist.gov/Projects/ssdf/publications) |

У новости 2019 есть служебное поле Created June 07, 2019; в лекции при точной дате используется дата анонса **June 11, 2019**, а не смешение этих полей. Рассказ TRANS 00:10:19 о появлении первой версии в 2019 уточнён: речь о проекте, не финальном SSDF 1.0.

**G16 не мог быть основан на опубликованном позднее SSDF.** Обратное заимствование этой хронологией также не доказывается. Для вопроса «кто раньше» нужны сравнимые классы документов и полный набор предшественников. Корпоративный lifecycle, национальный стандарт, модель зрелости и рекомендуемый framework выполняют разные задачи. Оценки «отставание на десять лет» / «разница в пределах года» в TRANS 01:05:59–01:09:04 — устная интерпретация участников, не измерение зрелости или полноты.

## 10. Что на самом деле сравнивается между редакциями 2016 и 2024

### Девять групп мер в финальном 2016, а не четырнадцать процессов

В TRANS 00:31:45 звучит приблизительный подсчёт «около 14», включая компенсирующие меры. Проверка оглавления окончательного G16, PDF-с. 3, показывает **девять тематических подразделов раздела 5**. В каждом находятся более детальные цели, меры и свидетельства; девять — количество групп, не всех отдельных требований.

| G16 | Группа мер: сокращённое название |
|---|---|
| 5.1 | Анализ требований к ПО |
| 5.2 | Проектирование архитектуры программы |
| 5.3 | Конструирование и комплексирование ПО |
| 5.4 | Квалификационное тестирование ПО |
| 5.5 | Инсталляция программы и поддержка приёмки ПО |
| 5.6 | Решение проблем в ПО в процессе эксплуатации |
| 5.7 | Менеджмент документацией и конфигурацией программы |
| 5.8 | Менеджмент инфраструктурой среды разработки ПО |
| 5.9 | Менеджмент людскими ресурсами |

Компенсирующие меры — возможность из **п. 4.5**, PDF-с. 8, когда отдельные базовые меры нельзя реализовать в среде разработки; они должны обеспечивать соответствующие цели и результаты. Это не две дополнительные группы в оглавлении и не универсальное разрешение просто отказаться от нужной работы.

В G24 раздел 5 включает 25 процессов, 5.1–5.25. Переход **9 групп → 25 процессов** описывает структуру документов. Из него нельзя вывести процент роста безопасности, количество принципиально новых практик или готовое соответствие один к одному. Переход от «мер» к «процессам» также нельзя объяснять так, будто в редакции 2016 вообще не было процессов: пп. 4.4, 4.8–4.9 уже требовали реализации мер в жизненном цикле, внутренних проверок и улучшений.

### Изменилась и нормативная лексика

| Редакция | Пункт | Значение «следует» |
|---|---|---|
| 2016 | 4.2, PDF-с. 8 | Рекомендация среди других возможностей |
| 2024 | 4.7, PDF-с. 6 | Условие, требуемое для соответствия требованию, как и «должен» |

Это проверенное различие важно при переносе старых регламентов. В английском объяснении G24 нельзя механически переводить «следует» как необязательное *should*, не объяснив принятую в этом тексте нормативную силу. Для рекомендаций G24 использует «рекомендуется», для допустимых действий — «может».

### Практический смысл перехода

TRANS 00:30:06–00:40:46 описывает разделение и детализацию существовавших мер, появление более явных процессов, изменение порядка изложения и акцент на людях. Этот рассказ полезен как объяснение участника. Для конкретной команды предлагаем анализировать каждую старую практику вместе с владельцем, её исполнением и свидетельствами; затем проверять требования G24 и недостающую работу. Это авторская рекомендация, а не заявленная в этой лекции завершённая матрица перехода.

Примеры направлений сравнения: G16 5.9 и G24 5.2 — работа с компетенциями; G16 5.7 и G24 5.4 — управление конфигурацией. Тематическая связь не равна полной эквивалентности требований. Старые артефакты могут быть полезны, но их достаточность требует проверки по новой редакции.

## 11. Реестр исправлений и непереносимых утверждений из транскрипта

| Время / фрагмент | Как обработано |
|---|---|
| 00:09:41, 00:10:19, 00:19:00: стандарт «принят / опубликован в Минюсте» | Формальная атрибуция исправлена по предисловию и Росстандарту; это не процедура утверждения национального стандарта Минюстом. Без аудио не определяется, была ли причина в оговорке или ASR |
| 00:18:19–00:20:19: «ТК 62», «Ишеон», варианты фамилии | Нормализованы в ТК 362, НПО «Эшелон», Виталий Вареница по предисловиям, титулу GOSTH и представлению; общая метка «Участник 1» не считается идентификатором говорящего |
| 00:09:41–00:12:54: «уникальный», «флагман» | Сохранён смысл самостоятельной национальной работы; мировое первенство и превосходство не заявляются |
| 00:31:45: «около 14», «12 + компенсирующие» | Заменено проверенной структурой: 9 групп мер финального G16 и 25 процессов G24; общего числа всех мер по этой реплике не считаем |
| 00:33:16–00:35:21 и 00:49:47–00:51:26: как появилось нефункциональное тестирование и почему менялись ссылки | Авторская критика и воспоминания; не протокол голосования и не официальное объяснение мотивов регулятора |
| 00:33:54, 00:52:25: нефункциональное тестирование «равно пентесту» | Не переносится как универсальное определение вида тестирования. Для будущего EP19 применяется точный G24 5.19 и относящиеся к нему термины; частный спор не подменяет терминологию всей отрасли |
| 00:24:25–00:27:28: рекомендательность всех ГОСТ, сертификация, «70-й приказ», ведомственный приказ 2017/18 | Номера и универсальные правовые последствия не восстанавливаются по ASR. Тема остаётся историческим регуляторным контекстом; применимость конкретному продукту устанавливается по действующим документам и их редакциям |
| 01:09:04–01:10:19: зарубежные штрафы и «российский разработчик ничего не заплатит» | Не переносится как правовой факт. Последствия зависят от отношений, нарушения, категории данных и применимого права |
| 01:10:19–01:11:38: 70% клиентов внедряли процессы вне сертификации | Личное наблюдение докладчика без размера и структуры выборки; не статистика российского рынка |
| 01:12:19–01:13:48: четыре предполагаемых уровня | В июле 2025 это прямо названо внутренним обсуждением; не действующая модель зрелости и не утверждённый уровень сертификации |

Нормативная граница для G24 проверена в локальном финальном тексте: п. 4.14 связывает требуемую совокупность процессов с применимыми документами и поясняет случай предъявления соответствия всему стандарту; п. 4.15 специально регулирует предъявление требований в ТЗ НИР/ОКР. Эти положения не означают автоматическую обязанность каждого разработчика сертифицировать любой продукт.

Показателен временной разрыв: официальный [реестр правовых актов ФСТЭК](https://publication.pravo.gov.ru/documents/block/foiv041) содержит приказ от 30.06.2025 № 230, изменяющий порядок по приказу № 240, но с регистрацией **18.09.2025** и опубликованием **19.09.2025**, то есть после исходного вебинара 02.07.2025. В этой работе подтверждены реквизиты публикации; полный актуальный порядок сертификации и все переходные положения отдельно не аудировались. Поэтому устное обсуждение 2025 года не используется как юридическая инструкция на сентябрь 2026 года.

## 12. Как материал перенесён в новый выпуск

Исторический блок 7–13 теперь отдельно раскрывает предпосылки, этапы подготовки, роли разработчиков и рецензентов, замысел семейства, международные связи, различие структуры редакций и повторяемую работу в процессе. Слайды 5–6 продолжают объяснять выбранные публикации и способы организации SDL; слайд 14 обсуждает пересечение практик и ограничения доказательств эффективности.

После истории выпуск возвращается к процессу 5.1: учебная команда сопоставляет текущую работу с требуемым состоянием, ресурсами, планами, исполнителями и свидетельствами. Рассказ участника разработки даёт контекст, а точные обязанности берутся из окончательного G24. Содержание большого русскоязычного конспекта не обязано полностью помещаться в английскую запись: это материал подготовки и ответов на вопросы.

Полная английская речь хранится в [EP01-script-en.md](EP01-script-en.md), автоматический расчёт — в [EP01-timing.md](EP01-timing.md). История Ware/Saltzer–Schroeder и институциональная дата 1925 остаются дополнительным контекстом в реестре источников. До записи остаётся авторская репетиция; независимая внешняя рецензия и просмотр видеозаписи не заявляются выполненными.

## Структура выступлений и деление учебного материала

Проверка выполнена по полной пользовательской расшифровке 6 сентября 2026 года. Основания атрибуции — представление участников, обращения по именам, передача слова, объявление программы и переход к вопросам. Единый технический ярлык «Участник 1» не используется как доказательство авторства. Время указывает на текстовый блок расшифровки; точный момент смены говорящего внутри блока по аудио не измерялся.

| Этап | Примерные границы | Наблюдаемое основание |
|---|---|---|
| Открытие | 00:00:52–00:05:30 | Карпов представляет участников. В 00:04:11 приглашает Вареницу «начать свою часть презентации», Пиков приветствует аудиторию и передаёт слово гостю |
| Отдельный исторический доклад Виталия Вареницы | ≈00:05:30–00:49:47 | В 00:05:30 гость говорит о подготовленной презентации по истории стандарта; в 00:49:07 объявляет последний слайд |
| Вопросы к историческому докладу | 00:49:47–01:17:44 | Переход к вопросам из чата; ведущие задают вопросы и дополняют ответы Вареницы |
| Завершение участия гостя | 01:17:44–01:19:16 | Благодарность за исторический рассказ, приглашение на следующий выпуск; прощание в 01:19:10 |
| Совместный разбор ГОСТ и планирования | 01:19:16–01:51:26 | Карпов объявляет новую программу и отмечает состоявшуюся отдельную презентацию. Затем ведущие чередуются в изложении |
| Дополнительные материалы и общие вопросы | 01:51:26–02:04:48 | Завершение основной программы, пояснения об инструментах и обучении, ответы ведущих |
| Итоги | 02:04:48–02:07:28 | Заключительные реплики и анонс; последняя отметка не является измеренным концом видео |

Во втором блоке Карпов даёт содержательный обзор структуры ГОСТ (примерно 01:21:10–01:32:03), объясняет смысл и стоимость планирования, разбор исходных практик, артефактов и автоматизацию. Пиков раскрывает актуальность, инициализацию, портфель продуктов и приоритеты, организационные документы и компетенции. Передача слова прямо подтверждается репликами в 01:33:19 («Спасибо большое, Андрей»), 01:38:37 («Виталий, как ты считаешь») и 01:39:18 («А скажи, Андрей»). Поэтому Карпов — участник содержательного изложения, а не только модератор; приписывать всю практическую часть одному Пикову неверно.

Редакционное решение: две основные части, соответствующие реально отделённым крупным блокам. Не создаём третий самостоятельный доклад только по числу выступавших. Учебное введение объединяет §§1–2; часть I, «История и развитие национального стандарта», — §§3–6 с подписью Вареницы; часть II, «Применение ГОСТ и планирование безопасной разработки», — §§7–21 с совместной подписью Карпова и Пикова. В ней один раз отмечен вклад Вареницы в общую дискуссию о проверках, ответственности, сопровождении и соответствии. Практикум §22, вопросы и библиография выделены отдельно.

Это тематическая учебная структура: она сохраняет границы основных выступлений, но не воспроизводит разговор по минутам. Вопросы применения обсуждались и с гостем, и позднее ведущими; их не приписываем одному человеку. Учебная систематизация методологий, уточнения по окончательным стандартам и практикум не выдаются за дословную речь конкретного докладчика. Подробная карта и временные метки остаются в этом исследовательском документе; в самостоятельной лекции — крупные части, подписи и удобное оглавление.