Пересказ 2025.07.02 Вебинар 1 по РБПО с PVS-STUDIO.mp4.txt
Вспомогательная навигация по темам; не заменяет полный текст.
Открыть исходный текстПересказ 2025.07.02 Вебинар 1 по РБПО с PVS-STUDIO.mp4.txtСодержание сохранено в двух формах
Учебная лекция на русском языке
Последовательное изложение связывает исторический контекст, требования стандартов и повседневную работу команды. Лекция рассчитана на самостоятельное изучение; примеры и библиография помогают продолжить работу с темой.
Англоязычный выпуск EP01
Сценарий, слайды и речь докладчика развивают материал для серии Secure Software Development in Practice. История связана с практической задачей первого процесса — планированием безопасной разработки.
29слайдов в обновлённой EP01
53:10плановая длительность выпуска
5,973английских слов в речи
15Markdown-документов целиком
Ключевые уточнения истории стандарта
| Вопрос | Уточнение для лекции | Основание |
|---|---|---|
| Структура редакции 2016 года | Девять групп мер в пунктах 5.1–5.9. Редакция 2024 года описывает 25 процессов; единицы группировки различаются. | Окончательная редакция 2016; редакция 2024 |
| Утверждение и начало действия | Росстандарт утвердил ГОСТ Р 56939-2016 1 июня 2016 года приказом № 458-ст. Введение в действие — 1 июня 2017 года. | Официальная карточка Росстандарта |
| Как читать слово «следует» | В редакции 2016 года это рекомендация по п. 4.2. В редакции 2024 года формулировки «должен» и «следует» выражают требования согласно п. 4.7. | ГОСТ Р 56939-2016; ГОСТ Р 56939-2024 |
Основания исторических утверждений
Формальные даты, статус редакций и нормативные требования опираются на проверочные источники. История подготовки стандарта отделена от требований окончательных редакций. Подробные основания приведены в библиографии лекции и исследовательских заметках.
Проверена синхронизация полного текста речи и всех Markdown-документов. Визуальная проверка обновлённой версии в браузере ещё не завершена.
История стандартов и организация безопасной разработки
В учебном материале сохранены два основных блока: исторический доклад и совместный практический разбор. Введение, практикум, вопросы и библиография помогают изучить материал последовательно и применить его в работе команды.
Первичные материалы для работы автора
Транскрипция 2025.07.02 Вебинар 1 по РБПО с PVS-STUDIO.mp4.txt
Основа подробной тематической лекции; сверка рассказа и вопросов участников.
Открыть исходный текстТранскрипция 2025.07.02 Вебинар 1 по РБПО с PVS-STUDIO.mp4.txtWhere Secure Development Begins
History, GOST and a working process
Бренд серии сохранён. Содержание слайдов и речь обновляются из Markdown-источника.
План выпуска · 53:10
Интервалы ниже — план для репетиции. Фактическая длительность зависит от темпа речи, пауз и монтажа. При 120 словах в минуту чтение текста займёт около 49:46; при 125 — около 47:47.
| Слайд | Интервал | Название | Тема |
|---|---|---|---|
| 01 | 00:00–01:05 | Where secure development begins | Welcome |
| 02 | 01:05–02:40 | One process. One useful result. | The series |
| 03 | 02:40–04:15 | Twenty-five processes, connected | The series |
| 04 | 04:15–06:15 | Friday's release is blocked | The engineering problem |
| 05 | 06:15–08:30 | Three documents before the methodologies | Foundations |
| 06 | 08:30–10:50 | From evaluating systems to building them | Foundations |
| 07 | 10:50–12:35 | A landscape of secure development methods | The methodology landscape |
| 08 | 12:35–14:10 | Different ways to organize the work | The methodology landscape |
| 09 | 14:10–15:45 | Before the standard: a practical problem | The origins of GOST R 56939 |
| 10 | 15:45–17:30 | The route from research to publication | The origins of GOST R 56939 |
| 11 | 17:30–19:50 | Who wrote it, and who was it for? | The origins of GOST R 56939 |
| 12 | 19:50–21:25 | A wider plan than one published document | The origins of GOST R 56939 |
| 13 | 21:25–23:30 | GOST in the international context | The origins of GOST R 56939 |
| 14 | 23:30–25:15 | Two editions, different structures | From the 2016 edition to 2024 |
| 15 | 25:15–26:55 | A process continues after the first tool run | From the 2016 edition to 2024 |
| 16 | 26:55–29:15 | When this standard actually binds | Legal force |
| 17 | 29:15–30:45 | Shared practices need evidence | Our comparison method |
| 18 | 30:45–32:35 | Compare obligations, not labels | Our comparison method |
| 19 | 32:35–35:00 | What process 5.1 asks for | Planning secure development |
| 20 | 35:00–36:40 | Start with a defensible scope | Planning secure development |
| 21 | 36:40–38:15 | Assess reality and assign owners | Planning secure development |
| 22 | 38:15–39:50 | Resources include human attention | Planning secure development |
| 23 | 39:50–41:30 | Two plans, two questions | Planning secure development |
| 24 | 41:30–43:45 | A 90-day plan for the importer | Worked example |
| 25 | 43:45–45:20 | Five linked records of evidence | Worked example |
| 26 | 45:20–47:50 | Every process is written the same way | Worked example |
| 27 | 47:50–49:40 | A first international crosswalk | Comparison result |
| 28 | 49:40–51:15 | Would this survive Friday's release? | Apply it |
| 29 | 51:15–53:10 | Security Training That Changes Engineering Decisions | Stay in touch · Next episode |
Подготовка к записи
Сначала прочитайте речь с таймером и отметьте места для пауз. Учебная лекция даёт развёрнутое объяснение темы, а англоязычный сценарий помогает выстроить последовательное выступление для выбранной аудитории.
Финал выпуска содержит имя Vitaliy Pikov, сайт pikov.art и анонс второго эпизода.
Источники и границы интерпретации
Источники связаны со слайдами через короткие идентификаторы. Полные исследовательские заметки и ссылки также сохранены в Markdown-архиве.
GOST R 56939-2024 · final edition
Developed by FSTEC of Russia with nine organisations, including Kaspersky, ISP RAS, Positive Technologies and NPO Echelon; submitted by TC 362; approved 24 October 2024 by order 1504-st; effective 20 December 2024. Foreword and structure; clause 4.7 on normative wording; clause 5.1 on planning and its implementation evidence. English clause wording is an author translation.
Открыть источникGOST R 56939-2016 · final edition
Developed by NPO Echelon and submitted by TC 362. Nine groups of measures in 5.1–5.9; clause 4.2 defines recommendation wording. Approved 1 June 2016; effective 1 June 2017; replaced by the 2024 edition.
Открыть источникRAND · Security Controls for Computer Systems
Original February 1970 report; the catalogue page describes the 1979 reissue.
Открыть источникSaltzer and Schroeder · The Protection of Information in Computer Systems
Proceedings of the IEEE, September 1975. Selected principles, not a complete account of security history.
Открыть источникMicrosoft · History of the SDL
Trustworthy Computing: January 2002; SDL integral to development: 2004.
Открыть источникRosstandart regional centre · Historical milestones
Institutional history: standardization committee established 15 September 1925.
Открыть источникNIST SP 800-218 · SSDF 1.1 · Final
Final baseline, 3 February 2022; the narrow example uses Table 1, task PO.2.1.
Открыть источникNIST SP 800-218 Rev. 1 · SSDF 1.2 · Draft
Initial public draft, 17 December 2025. Status checked 6 September 2026; recheck before recording.
Открыть источникOWASP SAMM · Strategy and Metrics · Stream A
Maturity model; activity G-SM-A-2 is the roadmap/strategy comparison. Living website, checked 6 September 2026.
Открыть источникKudriavtseva and Gadyatskaya · A Multivocal Literature Review
arXiv v2, 4 July 2023, preprint marked In submission. A review of 28 methodologies. Table II lists publication dates; the analysis covers engineering practices, operating models and limits of effectiveness evidence. Publication dates and the origins of ideas are distinct milestones.
Открыть источникOWASP SAMM · Version 2 public release
Official announcement, 31 January 2020; a version-release date, not the first appearance of all SAMM ideas.
Открыть источникVitaliy Varenitsa · Retrospective on GOST R 56939
History and current state of secure software development in Russia. GOST R 56939-2016/24. Title translated from Russian. Presentation, 2 July 2025. Pages 2–4 cover the context and drafting history; pages 3 and 22 cover international connections. Recollections describe the authors' intentions; adopted requirements are defined by the final standards.
Illustrative teaching example · Vitaliy Pikov
Fictional importer, roles, hours, dates, review cadence and tasks. Not a client case, GOST-prescribed schedule, or conformity claim.
James P. Anderson · Computer Security Technology Planning Study
ESD-TR-73-51, Vol. I, October 1972. Deputy for Command and Management Systems, HQ Electronic Systems Division (AFSC), L. G. Hanscom Field. Prepared under contract F19628-72-C-0198 by James P. Anderson & Co. Section 3.2.1 introduces the reference monitor; section 3.2.2, on pages 9-10, states three design requirements for the reference validation mechanism, which footnote 3 defines as the combination of hardware and software that implements the reference monitor concept: it must be tamper proof, it must always be invoked, and it must be small enough to be subject to analysis and tests. The 1973-style report number on a 1972 report is a common citation trap.
Открыть источникDepartment of Defense Trusted Computer System Evaluation Criteria · the Orange Book
DoD 5200.28-STD, 26 December 1985. Its own title page records that it supersedes CSC-STD-001-83, dated 15 August 1983. The two designations belong to two different documents; the 1985 standard is the better known one. The issuing organization of the 1983 version is not asserted here. The slide's claim that these criteria also ask about the work behind the product rests on the Life-Cycle Assurance sections 2.1.3.2, 2.2.3.2, 3.1.3.2, 3.2.3.2, 3.3.3.2 and 4.1.3.2; a Design Specification and Verification subsection appears from 3.1.3.2 upward and a Configuration Management subsection from 3.2.3.2 upward, so the assurance demanded of the development work grows with the class.
Открыть источникCommon Criteria for Information Technology Security Evaluation · Part 1, version 2.1
August 1999. Annex A.2, paragraph 185: CC version 1.0 was completed by the CCEB in January 1996 and approved by ISO in April 1996 for distribution as a Committee Draft. Annex A.1, paragraphs 181-183, records the earlier national criteria (TCSEC, ITSEC 1.2 in 1991, CTCPEC 3.0 and Federal Criteria 1.0 in early 1993); Annex A.2, paragraph 184, records the start of the CC Project in June 1993. The foreword, page ii, states that CC 2.1 aligns with International Standard ISO/IEC 15408:1999 and that CC 2.0 was issued in May 1998. Paragraph 105 states that the CC does not mandate any specific development methodology or life cycle model, while paragraph 131 gives constraints on the rigour of the development process as an example of an assurance requirement; that pair is the boundary the slide keeps. Note that the Common Criteria portal's ICCC history page gives 1994 for version 1.0; the criteria document itself gives January 1996 and is preferred.
Открыть источникFederal Law 162-FZ · On standardization in the Russian Federation · Article 26
Adopted 29 June 2015. Article 26 part 1: documents of the national standardization system are applied voluntarily unless legislation of the Russian Federation provides otherwise. Article 26 part 3: application of a national standard is mandatory for a manufacturer or performer after a public claim that a product conforms to it, including use of the designation in marking or documentation. Named in the foreword of GOST R 56939-2024. Checked 6 September 2026.
Открыть источникVitaliy Pikov · Secure development: history and practice
Companion Russian lecture on standards, processes and implementation, with a historical account by Vitaliy Varenitsa and references to the applicable editions.
Открыть источникNIST SSDF · public draft · June 2019
Official announcement of the public draft, 11 June 2019. Later than the adoption of GOST R 56939-2016.
Открыть источникNIST SSDF 1.0 · final · April 2020
Official announcement of the final white paper, 23 April 2020. Separate from the 2019 draft and SSDF 1.1 of February 2022.
Открыть источникПолная речь для 29 слайдов
Текст каждого слайда приведён целиком, без сокращений. Заголовок раскрывает плановый интервал, объём речи и тему.
01Where secure development begins00:00–01:05 · 117 слов · Welcome
Hello, and welcome. I'm Vitaliy Pikov. I work with secure software development processes, and I teach the engineering ideas behind them.
This is the first episode of Secure Software Development in Practice. We'll explore twenty-five processes from a Russian national standard, GOST R 56939-2024. And we'll compare them with international approaches.
Our question is simple. What can a development team actually use?
Today we'll do three things. We'll look at the history behind the subject. We'll learn how to read this standard. And we'll build a small example of a security process plan. You do not need previous knowledge of Russian standards. Just bring your own experience: building software, reviewing it, or helping a team deliver it safely.
Источники слайда: G24
02One process. One useful result.01:05–02:40 · 182 слов · The series
This series builds on an earlier project. I made a set of Russian-language webinars together with PVS-Studio. For this English series, I want to take that work further. And I want to compare it with international practices in a systematic way.
Each episode will focus on one process. We'll ask three questions. What problem does it address? How do other approaches address a similar problem? And what evidence would show that a team has put the process into practice?
The audience includes developers, AppSec practitioners, and technical leaders. Maybe you write code. Maybe you design a delivery pipeline. Maybe you decide where the team should invest its limited time. Each of those perspectives matters.
I'm also using this project to develop my professional English and to go deeper in my own research. I'll explain new terms. I'll name the sources. And when something needs a correction, I'll say so openly.
By the end of an episode, you should have something useful to discuss with your team. A small checklist. A decision record. Or an example you can adapt to your own work.
Источники слайда: G24
03Twenty-five processes, connected02:40–04:15 · 177 слов · The series
The standard gives us the structure of the series: twenty-five processes, and twenty-five core episodes. Episode one follows section five point one. Episode twenty-five follows section five point twenty-five.
The four groups on this slide are my teaching guide. They are not additional categories defined by the standard. They help us see how four things connect: planning, engineering, verification, and continued support.
Here's an example. A static analysis result is useful only when we know three things. What code was analysed. Who reviews the findings. And how a correction reaches a release. A dependency list is the same. It is useful only when somebody keeps it current and acts on the changes that matter.
We'll keep coming back to those connections. Some episodes will include a guest who can explain one practice from direct experience. Every core episode will still have its own practical result.
You can follow the whole series. Or pick an episode that matches a problem you have now. Today we set up the vocabulary and a planning example that later episodes can extend.
Источники слайда: G24
04Friday's release is blocked04:15–06:15 · 234 слов · The engineering problem
Let's start with a small team. The team is fictional. It develops a C++ tool that imports engineering files. The product also has a small service API. It uses third-party components and ships regular updates.
On Friday afternoon, an analysis tool reports a possible memory error in the file parser. The developer says the finding needs investigation. The security specialist asks if the affected parser is part of the release. The release owner asks if there is time to fix it.
Look at the break between the finding and the investigation. The tool produced information. But the team has not agreed how to use it. The scope is not clear. Nobody set aside time to investigate. And nobody wrote down how the decision is made.
We cannot solve all of that by buying another tool. We need people who understand their responsibilities. We need suitable tools. We need a way of working we can repeat. And we need evidence that connects those elements to the actual product version.
An organization may already use an analyzer, and still need to check what it covers, how it is set up, and what happens after a finding. Before proposing another purchase, find out what the team already does and where the actual gap is.
Keep this team in mind. At the end of the episode, we'll return to Friday's release with a more useful set of questions.
Источники слайда: EX
05Three documents before the methodologies06:15–08:30 · 238 слов · Foundations
Our subject is older than the two thousands. Its roots are in government and academic work on trusted systems.
A Defense Science Board task force worked on computer security. Willis Ware chaired it. It finished its report on the eleventh of February, nineteen seventy. The title is Security Controls for Computer Systems. RAND published it, and it was classified confidential. The Defense Advanced Research Projects Agency declassified it on the tenth of October, nineteen seventy-five. RAND then reissued the report for wider distribution.
The covering memo makes a careful claim. It calls this the first attempt to codify the principles and details of the problem.
In October nineteen seventy-two, James Anderson wrote the Computer Security Technology Planning Study. He wrote it for the United States Air Force. The report number is on the slide. It introduced the reference monitor. Anderson names three requirements for the mechanism that implements it. It must be tamper proof. It must always be invoked. And it must be small enough to analyse and test.
Then came Saltzer and Schroeder. In September nineteen seventy-five they published The Protection of Information in Computer Systems. It appeared in Proceedings of the IEEE. The paper lists eight design principles. Least privilege and fail-safe defaults are two of them. We still apply them today.
Look at what these three documents are. They are research and defence reports about building systems you can trust. They are not vendor methodologies.
06From evaluating systems to building them08:30–10:50 · 238 слов · Foundations
The next stage is about evaluation. How do we judge whether a system deserves trust?
The United States answered with the Trusted Computer System Evaluation Criteria. People call it the Orange Book. The first version is dated the fifteenth of August, nineteen eighty-three. The better known version is the Department of Defense standard. Its date is the twenty-sixth of December, nineteen eighty-five. It replaced the nineteen eighty-three version. Both document numbers are on the slide.
Then the work became international. Canadian, European and American criteria were brought together in the Common Criteria project. Version one point zero was completed in January nineteen ninety-six. ISO approved it in April that year for distribution as a committee draft. The first ISO edition, ISO slash IEC fifteen thousand four hundred eight, followed in nineteen ninety-nine.
Notice what these documents do. They evaluate a product, and they also ask for evidence about how it was built.
In January two thousand two, Microsoft launched its Trustworthy Computing initiative. In two thousand four, the SDL became an integral part of development at Microsoft.
That is where our next slide starts. It uses a twenty twenty-three review. The review gives two dates. The first systematic studies of how to build secure software appeared in two thousand one. From two thousand four onward, organizations began putting security processes into the lifecycle. So two thousand four opens the review's selection window. It does not open the subject.
07A landscape of secure development methods10:50–12:35 · 180 слов · The methodology landscape
The history of secure development has several parallel approaches. One useful map is the twenty twenty-three review by Arina Kudriavtseva and Olga Gadyatskaya. It examines twenty-eight methodologies. It uses publications from two thousand four to twenty twenty-two. They come from industry, government, and academic research.
Follow the timeline from left to right. We selected six milestones for this slide: publications and editions. First comes early lifecycle research. Then come the SDL, Touchpoints, and CLASP publications. Later examples include guidance for agile development, Singapore's Security-by-Design framework, version two of OWASP SAMM, and NIST's SSDF, version one point one.
These are the dates of the publications or editions we are discussing. They are not all dates when the underlying ideas first appeared. Take Microsoft. It made SDL integral to its development process in two thousand four. But the SDL book discussed in the review appeared in two thousand six.
So the picture is a landscape. It shows different ways to organize secure development. We should examine what each approach contributes. We should not assume that the newest publication replaces every earlier idea.
08Different ways to organize the work12:35–14:10 · 183 слов · The methodology landscape
The review helps us look past the names. Each approach gives a team a different way to organize its security work.
Microsoft SDL joins engineering practices with management support and training. Touchpoints, from Gary McGraw, focuses on risk management. That includes architecture analysis and code review. CLASP connects activities to roles. The agile SDL guidance sorts activities into three kinds: done once, repeated in every sprint, or placed in a bucket, a group that comes back on a regular cycle.
That last idea is practical. A team needs a reasoned schedule for security work. Repeating every activity in every sprint is not automatically the best design.
The review also looks at maturity approaches. SAMM helps an organization plan how its capability grows. BSIMM describes practices observed in organizations. Those purposes are different from telling a developer the next task to build.
For our importer team, the shared questions are familiar. Which activity do we need? Who does it? And when? Each approach answers at its own level. We still have to work out what each activity means for our real product and team.
Источники слайда: MLR
09Before the standard: a practical problem14:10–15:45 · 178 слов · The origins of GOST R 56939
Why did Russia develop a national standard for secure software development? According to Vitaliy Varenitsa, who took part in that work, talks with colleagues and regulators began around two thousand nine. The practical concern was this. Assessing a finished product did not, by itself, explain how security work was organized all the way through development.
The proposed standard would make that work more visible. Developers needed one shared reference. It would name the activities, who is responsible, and what evidence supports a claim that the activities were done.
It was meant to be useful beyond the in-house development method of one large software vendor. Other organizations, including smaller teams, should be able to understand the expectations. Each team should then be able to adapt its implementation to its own products.
These early talks came before any formal drafting. The national standard would be approved several years later.
For our series, the useful question is the problem the authors were trying to solve. How do we turn good security intentions into work that other people can understand and check?
10The route from research to publication15:45–17:30 · 179 слов · The origins of GOST R 56939
Varenitsa dates the start of the research project to April twenty thirteen. It began after the first discussions, once the author team was formed.
The history presentation puts the first draft in August twenty thirteen. More drafts and revisions followed in twenty fourteen and twenty fifteen. It describes a discussion with twenty-two organizations, and around two hundred comments and proposals.
Those numbers describe the consultation reported in the history presentation. They do not mean that twenty-two organizations are named as developers in the final standard.
Rosstandart approved GOST R five six nine three nine, edition twenty sixteen, on the first of June twenty sixteen. The approval came under order four five eight, s t. It became effective on the first of June twenty seventeen.
Keep the four events separate. Research began. Drafts were discussed. The standard was approved. And the standard became effective. The year in a standard's name does not replace that order of events.
This also helps us read later revisions. A working draft can hold valuable ideas without being an adopted edition of the national standard.
11Who wrote it, and who was it for?17:30–19:50 · 274 слов · The origins of GOST R 56939
The foreword of the twenty sixteen edition names NPO Echelon as the developer. Technical Committee three six two is named as the submitting committee.
The twenty twenty-four edition has a different foreword. It names the Federal Service for Technical and Export Control, FSTEC, together with nine organizations. Among them are Kaspersky, the Institute for System Programming of the Russian Academy of Sciences, Positive Technologies and NPO Echelon. Technical Committee three six two submitted it again. That change is worth a moment. One developer in twenty sixteen. The regulator and a group of product companies in twenty twenty-four.
Varenitsa describes a small author group that prepared the main text. Other organizations reviewed the drafts and raised comments. Writing the document and taking part in its consultation were distinct contributions.
He also stresses the intended audience. The standard was primarily for the people who develop software: architects, programmers, security specialists, and the people who organize their work. Independent assessors were a second audience, because they needed to judge how those practices were put in place.
That's a useful tension in the design. The material has to guide engineering work. It also has to make those results clear to a reviewer outside the team.
Think of our importer example. A procedure should help the developer look into a finding. It should also help a reviewer understand what happened. A document written only to satisfy a filing rule misses much of that practical purpose.
The standard, a team's implementation, and a particular certification scheme are three different things. We should first be clear about the actual assessment context. Then we can discuss which form of confirmation is required.
12A wider plan than one published document19:50–21:25 · 156 слов · The origins of GOST R 56939
The original idea went further than a single document.
Varenitsa recalls talks about a family of standards. Together they would cover secure development from several angles, and across the software lifecycle. The number of those documents, and the way they were arranged, changed during discussion. The twenty sixteen standard was the first published result of that wider idea.
The same difference applies to versions. Varenitsa recalls working material from twenty eighteen, twenty nineteen, twenty twenty, and twenty twenty-two. These were steps in ongoing revision work. They were not published national standards with those edition years.
The two adopted editions for this episode are twenty sixteen and twenty twenty-four. For each one, we can point to a final text and an official approval record.
For a development team, here's the practical difference. An adopted requirement is one thing. A proposal that may still change is another. An implementation plan needs to say which published edition it follows.
13GOST in the international context21:25–23:30 · 231 слов · The origins of GOST R 56939
A national standard can be original and still use international engineering knowledge. These are compatible ideas.
Its design context included Common Criteria, information security management, and software lifecycle standards. The intended result was one common reference, usable by different development organizations.
The twenty sixteen standard itself points to other documents. It links its use to ISO slash IEC twenty-seven thousand thirty-four and to Common Criteria assurance components. It also has an informative appendix with a related mapping.
That does not prove that every practice was new. We have already seen earlier work on secure development. To show a specific borrowing, or a specific difference, we have to compare the relevant documents.
The NIST Secure Software Development Framework gives us a useful check on dates. Its public draft was announced in June twenty nineteen. Final version one point zero came in April twenty twenty. Final version one point one came in February twenty twenty-two.
So the twenty sixteen GOST cannot have been based on those later SSDF publications. At the same time, being earlier than SSDF does not prove that GOST was the first secure development approach in the world. And similarity does not prove influence in the other direction.
Our comparison asks a more useful question. Which engineering concerns are shared? How are obligations organized? And what evidence does each approach expect? That is something we can study process by process.
14Two editions, different structures23:30–25:15 · 241 слов · From the 2016 edition to 2024
The two editions organize related engineering work in different ways.
Section five of the twenty sixteen standard has nine groups of measures. Section five of the twenty twenty-four edition has twenty-five named processes. These are different units of organization. Subtracting one number from the other does not tell us how many genuinely new practices appeared, or how much safer a product became.
There's also a concrete change in wording. Look at the Russian verb sleduet. The closest English word is should. Under clause four point two of the twenty sixteen edition, it had recommendation status. Under clause four point seven of the twenty twenty-four edition, the same verb expresses a requirement. Suppose you read an English translation and treat should as advice. Then you will do less than the current edition requires. These labels describe the force of that specific term. An English translation must preserve the force assigned by the relevant edition.
That's why it is risky to reuse an old checklist without reading the new edition. Familiar words can carry different force.
The twenty twenty-four edition was approved on the twenty-fourth of October, by order one five zero four, s t. It became effective on the twentieth of December of the same year. Moving to it needs a gap analysis. Which obligations and evidence are already covered? Which ones need adjustment? And which ones need new work? Practices that already work well are a starting point for that analysis.
15A process continues after the first tool run25:15–26:55 · 182 слов · From the 2016 edition to 2024
A process needs more than a new heading. It organizes work that continues over time. It needs clear responsibilities, repeatable actions, and results that inform the next cycle.
Here's a memorable example. A team buys an analysis tool for a short time, just before a release. That may produce a report. It does not automatically establish a maintained process for examining changes, reviewing findings, fixing problems, and checking the result again.
Let's follow the loop for our importer team. A relevant code change triggers the analysis. A named engineer runs the check and reviews the findings. The team records a decision. Then the team reviews what should change before the next cycle. At the centre, the evidence connects the finding and the decision to the product version.
Trigger, ownership, evidence, and feedback give us a practical way to examine a process. The twenty sixteen edition already addressed lifecycle work, internal checks, and improvement.
The practical lesson is simple. A tool becomes useful inside an organized way of working. Planning gives the team the time, people, and agreements to keep that work going.
16When this standard actually binds26:55–29:15 · 276 слов · Legal force
People often ask me one question. Is this standard the law?
No. In Russia a national standard is applied voluntarily, unless the law says otherwise. The foreword of this edition points to the rules of application. They live in article twenty-six of Federal Law one six two, f z, of twenty fifteen. The standard does not make itself binding.
Clause four point fourteen tells us what makes it binding. Here is my working translation. The set of processes a developer must implement is determined by the requirements of regulatory legal acts, national and industry standards, technical specifications for research and development work, and other documents.
So something else has to point at the standard. In practice that is an order from a regulator, a customer contract, a certification scheme, or a company's own decision. The law adds one more trigger. A public claim of conformity binds you too.
The same clause adds one sharp detail. Once a document says you must conform, all the requirements apply. The only exceptions are requirements that use the words recommended or may.
Clause four point fifteen adds a special rule for research and development work. There the standard can bind only through an explicit list of processes in the technical specification. And that list may be partial.
One more point. FSTEC co-developed this edition. That is authorship, not law. A regulator writing a standard does not turn it into a legal duty.
So the useful question is not: is GOST mandatory? The useful question is: what in my situation points at it? Read that way, it is a best-practice baseline. Teams elsewhere use ISO or NIST documents the same way.
17Shared practices need evidence29:15–30:45 · 171 слов · Our comparison method
What can we conclude from the literature review? It finds substantial overlap in practices. It also finds organizational concerns, such as risk management, culture, policies, and communication.
The review distinguishes three kinds of work. Work at the level of the organization. Work across the lifecycle. And activities linked to a project stage. So a security programme is more than a list of tools.
Evidence about complete methodologies is limited and uneven. That does not show that secure development fails. It means we have to examine the evaluation method, the context, and the result being measured.
The review selected accessible English-language material. Its omission of GOST cannot establish that the Russian standard is unique.
An expert's experience can reveal useful questions. A broader conclusion still needs evidence about the context, the method, and the result.
We'll compare specific practices and evidence, using named versions. Our NIST baseline is final SSDF one point one. As of September twenty twenty-six, version one point two is still a draft. Let's make the comparison method explicit.
18Compare obligations, not labels30:45–32:35 · 195 слов · Our comparison method
Here's the method we will use. First, we take one specific requirement or practice. We record who acts, what they do, the scope, and any conditions. Second, we compare the actual work and the expected result.
We also keep the force of the original wording. Clause four point seven of the twenty twenty-four GOST defines which wording expresses a required condition. When we translate such a condition, we must convey a requirement rather than turn it into an optional recommendation. On the international side, we ask what we are reading. Is it framework guidance, a requirement, or an example of implementation? Similar wording does not automatically give two documents the same authority.
Third, we demonstrate one concrete implementation. We also name the records that would let another person verify the result.
Finally, our conclusion may be substantial overlap, partial overlap, or a complementary practice. If we have not found a counterpart, we will state which sources we reviewed.
This lets us study the main question of this series without deciding the answer in advance. A useful comparison can show shared engineering ideas. And it can still show important differences in scope, detail, and expected evidence.
19What process 5.1 asks for32:35–35:00 · 309 слов · Planning secure development
Now we can read the first process directly. Section five point one is about planning secure software development processes.
It has five requirements. Periodically analyse the current state of the processes. Periodically analyse resource needs. Develop a plan for improving the processes. Develop a plan for implementing them. And define their scope.
The two plans must take the analyses into account. That connection matters. A plan can look good on paper. But if it ignores what the team does today, or what resources the team has, it may be impossible to carry out.
I use process improvement plan as a working English label for the plan of process development. In a moment we'll see how it differs from the implementation plan.
For our small team, the first step is to describe what already happens and what does not. Then we find the biggest gaps. We estimate the capacity needed to close them. And we assign work the team can really do.
The standard requires periodic analysis, but it does not give us a universal ninety-day schedule. The schedule later in this episode is an illustrative choice for our example.
One caution before we build the plan. The standard also carries an informative appendix A, initialisation of secure development processes. It repeats almost the same steps for a team that is only starting these processes. Analyse the current state. Analyse the resources needed. Write the result down as a plan. Its artifacts are almost word for word the same as the ones in five point one. The difference is status. Under clause four point sixteen, assessment of the appendix A processes is not mandatory during an external audit. Clause five point one is a full process, and it is assessed. So if you are deciding which of these two very similar texts to implement, that difference is what settles it.
Источники слайда: G24
20Start with a defensible scope35:00–36:40 · 203 слов · Planning secure development
What exactly does the plan cover? In our example, the scope includes version two point zero of the importer, its parser module, the small service API, and the libraries that ship with it.
The repository, the integration configuration, and the release workflow form relevant development context. We record links to them, so the plan connects to actual work.
Suppose the team also has an old prototype. It may sit outside the chosen scope. But the team needs a reason. If code or a dependency from that prototype goes into the release, the boundary needs another look.
The standard's scope artifact lists the parts the software is made of. That means versions, modules, components and functional subsystems. It also gives the reason for that selection. If we name a product but do not name its relevant parts, we leave room for misunderstanding.
This is not permission to declare inconvenient components irrelevant. The rationale must make sense for the product and for the obligations that apply to it. In a teaching example, we can keep the scope small. For a real implementation, the team needs to look at the actual relationships. And it needs to keep the boundary up to date as the product changes.
21Assess reality and assign owners36:40–38:15 · 184 слов · Planning secure development
Let's start with three questions. What already works? What needs improvement? What is missing? Introducing a standard does not mean rebuilding everything from zero.
The current-state record lists which processes are in place and which are not. It assesses the existing processes against this standard, against other standards that apply, and against the team's tools and technologies.
In our example, parser checks run by hand. Coverage is unclear. The decision history is incomplete. These are fictional findings.
Now we assign responsibilities. The engineering lead owns integration. The AppSec lead helps define investigation criteria and review security evidence. The release owner records decisions under the team's policy. A sponsor resolves conflicts about capacity and priority.
One person may hold several roles. Even then, it must stay clear who is responsible and who decides.
This allocation is our implementation example. The standard's implementation-plan artifact must identify the employees responsible for implementing the processes. It does not automatically give AppSec an independent power to block every release. The organization must define that authority. And it must make the link between investigation, review, and the release decision clear.
22Resources include human attention38:15–39:50 · 183 слов · Planning secure development
Resource planning includes time. Time to set up the checks. Time to investigate findings. Time to keep the workflow running. And time to teach people how to use it.
Here's our ninety-day effort. It's fictional. We reserve sixty engineering hours, twenty-four AppSec hours, and twelve hours for release coordination and sponsor decisions. The total is ninety-six person-hours.
These figures are a teaching example. They are not a benchmark. They are not a percentage required by GOST. No universal percentage can replace an estimate of the actual work.
Tools, infrastructure, and the cost of extra training need their own assessment. Dependencies matter too. If the build engineer is not available during the first month, the schedule must show that. Assigning a task does not create capacity.
The standard's resource-analysis record may include an estimate of the material and human resources the work will need. The chart makes those assumptions open to discussion. Ask the people doing the work if the estimate is realistic. Show it to the people who set priorities. Agree when to update it. Human attention is part of the resource plan.
23Two plans, two questions39:50–41:30 · 185 слов · Planning secure development
Planning gives everyone a shared language: the team, its managers, and the people who ask for the product. Two related plans help them agree on the direction and the work.
The improvement plan describes how processes will develop. It sets priorities and the order of changes. It takes available resources into account. Our team might make parser analysis repeatable, improve the handling of findings, and then review the results.
The implementation plan identifies goals, stages, dates, resources, and responsible people. In the middle of the diagram, one task names the parser target, the integration milestone and the owner. On the right, the evidence records coverage and the review of findings.
The standard allows these plans to be represented in a task management system. A roadmap with linked tasks can keep their different purposes clear, and avoid documents that sit apart from the work.
Here's the practical test: traceability. Why was this change chosen? Which resource assumption supports it? Who does the work? What shows that a stage is finished? A planning page becomes useful when the team can follow those links and act on them.
24A 90-day plan for the importer41:30–43:45 · 244 слов · Worked example
Let's put those parts together in a ninety-day example. The product is the engineering-file importer. Our first goal is to handle findings from parser analysis the same way every time, and to make that work easy to review.
In days one to thirty, the team confirms the software scope. It writes down the current state. It reviews the resource estimate. It names the owner of each planned action, and the person responsible for the release decision. The result is a small baseline that anyone can look at.
In days thirty-one to sixty, the engineer connects the chosen parser checks to continuous integration. The team writes down which source targets and configurations are covered. Every finding gets a review record, and the release workflow links to that record.
In days sixty-one to ninety, the team looks at evidence from two example release cycles. Did the checks run on the intended versions? Did every finding get a decision? Was the agreed capacity enough? The answers shape the next improvement plan.
The ninety-day period, the two releases, and the detailed tasks are our choices. They do not come from the standard. And finishing this example does not establish conformity with every process in the document.
For implementation of this GOST, section four point thirteen requires the following in the development environment. Version control. Continuous integration. And task management, including defect tracking. It does not say continuous deployment. That difference is useful when we explain our pipeline choices.
25Five linked records of evidence43:45–45:20 · 177 слов · Worked example
The standard names five matching kinds of evidence. Current-state analysis. Resource analysis. The improvement plan. The implementation plan. And the scope, with the reasons for choosing it.
These are five kinds of information, not an instruction to create five separate Word files. Existing systems can carry this work. A planning page can link to repository and task records you already keep.
In our example, the scope names the importer version and components. The baseline links to the checks that ran. The resource record holds estimates and assumptions. The improvement plan explains priorities. The implementation tasks name owners and milestones.
The standard recognizes forms such as electronic files, logs, and tool results. Choose a form that carries the required information and keeps it traceable.
A one-page template is only an entry point. It does not replace the analysis behind it, and it does not prove effectiveness. A reviewer should be able to follow the links. They should find the right version, understand the decisions, and see which questions are still open. Automation helps when it keeps those connections.
26Every process is written the same way45:20–47:50 · 276 слов · Worked example
Before the crosswalk, here is your reading key for the other twenty-four episodes.
Clause four point eight says every process has the same four parts. The name of the process. Its goals. Its implementation requirements. And its artifacts of requirement implementation. I will say artifacts, or evidence.
The numbering follows that shape. Five point one is the name: planning secure software development processes. Goals come first, then requirements, then artifacts. You saw the five requirements earlier, and the five records a moment ago.
So open any process and read it in that order. What is the work for? What must we do? What must we be able to show afterwards?
Two details help with the artifacts. Clause four point eleven keeps the form open. An artifact is any information, in any form, that lets someone confirm the requirement was met. A document, a report, a file, a log, the result of a tool or a process. Then read the verb. Here, four of the five records must contain the listed information. For the resource analysis, the verb is may.
In most of the later processes, the first artifact is what the standard calls a reglament. In English, a written procedure. As a rule, it must cover two things. The duties and roles of the staff, and the details of how the process is carried out. The standard sets no format for it.
This shape also gives us the plan for every episode. Goals answer our first question: what problem does the process address? Requirements and artifacts answer the third: what can a team do and verify? The second question, the comparison, is where we go next.
Источники слайда: G24
27A first international crosswalk47:50–49:40 · 196 слов · Comparison result
Let's make a small comparison, with clear limits. In GOST, the implementation-plan artifact identifies the employees responsible for implementing the processes. NIST SSDF task P O two point one covers roles and responsibilities for secure software development. There is a useful shared concern. People need to know which work belongs to them.
But the comparison is partial. The GOST artifact also includes goals, timing, stages, and resources. That single SSDF task does not by itself reproduce the complete artifact.
Now look at process improvement. In OWASP SAMM, the Strategy and Metrics practice gives us a useful link. It focuses on an improvement strategy and a roadmap. Again, we need to examine the details, and the purpose of the model, before we claim equivalence.
These comparisons help us read the first process in a wider engineering context. They do not establish that following one document automatically satisfies the other.
So our first conclusion is a modest one. Planning, responsibility, and improvement have international counterparts we can recognize. But the exact structure, the wording, and the expected evidence still need to be examined, requirement by requirement. The notes with this episode keep those limits and the source versions.
28Would this survive Friday's release?49:40–51:15 · 181 слов · Apply it
Let's go back to Friday's warning. A plan will not tell us by itself whether that warning is a real vulnerability. The plan helps organize the investigation and the decision.
We can name the affected version and component. We can find the owner of the investigation, and the person authorized to make the release decision. And we can see what evidence we have, and which results are missing.
Weak planning is easy to spot too. An analyzer with no review owner is incomplete. A roadmap with no capacity is unreliable. A scope with no rationale is hard to defend.
For this team, I would review the plan after ninety days, and after a material change, such as adding a parser. These are our own recommendations for implementation.
In a small team, one person may hold several responsibilities. Make the arrangement explicit, and check the capacity. Scaling the implementation does not establish that applicable requirements can be ignored.
Here is the practical test. Can another team member understand the next action? If only the author can explain the plan, then improve it.
29Security Training That Changes Engineering Decisions51:15–53:10 · 203 слов · Stay in touch · Next episode
Today we followed the Russian standard from the early discussions to the editions that were adopted. We connected that history to international work. And we used its first process to organize a practical improvement effort.
Your next step is simple. Choose one product, and start your planning page. Describe the current state. Name the next improvement. Then connect it to an owner, to the capacity you have, and to evidence someone can review. The worksheet with this episode will help you start.
I am Vitaliy Pikov. You can find me at pikov dot expert, and on LinkedIn. My email and my Telegram channel are on the slide. Please keep in touch, and share the questions you would like this series to explore.
The next episode is called Security Training That Changes Engineering Decisions. We'll look at employee training under clause five point two. What do different roles need to learn? How do we practise those skills? And what evidence can show progress beyond attendance?
We'll build a role and skills matrix, and use a short exercise before and after the training. So, which engineering decision would you most like your security training to improve? Thank you for watching. See you in episode two.
Все 15 Markdown-документов
Каждый документ доступен в оформленном виде и как полный исходный Markdown. Контрольные суммы позволяют сопоставить эту версию с файлами проекта.
01Безопасная разработка: от истории методологий к работающим процессамPVS-2025-07-02-lecture.md
Безопасная разработка: от истории методологий к работающим процессам
Составитель учебного материала — Виталий Пиков, эксперт и преподаватель в области информационной безопасности. pikov.art.
Безопасность программного обеспечения складывается из решений, принятых на протяжении всей его жизни. Что команда считает допустимым риском? Как выбирает зависимости? Кто проверяет архитектуру? Что происходит с предупреждением анализатора? Кто отвечает на сообщение об уязвимости после выпуска? Ответы на эти вопросы определяют результат не меньше, чем выбранный язык программирования или набор инструментов.
Эта лекция связывает историю безопасной разработки с практической задачей: организовать работу так, чтобы требования безопасности выполнялись регулярно и их выполнение можно было проверить. Мы рассмотрим происхождение ГОСТ Р 56939-2016, его международный контекст, переход к редакции 2024 года и первый процесс — планирование безопасной разработки.
После изучения материала вы сможете:
- объяснить, почему проверка готового продукта должна дополняться работой с процессами его создания;
- различать историю разработки стандарта, содержание его требований и способы подтверждения соответствия;
- правильно сопоставлять редакции ГОСТ Р 56939-2016 и ГОСТ Р 56939-2024;
- оценить исходное состояние своей команды и определить приоритетные улучшения;
- связать намеченное улучшение с людьми, ресурсами, сроками и проверяемым результатом.
Введение
Безопасная разработка объединяет инженерные практики, стандарты и организацию работы. Введение задаёт общий контекст для исторической и практической частей.
1. Безопасность начинается раньше испытаний
Представим команду, которая разработала приложение и за неделю до выпуска заказала проверку безопасности. Проверка выявила уязвимость в механизме разграничения доступа. Исправить её заменой одной функции невозможно: ошибочное предположение заложено в архитектуру, интерфейсы и модель данных. Теперь нужно менять несколько компонентов и повторно проверять уже работавшие сценарии.
Проверка оказалась полезной — проблема обнаружена до поставки. Но она одновременно показала ограниченность подхода, при котором безопасность появляется только в конце. Чем раньше принимается решение, тем больше последующих работ может от него зависеть. Ошибка в требовании или архитектурном предположении способна породить множество формально правильных, но небезопасных реализаций.
Поэтому безопасная разработка охватывает требования, проектирование, реализацию, тестирование, поставку и сопровождение. На каждом этапе возникают свои вопросы и свои свидетельства выполнения работы. Финальные испытания остаются необходимыми, но получают поддержку со стороны остальных действий команды.
Безопасность продукта и безопасность процесса тесно связаны, однако не равнозначны. Наличие хорошего процесса не доказывает отсутствие всех уязвимостей. И наоборот, отсутствие известных уязвимостей в конкретном релизе ещё не показывает, что организация умеет устойчиво выпускать и сопровождать безопасное программное обеспечение. Нужно рассматривать и продукт, и способ его создания.
Практический смысл процесса заключается в повторяемости обоснованных действий. Команда должна уметь объяснить, когда требуется анализ, кто принимает решение, какие результаты сохраняются и как обнаруженная проблема влияет на дальнейшую разработку. Именно здесь начинается переход от отдельных полезных действий к управляемой инженерной работе.
2. Как развивались методологии безопасной разработки
Безопасная разработка не возникла вместе с одним стандартом или одной аббревиатурой. Разные организации решали сходные проблемы: предотвращение ошибок проектирования, подготовка разработчиков, анализ кода, проверка архитектуры, управление уязвимостями и организация взаимодействия между командами.
Крупные производители программного обеспечения начали оформлять собственные методологии раньше появления многих общих стандартов. Microsoft связывает включение SDL в процесс разработки с 2004 годом. Публикации о Touchpoints и CLASP также относятся к раннему этапу систематизации практик. Позднее развивались способы включения безопасности в итеративную разработку, модели организационной зрелости и общие рамки, пригодные для разных поставщиков.
При изучении истории важно различать дату появления практики, дату её описания и дату конкретной редакции документа. Например, год публикации книги о методологии не обязательно совпадает с годом начала её применения. Хронологическая шкала без такого уточнения легко создаёт ложное впечатление, что все предшествующие подходы отсутствовали.
Обзор Secure Software Development Methodologies: A Multivocal Literature Review рассматривает 28 подходов и публикаций из промышленной, государственной и академической среды. Его полезность состоит не только в перечне дат. Он показывает, насколько разные способы организации могут объединять сходные инженерные практики.
| Подход | На чём полезно сосредоточить внимание |
|---|---|
| Microsoft SDL | Согласованная программа инженерных практик, поддержка руководства и обучение |
| Touchpoints | Связь управления рисками, архитектурного анализа, проверки кода и накопления знаний |
| CLASP | Роли участников, конкретные действия и средства организации внедрения |
| SDL-Agile | Различная периодичность работ: однократно, в каждом спринте и через определённые интервалы |
| OWASP SAMM | Развитие организационных возможностей и последовательное повышение зрелости |
| BSIMM | Наблюдаемые практики организаций и возможность сопоставить с ними собственную программу |
| NIST SSDF | Общая рамка практик безопасной разработки, применимая к разным жизненным циклам |
Эти подходы нельзя ранжировать по числу перечисленных действий. Модель зрелости, описание наблюдаемой практики и набор требований решают разные задачи. Сначала нужно понять назначение документа, затем — способ его применения к конкретной организации.
Обзор обнаруживает существенное пересечение базовых практик, но не предоставляет единой убедительной шкалы эффективности полных методологий. Это повод задавать содержательные вопросы: какие риски учитываются, какие решения меняются, какие результаты проверяются? Отсутствие какого-либо национального стандарта в англоязычной выборке само по себе ничего не говорит о его уникальности или полезности.
Выбранные публикации и редакции из истории методологий. Обзор рассматривает 28 подходов; шкала не исчерпывает их историю.
Часть I. История и развитие национального стандарта
Исторический доклад: Виталий Вареница.
Эта часть объясняет замысел ГОСТ Р 56939, подготовку первой редакции, международные связи и развитие системы документов. Историю создания необходимо отличать от содержания утверждённых требований.
3. Зачем понадобился национальный стандарт
Требования к безопасности готового продукта не всегда достаточно подробно объясняют, как организовать его разработку. Можно установить ожидаемые защитные свойства, но оставить открытыми вопросы работы с исходным кодом, средой разработки, изменениями и найденными недостатками. Между требуемым результатом и повседневными действиями команды возникает разрыв.
Национальный стандарт безопасной разработки позволяет сформировать общую основу для разговора разработчика, заказчика и оценщика. Он задаёт содержание работ, которое можно применять к разным продуктам и организациям. Собственная методология крупного вендора обычно тесно связана с его структурой и инфраструктурой; общий стандарт должен оставлять пространство для иной реализации тех же задач.
По воспоминаниям Виталия Вареницы, одного из участников разработки ГОСТ Р 56939-2016, обсуждения необходимости такого документа шли примерно с 2009 года. Подготовка замысла и взаимодействие с коллегами и регуляторами предшествовали формальному началу работы над проектом. Следовательно, 2016 год обозначает утверждение документа, а не начало безопасной разработки в России.
Исходная задача состояла в том, чтобы дополнить внимание к отдельному продукту вниманием к деятельности разработчика. Требовалось описать работы, позволяющие предупреждать появление уязвимостей, обнаруживать их и организовывать устранение. Такая постановка естественно включает не только программистов, но и архитекторов, руководителей, специалистов по безопасности, тестированию и сопровождению.
Общий язык полезен также для независимой оценки. Если организация заявляет, что её разработка безопасна, необходимо понять содержание заявления и основание доверия к нему. Стандарт помогает сделать обсуждение конкретным: какие действия выполняются, какие обязанности определены и какие результаты можно рассмотреть.
4. История создания ГОСТ Р 56939-2016
Подготовка стандарта проходит несколько разных этапов: формирование идеи, разработка проекта, обсуждение, доработка, утверждение и введение в действие. Смешение этих событий искажает историю и затрудняет работу с источниками.
Вареница связывает основную подготовку первой редакции с НПО «Эшелон». Это не означает единоличного принятия стандарта одной компанией. Другие организации участвовали в рассмотрении и обсуждении проекта, направляли замечания и предложения. При этом непосредственная подготовка текста и внешнее рецензирование — разные формы участия, которые стоит различать.
| Событие | Дата | Значение |
|---|---|---|
| Начало разработки в рамках НИР | Апрель 2013 года | Организованная работа над проектом стандарта |
| Первая редакция проекта | Август 2013 года | Рабочий текст для последующего рассмотрения |
| Окончательная редакция проекта | Май 2014 года | Этап подготовки и согласования |
| Уточнённая окончательная редакция | Сентябрь 2015 года | Доработка проекта |
| Утверждение ГОСТ Р 56939-2016 | 1 июня 2016 года | Приказ Росстандарта № 458-ст |
| Введение в действие | 1 июня 2017 года | Начало действия утверждённой редакции |
Этапы подготовки проекта приведены по историческому докладу Вареницы. В нём также указаны 22 организации, участвовавшие в публичном обсуждении, и около 200 замечаний и предложений. Даты утверждения и введения в действие зафиксированы в официальных сведениях Росстандарта и в самом стандарте.
Предисловие ГОСТ Р 56939-2016 называет разработчиком ЗАО «НПО „Эшелон“», а организацией, внёсшей документ, — ТК 362 «Защита информации». Стандарт утверждён Росстандартом. Поэтому в историческом изложении необходимо точно называть и разработчика, и технический комитет, и орган утверждения.
Рабочие редакции текста не следует путать с утверждёнными национальными стандартами. В воспоминаниях о дальнейшей работе встречаются версии 2018, 2019, 2020 и 2022 годов. Из этого не следует существование отдельных действовавших ГОСТ Р 56939 с каждым из этих обозначений. При практическом сравнении рассматриваются утверждённые редакции 2016 и 2024 годов.
Первая редакция была тесно связана с процессами жизненного цикла и привычной для специалистов по оценке соответствия системой требований. Вареница характеризует её устройство как иерархическое: меры соотносятся с целями, результатами и условиями реализации. Такая структура может быть удобна специалисту, знакомому с соответствующим подходом, и требовать дополнительного объяснения для другой аудитории. Удобство чтения и техническая полнота — разные свойства документа.
Подготовка проекта, утверждение и введение стандарта в действие — разные этапы.
5. Международные связи: самостоятельность не означает изоляцию
ГОСТ Р 56939-2016 не следует описывать ни как перевод одной зарубежной методологии, ни как документ, возникший вне международной инженерной практики. Его содержание и заявленные связи показывают более содержательную картину: национальная рамка создавалась с учётом уже существовавших подходов.
Раздел 1 редакции 2016 года допускает применение стандарта как источника мер и средств управления безопасностью программного обеспечения по ГОСТ Р ИСО/МЭК 27034-1. Он также допускает его использование для конкретизации или расширения компонентов доверия ГОСТ Р ИСО/МЭК 15408-3. В справочном приложении А представлены соответствующие взаимосвязи с требованиями доверия Common Criteria.
Значимы и связи с процессами жизненного цикла по 12207 и системой менеджмента информационной безопасности по 27001. Они помогают увидеть место безопасной разработки в более широкой деятельности организации. Безопасность не должна существовать как изолированный набор действий, не связанный с управлением продуктом, изменениями и ответственностью.
NIST SSDF удобен для современного сопоставления с ГОСТ, но не мог быть источником первой редакции 2016 года: первый публичный проект SSDF был объявлен NIST 11 июня 2019 года. SSDF 1.1 опубликован как NIST SP 800-218 в 2022 году. Эта последовательность устанавливает границу возможной причинной связи, однако сама по себе не доказывает ни мирового первенства ГОСТ, ни обратного заимствования.
Сравнивать подходы полезно на уровне конкретной задачи. Возьмём обучение: кто должен обладать компетенцией, для какого решения она нужна, как выявляют пробел и как проверяют результат подготовки? Затем аналогично можно сравнить анализ требований, работу с зависимостями и обработку уязвимостей. Такое сопоставление даёт практический результат и не требует заранее объявлять один документ уникальным или полностью эквивалентным другому.
6. От первой редакции к системе связанных документов
По воспоминаниям Вареницы, первоначальный замысел включал несколько взаимосвязанных документов: общие требования, типовые угрозы, рекомендации по реализации и подход к оценке. Конкретный состав предполагаемого комплекта менялся. Поэтому историю семейства стандартов следует рассматривать как развитие замысла, а не как исполнение неизменного первоначального плана.
Одним из связанных документов стал ГОСТ Р 58412-2019 о типовых угрозах безопасности информации при разработке программного обеспечения. Его назначение помогает понять важное различие: угрозы самому процессу и среде разработки не сводятся к уязвимостям готового приложения. Можно нарушить целостность исходного кода, повлиять на сборку или управление изменениями и получить небезопасный результат даже при внешне корректной организации испытаний.
При переходе к новой редакции 56939 нужно заново рассмотреть связи этих угроз с изменившейся структурой работ. Недостаточно механически заменить номера старых групп мер номерами новых процессов. Следует установить, какая угроза рассматривается, какие действия должны ей противодействовать и какие результаты подтверждают выполнение этих действий. Содержание ранее выполненной работы может сохраниться, но его место в общей системе необходимо объяснить.
С развитием технологий потребовалась более подробная поддержка отдельных направлений: анализа кода, тестирования, сборки, работы с компонентами. Общий стандарт не обязан содержать инструкцию по настройке каждого инструмента. Его дополняют специальные документы, методологии и практические руководства.
Редакция ГОСТ Р 56939-2024 утверждена 24 октября 2024 года приказом Росстандарта № 1504-ст и введена в действие 20 декабря 2024 года. Работа над обновлением велась раньше; Вареница вспоминает подготовленный к 2022 году проект и последующее расширение участия организаций. Эти воспоминания объясняют ход подготовки, но не заменяют официальные сведения об утверждении.
В окончательной редакции 2016 года раздел 5 содержит девять групп мер: анализ требований; проектирование архитектуры; конструирование и комплексирование; квалификационное тестирование; инсталляцию и приёмку; решение проблем при эксплуатации; управление документацией и конфигурацией; инфраструктуру среды разработки; людские ресурсы. В редакции 2024 года выделено двадцать пять процессов.
Здесь сравниваются разные единицы группировки. Нельзя считать увеличение числа заголовков непосредственным доказательством большей безопасности. Часть содержания разделена, часть конкретизирована, появились более явные акценты на отдельных направлениях. Компенсирующие меры, предусмотренные п. 4.5 редакции 2016 года, не являются ещё двумя группами оглавления: это возможность иным способом достигнуть целей и результатов базовых мер при невозможности их обычной реализации.
Для организации переход означает анализ содержания: что уже выполняется, что требуется уточнить, какие результаты нужно дополнить и где возникли новые обязанности. Работающие практики не следует отменять только потому, что изменились номера пунктов.
Часть II. Применение ГОСТ и планирование безопасной разработки
Совместный практический разбор: Андрей Карпов и Виталий Пиков.
От устройства стандарта перейдём к работе команды: определению области применения, оценке текущего состояния, ресурсам, ответственности и планированию. В разборе методов проверки, ответственности, сопровождения и оценки соответствия также использованы объяснения Виталия Вареницы из общей дискуссии.
7. Мера и процесс: что делает работу устойчивой
Мера и процесс описывают разные стороны деятельности. Отдельное действие может снижать риск или поддерживать достижение результата. Процесс связывает действия во времени, определяет их взаимодействие, исполнителей и порядок управления. Замена слова в заголовке сама по себе такого порядка не создаёт.
Представим, что команда приобрела анализатор на три месяца, проверила код перед выпуском и закончила работу. Найденные проблемы удалось исправить, но через полгода код изменился, появилась новая зависимость, а несколько важных разработчиков перешли в другие проекты. Прежний отчёт сохраняет историческую ценность, однако не описывает состояние новой версии продукта.
Устойчивый процесс отвечает на следующий вопрос: что запускает повторную работу? Изменение кода, новый релиз, новая информация об уязвимости, изменение архитектуры или запланированный пересмотр могут требовать разных действий. Для каждого случая нужен понятный порядок, соответствующий рискам продукта.
Регулярность не равна частому автоматическому запуску. Если анализ выполняется в каждой сборке, но предупреждения не рассматриваются, ожидаемый эффект не достигается. Необходимо определить обработку результатов, ответственность за решение, сроки исправления и условия дальнейшего движения изменения.
При этом неверно представлять редакцию 2016 года набором исключительно разовых мероприятий. Её пп. 4.4 и 4.7–4.9 уже предусматривали реализацию мер, выделение ресурсов, внутренние проверки и улучшение процессов. Различия между редакциями нужно искать в конкретных формулировках и устройстве требований, а не в упрощённой формуле «раньше один раз, теперь постоянно».
Практический критерий устойчивости — возможность продолжить работу при обычных изменениях в продукте и команде. Если всё держится на памяти одного человека, полезная практика существует, но остаётся уязвимой организационно. Её поддерживают распределением обязанностей, понятными правилами и сохраняемыми результатами.
Учебная модель поддерживаемого процесса: действия, решения и обратная связь остаются связанными.
8. Как читать требования стандарта
Начинать работу со стандартом следует с области применения, терминов и общих положений. Переход прямо к интересующему инструменту может привести к ошибочному пониманию: отдельный пункт существует внутри общей системы правил, определяющей смысл требования и условия соответствия.
Особенно нагляден пример слова «следует». В ГОСТ Р 56939-2016 п. 4.2 оно использовано для выражения рекомендации среди других возможностей. В ГОСТ Р 56939-2024 п. 4.7 слова «должен» и «следует» выражают требования, которые должны быть выполнены. Привычное прочтение старой редакции нельзя автоматически переносить в новую.
Редакция 2024 года не устанавливает одну обязательную модель жизненного цикла для всех разработчиков. Безопасность необходимо включить в реально используемую организацию работы. У команды с короткими итерациями и у команды с крупными этапными поставками будут различаться календарь и способ исполнения, но содержание требуемых задач от этого не исчезает.
Описание процесса связывает его цели, требования к реализации и артефакты реализации. Цель помогает понять ожидаемый результат. Требования раскрывают необходимую работу. Артефакты дают возможность рассмотреть её исполнение. Полезно читать эти части вместе: документ, похожий на указанный артефакт, ещё не доказывает достижение цели.
Нужно также различать окончательную редакцию, проект, таблицу изменений и поясняющую презентацию. Проект может содержать полезную историческую информацию, которой нет в окончательном документе. Но формулировка из проекта не становится действующим требованием только потому, что удобнее изложена.
Наконец, стандарт, договор и правила оценки соответствия отвечают на разные вопросы. Чтобы определить обязательства конкретной организации, необходимо установить, какие документы к ней применимы и каким образом требуется подтвердить выполнение работ. Универсальный ответ на основании одного названия ГОСТ обычно недостаточен.
9. Проверки безопасности решают разные задачи
Ни один метод анализа не обнаруживает все виды проблем. Функциональные тесты помогают установить соответствие требуемому поведению. Статический анализ исследует код без его обычного выполнения. Фаззинг позволяет проверять поведение на множестве специально сформированных входных данных. Анализ архитектуры рассматривает решения и доверительные границы, которые могут не проявляться как локальный дефект в отдельной функции.
Тестирование на проникновение позволяет исследовать возможность достижения целей атакующего в заданных условиях. Его ценность состоит не только в обнаружении отдельных ошибок, но и в проверке того, как взаимодействуют компоненты и ограничения системы. Однако результат такой работы зависит от области, времени, доступной информации и выбранных сценариев.
Термины «нефункциональное тестирование» и «тестирование на проникновение» не следует считать универсальными синонимами. Они относятся к разным способам классификации работ. При применении конкретного стандарта нужно читать его определения и содержание соответствующего процесса, а не переносить привычное название без анализа.
Методы полезны в сочетании. Модель угроз помогает выбрать существенные сценарии; анализ архитектуры — оценить решения; проверки кода и выполняемой программы — обнаружить дефекты реализации; последующий анализ результатов — определить необходимые изменения. Инструмент занимает место внутри этой цепочки, а не заменяет её целиком.
Важно различать техническое наблюдение и окончательное заключение. Предупреждение анализатора, воспроизводимый сбой и подтверждённая уязвимость — разные состояния знания о проблеме. Их нельзя сводить к одной отметке «найден баг». Требуется анализ условий возникновения, последствий и связи с требованиями безопасности.
Выбор проверок должен объясняться задачами продукта. Недостаточно перечислить популярные сокращения в политике разработки. Команда должна понимать, что она хочет обнаружить, какую часть продукта проверяет и что сделает с результатом.
Разные методы отвечают на разные вопросы о продукте; их результаты полезны в сочетании.
10. Сторонний код и код, созданный с участием ИИ
После включения библиотеки в продукт её проблемы могут стать проблемами этого продукта. Внешнее происхождение компонента не освобождает разработчика от оценки его применения, отслеживания изменений и реакции на новые сведения об уязвимостях.
Поэтому open source нельзя оценивать как заведомо безопасный или заведомо опасный способ получения кода. Важно, как организация выбирает компонент, понимает его состав и назначение, контролирует версию и организует сопровождение. Собственноручно написанная библиотека тоже может содержать серьёзные недостатки.
Композиционный анализ помогает получить представление об используемых компонентах и известных связанных проблемах. Но обнаружение записи об уязвимости ещё не описывает полностью её влияние на конкретный продукт. Нужно установить версию, условия использования и доступность соответствующего поведения. Это повод для квалифицированного рассмотрения, а не основание автоматически проигнорировать предупреждение или объявить продукт скомпрометированным.
Особенно опасна неопределённость ответственности. Если обновление зависимости формально относится к разработчикам, сведения о проблемах получает отдел безопасности, а выпуском распоряжается другая команда, необходимо связать их действия. Иначе каждый участник может считать свою часть выполненной, а уязвимый компонент останется в поставке.
Тот же принцип распространяется на код, предложенный инструментом искусственного интеллекта. Способ получения фрагмента не заменяет проверку его смысла, корректности и безопасности. Команда принимает решение включить код в продукт и должна обеспечить необходимый анализ.
Это не исчерпывает специальные вопросы безопасности самих систем ИИ. Для них могут понадобиться дополнительные модели угроз и методы оценки. Но в обычной программной разработке базовое правило сохраняется: ответственность связана с принятым и поставленным продуктом, а не только с непосредственным авторством каждой строки.
11. Планирование: согласовать намерение с возможностями
Планирование безопасной разработки начинается с признания простой вещи: новые обязанности требуют ресурсов. Нельзя добавить анализ архитектуры, обработку результатов проверок и обучение, оставив прежнюю загрузку людей без каких-либо изменений и рассчитывая на устойчивое исполнение.
Затраты на физическую безопасность обычно легче представить. Если предприятие ограничивает доступ, ему нужны технические средства, правила и сотрудники. В программной разработке значительная часть затрат выражается во времени специалистов, поэтому её проще не заметить и заменить пожеланием «работайте внимательнее».
Первый процесс ГОСТ Р 56939-2024 помогает сделать потребность явной. Необходимо определить, что организация собирается выполнять, в каких границах и с какими ресурсами. План становится общим языком руководства, команды и заказчика: он связывает желаемое состояние с конкретными действиями.
Например, требование «внедрить композиционный анализ» слишком широко для исполнения. Нужны выбор продуктов и источников сведений о составе, определение места проверки, настройка обработки результатов, распределение ответственности и способ актуализации. Только после такого разложения можно обоснованно оценивать сроки и стоимость.
Планирование отвечает на четыре вопроса: что делать, когда, за какие средства и кто будет этим заниматься. Горизонт может быть разным — от ближайшей итерации до нескольких лет. Но даже долгосрочная программа должна иметь связь с ближайшими исполнимыми задачами.
Хороший план показывает не только намерения, но и зависимости. Если следующая практика требует определённой компетенции, её развитие нужно предусмотреть раньше или параллельно. Если результат зависит от подрядчика, необходимо согласовать взаимодействие. Если инструменту требуется доступ к инфраструктуре, эту работу нельзя оставить неявной.
12. Установить исходное состояние
Невозможно обоснованно спланировать улучшение, не понимая, что уже работает. Поэтому начальный этап включает инвентаризацию процессов и оценку готовности организации. Здесь важно избегать двух крайностей: считать всё отсутствующим или считать внедрённым всё, для чего нашлось знакомое название.
У команды уже могут существовать обучение, матрица компетенций, анализ кода, тестирование, управление изменениями и обработка обращений. Эти практики могли не называться безопасной разработкой. Их следует рассмотреть по содержанию: какие задачи они решают и насколько устойчиво выполняются.
Наличие статического анализатора — только начало обследования. Какой код проверяется? Какие правила включены? Когда выполняется запуск? Кто рассматривает результаты? Где фиксируется решение? Что происходит при обнаружении существенной проблемы? Ответы определяют состояние процесса точнее, чем отметка о приобретённой лицензии.
Полезно разделить результаты обследования на три группы:
- Сохранить: практика работает и решает нужную задачу в выбранной области.
- Доработать: основа существует, но есть пробелы в охвате, регулярности, ответственности или результатах.
- Создать: существенная работа отсутствует и требует организации с начала.
Такой подход предотвращает ненужное повторное внедрение и делает оценку ресурсов точнее. Расширение проверки на ещё один репозиторий отличается от создания новой инфраструктуры. Уточнение программы обучения отличается от подготовки людей, которые впервые будут заниматься соответствующей задачей.
Описание исходного состояния должно опираться на примеры исполнения. «Тестирование есть» — слишком широкое утверждение. Нужны границы, вид работы, исполнители и результаты. Если практика выполняется эпизодически или зависит от одного человека, это следует отразить честно: обнаруженная слабость — полезный результат обследования, а не повод улучшать формулировку отчёта.
13. Область применения и очередность внедрения
В крупной организации одновременно разрабатываются разные продукты, работают внутренние команды и подрядчики. Средств на одинаковое немедленное улучшение всей разработки может не быть. Планирование должно помочь определить очередность и объяснить её основания.
Приоритет нельзя выбирать только по удобству демонстрации. Нужно учитывать назначение продукта, его критичность, способы использования, зависимости, уже известные проблемы и применимые обязательства. Категоризация программного обеспечения делает эту логику понятной и воспроизводимой.
Хорошо выбранная начальная область позволяет проверить способ внедрения и затем расширить его. Но пилот имеет смысл только при понятном отношении к остальной программе. Нужно заранее определить, какие выводы будут использованы дальше, что требуется изменить перед распространением и кто отвечает за следующий этап.
Важно различать постепенное выполнение программы и заявление о полном соответствии. Организация может внедрить несколько практик и планировать остальные — это нормальное описание развития. Оно не равнозначно подтверждению всех требований применимого стандарта. При наличии договорных или регуляторных обязанностей границы и допустимый порядок реализации определяют с учётом этих обязанностей.
Иногда удобным первым техническим направлением становится композиционный анализ: состав продукта и известные проблемы компонентов дают конкретный предмет работы. В другом проекте более срочным может быть анализ архитектуры, управление доступом к исходному коду или исправление уже обнаруженного недостатка. Универсальная последовательность без знания продукта будет слишком грубой.
Обоснование области должно объяснять не только включённую часть, но и связь с остальным продуктом. Если проверяемый сервис полностью зависит от общей платформы сборки и библиотеки соседней команды, нельзя считать эти зависимости несущественными только потому, что они расположены в другом подразделении.
14. Как оценивать ресурсы и стоимость
Универсального процента удорожания безопасной разработки недостаточно для планирования. Стоимость зависит от исходного состояния, размера продукта, инфраструктуры, компетенций, требуемого охвата и способа подтверждения результатов. Одинаковый процент может скрывать совершенно разный объём работ.
Полезнее разделить затраты на запуск и регулярное исполнение. К запуску относятся первичное обследование, выбор подхода, настройка интеграций, подготовка правил и обучение. К регулярной работе — анализ результатов, исправления, сопровождение инфраструктуры, актуализация сведений и поддержание компетенций.
Бесплатное программное средство не означает бесплатного процесса. Его требуется установить, настроить, включить в разработку, обновлять и поддерживать. Платная лицензия, в свою очередь, не гарантирует, что у команды появилось время на обработку результатов. Инструментальная и человеческая части бюджета должны рассматриваться вместе.
Для каждой практики стоит определить исполнителей, ожидаемую загрузку, необходимые средства и внешние зависимости. Оценки на первом этапе могут быть приблизительными, но их основания должны быть видны. Если неизвестен объём предупреждений или трудоёмкость проверки, можно запланировать ограниченное обследование и уточнение оценки по его результатам.
Затраты также следует сопоставлять с целью улучшения. Организация может стремиться уменьшить вероятность определённых проблем, сократить время реакции или обеспечить обязательный порядок разработки. Не каждую пользу можно сразу выразить точной денежной суммой, но связь расхода с ожидаемым результатом должна быть объяснима.
Недостаток ресурсов требует управленческого решения: изменить сроки, область, способ реализации или выделение мощности команды в допустимых пределах. Он не должен незаметно превращаться в ситуацию, когда работа числится обязательной, но систематически не выполняется.
15. Люди, компетенции и распределение ответственности
Назначение одного ответственного за безопасную разработку не создаёт все необходимые компетенции. Анализ архитектуры, реализация, тестирование, сопровождение и управление изменениями требуют участия разных людей. Координатор помогает связать работу, но не заменяет каждого исполнителя.
Если в организации нет специалистов, способных оценить состояние и составить первый план, разумно подготовить инициативную группу или привлечь необходимую экспертизу. Такая группа должна помогать внедрению, а не становиться единственным местом, где вообще понимают безопасность продукта.
Обучение полезно связывать с решениями, которые человек принимает на работе. Разработчику, архитектору, руководителю проекта и специалисту по безопасности нужны разные глубина и содержание подготовки. Матрица компетенций становится рабочим инструментом тогда, когда показывает требуемые способности и конкретные пробелы.
Security champions могут помогать распространять знания внутри команд, обсуждать типовые проблемы и поддерживать взаимодействие со специалистами по безопасности. Но роль должна сопровождаться временем, понятными ожиданиями и доступом к помощи. Само присвоение названия не создаёт организационную возможность.
Сопротивление изменениям часто связано не только с убеждениями людей, но и с неясной нагрузкой. Если специалисту поручили новые проверки, а сроки функциональных задач остались прежними, возникает скрытый конфликт приоритетов. Его следует решать планированием и распределением обязанностей, а не предполагать, что дополнительная работа выполнится за счёт личного энтузиазма.
Обучение и планирование развиваются совместно. Для начального плана уже требуется некоторое понимание; затем план включает развитие компетенций для следующих этапов. Практический путь — сформировать достаточное ядро, выполнить первые действия и последовательно расширять возможности команды.
16. Какие результаты должны остаться после планирования
После планирования должен появиться связанный набор результатов, позволяющий приступить к работе и впоследствии проверить исполнение. Его ценность определяется содержанием и связями, а не количеством отдельных файлов.
Для разбора первого процесса ГОСТ Р 56939-2024 удобно выделить пять записей:
| Результат | На какой вопрос отвечает |
|---|---|
| Исходное состояние процессов | Что уже выполняется и какие пробелы обнаружены? |
| Обоснование области применения | Какие продукты и работы включены и почему? |
| Анализ потребности в ресурсах | Какие люди, время и средства нужны для исполнения? |
| План развития процессов | Какие возможности предстоит создать или улучшить и в какой очередности? |
| План реализации процессов | Как организовано выполнение запланированных работ? |
Пробел в исходном состоянии должен приводить к объяснимому улучшению. Улучшение — к ресурсам. Работа — к исполнителю, сроку и проверяемому результату. Иначе обследование, бюджет и календарный план могут существовать отдельно и описывать разные намерения.
Организационная документация может включать политику безопасной разработки, правила категоризации продуктов, регламент и порядок контроля. Это возможные формы реализации. Названия документов сами по себе не являются универсальным рецептом для любой команды.
Политика задаёт общие правила и ответственность. Регламент объясняет порядок действий. Рабочие записи показывают исполнение в конкретном проекте. Один уровень не заменяет остальные: общий документ не доказывает выполнение каждой задачи, а разрозненные заявки не всегда объясняют установленный порядок.
Необходимо предусмотреть пересмотр. Продукт, команда и доступные сведения меняются. Поэтому вопрос «кто и при каких условиях обновляет план?» столь же важен, как первоначальное утверждение. Неактуальный план может создавать ложную уверенность именно потому, что выглядит завершённым документом.
Пять связанных результатов планирования по процессу 5.1 ГОСТ Р 56939-2024.
17. Автоматизация работы и свидетельств
Выполнение требований не обязывает создавать сотни независимых текстовых документов и таблиц. Значительная часть сведений уже возникает в репозиториях, системах задач, результатах сборки и проверки. Разумная автоматизация помогает сохранить связи и уменьшить повторный ручной ввод.
Например, задача исправления может ссылаться на выявленную проблему, изменение кода, результат повторной проверки и решение ответственного. Если эти сведения доступны и управляемы, отчёт может формироваться на их основе. Это полезнее, чем отдельно переписывать историю изменения в документ, который быстро отстаёт от реальной работы.
Средства управления внедрением позволяют видеть состояние практик, распределять задачи и собирать свидетельства. Но процент заполненных карточек не следует автоматически принимать за процент безопасности. Любая отметка должна иметь понятный критерий и содержательное основание.
Автоматизация особенно важна для регулярных действий. При этом она требует сопровождения: изменение сборки, структуры репозитория или формата отчёта может нарушить прежнюю связь. За инструментами и интеграциями также должны стоять владельцы и правила проверки их работы.
Выбирать систему стоит после определения необходимых действий и записей. Иначе организация рискует подстроить процесс под удобные поля приобретённого продукта и потерять существенные вопросы, для которых в нём не нашлось готового шаблона.
Тот же способ рассуждения помогает при чтении сложных документов по управлению конфигурацией и другим обеспечивающим процессам. Начните с вопросов: какие объекты требуется учитывать, кто вправе их изменять, как воспроизводится состояние и где остаётся история решений? Затем сопоставьте полученный порядок с требованиями документа. Сложность стандарта становится более понятной, когда его положения связаны с конкретными объектами и действиями команды.
18. Сопровождение и работа с выявленными недостатками
Безопасная разработка продолжается после выпуска. Даже тщательно проверенная версия меняется в своём контексте: появляются новые сведения о компонентах, способы атак и требования к эксплуатации. Организация должна уметь получать эту информацию и превращать её в действия.
Базовая цепочка включает получение сообщения, регистрацию, анализ, определение необходимых изменений, проверку исправления и поставку результата. В зависимости от продукта и обязательств может потребоваться информирование заказчиков, пользователей и других сторон. Конкретный порядок задаётся применимыми требованиями и принятой организацией работы.
Здесь особенно заметна разница между наличием контактного адреса и работающим процессом. Пользователь может отправить сообщение, но важно, кто его получит, как будет определена значимость и что произойдёт дальше. Обращение не должно теряться между поддержкой, разработкой и специалистами по безопасности.
Сопровождение связано с управлением версиями и изменениями. Нужно понимать, какие поставки затронуты проблемой, для каких поддерживаемых ветвей требуется исправление и как убедиться, что изменение дошло до нужных получателей. Без учёта состава и конфигурации продукта такая работа становится ненадёжной.
Обработка обычных дефектов и уязвимостей может использовать общую инфраструктуру, но должна учитывать различия в последствиях, срочности и обращении с информацией. Важно не только зарегистрировать проблему, но и принять обоснованное решение о ней.
Окончание поддержки также требует ясности. Пользователь должен понимать границы обязательств поставщика, а организация — учитывать условия своих договоров и систем оценки соответствия. Судьба конкретного сертификата или обязательства после прекращения поддержки определяется соответствующими документами, а не общей формулой для всех продуктов.
Учебная схема работы с недостатком на протяжении сопровождения продукта.
19. Соответствие, сертификация процессов и сертификация продукта
Полезно различать несколько вопросов. Выполняет ли команда определённые инженерные практики? Соответствуют ли они требованиям выбранного стандарта? Нужна ли отдельная сертификация процессов? Как оценивается сам продукт? Какие требования предъявляются к применяемым инструментам? Эти вопросы связаны, но ответы на них не совпадают автоматически.
Если заказчик требует соблюдения ГОСТ, необходимо установить содержание требования: редакцию документа, область применения, объект и способ подтверждения. Упоминание стандарта само по себе не объясняет все условия оценки. Дополнительные обязанности могут следовать из договора или применимого регулирования.
Государственные информационные системы (ГИС) и объекты критической информационной инфраструктуры (КИИ) нельзя автоматически подводить под один набор требований. Перед применением документа определяют вид системы, роль организации и область действия документа. Сходство инженерных задач безопасной разработки само по себе не устанавливает применимость конкретного требования.
Соответствие стандарту не следует без дальнейшего анализа отождествлять с наличием отдельного сертификата процессов. Однако столь же неверно утверждать, что сертификат никогда не требуется. В каждом случае нужно понимать конкретный режим и установленные правила подтверждения.
Сертификация продукта и оценка процесса могут влиять друг на друга, в том числе при организации последующих изменений. Но возможность обновления конкретного сертифицированного продукта зависит от применимых условий. Общий рассказ о преимуществах сертификации не является достаточным основанием для выбора процедуры изменения.
Отдельный предмет — инструменты разработки и проверки. Пригодность анализатора для определённых задач, выполнение специальных требований к нему и зрелость процессов организации — разные объекты оценки. Наличие подходящего инструмента не доказывает правильности его применения и полноты всей программы безопасной разработки.
Для бизнеса важно также планировать внешнюю оценку: компетенции исполнителей, необходимые материалы, сроки и взаимодействие. Но сведения о реестрах, аккредитациях и очередях меняются. Их следует проверять при принятии конкретного решения, а не использовать прежнюю ситуацию как неизменное свойство рынка.
Практический принцип — ясно формулировать заявление о достигнутом состоянии. «Используем отдельные практики», «внедрили процессы в такой-то области» и «подтвердили соответствие в установленном порядке» означают разное. Точность формулировки помогает и команде, и заказчику понимать реальные основания доверия.
20. Небольшая команда: соразмерность и обязательства
Переносить организационную конструкцию крупной компании в команду из трёх человек буквально обычно неразумно. Выделенные подразделения, сложная инфраструктура и большое количество независимых документов могут потребовать больше ресурсов, чем сама разработка. Но из этого не следует, что небольшому продукту не нужна безопасность.
Число сотрудников не определяет автоматически ни критичность продукта, ни применимые обязанности. Небольшая команда может создавать программное обеспечение с существенными функциями безопасности или работать в условиях строгих договорных требований. Тогда ограничения ресурсов необходимо учитывать при организации исполнения, а не объявлять освобождением от работы.
Соразмерность означает выбор понятной реализации. Один человек может совмещать несколько ролей; существующая система задач может хранить разные типы свидетельств; часть экспертизы можно получать извне. При этом нужно учитывать ограничения совмещения, доступность времени и необходимость независимости там, где она требуется.
Если небольшая команда работает внутри крупной организации, общие службы могут предоставлять инфраструктуру, анализ и обучение. Но это должно быть согласовано. Наличие отдела безопасности в организационной структуре ещё не означает, что его ресурсы зарезервированы для конкретного проекта.
Для малого проекта особенно полезны ограниченная ясная область, приоритеты и регулярность. Несколько устойчиво выполняемых действий могут стать основой дальнейшего развития. Однако описывать состояние нужно честно: частичное внедрение полезных практик не следует выдавать за полное выполнение требований, которые фактически не обеспечены.
21. Как учиться безопасной разработке
Безопасная разработка объединяет несколько самостоятельных дисциплин. Архитектурный анализ, тестирование, управление зависимостями, организация процессов и обработка уязвимостей требуют разных знаний и практического опыта. Поэтому поиск одной книги, которая полностью заменит подготовку по всем направлениям, редко приводит к нужному результату.
Эффективнее строить обучение вокруг рабочих задач. Стандарт помогает определить требования. Методология показывает способ организации. Техническое руководство объясняет метод. Практическое упражнение позволяет проверить, способен ли человек применить знание к своему продукту.
Например, после знакомства с моделированием угроз полезно получить не только ответы на тест, но и небольшую модель конкретного компонента с объяснением границ и предположений. После обучения анализатору — разобранные результаты и понимание дальнейших действий. После изучения планирования — обоснованный план улучшения с ресурсами и ответственностью.
Обучение должно продолжаться вместе с изменением обязанностей. Новый язык, технология, архитектурный подход или роль могут создать новый пробел в компетенциях. Поэтому матрица подготовки и учебные материалы нуждаются в актуализации так же, как технические правила разработки.
Полезна небольшая объяснённая библиотека источников. Для каждого материала стоит указывать, какой вопрос он помогает решить и к какой версии относится. Это делает подборку пригодной для повседневной работы и уменьшает риск применения устаревшего совета к новой ситуации.
Документ об обучении подтверждает определённый образовательный результат. Его не следует смешивать с сертификатом продукта или процессов разработки. Для организации важнее всего связь между подготовкой человека и качеством решений, которые он способен принимать после обучения.
Учебный практикум
Практическая работа объединяет результаты обеих частей и предназначена для самостоятельного выполнения.
22. Практическая работа: первый план для одного продукта
Рассмотрим учебный пример. Команда разрабатывает сервис обработки файлов. Исходный код хранится в системе управления версиями, сборка автоматизирована, есть функциональные тесты. Зависимости обновляются нерегулярно, предупреждения анализатора рассматриваются без общего порядка, а сообщения о проблемах поступают через обычную поддержку.
Начинать следует с описания реального состояния. Автоматизированная сборка — существующая возможность, которую можно использовать. Отсутствие общего порядка обработки предупреждений — пробел процесса. Нерегулярная актуализация зависимостей — ещё одна задача. При этом пока недостаточно сведений, чтобы объявить какую-либо из этих тем полностью внедрённой или полностью отсутствующей.
Затем команда определяет область первого улучшения. Например, один поддерживаемый сервис и его состав, включая используемые компоненты и сборку. Выбор нужно объяснить назначением продукта, выявленными проблемами и доступными ресурсами. Следует указать связанные элементы за пределами команды и необходимое взаимодействие с их владельцами.
Далее формируется небольшая программа работ:
| Шаг | Содержание | Проверяемый результат |
|---|---|---|
| Установить состав | Определить используемые компоненты и источники сведений о них | Проверяемая запись о составе выбранной версии |
| Определить обработку результатов | Согласовать участников, порядок рассмотрения и фиксации решений | Описанный порядок и пример его исполнения |
| Включить проверку в разработку | Определить условия запуска и связать результаты с задачами | Проверка реального изменения с сохранёнными результатами |
| Подготовить участников | Обучить людей необходимым решениям и действиям | Разобранные примеры, подтверждающие понимание работы |
| Пересмотреть план | Оценить трудоёмкость, ограничения и следующий этап | Обновлённое решение о развитии и ресурсах |
Это учебная последовательность, а не универсальный порядок для любого проекта. В другой команде исходное состояние и приоритеты будут иными. Существенна связь между выявленной проблемой, выбранной работой и доказательством её результата.
После подготовки плана полезно проверить его на обычном рабочем событии: завтра нужно выпустить изменение, а проверка обнаружила существенную проблему. Кто её рассматривает? Где фиксируется решение? Кто обеспечивает исправление? Как проверяется результат? Каковы полномочия участников? Если ответы приходится придумывать заново, плану не хватает связи с исполнением.
Для самостоятельной работы выберите один продукт или компонент. Опишите его исходное состояние, обоснуйте область применения, оцените необходимые ресурсы и определите ближайшее улучшение. Свяжите каждую работу с ответственным, сроком и ожидаемым результатом. Затем предложите событие, при котором план потребуется пересмотреть.
Практическая работа: проследите связь от выявленного пробела до результата исполнения.
Вопросы и ответы
Здесь собраны вопросы общей дискуссии и пояснения, полезные при применении материала к своему продукту.
Чем полезен ГОСТ, если сертификация не планируется?
Он даёт общую рамку для оценки и развития разработки. Можно сопоставить свои практики с задачами стандарта, обнаружить пробелы и выбрать улучшения. При этом необходимо точно описывать, какие требования приняты и что фактически реализовано, не заявляя автоматически полного соответствия.
Девять групп мер и двадцать пять процессов — это показатель прогресса?
Это прежде всего различие структуры. Для оценки изменений нужно сопоставлять содержание, детализацию, обязанности и результаты. Количество заголовков не измеряет безопасность и не показывает напрямую объём дополнительной работы.
Почему нельзя читать «следует» одинаково в обеих редакциях?
Потому что стандарты сами определяют смысл этой формулировки. В п. 4.2 редакции 2016 года она обозначает рекомендацию; в п. 4.7 редакции 2024 года — требование, которое должно быть выполнено. Значение нужно устанавливать по применимому документу.
Можно ли ограничиться одним анализатором?
Один инструмент покрывает определённый круг задач и имеет ограничения. Требования, архитектура, используемые компоненты, поведение системы и сопровождение требуют разных видов работы. Кроме того, результаты анализа должны быть включены в процесс принятия решений.
С чего начать, если процессы безопасности не организованы?
С людей, способных понять задачу, и с обследования исходного состояния. Затем нужно определить область, приоритетные пробелы, ресурсы и ближайшие действия. Даже в такой ситуации у организации обычно уже есть полезные практики, которые можно сохранить и развить.
Должны ли сначала пройти обучение все сотрудники?
Не обязательно одновременно и по одинаковой программе. Для начала нужны компетенции, позволяющие организовать обследование и планирование. Последующее обучение распределяют по ролям и задачам, связывая его с этапами внедрения.
Кто отвечает за безопасную разработку?
Обязанности распределяются между участниками жизненного цикла. Координатор связывает работу, но архитектор, разработчик, тестировщик и руководитель сохраняют ответственность за свои решения. Обязанности должны сопровождаться ресурсами и полномочиями.
Какой процент бюджета нужно добавить?
Универсальная цифра не заменяет расчёт. Нужно учитывать исходное состояние, разовые работы, регулярное исполнение, нагрузку людей и сопровождение средств. Первые оценки можно уточнять на ограниченной области по результатам практического выполнения.
Можно ли внедрять процессы постепенно?
Развитие можно планировать по этапам, но при этом нужно учитывать применимые обязательства. Частичное внедрение следует описывать как частичное. Оно не становится полным соответствием только благодаря наличию дорожной карты.
Требует ли ГОСТ множества отдельных файлов?
Существенны содержание, управляемость и проверяемость результатов. Рабочие системы могут поддерживать необходимые сведения и связи. Однако автоматизация не отменяет требований к самим действиям и достаточности свидетельств.
Чем open source отличается с точки зрения ответственности?
Внешнее происхождение требует учитывать особенности получения и сопровождения компонента, но не снимает ответственности за его использование в продукте. Нужно знать состав, отслеживать проблемы и организовывать необходимые действия.
Нужно ли проверять код, предложенный ИИ?
Да. Команда принимает решение о включении кода и должна обеспечить его проверку. Способ получения фрагмента не гарантирует ни корректности, ни безопасности и не заменяет инженерную ответственность.
Нужен ли отдельный сертификат, если заказчик требует ГОСТ?
Это определяется содержанием требования, договором и применимыми правилами оценки. Выполнение стандарта и получение отдельного сертификата — разные вопросы, которые нужно явно согласовать. Название документа само по себе не даёт полного ответа.
Обязательно ли сертифицировать каждый применяемый инструмент?
Требования к инструментам определяются конкретным контекстом. Нельзя автоматически переносить условия оценки продукта на любое средство разработки. Пригодность инструмента, соблюдение специальных требований к нему и корректность его применения следует рассматривать отдельно.
Что меняется для небольшой команды?
Меняется способ организации: роли могут совмещаться, инфраструктура — предоставляться централизованно, экспертиза — привлекаться извне. Но критичность продукта и применимые обязанности не исчезают из-за небольшого числа сотрудников.
Как понять, что внедрение начало работать?
Рассмотреть реальные изменения и проблемы продукта. Выполняются ли предусмотренные действия? Понятны ли решения и ответственность? Сохраняются ли результаты? Использует ли команда полученные сведения для исправлений и улучшения порядка работы? Такой разбор содержательнее одной отметки «процесс внедрён».
Источники для дальнейшего изучения
- ГОСТ Р 56939-2016. Защита информации. Разработка безопасного программного обеспечения. Общие требования. Для исторического сравнения особенно полезны разделы 1, 4, 5 и приложение А. Официальные сведения Росстандарта.
- ГОСТ Р 56939-2024. Защита информации. Разработка безопасного программного обеспечения. Общие требования. Общие положения определяют правила применения; п. 5.1 посвящён планированию. Официальные сведения Росстандарта.
- ГОСТ Р 58412-2019. Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.
- Виталий Вареница. «История создания и актуальное состояние РБПО в России. ГОСТ Р 56939-2016/24». Исторический доклад НПО «Эшелон», представленный 2 июля 2025 года.
- Arina Kudriavtseva, Olga Gadyatskaya. Secure Software Development Methodologies: A Multivocal Literature Review. Препринт arXiv:2211.16987v2, 4 июля 2023 года. Полезен для сопоставления назначения и содержания разных подходов. Версия v2.
- NIST SP 800-218. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, 2022. Окончательная публикация. Для исторической шкалы: объявление первого публичного проекта SSDF, 11 июня 2019 года.
- Microsoft Security Development Lifecycle. История и назначение SDL. Официальное описание.
- OWASP SAMM. Модель развития организационной зрелости безопасной разработки. Материалы проекта.
Основа материала — вебинар МАСКОМ и PVS-Studio от 2 июля 2025 года, проведённый Виталием Пиковым и Андреем Карповым, и исторический доклад Виталия Вареницы. Исторические сведения об участниках и этапах подготовки проекта атрибутированы докладчику; сведения об утверждённых редакциях приведены по соответствующим стандартам. Практическая работа в разделе 22 — учебный пример.
Исходный Markdown целиком
# Безопасная разработка: от истории методологий к работающим процессам
**Составитель учебного материала — Виталий Пиков**, эксперт и преподаватель в области информационной безопасности. [pikov.art](https://pikov.art).
Безопасность программного обеспечения складывается из решений, принятых на протяжении всей его жизни. Что команда считает допустимым риском? Как выбирает зависимости? Кто проверяет архитектуру? Что происходит с предупреждением анализатора? Кто отвечает на сообщение об уязвимости после выпуска? Ответы на эти вопросы определяют результат не меньше, чем выбранный язык программирования или набор инструментов.
Эта лекция связывает историю безопасной разработки с практической задачей: организовать работу так, чтобы требования безопасности выполнялись регулярно и их выполнение можно было проверить. Мы рассмотрим происхождение ГОСТ Р 56939-2016, его международный контекст, переход к редакции 2024 года и первый процесс — планирование безопасной разработки.
После изучения материала вы сможете:
- объяснить, почему проверка готового продукта должна дополняться работой с процессами его создания;
- различать историю разработки стандарта, содержание его требований и способы подтверждения соответствия;
- правильно сопоставлять редакции ГОСТ Р 56939-2016 и ГОСТ Р 56939-2024;
- оценить исходное состояние своей команды и определить приоритетные улучшения;
- связать намеченное улучшение с людьми, ресурсами, сроками и проверяемым результатом.
## Введение
Безопасная разработка объединяет инженерные практики, стандарты и организацию работы. Введение задаёт общий контекст для исторической и практической частей.
### 1. Безопасность начинается раньше испытаний
Представим команду, которая разработала приложение и за неделю до выпуска заказала проверку безопасности. Проверка выявила уязвимость в механизме разграничения доступа. Исправить её заменой одной функции невозможно: ошибочное предположение заложено в архитектуру, интерфейсы и модель данных. Теперь нужно менять несколько компонентов и повторно проверять уже работавшие сценарии.
Проверка оказалась полезной — проблема обнаружена до поставки. Но она одновременно показала ограниченность подхода, при котором безопасность появляется только в конце. Чем раньше принимается решение, тем больше последующих работ может от него зависеть. Ошибка в требовании или архитектурном предположении способна породить множество формально правильных, но небезопасных реализаций.
Поэтому безопасная разработка охватывает требования, проектирование, реализацию, тестирование, поставку и сопровождение. На каждом этапе возникают свои вопросы и свои свидетельства выполнения работы. Финальные испытания остаются необходимыми, но получают поддержку со стороны остальных действий команды.
Безопасность продукта и безопасность процесса тесно связаны, однако не равнозначны. Наличие хорошего процесса не доказывает отсутствие всех уязвимостей. И наоборот, отсутствие известных уязвимостей в конкретном релизе ещё не показывает, что организация умеет устойчиво выпускать и сопровождать безопасное программное обеспечение. Нужно рассматривать и продукт, и способ его создания.
Практический смысл процесса заключается в повторяемости обоснованных действий. Команда должна уметь объяснить, когда требуется анализ, кто принимает решение, какие результаты сохраняются и как обнаруженная проблема влияет на дальнейшую разработку. Именно здесь начинается переход от отдельных полезных действий к управляемой инженерной работе.
### 2. Как развивались методологии безопасной разработки
Безопасная разработка не возникла вместе с одним стандартом или одной аббревиатурой. Разные организации решали сходные проблемы: предотвращение ошибок проектирования, подготовка разработчиков, анализ кода, проверка архитектуры, управление уязвимостями и организация взаимодействия между командами.
Крупные производители программного обеспечения начали оформлять собственные методологии раньше появления многих общих стандартов. Microsoft связывает включение SDL в процесс разработки с 2004 годом. Публикации о Touchpoints и CLASP также относятся к раннему этапу систематизации практик. Позднее развивались способы включения безопасности в итеративную разработку, модели организационной зрелости и общие рамки, пригодные для разных поставщиков.
При изучении истории важно различать дату появления практики, дату её описания и дату конкретной редакции документа. Например, год публикации книги о методологии не обязательно совпадает с годом начала её применения. Хронологическая шкала без такого уточнения легко создаёт ложное впечатление, что все предшествующие подходы отсутствовали.
Обзор *Secure Software Development Methodologies: A Multivocal Literature Review* рассматривает 28 подходов и публикаций из промышленной, государственной и академической среды. Его полезность состоит не только в перечне дат. Он показывает, насколько разные способы организации могут объединять сходные инженерные практики.
| Подход | На чём полезно сосредоточить внимание |
|---|---|
| Microsoft SDL | Согласованная программа инженерных практик, поддержка руководства и обучение |
| Touchpoints | Связь управления рисками, архитектурного анализа, проверки кода и накопления знаний |
| CLASP | Роли участников, конкретные действия и средства организации внедрения |
| SDL-Agile | Различная периодичность работ: однократно, в каждом спринте и через определённые интервалы |
| OWASP SAMM | Развитие организационных возможностей и последовательное повышение зрелости |
| BSIMM | Наблюдаемые практики организаций и возможность сопоставить с ними собственную программу |
| NIST SSDF | Общая рамка практик безопасной разработки, применимая к разным жизненным циклам |
Эти подходы нельзя ранжировать по числу перечисленных действий. Модель зрелости, описание наблюдаемой практики и набор требований решают разные задачи. Сначала нужно понять назначение документа, затем — способ его применения к конкретной организации.
Обзор обнаруживает существенное пересечение базовых практик, но не предоставляет единой убедительной шкалы эффективности полных методологий. Это повод задавать содержательные вопросы: какие риски учитываются, какие решения меняются, какие результаты проверяются? Отсутствие какого-либо национального стандарта в англоязычной выборке само по себе ничего не говорит о его уникальности или полезности.
*Выбранные публикации и редакции из истории методологий. Обзор рассматривает 28 подходов; шкала не исчерпывает их историю.*
## Часть I. История и развитие национального стандарта
**Исторический доклад: Виталий Вареница.**
Эта часть объясняет замысел ГОСТ Р 56939, подготовку первой редакции, международные связи и развитие системы документов. Историю создания необходимо отличать от содержания утверждённых требований.
### 3. Зачем понадобился национальный стандарт
Требования к безопасности готового продукта не всегда достаточно подробно объясняют, как организовать его разработку. Можно установить ожидаемые защитные свойства, но оставить открытыми вопросы работы с исходным кодом, средой разработки, изменениями и найденными недостатками. Между требуемым результатом и повседневными действиями команды возникает разрыв.
Национальный стандарт безопасной разработки позволяет сформировать общую основу для разговора разработчика, заказчика и оценщика. Он задаёт содержание работ, которое можно применять к разным продуктам и организациям. Собственная методология крупного вендора обычно тесно связана с его структурой и инфраструктурой; общий стандарт должен оставлять пространство для иной реализации тех же задач.
По воспоминаниям Виталия Вареницы, одного из участников разработки ГОСТ Р 56939-2016, обсуждения необходимости такого документа шли примерно с 2009 года. Подготовка замысла и взаимодействие с коллегами и регуляторами предшествовали формальному началу работы над проектом. Следовательно, 2016 год обозначает утверждение документа, а не начало безопасной разработки в России.
Исходная задача состояла в том, чтобы дополнить внимание к отдельному продукту вниманием к деятельности разработчика. Требовалось описать работы, позволяющие предупреждать появление уязвимостей, обнаруживать их и организовывать устранение. Такая постановка естественно включает не только программистов, но и архитекторов, руководителей, специалистов по безопасности, тестированию и сопровождению.
Общий язык полезен также для независимой оценки. Если организация заявляет, что её разработка безопасна, необходимо понять содержание заявления и основание доверия к нему. Стандарт помогает сделать обсуждение конкретным: какие действия выполняются, какие обязанности определены и какие результаты можно рассмотреть.
### 4. История создания ГОСТ Р 56939-2016
Подготовка стандарта проходит несколько разных этапов: формирование идеи, разработка проекта, обсуждение, доработка, утверждение и введение в действие. Смешение этих событий искажает историю и затрудняет работу с источниками.
Вареница связывает основную подготовку первой редакции с НПО «Эшелон». Это не означает единоличного принятия стандарта одной компанией. Другие организации участвовали в рассмотрении и обсуждении проекта, направляли замечания и предложения. При этом непосредственная подготовка текста и внешнее рецензирование — разные формы участия, которые стоит различать.
| Событие | Дата | Значение |
|---|---|---|
| Начало разработки в рамках НИР | Апрель 2013 года | Организованная работа над проектом стандарта |
| Первая редакция проекта | Август 2013 года | Рабочий текст для последующего рассмотрения |
| Окончательная редакция проекта | Май 2014 года | Этап подготовки и согласования |
| Уточнённая окончательная редакция | Сентябрь 2015 года | Доработка проекта |
| Утверждение ГОСТ Р 56939-2016 | **1 июня 2016 года** | Приказ Росстандарта № 458-ст |
| Введение в действие | **1 июня 2017 года** | Начало действия утверждённой редакции |
Этапы подготовки проекта приведены по историческому докладу Вареницы. В нём также указаны 22 организации, участвовавшие в публичном обсуждении, и около 200 замечаний и предложений. Даты утверждения и введения в действие зафиксированы в официальных сведениях Росстандарта и в самом стандарте.
Предисловие ГОСТ Р 56939-2016 называет разработчиком ЗАО «НПО „Эшелон“», а организацией, внёсшей документ, — ТК 362 «Защита информации». Стандарт утверждён Росстандартом. Поэтому в историческом изложении необходимо точно называть и разработчика, и технический комитет, и орган утверждения.
Рабочие редакции текста не следует путать с утверждёнными национальными стандартами. В воспоминаниях о дальнейшей работе встречаются версии 2018, 2019, 2020 и 2022 годов. Из этого не следует существование отдельных действовавших ГОСТ Р 56939 с каждым из этих обозначений. При практическом сравнении рассматриваются утверждённые редакции 2016 и 2024 годов.
Первая редакция была тесно связана с процессами жизненного цикла и привычной для специалистов по оценке соответствия системой требований. Вареница характеризует её устройство как иерархическое: меры соотносятся с целями, результатами и условиями реализации. Такая структура может быть удобна специалисту, знакомому с соответствующим подходом, и требовать дополнительного объяснения для другой аудитории. Удобство чтения и техническая полнота — разные свойства документа.
*Подготовка проекта, утверждение и введение стандарта в действие — разные этапы.*
### 5. Международные связи: самостоятельность не означает изоляцию
ГОСТ Р 56939-2016 не следует описывать ни как перевод одной зарубежной методологии, ни как документ, возникший вне международной инженерной практики. Его содержание и заявленные связи показывают более содержательную картину: национальная рамка создавалась с учётом уже существовавших подходов.
Раздел 1 редакции 2016 года допускает применение стандарта как источника мер и средств управления безопасностью программного обеспечения по ГОСТ Р ИСО/МЭК 27034-1. Он также допускает его использование для конкретизации или расширения компонентов доверия ГОСТ Р ИСО/МЭК 15408-3. В справочном приложении А представлены соответствующие взаимосвязи с требованиями доверия Common Criteria.
Значимы и связи с процессами жизненного цикла по 12207 и системой менеджмента информационной безопасности по 27001. Они помогают увидеть место безопасной разработки в более широкой деятельности организации. Безопасность не должна существовать как изолированный набор действий, не связанный с управлением продуктом, изменениями и ответственностью.
NIST SSDF удобен для современного сопоставления с ГОСТ, но не мог быть источником первой редакции 2016 года: первый публичный проект SSDF был объявлен NIST 11 июня 2019 года. SSDF 1.1 опубликован как NIST SP 800-218 в 2022 году. Эта последовательность устанавливает границу возможной причинной связи, однако сама по себе не доказывает ни мирового первенства ГОСТ, ни обратного заимствования.
Сравнивать подходы полезно на уровне конкретной задачи. Возьмём обучение: кто должен обладать компетенцией, для какого решения она нужна, как выявляют пробел и как проверяют результат подготовки? Затем аналогично можно сравнить анализ требований, работу с зависимостями и обработку уязвимостей. Такое сопоставление даёт практический результат и не требует заранее объявлять один документ уникальным или полностью эквивалентным другому.
### 6. От первой редакции к системе связанных документов
По воспоминаниям Вареницы, первоначальный замысел включал несколько взаимосвязанных документов: общие требования, типовые угрозы, рекомендации по реализации и подход к оценке. Конкретный состав предполагаемого комплекта менялся. Поэтому историю семейства стандартов следует рассматривать как развитие замысла, а не как исполнение неизменного первоначального плана.
Одним из связанных документов стал ГОСТ Р 58412-2019 о типовых угрозах безопасности информации при разработке программного обеспечения. Его назначение помогает понять важное различие: угрозы самому процессу и среде разработки не сводятся к уязвимостям готового приложения. Можно нарушить целостность исходного кода, повлиять на сборку или управление изменениями и получить небезопасный результат даже при внешне корректной организации испытаний.
При переходе к новой редакции 56939 нужно заново рассмотреть связи этих угроз с изменившейся структурой работ. Недостаточно механически заменить номера старых групп мер номерами новых процессов. Следует установить, какая угроза рассматривается, какие действия должны ей противодействовать и какие результаты подтверждают выполнение этих действий. Содержание ранее выполненной работы может сохраниться, но его место в общей системе необходимо объяснить.
С развитием технологий потребовалась более подробная поддержка отдельных направлений: анализа кода, тестирования, сборки, работы с компонентами. Общий стандарт не обязан содержать инструкцию по настройке каждого инструмента. Его дополняют специальные документы, методологии и практические руководства.
Редакция ГОСТ Р 56939-2024 утверждена 24 октября 2024 года приказом Росстандарта № 1504-ст и введена в действие 20 декабря 2024 года. Работа над обновлением велась раньше; Вареница вспоминает подготовленный к 2022 году проект и последующее расширение участия организаций. Эти воспоминания объясняют ход подготовки, но не заменяют официальные сведения об утверждении.
В окончательной редакции 2016 года раздел 5 содержит **девять групп мер**: анализ требований; проектирование архитектуры; конструирование и комплексирование; квалификационное тестирование; инсталляцию и приёмку; решение проблем при эксплуатации; управление документацией и конфигурацией; инфраструктуру среды разработки; людские ресурсы. В редакции 2024 года выделено **двадцать пять процессов**.
Здесь сравниваются разные единицы группировки. Нельзя считать увеличение числа заголовков непосредственным доказательством большей безопасности. Часть содержания разделена, часть конкретизирована, появились более явные акценты на отдельных направлениях. Компенсирующие меры, предусмотренные п. 4.5 редакции 2016 года, не являются ещё двумя группами оглавления: это возможность иным способом достигнуть целей и результатов базовых мер при невозможности их обычной реализации.
Для организации переход означает анализ содержания: что уже выполняется, что требуется уточнить, какие результаты нужно дополнить и где возникли новые обязанности. Работающие практики не следует отменять только потому, что изменились номера пунктов.
## Часть II. Применение ГОСТ и планирование безопасной разработки
**Совместный практический разбор: Андрей Карпов и Виталий Пиков.**
От устройства стандарта перейдём к работе команды: определению области применения, оценке текущего состояния, ресурсам, ответственности и планированию. В разборе методов проверки, ответственности, сопровождения и оценки соответствия также использованы объяснения Виталия Вареницы из общей дискуссии.
### 7. Мера и процесс: что делает работу устойчивой
Мера и процесс описывают разные стороны деятельности. Отдельное действие может снижать риск или поддерживать достижение результата. Процесс связывает действия во времени, определяет их взаимодействие, исполнителей и порядок управления. Замена слова в заголовке сама по себе такого порядка не создаёт.
Представим, что команда приобрела анализатор на три месяца, проверила код перед выпуском и закончила работу. Найденные проблемы удалось исправить, но через полгода код изменился, появилась новая зависимость, а несколько важных разработчиков перешли в другие проекты. Прежний отчёт сохраняет историческую ценность, однако не описывает состояние новой версии продукта.
Устойчивый процесс отвечает на следующий вопрос: что запускает повторную работу? Изменение кода, новый релиз, новая информация об уязвимости, изменение архитектуры или запланированный пересмотр могут требовать разных действий. Для каждого случая нужен понятный порядок, соответствующий рискам продукта.
Регулярность не равна частому автоматическому запуску. Если анализ выполняется в каждой сборке, но предупреждения не рассматриваются, ожидаемый эффект не достигается. Необходимо определить обработку результатов, ответственность за решение, сроки исправления и условия дальнейшего движения изменения.
При этом неверно представлять редакцию 2016 года набором исключительно разовых мероприятий. Её пп. 4.4 и 4.7–4.9 уже предусматривали реализацию мер, выделение ресурсов, внутренние проверки и улучшение процессов. Различия между редакциями нужно искать в конкретных формулировках и устройстве требований, а не в упрощённой формуле «раньше один раз, теперь постоянно».
Практический критерий устойчивости — возможность продолжить работу при обычных изменениях в продукте и команде. Если всё держится на памяти одного человека, полезная практика существует, но остаётся уязвимой организационно. Её поддерживают распределением обязанностей, понятными правилами и сохраняемыми результатами.
*Учебная модель поддерживаемого процесса: действия, решения и обратная связь остаются связанными.*
### 8. Как читать требования стандарта
Начинать работу со стандартом следует с области применения, терминов и общих положений. Переход прямо к интересующему инструменту может привести к ошибочному пониманию: отдельный пункт существует внутри общей системы правил, определяющей смысл требования и условия соответствия.
Особенно нагляден пример слова «следует». В ГОСТ Р 56939-2016 п. 4.2 оно использовано для выражения рекомендации среди других возможностей. В ГОСТ Р 56939-2024 п. 4.7 слова «должен» и «следует» выражают требования, которые должны быть выполнены. Привычное прочтение старой редакции нельзя автоматически переносить в новую.
Редакция 2024 года не устанавливает одну обязательную модель жизненного цикла для всех разработчиков. Безопасность необходимо включить в реально используемую организацию работы. У команды с короткими итерациями и у команды с крупными этапными поставками будут различаться календарь и способ исполнения, но содержание требуемых задач от этого не исчезает.
Описание процесса связывает его цели, требования к реализации и артефакты реализации. Цель помогает понять ожидаемый результат. Требования раскрывают необходимую работу. Артефакты дают возможность рассмотреть её исполнение. Полезно читать эти части вместе: документ, похожий на указанный артефакт, ещё не доказывает достижение цели.
Нужно также различать окончательную редакцию, проект, таблицу изменений и поясняющую презентацию. Проект может содержать полезную историческую информацию, которой нет в окончательном документе. Но формулировка из проекта не становится действующим требованием только потому, что удобнее изложена.
Наконец, стандарт, договор и правила оценки соответствия отвечают на разные вопросы. Чтобы определить обязательства конкретной организации, необходимо установить, какие документы к ней применимы и каким образом требуется подтвердить выполнение работ. Универсальный ответ на основании одного названия ГОСТ обычно недостаточен.
### 9. Проверки безопасности решают разные задачи
Ни один метод анализа не обнаруживает все виды проблем. Функциональные тесты помогают установить соответствие требуемому поведению. Статический анализ исследует код без его обычного выполнения. Фаззинг позволяет проверять поведение на множестве специально сформированных входных данных. Анализ архитектуры рассматривает решения и доверительные границы, которые могут не проявляться как локальный дефект в отдельной функции.
Тестирование на проникновение позволяет исследовать возможность достижения целей атакующего в заданных условиях. Его ценность состоит не только в обнаружении отдельных ошибок, но и в проверке того, как взаимодействуют компоненты и ограничения системы. Однако результат такой работы зависит от области, времени, доступной информации и выбранных сценариев.
Термины «нефункциональное тестирование» и «тестирование на проникновение» не следует считать универсальными синонимами. Они относятся к разным способам классификации работ. При применении конкретного стандарта нужно читать его определения и содержание соответствующего процесса, а не переносить привычное название без анализа.
Методы полезны в сочетании. Модель угроз помогает выбрать существенные сценарии; анализ архитектуры — оценить решения; проверки кода и выполняемой программы — обнаружить дефекты реализации; последующий анализ результатов — определить необходимые изменения. Инструмент занимает место внутри этой цепочки, а не заменяет её целиком.
Важно различать техническое наблюдение и окончательное заключение. Предупреждение анализатора, воспроизводимый сбой и подтверждённая уязвимость — разные состояния знания о проблеме. Их нельзя сводить к одной отметке «найден баг». Требуется анализ условий возникновения, последствий и связи с требованиями безопасности.
Выбор проверок должен объясняться задачами продукта. Недостаточно перечислить популярные сокращения в политике разработки. Команда должна понимать, что она хочет обнаружить, какую часть продукта проверяет и что сделает с результатом.
*Разные методы отвечают на разные вопросы о продукте; их результаты полезны в сочетании.*
### 10. Сторонний код и код, созданный с участием ИИ
После включения библиотеки в продукт её проблемы могут стать проблемами этого продукта. Внешнее происхождение компонента не освобождает разработчика от оценки его применения, отслеживания изменений и реакции на новые сведения об уязвимостях.
Поэтому open source нельзя оценивать как заведомо безопасный или заведомо опасный способ получения кода. Важно, как организация выбирает компонент, понимает его состав и назначение, контролирует версию и организует сопровождение. Собственноручно написанная библиотека тоже может содержать серьёзные недостатки.
Композиционный анализ помогает получить представление об используемых компонентах и известных связанных проблемах. Но обнаружение записи об уязвимости ещё не описывает полностью её влияние на конкретный продукт. Нужно установить версию, условия использования и доступность соответствующего поведения. Это повод для квалифицированного рассмотрения, а не основание автоматически проигнорировать предупреждение или объявить продукт скомпрометированным.
Особенно опасна неопределённость ответственности. Если обновление зависимости формально относится к разработчикам, сведения о проблемах получает отдел безопасности, а выпуском распоряжается другая команда, необходимо связать их действия. Иначе каждый участник может считать свою часть выполненной, а уязвимый компонент останется в поставке.
Тот же принцип распространяется на код, предложенный инструментом искусственного интеллекта. Способ получения фрагмента не заменяет проверку его смысла, корректности и безопасности. Команда принимает решение включить код в продукт и должна обеспечить необходимый анализ.
Это не исчерпывает специальные вопросы безопасности самих систем ИИ. Для них могут понадобиться дополнительные модели угроз и методы оценки. Но в обычной программной разработке базовое правило сохраняется: ответственность связана с принятым и поставленным продуктом, а не только с непосредственным авторством каждой строки.
### 11. Планирование: согласовать намерение с возможностями
Планирование безопасной разработки начинается с признания простой вещи: новые обязанности требуют ресурсов. Нельзя добавить анализ архитектуры, обработку результатов проверок и обучение, оставив прежнюю загрузку людей без каких-либо изменений и рассчитывая на устойчивое исполнение.
Затраты на физическую безопасность обычно легче представить. Если предприятие ограничивает доступ, ему нужны технические средства, правила и сотрудники. В программной разработке значительная часть затрат выражается во времени специалистов, поэтому её проще не заметить и заменить пожеланием «работайте внимательнее».
Первый процесс ГОСТ Р 56939-2024 помогает сделать потребность явной. Необходимо определить, что организация собирается выполнять, в каких границах и с какими ресурсами. План становится общим языком руководства, команды и заказчика: он связывает желаемое состояние с конкретными действиями.
Например, требование «внедрить композиционный анализ» слишком широко для исполнения. Нужны выбор продуктов и источников сведений о составе, определение места проверки, настройка обработки результатов, распределение ответственности и способ актуализации. Только после такого разложения можно обоснованно оценивать сроки и стоимость.
Планирование отвечает на четыре вопроса: **что делать, когда, за какие средства и кто будет этим заниматься**. Горизонт может быть разным — от ближайшей итерации до нескольких лет. Но даже долгосрочная программа должна иметь связь с ближайшими исполнимыми задачами.
Хороший план показывает не только намерения, но и зависимости. Если следующая практика требует определённой компетенции, её развитие нужно предусмотреть раньше или параллельно. Если результат зависит от подрядчика, необходимо согласовать взаимодействие. Если инструменту требуется доступ к инфраструктуре, эту работу нельзя оставить неявной.
### 12. Установить исходное состояние
Невозможно обоснованно спланировать улучшение, не понимая, что уже работает. Поэтому начальный этап включает инвентаризацию процессов и оценку готовности организации. Здесь важно избегать двух крайностей: считать всё отсутствующим или считать внедрённым всё, для чего нашлось знакомое название.
У команды уже могут существовать обучение, матрица компетенций, анализ кода, тестирование, управление изменениями и обработка обращений. Эти практики могли не называться безопасной разработкой. Их следует рассмотреть по содержанию: какие задачи они решают и насколько устойчиво выполняются.
Наличие статического анализатора — только начало обследования. Какой код проверяется? Какие правила включены? Когда выполняется запуск? Кто рассматривает результаты? Где фиксируется решение? Что происходит при обнаружении существенной проблемы? Ответы определяют состояние процесса точнее, чем отметка о приобретённой лицензии.
Полезно разделить результаты обследования на три группы:
- **Сохранить:** практика работает и решает нужную задачу в выбранной области.
- **Доработать:** основа существует, но есть пробелы в охвате, регулярности, ответственности или результатах.
- **Создать:** существенная работа отсутствует и требует организации с начала.
Такой подход предотвращает ненужное повторное внедрение и делает оценку ресурсов точнее. Расширение проверки на ещё один репозиторий отличается от создания новой инфраструктуры. Уточнение программы обучения отличается от подготовки людей, которые впервые будут заниматься соответствующей задачей.
Описание исходного состояния должно опираться на примеры исполнения. «Тестирование есть» — слишком широкое утверждение. Нужны границы, вид работы, исполнители и результаты. Если практика выполняется эпизодически или зависит от одного человека, это следует отразить честно: обнаруженная слабость — полезный результат обследования, а не повод улучшать формулировку отчёта.
### 13. Область применения и очередность внедрения
В крупной организации одновременно разрабатываются разные продукты, работают внутренние команды и подрядчики. Средств на одинаковое немедленное улучшение всей разработки может не быть. Планирование должно помочь определить очередность и объяснить её основания.
Приоритет нельзя выбирать только по удобству демонстрации. Нужно учитывать назначение продукта, его критичность, способы использования, зависимости, уже известные проблемы и применимые обязательства. Категоризация программного обеспечения делает эту логику понятной и воспроизводимой.
Хорошо выбранная начальная область позволяет проверить способ внедрения и затем расширить его. Но пилот имеет смысл только при понятном отношении к остальной программе. Нужно заранее определить, какие выводы будут использованы дальше, что требуется изменить перед распространением и кто отвечает за следующий этап.
Важно различать постепенное выполнение программы и заявление о полном соответствии. Организация может внедрить несколько практик и планировать остальные — это нормальное описание развития. Оно не равнозначно подтверждению всех требований применимого стандарта. При наличии договорных или регуляторных обязанностей границы и допустимый порядок реализации определяют с учётом этих обязанностей.
Иногда удобным первым техническим направлением становится композиционный анализ: состав продукта и известные проблемы компонентов дают конкретный предмет работы. В другом проекте более срочным может быть анализ архитектуры, управление доступом к исходному коду или исправление уже обнаруженного недостатка. Универсальная последовательность без знания продукта будет слишком грубой.
Обоснование области должно объяснять не только включённую часть, но и связь с остальным продуктом. Если проверяемый сервис полностью зависит от общей платформы сборки и библиотеки соседней команды, нельзя считать эти зависимости несущественными только потому, что они расположены в другом подразделении.
### 14. Как оценивать ресурсы и стоимость
Универсального процента удорожания безопасной разработки недостаточно для планирования. Стоимость зависит от исходного состояния, размера продукта, инфраструктуры, компетенций, требуемого охвата и способа подтверждения результатов. Одинаковый процент может скрывать совершенно разный объём работ.
Полезнее разделить затраты на запуск и регулярное исполнение. К запуску относятся первичное обследование, выбор подхода, настройка интеграций, подготовка правил и обучение. К регулярной работе — анализ результатов, исправления, сопровождение инфраструктуры, актуализация сведений и поддержание компетенций.
Бесплатное программное средство не означает бесплатного процесса. Его требуется установить, настроить, включить в разработку, обновлять и поддерживать. Платная лицензия, в свою очередь, не гарантирует, что у команды появилось время на обработку результатов. Инструментальная и человеческая части бюджета должны рассматриваться вместе.
Для каждой практики стоит определить исполнителей, ожидаемую загрузку, необходимые средства и внешние зависимости. Оценки на первом этапе могут быть приблизительными, но их основания должны быть видны. Если неизвестен объём предупреждений или трудоёмкость проверки, можно запланировать ограниченное обследование и уточнение оценки по его результатам.
Затраты также следует сопоставлять с целью улучшения. Организация может стремиться уменьшить вероятность определённых проблем, сократить время реакции или обеспечить обязательный порядок разработки. Не каждую пользу можно сразу выразить точной денежной суммой, но связь расхода с ожидаемым результатом должна быть объяснима.
Недостаток ресурсов требует управленческого решения: изменить сроки, область, способ реализации или выделение мощности команды в допустимых пределах. Он не должен незаметно превращаться в ситуацию, когда работа числится обязательной, но систематически не выполняется.
### 15. Люди, компетенции и распределение ответственности
Назначение одного ответственного за безопасную разработку не создаёт все необходимые компетенции. Анализ архитектуры, реализация, тестирование, сопровождение и управление изменениями требуют участия разных людей. Координатор помогает связать работу, но не заменяет каждого исполнителя.
Если в организации нет специалистов, способных оценить состояние и составить первый план, разумно подготовить инициативную группу или привлечь необходимую экспертизу. Такая группа должна помогать внедрению, а не становиться единственным местом, где вообще понимают безопасность продукта.
Обучение полезно связывать с решениями, которые человек принимает на работе. Разработчику, архитектору, руководителю проекта и специалисту по безопасности нужны разные глубина и содержание подготовки. Матрица компетенций становится рабочим инструментом тогда, когда показывает требуемые способности и конкретные пробелы.
Security champions могут помогать распространять знания внутри команд, обсуждать типовые проблемы и поддерживать взаимодействие со специалистами по безопасности. Но роль должна сопровождаться временем, понятными ожиданиями и доступом к помощи. Само присвоение названия не создаёт организационную возможность.
Сопротивление изменениям часто связано не только с убеждениями людей, но и с неясной нагрузкой. Если специалисту поручили новые проверки, а сроки функциональных задач остались прежними, возникает скрытый конфликт приоритетов. Его следует решать планированием и распределением обязанностей, а не предполагать, что дополнительная работа выполнится за счёт личного энтузиазма.
Обучение и планирование развиваются совместно. Для начального плана уже требуется некоторое понимание; затем план включает развитие компетенций для следующих этапов. Практический путь — сформировать достаточное ядро, выполнить первые действия и последовательно расширять возможности команды.
### 16. Какие результаты должны остаться после планирования
После планирования должен появиться связанный набор результатов, позволяющий приступить к работе и впоследствии проверить исполнение. Его ценность определяется содержанием и связями, а не количеством отдельных файлов.
Для разбора первого процесса ГОСТ Р 56939-2024 удобно выделить пять записей:
| Результат | На какой вопрос отвечает |
|---|---|
| Исходное состояние процессов | Что уже выполняется и какие пробелы обнаружены? |
| Обоснование области применения | Какие продукты и работы включены и почему? |
| Анализ потребности в ресурсах | Какие люди, время и средства нужны для исполнения? |
| План развития процессов | Какие возможности предстоит создать или улучшить и в какой очередности? |
| План реализации процессов | Как организовано выполнение запланированных работ? |
Пробел в исходном состоянии должен приводить к объяснимому улучшению. Улучшение — к ресурсам. Работа — к исполнителю, сроку и проверяемому результату. Иначе обследование, бюджет и календарный план могут существовать отдельно и описывать разные намерения.
Организационная документация может включать политику безопасной разработки, правила категоризации продуктов, регламент и порядок контроля. Это возможные формы реализации. Названия документов сами по себе не являются универсальным рецептом для любой команды.
Политика задаёт общие правила и ответственность. Регламент объясняет порядок действий. Рабочие записи показывают исполнение в конкретном проекте. Один уровень не заменяет остальные: общий документ не доказывает выполнение каждой задачи, а разрозненные заявки не всегда объясняют установленный порядок.
Необходимо предусмотреть пересмотр. Продукт, команда и доступные сведения меняются. Поэтому вопрос «кто и при каких условиях обновляет план?» столь же важен, как первоначальное утверждение. Неактуальный план может создавать ложную уверенность именно потому, что выглядит завершённым документом.
*Пять связанных результатов планирования по процессу 5.1 ГОСТ Р 56939-2024.*
### 17. Автоматизация работы и свидетельств
Выполнение требований не обязывает создавать сотни независимых текстовых документов и таблиц. Значительная часть сведений уже возникает в репозиториях, системах задач, результатах сборки и проверки. Разумная автоматизация помогает сохранить связи и уменьшить повторный ручной ввод.
Например, задача исправления может ссылаться на выявленную проблему, изменение кода, результат повторной проверки и решение ответственного. Если эти сведения доступны и управляемы, отчёт может формироваться на их основе. Это полезнее, чем отдельно переписывать историю изменения в документ, который быстро отстаёт от реальной работы.
Средства управления внедрением позволяют видеть состояние практик, распределять задачи и собирать свидетельства. Но процент заполненных карточек не следует автоматически принимать за процент безопасности. Любая отметка должна иметь понятный критерий и содержательное основание.
Автоматизация особенно важна для регулярных действий. При этом она требует сопровождения: изменение сборки, структуры репозитория или формата отчёта может нарушить прежнюю связь. За инструментами и интеграциями также должны стоять владельцы и правила проверки их работы.
Выбирать систему стоит после определения необходимых действий и записей. Иначе организация рискует подстроить процесс под удобные поля приобретённого продукта и потерять существенные вопросы, для которых в нём не нашлось готового шаблона.
Тот же способ рассуждения помогает при чтении сложных документов по управлению конфигурацией и другим обеспечивающим процессам. Начните с вопросов: какие объекты требуется учитывать, кто вправе их изменять, как воспроизводится состояние и где остаётся история решений? Затем сопоставьте полученный порядок с требованиями документа. Сложность стандарта становится более понятной, когда его положения связаны с конкретными объектами и действиями команды.
### 18. Сопровождение и работа с выявленными недостатками
Безопасная разработка продолжается после выпуска. Даже тщательно проверенная версия меняется в своём контексте: появляются новые сведения о компонентах, способы атак и требования к эксплуатации. Организация должна уметь получать эту информацию и превращать её в действия.
Базовая цепочка включает получение сообщения, регистрацию, анализ, определение необходимых изменений, проверку исправления и поставку результата. В зависимости от продукта и обязательств может потребоваться информирование заказчиков, пользователей и других сторон. Конкретный порядок задаётся применимыми требованиями и принятой организацией работы.
Здесь особенно заметна разница между наличием контактного адреса и работающим процессом. Пользователь может отправить сообщение, но важно, кто его получит, как будет определена значимость и что произойдёт дальше. Обращение не должно теряться между поддержкой, разработкой и специалистами по безопасности.
Сопровождение связано с управлением версиями и изменениями. Нужно понимать, какие поставки затронуты проблемой, для каких поддерживаемых ветвей требуется исправление и как убедиться, что изменение дошло до нужных получателей. Без учёта состава и конфигурации продукта такая работа становится ненадёжной.
Обработка обычных дефектов и уязвимостей может использовать общую инфраструктуру, но должна учитывать различия в последствиях, срочности и обращении с информацией. Важно не только зарегистрировать проблему, но и принять обоснованное решение о ней.
Окончание поддержки также требует ясности. Пользователь должен понимать границы обязательств поставщика, а организация — учитывать условия своих договоров и систем оценки соответствия. Судьба конкретного сертификата или обязательства после прекращения поддержки определяется соответствующими документами, а не общей формулой для всех продуктов.
*Учебная схема работы с недостатком на протяжении сопровождения продукта.*
### 19. Соответствие, сертификация процессов и сертификация продукта
Полезно различать несколько вопросов. Выполняет ли команда определённые инженерные практики? Соответствуют ли они требованиям выбранного стандарта? Нужна ли отдельная сертификация процессов? Как оценивается сам продукт? Какие требования предъявляются к применяемым инструментам? Эти вопросы связаны, но ответы на них не совпадают автоматически.
Если заказчик требует соблюдения ГОСТ, необходимо установить содержание требования: редакцию документа, область применения, объект и способ подтверждения. Упоминание стандарта само по себе не объясняет все условия оценки. Дополнительные обязанности могут следовать из договора или применимого регулирования.
Государственные информационные системы (ГИС) и объекты критической информационной инфраструктуры (КИИ) нельзя автоматически подводить под один набор требований. Перед применением документа определяют вид системы, роль организации и область действия документа. Сходство инженерных задач безопасной разработки само по себе не устанавливает применимость конкретного требования.
Соответствие стандарту не следует без дальнейшего анализа отождествлять с наличием отдельного сертификата процессов. Однако столь же неверно утверждать, что сертификат никогда не требуется. В каждом случае нужно понимать конкретный режим и установленные правила подтверждения.
Сертификация продукта и оценка процесса могут влиять друг на друга, в том числе при организации последующих изменений. Но возможность обновления конкретного сертифицированного продукта зависит от применимых условий. Общий рассказ о преимуществах сертификации не является достаточным основанием для выбора процедуры изменения.
Отдельный предмет — инструменты разработки и проверки. Пригодность анализатора для определённых задач, выполнение специальных требований к нему и зрелость процессов организации — разные объекты оценки. Наличие подходящего инструмента не доказывает правильности его применения и полноты всей программы безопасной разработки.
Для бизнеса важно также планировать внешнюю оценку: компетенции исполнителей, необходимые материалы, сроки и взаимодействие. Но сведения о реестрах, аккредитациях и очередях меняются. Их следует проверять при принятии конкретного решения, а не использовать прежнюю ситуацию как неизменное свойство рынка.
Практический принцип — ясно формулировать заявление о достигнутом состоянии. «Используем отдельные практики», «внедрили процессы в такой-то области» и «подтвердили соответствие в установленном порядке» означают разное. Точность формулировки помогает и команде, и заказчику понимать реальные основания доверия.
### 20. Небольшая команда: соразмерность и обязательства
Переносить организационную конструкцию крупной компании в команду из трёх человек буквально обычно неразумно. Выделенные подразделения, сложная инфраструктура и большое количество независимых документов могут потребовать больше ресурсов, чем сама разработка. Но из этого не следует, что небольшому продукту не нужна безопасность.
Число сотрудников не определяет автоматически ни критичность продукта, ни применимые обязанности. Небольшая команда может создавать программное обеспечение с существенными функциями безопасности или работать в условиях строгих договорных требований. Тогда ограничения ресурсов необходимо учитывать при организации исполнения, а не объявлять освобождением от работы.
Соразмерность означает выбор понятной реализации. Один человек может совмещать несколько ролей; существующая система задач может хранить разные типы свидетельств; часть экспертизы можно получать извне. При этом нужно учитывать ограничения совмещения, доступность времени и необходимость независимости там, где она требуется.
Если небольшая команда работает внутри крупной организации, общие службы могут предоставлять инфраструктуру, анализ и обучение. Но это должно быть согласовано. Наличие отдела безопасности в организационной структуре ещё не означает, что его ресурсы зарезервированы для конкретного проекта.
Для малого проекта особенно полезны ограниченная ясная область, приоритеты и регулярность. Несколько устойчиво выполняемых действий могут стать основой дальнейшего развития. Однако описывать состояние нужно честно: частичное внедрение полезных практик не следует выдавать за полное выполнение требований, которые фактически не обеспечены.
### 21. Как учиться безопасной разработке
Безопасная разработка объединяет несколько самостоятельных дисциплин. Архитектурный анализ, тестирование, управление зависимостями, организация процессов и обработка уязвимостей требуют разных знаний и практического опыта. Поэтому поиск одной книги, которая полностью заменит подготовку по всем направлениям, редко приводит к нужному результату.
Эффективнее строить обучение вокруг рабочих задач. Стандарт помогает определить требования. Методология показывает способ организации. Техническое руководство объясняет метод. Практическое упражнение позволяет проверить, способен ли человек применить знание к своему продукту.
Например, после знакомства с моделированием угроз полезно получить не только ответы на тест, но и небольшую модель конкретного компонента с объяснением границ и предположений. После обучения анализатору — разобранные результаты и понимание дальнейших действий. После изучения планирования — обоснованный план улучшения с ресурсами и ответственностью.
Обучение должно продолжаться вместе с изменением обязанностей. Новый язык, технология, архитектурный подход или роль могут создать новый пробел в компетенциях. Поэтому матрица подготовки и учебные материалы нуждаются в актуализации так же, как технические правила разработки.
Полезна небольшая объяснённая библиотека источников. Для каждого материала стоит указывать, какой вопрос он помогает решить и к какой версии относится. Это делает подборку пригодной для повседневной работы и уменьшает риск применения устаревшего совета к новой ситуации.
Документ об обучении подтверждает определённый образовательный результат. Его не следует смешивать с сертификатом продукта или процессов разработки. Для организации важнее всего связь между подготовкой человека и качеством решений, которые он способен принимать после обучения.
## Учебный практикум
Практическая работа объединяет результаты обеих частей и предназначена для самостоятельного выполнения.
### 22. Практическая работа: первый план для одного продукта
Рассмотрим учебный пример. Команда разрабатывает сервис обработки файлов. Исходный код хранится в системе управления версиями, сборка автоматизирована, есть функциональные тесты. Зависимости обновляются нерегулярно, предупреждения анализатора рассматриваются без общего порядка, а сообщения о проблемах поступают через обычную поддержку.
Начинать следует с описания реального состояния. Автоматизированная сборка — существующая возможность, которую можно использовать. Отсутствие общего порядка обработки предупреждений — пробел процесса. Нерегулярная актуализация зависимостей — ещё одна задача. При этом пока недостаточно сведений, чтобы объявить какую-либо из этих тем полностью внедрённой или полностью отсутствующей.
Затем команда определяет область первого улучшения. Например, один поддерживаемый сервис и его состав, включая используемые компоненты и сборку. Выбор нужно объяснить назначением продукта, выявленными проблемами и доступными ресурсами. Следует указать связанные элементы за пределами команды и необходимое взаимодействие с их владельцами.
Далее формируется небольшая программа работ:
| Шаг | Содержание | Проверяемый результат |
|---|---|---|
| Установить состав | Определить используемые компоненты и источники сведений о них | Проверяемая запись о составе выбранной версии |
| Определить обработку результатов | Согласовать участников, порядок рассмотрения и фиксации решений | Описанный порядок и пример его исполнения |
| Включить проверку в разработку | Определить условия запуска и связать результаты с задачами | Проверка реального изменения с сохранёнными результатами |
| Подготовить участников | Обучить людей необходимым решениям и действиям | Разобранные примеры, подтверждающие понимание работы |
| Пересмотреть план | Оценить трудоёмкость, ограничения и следующий этап | Обновлённое решение о развитии и ресурсах |
Это учебная последовательность, а не универсальный порядок для любого проекта. В другой команде исходное состояние и приоритеты будут иными. Существенна связь между выявленной проблемой, выбранной работой и доказательством её результата.
После подготовки плана полезно проверить его на обычном рабочем событии: завтра нужно выпустить изменение, а проверка обнаружила существенную проблему. Кто её рассматривает? Где фиксируется решение? Кто обеспечивает исправление? Как проверяется результат? Каковы полномочия участников? Если ответы приходится придумывать заново, плану не хватает связи с исполнением.
Для самостоятельной работы выберите один продукт или компонент. Опишите его исходное состояние, обоснуйте область применения, оцените необходимые ресурсы и определите ближайшее улучшение. Свяжите каждую работу с ответственным, сроком и ожидаемым результатом. Затем предложите событие, при котором план потребуется пересмотреть.
*Практическая работа: проследите связь от выявленного пробела до результата исполнения.*
## Вопросы и ответы
Здесь собраны вопросы общей дискуссии и пояснения, полезные при применении материала к своему продукту.
### Чем полезен ГОСТ, если сертификация не планируется?
Он даёт общую рамку для оценки и развития разработки. Можно сопоставить свои практики с задачами стандарта, обнаружить пробелы и выбрать улучшения. При этом необходимо точно описывать, какие требования приняты и что фактически реализовано, не заявляя автоматически полного соответствия.
### Девять групп мер и двадцать пять процессов — это показатель прогресса?
Это прежде всего различие структуры. Для оценки изменений нужно сопоставлять содержание, детализацию, обязанности и результаты. Количество заголовков не измеряет безопасность и не показывает напрямую объём дополнительной работы.
### Почему нельзя читать «следует» одинаково в обеих редакциях?
Потому что стандарты сами определяют смысл этой формулировки. В п. 4.2 редакции 2016 года она обозначает рекомендацию; в п. 4.7 редакции 2024 года — требование, которое должно быть выполнено. Значение нужно устанавливать по применимому документу.
### Можно ли ограничиться одним анализатором?
Один инструмент покрывает определённый круг задач и имеет ограничения. Требования, архитектура, используемые компоненты, поведение системы и сопровождение требуют разных видов работы. Кроме того, результаты анализа должны быть включены в процесс принятия решений.
### С чего начать, если процессы безопасности не организованы?
С людей, способных понять задачу, и с обследования исходного состояния. Затем нужно определить область, приоритетные пробелы, ресурсы и ближайшие действия. Даже в такой ситуации у организации обычно уже есть полезные практики, которые можно сохранить и развить.
### Должны ли сначала пройти обучение все сотрудники?
Не обязательно одновременно и по одинаковой программе. Для начала нужны компетенции, позволяющие организовать обследование и планирование. Последующее обучение распределяют по ролям и задачам, связывая его с этапами внедрения.
### Кто отвечает за безопасную разработку?
Обязанности распределяются между участниками жизненного цикла. Координатор связывает работу, но архитектор, разработчик, тестировщик и руководитель сохраняют ответственность за свои решения. Обязанности должны сопровождаться ресурсами и полномочиями.
### Какой процент бюджета нужно добавить?
Универсальная цифра не заменяет расчёт. Нужно учитывать исходное состояние, разовые работы, регулярное исполнение, нагрузку людей и сопровождение средств. Первые оценки можно уточнять на ограниченной области по результатам практического выполнения.
### Можно ли внедрять процессы постепенно?
Развитие можно планировать по этапам, но при этом нужно учитывать применимые обязательства. Частичное внедрение следует описывать как частичное. Оно не становится полным соответствием только благодаря наличию дорожной карты.
### Требует ли ГОСТ множества отдельных файлов?
Существенны содержание, управляемость и проверяемость результатов. Рабочие системы могут поддерживать необходимые сведения и связи. Однако автоматизация не отменяет требований к самим действиям и достаточности свидетельств.
### Чем open source отличается с точки зрения ответственности?
Внешнее происхождение требует учитывать особенности получения и сопровождения компонента, но не снимает ответственности за его использование в продукте. Нужно знать состав, отслеживать проблемы и организовывать необходимые действия.
### Нужно ли проверять код, предложенный ИИ?
Да. Команда принимает решение о включении кода и должна обеспечить его проверку. Способ получения фрагмента не гарантирует ни корректности, ни безопасности и не заменяет инженерную ответственность.
### Нужен ли отдельный сертификат, если заказчик требует ГОСТ?
Это определяется содержанием требования, договором и применимыми правилами оценки. Выполнение стандарта и получение отдельного сертификата — разные вопросы, которые нужно явно согласовать. Название документа само по себе не даёт полного ответа.
### Обязательно ли сертифицировать каждый применяемый инструмент?
Требования к инструментам определяются конкретным контекстом. Нельзя автоматически переносить условия оценки продукта на любое средство разработки. Пригодность инструмента, соблюдение специальных требований к нему и корректность его применения следует рассматривать отдельно.
### Что меняется для небольшой команды?
Меняется способ организации: роли могут совмещаться, инфраструктура — предоставляться централизованно, экспертиза — привлекаться извне. Но критичность продукта и применимые обязанности не исчезают из-за небольшого числа сотрудников.
### Как понять, что внедрение начало работать?
Рассмотреть реальные изменения и проблемы продукта. Выполняются ли предусмотренные действия? Понятны ли решения и ответственность? Сохраняются ли результаты? Использует ли команда полученные сведения для исправлений и улучшения порядка работы? Такой разбор содержательнее одной отметки «процесс внедрён».
## Источники для дальнейшего изучения
1. **ГОСТ Р 56939-2016.** Защита информации. Разработка безопасного программного обеспечения. Общие требования. Для исторического сравнения особенно полезны разделы 1, 4, 5 и приложение А. [Официальные сведения Росстандарта](https://protect.gost.ru/gost/details/286a588e-4a6a-4899-88f7-3c370dea1e1d).
2. **ГОСТ Р 56939-2024.** Защита информации. Разработка безопасного программного обеспечения. Общие требования. Общие положения определяют правила применения; п. 5.1 посвящён планированию. [Официальные сведения Росстандарта](https://protect.gost.ru/gost/details/f3818925-a96f-4f55-96e9-46b44720ee64).
3. **ГОСТ Р 58412-2019.** Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.
4. **Виталий Вареница.** «История создания и актуальное состояние РБПО в России. ГОСТ Р 56939-2016/24». Исторический доклад НПО «Эшелон», представленный 2 июля 2025 года.
5. **Arina Kudriavtseva, Olga Gadyatskaya.** *Secure Software Development Methodologies: A Multivocal Literature Review*. Препринт arXiv:2211.16987v2, 4 июля 2023 года. Полезен для сопоставления назначения и содержания разных подходов. [Версия v2](https://arxiv.org/html/2211.16987v2).
6. **NIST SP 800-218.** *Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities*, 2022. [Окончательная публикация](https://csrc.nist.gov/pubs/sp/800/218/final). Для исторической шкалы: [объявление первого публичного проекта SSDF, 11 июня 2019 года](https://csrc.nist.gov/News/2019/draft-white-paper-on-ssdf).
7. **Microsoft Security Development Lifecycle.** История и назначение SDL. [Официальное описание](https://www.microsoft.com/en-us/securityengineering/sdl/about).
8. **OWASP SAMM.** Модель развития организационной зрелости безопасной разработки. [Материалы проекта](https://owaspsamm.org/).
*Основа материала — вебинар МАСКОМ и PVS-Studio от 2 июля 2025 года, проведённый Виталием Пиковым и Андреем Карповым, и исторический доклад Виталия Вареницы. Исторические сведения об участниках и этапах подготовки проекта атрибутированы докладчику; сведения об утверждённых редакциях приведены по соответствующим стандартам. Практическая работа в разделе 22 — учебный пример.*
SHA-256: 4af023268a557bb802d7252ad1cefb81971da57a6294f28b9347ef12f33bd137
02EP01 — Обложка и визуальный язык серииEP01-cover-design.md
EP01 — Обложка и визуальный язык серии
Дата создания: 2026-09-06. Результат: assets/ep01-cover.png. Генерация выполнена встроенным image_gen.imagegen по двум фотографиям пользователя. Фотографии просмотрены перед использованием; пользователь явно разрешил их использовать для титульного слайда.
Постоянные элементы будущих выпусков
- Светлый фон
#F7F8FA, глубокий тёмно-синий#17212B, кобальт#2356A8, сдержанный cyan. - Портрет автора справа, около 38% композиции. Слева крупный короткий английский заголовок.
- Серия сверху:
SECURE SOFTWARE DEVELOPMENT IN PRACTICE. - Идентификатор
EPnn / 25, авторVITALIY PIKOV, сайтpikov.art, обозначениеGOST R 56939-2024. - Тонкие связи и узлы инженерного процесса. Светлая, профессиональная, предметная подача.
- Поля безопасности около 7%; текст не накладывать на лицо. Для веб-презентации показывать изображение целиком без кадрирования.
- Менять тему, подзаголовок и номер; сохранять расположение и палитру. В будущих обложках использовать эту обложку как стилевой референс и исходные фото для узнаваемости лица.
Источники изображения
Основная фотография: V:\tmp\codex\2026 Photo\_IMG_5478.jpg.
Дополнительная фотография для лица: V:\tmp\codex\2026 Photo\_IMG_5476.jpg.
Исходный результат генератора: C:\Users\user\.codex\generated_images\01a075f0-767f-7293-af82-d96d7162776a\exec-4a59ec6b-acc7-45c9-b078-4bfe308cbf3c.png. В комплект скопирована финальная PNG, поэтому он не зависит от кэша генератора. Оригиналы фотографий не изменялись.
Изображение — сгенерированная композиция, а не неизменённая студийная фотография. Визуально проверены узнаваемость, основные надписи, отсутствие исходных вывесок и значков. Короткие декоративные подписи процесса появились в результате генерации и не являются обязательной структурой ГОСТ. Текст встроен в PNG; для следующего выпуска менять его новой генерацией, а обычный текст веб-слайдов редактировать в Markdown.
Точный запрос генерации
Create one polished 16:9 landscape title-slide / YouTube cover image for an English educational webinar series by the man in the two reference photographs. Both images show the same person; first is the primary identity reference, second supports face fidelity. Preserve his recognizable exact facial features, short greying hair, age, natural skin texture, calm confident expression, navy suit, white shirt and blue patterned neck scarf. Do not beautify him into a different person, change age or add glasses. Remove the original room, company signage and lapel badge/logo. Composition: waist-up portrait of this man occupying the RIGHT 38 percent, facing near camera, softly lit with natural editorial portrait quality; LEFT 58 percent is a clear typographic field, generous breathing space. A distinctive bright engineering editorial visual identity: ice-white #F7F8FA background, deep navy #17212B text, strong cobalt #2356A8 accents and restrained cyan; subtle precise technical diagram lines and a sequence of small process nodes integrated behind the portrait, conveying secure software development, evidence and repeatable engineering. Keep abstract geometry subtle and purposeful, not a busy circuit-board wallpaper. No hooded hackers, padlocks, shields, national flags, government emblems, vendor logos or fake certification seals. Large crisp impeccably spelled English typography, exact text only: upper small series line 'SECURE SOFTWARE DEVELOPMENT IN PRACTICE'; primary large multiline title 'WHERE SECURE\nDEVELOPMENT BEGINS'; subordinate small line 'History, GOST and a working process'; small episode identifier 'EP01 / 25'; bottom author 'VITALIY PIKOV'; bottom website 'pikov.art'; compact standard reference 'GOST R 56939-2024'. Harmonious contemporary geometric sans-serif typography. All text comfortably inside 7 percent safe margins, no text over the face. This should look like a coherent premium educational series cover, bright, credible, memorable, not a generic advertising poster. Final flat artwork, not a photo of a screen, no device mockup. Wide 16:9 high-resolution composition.
Параметры: referenced_image_paths — два пути выше в указанном порядке; число последних изображений не использовалось. Одна генерация, без последующего программного редактирования картинки.
Исходный Markdown целиком
# EP01 — Обложка и визуальный язык серии
Дата создания: 2026-09-06. Результат: [assets/ep01-cover.png](assets/ep01-cover.png). Генерация выполнена встроенным `image_gen.imagegen` по двум фотографиям пользователя. Фотографии просмотрены перед использованием; пользователь явно разрешил их использовать для титульного слайда.
## Постоянные элементы будущих выпусков
- Светлый фон `#F7F8FA`, глубокий тёмно-синий `#17212B`, кобальт `#2356A8`, сдержанный cyan.
- Портрет автора справа, около 38% композиции. Слева крупный короткий английский заголовок.
- Серия сверху: `SECURE SOFTWARE DEVELOPMENT IN PRACTICE`.
- Идентификатор `EPnn / 25`, автор `VITALIY PIKOV`, сайт `pikov.art`, обозначение `GOST R 56939-2024`.
- Тонкие связи и узлы инженерного процесса. Светлая, профессиональная, предметная подача.
- Поля безопасности около 7%; текст не накладывать на лицо. Для веб-презентации показывать изображение целиком без кадрирования.
- Менять тему, подзаголовок и номер; сохранять расположение и палитру. В будущих обложках использовать эту обложку как стилевой референс и исходные фото для узнаваемости лица.
## Источники изображения
Основная фотография: `V:\tmp\codex\2026 Photo\_IMG_5478.jpg`.
Дополнительная фотография для лица: `V:\tmp\codex\2026 Photo\_IMG_5476.jpg`.
Исходный результат генератора: `C:\Users\user\.codex\generated_images\01a075f0-767f-7293-af82-d96d7162776a\exec-4a59ec6b-acc7-45c9-b078-4bfe308cbf3c.png`. В комплект скопирована финальная PNG, поэтому он не зависит от кэша генератора. Оригиналы фотографий не изменялись.
Изображение — сгенерированная композиция, а не неизменённая студийная фотография. Визуально проверены узнаваемость, основные надписи, отсутствие исходных вывесок и значков. Короткие декоративные подписи процесса появились в результате генерации и не являются обязательной структурой ГОСТ. Текст встроен в PNG; для следующего выпуска менять его новой генерацией, а обычный текст веб-слайдов редактировать в Markdown.
## Точный запрос генерации
```text
Create one polished 16:9 landscape title-slide / YouTube cover image for an English educational webinar series by the man in the two reference photographs. Both images show the same person; first is the primary identity reference, second supports face fidelity. Preserve his recognizable exact facial features, short greying hair, age, natural skin texture, calm confident expression, navy suit, white shirt and blue patterned neck scarf. Do not beautify him into a different person, change age or add glasses. Remove the original room, company signage and lapel badge/logo. Composition: waist-up portrait of this man occupying the RIGHT 38 percent, facing near camera, softly lit with natural editorial portrait quality; LEFT 58 percent is a clear typographic field, generous breathing space. A distinctive bright engineering editorial visual identity: ice-white #F7F8FA background, deep navy #17212B text, strong cobalt #2356A8 accents and restrained cyan; subtle precise technical diagram lines and a sequence of small process nodes integrated behind the portrait, conveying secure software development, evidence and repeatable engineering. Keep abstract geometry subtle and purposeful, not a busy circuit-board wallpaper. No hooded hackers, padlocks, shields, national flags, government emblems, vendor logos or fake certification seals. Large crisp impeccably spelled English typography, exact text only: upper small series line 'SECURE SOFTWARE DEVELOPMENT IN PRACTICE'; primary large multiline title 'WHERE SECURE\nDEVELOPMENT BEGINS'; subordinate small line 'History, GOST and a working process'; small episode identifier 'EP01 / 25'; bottom author 'VITALIY PIKOV'; bottom website 'pikov.art'; compact standard reference 'GOST R 56939-2024'. Harmonious contemporary geometric sans-serif typography. All text comfortably inside 7 percent safe margins, no text over the face. This should look like a coherent premium educational series cover, bright, credible, memorable, not a generic advertising poster. Final flat artwork, not a photo of a screen, no device mockup. Wide 16:9 high-resolution composition.
```
Параметры: `referenced_image_paths` — два пути выше в указанном порядке; число последних изображений не использовалось. Одна генерация, без последующего программного редактирования картинки.
SHA-256: ad559b87e8813a4c42a73061adec49d320a926c7542cb3f6ff7fcf072112bb9a
03EP01 — История SDL и создания ГОСТ: PDF, полный транскрипт и проверка редакции 2016EP01-history-research.md
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.
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 в метаданных не подменяет автора на титуле.
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»: имена говорящих определяются по представлению и передаче слова, автоматическая диаризация не подтверждена. Это расшифровка устного источника с ошибками распознавания, не официальный протокол разработки стандарта.
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 дополнительно просмотрены визуально. Это рабочая архивная копия; даты и организация-разработчик сверены с официальной карточкой Росстандарта.
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. Выпуск SAMM v2 подтверждён объявлением 31.01.2020. OWASP SAMM release. SSDF 1.1 опубликован как NIST SP 800-218 в 2022 году; это версия, выбранная в серии. NIST 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, записи 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 года, дата SSDF v1.1 — карточкой NIST от 3 февраля 2022 года, внедрение SDL с 2004 года — историей Microsoft SDL. Шкала представляет авторскую перерисовку по 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-ст | Официальная карточка Росстандарта; заменяет ошибочное «май 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 |
Карточка и предисловие редакции 2016 называют ЗАО «НПО «Эшелон» разработчиком, ТК 362 «Защита информации» — вносящим комитетом. TRANS 00:19:00–00:20:19 добавляет воспоминание: небольшая группа в «Эшелоне» готовила текст, другие организации преимущественно обсуждали его и давали замечания. Такое разделение ролей объясняет, как один указанный разработчик сочетается с широким обсуждением. Полный список 22 рецензировавших организаций и протоколы здесь не проверены.
В предисловии и официальной карточке 2024 перечислены десять организаций: ФСТЭК России, АО «Лаборатория Касперского», ИСП РАН, АО «ИнфоТеКС», АО «Позитив Текнолоджиз», ООО «РусБИТех-Астра», АО «СберТех», ООО НТЦ «Фобос-НТ», ООО «ЦБИ», АО НПО «Эшелон». Вносит стандарт также ТК 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. Текст доклада ценен для истории, но не заменяет стандарт.
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 |
| Финальный white paper, SSDF 1.0 | 23.04.2020 | NIST: опубликован SSDF, полный white paper |
| Финальный NIST SP 800-218, SSDF 1.1 | 03.02.2022 | NIST SP 800-218 |
| Initial public draft SSDF 1.2 | 17.12.2025; на дату проверки отмечен Draft | Реестр NIST SSDF |
У новости 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 специально регулирует предъявление требований в ТЗ НИР/ОКР. Эти положения не означают автоматическую обязанность каждого разработчика сертифицировать любой продукт.
Показателен временной разрыв: официальный реестр правовых актов ФСТЭК содержит приказ от 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-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, вопросы и библиография выделены отдельно.
Это тематическая учебная структура: она сохраняет границы основных выступлений, но не воспроизводит разговор по минутам. Вопросы применения обсуждались и с гостем, и позднее ведущими; их не приписываем одному человеку. Учебная систематизация методологий, уточнения по окончательным стандартам и практикум не выдаются за дословную речь конкретного докладчика. Подробная карта и временные метки остаются в этом исследовательском документе; в самостоятельной лекции — крупные части, подписи и удобное оглавление.
Исходный Markdown целиком
# 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, вопросы и библиография выделены отдельно.
Это тематическая учебная структура: она сохраняет границы основных выступлений, но не воспроизводит разговор по минутам. Вопросы применения обсуждались и с гостем, и позднее ведущими; их не приписываем одному человеку. Учебная систематизация методологий, уточнения по окончательным стандартам и практикум не выдаются за дословную речь конкретного докладчика. Подробная карта и временные метки остаются в этом исследовательском документе; в самостоятельной лекции — крупные части, подписи и удобное оглавление.
SHA-256: 431f498a0226dc395f158a2027989b5bfcb2d67f25d66db4a57529577b309f6b
04EP01 — План первого вебинараEP01-plan.md
EP01 — План первого вебинара
Дата: 2026-09-06. Формат: предварительная запись с монтажом, основной голос — автор. На EP01 гость не нужен: знакомство, постановка исследовательского вопроса и единая логика рассказа требуют цельного авторского выступления. Это редакционное решение для проекта, а не ограничение будущих выпусков.
Обещание зрителю
Примерно за 42 минуты понять, зачем исследовать 25 процессов российского стандарта, проследить создание редакции 2016 года и научиться составлять связанный план первой инициативы по безопасной разработке.
Выпуск содержит 29 слайдов. Самостоятельная русская лекция и её HTML-версия охватывают историю стандартов, организацию процессов и практику внедрения; они предназначены для чтения и передачи слушателям и партнёрам. Английский EP01 сохраняет свой фокус: введение, история стандарта и планирование. Сведения об исходном вебинаре приведены в примечании к учебной лекции; рабочая карта источников хранится в исследовательских документах.
Основная аудитория: практики AppSec/SSDLC, разработчики и технические руководители. Опыт программирования полезен, знание российских стандартов не требуется. Аудиторам пригодятся подробные ссылки и границы сопоставления в приложениях.
К концу выпуска зритель сможет:
- Различить национальный стандарт, framework практик и модель зрелости.
- Объяснить, почему история безопасной разработки включает архитектурные принципы и организацию работы.
- Назвать пять требований процесса 5.1 и соответствующие категории свидетельств.
- Отличить план развития процессов от плана их реализации.
- Заполнить небольшой рабочий лист: область, состояние, ресурсы, развитие, реализация.
- Разделить ранние обсуждения, начало НИР, проекты, утверждение и введение стандарта в действие.
- Проверять модальность и структуру по конкретной редакции, включая изменение значения «следует» между 2016 и 2024 годами.
Драматургия и хронометраж
| Интервал | Слайды | Содержание | Зачем |
|---|---|---|---|
| 00:00–04:15 | 1–3 | Автор, обещание, 25 процессов и формат | Объяснить, почему эту серию стоит смотреть |
| 04:15–06:15 | 4 | Проблема релиза C++ импортера; проверить уже существующие практики | Дать конкретную инженерную ситуацию |
| 06:15–09:35 | 5–6 | Обзор 28 методологий, выбранные публикации 2004–2022, разные способы организации работ | Показать развитие подходов и их содержательные различия |
| 09:35–12:55 | 7–8 | Обсуждения около 2009 года, НИР и проекты с 2013-го, утверждение 2016 и введение 2017 | Отделить воспоминания участника от формальных дат |
| 12:55–16:15 | 9–10 | Разработчики и рецензенты; первичная аудитория; замысел серии документов и рабочие версии | Объяснить, зачем и для кого создавали стандарт |
| 16:15–20:05 | 11–12 | Международные связи; хронология SSDF; структура и модальность двух редакций | Избежать ложных выводов о заимствованиях и арифметического сравнения мер/процессов |
| 20:05–21:45 | 13 | Разовая проверка и поддерживаемый процесс | Перейти от истории к организации работы |
| 21:45–25:05 | 14–15 | Границы доказательств; метод сравнения требований | Сопоставлять действия, условия и свидетельства |
| 25:05–33:20 | 16–20 | Пять требований, область, состояние, роли, ресурсы, два плана | Подготовить практический пример |
| 33:20–37:10 | 21–22 | План на 90 дней и пять связанных записей | Показать применимый результат |
| 37:10–40:35 | 23–24 | Ограниченное сопоставление и проверка плана, масштаб небольшой команды | Вернуться к международному вопросу и пятничному релизу |
| 40:35–53:00 | 25 | Vitaliy Pikov, pikov.art и анонс EP02; краткое упражнение в речи | Дать контакт автора и понятный следующий шаг |
Подробные слоты, количество слов и зависимость от темпа — в EP01-timing.md. 53:00 — рабочий ориентир для репетиции, рассчитанный при 120 словах/мин и отдельных паузах на показ схем, не требование ГОСТ и не доказанный оптимум удержания YouTube. Если ясная речь занимает больше времени, длительность можно увеличить; автор разрешил расширение выпуска.
Что показывать
- Слайд 1: готовая яркая обложка. При монтаже допустимо начать с автора в кадре и перейти к ней.
- Слайды 2–3: три вопроса и четыре авторские учебные группы. Группы не выдаются за классификацию стандарта.
- Слайд 5: самостоятельно составленная SVG-шкала шести публикаций/редакций: 2004 — исследование жизненного цикла; 2006 — SDL, Touchpoints, CLASP; 2012 — SDL-Agile v5.2; 2017 — Singapore Security-by-Design; 2020 — SAMM v2.0; 2022 — SSDF v1.1. Это годы выбранных публикаций по Table II, не даты первого появления всех практик. Figure 2 содержит расхождения и не переносится целиком. Слайд 6: способы организации работ. Семь слайдов 7–13 раскрывают историю, авторство, замысел, международные связи и переход к практике.
- Слайд 8: апрель 2013 — начало НИР; Росстандарт утвердил стандарт 1 июня 2016 года, введение — 1 июня 2017 года. Не смешивать эти события.
- Слайд 12: девять групп мер 2016 и 25 процессов 2024 — разные единицы структуры. «Следует» проверять по п. 4.2 старой редакции и п. 4.7 новой.
- Слайды 16 и 22: пары «требования / свидетельства», визуально одинаковая структура из пяти пунктов.
- Слайды 17–21: один учебный продукт; роли и суммы повторяются согласованно. Планирование связывает существующее состояние, приоритеты и ресурсы; проценты расходов из дискуссии не выдавать за норматив.
- Слайд 23: две узкие пары сравнения. Расширенные направления исследования оставить в Markdown.
- Слайд 25: имя Vitaliy Pikov, заметная кликабельная ссылка pikov.art и полный заголовок следующего выпуска — EP02 · Security Training That Changes Engineering Decisions (ГОСТ 5.2, обучение сотрудников). Анонс объясняет пользу: связать роли с навыками и проверить результат обучения практическим заданием. Небольшое действие для зрителя остаётся в завершающей речи.
На слайдах — краткие формулировки, в Speaker notes — полный английский текст. Подсказки Cue на русском остаются в Markdown, зрителю их не показывать. Не читать метаданные и длинные URL вслух; короткий адрес автора в финале произнести как “pikov dot expert”. Смена слайда соответствует законченной мысли, а не каждому абзацу.
Рисунки и ведение зрителя
Визуальные материалы заданы в EP01-visuals.md: 16 иллюстрированных слайдов и 7 рисунков русской лекции. Сохраняются 29 слайдов и временные слоты; новая графика объясняет уже предусмотренные тезисы.
| Слайды | Визуальный приём | Действие докладчика |
|---|---|---|
| 03; 15 | Связанные учебные группы; способ сопоставления | Провести зрителя по связи между задачами, не объявляя схему классификацией ГОСТ |
| 04 → 24 | Один путь от входного файла до релизного решения: сначала с разрывом, затем с понятными действиями | В начале указать неопределённость, в конце проверить область, время, участника и свидетельство |
| 05; 08; 11 | Шкалы методологий, создания ГОСТ и публикаций SSDF | Назвать тип даты и объяснить, почему хронология не доказывает заимствование |
| 12 | Две редакции: структура и значение «следует» | Сравнить конкретные правила, не показывать 9 → 25 как количественный рост безопасности |
| 13 | Цикл события, исполнения, решения и пересмотра | Дойти от запуска проверки до следующего цикла работы |
| 16 → 22 | Одинаковая карта требований и свидетельств | Сначала объяснить зависимости планов, затем показать записи, по которым их проверяют |
| 17 | Граница продукта и связанная среда | Отделить включённые компоненты, контекст и обоснованное исключение |
| 19 | Горизонтальные полосы 60, 24 и 12 человеко-часов | Сделать паузу на сумме 96; пояснить, что это весь учебный план, не недельная нагрузка |
| 20; 21 | Возможность → задача → результат; три этапа на 90 дней | Связать намерение с исполнимой работой и результатом каждого этапа |
| 23 | Две пары частичного сопоставления | Прочитать общую задачу между документами, затем назвать границу вывода |
Семь русских рисунков относятся к §2, §4, §7, §9, §16, §18 и §22: методологии, история ГОСТ, повторяемый процесс, виды проверок, планирование, сопровождение, практикум. Иллюстрация должна дополнять самостоятельное изложение, иметь подпись и текстовое описание, доступные вместе с Markdown.
Для видимого текста и подписей используются начертания 600/700; длинное объяснение остаётся в речи. Цвет дублируется словесной подписью. Размеры блоков и стрелки учебных схем не означают численной оценки эффективности. Проверить читаемость после сборки на целевом кадре записи и в режиме чтения; результаты браузерной проверки фиксируются отдельно.
Содержание рисунка изменяется в Markdown-каталоге, затем выполняются build-visuals.py → build-content.py → build-review.py. Сценарий, самостоятельная лекция и их HTML-представления сохраняют одни и те же рисунки, подписи и смысловые ограничения.
Редакционные границы
История — выборка вех и анализ конкретных источников, не полная история компьютерной безопасности и не доказанная цепочка заимствований. Основания: полный транскрипт, два пользовательских PDF (обзор методологий и доклад Вареницы), окончательные тексты ГОСТ 2016/2024 и официальные карточки; подробности в исследовании. Воспоминания Вареницы атрибутировать; ошибочные «Минюст», «14 мер» и вывод о первенстве не переносить как проверенные факты. Международные пары на слайде 23 — Partial overlap, без сертификационной эквивалентности.
Пример импортера вымышленный. 90 дней, 96 человеко-часов, две релизные итерации и конкретное распределение ролей выбраны для обучения. Требования процесса и полезные способы реализации явно разграничены. Содержание п. 4.13 передаётся точно: CI, а не обязательный continuous deployment.
Содержательные темы всей исходной дискуссии и вопросы аудитории сохранены в отдельной русской лекции. Для английского EP01 не требуется зачитывать весь двухчасовой вебинар: подробные споры о тестировании, сертификации, обучении и инструментах доступны в конспекте и служат основой следующих выпусков. Запись звука и внешняя техническая рецензия ещё не выполнены.
Решение о порядке подготовки
По указанию автора 6 сентября первым подробно разрабатывается EP01, с введением и историей. Ранее предложенный порядок производственного пилота EP07 → EP10 → EP01 был рекомендацией; он не препятствует этому решению. Нумерация 25 процессов сохраняется.
Исходный Markdown целиком
# EP01 — План первого вебинара
Дата: 2026-09-06. Формат: предварительная запись с монтажом, основной голос — автор. На EP01 гость не нужен: знакомство, постановка исследовательского вопроса и единая логика рассказа требуют цельного авторского выступления. Это редакционное решение для проекта, а не ограничение будущих выпусков.
## Обещание зрителю
**Примерно за 42 минуты понять, зачем исследовать 25 процессов российского стандарта, проследить создание редакции 2016 года и научиться составлять связанный план первой инициативы по безопасной разработке.**
Выпуск содержит 29 слайдов. [Самостоятельная русская лекция](PVS-2025-07-02-lecture.md) и её [HTML-версия](PVS-2025-07-02-lecture.html) охватывают историю стандартов, организацию процессов и практику внедрения; они предназначены для чтения и передачи слушателям и партнёрам. Английский EP01 сохраняет свой фокус: введение, история стандарта и планирование. Сведения об исходном вебинаре приведены в примечании к учебной лекции; рабочая карта источников хранится в исследовательских документах.
Основная аудитория: практики AppSec/SSDLC, разработчики и технические руководители. Опыт программирования полезен, знание российских стандартов не требуется. Аудиторам пригодятся подробные ссылки и границы сопоставления в приложениях.
К концу выпуска зритель сможет:
1. Различить национальный стандарт, framework практик и модель зрелости.
2. Объяснить, почему история безопасной разработки включает архитектурные принципы и организацию работы.
3. Назвать пять требований процесса 5.1 и соответствующие категории свидетельств.
4. Отличить план развития процессов от плана их реализации.
5. Заполнить небольшой рабочий лист: область, состояние, ресурсы, развитие, реализация.
6. Разделить ранние обсуждения, начало НИР, проекты, утверждение и введение стандарта в действие.
7. Проверять модальность и структуру по конкретной редакции, включая изменение значения «следует» между 2016 и 2024 годами.
## Драматургия и хронометраж
| Интервал | Слайды | Содержание | Зачем |
|---|---|---|---|
| 00:00–04:15 | 1–3 | Автор, обещание, 25 процессов и формат | Объяснить, почему эту серию стоит смотреть |
| 04:15–06:15 | 4 | Проблема релиза C++ импортера; проверить уже существующие практики | Дать конкретную инженерную ситуацию |
| 06:15–09:35 | 5–6 | Обзор 28 методологий, выбранные публикации 2004–2022, разные способы организации работ | Показать развитие подходов и их содержательные различия |
| 09:35–12:55 | 7–8 | Обсуждения около 2009 года, НИР и проекты с 2013-го, утверждение 2016 и введение 2017 | Отделить воспоминания участника от формальных дат |
| 12:55–16:15 | 9–10 | Разработчики и рецензенты; первичная аудитория; замысел серии документов и рабочие версии | Объяснить, зачем и для кого создавали стандарт |
| 16:15–20:05 | 11–12 | Международные связи; хронология SSDF; структура и модальность двух редакций | Избежать ложных выводов о заимствованиях и арифметического сравнения мер/процессов |
| 20:05–21:45 | 13 | Разовая проверка и поддерживаемый процесс | Перейти от истории к организации работы |
| 21:45–25:05 | 14–15 | Границы доказательств; метод сравнения требований | Сопоставлять действия, условия и свидетельства |
| 25:05–33:20 | 16–20 | Пять требований, область, состояние, роли, ресурсы, два плана | Подготовить практический пример |
| 33:20–37:10 | 21–22 | План на 90 дней и пять связанных записей | Показать применимый результат |
| 37:10–40:35 | 23–24 | Ограниченное сопоставление и проверка плана, масштаб небольшой команды | Вернуться к международному вопросу и пятничному релизу |
| 40:35–53:00 | 25 | Vitaliy Pikov, pikov.art и анонс EP02; краткое упражнение в речи | Дать контакт автора и понятный следующий шаг |
Подробные слоты, количество слов и зависимость от темпа — в [EP01-timing.md](EP01-timing.md). 53:00 — рабочий ориентир для репетиции, рассчитанный при 120 словах/мин и отдельных паузах на показ схем, не требование ГОСТ и не доказанный оптимум удержания YouTube. Если ясная речь занимает больше времени, длительность можно увеличить; автор разрешил расширение выпуска.
## Что показывать
- Слайд 1: готовая яркая обложка. При монтаже допустимо начать с автора в кадре и перейти к ней.
- Слайды 2–3: три вопроса и четыре авторские учебные группы. Группы не выдаются за классификацию стандарта.
- Слайд 5: самостоятельно составленная SVG-шкала шести публикаций/редакций: 2004 — исследование жизненного цикла; 2006 — SDL, Touchpoints, CLASP; 2012 — SDL-Agile v5.2; 2017 — Singapore Security-by-Design; 2020 — SAMM v2.0; 2022 — SSDF v1.1. Это годы выбранных публикаций по Table II, не даты первого появления всех практик. Figure 2 содержит расхождения и не переносится целиком. Слайд 6: способы организации работ. Семь слайдов 7–13 раскрывают историю, авторство, замысел, международные связи и переход к практике.
- Слайд 8: апрель 2013 — начало НИР; Росстандарт утвердил стандарт 1 июня 2016 года, введение — 1 июня 2017 года. Не смешивать эти события.
- Слайд 12: девять групп мер 2016 и 25 процессов 2024 — разные единицы структуры. «Следует» проверять по п. 4.2 старой редакции и п. 4.7 новой.
- Слайды 16 и 22: пары «требования / свидетельства», визуально одинаковая структура из пяти пунктов.
- Слайды 17–21: один учебный продукт; роли и суммы повторяются согласованно. Планирование связывает существующее состояние, приоритеты и ресурсы; проценты расходов из дискуссии не выдавать за норматив.
- Слайд 23: две узкие пары сравнения. Расширенные направления исследования оставить в Markdown.
- Слайд 25: имя **Vitaliy Pikov**, заметная кликабельная ссылка **[pikov.art](https://pikov.art)** и полный заголовок следующего выпуска — **EP02 · Security Training That Changes Engineering Decisions** (ГОСТ 5.2, обучение сотрудников). Анонс объясняет пользу: связать роли с навыками и проверить результат обучения практическим заданием. Небольшое действие для зрителя остаётся в завершающей речи.
На слайдах — краткие формулировки, в Speaker notes — полный английский текст. Подсказки `Cue` на русском остаются в Markdown, зрителю их не показывать. Не читать метаданные и длинные URL вслух; короткий адрес автора в финале произнести как **“pikov dot expert”**. Смена слайда соответствует законченной мысли, а не каждому абзацу.
### Рисунки и ведение зрителя
Визуальные материалы заданы в [EP01-visuals.md](EP01-visuals.md): **16 иллюстрированных слайдов и 7 рисунков русской лекции**. Сохраняются 29 слайдов и временные слоты; новая графика объясняет уже предусмотренные тезисы.
| Слайды | Визуальный приём | Действие докладчика |
|---|---|---|
| 03; 15 | Связанные учебные группы; способ сопоставления | Провести зрителя по связи между задачами, не объявляя схему классификацией ГОСТ |
| 04 → 24 | Один путь от входного файла до релизного решения: сначала с разрывом, затем с понятными действиями | В начале указать неопределённость, в конце проверить область, время, участника и свидетельство |
| 05; 08; 11 | Шкалы методологий, создания ГОСТ и публикаций SSDF | Назвать тип даты и объяснить, почему хронология не доказывает заимствование |
| 12 | Две редакции: структура и значение «следует» | Сравнить конкретные правила, не показывать 9 → 25 как количественный рост безопасности |
| 13 | Цикл события, исполнения, решения и пересмотра | Дойти от запуска проверки до следующего цикла работы |
| 16 → 22 | Одинаковая карта требований и свидетельств | Сначала объяснить зависимости планов, затем показать записи, по которым их проверяют |
| 17 | Граница продукта и связанная среда | Отделить включённые компоненты, контекст и обоснованное исключение |
| 19 | Горизонтальные полосы 60, 24 и 12 человеко-часов | Сделать паузу на сумме 96; пояснить, что это весь учебный план, не недельная нагрузка |
| 20; 21 | Возможность → задача → результат; три этапа на 90 дней | Связать намерение с исполнимой работой и результатом каждого этапа |
| 23 | Две пары частичного сопоставления | Прочитать общую задачу между документами, затем назвать границу вывода |
Семь русских рисунков относятся к §2, §4, §7, §9, §16, §18 и §22: методологии, история ГОСТ, повторяемый процесс, виды проверок, планирование, сопровождение, практикум. Иллюстрация должна дополнять самостоятельное изложение, иметь подпись и текстовое описание, доступные вместе с Markdown.
Для видимого текста и подписей используются начертания **600/700**; длинное объяснение остаётся в речи. Цвет дублируется словесной подписью. Размеры блоков и стрелки учебных схем не означают численной оценки эффективности. Проверить читаемость после сборки на целевом кадре записи и в режиме чтения; результаты браузерной проверки фиксируются отдельно.
Содержание рисунка изменяется в Markdown-каталоге, затем выполняются `build-visuals.py` → `build-content.py` → `build-review.py`. Сценарий, самостоятельная лекция и их HTML-представления сохраняют одни и те же рисунки, подписи и смысловые ограничения.
## Редакционные границы
История — выборка вех и анализ конкретных источников, не полная история компьютерной безопасности и не доказанная цепочка заимствований. Основания: полный транскрипт, два пользовательских PDF (обзор методологий и доклад Вареницы), окончательные тексты ГОСТ 2016/2024 и официальные карточки; подробности в [исследовании](EP01-history-research.md). Воспоминания Вареницы атрибутировать; ошибочные «Минюст», «14 мер» и вывод о первенстве не переносить как проверенные факты. Международные пары на слайде 23 — `Partial overlap`, без сертификационной эквивалентности.
Пример импортера вымышленный. 90 дней, 96 человеко-часов, две релизные итерации и конкретное распределение ролей выбраны для обучения. Требования процесса и полезные способы реализации явно разграничены. Содержание п. 4.13 передаётся точно: CI, а не обязательный continuous deployment.
Содержательные темы всей исходной дискуссии и вопросы аудитории сохранены в отдельной русской лекции. Для английского EP01 не требуется зачитывать весь двухчасовой вебинар: подробные споры о тестировании, сертификации, обучении и инструментах доступны в конспекте и служат основой следующих выпусков. Запись звука и внешняя техническая рецензия ещё не выполнены.
## Решение о порядке подготовки
По указанию автора 6 сентября первым подробно разрабатывается **EP01**, с введением и историей. Ранее предложенный порядок производственного пилота EP07 → EP10 → EP01 был рекомендацией; он не препятствует этому решению. Нумерация 25 процессов сохраняется.
SHA-256: 54b7785da1af3b1e3f77b1b61289d6a511d3d464f8f11c0c58f617940ab1791a
05EP01 — A planning example for an engineering-file importerEP01-planning-example.md
EP01 — A planning example for an engineering-file importer
Illustrative teaching example. The product, observations, roles, numbers and schedule below are fictional. This is a starting model for discussion, not a completed conformity assessment. Baseline: GOST R 56939-2024, 5.1.2 and 5.1.3; implementation choices are identified separately.
1. Scope and rationale — 5.1.3.5
Software: Importer 2.0, its C++ parser module, small service API and shipped third-party libraries. Include the relevant version and component identifiers in the real record. Rationale: these elements participate in processing externally supplied engineering files or distributing the product.
Connected development context: source repository, build definitions, CI configuration, issue tracker and release workflow. These links support traceability; they do not replace identifying the parts the software is made of.
Proposed exclusion: a retired prototype, only after confirming that its code, generated artifacts and dependencies do not flow into the selected release. Record the reason and supporting inspection. A convenient boundary is not automatically a justified boundary.
2. Current-state analysis — 5.1.3.1
| Illustrative observation | Evidence to collect in a real assessment | Planning consequence |
|---|---|---|
| Parser analysis is run manually | Recent reports, invocation/configuration and covered targets | Make the activity repeatable and version-linked |
| Finding ownership is unclear | Existing tickets and decision history | Assign investigation and decision responsibilities |
| Coverage is not documented | Build target list versus analyzed target list | Review gaps and record justified boundaries |
| Other secure development processes are not assessed in this exercise | A real inventory of implemented and unimplemented processes is required | Extend the assessment before claiming a complete 5.1.3.1 artifact |
The standard's current-state artifact concerns implemented and unimplemented processes and the sufficiency and conformity of those implemented. This teaching slice intentionally concentrates on one improvement; its four-row table is not a complete organizational assessment.
3. Resource analysis — 5.1.3.2
| Stage | Engineering hours | AppSec hours | Release/sponsor hours | Total |
|---|---|---|---|---|
| Days 1–30 | 12 | 8 | 4 | 24 |
| Days 31–60 | 36 | 8 | 4 | 48 |
| Days 61–90 | 12 | 8 | 4 | 24 |
| Total | 60 | 24 | 12 | 96 |
Units: person-hours across the full illustrative 90-day effort. These are estimates to validate with the people doing the work, not recorded effort or a industry benchmark. Tool licences, compute capacity, storage and additional training costs are assessed separately; they are not assumed to be free. Confirm build-engineer availability and the planned release cadence.
The artifact description permits estimated material and human resource indicators. It does not prescribe these figures or a universal percentage of development cost.
4. Process improvement plan — 5.1.3.3
Goal: move from ad hoc parser analysis to a repeatable, traceable process with understandable ownership.
Priority order: establish scope and baseline → integrate the selected checks → make findings reviewable → evaluate observed gaps and resource use. Reason: automation without a known target and an owner would preserve the original ambiguity.
Planned organizational change: define investigation ownership and release decision authority in the team's policy. Planned capability change: reliable integration of the selected parser checks. Training: use the allocated AppSec/engineering effort to explain triage records and coverage limitations; reassess if specialist training is needed. Procurement: decide from the resource assessment rather than assume a new product is necessary.
5. Implementation plan — 5.1.3.4
| Stage and objective | Owner | Resources | Evidence expected at review |
|---|---|---|---|
| Days 1–30: agreed baseline | Engineering lead with AppSec; sponsor confirms capacity | 24 hours | Versioned scope/rationale, current-state notes, resource assumptions, named owners |
| Days 31–60: repeatable checks and triage | Engineering lead; AppSec reviews criteria | 48 hours | CI run linked to commit, coverage record, finding/decision records, release-workflow links |
| Days 61–90: review actual execution | Release owner coordinates; engineering/AppSec review evidence | 24 hours | Evidence from two illustrative releases, gaps, actual versus estimated effort, updated improvement priorities |
The release owner acts under the team's approved policy. The role title alone does not confer residual-risk acceptance authority. If one person holds several roles, record that explicitly and assess the arrangement in context.
Review trigger chosen for this example: at day 90 and after a material scope or workflow change. If two releases do not occur, revise the evaluation plan; do not manufacture evidence or label the process effective without observation. Store dated versions of the analyses and plans.
Review questions
Can a reviewer identify the affected product/version, why the next improvement was chosen, who performs the work, who makes the decision, what capacity is available, and where the underlying evidence is stored? Can they distinguish completed actions from future tasks and unassessed processes?
The one-page summary and linked records can live in a repository or task tracker. The standard explicitly allows task-management representations of the two plans. A particular tool, document count and 90-day timetable are not prescribed.
Source: local final GOST text, clauses 4.11–4.13 and 5.1; edition verified in the official Rosstandart record. Methodical details and international comparisons: EP01-sources.md.
Исходный Markdown целиком
# EP01 — A planning example for an engineering-file importer
**Illustrative teaching example.** The product, observations, roles, numbers and schedule below are fictional. This is a starting model for discussion, not a completed conformity assessment. Baseline: GOST R 56939-2024, 5.1.2 and 5.1.3; implementation choices are identified separately.
## 1. Scope and rationale — 5.1.3.5
Software: Importer 2.0, its C++ parser module, small service API and shipped third-party libraries. Include the relevant version and component identifiers in the real record. Rationale: these elements participate in processing externally supplied engineering files or distributing the product.
Connected development context: source repository, build definitions, CI configuration, issue tracker and release workflow. These links support traceability; they do not replace identifying the parts the software is made of.
Proposed exclusion: a retired prototype, only after confirming that its code, generated artifacts and dependencies do not flow into the selected release. Record the reason and supporting inspection. A convenient boundary is not automatically a justified boundary.
## 2. Current-state analysis — 5.1.3.1
| Illustrative observation | Evidence to collect in a real assessment | Planning consequence |
|---|---|---|
| Parser analysis is run manually | Recent reports, invocation/configuration and covered targets | Make the activity repeatable and version-linked |
| Finding ownership is unclear | Existing tickets and decision history | Assign investigation and decision responsibilities |
| Coverage is not documented | Build target list versus analyzed target list | Review gaps and record justified boundaries |
| Other secure development processes are not assessed in this exercise | A real inventory of implemented and unimplemented processes is required | Extend the assessment before claiming a complete 5.1.3.1 artifact |
The standard's current-state artifact concerns implemented and unimplemented processes and the sufficiency and conformity of those implemented. This teaching slice intentionally concentrates on one improvement; its four-row table is not a complete organizational assessment.
## 3. Resource analysis — 5.1.3.2
| Stage | Engineering hours | AppSec hours | Release/sponsor hours | Total |
|---|---:|---:|---:|---:|
| Days 1–30 | 12 | 8 | 4 | 24 |
| Days 31–60 | 36 | 8 | 4 | 48 |
| Days 61–90 | 12 | 8 | 4 | 24 |
| **Total** | **60** | **24** | **12** | **96** |
Units: person-hours across the full illustrative 90-day effort. These are estimates to validate with the people doing the work, not recorded effort or a industry benchmark. Tool licences, compute capacity, storage and additional training costs are assessed separately; they are not assumed to be free. Confirm build-engineer availability and the planned release cadence.
The artifact description permits estimated material and human resource indicators. It does not prescribe these figures or a universal percentage of development cost.
## 4. Process improvement plan — 5.1.3.3
Goal: move from ad hoc parser analysis to a repeatable, traceable process with understandable ownership.
Priority order: establish scope and baseline → integrate the selected checks → make findings reviewable → evaluate observed gaps and resource use. Reason: automation without a known target and an owner would preserve the original ambiguity.
Planned organizational change: define investigation ownership and release decision authority in the team's policy. Planned capability change: reliable integration of the selected parser checks. Training: use the allocated AppSec/engineering effort to explain triage records and coverage limitations; reassess if specialist training is needed. Procurement: decide from the resource assessment rather than assume a new product is necessary.
## 5. Implementation plan — 5.1.3.4
| Stage and objective | Owner | Resources | Evidence expected at review |
|---|---|---|---|
| Days 1–30: agreed baseline | Engineering lead with AppSec; sponsor confirms capacity | 24 hours | Versioned scope/rationale, current-state notes, resource assumptions, named owners |
| Days 31–60: repeatable checks and triage | Engineering lead; AppSec reviews criteria | 48 hours | CI run linked to commit, coverage record, finding/decision records, release-workflow links |
| Days 61–90: review actual execution | Release owner coordinates; engineering/AppSec review evidence | 24 hours | Evidence from two illustrative releases, gaps, actual versus estimated effort, updated improvement priorities |
The release owner acts under the team's approved policy. The role title alone does not confer residual-risk acceptance authority. If one person holds several roles, record that explicitly and assess the arrangement in context.
Review trigger chosen for this example: at day 90 and after a material scope or workflow change. If two releases do not occur, revise the evaluation plan; do not manufacture evidence or label the process effective without observation. Store dated versions of the analyses and plans.
## Review questions
Can a reviewer identify the affected product/version, why the next improvement was chosen, who performs the work, who makes the decision, what capacity is available, and where the underlying evidence is stored? Can they distinguish completed actions from future tasks and unassessed processes?
The one-page summary and linked records can live in a repository or task tracker. The standard explicitly allows task-management representations of the two plans. A particular tool, document count and 90-day timetable are not prescribed.
Source: local final GOST text, clauses 4.11–4.13 and 5.1; edition verified in the [official Rosstandart record](https://protect.gost.ru/gost/details/f3818925-a96f-4f55-96e9-46b44720ee64). Methodical details and international comparisons: [EP01-sources.md](EP01-sources.md).
SHA-256: 02e4100c4bff8ef3ea1ba4ecb3f083af5e1c60e5dd0e5954dd21f07df793b26b
06Secure development planning — worksheetEP01-planning-worksheet.md
Secure development planning — worksheet
Companion to EP01, Secure Software Development in Practice, Vitaliy Pikov. This is an intentionally blank exercise. Adapt it to the actual product and obligations. A filled worksheet does not by itself establish conformity with GOST R 56939-2024.
Product and record
- Product / version / components:
- Record owner / date / revision:
- Applicable context and standards to consider:
- Links to the repository and task tracker:
Scope — 5.1.3.5
- Included software and why it was selected:
- Proposed exclusions, rationale and supporting evidence:
- Relationships that may require widening the scope:
- Who reviewed the boundary and when:
Current state — 5.1.3.1
| Process | Implemented / not implemented / not assessed | Evidence | Sufficiency and conformity assessment | Gap |
|---|---|---|---|---|
Inventory the relevant processes. Do not turn “not assessed” into “implemented” without examination. Link to actual records, not only statements that tools exist.
Resources — 5.1.3.2
| Needed capability | People and availability | Tools / infrastructure | Estimate and assumptions | Unresolved constraint |
|---|---|---|---|---|
Improvement plan — 5.1.3.3
| Priority | Intended process change | Reason from the analyses | Resource dependency | Target sequence |
|---|---|---|---|---|
Include relevant organizational changes, procurement and training needs. Explain prioritization.
Implementation plan — 5.1.3.4
| Goal / action | Stage and date | Responsible person | Resources | Expected evidence | Status |
|---|---|---|---|---|---|
Review and authority
- Review frequency selected by the organization:
- Additional review triggers:
- Who can resolve resource conflicts:
- Who can make the relevant release/risk decision under the applicable policy:
- Where changes and previous decisions are preserved:
Discussion prompt
Ask another team member to find the next action, its owner and the expected result without a verbal explanation from you. Record what was unclear and improve the page.
Исходный Markdown целиком
# Secure development planning — worksheet
Companion to EP01, *Secure Software Development in Practice*, Vitaliy Pikov.
This is an intentionally blank exercise. Adapt it to the actual product and obligations. A filled worksheet does not by itself establish conformity with GOST R 56939-2024.
## Product and record
- Product / version / components:
- Record owner / date / revision:
- Applicable context and standards to consider:
- Links to the repository and task tracker:
## Scope — 5.1.3.5
- Included software and why it was selected:
- Proposed exclusions, rationale and supporting evidence:
- Relationships that may require widening the scope:
- Who reviewed the boundary and when:
## Current state — 5.1.3.1
| Process | Implemented / not implemented / not assessed | Evidence | Sufficiency and conformity assessment | Gap |
|---|---|---|---|---|
| | | | | |
Inventory the relevant processes. Do not turn “not assessed” into “implemented” without examination. Link to actual records, not only statements that tools exist.
## Resources — 5.1.3.2
| Needed capability | People and availability | Tools / infrastructure | Estimate and assumptions | Unresolved constraint |
|---|---|---|---|---|
| | | | | |
## Improvement plan — 5.1.3.3
| Priority | Intended process change | Reason from the analyses | Resource dependency | Target sequence |
|---|---|---|---|---|
| | | | | |
Include relevant organizational changes, procurement and training needs. Explain prioritization.
## Implementation plan — 5.1.3.4
| Goal / action | Stage and date | Responsible person | Resources | Expected evidence | Status |
|---|---|---|---|---|---|
| | | | | | |
## Review and authority
- Review frequency selected by the organization:
- Additional review triggers:
- Who can resolve resource conflicts:
- Who can make the relevant release/risk decision under the applicable policy:
- Where changes and previous decisions are preserved:
## Discussion prompt
Ask another team member to find the next action, its owner and the expected result without a verbal explanation from you. Record what was unclear and improve the page.
SHA-256: a210c3eb29e21fef84a472882229e2cda8d34706fba39294eaebeccab5766915
07EP01 — YouTube publishing draftEP01-publishing-draft.md
EP01 — YouTube publishing draft
Prepared 2026-09-06. Draft text only: nothing has been uploaded or posted. Replace planned chapter times with the final edited recording times; add the actual public materials URL when one exists. Local filesystem paths must not be put in the public description.
Title
Where Secure Development Begins: History, GOST & a Practical Plan | EP01
Series: Secure Software Development in Practice Subtitle: 25 Processes from GOST R 56939 Compared with Global Practices
Description
What turns a security intention into work a software team can actually perform?
In this first episode, Vitaliy Pikov introduces a 25-part series exploring the processes of GOST R 56939-2024 and comparing them with international secure development practices.
We use a review of 28 secure-development methodologies to explore publication milestones, ways of organizing security work, and the limits of effectiveness evidence. The history of the Russian standard follows early conversations around 2009, research and drafting from 2013, approval in 2016 and entry into force in 2017. Vitaliy Varenitsa's account explains the early discussions and the authors' original intentions.
The expanded history separates the author's recollections from official records. It covers the original plan for a family of documents, the roles of developers and reviewers, international connections and the transition to the 2024 edition. We also examine why nine groups of measures cannot be compared arithmetically with 25 processes, and why requirement wording must be read in its specific edition.
The practical section builds an illustrative plan for a C++ engineering-file importer: current-state analysis, resources, process improvement, implementation planning, scope and evidence. We look for existing useful practices before proposing new tools, distinguish one-time checks from maintained processes, and connect planning records to work the team can review.
You will also see a bounded comparison with NIST SSDF 1.1 and OWASP SAMM. Similar engineering concerns do not automatically mean equivalent requirements.
The 90-day schedule and resource figures are teaching examples. English translations of GOST clauses are the author's working translations. Framework versions and links were checked on 6 September 2026; SSDF 1.2 was listed as a draft at that check.
Sources:
- GOST R 56939-2024, official record
- GOST R 56939-2016, official record
- NIST SSDF public draft announcement, June 2019
- NIST SSDF 1.0 final announcement, April 2020
- NIST SSDF 1.1
- OWASP SAMM: Strategy and Metrics
- Microsoft SDL history
- RAND: Security Controls for Computer Systems
- Saltzer and Schroeder
- Secure Software Development Methodologies: A Multivocal Literature Review
- OWASP SAMM v2 release announcement
Historical source: Vitaliy Varenitsa, “История создания и актуальное состояние РБПО в России. ГОСТ Р 56939-2016/24”, presentation at the MASCOM / PVS-Studio webinar, 2 July 2025.
The series builds on an earlier Russian-language webinar project delivered with PVS-Studio. The companion Russian lecture covers the history of the standards and practical ways to organize secure development. The international comparison and worked example extend that teaching material.
Author: Vitaliy Pikov — pikov.art.
Next episode: Security Training That Changes Engineering Decisions — employee training under clause 5.2, role and skills mapping, practical exercises and evidence of progress.
Planned chapters — update after editing
00:00 Where secure development begins
01:05 The series and its practical promise
04:15 A release problem in a fictional C++ team
06:15 Methodology publications and different operating models
09:35 The problem behind the Russian standard
11:10 Research, drafts, approval and effective date
12:55 Authors, reviewers and intended users
14:40 The original plan for a family of standards
16:15 International connections and the SSDF timeline
18:20 Two editions: structure and requirement wording
20:05 From a tool run to a maintained process
21:45 Shared practices and effectiveness evidence
23:15 Our comparison method
25:05 The five planning requirements
31:40 Two plans, two questions
33:20 A 90-day planning example
37:10 The first international crosswalk
39:00 Applying the plan to the release decision
40:35 Stay in touch and the next episode
Pinned comment draft
Which planning problem is hardest in your team: defining scope, assigning ownership, reserving capacity, or keeping the plan current? Share an example without confidential product or customer details.
Final publication fields still to set
Public materials URL; actual recording/version-check date; final timestamps; selected subtitle track. These are publication inputs, not blockers for rehearsing the completed draft. No guest or release date is currently announced.
Исходный Markdown целиком
# EP01 — YouTube publishing draft
Prepared 2026-09-06. Draft text only: nothing has been uploaded or posted. Replace planned chapter times with the final edited recording times; add the actual public materials URL when one exists. Local filesystem paths must not be put in the public description.
## Title
Where Secure Development Begins: History, GOST & a Practical Plan | EP01
Series: **Secure Software Development in Practice**
Subtitle: **25 Processes from GOST R 56939 Compared with Global Practices**
## Description
What turns a security intention into work a software team can actually perform?
In this first episode, Vitaliy Pikov introduces a 25-part series exploring the processes of GOST R 56939-2024 and comparing them with international secure development practices.
We use a review of 28 secure-development methodologies to explore publication milestones, ways of organizing security work, and the limits of effectiveness evidence. The history of the Russian standard follows early conversations around 2009, research and drafting from 2013, approval in 2016 and entry into force in 2017. Vitaliy Varenitsa's account explains the early discussions and the authors' original intentions.
The expanded history separates the author's recollections from official records. It covers the original plan for a family of documents, the roles of developers and reviewers, international connections and the transition to the 2024 edition. We also examine why nine groups of measures cannot be compared arithmetically with 25 processes, and why requirement wording must be read in its specific edition.
The practical section builds an illustrative plan for a C++ engineering-file importer: current-state analysis, resources, process improvement, implementation planning, scope and evidence. We look for existing useful practices before proposing new tools, distinguish one-time checks from maintained processes, and connect planning records to work the team can review.
You will also see a bounded comparison with NIST SSDF 1.1 and OWASP SAMM. Similar engineering concerns do not automatically mean equivalent requirements.
The 90-day schedule and resource figures are teaching examples. English translations of GOST clauses are the author's working translations. Framework versions and links were checked on 6 September 2026; SSDF 1.2 was listed as a draft at that check.
Sources:
- [GOST R 56939-2024, official record](https://protect.gost.ru/gost/details/f3818925-a96f-4f55-96e9-46b44720ee64)
- [GOST R 56939-2016, official record](https://protect.gost.ru/gost/details/286a588e-4a6a-4899-88f7-3c370dea1e1d)
- [NIST SSDF public draft announcement, June 2019](https://csrc.nist.gov/News/2019/draft-white-paper-on-ssdf)
- [NIST SSDF 1.0 final announcement, April 2020](https://csrc.nist.gov/news/2020/mitigating-risk-of-software-vulns-ssdf)
- [NIST SSDF 1.1](https://csrc.nist.gov/pubs/sp/800/218/final)
- [OWASP SAMM: Strategy and Metrics](https://owaspsamm.org/model/governance/strategy-and-metrics/stream-a/)
- [Microsoft SDL history](https://www.microsoft.com/en-us/securityengineering/sdl/about)
- [RAND: Security Controls for Computer Systems](https://www.rand.org/pubs/reports/R609-1.html)
- [Saltzer and Schroeder](https://web.mit.edu/saltzer/www/publications/protection/index.html)
- [Secure Software Development Methodologies: A Multivocal Literature Review](https://arxiv.org/abs/2211.16987)
- [OWASP SAMM v2 release announcement](https://owaspsamm.org/blog/samm2-release/)
Historical source: Vitaliy Varenitsa, “История создания и актуальное состояние РБПО в России. ГОСТ Р 56939-2016/24”, presentation at the MASCOM / PVS-Studio webinar, 2 July 2025.
The series builds on an earlier Russian-language webinar project delivered with PVS-Studio. The companion Russian lecture covers the history of the standards and practical ways to organize secure development. The international comparison and worked example extend that teaching material.
Author: **Vitaliy Pikov — [pikov.art](https://pikov.art)**.
Next episode: **Security Training That Changes Engineering Decisions** — employee training under clause 5.2, role and skills mapping, practical exercises and evidence of progress.
## Planned chapters — update after editing
```text
00:00 Where secure development begins
01:05 The series and its practical promise
04:15 A release problem in a fictional C++ team
06:15 Methodology publications and different operating models
09:35 The problem behind the Russian standard
11:10 Research, drafts, approval and effective date
12:55 Authors, reviewers and intended users
14:40 The original plan for a family of standards
16:15 International connections and the SSDF timeline
18:20 Two editions: structure and requirement wording
20:05 From a tool run to a maintained process
21:45 Shared practices and effectiveness evidence
23:15 Our comparison method
25:05 The five planning requirements
31:40 Two plans, two questions
33:20 A 90-day planning example
37:10 The first international crosswalk
39:00 Applying the plan to the release decision
40:35 Stay in touch and the next episode
```
## Pinned comment draft
Which planning problem is hardest in your team: defining scope, assigning ownership, reserving capacity, or keeping the plan current? Share an example without confidential product or customer details.
## Final publication fields still to set
Public materials URL; actual recording/version-check date; final timestamps; selected subtitle track. These are publication inputs, not blockers for rehearsing the completed draft. No guest or release date is currently announced.
SHA-256: aebc088380eb4693cc91fe341e8f5bd933b8476dd4f17e533be6688962d9d7a6
08EP01 — Подготовка английской речи и записиEP01-rehearsal.md
EP01 — Подготовка английской речи и записи
Порядок репетиции
- Прочитать слайды 1–4 вслух, записать звук и оценить темп по времени, а не ощущению. Затем отдельно проговорить исторические названия и номера пунктов.
- Провести полный проход с текстом. Таймер включить с первого слова; записать реальные границы блоков, паузы и места потери дыхания.
- Сверить результат с моделью хронометража. После сверки речи с графикой — 4327 слов, 29 слайдов и 53:00 плановых слотов. Распределение времени и пауз обосновано в проверке речи. Ориентир артикуляции 120–125 слов/мин с паузами, а не обязательная скорость. При естественном темпе 110 слов/мин увеличивать длительность или сокращать повторы; автор разрешил расширение выпуска.
- Повторно записать только трудные места: GOST designation, годы, shall/should, два плана и сравнительный вывод. Сохранять одинаковые английские термины.
- Записать чистовые блоки по 3–5 слайдов. Начало и конец каждого блока оставить с короткой тишиной для монтажа. После склейки прослушать переходы целиком.
В режиме веб-показа отключить полный текст речи в захватываемой области экрана. Читать Markdown или speaker notes на отдельном экране/окне, которое не попадает в запись. Одно окно презентации с раскрытыми notes удобно для репетиции; отдельного синхронизированного телесуфлёра в проекте нет.
Отдельно отрепетировать слайды 5–13: фамилии Arina Kudriavtseva / Olga Gadyatskaya / Vitaliy Varenitsa; различие research project / working draft / approval / entry into force; числа twenty-two organizations / around two hundred comments; даты June 2016 / June 2017; хронологию SSDF 2019 / 2020 / 2022. После первого упоминания авторов можно говорить the review и the retrospective. Вареница — участник разработки и автор исторического рассказа, Пиков — автор текущего выпуска. В слайде 12 произнести различие nine groups of measures / twenty-five processes и объяснить, почему «следует» имеет разную силу в двух редакциях.
Перед репетицией прочитать полную тематическую лекцию по исходному вебинару. История и практическая часть разделены по содержательным докладам; техническая карта источника хранится в исследовательских материалах. Английская речь уже адаптирована к нашему выпуску; не добавлять поверх неё все двухчасовые обсуждения. Финальный слайд теперь 25: произнести pikov dot expert, полное название EP02 и оставить зрителю время прочитать адрес.
Произношение и терминология
Подсказки ударения — приблизительные, не фонетическая транскрипция. Приоритет — понятная речь и единообразие.
| Term | Ударение / как произнести | Смысл |
|---|---|---|
| secure software development | se-CURE SOFTWARE de-VE-lop-ment | Разработка безопасного ПО |
| vulnerability | vul-ner-a-BI-li-ty | Подтверждённая уязвимость, не любое предупреждение |
| evidence | E-vi-dence | Неисчисляемое: evidence, some evidence; не evidences |
| scope | Односложное слово | Область применения, определённые границы |
| rationale | ra-tio-NALE | Обоснование выбора |
| requirements | re-QUIRE-ments | Требования |
| implementation | im-ple-men-TA-tion | Реализация |
| responsibility | re-spon-si-BI-li-ty | Ответственность за работу |
| traceability | trace-a-BI-li-ty | Прослеживаемость |
| maturity | ma-TU-ri-ty | Зрелость |
| triage | TREE-ahzh | Первичный разбор/приоритизация находок |
| NIST SSDF | NIST; S S D F | Сначала полное название, потом сокращение |
| OWASP SAMM | OH-wasp; sam | Software Assurance Maturity Model |
| SDL / CI | S D L / C I | Не смешивать CI и continuous deployment |
| PO.2.1 | P O, two point one | Идентификатор задачи в SSDF 1.1 |
| GOST R 56939-2024 | GOST R, five six nine three nine, twenty twenty-four | После первого полного упоминания достаточно the standard |
| BSIMM | BEE-sim | Одним словом, не по буквам |
| McGraw | muh-GRAW | Gary McGraw, автор Touchpoints |
| NPO Echelon | N P O, ESH-uh-lon | Разработчик редакции 2016 |
| FSTEC | F S T E C | Регулятор; разработчик редакции 2024 |
| sleduet | SLE-du-yet | Русское «следует»; в 2024 выражает требование, не совет |
Рабочие переводы: process improvement plan для «плана развития процессов» и process implementation plan для «плана реализации». В материалах обозначено, что переводы авторские. Process procedure обычно яснее, чем regulation, когда речь о внутреннем регламенте.
Фразы, которые помогают держать нить
- “Let us make this concrete.”
- “The shared concern is …”
- “The difference is in the scope and expected evidence.”
- “This is an illustrative choice, not a prescribed timetable.”
- “Keep this example in mind; we will return to it.”
- “The comparison is partial.”
Это запасные связки для живой подачи; не добавлять все поверх полного сценария, иначе вырастет хронометраж.
Контроль перед чистовой записью
- Автор прочитал весь текст и согласен с личным представлением и упоминанием прежнего проекта PVS-Studio.
- Даты и статусы источников перепроверены на дату записи; SSDF 1.2 не назван final без нового подтверждения.
- Термины «следует», «должен», CI/CD и разница двух планов произносятся без изменения смысла.
- Речь укладывается в выбранный темп; места пауз отмечены после пробной записи.
- Обложка и слайды читаются в реальном размере окна записи; лицо не перекрыто интерфейсом.
- В записи нет редакторских подсказок, уведомлений, личных данных других приложений или незаполненных ссылок публикации.
- После монтажа субтитры вручную сверены для имён, сокращений и номеров стандартов.
Это производственная памятка. Выполнение пунктов не считается установленным до реальной записи автора.
Исходный Markdown целиком
# EP01 — Подготовка английской речи и записи
## Порядок репетиции
1. Прочитать слайды 1–4 вслух, записать звук и оценить темп по времени, а не ощущению. Затем отдельно проговорить исторические названия и номера пунктов.
2. Провести полный проход с [текстом](EP01-script-en.md). Таймер включить с первого слова; записать реальные границы блоков, паузы и места потери дыхания.
3. Сверить результат с [моделью хронометража](EP01-timing.md). После сверки речи с графикой — 4327 слов, 29 слайдов и 53:00 плановых слотов. Распределение времени и пауз обосновано в [проверке речи](EP01-speech-review.md). Ориентир артикуляции 120–125 слов/мин с паузами, а не обязательная скорость. При естественном темпе 110 слов/мин увеличивать длительность или сокращать повторы; автор разрешил расширение выпуска.
4. Повторно записать только трудные места: GOST designation, годы, shall/should, два плана и сравнительный вывод. Сохранять одинаковые английские термины.
5. Записать чистовые блоки по 3–5 слайдов. Начало и конец каждого блока оставить с короткой тишиной для монтажа. После склейки прослушать переходы целиком.
В режиме веб-показа отключить полный текст речи в захватываемой области экрана. Читать Markdown или speaker notes на отдельном экране/окне, которое не попадает в запись. Одно окно презентации с раскрытыми notes удобно для репетиции; отдельного синхронизированного телесуфлёра в проекте нет.
Отдельно отрепетировать слайды 5–13: фамилии Arina Kudriavtseva / Olga Gadyatskaya / Vitaliy Varenitsa; различие research project / working draft / approval / entry into force; числа twenty-two organizations / around two hundred comments; даты June 2016 / June 2017; хронологию SSDF 2019 / 2020 / 2022. После первого упоминания авторов можно говорить `the review` и `the retrospective`. Вареница — участник разработки и автор исторического рассказа, Пиков — автор текущего выпуска. В слайде 12 произнести различие nine groups of measures / twenty-five processes и объяснить, почему «следует» имеет разную силу в двух редакциях.
Перед репетицией прочитать [полную тематическую лекцию по исходному вебинару](PVS-2025-07-02-lecture.md). История и практическая часть разделены по содержательным докладам; техническая карта источника хранится в исследовательских материалах. Английская речь уже адаптирована к нашему выпуску; не добавлять поверх неё все двухчасовые обсуждения. Финальный слайд теперь 25: произнести `pikov dot expert`, полное название EP02 и оставить зрителю время прочитать адрес.
## Произношение и терминология
Подсказки ударения — приблизительные, не фонетическая транскрипция. Приоритет — понятная речь и единообразие.
| Term | Ударение / как произнести | Смысл |
|---|---|---|
| secure software development | se-CURE SOFTWARE de-VE-lop-ment | Разработка безопасного ПО |
| vulnerability | vul-ner-a-BI-li-ty | Подтверждённая уязвимость, не любое предупреждение |
| evidence | E-vi-dence | Неисчисляемое: evidence, some evidence; не evidences |
| scope | Односложное слово | Область применения, определённые границы |
| rationale | ra-tio-NALE | Обоснование выбора |
| requirements | re-QUIRE-ments | Требования |
| implementation | im-ple-men-TA-tion | Реализация |
| responsibility | re-spon-si-BI-li-ty | Ответственность за работу |
| traceability | trace-a-BI-li-ty | Прослеживаемость |
| maturity | ma-TU-ri-ty | Зрелость |
| triage | TREE-ahzh | Первичный разбор/приоритизация находок |
| NIST SSDF | NIST; S S D F | Сначала полное название, потом сокращение |
| OWASP SAMM | OH-wasp; sam | Software Assurance Maturity Model |
| SDL / CI | S D L / C I | Не смешивать CI и continuous deployment |
| PO.2.1 | P O, two point one | Идентификатор задачи в SSDF 1.1 |
| GOST R 56939-2024 | GOST R, five six nine three nine, twenty twenty-four | После первого полного упоминания достаточно the standard |
| BSIMM | BEE-sim | Одним словом, не по буквам |
| McGraw | muh-GRAW | Gary McGraw, автор Touchpoints |
| NPO Echelon | N P O, ESH-uh-lon | Разработчик редакции 2016 |
| FSTEC | F S T E C | Регулятор; разработчик редакции 2024 |
| sleduet | SLE-du-yet | Русское «следует»; в 2024 выражает требование, не совет |
Рабочие переводы: `process improvement plan` для «плана развития процессов» и `process implementation plan` для «плана реализации». В материалах обозначено, что переводы авторские. `Process procedure` обычно яснее, чем `regulation`, когда речь о внутреннем регламенте.
## Фразы, которые помогают держать нить
- “Let us make this concrete.”
- “The shared concern is …”
- “The difference is in the scope and expected evidence.”
- “This is an illustrative choice, not a prescribed timetable.”
- “Keep this example in mind; we will return to it.”
- “The comparison is partial.”
Это запасные связки для живой подачи; не добавлять все поверх полного сценария, иначе вырастет хронометраж.
## Контроль перед чистовой записью
- Автор прочитал весь текст и согласен с личным представлением и упоминанием прежнего проекта PVS-Studio.
- Даты и статусы источников перепроверены на дату записи; SSDF 1.2 не назван final без нового подтверждения.
- Термины «следует», «должен», CI/CD и разница двух планов произносятся без изменения смысла.
- Речь укладывается в выбранный темп; места пауз отмечены после пробной записи.
- Обложка и слайды читаются в реальном размере окна записи; лицо не перекрыто интерфейсом.
- В записи нет редакторских подсказок, уведомлений, личных данных других приложений или незаполненных ссылок публикации.
- После монтажа субтитры вручную сверены для имён, сокращений и номеров стандартов.
Это производственная памятка. Выполнение пунктов не считается установленным до реальной записи автора.
SHA-256: b1e082537c70ee22a65fa9aebbf5436f412472f8f1ec964dfcb56fb7a8cb9f24
09EP01 — Where Secure Development BeginsEP01-script-en.md
EP01 — Where Secure Development Begins
Full spoken English script. Author: Vitaliy Pikov. Prepared: 2026-09-06.
Target: 53:10, including pauses and slide changes. Timings are rehearsal targets, not a measured recording. Text after Speech: is spoken; metadata and Cue: are not. Visual: and the adjacent image identify the SVG replacing the on-screen list; Items: remain its text alternative. Visual labels and source notes are maintained in EP01-visuals.md.
Working translations of GOST clauses are the author's, not an official English translation.
An introduction to the history of secure development, the two editions of GOST R 56939, and practical process planning. Historical accounts are attributed; requirements refer to the stated editions of the standards.
01 | Where secure development begins
Seconds: 65 Section: Welcome Layout: cover Lead: History, GOST and a working process Items: - EP01 / 25 | Planning secure software development processes Sources: G24 Speech: Hello, and welcome. I'm Vitaliy Pikov. I work with secure software development processes, and I teach the engineering ideas behind them.
This is the first episode of Secure Software Development in Practice. We'll explore twenty-five processes from a Russian national standard, GOST R 56939-2024. And we'll compare them with international approaches.
Our question is simple. What can a development team actually use?
Today we'll do three things. We'll look at the history behind the subject. We'll learn how to read this standard. And we'll build a small example of a security process plan. You do not need previous knowledge of Russian standards. Just bring your own experience: building software, reviewing it, or helping a team deliver it safely. Cue: Улыбка, короткая пауза после вопроса. Не читать цифровой номер слишком быстро.
02 | One process. One useful result.
Seconds: 95 Section: The series Layout: cards Lead: A practical question for every episode Items: - Understand | What problem does the process address? - Compare | Where do international practices overlap or differ? - Apply | What can a team do and verify? Sources: G24 Speech: This series builds on an earlier project. I made a set of Russian-language webinars together with PVS-Studio. For this English series, I want to take that work further. And I want to compare it with international practices in a systematic way.
Each episode will focus on one process. We'll ask three questions. What problem does it address? How do other approaches address a similar problem? And what evidence would show that a team has put the process into practice?
The audience includes developers, AppSec practitioners, and technical leaders. Maybe you write code. Maybe you design a delivery pipeline. Maybe you decide where the team should invest its limited time. Each of those perspectives matters.
I'm also using this project to develop my professional English and to go deeper in my own research. I'll explain new terms. I'll name the sources. And when something needs a correction, I'll say so openly.
By the end of an episode, you should have something useful to discuss with your team. A small checklist. A decision record. Or an example you can adapt to your own work. Cue: Личный мотив произнести спокойно, без извинений за английский. Архивное происхождение подтверждено презентацией 2025 года.
03 | Twenty-five processes, connected
An author's teaching guide to the connections between the 25 processes.
Speech: The standard gives us the structure of the series: twenty-five processes, and twenty-five core episodes. Episode one follows section five point one. Episode twenty-five follows section five point twenty-five.
The four groups on this slide are my teaching guide. They are not additional categories defined by the standard. They help us see how four things connect: planning, engineering, verification, and continued support.
Here's an example. A static analysis result is useful only when we know three things. What code was analysed. Who reviews the findings. And how a correction reaches a release. A dependency list is the same. It is useful only when somebody keeps it current and acts on the changes that matter.
We'll keep coming back to those connections. Some episodes will include a guest who can explain one practice from direct experience. Every core episode will still have its own practical result.
You can follow the whole series. Or pick an episode that matches a problem you have now. Today we set up the vocabulary and a planning example that later episodes can extend. Cue: Показать четыре группы. Уточнение «my teaching guide» важно: это не новая классификация ГОСТ. Визуальная опора: Four connected teaching groups: Organize, Engineer, Verify and Sustain. These are the author's guide to the series, not categories defined by GOST.
04 | Friday's release is blocked
Illustrative case: a finding is useful only when the team can act on it.
Speech: Let's start with a small team. The team is fictional. It develops a C++ tool that imports engineering files. The product also has a small service API. It uses third-party components and ships regular updates.
On Friday afternoon, an analysis tool reports a possible memory error in the file parser. The developer says the finding needs investigation. The security specialist asks if the affected parser is part of the release. The release owner asks if there is time to fix it.
Look at the break between the finding and the investigation. The tool produced information. But the team has not agreed how to use it. The scope is not clear. Nobody set aside time to investigate. And nobody wrote down how the decision is made.
We cannot solve all of that by buying another tool. We need people who understand their responsibilities. We need suitable tools. We need a way of working we can repeat. And we need evidence that connects those elements to the actual product version.
An organization may already use an analyzer, and still need to check what it covers, how it is set up, and what happens after a finding. Before proposing another purchase, find out what the team already does and where the actual gap is.
Keep this team in mind. At the end of the episode, we'll return to Friday's release with a more useful set of questions. Cue: История вымышленная. Не говорить, что это конкретный проект заказчика или реальный инцидент. Визуальная опора: A file reaches the C++ parser, analysis produces a finding, and the path toward investigation and a release decision is interrupted by unclear ownership and capacity.
05 | Three documents before the methodologies
Seconds: 135 Section: Foundations Layout: timeline Lead: Trusted-systems research predates the vendor methodologies by decades Items: - 1970 | Ware report · Security Controls for Computer Systems · RAND R-609 - 1972 | Anderson · Computer Security Technology Planning Study · ESD-TR-73-51 - 1975 | Saltzer and Schroeder · eight design principles · Proceedings of the IEEE - The pattern | Government and academic reports, not vendor programmes Sources: WARE, AND72, SS75 Speech: Our subject is older than the two thousands. Its roots are in government and academic work on trusted systems.
A Defense Science Board task force worked on computer security. Willis Ware chaired it. It finished its report on the eleventh of February, nineteen seventy. The title is Security Controls for Computer Systems. RAND published it, and it was classified confidential. The Defense Advanced Research Projects Agency declassified it on the tenth of October, nineteen seventy-five. RAND then reissued the report for wider distribution.
The covering memo makes a careful claim. It calls this the first attempt to codify the principles and details of the problem.
In October nineteen seventy-two, James Anderson wrote the Computer Security Technology Planning Study. He wrote it for the United States Air Force. The report number is on the slide. It introduced the reference monitor. Anderson names three requirements for the mechanism that implements it. It must be tamper proof. It must always be invoked. And it must be small enough to analyse and test.
Then came Saltzer and Schroeder. In September nineteen seventy-five they published The Protection of Information in Computer Systems. It appeared in Proceedings of the IEEE. The paper lists eight design principles. Least privilege and fail-safe defaults are two of them. We still apply them today.
Look at what these three documents are. They are research and defence reports about building systems you can trust. They are not vendor methodologies. Cue: Произношение: Ware — Уэр, Anderson — Андерсон, Saltzer — Солтцер, Schroeder — Шрёдер. Первоисточники: титул скана даёт «11 FEBRUARY 1970», уведомление — «it is classified CONFIDENTIAL overall», подпись меморандума — Willis H. Ware, Chairman. Предисловие RAND: рассекречивание DARPA 10.10.1975 и переиздание «for wider distribution». ВАЖНО про номер: на слайде R-609 — каноническая ссылка на отчёт 1970 года («was subsequently published as Rand Report R-609»); R-609-1 — переиздание 1979 года, оно уже описано в примечании к источнику WARE. На самом скане R-номера нет нигде — отсутствие номера не повод «вернуть» R-609-1. У Андерсона ловушка: обложка датирована октябрём 1972, а номер ESD-TR-73-51 выглядит как 1973; номер только на слайде, вслух не читать. Три требования (раздел 3.2.2, с.9–10) относятся к reference validation mechanism, сноска 3: «that combination of hardware and software which implements the reference monitor concept» — поэтому вслух «the mechanism that implements it», а не «требования к reference monitor». У Солтцера и Шрёдера дословно «Here are eight examples of design principles that apply particularly to protection mechanisms»; дальше в статье ещё два с оговоркой «apply only imperfectly» — говорим ровно «eight», не «ten». Мировое первенство от своего лица не утверждаем: только формулировка сопроводительного меморандума и описательный вывод в конце слайда.
06 | From evaluating systems to building them
Seconds: 140 Section: Foundations Layout: cards Lead: The assurance question moves from the finished product to the work behind it Items: - 1983 and 1985 | TCSEC, the Orange Book · CSC-STD-001-83, then DoD 5200.28-STD - 1996 | Common Criteria version 1.0 · first ISO/IEC 15408 edition in 1999 - 2002 | Microsoft launches Trustworthy Computing - 2004 | SDL integral at Microsoft · the review's selection window opens Sources: TCSEC, CC21, MSH, MLR Speech: The next stage is about evaluation. How do we judge whether a system deserves trust?
The United States answered with the Trusted Computer System Evaluation Criteria. People call it the Orange Book. The first version is dated the fifteenth of August, nineteen eighty-three. The better known version is the Department of Defense standard. Its date is the twenty-sixth of December, nineteen eighty-five. It replaced the nineteen eighty-three version. Both document numbers are on the slide.
Then the work became international. Canadian, European and American criteria were brought together in the Common Criteria project. Version one point zero was completed in January nineteen ninety-six. ISO approved it in April that year for distribution as a committee draft. The first ISO edition, ISO slash IEC fifteen thousand four hundred eight, followed in nineteen ninety-nine.
Notice what these documents do. They evaluate a product, and they also ask for evidence about how it was built.
In January two thousand two, Microsoft launched its Trustworthy Computing initiative. In two thousand four, the SDL became an integral part of development at Microsoft.
That is where our next slide starts. It uses a twenty twenty-three review. The review gives two dates. The first systematic studies of how to build secure software appeared in two thousand one. From two thousand four onward, organizations began putting security processes into the lifecycle. So two thousand four opens the review's selection window. It does not open the subject. Cue: Обозначения 5200.28-STD и CSC-STD-001-83 только на слайде; вслух — «первая версия 1983 года» и «стандарт Министерства обороны 1985 года». Проверено по самому документу: «Supersedes CSC-STD-001-83, dtd 15 Aug 83» и «December 26, 1985». Издающий орган версии 1983 не называем и «промежуточной» её не называем — не проверено. Common Criteria: январь 1996 и одобрение ISO в апреле 1996 — Annex A.2, пункт 185 части 1 версии 2.1 (август 1999); июнь 1993 (старт CC Project) — пункт 184; более ранние национальные критерии — пункты 181–183 в Annex A.1. Предисловие той же части подтверждает «aligns it with International Standard ISO/IEC 15408:1999» и «CC 2.0 was issued in May, 1998» — версию 2.0 вслух сознательно не даём, слайд и так плотный. ВНИМАНИЕ: страница истории на портале Common Criteria пишет «version 1.0 was issued in 1994» — это расходится с самим документом критериев; слайд не «исправлять». Тезис «they also ask for evidence about how it was built» опирается на разделы Life-Cycle Assurance в TCSEC и на пункт 131 CC («constraints on the rigour of the development process»); при этом пункт 105 прямо говорит, что CC не предписывает методологию разработки, — поэтому вслух только «ask for evidence about», никогда «prescribe how to build». Microsoft: на странице SDL именно «launched its Trustworthy Computing initiative» и «integral part … in 2004» — не говорить «memo» и не говорить «mandatory». Даты 2001 и 2004 — собственная рамка отбора обзора (с.1), а не дата рождения дисциплины.
07 | A landscape of secure development methods
Selected publications and editions from the methodology landscape; the review covers 28 approaches.
Speech: The history of secure development has several parallel approaches. One useful map is the twenty twenty-three review by Arina Kudriavtseva and Olga Gadyatskaya. It examines twenty-eight methodologies. It uses publications from two thousand four to twenty twenty-two. They come from industry, government, and academic research.
Follow the timeline from left to right. We selected six milestones for this slide: publications and editions. First comes early lifecycle research. Then come the SDL, Touchpoints, and CLASP publications. Later examples include guidance for agile development, Singapore's Security-by-Design framework, version two of OWASP SAMM, and NIST's SSDF, version one point one.
These are the dates of the publications or editions we are discussing. They are not all dates when the underlying ideas first appeared. Take Microsoft. It made SDL integral to its development process in two thousand four. But the SDL book discussed in the review appeared in two thousand six.
So the picture is a landscape. It shows different ways to organize secure development. We should examine what each approach contributes. We should not assume that the newest publication replaces every earlier idea. Cue: Все годы на шкале — выбранные публикации/редакции. В локальном PDF Figure 2 и Table II имеют расхождения; наша шкала собрана по Table II с явными подписями. Не переносить рисунок целиком. Визуальная опора: Selected publication and edition milestones: lifecycle research in 2004; SDL, Touchpoints and CLASP publications in 2006; SDL-Agile guidance v5.2 in 2012; Singapore Security-by-Design in 2017; SAMM v2.0 in 2020; SSDF v1.1 in 2022.
08 | Different ways to organize the work
Seconds: 95 Section: The methodology landscape Layout: cards Lead: What the reviewed approaches emphasize Items: - Microsoft SDL | A coordinated engineering programme - Touchpoints | Risk management, architecture and code review - CLASP | Activities connected to roles - SDL-Agile | One-time · every-sprint · bucket activities Sources: MLR Speech: The review helps us look past the names. Each approach gives a team a different way to organize its security work.
Microsoft SDL joins engineering practices with management support and training. Touchpoints, from Gary McGraw, focuses on risk management. That includes architecture analysis and code review. CLASP connects activities to roles. The agile SDL guidance sorts activities into three kinds: done once, repeated in every sprint, or placed in a bucket, a group that comes back on a regular cycle.
That last idea is practical. A team needs a reasoned schedule for security work. Repeating every activity in every sprint is not automatically the best design.
The review also looks at maturity approaches. SAMM helps an organization plan how its capability grows. BSIMM describes practices observed in organizations. Those purposes are different from telling a developer the next task to build.
For our importer team, the shared questions are familiar. Which activity do we need? Who does it? And when? Each approach answers at its own level. We still have to work out what each activity means for our real product and team. Cue: Это характеристика рассмотренных в обзоре редакций, не исчерпывающее описание современных frameworks. Bucket объяснить как группу периодических работ; не как произвольное пропускание проверок.
09 | Before the standard: a practical problem
Seconds: 95 Section: The origins of GOST R 56939 Layout: cards Lead: The practical problem behind the national standard Items: - Around 2009 | Discussions with colleagues and regulators - The engineering gap | Product assessment also needs confidence in development work - The intended result | A common reference usable by different development teams Sources: TRANS, GOSTH Speech: Why did Russia develop a national standard for secure software development? According to Vitaliy Varenitsa, who took part in that work, talks with colleagues and regulators began around two thousand nine. The practical concern was this. Assessing a finished product did not, by itself, explain how security work was organized all the way through development.
The proposed standard would make that work more visible. Developers needed one shared reference. It would name the activities, who is responsible, and what evidence supports a claim that the activities were done.
It was meant to be useful beyond the in-house development method of one large software vendor. Other organizations, including smaller teams, should be able to understand the expectations. Each team should then be able to adapt its implementation to its own products.
These early talks came before any formal drafting. The national standard would be approved several years later.
For our series, the useful question is the problem the authors were trying to solve. How do we turn good security intentions into work that other people can understand and check? Cue: TRANS 00:08:01–00:14:32. Около 2009 — воспоминание участника, не дата утверждённого документа. Не объявлять отсутствие требований во всём мире.
10 | The route from research to publication
From research to an effective standard: different events, different dates.
Speech: Varenitsa dates the start of the research project to April twenty thirteen. It began after the first discussions, once the author team was formed.
The history presentation puts the first draft in August twenty thirteen. More drafts and revisions followed in twenty fourteen and twenty fifteen. It describes a discussion with twenty-two organizations, and around two hundred comments and proposals.
Those numbers describe the consultation reported in the history presentation. They do not mean that twenty-two organizations are named as developers in the final standard.
Rosstandart approved GOST R five six nine three nine, edition twenty sixteen, on the first of June twenty sixteen. The approval came under order four five eight, s t. It became effective on the first of June twenty seventeen.
Keep the four events separate. Research began. Drafts were discussed. The standard was approved. And the standard became effective. The year in a standard's name does not replace that order of events.
This also helps us read later revisions. A working draft can hold valuable ideas without being an adopted edition of the national standard. Cue: TRANS 00:17:33–00:20:19; PDF истории с.4; предисловие ГОСТ 2016 и карточка Росстандарта. В речи не повторять «принят Минюстом» и ошибочный май 2016. Визуальная опора: GOST development milestones: research began in April 2013 and a first draft followed in August; review and revision continued in 2014–2015; Rosstandart approved the standard on 1 June 2016; it became effective on 1 June 2017. Project milestones come from Varenitsa's historical account, while the final two dates are formal publication facts.
11 | Who wrote it, and who was it for?
Seconds: 140 Section: The origins of GOST R 56939 Layout: cards Lead: Formal authorship, consultation and intended users play different roles Items: - 2016 development | NPO Echelon · submitted by Technical Committee 362 - 2024 development | FSTEC of Russia with nine organisations, including Kaspersky, ISP RAS and Positive Technologies · again submitted by Technical Committee 362 - Consultation | Other organizations reviewed and commented on drafts - Primary users | Developers, architects, security specialists and team leaders - Additional users | Independent assessors reviewing implementation evidence Sources: G16, G24, TRANS Speech: The foreword of the twenty sixteen edition names NPO Echelon as the developer. Technical Committee three six two is named as the submitting committee.
The twenty twenty-four edition has a different foreword. It names the Federal Service for Technical and Export Control, FSTEC, together with nine organizations. Among them are Kaspersky, the Institute for System Programming of the Russian Academy of Sciences, Positive Technologies and NPO Echelon. Technical Committee three six two submitted it again. That change is worth a moment. One developer in twenty sixteen. The regulator and a group of product companies in twenty twenty-four.
Varenitsa describes a small author group that prepared the main text. Other organizations reviewed the drafts and raised comments. Writing the document and taking part in its consultation were distinct contributions.
He also stresses the intended audience. The standard was primarily for the people who develop software: architects, programmers, security specialists, and the people who organize their work. Independent assessors were a second audience, because they needed to judge how those practices were put in place.
That's a useful tension in the design. The material has to guide engineering work. It also has to make those results clear to a reviewer outside the team.
Think of our importer example. A procedure should help the developer look into a finding. It should also help a reviewer understand what happened. A document written only to satisfy a filing rule misses much of that practical purpose.
The standard, a team's implementation, and a particular certification scheme are three different things. We should first be clear about the actual assessment context. Then we can discuss which form of confirmation is required. Cue: TRANS 00:19:00–00:24:25, 01:14:03–01:17:27. Формальное авторство — предисловия обеих редакций: 2016 — НПО «Эшелон», 2024 — ФСТЭК России и девять организаций (с.2 стандарта). Не превращать целевую аудиторию в обещание универсальной сертификационной процедуры.
12 | A wider plan than one published document
Seconds: 95 Section: The origins of GOST R 56939 Layout: compare Lead: The original ambition and the published record answer different questions Items: - Original ambition | A family of documents covering several perspectives on development - Published baseline | GOST R 56939-2016, followed by GOST R 56939-2024 - Working material | Recalled drafts and revisions do not establish adopted editions Sources: TRANS, G16, G24 Speech: The original idea went further than a single document.
Varenitsa recalls talks about a family of standards. Together they would cover secure development from several angles, and across the software lifecycle. The number of those documents, and the way they were arranged, changed during discussion. The twenty sixteen standard was the first published result of that wider idea.
The same difference applies to versions. Varenitsa recalls working material from twenty eighteen, twenty nineteen, twenty twenty, and twenty twenty-two. These were steps in ongoing revision work. They were not published national standards with those edition years.
The two adopted editions for this episode are twenty sixteen and twenty twenty-four. For each one, we can point to a final text and an official approval record.
For a development team, here's the practical difference. An adopted requirement is one thing. A proposal that may still change is another. An implementation plan needs to say which published edition it follows. Cue: TRANS 00:09:41–00:11:06, 00:18:19–00:20:19, 00:29:25. Не называть внутренние версии 2018/2019/2020/2022 опубликованными редакциями ГОСТ.
13 | GOST in the international context
Chronology helps test an ancestry claim; similarity alone cannot establish one.
Speech: A national standard can be original and still use international engineering knowledge. These are compatible ideas.
Its design context included Common Criteria, information security management, and software lifecycle standards. The intended result was one common reference, usable by different development organizations.
The twenty sixteen standard itself points to other documents. It links its use to ISO slash IEC twenty-seven thousand thirty-four and to Common Criteria assurance components. It also has an informative appendix with a related mapping.
That does not prove that every practice was new. We have already seen earlier work on secure development. To show a specific borrowing, or a specific difference, we have to compare the relevant documents.
The NIST Secure Software Development Framework gives us a useful check on dates. Its public draft was announced in June twenty nineteen. Final version one point zero came in April twenty twenty. Final version one point one came in February twenty twenty-two.
So the twenty sixteen GOST cannot have been based on those later SSDF publications. At the same time, being earlier than SSDF does not prove that GOST was the first secure development approach in the world. And similarity does not prove influence in the other direction.
Our comparison asks a more useful question. Which engineering concerns are shared? How are obligations organized? And what evidence does each approach expect? That is something we can study process by process. Cue: TRANS 00:10:19–00:14:32; PDF истории с.3/22. NIST: 11.06.2019 draft, 23.04.2020 final1.0, 03.02.2022 final1.1. Не повторять ошибку пересказа «ГОСТ основан на SSDF» и неподтверждённое мировое первенство. Визуальная опора: On a common time axis, GOST R 56939 was approved in 2016; the first public SSDF draft appeared in 2019, final SSDF 1.0 in 2020, and final SSDF 1.1 in 2022. The timeline does not assert ancestry between the documents.
14 | Two editions, different structures
These labels compare the normative force of one term in the original text.
Speech: The two editions organize related engineering work in different ways.
Section five of the twenty sixteen standard has nine groups of measures. Section five of the twenty twenty-four edition has twenty-five named processes. These are different units of organization. Subtracting one number from the other does not tell us how many genuinely new practices appeared, or how much safer a product became.
There's also a concrete change in wording. Look at the Russian verb sleduet. The closest English word is should. Under clause four point two of the twenty sixteen edition, it had recommendation status. Under clause four point seven of the twenty twenty-four edition, the same verb expresses a requirement. Suppose you read an English translation and treat should as advice. Then you will do less than the current edition requires. These labels describe the force of that specific term. An English translation must preserve the force assigned by the relevant edition.
That's why it is risky to reuse an old checklist without reading the new edition. Familiar words can carry different force.
The twenty twenty-four edition was approved on the twenty-fourth of October, by order one five zero four, s t. It became effective on the twentieth of December of the same year. Moving to it needs a gap analysis. Which obligations and evidence are already covered? Which ones need adjustment? And which ones need new work? Practices that already work well are a starting point for that analysis. Cue: Оглавление и п.4.2 ГОСТ2016; оглавление и п.4.7 ГОСТ2024. В записи «14 мер» не совпадает с девятью группами финального оглавления. 2024: утверждён24.10, действует20.12. Английский перевод модальности пояснить по конкретной редакции. Визуальная опора: The 2016 edition has nine groups of measures; clause 4.2 assigns recommendation status to a term that expresses a requirement under clause 4.7 of the 2024 edition. The 2024 edition has 25 named processes. Structural counts do not measure a change in security.
15 | A process continues after the first tool run
A teaching model of repeatable work: actions, decisions and feedback remain connected.
Speech: A process needs more than a new heading. It organizes work that continues over time. It needs clear responsibilities, repeatable actions, and results that inform the next cycle.
Here's a memorable example. A team buys an analysis tool for a short time, just before a release. That may produce a report. It does not automatically establish a maintained process for examining changes, reviewing findings, fixing problems, and checking the result again.
Let's follow the loop for our importer team. A relevant code change triggers the analysis. A named engineer runs the check and reviews the findings. The team records a decision. Then the team reviews what should change before the next cycle. At the centre, the evidence connects the finding and the decision to the product version.
Trigger, ownership, evidence, and feedback give us a practical way to examine a process. The twenty sixteen edition already addressed lifecycle work, internal checks, and improvement.
The practical lesson is simple. A tool becomes useful inside an organized way of working. Planning gives the team the time, people, and agreements to keep that work going. Cue: TRANS 00:49:47–00:51:26 и 01:25:22–01:27:08: позиции собеседников различаются. Четыре вопроса — авторский учебный приём; не приписывать 2016 отсутствие регулярных практик. Визуальная опора: A repeating process connects a trigger, assigned work, a recorded decision and review. Product version and evidence remain at the centre of the cycle.
16 | When this standard actually binds
Seconds: 140 Section: Legal force Layout: cards Lead: A national standard applies voluntarily until another document points at it Items: - Default | Applied voluntarily · the foreword names article 26 of Federal Law 162-FZ of 2015 as the rules of application - Clause 4.14 | Regulatory acts, national and industry standards, technical specifications for research and development work, and other documents define which processes apply - In practice | A regulator's order, a customer contract, a certification scheme, or a company's own decision - Once it binds | Every requirement applies · except those that use the words recommended or may - Clause 4.15 | Research and development work · only an explicit list of processes in the technical specification imposes the standard · partial lists allowed Sources: G24, NS162 Speech: People often ask me one question. Is this standard the law?
No. In Russia a national standard is applied voluntarily, unless the law says otherwise. The foreword of this edition points to the rules of application. They live in article twenty-six of Federal Law one six two, f z, of twenty fifteen. The standard does not make itself binding.
Clause four point fourteen tells us what makes it binding. Here is my working translation. The set of processes a developer must implement is determined by the requirements of regulatory legal acts, national and industry standards, technical specifications for research and development work, and other documents.
So something else has to point at the standard. In practice that is an order from a regulator, a customer contract, a certification scheme, or a company's own decision. The law adds one more trigger. A public claim of conformity binds you too.
The same clause adds one sharp detail. Once a document says you must conform, all the requirements apply. The only exceptions are requirements that use the words recommended or may.
Clause four point fifteen adds a special rule for research and development work. There the standard can bind only through an explicit list of processes in the technical specification. And that list may be partial.
One more point. FSTEC co-developed this edition. That is authorship, not law. A regulator writing a standard does not turn it into a legal duty.
So the useful question is not: is GOST mandatory? The useful question is: what in my situation points at it? Read that way, it is a best-practice baseline. Teams elsewhere use ISO or NIST documents the same way. Cue: П.4.14 и 4.15 ГОСТ Р 56939-2024, предисловие (правила применения — ст.26 ФЗ-162 от 29.06.2015; ч.1 — добровольность «если иное не установлено законодательством», ч.3 — публичное заявление о соответствии). ФСТЭК — соразработчик редакции 2024, не законодатель: не говорить, что ФСТЭК делает стандарт обязательным. Только механизм, без оценок российского регулирования. Пауза после вопроса «Is this standard the law?», затем твёрдое «No». Номер закона читать медленно.
17 | Shared practices need evidence
Seconds: 90 Section: Our comparison method Layout: compare Lead: Findings and limits of the multivocal literature review Items: - Shared practices | Similar engineering work, organized in different ways - Organizational work | Risk, culture, people, policy and communication matter - Effectiveness evidence | Limited and uneven validation of complete methodologies Sources: MLR, N11, N12 Speech: What can we conclude from the literature review? It finds substantial overlap in practices. It also finds organizational concerns, such as risk management, culture, policies, and communication.
The review distinguishes three kinds of work. Work at the level of the organization. Work across the lifecycle. And activities linked to a project stage. So a security programme is more than a list of tools.
Evidence about complete methodologies is limited and uneven. That does not show that secure development fails. It means we have to examine the evaluation method, the context, and the result being measured.
The review selected accessible English-language material. Its omission of GOST cannot establish that the Russian standard is unique.
An expert's experience can reveal useful questions. A broader conclusion still needs evidence about the context, the method, and the result.
We'll compare specific practices and evidence, using named versions. Our NIST baseline is final SSDF one point one. As of September twenty twenty-six, version one point two is still a draft. Let's make the comparison method explicit. Cue: Результат обзора не равен доказательству причинного снижения уязвимостей. Не говорить «доказательств вообще нет» и не интерпретировать авторскую разметку Waterfall/Agile как статистику отрасли.
18 | Compare obligations, not labels
Compare what the documents ask people to do and what would demonstrate the result.
Speech: Here's the method we will use. First, we take one specific requirement or practice. We record who acts, what they do, the scope, and any conditions. Second, we compare the actual work and the expected result.
We also keep the force of the original wording. Clause four point seven of the twenty twenty-four GOST defines which wording expresses a required condition. When we translate such a condition, we must convey a requirement rather than turn it into an optional recommendation. On the international side, we ask what we are reading. Is it framework guidance, a requirement, or an example of implementation? Similar wording does not automatically give two documents the same authority.
Third, we demonstrate one concrete implementation. We also name the records that would let another person verify the result.
Finally, our conclusion may be substantial overlap, partial overlap, or a complementary practice. If we have not found a counterpart, we will state which sources we reviewed.
This lets us study the main question of this series without deciding the answer in advance. A useful comparison can show shared engineering ideas. And it can still show important differences in scope, detail, and expected evidence. Cue: Русские термины объяснить, не превращать в упражнение для зрителя. Слайд даёт метод, не формальную сертификационную оценку. Визуальная опора: The comparison method proceeds from reading actors, actions and conditions, to examining differences, demonstrating an implementation, and stating a bounded conclusion.
19 | What process 5.1 asks for
Five planning requirements connected by their information dependencies.
Speech: Now we can read the first process directly. Section five point one is about planning secure software development processes.
It has five requirements. Periodically analyse the current state of the processes. Periodically analyse resource needs. Develop a plan for improving the processes. Develop a plan for implementing them. And define their scope.
The two plans must take the analyses into account. That connection matters. A plan can look good on paper. But if it ignores what the team does today, or what resources the team has, it may be impossible to carry out.
I use process improvement plan as a working English label for the plan of process development. In a moment we'll see how it differs from the implementation plan.
For our small team, the first step is to describe what already happens and what does not. Then we find the biggest gaps. We estimate the capacity needed to close them. And we assign work the team can really do.
The standard requires periodic analysis, but it does not give us a universal ninety-day schedule. The schedule later in this episode is an illustrative choice for our example.
One caution before we build the plan. The standard also carries an informative appendix A, initialisation of secure development processes. It repeats almost the same steps for a team that is only starting these processes. Analyse the current state. Analyse the resources needed. Write the result down as a plan. Its artifacts are almost word for word the same as the ones in five point one. The difference is status. Under clause four point sixteen, assessment of the appendix A processes is not mandatory during an external audit. Clause five point one is a full process, and it is assessed. So if you are deciding which of these two very similar texts to implement, that difference is what settles it. Cue: Все пять требований на экране. Не объявлять квартал обязательной частотой ГОСТ. Приложение А (справочное) — п.4.16: оценка не обязательна при внешнем аудите, в отличие от 5.1. Визуальная опора: Within the defined scope, current-state analysis and resource analysis support both the process improvement plan and the process implementation plan. The five nodes carry clauses 5.1.2.1 through 5.1.2.5.
20 | Start with a defensible scope
Illustrative scope: record what is included, what is connected and why an exclusion is justified.
Speech: What exactly does the plan cover? In our example, the scope includes version two point zero of the importer, its parser module, the small service API, and the libraries that ship with it.
The repository, the integration configuration, and the release workflow form relevant development context. We record links to them, so the plan connects to actual work.
Suppose the team also has an old prototype. It may sit outside the chosen scope. But the team needs a reason. If code or a dependency from that prototype goes into the release, the boundary needs another look.
The standard's scope artifact lists the parts the software is made of. That means versions, modules, components and functional subsystems. It also gives the reason for that selection. If we name a product but do not name its relevant parts, we leave room for misunderstanding.
This is not permission to declare inconvenient components irrelevant. The rationale must make sense for the product and for the obligations that apply to it. In a teaching example, we can keep the scope small. For a real implementation, the team needs to look at the actual relationships. And it needs to keep the boundary up to date as the product changes. Cue: «Connected context» не смешивать с буквальным составом ПО из 5.1.3.5. Это полезные связанные записи примера. Визуальная опора: Importer 2.0 contains the parser, service API and shipped libraries. Repository, CI configuration and release workflow form connected development context. Excluding a retired prototype requires evidence that it has no code or dependency path into the release.
21 | Assess reality and assign owners
Seconds: 95 Section: Planning secure development Layout: cards Lead: Illustrative findings, with people who can act Items: - Engineering lead | Parser checks run manually; coverage is unclear - AppSec lead | Review findings and agree investigation criteria - Release owner | Record release decisions under the team's policy - Sponsor | Resolve capacity and priority conflicts Sources: G24, EX Speech: Let's start with three questions. What already works? What needs improvement? What is missing? Introducing a standard does not mean rebuilding everything from zero.
The current-state record lists which processes are in place and which are not. It assesses the existing processes against this standard, against other standards that apply, and against the team's tools and technologies.
In our example, parser checks run by hand. Coverage is unclear. The decision history is incomplete. These are fictional findings.
Now we assign responsibilities. The engineering lead owns integration. The AppSec lead helps define investigation criteria and review security evidence. The release owner records decisions under the team's policy. A sponsor resolves conflicts about capacity and priority.
One person may hold several roles. Even then, it must stay clear who is responsible and who decides.
This allocation is our implementation example. The standard's implementation-plan artifact must identify the employees responsible for implementing the processes. It does not automatically give AppSec an independent power to block every release. The organization must define that authority. And it must make the link between investigation, review, and the release decision clear. Cue: Отличать ответственного за действие от того, кто уполномочен принимать остаточный риск.
22 | Resources include human attention
Illustrative total effort for the 90-day plan; validate the estimates with the people doing the work.
Speech: Resource planning includes time. Time to set up the checks. Time to investigate findings. Time to keep the workflow running. And time to teach people how to use it.
Here's our ninety-day effort. It's fictional. We reserve sixty engineering hours, twenty-four AppSec hours, and twelve hours for release coordination and sponsor decisions. The total is ninety-six person-hours.
These figures are a teaching example. They are not a benchmark. They are not a percentage required by GOST. No universal percentage can replace an estimate of the actual work.
Tools, infrastructure, and the cost of extra training need their own assessment. Dependencies matter too. If the build engineer is not available during the first month, the schedule must show that. Assigning a task does not create capacity.
The standard's resource-analysis record may include an estimate of the material and human resources the work will need. The chart makes those assumptions open to discussion. Ask the people doing the work if the estimate is realistic. Show it to the people who set priorities. Agree when to update it. Human attention is part of the resource plan. Cue: Сделать паузу на сумме 96. Часы для всего учебного плана, не недельная нагрузка. Визуальная опора: An illustrative 90-day effort allocates 60 person-hours to engineering, 24 to AppSec, and 12 to release coordination and sponsor decisions, for a total of 96 person-hours. Tools and infrastructure are assessed separately.
23 | Two plans, two questions
Connect the capability in the improvement plan to executable work and its evidence.
Speech: Planning gives everyone a shared language: the team, its managers, and the people who ask for the product. Two related plans help them agree on the direction and the work.
The improvement plan describes how processes will develop. It sets priorities and the order of changes. It takes available resources into account. Our team might make parser analysis repeatable, improve the handling of findings, and then review the results.
The implementation plan identifies goals, stages, dates, resources, and responsible people. In the middle of the diagram, one task names the parser target, the integration milestone and the owner. On the right, the evidence records coverage and the review of findings.
The standard allows these plans to be represented in a task management system. A roadmap with linked tasks can keep their different purposes clear, and avoid documents that sit apart from the work.
Here's the practical test: traceability. Why was this change chosen? Which resource assumption supports it? Who does the work? What shows that a stage is finished? A planning page becomes useful when the team can follow those links and act on them. Cue: Не говорить, что стандарт требует два отдельных файла или конкретный формат Jira. Визуальная опора: A process improvement goal, repeatable parser checks, is linked to an implementation task with an owner and milestone, and then to evidence of coverage and triage decisions. Current-state and resource analysis support the entire chain.
24 | A 90-day plan for the importer
A 90-day example for the importer: each stage produces something the team can review.
Speech: Let's put those parts together in a ninety-day example. The product is the engineering-file importer. Our first goal is to handle findings from parser analysis the same way every time, and to make that work easy to review.
In days one to thirty, the team confirms the software scope. It writes down the current state. It reviews the resource estimate. It names the owner of each planned action, and the person responsible for the release decision. The result is a small baseline that anyone can look at.
In days thirty-one to sixty, the engineer connects the chosen parser checks to continuous integration. The team writes down which source targets and configurations are covered. Every finding gets a review record, and the release workflow links to that record.
In days sixty-one to ninety, the team looks at evidence from two example release cycles. Did the checks run on the intended versions? Did every finding get a decision? Was the agreed capacity enough? The answers shape the next improvement plan.
The ninety-day period, the two releases, and the detailed tasks are our choices. They do not come from the standard. And finishing this example does not establish conformity with every process in the document.
For implementation of this GOST, section four point thirteen requires the following in the development environment. Version control. Continuous integration. And task management, including defect tracking. It does not say continuous deployment. That difference is useful when we explain our pipeline choices. Cue: Здесь главная практическая пауза: провести взглядом по трём этапам. Не уходить в live demo настройки анализатора. Визуальная опора: The illustrative plan has three equal 30-day periods: establish scope, baseline and ownership; integrate parser checks and record decisions; then review two release cycles, close gaps and update the next plan.
25 | Five linked records of evidence
The same planning structure, now expressed as records a reviewer can follow.
Speech: The standard names five matching kinds of evidence. Current-state analysis. Resource analysis. The improvement plan. The implementation plan. And the scope, with the reasons for choosing it.
These are five kinds of information, not an instruction to create five separate Word files. Existing systems can carry this work. A planning page can link to repository and task records you already keep.
In our example, the scope names the importer version and components. The baseline links to the checks that ran. The resource record holds estimates and assumptions. The improvement plan explains priorities. The implementation tasks name owners and milestones.
The standard recognizes forms such as electronic files, logs, and tool results. Choose a form that carries the required information and keeps it traceable.
A one-page template is only an entry point. It does not replace the analysis behind it, and it does not prove effectiveness. A reviewer should be able to follow the links. They should find the right version, understand the decisions, and see which questions are still open. Automation helps when it keeps those connections. Cue: На слайде артефакты 5.1.3.1–5; подробный шаблон приложен Markdown. Не обещать «одной страницы достаточно для соответствия». Визуальная опора: Five evidence categories mirror the planning requirements: baseline checks and gaps, resource estimates and assumptions, improvement priorities, implementation owners and milestones, and the importer scope with its rationale.
26 | Every process is written the same way
Seconds: 150 Section: Worked example Layout: cards Lead: One shape for all 25 processes: name, goals, requirements, artifacts Items: - Name · 5.1 | Planning secure software development processes - Goals · 5.1.1 | What the process is for · 5.1.1.1 to 5.1.1.3 - Requirements · 5.1.2 | What to do · 5.1.2.1 to 5.1.2.5 - Artifacts · 5.1.3 | What to show afterwards · 5.1.3.1 to 5.1.3.5 - In every episode | Goals to understand · then compare · requirements and artifacts to apply Sources: G24 Speech: Before the crosswalk, here is your reading key for the other twenty-four episodes.
Clause four point eight says every process has the same four parts. The name of the process. Its goals. Its implementation requirements. And its artifacts of requirement implementation. I will say artifacts, or evidence.
The numbering follows that shape. Five point one is the name: planning secure software development processes. Goals come first, then requirements, then artifacts. You saw the five requirements earlier, and the five records a moment ago.
So open any process and read it in that order. What is the work for? What must we do? What must we be able to show afterwards?
Two details help with the artifacts. Clause four point eleven keeps the form open. An artifact is any information, in any form, that lets someone confirm the requirement was met. A document, a report, a file, a log, the result of a tool or a process. Then read the verb. Here, four of the five records must contain the listed information. For the resource analysis, the verb is may.
In most of the later processes, the first artifact is what the standard calls a reglament. In English, a written procedure. As a rule, it must cover two things. The duties and roles of the staff, and the details of how the process is carried out. The standard sets no format for it.
This shape also gives us the plan for every episode. Goals answer our first question: what problem does the process address? Requirements and artifacts answer the third: what can a team do and verify? The second question, the comparison, is where we go next. Cue: Ключ к чтению всех 25 процессов. П.4.8 — структура; 4.11 — что считается артефактом; 4.12 — регламент: «в общем случае» обязанности и роли сотрудников плюс сведения об особенностях реализации процесса, формат не задан. Точное число процессов с регламентом вслух не называть. 5.1.3.2 — «могут содержать», остальные четыре — «должны/должен/должно содержать». Ссылки назад: требования были на слайде про 5.1, записи — на предыдущем.
27 | A first international crosswalk
Bounded comparison: a shared concern is useful, but does not establish full equivalence.
Speech: Let's make a small comparison, with clear limits. In GOST, the implementation-plan artifact identifies the employees responsible for implementing the processes. NIST SSDF task P O two point one covers roles and responsibilities for secure software development. There is a useful shared concern. People need to know which work belongs to them.
But the comparison is partial. The GOST artifact also includes goals, timing, stages, and resources. That single SSDF task does not by itself reproduce the complete artifact.
Now look at process improvement. In OWASP SAMM, the Strategy and Metrics practice gives us a useful link. It focuses on an improvement strategy and a roadmap. Again, we need to examine the details, and the purpose of the model, before we claim equivalence.
These comparisons help us read the first process in a wider engineering context. They do not establish that following one document automatically satisfies the other.
So our first conclusion is a modest one. Planning, responsibility, and improvement have international counterparts we can recognize. But the exact structure, the wording, and the expected evidence still need to be examined, requirement by requirement. The notes with this episode keep those limits and the source versions. Cue: PO.2.1 произнести «P O, two point one». Сопоставлены узкие положения, не все пять требований полностью. Визуальная опора: Two partial overlaps are shown: GOST 5.1.3.4 and NIST SSDF PO.2.1 share a concern with roles and responsibility; GOST 5.1.2.3 and SAMM Strategy and Metrics share a concern with an improvement roadmap. Scope and evidence expectations still differ.
28 | Would this survive Friday's release?
Return to Friday's release: can the team follow the finding through an owned, evidenced decision?
Speech: Let's go back to Friday's warning. A plan will not tell us by itself whether that warning is a real vulnerability. The plan helps organize the investigation and the decision.
We can name the affected version and component. We can find the owner of the investigation, and the person authorized to make the release decision. And we can see what evidence we have, and which results are missing.
Weak planning is easy to spot too. An analyzer with no review owner is incomplete. A roadmap with no capacity is unreliable. A scope with no rationale is hard to defend.
For this team, I would review the plan after ninety days, and after a material change, such as adding a parser. These are our own recommendations for implementation.
In a small team, one person may hold several responsibilities. Make the arrangement explicit, and check the capacity. Scaling the implementation does not establish that applicable requirements can be ignored.
Here is the practical test. Can another team member understand the next action? If only the author can explain the plan, then improve it. Cue: Провести зрителя по пяти узлам: input file → parser → finding → investigate → decide. Сделать короткую паузу на связи расследования с решением о выпуске. Период и триггеры пересмотра — авторский пример. Визуальная опора: The importer scenario returns with a connected path: identify the input and covered parser, retain the finding evidence, assign time and ownership for investigation, and record a release decision under the team's policy. This is a review of the process, not proof that a release is safe.
29 | Security Training That Changes Engineering Decisions
Seconds: 115 Section: Stay in touch · Next episode Layout: closing Lead: Next: EP02 · Employee training · GOST R 56939-2024, clause 5.2 Contact: Vitaliy Pikov | pikov.art | https://pikov.art Channels: - LinkedIn | in/vitaliy-pikov | https://www.linkedin.com/in/vitaliy-pikov/ - Email | vitaly@pikov.expert | mailto:vitaly@pikov.expert - Telegram | UnderLineSecurity | https://t.me/UnderLineSecurity Items: - Roles & skills | What each person needs to learn - Practical learning | A short exercise before and after training - Evidence of progress | Look beyond attendance to demonstrated skills Sources: G24, EX Speech: Today we followed the Russian standard from the early discussions to the editions that were adopted. We connected that history to international work. And we used its first process to organize a practical improvement effort.
Your next step is simple. Choose one product, and start your planning page. Describe the current state. Name the next improvement. Then connect it to an owner, to the capacity you have, and to evidence someone can review. The worksheet with this episode will help you start.
I am Vitaliy Pikov. You can find me at pikov dot expert, and on LinkedIn. My email and my Telegram channel are on the slide. Please keep in touch, and share the questions you would like this series to explore.
The next episode is called Security Training That Changes Engineering Decisions. We'll look at employee training under clause five point two. What do different roles need to learn? How do we practise those skills? And what evidence can show progress beyond attendance?
We'll build a role and skills matrix, and use a short exercise before and after the training. So, which engineering decision would you most like your security training to improve? Thank you for watching. See you in episode two. Cue: Произнести «pikov dot expert», выдержать паузу у адреса. Ссылки на LinkedIn, почту и Telegram — на слайде, вслух их не читать. Название EP02 прочитать полностью. В конце оставить слайд с контактом и анонсом на несколько секунд; дата выпуска пока не объявлена.
Исходный Markdown целиком
# EP01 — Where Secure Development Begins
Full spoken English script. Author: Vitaliy Pikov. Prepared: 2026-09-06.
Target: 53:10, including pauses and slide changes. Timings are rehearsal targets, not a measured recording. Text after `Speech:` is spoken; metadata and `Cue:` are not. `Visual:` and the adjacent image identify the SVG replacing the on-screen list; `Items:` remain its text alternative. Visual labels and source notes are maintained in [EP01-visuals.md](EP01-visuals.md).
Working translations of GOST clauses are the author's, not an official English translation.
An introduction to the history of secure development, the two editions of GOST R 56939, and practical process planning. Historical accounts are attributed; requirements refer to the stated editions of the standards.
## 01 | Where secure development begins
Seconds: 65
Section: Welcome
Layout: cover
Lead: History, GOST and a working process
Items:
- EP01 / 25 | Planning secure software development processes
Sources: G24
Speech:
Hello, and welcome. I'm Vitaliy Pikov. I work with secure software development processes, and I teach the engineering ideas behind them.
This is the first episode of Secure Software Development in Practice. We'll explore twenty-five processes from a Russian national standard, GOST R 56939-2024. And we'll compare them with international approaches.
Our question is simple. What can a development team actually use?
Today we'll do three things. We'll look at the history behind the subject. We'll learn how to read this standard. And we'll build a small example of a security process plan. You do not need previous knowledge of Russian standards. Just bring your own experience: building software, reviewing it, or helping a team deliver it safely.
Cue: Улыбка, короткая пауза после вопроса. Не читать цифровой номер слишком быстро.
## 02 | One process. One useful result.
Seconds: 95
Section: The series
Layout: cards
Lead: A practical question for every episode
Items:
- Understand | What problem does the process address?
- Compare | Where do international practices overlap or differ?
- Apply | What can a team do and verify?
Sources: G24
Speech:
This series builds on an earlier project. I made a set of Russian-language webinars together with PVS-Studio. For this English series, I want to take that work further. And I want to compare it with international practices in a systematic way.
Each episode will focus on one process. We'll ask three questions. What problem does it address? How do other approaches address a similar problem? And what evidence would show that a team has put the process into practice?
The audience includes developers, AppSec practitioners, and technical leaders. Maybe you write code. Maybe you design a delivery pipeline. Maybe you decide where the team should invest its limited time. Each of those perspectives matters.
I'm also using this project to develop my professional English and to go deeper in my own research. I'll explain new terms. I'll name the sources. And when something needs a correction, I'll say so openly.
By the end of an episode, you should have something useful to discuss with your team. A small checklist. A decision record. Or an example you can adapt to your own work.
Cue: Личный мотив произнести спокойно, без извинений за английский. Архивное происхождение подтверждено презентацией 2025 года.
## 03 | Twenty-five processes, connected
Seconds: 95
Section: The series
Layout: steps
Visual: slide-03
Lead: EP01 ↔ clause 5.1 · EP25 ↔ clause 5.25
Items:
- Organize | Plan the work, develop skills and assign responsibility
- Engineer | Address threats, design, code, dependencies and builds
- Verify | Review, analyse and test
- Sustain | Deliver updates, handle weaknesses and improve
Sources: G24
*An author's teaching guide to the connections between the 25 processes.*
Speech:
The standard gives us the structure of the series: twenty-five processes, and twenty-five core episodes. Episode one follows section five point one. Episode twenty-five follows section five point twenty-five.
The four groups on this slide are my teaching guide. They are not additional categories defined by the standard. They help us see how four things connect: planning, engineering, verification, and continued support.
Here's an example. A static analysis result is useful only when we know three things. What code was analysed. Who reviews the findings. And how a correction reaches a release. A dependency list is the same. It is useful only when somebody keeps it current and acts on the changes that matter.
We'll keep coming back to those connections. Some episodes will include a guest who can explain one practice from direct experience. Every core episode will still have its own practical result.
You can follow the whole series. Or pick an episode that matches a problem you have now. Today we set up the vocabulary and a planning example that later episodes can extend.
Cue: Показать четыре группы. Уточнение «my teaching guide» важно: это не новая классификация ГОСТ. Визуальная опора: Four connected teaching groups: Organize, Engineer, Verify and Sustain. These are the author's guide to the series, not categories defined by GOST.
## 04 | Friday's release is blocked
Seconds: 120
Section: The engineering problem
Layout: cards
Visual: slide-04
Lead: Illustrative case · a C++ engineering-file importer
Items:
- A warning | A parser issue appears just before release
- A gap | Nobody agreed who investigates it
- A decision | The release owner lacks reliable evidence
Sources: EX
*Illustrative case: a finding is useful only when the team can act on it.*
Speech:
Let's start with a small team. The team is fictional. It develops a C++ tool that imports engineering files. The product also has a small service API. It uses third-party components and ships regular updates.
On Friday afternoon, an analysis tool reports a possible memory error in the file parser. The developer says the finding needs investigation. The security specialist asks if the affected parser is part of the release. The release owner asks if there is time to fix it.
Look at the break between the finding and the investigation. The tool produced information. But the team has not agreed how to use it. The scope is not clear. Nobody set aside time to investigate. And nobody wrote down how the decision is made.
We cannot solve all of that by buying another tool. We need people who understand their responsibilities. We need suitable tools. We need a way of working we can repeat. And we need evidence that connects those elements to the actual product version.
An organization may already use an analyzer, and still need to check what it covers, how it is set up, and what happens after a finding. Before proposing another purchase, find out what the team already does and where the actual gap is.
Keep this team in mind. At the end of the episode, we'll return to Friday's release with a more useful set of questions.
Cue: История вымышленная. Не говорить, что это конкретный проект заказчика или реальный инцидент. Визуальная опора: A file reaches the C++ parser, analysis produces a finding, and the path toward investigation and a release decision is interrupted by unclear ownership and capacity.
## 05 | Three documents before the methodologies
Seconds: 135
Section: Foundations
Layout: timeline
Lead: Trusted-systems research predates the vendor methodologies by decades
Items:
- 1970 | Ware report · Security Controls for Computer Systems · RAND R-609
- 1972 | Anderson · Computer Security Technology Planning Study · ESD-TR-73-51
- 1975 | Saltzer and Schroeder · eight design principles · Proceedings of the IEEE
- The pattern | Government and academic reports, not vendor programmes
Sources: WARE, AND72, SS75
Speech:
Our subject is older than the two thousands. Its roots are in government and academic work on trusted systems.
A Defense Science Board task force worked on computer security. Willis Ware chaired it. It finished its report on the eleventh of February, nineteen seventy. The title is Security Controls for Computer Systems. RAND published it, and it was classified confidential. The Defense Advanced Research Projects Agency declassified it on the tenth of October, nineteen seventy-five. RAND then reissued the report for wider distribution.
The covering memo makes a careful claim. It calls this the first attempt to codify the principles and details of the problem.
In October nineteen seventy-two, James Anderson wrote the Computer Security Technology Planning Study. He wrote it for the United States Air Force. The report number is on the slide. It introduced the reference monitor. Anderson names three requirements for the mechanism that implements it. It must be tamper proof. It must always be invoked. And it must be small enough to analyse and test.
Then came Saltzer and Schroeder. In September nineteen seventy-five they published The Protection of Information in Computer Systems. It appeared in Proceedings of the IEEE. The paper lists eight design principles. Least privilege and fail-safe defaults are two of them. We still apply them today.
Look at what these three documents are. They are research and defence reports about building systems you can trust. They are not vendor methodologies.
Cue: Произношение: Ware — Уэр, Anderson — Андерсон, Saltzer — Солтцер, Schroeder — Шрёдер. Первоисточники: титул скана даёт «11 FEBRUARY 1970», уведомление — «it is classified CONFIDENTIAL overall», подпись меморандума — Willis H. Ware, Chairman. Предисловие RAND: рассекречивание DARPA 10.10.1975 и переиздание «for wider distribution». ВАЖНО про номер: на слайде R-609 — каноническая ссылка на отчёт 1970 года («was subsequently published as Rand Report R-609»); R-609-1 — переиздание 1979 года, оно уже описано в примечании к источнику WARE. На самом скане R-номера нет нигде — отсутствие номера не повод «вернуть» R-609-1. У Андерсона ловушка: обложка датирована октябрём 1972, а номер ESD-TR-73-51 выглядит как 1973; номер только на слайде, вслух не читать. Три требования (раздел 3.2.2, с.9–10) относятся к reference validation mechanism, сноска 3: «that combination of hardware and software which implements the reference monitor concept» — поэтому вслух «the mechanism that implements it», а не «требования к reference monitor». У Солтцера и Шрёдера дословно «Here are eight examples of design principles that apply particularly to protection mechanisms»; дальше в статье ещё два с оговоркой «apply only imperfectly» — говорим ровно «eight», не «ten». Мировое первенство от своего лица не утверждаем: только формулировка сопроводительного меморандума и описательный вывод в конце слайда.
## 06 | From evaluating systems to building them
Seconds: 140
Section: Foundations
Layout: cards
Lead: The assurance question moves from the finished product to the work behind it
Items:
- 1983 and 1985 | TCSEC, the Orange Book · CSC-STD-001-83, then DoD 5200.28-STD
- 1996 | Common Criteria version 1.0 · first ISO/IEC 15408 edition in 1999
- 2002 | Microsoft launches Trustworthy Computing
- 2004 | SDL integral at Microsoft · the review's selection window opens
Sources: TCSEC, CC21, MSH, MLR
Speech:
The next stage is about evaluation. How do we judge whether a system deserves trust?
The United States answered with the Trusted Computer System Evaluation Criteria. People call it the Orange Book. The first version is dated the fifteenth of August, nineteen eighty-three. The better known version is the Department of Defense standard. Its date is the twenty-sixth of December, nineteen eighty-five. It replaced the nineteen eighty-three version. Both document numbers are on the slide.
Then the work became international. Canadian, European and American criteria were brought together in the Common Criteria project. Version one point zero was completed in January nineteen ninety-six. ISO approved it in April that year for distribution as a committee draft. The first ISO edition, ISO slash IEC fifteen thousand four hundred eight, followed in nineteen ninety-nine.
Notice what these documents do. They evaluate a product, and they also ask for evidence about how it was built.
In January two thousand two, Microsoft launched its Trustworthy Computing initiative. In two thousand four, the SDL became an integral part of development at Microsoft.
That is where our next slide starts. It uses a twenty twenty-three review. The review gives two dates. The first systematic studies of how to build secure software appeared in two thousand one. From two thousand four onward, organizations began putting security processes into the lifecycle. So two thousand four opens the review's selection window. It does not open the subject.
Cue: Обозначения 5200.28-STD и CSC-STD-001-83 только на слайде; вслух — «первая версия 1983 года» и «стандарт Министерства обороны 1985 года». Проверено по самому документу: «Supersedes CSC-STD-001-83, dtd 15 Aug 83» и «December 26, 1985». Издающий орган версии 1983 не называем и «промежуточной» её не называем — не проверено. Common Criteria: январь 1996 и одобрение ISO в апреле 1996 — Annex A.2, пункт 185 части 1 версии 2.1 (август 1999); июнь 1993 (старт CC Project) — пункт 184; более ранние национальные критерии — пункты 181–183 в Annex A.1. Предисловие той же части подтверждает «aligns it with International Standard ISO/IEC 15408:1999» и «CC 2.0 was issued in May, 1998» — версию 2.0 вслух сознательно не даём, слайд и так плотный. ВНИМАНИЕ: страница истории на портале Common Criteria пишет «version 1.0 was issued in 1994» — это расходится с самим документом критериев; слайд не «исправлять». Тезис «they also ask for evidence about how it was built» опирается на разделы Life-Cycle Assurance в TCSEC и на пункт 131 CC («constraints on the rigour of the development process»); при этом пункт 105 прямо говорит, что CC не предписывает методологию разработки, — поэтому вслух только «ask for evidence about», никогда «prescribe how to build». Microsoft: на странице SDL именно «launched its Trustworthy Computing initiative» и «integral part … in 2004» — не говорить «memo» и не говорить «mandatory». Даты 2001 и 2004 — собственная рамка отбора обзора (с.1), а не дата рождения дисциплины.
## 07 | A landscape of secure development methods
Seconds: 105
Section: The methodology landscape
Layout: timeline
Visual: slide-05
Lead: Selected publication / edition dates in a 28-methodology review
Items:
- 2004 | Lifecycle research · Jones and Rastogi
- 2006 | SDL · Touchpoints · CLASP
- 2012 | Microsoft SDL guidance v5.2 / SDL-Agile
- 2017 | Singapore Security-by-Design framework
- 2020 | OWASP SAMM v2.0
- 2022 | NIST SSDF v1.1
Sources: MLR, MSH, SAMM20, N11
*Selected publications and editions from the methodology landscape; the review covers 28 approaches.*
Speech:
The history of secure development has several parallel approaches. One useful map is the twenty twenty-three review by Arina Kudriavtseva and Olga Gadyatskaya. It examines twenty-eight methodologies. It uses publications from two thousand four to twenty twenty-two. They come from industry, government, and academic research.
Follow the timeline from left to right. We selected six milestones for this slide: publications and editions. First comes early lifecycle research. Then come the SDL, Touchpoints, and CLASP publications. Later examples include guidance for agile development, Singapore's Security-by-Design framework, version two of OWASP SAMM, and NIST's SSDF, version one point one.
These are the dates of the publications or editions we are discussing. They are not all dates when the underlying ideas first appeared. Take Microsoft. It made SDL integral to its development process in two thousand four. But the SDL book discussed in the review appeared in two thousand six.
So the picture is a landscape. It shows different ways to organize secure development. We should examine what each approach contributes. We should not assume that the newest publication replaces every earlier idea.
Cue: Все годы на шкале — выбранные публикации/редакции. В локальном PDF Figure 2 и Table II имеют расхождения; наша шкала собрана по Table II с явными подписями. Не переносить рисунок целиком. Визуальная опора: Selected publication and edition milestones: lifecycle research in 2004; SDL, Touchpoints and CLASP publications in 2006; SDL-Agile guidance v5.2 in 2012; Singapore Security-by-Design in 2017; SAMM v2.0 in 2020; SSDF v1.1 in 2022.
## 08 | Different ways to organize the work
Seconds: 95
Section: The methodology landscape
Layout: cards
Lead: What the reviewed approaches emphasize
Items:
- Microsoft SDL | A coordinated engineering programme
- Touchpoints | Risk management, architecture and code review
- CLASP | Activities connected to roles
- SDL-Agile | One-time · every-sprint · bucket activities
Sources: MLR
Speech:
The review helps us look past the names. Each approach gives a team a different way to organize its security work.
Microsoft SDL joins engineering practices with management support and training. Touchpoints, from Gary McGraw, focuses on risk management. That includes architecture analysis and code review. CLASP connects activities to roles. The agile SDL guidance sorts activities into three kinds: done once, repeated in every sprint, or placed in a bucket, a group that comes back on a regular cycle.
That last idea is practical. A team needs a reasoned schedule for security work. Repeating every activity in every sprint is not automatically the best design.
The review also looks at maturity approaches. SAMM helps an organization plan how its capability grows. BSIMM describes practices observed in organizations. Those purposes are different from telling a developer the next task to build.
For our importer team, the shared questions are familiar. Which activity do we need? Who does it? And when? Each approach answers at its own level. We still have to work out what each activity means for our real product and team.
Cue: Это характеристика рассмотренных в обзоре редакций, не исчерпывающее описание современных frameworks. Bucket объяснить как группу периодических работ; не как произвольное пропускание проверок.
## 09 | Before the standard: a practical problem
Seconds: 95
Section: The origins of GOST R 56939
Layout: cards
Lead: The practical problem behind the national standard
Items:
- Around 2009 | Discussions with colleagues and regulators
- The engineering gap | Product assessment also needs confidence in development work
- The intended result | A common reference usable by different development teams
Sources: TRANS, GOSTH
Speech:
Why did Russia develop a national standard for secure software development? According to Vitaliy Varenitsa, who took part in that work, talks with colleagues and regulators began around two thousand nine. The practical concern was this. Assessing a finished product did not, by itself, explain how security work was organized all the way through development.
The proposed standard would make that work more visible. Developers needed one shared reference. It would name the activities, who is responsible, and what evidence supports a claim that the activities were done.
It was meant to be useful beyond the in-house development method of one large software vendor. Other organizations, including smaller teams, should be able to understand the expectations. Each team should then be able to adapt its implementation to its own products.
These early talks came before any formal drafting. The national standard would be approved several years later.
For our series, the useful question is the problem the authors were trying to solve. How do we turn good security intentions into work that other people can understand and check?
Cue: TRANS 00:08:01–00:14:32. Около 2009 — воспоминание участника, не дата утверждённого документа. Не объявлять отсутствие требований во всём мире.
## 10 | The route from research to publication
Seconds: 105
Section: The origins of GOST R 56939
Layout: timeline
Visual: slide-08
Lead: Research start, working drafts, approval and effective date are distinct events
Items:
- 2013 | April: research project starts · August: first draft
- 2014–2015 | Draft review and revision
- 2016 | Approved 1 June · Rosstandart order 458-st
- 2017 | Effective from 1 June
Sources: TRANS, GOSTH, G16
*From research to an effective standard: different events, different dates.*
Speech:
Varenitsa dates the start of the research project to April twenty thirteen. It began after the first discussions, once the author team was formed.
The history presentation puts the first draft in August twenty thirteen. More drafts and revisions followed in twenty fourteen and twenty fifteen. It describes a discussion with twenty-two organizations, and around two hundred comments and proposals.
Those numbers describe the consultation reported in the history presentation. They do not mean that twenty-two organizations are named as developers in the final standard.
Rosstandart approved GOST R five six nine three nine, edition twenty sixteen, on the first of June twenty sixteen. The approval came under order four five eight, s t. It became effective on the first of June twenty seventeen.
Keep the four events separate. Research began. Drafts were discussed. The standard was approved. And the standard became effective. The year in a standard's name does not replace that order of events.
This also helps us read later revisions. A working draft can hold valuable ideas without being an adopted edition of the national standard.
Cue: TRANS 00:17:33–00:20:19; PDF истории с.4; предисловие ГОСТ 2016 и карточка Росстандарта. В речи не повторять «принят Минюстом» и ошибочный май 2016. Визуальная опора: GOST development milestones: research began in April 2013 and a first draft followed in August; review and revision continued in 2014–2015; Rosstandart approved the standard on 1 June 2016; it became effective on 1 June 2017. Project milestones come from Varenitsa's historical account, while the final two dates are formal publication facts.
## 11 | Who wrote it, and who was it for?
Seconds: 140
Section: The origins of GOST R 56939
Layout: cards
Lead: Formal authorship, consultation and intended users play different roles
Items:
- 2016 development | NPO Echelon · submitted by Technical Committee 362
- 2024 development | FSTEC of Russia with nine organisations, including Kaspersky, ISP RAS and Positive Technologies · again submitted by Technical Committee 362
- Consultation | Other organizations reviewed and commented on drafts
- Primary users | Developers, architects, security specialists and team leaders
- Additional users | Independent assessors reviewing implementation evidence
Sources: G16, G24, TRANS
Speech:
The foreword of the twenty sixteen edition names NPO Echelon as the developer. Technical Committee three six two is named as the submitting committee.
The twenty twenty-four edition has a different foreword. It names the Federal Service for Technical and Export Control, FSTEC, together with nine organizations. Among them are Kaspersky, the Institute for System Programming of the Russian Academy of Sciences, Positive Technologies and NPO Echelon. Technical Committee three six two submitted it again. That change is worth a moment. One developer in twenty sixteen. The regulator and a group of product companies in twenty twenty-four.
Varenitsa describes a small author group that prepared the main text. Other organizations reviewed the drafts and raised comments. Writing the document and taking part in its consultation were distinct contributions.
He also stresses the intended audience. The standard was primarily for the people who develop software: architects, programmers, security specialists, and the people who organize their work. Independent assessors were a second audience, because they needed to judge how those practices were put in place.
That's a useful tension in the design. The material has to guide engineering work. It also has to make those results clear to a reviewer outside the team.
Think of our importer example. A procedure should help the developer look into a finding. It should also help a reviewer understand what happened. A document written only to satisfy a filing rule misses much of that practical purpose.
The standard, a team's implementation, and a particular certification scheme are three different things. We should first be clear about the actual assessment context. Then we can discuss which form of confirmation is required.
Cue: TRANS 00:19:00–00:24:25, 01:14:03–01:17:27. Формальное авторство — предисловия обеих редакций: 2016 — НПО «Эшелон», 2024 — ФСТЭК России и девять организаций (с.2 стандарта). Не превращать целевую аудиторию в обещание универсальной сертификационной процедуры.
## 12 | A wider plan than one published document
Seconds: 95
Section: The origins of GOST R 56939
Layout: compare
Lead: The original ambition and the published record answer different questions
Items:
- Original ambition | A family of documents covering several perspectives on development
- Published baseline | GOST R 56939-2016, followed by GOST R 56939-2024
- Working material | Recalled drafts and revisions do not establish adopted editions
Sources: TRANS, G16, G24
Speech:
The original idea went further than a single document.
Varenitsa recalls talks about a family of standards. Together they would cover secure development from several angles, and across the software lifecycle. The number of those documents, and the way they were arranged, changed during discussion. The twenty sixteen standard was the first published result of that wider idea.
The same difference applies to versions. Varenitsa recalls working material from twenty eighteen, twenty nineteen, twenty twenty, and twenty twenty-two. These were steps in ongoing revision work. They were not published national standards with those edition years.
The two adopted editions for this episode are twenty sixteen and twenty twenty-four. For each one, we can point to a final text and an official approval record.
For a development team, here's the practical difference. An adopted requirement is one thing. A proposal that may still change is another. An implementation plan needs to say which published edition it follows.
Cue: TRANS 00:09:41–00:11:06, 00:18:19–00:20:19, 00:29:25. Не называть внутренние версии 2018/2019/2020/2022 опубликованными редакциями ГОСТ.
## 13 | GOST in the international context
Seconds: 125
Section: The origins of GOST R 56939
Layout: compare
Visual: slide-11
Lead: Earlier international work informed the context; chronology limits ancestry claims
Items:
- Design context | Common Criteria · ISO/IEC 27034 · lifecycle standards
- GOST R 56939 | Approved in 2016
- NIST SSDF | Public draft 2019 · final 1.0 in 2020 · final 1.1 in 2022
Sources: TRANS, GOSTH, G16, N19, N20, N11
*Chronology helps test an ancestry claim; similarity alone cannot establish one.*
Speech:
A national standard can be original and still use international engineering knowledge. These are compatible ideas.
Its design context included Common Criteria, information security management, and software lifecycle standards. The intended result was one common reference, usable by different development organizations.
The twenty sixteen standard itself points to other documents. It links its use to ISO slash IEC twenty-seven thousand thirty-four and to Common Criteria assurance components. It also has an informative appendix with a related mapping.
That does not prove that every practice was new. We have already seen earlier work on secure development. To show a specific borrowing, or a specific difference, we have to compare the relevant documents.
The NIST Secure Software Development Framework gives us a useful check on dates. Its public draft was announced in June twenty nineteen. Final version one point zero came in April twenty twenty. Final version one point one came in February twenty twenty-two.
So the twenty sixteen GOST cannot have been based on those later SSDF publications. At the same time, being earlier than SSDF does not prove that GOST was the first secure development approach in the world. And similarity does not prove influence in the other direction.
Our comparison asks a more useful question. Which engineering concerns are shared? How are obligations organized? And what evidence does each approach expect? That is something we can study process by process.
Cue: TRANS 00:10:19–00:14:32; PDF истории с.3/22. NIST: 11.06.2019 draft, 23.04.2020 final1.0, 03.02.2022 final1.1. Не повторять ошибку пересказа «ГОСТ основан на SSDF» и неподтверждённое мировое первенство. Визуальная опора: On a common time axis, GOST R 56939 was approved in 2016; the first public SSDF draft appeared in 2019, final SSDF 1.0 in 2020, and final SSDF 1.1 in 2022. The timeline does not assert ancestry between the documents.
## 14 | Two editions, different structures
Seconds: 105
Section: From the 2016 edition to 2024
Layout: cards
Visual: slide-12
Lead: The same source term has different normative force
Items:
- 2016 edition | Nine groups of measures · clauses 5.1–5.9
- 2024 edition | Twenty-five named processes · clauses 5.1–5.25
- A wording change | The same term: recommendation in 2016 · requirement in 2024
- Migration | Map obligations and evidence; preserve practices that work
Sources: G16, G24
*These labels compare the normative force of one term in the original text.*
Speech:
The two editions organize related engineering work in different ways.
Section five of the twenty sixteen standard has nine groups of measures. Section five of the twenty twenty-four edition has twenty-five named processes. These are different units of organization. Subtracting one number from the other does not tell us how many genuinely new practices appeared, or how much safer a product became.
There's also a concrete change in wording. Look at the Russian verb sleduet. The closest English word is should. Under clause four point two of the twenty sixteen edition, it had recommendation status. Under clause four point seven of the twenty twenty-four edition, the same verb expresses a requirement. Suppose you read an English translation and treat should as advice. Then you will do less than the current edition requires. These labels describe the force of that specific term. An English translation must preserve the force assigned by the relevant edition.
That's why it is risky to reuse an old checklist without reading the new edition. Familiar words can carry different force.
The twenty twenty-four edition was approved on the twenty-fourth of October, by order one five zero four, s t. It became effective on the twentieth of December of the same year. Moving to it needs a gap analysis. Which obligations and evidence are already covered? Which ones need adjustment? And which ones need new work? Practices that already work well are a starting point for that analysis.
Cue: Оглавление и п.4.2 ГОСТ2016; оглавление и п.4.7 ГОСТ2024. В записи «14 мер» не совпадает с девятью группами финального оглавления. 2024: утверждён24.10, действует20.12. Английский перевод модальности пояснить по конкретной редакции. Визуальная опора: The 2016 edition has nine groups of measures; clause 4.2 assigns recommendation status to a term that expresses a requirement under clause 4.7 of the 2024 edition. The 2024 edition has 25 named processes. Structural counts do not measure a change in security.
## 15 | A process continues after the first tool run
Seconds: 100
Section: From the 2016 edition to 2024
Layout: steps
Visual: slide-13
Lead: Triggers, ownership, evidence and feedback make work repeatable
Items:
- Trigger | What event starts the work?
- Ownership | Who performs it and who reviews the result?
- Evidence | Which version, findings and decisions are recorded?
- Feedback | What changes before the next cycle?
Sources: G24, EX
*A teaching model of repeatable work: actions, decisions and feedback remain connected.*
Speech:
A process needs more than a new heading. It organizes work that continues over time. It needs clear responsibilities, repeatable actions, and results that inform the next cycle.
Here's a memorable example. A team buys an analysis tool for a short time, just before a release. That may produce a report. It does not automatically establish a maintained process for examining changes, reviewing findings, fixing problems, and checking the result again.
Let's follow the loop for our importer team. A relevant code change triggers the analysis. A named engineer runs the check and reviews the findings. The team records a decision. Then the team reviews what should change before the next cycle. At the centre, the evidence connects the finding and the decision to the product version.
Trigger, ownership, evidence, and feedback give us a practical way to examine a process. The twenty sixteen edition already addressed lifecycle work, internal checks, and improvement.
The practical lesson is simple. A tool becomes useful inside an organized way of working. Planning gives the team the time, people, and agreements to keep that work going.
Cue: TRANS 00:49:47–00:51:26 и 01:25:22–01:27:08: позиции собеседников различаются. Четыре вопроса — авторский учебный приём; не приписывать 2016 отсутствие регулярных практик. Визуальная опора: A repeating process connects a trigger, assigned work, a recorded decision and review. Product version and evidence remain at the centre of the cycle.
## 16 | When this standard actually binds
Seconds: 140
Section: Legal force
Layout: cards
Lead: A national standard applies voluntarily until another document points at it
Items:
- Default | Applied voluntarily · the foreword names article 26 of Federal Law 162-FZ of 2015 as the rules of application
- Clause 4.14 | Regulatory acts, national and industry standards, technical specifications for research and development work, and other documents define which processes apply
- In practice | A regulator's order, a customer contract, a certification scheme, or a company's own decision
- Once it binds | Every requirement applies · except those that use the words recommended or may
- Clause 4.15 | Research and development work · only an explicit list of processes in the technical specification imposes the standard · partial lists allowed
Sources: G24, NS162
Speech:
People often ask me one question. Is this standard the law?
No. In Russia a national standard is applied voluntarily, unless the law says otherwise. The foreword of this edition points to the rules of application. They live in article twenty-six of Federal Law one six two, f z, of twenty fifteen. The standard does not make itself binding.
Clause four point fourteen tells us what makes it binding. Here is my working translation. The set of processes a developer must implement is determined by the requirements of regulatory legal acts, national and industry standards, technical specifications for research and development work, and other documents.
So something else has to point at the standard. In practice that is an order from a regulator, a customer contract, a certification scheme, or a company's own decision. The law adds one more trigger. A public claim of conformity binds you too.
The same clause adds one sharp detail. Once a document says you must conform, all the requirements apply. The only exceptions are requirements that use the words recommended or may.
Clause four point fifteen adds a special rule for research and development work. There the standard can bind only through an explicit list of processes in the technical specification. And that list may be partial.
One more point. FSTEC co-developed this edition. That is authorship, not law. A regulator writing a standard does not turn it into a legal duty.
So the useful question is not: is GOST mandatory? The useful question is: what in my situation points at it? Read that way, it is a best-practice baseline. Teams elsewhere use ISO or NIST documents the same way.
Cue: П.4.14 и 4.15 ГОСТ Р 56939-2024, предисловие (правила применения — ст.26 ФЗ-162 от 29.06.2015; ч.1 — добровольность «если иное не установлено законодательством», ч.3 — публичное заявление о соответствии). ФСТЭК — соразработчик редакции 2024, не законодатель: не говорить, что ФСТЭК делает стандарт обязательным. Только механизм, без оценок российского регулирования. Пауза после вопроса «Is this standard the law?», затем твёрдое «No». Номер закона читать медленно.
## 17 | Shared practices need evidence
Seconds: 90
Section: Our comparison method
Layout: compare
Lead: Findings and limits of the multivocal literature review
Items:
- Shared practices | Similar engineering work, organized in different ways
- Organizational work | Risk, culture, people, policy and communication matter
- Effectiveness evidence | Limited and uneven validation of complete methodologies
Sources: MLR, N11, N12
Speech:
What can we conclude from the literature review? It finds substantial overlap in practices. It also finds organizational concerns, such as risk management, culture, policies, and communication.
The review distinguishes three kinds of work. Work at the level of the organization. Work across the lifecycle. And activities linked to a project stage. So a security programme is more than a list of tools.
Evidence about complete methodologies is limited and uneven. That does not show that secure development fails. It means we have to examine the evaluation method, the context, and the result being measured.
The review selected accessible English-language material. Its omission of GOST cannot establish that the Russian standard is unique.
An expert's experience can reveal useful questions. A broader conclusion still needs evidence about the context, the method, and the result.
We'll compare specific practices and evidence, using named versions. Our NIST baseline is final SSDF one point one. As of September twenty twenty-six, version one point two is still a draft. Let's make the comparison method explicit.
Cue: Результат обзора не равен доказательству причинного снижения уязвимостей. Не говорить «доказательств вообще нет» и не интерпретировать авторскую разметку Waterfall/Agile как статистику отрасли.
## 18 | Compare obligations, not labels
Seconds: 110
Section: Our comparison method
Layout: steps
Visual: slide-15
Lead: Similar goals can still imply different work
Items:
- Read | Actor · action · scope · conditions
- Compare | Shared intent and concrete differences
- Demonstrate | One implementation example with evidence
- Conclude | Partial overlap is a useful result
Sources: G24, N11
*Compare what the documents ask people to do and what would demonstrate the result.*
Speech:
Here's the method we will use. First, we take one specific requirement or practice. We record who acts, what they do, the scope, and any conditions. Second, we compare the actual work and the expected result.
We also keep the force of the original wording. Clause four point seven of the twenty twenty-four GOST defines which wording expresses a required condition. When we translate such a condition, we must convey a requirement rather than turn it into an optional recommendation. On the international side, we ask what we are reading. Is it framework guidance, a requirement, or an example of implementation? Similar wording does not automatically give two documents the same authority.
Third, we demonstrate one concrete implementation. We also name the records that would let another person verify the result.
Finally, our conclusion may be substantial overlap, partial overlap, or a complementary practice. If we have not found a counterpart, we will state which sources we reviewed.
This lets us study the main question of this series without deciding the answer in advance. A useful comparison can show shared engineering ideas. And it can still show important differences in scope, detail, and expected evidence.
Cue: Русские термины объяснить, не превращать в упражнение для зрителя. Слайд даёт метод, не формальную сертификационную оценку. Визуальная опора: The comparison method proceeds from reading actors, actions and conditions, to examining differences, demonstrating an implementation, and stating a bounded conclusion.
## 19 | What process 5.1 asks for
Seconds: 145
Section: Planning secure development
Layout: steps
Visual: slide-16
Lead: Five requirements that connect the present to the next action
Items:
- 5.1.2.1 | Periodically analyse the current state
- 5.1.2.2 | Periodically analyse resource needs
- 5.1.2.3 | Develop a process improvement plan
- 5.1.2.4 | Develop a process implementation plan
- 5.1.2.5 | Define the scope of the processes
Sources: G24
*Five planning requirements connected by their information dependencies.*
Speech:
Now we can read the first process directly. Section five point one is about planning secure software development processes.
It has five requirements. Periodically analyse the current state of the processes. Periodically analyse resource needs. Develop a plan for improving the processes. Develop a plan for implementing them. And define their scope.
The two plans must take the analyses into account. That connection matters. A plan can look good on paper. But if it ignores what the team does today, or what resources the team has, it may be impossible to carry out.
I use process improvement plan as a working English label for the plan of process development. In a moment we'll see how it differs from the implementation plan.
For our small team, the first step is to describe what already happens and what does not. Then we find the biggest gaps. We estimate the capacity needed to close them. And we assign work the team can really do.
The standard requires periodic analysis, but it does not give us a universal ninety-day schedule. The schedule later in this episode is an illustrative choice for our example.
One caution before we build the plan. The standard also carries an informative appendix A, initialisation of secure development processes. It repeats almost the same steps for a team that is only starting these processes. Analyse the current state. Analyse the resources needed. Write the result down as a plan. Its artifacts are almost word for word the same as the ones in five point one. The difference is status. Under clause four point sixteen, assessment of the appendix A processes is not mandatory during an external audit. Clause five point one is a full process, and it is assessed. So if you are deciding which of these two very similar texts to implement, that difference is what settles it.
Cue: Все пять требований на экране. Не объявлять квартал обязательной частотой ГОСТ. Приложение А (справочное) — п.4.16: оценка не обязательна при внешнем аудите, в отличие от 5.1. Визуальная опора: Within the defined scope, current-state analysis and resource analysis support both the process improvement plan and the process implementation plan. The five nodes carry clauses 5.1.2.1 through 5.1.2.5.
## 20 | Start with a defensible scope
Seconds: 100
Section: Planning secure development
Layout: table
Visual: slide-17
Lead: Name the software and explain the boundary
Items:
- Included | Importer 2.0 · parser module · service API · shipped libraries
- Connected context | Repository, CI configuration and release workflow
- Boundary to justify | Retired prototype with no code or dependency path into release
- Evidence | Versioned scope record with the selection rationale
Sources: G24, EX
*Illustrative scope: record what is included, what is connected and why an exclusion is justified.*
Speech:
What exactly does the plan cover? In our example, the scope includes version two point zero of the importer, its parser module, the small service API, and the libraries that ship with it.
The repository, the integration configuration, and the release workflow form relevant development context. We record links to them, so the plan connects to actual work.
Suppose the team also has an old prototype. It may sit outside the chosen scope. But the team needs a reason. If code or a dependency from that prototype goes into the release, the boundary needs another look.
The standard's scope artifact lists the parts the software is made of. That means versions, modules, components and functional subsystems. It also gives the reason for that selection. If we name a product but do not name its relevant parts, we leave room for misunderstanding.
This is not permission to declare inconvenient components irrelevant. The rationale must make sense for the product and for the obligations that apply to it. In a teaching example, we can keep the scope small. For a real implementation, the team needs to look at the actual relationships. And it needs to keep the boundary up to date as the product changes.
Cue: «Connected context» не смешивать с буквальным составом ПО из 5.1.3.5. Это полезные связанные записи примера. Визуальная опора: Importer 2.0 contains the parser, service API and shipped libraries. Repository, CI configuration and release workflow form connected development context. Excluding a retired prototype requires evidence that it has no code or dependency path into the release.
## 21 | Assess reality and assign owners
Seconds: 95
Section: Planning secure development
Layout: cards
Lead: Illustrative findings, with people who can act
Items:
- Engineering lead | Parser checks run manually; coverage is unclear
- AppSec lead | Review findings and agree investigation criteria
- Release owner | Record release decisions under the team's policy
- Sponsor | Resolve capacity and priority conflicts
Sources: G24, EX
Speech:
Let's start with three questions. What already works? What needs improvement? What is missing? Introducing a standard does not mean rebuilding everything from zero.
The current-state record lists which processes are in place and which are not. It assesses the existing processes against this standard, against other standards that apply, and against the team's tools and technologies.
In our example, parser checks run by hand. Coverage is unclear. The decision history is incomplete. These are fictional findings.
Now we assign responsibilities. The engineering lead owns integration. The AppSec lead helps define investigation criteria and review security evidence. The release owner records decisions under the team's policy. A sponsor resolves conflicts about capacity and priority.
One person may hold several roles. Even then, it must stay clear who is responsible and who decides.
This allocation is our implementation example. The standard's implementation-plan artifact must identify the employees responsible for implementing the processes. It does not automatically give AppSec an independent power to block every release. The organization must define that authority. And it must make the link between investigation, review, and the release decision clear.
Cue: Отличать ответственного за действие от того, кто уполномочен принимать остаточный риск.
## 22 | Resources include human attention
Seconds: 95
Section: Planning secure development
Layout: cards
Visual: slide-19
Lead: Illustrative 90-day estimate · validate it with the team
Items:
- Engineering | 60 person-hours
- AppSec | 24 person-hours
- Release and sponsor | 12 person-hours
- Total | 96 person-hours · tools and infrastructure assessed separately
Sources: G24, EX
*Illustrative total effort for the 90-day plan; validate the estimates with the people doing the work.*
Speech:
Resource planning includes time. Time to set up the checks. Time to investigate findings. Time to keep the workflow running. And time to teach people how to use it.
Here's our ninety-day effort. It's fictional. We reserve sixty engineering hours, twenty-four AppSec hours, and twelve hours for release coordination and sponsor decisions. The total is ninety-six person-hours.
These figures are a teaching example. They are not a benchmark. They are not a percentage required by GOST. No universal percentage can replace an estimate of the actual work.
Tools, infrastructure, and the cost of extra training need their own assessment. Dependencies matter too. If the build engineer is not available during the first month, the schedule must show that. Assigning a task does not create capacity.
The standard's resource-analysis record may include an estimate of the material and human resources the work will need. The chart makes those assumptions open to discussion. Ask the people doing the work if the estimate is realistic. Show it to the people who set priorities. Agree when to update it. Human attention is part of the resource plan.
Cue: Сделать паузу на сумме 96. Часы для всего учебного плана, не недельная нагрузка. Визуальная опора: An illustrative 90-day effort allocates 60 person-hours to engineering, 24 to AppSec, and 12 to release coordination and sponsor decisions, for a total of 96 person-hours. Tools and infrastructure are assessed separately.
## 23 | Two plans, two questions
Seconds: 100
Section: Planning secure development
Layout: compare
Visual: slide-20
Lead: A roadmap and an execution plan can be linked in one tracker
Items:
- Improvement plan | What capability changes, in what order, with which resources?
- Implementation plan | What work happens, by whom, at which stage, and by when?
- Shared foundation | Current-state analysis and resource analysis
Sources: G24, EX
*Connect the capability in the improvement plan to executable work and its evidence.*
Speech:
Planning gives everyone a shared language: the team, its managers, and the people who ask for the product. Two related plans help them agree on the direction and the work.
The improvement plan describes how processes will develop. It sets priorities and the order of changes. It takes available resources into account. Our team might make parser analysis repeatable, improve the handling of findings, and then review the results.
The implementation plan identifies goals, stages, dates, resources, and responsible people. In the middle of the diagram, one task names the parser target, the integration milestone and the owner. On the right, the evidence records coverage and the review of findings.
The standard allows these plans to be represented in a task management system. A roadmap with linked tasks can keep their different purposes clear, and avoid documents that sit apart from the work.
Here's the practical test: traceability. Why was this change chosen? Which resource assumption supports it? Who does the work? What shows that a stage is finished? A planning page becomes useful when the team can follow those links and act on them.
Cue: Не говорить, что стандарт требует два отдельных файла или конкретный формат Jira. Визуальная опора: A process improvement goal, repeatable parser checks, is linked to an implementation task with an owner and milestone, and then to evidence of coverage and triage decisions. Current-state and resource analysis support the entire chain.
## 24 | A 90-day plan for the importer
Seconds: 135
Section: Worked example
Layout: timeline
Visual: slide-21
Lead: Illustrative implementation choices, not a GOST timetable
Items:
- Days 1–30 | Confirm scope and baseline · assign owners · agree capacity
- Days 31–60 | Connect parser checks to CI · record coverage and triage decisions
- Days 61–90 | Review two release cycles · correct gaps · update the next plan
Sources: G24, EX
*A 90-day example for the importer: each stage produces something the team can review.*
Speech:
Let's put those parts together in a ninety-day example. The product is the engineering-file importer. Our first goal is to handle findings from parser analysis the same way every time, and to make that work easy to review.
In days one to thirty, the team confirms the software scope. It writes down the current state. It reviews the resource estimate. It names the owner of each planned action, and the person responsible for the release decision. The result is a small baseline that anyone can look at.
In days thirty-one to sixty, the engineer connects the chosen parser checks to continuous integration. The team writes down which source targets and configurations are covered. Every finding gets a review record, and the release workflow links to that record.
In days sixty-one to ninety, the team looks at evidence from two example release cycles. Did the checks run on the intended versions? Did every finding get a decision? Was the agreed capacity enough? The answers shape the next improvement plan.
The ninety-day period, the two releases, and the detailed tasks are our choices. They do not come from the standard. And finishing this example does not establish conformity with every process in the document.
For implementation of this GOST, section four point thirteen requires the following in the development environment. Version control. Continuous integration. And task management, including defect tracking. It does not say continuous deployment. That difference is useful when we explain our pipeline choices.
Cue: Здесь главная практическая пауза: провести взглядом по трём этапам. Не уходить в live demo настройки анализатора. Визуальная опора: The illustrative plan has three equal 30-day periods: establish scope, baseline and ownership; integrate parser checks and record decisions; then review two release cycles, close gaps and update the next plan.
## 25 | Five linked records of evidence
Seconds: 95
Section: Worked example
Layout: steps
Visual: slide-22
Lead: A one-page summary points to the underlying records
Items:
- 5.1.3.1 | Current-state analysis
- 5.1.3.2 | Resource analysis
- 5.1.3.3 | Process improvement plan
- 5.1.3.4 | Process implementation plan
- 5.1.3.5 | Scope and selection rationale
Sources: G24, EX
*The same planning structure, now expressed as records a reviewer can follow.*
Speech:
The standard names five matching kinds of evidence. Current-state analysis. Resource analysis. The improvement plan. The implementation plan. And the scope, with the reasons for choosing it.
These are five kinds of information, not an instruction to create five separate Word files. Existing systems can carry this work. A planning page can link to repository and task records you already keep.
In our example, the scope names the importer version and components. The baseline links to the checks that ran. The resource record holds estimates and assumptions. The improvement plan explains priorities. The implementation tasks name owners and milestones.
The standard recognizes forms such as electronic files, logs, and tool results. Choose a form that carries the required information and keeps it traceable.
A one-page template is only an entry point. It does not replace the analysis behind it, and it does not prove effectiveness. A reviewer should be able to follow the links. They should find the right version, understand the decisions, and see which questions are still open. Automation helps when it keeps those connections.
Cue: На слайде артефакты 5.1.3.1–5; подробный шаблон приложен Markdown. Не обещать «одной страницы достаточно для соответствия». Визуальная опора: Five evidence categories mirror the planning requirements: baseline checks and gaps, resource estimates and assumptions, improvement priorities, implementation owners and milestones, and the importer scope with its rationale.
## 26 | Every process is written the same way
Seconds: 150
Section: Worked example
Layout: cards
Lead: One shape for all 25 processes: name, goals, requirements, artifacts
Items:
- Name · 5.1 | Planning secure software development processes
- Goals · 5.1.1 | What the process is for · 5.1.1.1 to 5.1.1.3
- Requirements · 5.1.2 | What to do · 5.1.2.1 to 5.1.2.5
- Artifacts · 5.1.3 | What to show afterwards · 5.1.3.1 to 5.1.3.5
- In every episode | Goals to understand · then compare · requirements and artifacts to apply
Sources: G24
Speech:
Before the crosswalk, here is your reading key for the other twenty-four episodes.
Clause four point eight says every process has the same four parts. The name of the process. Its goals. Its implementation requirements. And its artifacts of requirement implementation. I will say artifacts, or evidence.
The numbering follows that shape. Five point one is the name: planning secure software development processes. Goals come first, then requirements, then artifacts. You saw the five requirements earlier, and the five records a moment ago.
So open any process and read it in that order. What is the work for? What must we do? What must we be able to show afterwards?
Two details help with the artifacts. Clause four point eleven keeps the form open. An artifact is any information, in any form, that lets someone confirm the requirement was met. A document, a report, a file, a log, the result of a tool or a process. Then read the verb. Here, four of the five records must contain the listed information. For the resource analysis, the verb is may.
In most of the later processes, the first artifact is what the standard calls a reglament. In English, a written procedure. As a rule, it must cover two things. The duties and roles of the staff, and the details of how the process is carried out. The standard sets no format for it.
This shape also gives us the plan for every episode. Goals answer our first question: what problem does the process address? Requirements and artifacts answer the third: what can a team do and verify? The second question, the comparison, is where we go next.
Cue: Ключ к чтению всех 25 процессов. П.4.8 — структура; 4.11 — что считается артефактом; 4.12 — регламент: «в общем случае» обязанности и роли сотрудников плюс сведения об особенностях реализации процесса, формат не задан. Точное число процессов с регламентом вслух не называть. 5.1.3.2 — «могут содержать», остальные четыре — «должны/должен/должно содержать». Ссылки назад: требования были на слайде про 5.1, записи — на предыдущем.
## 27 | A first international crosswalk
Seconds: 110
Section: Comparison result
Layout: compare
Visual: slide-23
Lead: Useful connections · bounded conclusions
Items:
- People | GOST 5.1.3.4 ↔ NIST SSDF PO.2.1 · partial overlap
- Improvement | GOST 5.1.2.3 ↔ SAMM Strategy & Metrics · partial overlap
- Difference | GOST explicitly identifies five planning evidence categories
Sources: G24, N11, SAMM
*Bounded comparison: a shared concern is useful, but does not establish full equivalence.*
Speech:
Let's make a small comparison, with clear limits. In GOST, the implementation-plan artifact identifies the employees responsible for implementing the processes. NIST SSDF task P O two point one covers roles and responsibilities for secure software development. There is a useful shared concern. People need to know which work belongs to them.
But the comparison is partial. The GOST artifact also includes goals, timing, stages, and resources. That single SSDF task does not by itself reproduce the complete artifact.
Now look at process improvement. In OWASP SAMM, the Strategy and Metrics practice gives us a useful link. It focuses on an improvement strategy and a roadmap. Again, we need to examine the details, and the purpose of the model, before we claim equivalence.
These comparisons help us read the first process in a wider engineering context. They do not establish that following one document automatically satisfies the other.
So our first conclusion is a modest one. Planning, responsibility, and improvement have international counterparts we can recognize. But the exact structure, the wording, and the expected evidence still need to be examined, requirement by requirement. The notes with this episode keep those limits and the source versions.
Cue: PO.2.1 произнести «P O, two point one». Сопоставлены узкие положения, не все пять требований полностью. Визуальная опора: Two partial overlaps are shown: GOST 5.1.3.4 and NIST SSDF PO.2.1 share a concern with roles and responsibility; GOST 5.1.2.3 and SAMM Strategy and Metrics share a concern with an improvement roadmap. Scope and evidence expectations still differ.
## 28 | Would this survive Friday's release?
Seconds: 95
Section: Apply it
Layout: cards
Visual: slide-24
Lead: A short review before calling the plan usable
Items:
- Scope | Which version and components are covered, and why?
- Capacity | Who has time and authority to act?
- Evidence | Can we trace an action to its result?
- Review | When do we revisit the assumptions?
Sources: EX, G24
*Return to Friday's release: can the team follow the finding through an owned, evidenced decision?*
Speech:
Let's go back to Friday's warning. A plan will not tell us by itself whether that warning is a real vulnerability. The plan helps organize the investigation and the decision.
We can name the affected version and component. We can find the owner of the investigation, and the person authorized to make the release decision. And we can see what evidence we have, and which results are missing.
Weak planning is easy to spot too. An analyzer with no review owner is incomplete. A roadmap with no capacity is unreliable. A scope with no rationale is hard to defend.
For this team, I would review the plan after ninety days, and after a material change, such as adding a parser. These are our own recommendations for implementation.
In a small team, one person may hold several responsibilities. Make the arrangement explicit, and check the capacity. Scaling the implementation does not establish that applicable requirements can be ignored.
Here is the practical test. Can another team member understand the next action? If only the author can explain the plan, then improve it.
Cue: Провести зрителя по пяти узлам: input file → parser → finding → investigate → decide. Сделать короткую паузу на связи расследования с решением о выпуске. Период и триггеры пересмотра — авторский пример. Визуальная опора: The importer scenario returns with a connected path: identify the input and covered parser, retain the finding evidence, assign time and ownership for investigation, and record a release decision under the team's policy. This is a review of the process, not proof that a release is safe.
## 29 | Security Training That Changes Engineering Decisions
Seconds: 115
Section: Stay in touch · Next episode
Layout: closing
Lead: Next: EP02 · Employee training · GOST R 56939-2024, clause 5.2
Contact: Vitaliy Pikov | pikov.art | https://pikov.art
Channels:
- LinkedIn | in/vitaliy-pikov | https://www.linkedin.com/in/vitaliy-pikov/
- Email | vitaly@pikov.expert | mailto:vitaly@pikov.expert
- Telegram | UnderLineSecurity | https://t.me/UnderLineSecurity
Items:
- Roles & skills | What each person needs to learn
- Practical learning | A short exercise before and after training
- Evidence of progress | Look beyond attendance to demonstrated skills
Sources: G24, EX
Speech:
Today we followed the Russian standard from the early discussions to the editions that were adopted. We connected that history to international work. And we used its first process to organize a practical improvement effort.
Your next step is simple. Choose one product, and start your planning page. Describe the current state. Name the next improvement. Then connect it to an owner, to the capacity you have, and to evidence someone can review. The worksheet with this episode will help you start.
I am Vitaliy Pikov. You can find me at pikov dot expert, and on LinkedIn. My email and my Telegram channel are on the slide. Please keep in touch, and share the questions you would like this series to explore.
The next episode is called Security Training That Changes Engineering Decisions. We'll look at employee training under clause five point two. What do different roles need to learn? How do we practise those skills? And what evidence can show progress beyond attendance?
We'll build a role and skills matrix, and use a short exercise before and after the training. So, which engineering decision would you most like your security training to improve? Thank you for watching. See you in episode two.
Cue: Произнести «pikov dot expert», выдержать паузу у адреса. Ссылки на LinkedIn, почту и Telegram — на слайде, вслух их не читать. Название EP02 прочитать полностью. В конце оставить слайд с контактом и анонсом на несколько секунд; дата выпуска пока не объявлена.
SHA-256: a02d19808b0414c2b92c64d13ca5528c5f4c8e8fb8c86bf4134f6503d93edbda
10EP01 — Источники и границы выводовEP01-sources.md
EP01 — Источники и границы выводов
Проверка: 6 сентября 2026 года, включая доработку по полному транскрипту вебинара 02.07.2025 и архивному финальному ГОСТ Р 56939-2016. Ранее полностью прочитаны два точных PDF из подпапки «РАЗДАВАТЬ»: обзор методологий — 27 страниц, доклад Вареницы — 26. Для копии G16 извлечён текст всех 24 PDF-страниц и проверены относящиеся к истории разделы; предисловие, оглавление и общие положения просмотрены визуально. Детальный разбор, карта 28 публикаций и исправленные расхождения — в EP01-history-research.md. Основа текущих требований — локальный текст окончательной редакции G24, не проект «20ХХ» и не устный пересказ. Краткие ID используются в сценарии и презентации; текущий выпуск — 29 слайдов, план 53:00.
Реестр внешних источников
| ID | Источник / версия | Использованный тезис и граница |
|---|---|---|
| G24 | Росстандарт: ГОСТ Р 56939-2024 | Утверждён 24.10.2024 приказом 1504-ст, введён 20.12.2024, заменяет 2016. Содержание требований прочитано в локальном полном тексте |
| G16 | Росстандарт: ГОСТ Р 56939-2016; локальный PDF «ГОСТ Р 56939-2016 (редакция 2016).pdf» | Росстандарт, приказ 458-ст от 01.06.2016; введён 01.06.2017. Предисловие: ЗАО НПО «Эшелон», ТК 362. 9 тематических подразделов 5.1–5.9; п. 4.2: «следует» — рекомендация; п. 4.5: компенсирующие меры; раздел 1 и приложение А: связи с 27034 и 15408 |
| WARE | RAND: Security Controls for Computer Systems | Доклад первоначально опубликован в феврале 1970; 1979 на странице — переиздание. Не стандарт SSDLC |
| SS75 | Saltzer–Schroeder: оригинальная статья, библиография автора | September 1975, Proceedings of the IEEE 63(9), 1278–1308. Два принципа — выборка, не вся статья |
| MSH | Microsoft: история SDL | Trustworthy Computing — январь 2002; SDL как часть разработки Microsoft — 2004. Не утверждается первенство Microsoft во всей области |
| RH | Омский ЦСМ: исторические вехи Росстандарта | Комитет по стандартизации — 15.09.1925. Институциональная история, не дата возникновения практик безопасной разработки |
| N11 | NIST SP 800-218, SSDF 1.1 final, Table 1 полного текста | Финальная редакция 03.02.2022; узкое сопоставление с PO.2.1 |
| N19 | NIST: анонс проекта SSDF | Дата анонса 11.06.2019; draft. Служебное Created 07.06.2019 не подменяет дату новости. Источник для хронологии, не доказательство заимствования в любом направлении |
| N20 | NIST: публикация SSDF 1.0, white paper | Финальный white paper от 23.04.2020; не путать с draft 2019 или SP 800-218 / 1.1 от 2022 |
| N12 | SSDF 1.2 initial public draft, реестр SSDF | Проект 17.12.2025 остаётся обозначен draft на дату проверки. В выпуске не подменяет final 1.1 |
| SAMM | OWASP SAMM, Strategy and Metrics, stream A | База модели SAMM 2.0, живая веб-документация; для сравнения конкретно G-SM-A-2 |
| MLR | Локальный PDF; Kudriavtseva & Gadyatskaya, arXiv:2211.16987v2, метаданные | Препринт v2 от 04.07.2023, In submission; 27 страниц прочитаны. Table II, Figure 2, практики и ограничения эффективности; не доказательство уникальности ГОСТ |
| SAMM20 | OWASP SAMM v2 public release | Подтверждение выпуска версии 2 от 31.01.2020 для шкалы публикаций |
| GOSTH | Локальный PDF: Вареница Виталий, «История создания и актуальное состояние РБПО в России. ГОСТ Р 56939-2016/24» | 26 страниц, экспорт PDF 02.07.2025; с. 2–4 — предпосылки и разработка, с. 3/22 — международные связи. Дата утверждения и фрагменты проекта уточнены по официальной карточке и финальному тексту |
| TRANS | Полный транскрипт вебинара 02.07.2025 | Метки 00:00:05–02:07:28; исходный текст пользователя, не официальный протокол. Времена исторических тезисов и исправления ASR — в историческом разборе. Все реплики размечены «Участник 1», поэтому автоматическая атрибуция голосов не подтверждена. Само видео не просматривалось |
| EX | Авторский учебный пример | Продукт, наблюдения, часы, график, роли и триггеры пересмотра придуманы для объяснения; внешней эмпирической оценки нет |
Исследование из прежних материалов
Arina Kudriavtseva и Olga Gadyatskaya, Secure Software Development Methodologies: A Multivocal Literature Review. Авторы рассматривают 28 методологий из отрасли, государственных и академических источников, опубликованных в 2004–2022 годах; анализируют технические и организационные практики и опубликованные сведения об эффективности.
В разделе III перед Figure 2 прямо отмечено: дата публикации может отличаться от даты появления подхода. Пример — SDL внедрялся в Microsoft с 2004 года, хотя рассмотренная книга опубликована в 2006. Более того, Figure 2 и Table II на PDF-с. 5 расходятся по нескольким позициям. Поэтому слайд 5 содержит самостоятельно составленную шкалу выбранных публикаций/редакций с явным типом даты; исходный рисунок не перенесён целиком.
Обзор ограничен критериями отбора, доступностью и английским языком источников; это не перепись всей мировой практики. Используем его для карты методологий (слайд 5), различий способов организации работ (6) и ограничений выводов об эффективности (14). Утверждений о доказанном количественном снижении уязвимостей по этому обзору в сценарии нет. Источники WARE, SS75 и RH остаются дополнительным контекстом вне основной речи обновлённого исторического блока.
Точный нормативный конспект процесса 5.1
| Пункт | Смысл для автора | Где раскрыт |
|---|---|---|
| 5.1.2.1 / 5.1.3.1 | Периодический анализ состояния; реализованные и нереализованные процессы; оценка достаточности и соответствия с учётом применимых стандартов, инструментов и технологий | Слайды 16, 18, 22; пример §2 |
| 5.1.2.2 / 5.1.3.2 | Периодический анализ потребностей в ресурсах; оценочные материальные/людские показатели в описании артефакта допустимы («могут содержать») | Слайды 16, 19; пример §3 |
| 5.1.2.3 / 5.1.3.3 | План развития с учётом двух анализов; очередность, приоритеты, ресурсы, организационные изменения, инструменты и обучение | Слайды 16, 20–22; пример §4 |
| 5.1.2.4 / 5.1.3.4 | План реализации с учётом анализов; цели, сроки, этапы, ресурсы, ответственные сотрудники | Слайды 16, 18, 20–22; пример §5 |
| 5.1.2.5 / 5.1.3.5 | Определение области; состав ПО и обоснование выбора состава | Слайды 16–17, 22; пример §1 |
Оба плана допустимо представить в системе управления задачами. Пять видов информации не означают обязательные пять отдельных файлов. План на 90 дней — учебный вариант; полная оценка всех процессов не выполнена.
Дополнительные пункты: 4.3 — независимость от модели жизненного цикла; 4.5 — участие руководства и ресурсы; 4.7 — и «должен», и «следует» выражают требование; 4.11 — разные формы сохранённых свидетельств; 4.12 — формат регламентов не предписан; 4.13 — контроль версий, непрерывная интеграция и управление задачами, включая отслеживание ошибок. Подмена CI на обязательный CD недопустима. Пункты 4.14–4.15 не используются для вывода, что стандарт автоматически обязателен для каждой команды.
Два ограниченных сопоставления для слайда 23
| Поле | Ответственность | Развитие процессов |
|---|---|---|
| ГОСТ | 5.1.3.4, ответственные сотрудники в плане реализации; требуемое содержание артефакта | 5.1.2.3 и 5.1.3.3; требование планировать развитие на основе анализов |
| Международный фрагмент | SSDF 1.1, PO.2.1: жизненный цикл ролей и ответственности; задача рекомендательного framework | SAMM, G-SM-A-2: стратегия, бюджет и этапы дорожной карты; деятельность модели зрелости |
| Общая часть | Ясная ответственность за работу | Организация последовательного улучшения с ресурсами и этапами |
| Различия | В ГОСТ артефакт содержит также цели, сроки, этапы и ресурсы; PO.2.1 шире конкретного плана по роли в lifecycle | SAMM задаёт контекст зрелости программы; ГОСТ — определённые требования и содержание артефактов |
| Учебное применение | Владелец задачи, ответственный за решение, ссылка на политику полномочий | Обоснованная очередь изменений и связанные задачи |
| Вывод | Partial overlap, узкая пара, уверенность средняя | Partial overlap, узкая пара, уверенность средняя |
Проверка содержания выполнена при подготовке, внешнего рецензента не было. Нормативная сила сторон различается. Эти две пары не являются полной матрицей 5.1 и не подтверждают юридическую/сертификационную эквивалентность. Направления дальнейшего анализа: SSDF PO.1/PO.3/PO.4 и остальные активности SAMM; статус полного сопоставления — Not assessed.
Российское семейство: справка вне основного хронометража
ГОСТ Р 56939 не исчерпывает российские документы по теме. Примеры: ГОСТ Р 58412-2019 — угрозы безопасности информации при разработке; ГОСТ Р 71206-2024 — безопасный компилятор C/C++, общие требования; ГОСТ Р 71207-2024 — статический анализ ПО, общие требования. Проверены каталог 58412, каталог 71206, карточка 71207. Это три примера, а не полный реестр. Детали этих документов не приписываются требованиям процесса 5.1.
Использование архива PVS-Studio
База: V:\Yandex.Disk\_МАСКОМ\2025 Вебинары по РБПО с PVS-STUDIO\2025.07.02 Вебинар1 по РБПО с PVS-STUDIO. Пользователь прямо разрешил свободное использование этих материалов в текущей задаче; дополнительного разрешения не требуется.
| Файл относительно базы | Проверенный объём | Что использовано |
|---|---|---|
2025.07.02 Вебинар1 по РБПО с PVS-STUDIO (РАЗДАВАТЬ)\2025.07.02 Вебинар 1 по РБПО с PVS-STUDIO.pdf |
54 страницы; текст, выборочная визуальная проверка | С. 6–8 — прежняя идея серии; 13–19 — авторское объяснение эволюции; 26–29 — цель/требования/свидетельства; 37–45 — процесс 5.1 |
1.pdf |
49 страниц, текст | Ранняя близкая версия, сопоставление содержания |
2025-04-24 - Пиков - УЦ Маском - v.003 (с 117 приказом).pdf |
58 страниц; историческая схема с. 5 просмотрена визуально | Обзорное исследование MLR и логика исторического вступления |
1. Техническое задание_аудит DevSecOps (без бренда).pdf |
6 страниц | Структура обследования, границы, интервью, целевое состояние и планирование |
2025.07.02 Вебинар1 по РБПО с PVS-STUDIO (РАЗДАВАТЬ)\Secure Software Development Methodologies. A Multivocal Literature Review - 2023.pdf |
Полностью, 27 страниц; с. 5–9 просмотрены визуально | Карта публикаций, сопоставление практик и ограничений оценки эффективности |
2025.07.02 Вебинар1 по РБПО с PVS-STUDIO (РАЗДАВАТЬ)\История+создания+РБПО+ГОСТ+Р+56939-202x.pdf |
Полностью, 26 страниц; с. 1–4, 22–23 просмотрены визуально | Предпосылки, история подготовки 2013–2015, обсуждение и международные связи |
2025.07.02 Вебинар1 по РБПО с PVS-STUDIO (РАЗДАВАТЬ)\ГОСТ Р 56939-2016 (редакция 2016).pdf |
24 страницы; извлечён полный текст; для истории проверены предисловие, оглавление, разделы 1, 2, 4, структура 5 и приложение А; с. 2, 3, 8 просмотрены визуально | Авторство и даты; 9 групп мер вместо неподтверждённых «14»; прежняя нормативная сила «следует»; связь с Common Criteria и 27034 |
При первоначальной подготовке чтение отдельных облачных исторических файлов зависало. После уточнения пользователя точные PDF-копии из подпапки «РАЗДАВАТЬ» успешно прочитаны; ограничение доступа к ним снято. Затем пользователь добавил полный транскрипт непосредственно в EP01; прежняя констатация его отсутствия больше не актуальна. Не заявляется чтение всех одноимённых PPTX или просмотр видео. Расхождения дат, проектных схем, устных оценок и финальных требований перечислены в историческом разборе.
Из архива исключены неподтверждённые универсальные 10–15% удорожания (с. 38), прогноз стандарта к концу 2025 года (с. 28), абсолютное утверждение о невозможности мер без CI/CD (с. 15), прежние рекламные/скидочные блоки. История пересмотра со слайдов не выдаётся за официальный протокол мотивов разработчиков стандарта. Образец ТЗ не выдаётся за доказательство завершённого клиентского внедрения.
Полный текст требований: V:\pikov.art\56939-lections\laws\ГОСТ_Р_56939_2024_Национальный_стандарт_Российской_Федерац.docx и одноимённый PDF (40 страниц, сохранение КонсультантПлюс 10.06.2025; процесс 5.1 на PDF-с. 8–9). Это рабочая локальная копия, не заявленная оригинальной публикацией Росстандарта. Проект 20ХХ не использован как нормативная база.
Исходный Markdown целиком
# EP01 — Источники и границы выводов
Проверка: **6 сентября 2026 года**, включая доработку по полному транскрипту вебинара 02.07.2025 и архивному финальному ГОСТ Р 56939-2016. Ранее полностью прочитаны два точных PDF из подпапки «РАЗДАВАТЬ»: обзор методологий — 27 страниц, доклад Вареницы — 26. Для копии G16 извлечён текст всех 24 PDF-страниц и проверены относящиеся к истории разделы; предисловие, оглавление и общие положения просмотрены визуально. Детальный разбор, карта 28 публикаций и исправленные расхождения — в [EP01-history-research.md](EP01-history-research.md). Основа текущих требований — локальный текст окончательной редакции G24, не проект «20ХХ» и не устный пересказ. Краткие ID используются в сценарии и презентации; текущий выпуск — 29 слайдов, план 53:00.
## Реестр внешних источников
| ID | Источник / версия | Использованный тезис и граница |
|---|---|---|
| G24 | [Росстандарт: ГОСТ Р 56939-2024](https://protect.gost.ru/gost/details/f3818925-a96f-4f55-96e9-46b44720ee64) | Утверждён 24.10.2024 приказом 1504-ст, введён 20.12.2024, заменяет 2016. Содержание требований прочитано в локальном полном тексте |
| G16 | [Росстандарт: ГОСТ Р 56939-2016](https://protect.gost.ru/gost/details/286a588e-4a6a-4899-88f7-3c370dea1e1d); локальный PDF «ГОСТ Р 56939-2016 (редакция 2016).pdf» | Росстандарт, приказ 458-ст от 01.06.2016; введён 01.06.2017. Предисловие: ЗАО НПО «Эшелон», ТК 362. 9 тематических подразделов 5.1–5.9; п. 4.2: «следует» — рекомендация; п. 4.5: компенсирующие меры; раздел 1 и приложение А: связи с 27034 и 15408 |
| WARE | [RAND: Security Controls for Computer Systems](https://www.rand.org/pubs/reports/R609-1.html) | Доклад первоначально опубликован в феврале 1970; 1979 на странице — переиздание. Не стандарт SSDLC |
| SS75 | [Saltzer–Schroeder: оригинальная статья](https://web.mit.edu/saltzer/www/publications/protection/index.html), [библиография автора](https://web.mit.edu/saltzer/www/publications/pubs.html) | September 1975, Proceedings of the IEEE 63(9), 1278–1308. Два принципа — выборка, не вся статья |
| MSH | [Microsoft: история SDL](https://www.microsoft.com/en-us/securityengineering/sdl/about) | Trustworthy Computing — январь 2002; SDL как часть разработки Microsoft — 2004. Не утверждается первенство Microsoft во всей области |
| RH | [Омский ЦСМ: исторические вехи Росстандарта](https://csm.omsk.ru/about/90-years/rosstandart-istor-vehi/16107/) | Комитет по стандартизации — 15.09.1925. Институциональная история, не дата возникновения практик безопасной разработки |
| N11 | [NIST SP 800-218, SSDF 1.1 final](https://csrc.nist.gov/pubs/sp/800/218/final), [Table 1 полного текста](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf) | Финальная редакция 03.02.2022; узкое сопоставление с PO.2.1 |
| N19 | [NIST: анонс проекта SSDF](https://csrc.nist.gov/News/2019/draft-white-paper-on-ssdf) | Дата анонса 11.06.2019; draft. Служебное Created 07.06.2019 не подменяет дату новости. Источник для хронологии, не доказательство заимствования в любом направлении |
| N20 | [NIST: публикация SSDF 1.0](https://csrc.nist.gov/news/2020/mitigating-risk-of-software-vulns-ssdf), [white paper](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04232020.pdf) | Финальный white paper от 23.04.2020; не путать с draft 2019 или SP 800-218 / 1.1 от 2022 |
| N12 | [SSDF 1.2 initial public draft](https://csrc.nist.gov/pubs/sp/800/218/r1/ipd), [реестр SSDF](https://csrc.nist.gov/Projects/ssdf/publications) | Проект 17.12.2025 остаётся обозначен draft на дату проверки. В выпуске не подменяет final 1.1 |
| SAMM | [OWASP SAMM, Strategy and Metrics, stream A](https://owaspsamm.org/model/governance/strategy-and-metrics/stream-a/) | База модели SAMM 2.0, живая веб-документация; для сравнения конкретно G-SM-A-2 |
| MLR | Локальный PDF; [Kudriavtseva & Gadyatskaya, arXiv:2211.16987v2](https://arxiv.org/html/2211.16987v2), [метаданные](https://arxiv.org/abs/2211.16987) | Препринт v2 от 04.07.2023, In submission; 27 страниц прочитаны. Table II, Figure 2, практики и ограничения эффективности; не доказательство уникальности ГОСТ |
| SAMM20 | [OWASP SAMM v2 public release](https://owaspsamm.org/blog/samm2-release/) | Подтверждение выпуска версии 2 от 31.01.2020 для шкалы публикаций |
| GOSTH | Локальный PDF: Вареница Виталий, «История создания и актуальное состояние РБПО в России. ГОСТ Р 56939-2016/24» | 26 страниц, экспорт PDF 02.07.2025; с. 2–4 — предпосылки и разработка, с. 3/22 — международные связи. Дата утверждения и фрагменты проекта уточнены по официальной карточке и финальному тексту |
| TRANS | [Полный транскрипт вебинара 02.07.2025](Транскрипция%202025.07.02%20Вебинар%201%20по%20РБПО%20с%20PVS-STUDIO.mp4.txt) | Метки 00:00:05–02:07:28; исходный текст пользователя, не официальный протокол. Времена исторических тезисов и исправления ASR — в историческом разборе. Все реплики размечены «Участник 1», поэтому автоматическая атрибуция голосов не подтверждена. Само видео не просматривалось |
| EX | Авторский учебный пример | Продукт, наблюдения, часы, график, роли и триггеры пересмотра придуманы для объяснения; внешней эмпирической оценки нет |
## Исследование из прежних материалов
Arina Kudriavtseva и Olga Gadyatskaya, *Secure Software Development Methodologies: A Multivocal Literature Review*. Авторы рассматривают 28 методологий из отрасли, государственных и академических источников, опубликованных в 2004–2022 годах; анализируют технические и организационные практики и опубликованные сведения об эффективности.
В разделе III перед Figure 2 прямо отмечено: дата публикации может отличаться от даты появления подхода. Пример — SDL внедрялся в Microsoft с 2004 года, хотя рассмотренная книга опубликована в 2006. Более того, Figure 2 и Table II на PDF-с. 5 расходятся по нескольким позициям. Поэтому слайд 5 содержит самостоятельно составленную шкалу выбранных публикаций/редакций с явным типом даты; исходный рисунок не перенесён целиком.
Обзор ограничен критериями отбора, доступностью и английским языком источников; это не перепись всей мировой практики. Используем его для карты методологий (слайд 5), различий способов организации работ (6) и ограничений выводов об эффективности (14). Утверждений о доказанном количественном снижении уязвимостей по этому обзору в сценарии нет. Источники WARE, SS75 и RH остаются дополнительным контекстом вне основной речи обновлённого исторического блока.
## Точный нормативный конспект процесса 5.1
| Пункт | Смысл для автора | Где раскрыт |
|---|---|---|
| 5.1.2.1 / 5.1.3.1 | Периодический анализ состояния; реализованные и нереализованные процессы; оценка достаточности и соответствия с учётом применимых стандартов, инструментов и технологий | Слайды 16, 18, 22; пример §2 |
| 5.1.2.2 / 5.1.3.2 | Периодический анализ потребностей в ресурсах; оценочные материальные/людские показатели в описании артефакта допустимы («могут содержать») | Слайды 16, 19; пример §3 |
| 5.1.2.3 / 5.1.3.3 | План развития с учётом двух анализов; очередность, приоритеты, ресурсы, организационные изменения, инструменты и обучение | Слайды 16, 20–22; пример §4 |
| 5.1.2.4 / 5.1.3.4 | План реализации с учётом анализов; цели, сроки, этапы, ресурсы, ответственные сотрудники | Слайды 16, 18, 20–22; пример §5 |
| 5.1.2.5 / 5.1.3.5 | Определение области; состав ПО и обоснование выбора состава | Слайды 16–17, 22; пример §1 |
Оба плана допустимо представить в системе управления задачами. Пять видов информации не означают обязательные пять отдельных файлов. План на 90 дней — учебный вариант; полная оценка всех процессов не выполнена.
Дополнительные пункты: 4.3 — независимость от модели жизненного цикла; 4.5 — участие руководства и ресурсы; 4.7 — и «должен», и «следует» выражают требование; 4.11 — разные формы сохранённых свидетельств; 4.12 — формат регламентов не предписан; 4.13 — контроль версий, непрерывная интеграция и управление задачами, включая отслеживание ошибок. Подмена CI на обязательный CD недопустима. Пункты 4.14–4.15 не используются для вывода, что стандарт автоматически обязателен для каждой команды.
## Два ограниченных сопоставления для слайда 23
| Поле | Ответственность | Развитие процессов |
|---|---|---|
| ГОСТ | 5.1.3.4, ответственные сотрудники в плане реализации; требуемое содержание артефакта | 5.1.2.3 и 5.1.3.3; требование планировать развитие на основе анализов |
| Международный фрагмент | SSDF 1.1, PO.2.1: жизненный цикл ролей и ответственности; задача рекомендательного framework | SAMM, G-SM-A-2: стратегия, бюджет и этапы дорожной карты; деятельность модели зрелости |
| Общая часть | Ясная ответственность за работу | Организация последовательного улучшения с ресурсами и этапами |
| Различия | В ГОСТ артефакт содержит также цели, сроки, этапы и ресурсы; PO.2.1 шире конкретного плана по роли в lifecycle | SAMM задаёт контекст зрелости программы; ГОСТ — определённые требования и содержание артефактов |
| Учебное применение | Владелец задачи, ответственный за решение, ссылка на политику полномочий | Обоснованная очередь изменений и связанные задачи |
| Вывод | **Partial overlap**, узкая пара, уверенность средняя | **Partial overlap**, узкая пара, уверенность средняя |
Проверка содержания выполнена при подготовке, внешнего рецензента не было. Нормативная сила сторон различается. Эти две пары не являются полной матрицей 5.1 и не подтверждают юридическую/сертификационную эквивалентность. Направления дальнейшего анализа: SSDF PO.1/PO.3/PO.4 и остальные активности SAMM; статус полного сопоставления — **Not assessed**.
## Российское семейство: справка вне основного хронометража
ГОСТ Р 56939 не исчерпывает российские документы по теме. Примеры: ГОСТ Р 58412-2019 — угрозы безопасности информации при разработке; ГОСТ Р 71206-2024 — безопасный компилятор C/C++, общие требования; ГОСТ Р 71207-2024 — статический анализ ПО, общие требования. Проверены [каталог 58412](https://protect.gost.ru/gost?month=0&page=2175&search=&year=0), [каталог 71206](https://protect.gost.ru/gost?month=0&page=2328&search=&year=0), [карточка 71207](https://protect.gost.ru/gost/details/9dd6f064-6014-4416-a3ca-ef72ce0a6c3a). Это три примера, а не полный реестр. Детали этих документов не приписываются требованиям процесса 5.1.
## Использование архива PVS-Studio
База: `V:\Yandex.Disk\_МАСКОМ\2025 Вебинары по РБПО с PVS-STUDIO\2025.07.02 Вебинар1 по РБПО с PVS-STUDIO`. Пользователь прямо разрешил свободное использование этих материалов в текущей задаче; дополнительного разрешения не требуется.
| Файл относительно базы | Проверенный объём | Что использовано |
|---|---|---|
| `2025.07.02 Вебинар1 по РБПО с PVS-STUDIO (РАЗДАВАТЬ)\2025.07.02 Вебинар 1 по РБПО с PVS-STUDIO.pdf` | 54 страницы; текст, выборочная визуальная проверка | С. 6–8 — прежняя идея серии; 13–19 — авторское объяснение эволюции; 26–29 — цель/требования/свидетельства; 37–45 — процесс 5.1 |
| `1.pdf` | 49 страниц, текст | Ранняя близкая версия, сопоставление содержания |
| `2025-04-24 - Пиков - УЦ Маском - v.003 (с 117 приказом).pdf` | 58 страниц; историческая схема с. 5 просмотрена визуально | Обзорное исследование MLR и логика исторического вступления |
| `1. Техническое задание_аудит DevSecOps (без бренда).pdf` | 6 страниц | Структура обследования, границы, интервью, целевое состояние и планирование |
| `2025.07.02 Вебинар1 по РБПО с PVS-STUDIO (РАЗДАВАТЬ)\Secure Software Development Methodologies. A Multivocal Literature Review - 2023.pdf` | Полностью, 27 страниц; с. 5–9 просмотрены визуально | Карта публикаций, сопоставление практик и ограничений оценки эффективности |
| `2025.07.02 Вебинар1 по РБПО с PVS-STUDIO (РАЗДАВАТЬ)\История+создания+РБПО+ГОСТ+Р+56939-202x.pdf` | Полностью, 26 страниц; с. 1–4, 22–23 просмотрены визуально | Предпосылки, история подготовки 2013–2015, обсуждение и международные связи |
| `2025.07.02 Вебинар1 по РБПО с PVS-STUDIO (РАЗДАВАТЬ)\ГОСТ Р 56939-2016 (редакция 2016).pdf` | 24 страницы; извлечён полный текст; для истории проверены предисловие, оглавление, разделы 1, 2, 4, структура 5 и приложение А; с. 2, 3, 8 просмотрены визуально | Авторство и даты; 9 групп мер вместо неподтверждённых «14»; прежняя нормативная сила «следует»; связь с Common Criteria и 27034 |
При первоначальной подготовке чтение отдельных облачных исторических файлов зависало. После уточнения пользователя точные PDF-копии из подпапки «РАЗДАВАТЬ» успешно прочитаны; ограничение доступа к ним снято. Затем пользователь добавил полный транскрипт непосредственно в EP01; прежняя констатация его отсутствия больше не актуальна. Не заявляется чтение всех одноимённых PPTX или просмотр видео. Расхождения дат, проектных схем, устных оценок и финальных требований перечислены в [историческом разборе](EP01-history-research.md).
Из архива исключены неподтверждённые универсальные 10–15% удорожания (с. 38), прогноз стандарта к концу 2025 года (с. 28), абсолютное утверждение о невозможности мер без CI/CD (с. 15), прежние рекламные/скидочные блоки. История пересмотра со слайдов не выдаётся за официальный протокол мотивов разработчиков стандарта. Образец ТЗ не выдаётся за доказательство завершённого клиентского внедрения.
Полный текст требований: `V:\pikov.art\56939-lections\laws\ГОСТ_Р_56939_2024_Национальный_стандарт_Российской_Федерац.docx` и одноимённый PDF (40 страниц, сохранение КонсультантПлюс 10.06.2025; процесс 5.1 на PDF-с. 8–9). Это рабочая локальная копия, не заявленная оригинальной публикацией Росстандарта. Проект `20ХХ` не использован как нормативная база.
SHA-256: 7160c835519e67037bc3efe89e770d1beb4c2efd2bc96a0b34783888f721e83a
11EP01 — соответствие речи слайдам и реальный ориентир по времениEP01-speech-review.md
EP01 — соответствие речи слайдам и реальный ориентир по времени
Проверено 6 сентября 2026 года. Сопоставлены все 25 блоков Speech: в английском сценарии, заметки презентации, видимые пункты и 16 английских SVG.
Вывод
Речь соответствует слайдам и по объёму не является короткой. Основных содержательных противоречий не обнаружено. После точечных уточнений в ней 4327 слов. Старый план на 40:00 был неравномерным: у части исторических слайдов оставался большой запас, тогда как сравнения и схемы почти не оставляли времени на показ.
Рабочие слоты перераспределены; новый план — 53:00, включая паузы и округление. Это ориентир для репетиции, а не замер записанного выступления. При спокойной подаче разумно ожидать примерно 40–44 минуты; при более быстром темпе выпуск может закончиться раньше. Нет необходимости растягивать коротко и ясно изложенный материал.
Что уточнено
- Слайд 4: добавлено указание на разрыв между находкой и расследованием.
- Слайд 12: речь и подпись явно связывают Recommendation / Requirement с одним термином исходного текста, чтобы слушатель не относил ярлык ко всем положениям редакции.
- Слайд 13: объяснение следует узлам цикла, затем возвращает внимание к версии продукта и свидетельствам в центре.
- Слайд 15: добавлен недостающий устный разбор шага Demonstrate.
- Слайд 19: устаревшее слово table заменено на chart.
- Слайд 20: явно объяснены средний и правый блоки рисунка.
- Слайд 24: авторская подсказка исправлена под пять узлов схемы.
Добавилось 58 слов к исходным 4269 — за счёт пояснения рисунков. Слайды 7, 8 и 23 не расширялись ради заполнения прежнего двухминутного слота.
Модель времени
Формула для слайда: время = число слов × 60 / темп + отдельные паузы на осмотр и переход. Для рабочих слотов взят сценарий 120 слов/мин, после чего каждый результат округлён вверх до ближайших пяти секунд.
Паузы в таблице — редакционные предположения по сложности материала. Их сумма — 316 секунд, или 5:16. Они распределяются короткими остановками внутри объяснения, а не одной длинной паузой в конце слайда. Их нельзя второй раз добавлять к темпу, уже измеренному по полному выступлению со всеми остановками.
| Сценарий темпа | Только текст | Паузы модели | Всего до округления слотов |
|---|---|---|---|
| 110 слов/мин | 39:20 | 05:16 | 44:36 |
| 115 слов/мин | 37:38 | 05:16 | 42:54 |
| 120 слов/мин | 36:04 | 05:16 | 41:20 |
| 125 слов/мин | 34:37 | 05:16 | 39:53 |
| 130 слов/мин | 33:17 | 05:16 | 38:33 |
При 120 словах/мин расчёт даёт 36:04 текста + 5:16 пауз ≈ 41:20. Округление отдельных слотов добавляет около минуты резерва: итог 53:00. Это не статистический доверительный интервал и не измеренный темп автора.
Подсчёт основан на письменных английских словах. Названия стандартов, номера пунктов, фамилии и аббревиатуры могут занимать больше времени, чем подсказывает число токенов. Определять окончательные timestamps по таблице до записи нельзя.
Слайд 12 отдельно
После уточнения — 182 слова. При 120 словах/мин текст занимает 1:31, а 12 секунд на сравнение двух колонок дают 1:43. Новый слот 1:45 выглядит обоснованнее прежнего 1:30. Речь поясняет обе структуры и разную силу одного термина; источники и даты остаются привязаны к конкретным редакциям.
Все 29 слайдов
Паузы и новый слот заданы для сценария 120 слов/мин. Полные интервалы синхронизированы в сценарии, данных презентации, плане и черновике глав публикации.
| № | Слова | Старый слот | Паузы модели, с | Новый слот | Соответствие речи видимому содержанию |
|---|---|---|---|---|---|
| 01 | 112 | 01:00 | 5 | 01:05 | Да. Представление автора, вопрос серии и задачи выпуска. |
| 02 | 166 | 01:30 | 8 | 01:35 | Да. Все три результата: понять, сравнить, применить. |
| 03 | 162 | 01:30 | 12 | 01:35 | Да. Четыре авторские группы процессов и связи между ними. |
| 04 | 213 | 02:00 | 12 | 02:00 | Да. Вымышленный импортер и разрыв между находкой и расследованием; добавлен прямой указатель на разрыв схемы. |
| 05 | 169 | 01:30 | 16 | 01:45 | Да. Все шесть вех; публикации и редакции отделены от происхождения идей. |
| 06 | 165 | 01:30 | 12 | 01:35 | Да. Все четыре подхода; дополнительные модели в речи не противоречат карточкам. |
| 07 | 162 | 02:00 | 10 | 01:35 | Да. Практическая проблема и ранние обсуждения. |
| 08 | 172 | 02:00 | 16 | 01:45 | Да. Все этапы подготовки; утверждение и вступление в силу различены. |
| 09 | 181 | 01:30 | 10 | 01:45 | Да. Разработчик, рецензенты и аудитории различены. |
| 10 | 163 | 01:30 | 10 | 01:35 | Да. Семейство документов, принятые редакции и рабочие материалы различены. |
| 11 | 217 | 02:00 | 16 | 02:05 | Да. Все четыре даты и граница вывода о происхождении документов. |
| 12 | 182 | 01:30 | 12 | 01:45 | Да. 9 групп / 25 процессов; подписи относятся к силе одного термина, что теперь прямо сказано и показано. |
| 13 | 173 | 01:30 | 12 | 01:40 | Да. Речь теперь последовательно проходит по циклу и связывает центр рисунка с версией продукта. |
| 14 | 158 | 01:30 | 10 | 01:30 | Да. Все три тезиса о практиках и границах доказательств. |
| 15 | 187 | 01:30 | 12 | 01:50 | Да. Отдельно добавлено объяснение шага Demonstrate и проверяемых свидетельств. |
| 16 | 173 | 01:30 | 16 | 01:45 | Да. Все пять требований и связь двух планов объяснены. |
| 17 | 174 | 01:30 | 12 | 01:40 | Да. Граница продукта, контекст и обоснование исключения. |
| 18 | 164 | 01:30 | 10 | 01:35 | Да. Все четыре роли и реальные исходные проблемы. |
| 19 | 162 | 01:30 | 14 | 01:35 | Да. 60 + 24 + 12 = 96; исправлена устаревшая ссылка table → chart. |
| 20 | 170 | 01:30 | 12 | 01:40 | Да. Два плана; речь теперь прямо показывает задачу в середине и свидетельства справа. |
| 21 | 229 | 02:00 | 18 | 02:15 | Да. Все три этапа плана и их результаты; самый длинный текст после истории международных связей. |
| 22 | 161 | 01:30 | 14 | 01:35 | Да. Все пять категорий записей и связь с областью применения. |
| 23 | 174 | 02:00 | 20 | 01:50 | Да. Оба частичных сопоставления; объяснение границ вывода. |
| 24 | 163 | 01:30 | 12 | 01:35 | Да. Расследование, ответственность и решение; подсказка автору обновлена под пять узлов рисунка. |
| 25 | 175 | 01:30 | 15 | 01:45 | Да. Контакты, pikov.art, полное название EP02 и три темы следующего выпуска. |
Наиболее заметные изменения: слайд 7 — 2:00 → 1:35; слайд 8 — 2:00 → 1:45; слайд 12 — 1:30 → 1:45; слайд 15 — 1:30 → 1:50; слайд 21 — 2:00 → 2:15; слайд 23 — 2:00 → 1:50. Общая длительность выросла за счёт размещения пауз там, где слушателю действительно нужно осмотреть схему.
Как проверить на собственной речи
- Записать слайды 5, 12 и 21 с рисунками и естественными остановками. Они проверяют хронологию, сравнение и подробный пример.
- Записать фактическое время от начала первого слова до перехода на следующий слайд. Для этого способа измерения дополнительные паузы уже входят в результат.
- Сравнить с рабочими слотами 1:45 / 1:45 / 2:15. Отметить места, где приходится спешить или, наоборот, ждать.
- Сделать полный проход. Не навёрстывать отставание ускорением фамилий и номеров стандартов; перераспределять слоты или убирать повторения.
В записи с монтажом итогом служит ясное законченное объяснение. Если фактическая версия займёт 39 или 44 минуты и все обещанные вопросы раскрыты, это само по себе не является недостатком.
Источники проверки и ограничения
- Полная английская речь: редактируемый источник.
- Каталог рисунков: видимое содержание схем.
- Данные презентации: речь в браузере и слоты.
- Пересчитанный хронометраж.
- Памятка репетиции.
Проверено совпадение всех 25 блоков речи в Markdown и данных браузера, сохранение 16 английских схем и отсутствие кириллицы в английских данных. Аудиозапись новой английской репетиции в этой задаче не предоставлялась; произношение, индивидуальный темп и фактическая длительность ещё не измерены.
Исходный Markdown целиком
# EP01 — соответствие речи слайдам и реальный ориентир по времени
Проверено 6 сентября 2026 года. Сопоставлены все 25 блоков `Speech:` в английском сценарии, заметки презентации, видимые пункты и 16 английских SVG.
## Вывод
**Речь соответствует слайдам и по объёму не является короткой.** Основных содержательных противоречий не обнаружено. После точечных уточнений в ней **4327 слов**. Старый план на 40:00 был неравномерным: у части исторических слайдов оставался большой запас, тогда как сравнения и схемы почти не оставляли времени на показ.
Рабочие слоты перераспределены; новый план — **53:00**, включая паузы и округление. Это ориентир для репетиции, а не замер записанного выступления. При спокойной подаче разумно ожидать примерно 40–44 минуты; при более быстром темпе выпуск может закончиться раньше. Нет необходимости растягивать коротко и ясно изложенный материал.
## Что уточнено
- Слайд 4: добавлено указание на разрыв между находкой и расследованием.
- Слайд 12: речь и подпись явно связывают Recommendation / Requirement с одним термином исходного текста, чтобы слушатель не относил ярлык ко всем положениям редакции.
- Слайд 13: объяснение следует узлам цикла, затем возвращает внимание к версии продукта и свидетельствам в центре.
- Слайд 15: добавлен недостающий устный разбор шага Demonstrate.
- Слайд 19: устаревшее слово table заменено на chart.
- Слайд 20: явно объяснены средний и правый блоки рисунка.
- Слайд 24: авторская подсказка исправлена под пять узлов схемы.
Добавилось **58 слов** к исходным 4269 — за счёт пояснения рисунков. Слайды 7, 8 и 23 не расширялись ради заполнения прежнего двухминутного слота.
## Модель времени
Формула для слайда: **время = число слов × 60 / темп + отдельные паузы на осмотр и переход**. Для рабочих слотов взят сценарий **120 слов/мин**, после чего каждый результат округлён вверх до ближайших пяти секунд.
Паузы в таблице — редакционные предположения по сложности материала. Их сумма — **316 секунд, или 5:16**. Они распределяются короткими остановками внутри объяснения, а не одной длинной паузой в конце слайда. Их нельзя второй раз добавлять к темпу, уже измеренному по полному выступлению со всеми остановками.
| Сценарий темпа | Только текст | Паузы модели | Всего до округления слотов |
|---|---|---|---|
| 110 слов/мин | 39:20 | 05:16 | 44:36 |
| 115 слов/мин | 37:38 | 05:16 | 42:54 |
| 120 слов/мин | 36:04 | 05:16 | 41:20 |
| 125 слов/мин | 34:37 | 05:16 | 39:53 |
| 130 слов/мин | 33:17 | 05:16 | 38:33 |
При 120 словах/мин расчёт даёт **36:04 текста + 5:16 пауз ≈ 41:20**. Округление отдельных слотов добавляет около минуты резерва: итог **53:00**. Это не статистический доверительный интервал и не измеренный темп автора.
Подсчёт основан на письменных английских словах. Названия стандартов, номера пунктов, фамилии и аббревиатуры могут занимать больше времени, чем подсказывает число токенов. Определять окончательные timestamps по таблице до записи нельзя.
## Слайд 12 отдельно
После уточнения — **182 слова**. При 120 словах/мин текст занимает **1:31**, а 12 секунд на сравнение двух колонок дают **1:43**. Новый слот **1:45** выглядит обоснованнее прежнего 1:30. Речь поясняет обе структуры и разную силу одного термина; источники и даты остаются привязаны к конкретным редакциям.
## Все 29 слайдов
Паузы и новый слот заданы для сценария 120 слов/мин. Полные интервалы синхронизированы в сценарии, данных презентации, плане и черновике глав публикации.
| № | Слова | Старый слот | Паузы модели, с | Новый слот | Соответствие речи видимому содержанию |
|---|---:|---|---:|---|---|
| 01 | 112 | 01:00 | 5 | 01:05 | Да. Представление автора, вопрос серии и задачи выпуска. |
| 02 | 166 | 01:30 | 8 | 01:35 | Да. Все три результата: понять, сравнить, применить. |
| 03 | 162 | 01:30 | 12 | 01:35 | Да. Четыре авторские группы процессов и связи между ними. |
| 04 | 213 | 02:00 | 12 | 02:00 | Да. Вымышленный импортер и разрыв между находкой и расследованием; добавлен прямой указатель на разрыв схемы. |
| 05 | 169 | 01:30 | 16 | 01:45 | Да. Все шесть вех; публикации и редакции отделены от происхождения идей. |
| 06 | 165 | 01:30 | 12 | 01:35 | Да. Все четыре подхода; дополнительные модели в речи не противоречат карточкам. |
| 07 | 162 | 02:00 | 10 | 01:35 | Да. Практическая проблема и ранние обсуждения. |
| 08 | 172 | 02:00 | 16 | 01:45 | Да. Все этапы подготовки; утверждение и вступление в силу различены. |
| 09 | 181 | 01:30 | 10 | 01:45 | Да. Разработчик, рецензенты и аудитории различены. |
| 10 | 163 | 01:30 | 10 | 01:35 | Да. Семейство документов, принятые редакции и рабочие материалы различены. |
| 11 | 217 | 02:00 | 16 | 02:05 | Да. Все четыре даты и граница вывода о происхождении документов. |
| 12 | 182 | 01:30 | 12 | 01:45 | Да. 9 групп / 25 процессов; подписи относятся к силе одного термина, что теперь прямо сказано и показано. |
| 13 | 173 | 01:30 | 12 | 01:40 | Да. Речь теперь последовательно проходит по циклу и связывает центр рисунка с версией продукта. |
| 14 | 158 | 01:30 | 10 | 01:30 | Да. Все три тезиса о практиках и границах доказательств. |
| 15 | 187 | 01:30 | 12 | 01:50 | Да. Отдельно добавлено объяснение шага Demonstrate и проверяемых свидетельств. |
| 16 | 173 | 01:30 | 16 | 01:45 | Да. Все пять требований и связь двух планов объяснены. |
| 17 | 174 | 01:30 | 12 | 01:40 | Да. Граница продукта, контекст и обоснование исключения. |
| 18 | 164 | 01:30 | 10 | 01:35 | Да. Все четыре роли и реальные исходные проблемы. |
| 19 | 162 | 01:30 | 14 | 01:35 | Да. 60 + 24 + 12 = 96; исправлена устаревшая ссылка table → chart. |
| 20 | 170 | 01:30 | 12 | 01:40 | Да. Два плана; речь теперь прямо показывает задачу в середине и свидетельства справа. |
| 21 | 229 | 02:00 | 18 | 02:15 | Да. Все три этапа плана и их результаты; самый длинный текст после истории международных связей. |
| 22 | 161 | 01:30 | 14 | 01:35 | Да. Все пять категорий записей и связь с областью применения. |
| 23 | 174 | 02:00 | 20 | 01:50 | Да. Оба частичных сопоставления; объяснение границ вывода. |
| 24 | 163 | 01:30 | 12 | 01:35 | Да. Расследование, ответственность и решение; подсказка автору обновлена под пять узлов рисунка. |
| 25 | 175 | 01:30 | 15 | 01:45 | Да. Контакты, pikov.art, полное название EP02 и три темы следующего выпуска. |
Наиболее заметные изменения: слайд 7 — 2:00 → 1:35; слайд 8 — 2:00 → 1:45; слайд 12 — 1:30 → 1:45; слайд 15 — 1:30 → 1:50; слайд 21 — 2:00 → 2:15; слайд 23 — 2:00 → 1:50. Общая длительность выросла за счёт размещения пауз там, где слушателю действительно нужно осмотреть схему.
## Как проверить на собственной речи
1. Записать слайды 5, 12 и 21 с рисунками и естественными остановками. Они проверяют хронологию, сравнение и подробный пример.
2. Записать фактическое время от начала первого слова до перехода на следующий слайд. Для этого способа измерения дополнительные паузы уже входят в результат.
3. Сравнить с рабочими слотами 1:45 / 1:45 / 2:15. Отметить места, где приходится спешить или, наоборот, ждать.
4. Сделать полный проход. Не навёрстывать отставание ускорением фамилий и номеров стандартов; перераспределять слоты или убирать повторения.
В записи с монтажом итогом служит ясное законченное объяснение. Если фактическая версия займёт 39 или 44 минуты и все обещанные вопросы раскрыты, это само по себе не является недостатком.
## Источники проверки и ограничения
- [Полная английская речь](EP01-script-en.md): редактируемый источник.
- [Каталог рисунков](EP01-visuals.md): видимое содержание схем.
- [Данные презентации](assets/episode-data.js): речь в браузере и слоты.
- [Пересчитанный хронометраж](EP01-timing.md).
- [Памятка репетиции](EP01-rehearsal.md).
Проверено совпадение всех 25 блоков речи в Markdown и данных браузера, сохранение 16 английских схем и отсутствие кириллицы в английских данных. Аудиозапись новой английской репетиции в этой задаче не предоставлялась; произношение, индивидуальный темп и фактическая длительность ещё не измерены.
SHA-256: 6cea2fa4b11a87fb7f526fd431ffc179ead36327e02ec2710e67aa9ec676876b
12EP01 — Timing and rehearsal modelEP01-timing.md
EP01 — Timing and rehearsal model
Generated from the full English script. Timing slots total 53:10. Count uses written English word tokens, including contractions and hyphenated words. Acronyms and numeric designations may take longer to pronounce than this token count suggests; only a recorded rehearsal establishes the actual duration.
| Slide | Start–end | Slot | Speech words | Words/min in slot |
|---|---|---|---|---|
| 01. Where secure development begins | 00:00–01:05 | 01:05 | 117 | 108.0 |
| 02. One process. One useful result. | 01:05–02:40 | 01:35 | 182 | 114.9 |
| 03. Twenty-five processes, connected | 02:40–04:15 | 01:35 | 177 | 111.8 |
| 04. Friday's release is blocked | 04:15–06:15 | 02:00 | 234 | 117.0 |
| 05. Three documents before the methodologies | 06:15–08:30 | 02:15 | 238 | 105.8 |
| 06. From evaluating systems to building them | 08:30–10:50 | 02:20 | 238 | 102.0 |
| 07. A landscape of secure development methods | 10:50–12:35 | 01:45 | 180 | 102.9 |
| 08. Different ways to organize the work | 12:35–14:10 | 01:35 | 183 | 115.6 |
| 09. Before the standard: a practical problem | 14:10–15:45 | 01:35 | 178 | 112.4 |
| 10. The route from research to publication | 15:45–17:30 | 01:45 | 179 | 102.3 |
| 11. Who wrote it, and who was it for? | 17:30–19:50 | 02:20 | 274 | 117.4 |
| 12. A wider plan than one published document | 19:50–21:25 | 01:35 | 156 | 98.5 |
| 13. GOST in the international context | 21:25–23:30 | 02:05 | 231 | 110.9 |
| 14. Two editions, different structures | 23:30–25:15 | 01:45 | 241 | 137.7 |
| 15. A process continues after the first tool run | 25:15–26:55 | 01:40 | 182 | 109.2 |
| 16. When this standard actually binds | 26:55–29:15 | 02:20 | 276 | 118.3 |
| 17. Shared practices need evidence | 29:15–30:45 | 01:30 | 171 | 114.0 |
| 18. Compare obligations, not labels | 30:45–32:35 | 01:50 | 195 | 106.4 |
| 19. What process 5.1 asks for | 32:35–35:00 | 02:25 | 309 | 127.9 |
| 20. Start with a defensible scope | 35:00–36:40 | 01:40 | 203 | 121.8 |
| 21. Assess reality and assign owners | 36:40–38:15 | 01:35 | 184 | 116.2 |
| 22. Resources include human attention | 38:15–39:50 | 01:35 | 183 | 115.6 |
| 23. Two plans, two questions | 39:50–41:30 | 01:40 | 185 | 111.0 |
| 24. A 90-day plan for the importer | 41:30–43:45 | 02:15 | 244 | 108.4 |
| 25. Five linked records of evidence | 43:45–45:20 | 01:35 | 177 | 111.8 |
| 26. Every process is written the same way | 45:20–47:50 | 02:30 | 276 | 110.4 |
| 27. A first international crosswalk | 47:50–49:40 | 01:50 | 196 | 106.9 |
| 28. Would this survive Friday's release? | 49:40–51:15 | 01:35 | 181 | 114.3 |
| 29. Security Training That Changes Engineering Decisions | 51:15–53:10 | 01:55 | 203 | 105.9 |
Total: 5973 spoken words.
Speaking pace sensitivity
| Articulation pace | Speech alone | Space left inside 53:10 for pauses/transitions |
|---|---|---|
| 110 words/min | 54:18 | exceeds slot by 01:08 |
| 115 words/min | 51:56 | 01:14 |
| 120 words/min | 49:46 | 03:24 |
| 125 words/min | 47:47 | 05:23 |
| 130 words/min | 45:57 | 07:13 |
Use a recorded rehearsal to select the pace. Slot rates include silence; actual articulation is faster. Do not speed up historical names or clause numbers to meet an arbitrary timestamp. If a slide overruns, trim its example or redistribute time, regenerate this file and check the complete run again.
The deck has slide navigation and notes; it does not auto-advance or claim to measure speech. Final YouTube chapters must use the edited recording timestamps, not these planning slots.
The current slot allocation and explicit pause assumptions are documented in the speech-to-slide review. Extra diagram-viewing time is counted once; do not add it again to a delivery pace already measured over a complete rehearsal.
Исходный Markdown целиком
# EP01 — Timing and rehearsal model
Generated from [the full English script](EP01-script-en.md). Timing slots total **53:10**. Count uses written English word tokens, including contractions and hyphenated words. Acronyms and numeric designations may take longer to pronounce than this token count suggests; only a recorded rehearsal establishes the actual duration.
| Slide | Start–end | Slot | Speech words | Words/min in slot |
|---|---|---|---|---|
| 01. Where secure development begins | 00:00–01:05 | 01:05 | 117 | 108.0 |
| 02. One process. One useful result. | 01:05–02:40 | 01:35 | 182 | 114.9 |
| 03. Twenty-five processes, connected | 02:40–04:15 | 01:35 | 177 | 111.8 |
| 04. Friday's release is blocked | 04:15–06:15 | 02:00 | 234 | 117.0 |
| 05. Three documents before the methodologies | 06:15–08:30 | 02:15 | 238 | 105.8 |
| 06. From evaluating systems to building them | 08:30–10:50 | 02:20 | 238 | 102.0 |
| 07. A landscape of secure development methods | 10:50–12:35 | 01:45 | 180 | 102.9 |
| 08. Different ways to organize the work | 12:35–14:10 | 01:35 | 183 | 115.6 |
| 09. Before the standard: a practical problem | 14:10–15:45 | 01:35 | 178 | 112.4 |
| 10. The route from research to publication | 15:45–17:30 | 01:45 | 179 | 102.3 |
| 11. Who wrote it, and who was it for? | 17:30–19:50 | 02:20 | 274 | 117.4 |
| 12. A wider plan than one published document | 19:50–21:25 | 01:35 | 156 | 98.5 |
| 13. GOST in the international context | 21:25–23:30 | 02:05 | 231 | 110.9 |
| 14. Two editions, different structures | 23:30–25:15 | 01:45 | 241 | 137.7 |
| 15. A process continues after the first tool run | 25:15–26:55 | 01:40 | 182 | 109.2 |
| 16. When this standard actually binds | 26:55–29:15 | 02:20 | 276 | 118.3 |
| 17. Shared practices need evidence | 29:15–30:45 | 01:30 | 171 | 114.0 |
| 18. Compare obligations, not labels | 30:45–32:35 | 01:50 | 195 | 106.4 |
| 19. What process 5.1 asks for | 32:35–35:00 | 02:25 | 309 | 127.9 |
| 20. Start with a defensible scope | 35:00–36:40 | 01:40 | 203 | 121.8 |
| 21. Assess reality and assign owners | 36:40–38:15 | 01:35 | 184 | 116.2 |
| 22. Resources include human attention | 38:15–39:50 | 01:35 | 183 | 115.6 |
| 23. Two plans, two questions | 39:50–41:30 | 01:40 | 185 | 111.0 |
| 24. A 90-day plan for the importer | 41:30–43:45 | 02:15 | 244 | 108.4 |
| 25. Five linked records of evidence | 43:45–45:20 | 01:35 | 177 | 111.8 |
| 26. Every process is written the same way | 45:20–47:50 | 02:30 | 276 | 110.4 |
| 27. A first international crosswalk | 47:50–49:40 | 01:50 | 196 | 106.9 |
| 28. Would this survive Friday's release? | 49:40–51:15 | 01:35 | 181 | 114.3 |
| 29. Security Training That Changes Engineering Decisions | 51:15–53:10 | 01:55 | 203 | 105.9 |
**Total: 5973 spoken words.**
## Speaking pace sensitivity
| Articulation pace | Speech alone | Space left inside 53:10 for pauses/transitions |
|---|---|---|
| 110 words/min | 54:18 | exceeds slot by 01:08 |
| 115 words/min | 51:56 | 01:14 |
| 120 words/min | 49:46 | 03:24 |
| 125 words/min | 47:47 | 05:23 |
| 130 words/min | 45:57 | 07:13 |
Use a recorded rehearsal to select the pace. Slot rates include silence; actual articulation is faster. Do not speed up historical names or clause numbers to meet an arbitrary timestamp. If a slide overruns, trim its example or redistribute time, regenerate this file and check the complete run again.
The deck has slide navigation and notes; it does not auto-advance or claim to measure speech. Final YouTube chapters must use the edited recording timestamps, not these planning slots.
The current slot allocation and explicit pause assumptions are documented in [the speech-to-slide review](EP01-speech-review.md). Extra diagram-viewing time is counted once; do not add it again to a delivery pace already measured over a complete rehearsal.
SHA-256: 88b15dbe6aa771eb983ab727cb3fa4ae3f8852b96ea0bcad49f586968a73b7f3
13EP01 — проверка читаемости и схемEP01-visual-review.md
EP01 — проверка читаемости и схем
Дата: 6 сентября 2026 года. Проверка относится к локальному пакету после добавления графики; качество видеозаписи и сжатия YouTube ещё не проверялось.
Результат
В 16 из 29 слайдов текстовые перечни заменены смысловыми SVG-схемами. В самостоятельную русскую лекцию добавлены 7 рисунков. Источники и данные схем находятся в EP01-visuals.md, полный английский сценарий — в EP01-script-en.md. Текущий план после проверки речи — 53:00; количество слов и расчёт см. в EP01-timing.md. Фактическую длительность определит репетиция.
Основной текст слайдов имеет начертание 600, заголовки и подписи — 700. Режим выступления использует ширину экрана. Повторяющийся номер над заголовком скрыт; подробные подписи рисунков видны в режиме чтения. Полная речь и текстовое описание схем доступны в заметках. На последнем слайде сохранены pikov.art и анонс EP02.
Браузерная проверка
Проверялась область страницы в CSS px. Full HD, 4K и мобильный размер проверены эмуляцией размеров вкладки; это не испытание на физических мониторах. После проверки временная эмуляция сброшена.
| Область страницы | Проверка | Результат |
|---|---|---|
| 1280 × 720 | Все 29 слайдов в режиме выступления | Нижняя граница самой высокой панели — 708 px; панели полностью помещаются |
| 1920 × 1080 | Все 29 слайдов | Максимальная нижняя граница — 1021 px; горизонтального переполнения нет |
| 3840 × 2160 | Все 29 слайдов | Максимальная нижняя граница — 1992 px; горизонтального переполнения нет |
| 390 × 844 | Режим чтения и русская лекция | Страница не расширяется; SVG шириной 1000 px прокручиваются внутри собственного блока |
| SVG-каталог | Границы текстовых элементов всех 23 рисунков | Подписи находятся внутри холста |
При ширине 3840 px непосредственно измерены основной текст 50,688 px / 600 и заголовок 128 px / 700. По формулам CSS при 1280 / 1920 px основной текст составляет 20 / 25,344 px. Эти значения относятся к тексту слайдов; в SVG собственная векторная типографика, масштабируемая с изображением.
В браузере загружаются 16 английских и 7 русских схем. Русские SVG встроены в HTML как data URI: для их чтения не требуется сервер или сеть. Наблюдавшиеся страницы не выдавали ошибок консоли. Выборочно визуально просмотрены хронология SDL, схема планирования и диаграмма ресурсов.
Проверка источников и чисел
- Timeline показывает выбранные публикации и редакции. В нём не смешаны появление Microsoft SDL в процессе компании в 2004 году и книга 2006 года. Разбор расхождений Figure 2 и Table II сохранён в исследовании истории.
- В истории ГОСТ разделены подготовка проекта, утверждение 1 июня 2016 года и введение в действие 1 июня 2017 года.
- Ресурсы учебного примера: 60 + 24 + 12 = 96 человеко-часов. Ширины столбцов SVG: 930 / 372 / 186 единиц, то есть точно пропорциональны значениям.
- Периоды 30/60/90 дней, часы и роли — авторский учебный пример; они не изображают обязательный нормативный график.
- Стрелки процессов и сопоставления — учебное объяснение связей. Они не доказывают происхождение одного стандарта от другого, равенство стандартов или эффективность практик.
Синхронность и воспроизводимость
Проверены build-visuals.py --check, build-review.py --check, синтаксис assets/presentation.js, ссылки на SVG и хеши ресурсов. Независимый просмотр изменений генераторов не выявил ошибок в текущем пакете.
Скачиваемый из HTML Markdown проверяется побайтно, включая переводы строк. Все 7 встроенных русских SVG побайтно совпадают с файлами в assets/visuals/; их порядок соответствует изображениям Markdown. В браузерных данных сохранены все 25 блоков полной речи.
Сборка: build-visuals.py → build-content.py → build-review.py. Адреса CSS, JavaScript и английских SVG включают хеш содержимого, чтобы браузер загружал соответствующую версию после правок. Для проверки результата открыть презентацию, русскую лекцию и обзор подготовки.
Перед записью остаётся авторская репетиция: проверить произношение имён, паузы на схемах и фактическое время. Плановые слоты не являются измеренной длительностью готового ролика.
Языковая правка после замечания автора
6 сентября 2026 года автор обнаружил русское слово на рисунке слайда 12. Предыдущая проверка геометрии и загрузки рисунков этот дефект не выявляла: она не контролировала язык материала.
В исходнике SVG, английском Markdown, текстовой альтернативе и речи слайда 12 термин заменён английским объяснением различия рекомендации и требования. Также переведено название русскоязычного доклада в реестре источников и убрана транслитерация из речи слайда 15. В английских данных 29 слайдов, реестре 16 источников и 16 английских SVG кириллицы больше нет. Исходники русской лекции и её 7 рисунков остаются русскими.
Сборка теперь проверяет кириллицу отдельно в английских спецификациях рисунков, готовом SVG и всех данных англоязычной презентации. Эта проверка предотвращает повторение данного дефекта, но не заменяет редакторскую проверку английской грамматики и смысла.
Исходный Markdown целиком
# EP01 — проверка читаемости и схем
Дата: 6 сентября 2026 года. Проверка относится к локальному пакету после добавления графики; качество видеозаписи и сжатия YouTube ещё не проверялось.
## Результат
В 16 из 29 слайдов текстовые перечни заменены смысловыми SVG-схемами. В самостоятельную русскую лекцию добавлены 7 рисунков. Источники и данные схем находятся в [EP01-visuals.md](EP01-visuals.md), полный английский сценарий — в [EP01-script-en.md](EP01-script-en.md). Текущий план после проверки речи — 53:00; количество слов и расчёт см. в [EP01-timing.md](EP01-timing.md). Фактическую длительность определит репетиция.
Основной текст слайдов имеет начертание 600, заголовки и подписи — 700. Режим выступления использует ширину экрана. Повторяющийся номер над заголовком скрыт; подробные подписи рисунков видны в режиме чтения. Полная речь и текстовое описание схем доступны в заметках. На последнем слайде сохранены pikov.art и анонс EP02.
## Браузерная проверка
Проверялась область страницы в CSS px. Full HD, 4K и мобильный размер проверены эмуляцией размеров вкладки; это не испытание на физических мониторах. После проверки временная эмуляция сброшена.
| Область страницы | Проверка | Результат |
|---|---|---|
| 1280 × 720 | Все 29 слайдов в режиме выступления | Нижняя граница самой высокой панели — 708 px; панели полностью помещаются |
| 1920 × 1080 | Все 29 слайдов | Максимальная нижняя граница — 1021 px; горизонтального переполнения нет |
| 3840 × 2160 | Все 29 слайдов | Максимальная нижняя граница — 1992 px; горизонтального переполнения нет |
| 390 × 844 | Режим чтения и русская лекция | Страница не расширяется; SVG шириной 1000 px прокручиваются внутри собственного блока |
| SVG-каталог | Границы текстовых элементов всех 23 рисунков | Подписи находятся внутри холста |
При ширине 3840 px непосредственно измерены основной текст 50,688 px / 600 и заголовок 128 px / 700. По формулам CSS при 1280 / 1920 px основной текст составляет 20 / 25,344 px. Эти значения относятся к тексту слайдов; в SVG собственная векторная типографика, масштабируемая с изображением.
В браузере загружаются 16 английских и 7 русских схем. Русские SVG встроены в HTML как data URI: для их чтения не требуется сервер или сеть. Наблюдавшиеся страницы не выдавали ошибок консоли. Выборочно визуально просмотрены хронология SDL, схема планирования и диаграмма ресурсов.
## Проверка источников и чисел
- Timeline показывает выбранные публикации и редакции. В нём не смешаны появление Microsoft SDL в процессе компании в 2004 году и книга 2006 года. Разбор расхождений Figure 2 и Table II сохранён в [исследовании истории](EP01-history-research.md).
- В истории ГОСТ разделены подготовка проекта, утверждение 1 июня 2016 года и введение в действие 1 июня 2017 года.
- Ресурсы учебного примера: 60 + 24 + 12 = 96 человеко-часов. Ширины столбцов SVG: 930 / 372 / 186 единиц, то есть точно пропорциональны значениям.
- Периоды 30/60/90 дней, часы и роли — авторский учебный пример; они не изображают обязательный нормативный график.
- Стрелки процессов и сопоставления — учебное объяснение связей. Они не доказывают происхождение одного стандарта от другого, равенство стандартов или эффективность практик.
## Синхронность и воспроизводимость
Проверены `build-visuals.py --check`, `build-review.py --check`, синтаксис `assets/presentation.js`, ссылки на SVG и хеши ресурсов. Независимый просмотр изменений генераторов не выявил ошибок в текущем пакете.
Скачиваемый из HTML Markdown проверяется **побайтно**, включая переводы строк. Все 7 встроенных русских SVG побайтно совпадают с файлами в `assets/visuals/`; их порядок соответствует изображениям Markdown. В браузерных данных сохранены все 25 блоков полной речи.
Сборка: `build-visuals.py` → `build-content.py` → `build-review.py`. Адреса CSS, JavaScript и английских SVG включают хеш содержимого, чтобы браузер загружал соответствующую версию после правок. Для проверки результата открыть [презентацию](index.html), [русскую лекцию](PVS-2025-07-02-lecture.html) и [обзор подготовки](review.html).
Перед записью остаётся авторская репетиция: проверить произношение имён, паузы на схемах и фактическое время. Плановые слоты не являются измеренной длительностью готового ролика.
## Языковая правка после замечания автора
6 сентября 2026 года автор обнаружил русское слово на рисунке слайда 12. Предыдущая проверка геометрии и загрузки рисунков этот дефект не выявляла: она не контролировала язык материала.
В исходнике SVG, английском Markdown, текстовой альтернативе и речи слайда 12 термин заменён английским объяснением различия рекомендации и требования. Также переведено название русскоязычного доклада в реестре источников и убрана транслитерация из речи слайда 15. В английских данных 29 слайдов, реестре 16 источников и 16 английских SVG кириллицы больше нет. Исходники русской лекции и её 7 рисунков остаются русскими.
Сборка теперь проверяет кириллицу отдельно в английских спецификациях рисунков, готовом SVG и всех данных англоязычной презентации. Эта проверка предотвращает повторение данного дефекта, но не заменяет редакторскую проверку английской грамматики и смысла.
SHA-256: 5422d7c5832e55ce059b31ca76e8c16bc88949f2969c3f68ab6ffcdfa73ce313
14EP01 — Каталог учебных визуализацийEP01-visuals.md
EP01 — Каталог учебных визуализаций
Дата: 2026-09-06. Автор учебного материала: Vitaliy Pikov.
Этот файл задаёт содержание локальных SVG-иллюстраций для английской презентации и самостоятельной русской лекции. Каждая JSON-запись описывает одну иллюстрацию: подписи, доступное текстовое описание, пояснение и идентификаторы источников из каталога EP01. Английские и русские версии предназначены для соответствующего языка материала.
Схемы показывают связи и учебные примеры; расстояния, размеры блоков и стрелки не измеряют эффективность, безопасность или нормативную эквивалентность. Исключения — хронологические координаты шкал и диаграмма явно заданного учебного бюджета времени. Годы на шкале методологий обозначают выбранные публикации и редакции, а не обязательные даты возникновения идей. Пример на 90 дней и 96 человеко-часов не является требованием ГОСТ.
slide-03
Четыре связанные области дают зрителю маршрут серии. Подпись явно относит группировку к учебному объяснению автора; она не вводит новую классификацию стандарта.
{
"id": "slide-03", "kind": "flow", "lang": "en",
"alt": "Four connected teaching groups: Organize, Engineer, Verify and Sustain. These are the author's guide to the series, not categories defined by GOST.",
"caption": "An author's teaching guide to the connections between the 25 processes.",
"sourceIds": ["G24"],
"nodes": [
{"label": "01", "title": "Organize", "detail": "Plans, skills, owners"},
{"label": "02", "title": "Engineer", "detail": "Design, code, builds"},
{"label": "03", "title": "Verify", "detail": "Review, analyze, test"},
{"label": "04", "title": "Sustain", "detail": "Updates and improvement"}
],
"note": "Teaching groups, not an official GOST classification or a prescribed sequence."
}
slide-04
Условный импортёр связывает техническое предупреждение с организационной проблемой. Разрыв расположен перед расследованием: информация уже получена, но дальнейшая работа не согласована.
{
"id": "slide-04", "kind": "release", "lang": "en",
"alt": "A file reaches the C++ parser, analysis produces a finding, and the path toward investigation and a release decision is interrupted by unclear ownership and capacity.",
"caption": "Illustrative case: a finding is useful only when the team can act on it.",
"sourceIds": ["EX"],
"gap": true,
"nodes": [
{"label": "01", "title": "Input file", "detail": "Engineering data"},
{"label": "02", "title": "Parser", "detail": "C++ importer"},
{"label": "03", "title": "Finding", "detail": "Possible memory error"},
{"label": "04", "title": "Investigate", "detail": "Owner? Capacity?"},
{"label": "05", "title": "Decide", "detail": "Release evidence?"}
],
"note": "The team has a warning; it still needs an agreed response."
}
slide-05
Шкала показывает выборку публикаций из обзора, не превращая историю в цепочку «один подход заменил другой». Координаты опираются на годы; подписи отделяют публикацию от появления практики.
{
"id": "slide-05", "kind": "timeline", "lang": "en",
"alt": "Selected publication and edition milestones: lifecycle research in 2004; SDL, Touchpoints and CLASP publications in 2006; SDL-Agile guidance v5.2 in 2012; Singapore Security-by-Design in 2017; SAMM v2.0 in 2020; SSDF v1.1 in 2022.",
"caption": "Selected publications and editions from the methodology landscape; the review covers 28 approaches.",
"sourceIds": ["MLR", "MSH", "SAMM20", "N11"],
"axis": [2004, 2022],
"nodes": [
{"year": 2004, "label": "2004", "title": "Lifecycle research", "detail": "Jones and Rastogi"},
{"year": 2006, "label": "2006", "title": "SDL / Touchpoints", "detail": "CLASP"},
{"year": 2012, "label": "2012", "title": "SDL-Agile", "detail": "Guidance v5.2"},
{"year": 2017, "label": "2017", "title": "Security-by-Design", "detail": "Singapore framework"},
{"year": 2020, "label": "2020", "title": "SAMM v2.0", "detail": "Capability improvement"},
{"year": 2022, "label": "2022", "title": "SSDF v1.1", "detail": "NIST SP 800-218"}
],
"note": "Publication dates are not necessarily the dates when the practices first appeared."
}
slide-08
Отдельные узлы проекта, утверждения и введения в действие защищают от смешения событий. Группировка 2014–2015 годов обозначена диапазоном, а не выдуманной точной датой.
{
"id": "slide-08", "kind": "timeline", "lang": "en",
"alt": "GOST development milestones: research began in April 2013 and a first draft followed in August; review and revision continued in 2014–2015; Rosstandart approved the standard on 1 June 2016; it became effective on 1 June 2017. Project milestones come from Varenitsa's historical account, while the final two dates are formal publication facts.",
"caption": "From research to an effective standard: different events, different dates.",
"sourceIds": ["TRANS", "GOSTH", "G16"],
"axis": [2013, 2017],
"nodes": [
{"year": 2013, "label": "2013", "title": "Research & first draft", "detail": "April start · August draft", "tone": "account"},
{"year": 2014.5, "label": "2014–2015", "title": "Review & revision", "detail": "Working drafts", "tone": "account"},
{"year": 2016, "label": "1 June 2016", "title": "Approved", "detail": "Rosstandart · 458-st", "tone": "formal"},
{"year": 2017, "label": "1 June 2017", "title": "Effective", "detail": "GOST R 56939-2016", "tone": "formal"}
],
"note": "Project history: Varenitsa's account. Approval and effective dates: the final standard."
}
slide-11
Хронология ограничивает заявления о заимствовании. Линия означает течение времени, а не документально доказанную связь происхождения ГОСТ и SSDF.
{
"id": "slide-11", "kind": "timeline", "lang": "en",
"alt": "On a common time axis, GOST R 56939 was approved in 2016; the first public SSDF draft appeared in 2019, final SSDF 1.0 in 2020, and final SSDF 1.1 in 2022. The timeline does not assert ancestry between the documents.",
"caption": "Chronology helps test an ancestry claim; similarity alone cannot establish one.",
"sourceIds": ["G16", "N19", "N20", "N11"],
"axis": [2016, 2022],
"nodes": [
{"year": 2016, "label": "2016", "title": "GOST R 56939", "detail": "Approved", "tone": "gost"},
{"year": 2019, "label": "2019", "title": "SSDF public draft", "detail": "11 June", "tone": "ssdf"},
{"year": 2020, "label": "2020", "title": "SSDF 1.0", "detail": "Final white paper", "tone": "ssdf"},
{"year": 2022, "label": "2022", "title": "SSDF 1.1", "detail": "NIST SP 800-218", "tone": "ssdf"}
],
"note": "Dates establish sequence, not a proven line of influence."
}
slide-12
Сравнение обложек и смысла «следует» содержательнее графика роста числа заголовков. Девять групп мер и двадцать пять процессов не являются сопоставимыми единицами прогресса.
{
"id": "slide-12", "kind": "editions", "lang": "en",
"alt": "The 2016 edition has nine groups of measures; clause 4.2 assigns recommendation status to a term that expresses a requirement under clause 4.7 of the 2024 edition. The 2024 edition has 25 named processes. Structural counts do not measure a change in security.",
"caption": "These labels compare the normative force of one term in the original text.",
"sourceIds": ["G16", "G24"],
"nodes": [
{"label": "2016", "title": "9 groups of measures", "detail": "Recommendation · clause 4.2"},
{"label": "2024", "title": "25 named processes", "detail": "Requirement · clause 4.7"}
],
"note": "Different structural units: 25 minus 9 is not a measure of improvement."
}
slide-13
Обратная связь отличает поддерживаемый порядок работы от отдельного запуска инструмента. Версия продукта и свидетельства находятся в центре, потому что связывают действия с конкретным состоянием ПО.
{
"id": "slide-13", "kind": "loop", "lang": "en",
"alt": "A repeating process connects a trigger, assigned work, a recorded decision and review. Product version and evidence remain at the centre of the cycle.",
"caption": "A teaching model of repeatable work: actions, decisions and feedback remain connected.",
"sourceIds": ["G24", "EX"],
"center": "Version + evidence",
"nodes": [
{"label": "01", "title": "Trigger", "detail": "Change, release, new risk"},
{"label": "02", "title": "Assigned work", "detail": "Perform and review"},
{"label": "03", "title": "Recorded decision", "detail": "Finding and response"},
{"label": "04", "title": "Review & improve", "detail": "Update the next cycle"}
],
"note": "Running a tool is one action inside the process."
}
slide-15
Короткий путь сопоставления заменяет абстрактный список действий конкретным вопросом на каждом шаге. Последний узел разрешает обоснованный частичный результат.
{
"id": "slide-15", "kind": "flow", "lang": "en",
"alt": "The comparison method proceeds from reading actors, actions and conditions, to examining differences, demonstrating an implementation, and stating a bounded conclusion.",
"caption": "Compare what the documents ask people to do and what would demonstrate the result.",
"sourceIds": ["G24", "N11"],
"nodes": [
{"label": "01", "title": "Read", "detail": "Actor, action, conditions"},
{"label": "02", "title": "Compare", "detail": "Shared intent, differences"},
{"label": "03", "title": "Demonstrate", "detail": "Example and evidence"},
{"label": "04", "title": "Conclude", "detail": "State the limits"}
],
"note": "Partial overlap is useful; it does not establish full equivalence."
}
slide-16
Обе аналитические работы образуют основание двух планов. Область применения окружает карту; порядок узлов не изображает обязательную очерёдность внедрения.
{
"id": "slide-16", "kind": "planning", "lang": "en",
"alt": "Within the defined scope, current-state analysis and resource analysis support both the process improvement plan and the process implementation plan. The five nodes carry clauses 5.1.2.1 through 5.1.2.5.",
"caption": "Five planning requirements connected by their information dependencies.",
"sourceIds": ["G24"],
"nodes": [
{"label": "5.1.2.1", "title": "Current state", "detail": "Periodically analyze"},
{"label": "5.1.2.2", "title": "Resource needs", "detail": "Periodically analyze"},
{"label": "5.1.2.3", "title": "Improvement plan", "detail": "Develop capabilities"},
{"label": "5.1.2.4", "title": "Implementation plan", "detail": "Organize the work"},
{"label": "5.1.2.5", "title": "Scope", "detail": "Define the boundary"}
],
"note": "Both plans take the analyses into account. This is a map of connections, not a required sequence."
}
slide-17
Видимая граница помогает отличить состав продукта от связанного контекста разработки. Исключение требует обоснования и не определяется лишь возрастом прототипа.
{
"id": "slide-17", "kind": "boundary", "lang": "en",
"alt": "Importer 2.0 contains the parser, service API and shipped libraries. Repository, CI configuration and release workflow form connected development context. Excluding a retired prototype requires evidence that it has no code or dependency path into the release.",
"caption": "Illustrative scope: record what is included, what is connected and why an exclusion is justified.",
"sourceIds": ["G24", "EX"],
"title": "Importer 2.0",
"components": ["Parser module", "Service API", "Shipped libraries"],
"context": ["Repository", "CI configuration", "Release workflow"],
"exclusion": "Retired prototype: no code or dependency path into release",
"note": "Keep a versioned scope record and the selection rationale."
}
slide-19
Единственная диаграмма объёма в наборе использует заданные в учебном примере числа. Общий ноль и одинаковая единица делают соотношение трудозатрат честным и понятным.
{
"id": "slide-19", "kind": "bars", "lang": "en",
"alt": "An illustrative 90-day effort allocates 60 person-hours to engineering, 24 to AppSec, and 12 to release coordination and sponsor decisions, for a total of 96 person-hours. Tools and infrastructure are assessed separately.",
"caption": "Illustrative total effort for the 90-day plan; validate the estimates with the people doing the work.",
"sourceIds": ["G24", "EX"],
"unit": "person-hours", "total": 96,
"nodes": [
{"label": "Engineering", "value": 60, "unit": "person-hours"},
{"label": "AppSec", "value": 24, "unit": "person-hours"},
{"label": "Release & sponsor", "value": 12, "unit": "person-hours"}
],
"note": "A teaching estimate, not a benchmark or a GOST percentage. Tools and infrastructure are separate."
}
slide-20
Переход от возможности к исполнимой задаче и свидетельству результата раскрывает разницу двух планов. Общий трекер может хранить эти связи без требования отдельных файлов.
{
"id": "slide-20", "kind": "flow", "lang": "en",
"alt": "A process improvement goal, repeatable parser checks, is linked to an implementation task with an owner and milestone, and then to evidence of coverage and triage decisions. Current-state and resource analysis support the entire chain.",
"caption": "Connect the capability in the improvement plan to executable work and its evidence.",
"sourceIds": ["G24", "EX"],
"nodes": [
{"label": "IMPROVEMENT PLAN", "title": "Capability", "detail": "Repeatable parser checks"},
{"label": "IMPLEMENTATION PLAN", "title": "Task", "detail": "Owner and milestone"},
{"label": "RESULT", "title": "Evidence", "detail": "Coverage and decisions"}
],
"note": "Shared foundation: current-state analysis and resource analysis. The plans may be linked in one tracker."
}
slide-21
Каждый период заканчивается проверяемым результатом. Шкала представляет только учебный пример, не обязательную частоту анализа и не обещание полного внедрения за квартал.
{
"id": "slide-21", "kind": "roadmap", "lang": "en",
"alt": "The illustrative plan has three equal 30-day periods: establish scope, baseline and ownership; integrate parser checks and record decisions; then review two release cycles, close gaps and update the next plan.",
"caption": "A 90-day example for the importer: each stage produces something the team can review.",
"sourceIds": ["G24", "EX"],
"nodes": [
{"label": "Days 1–30", "title": "Establish baseline", "detail": "Scope, owners, capacity"},
{"label": "Days 31–60", "title": "Integrate & record", "detail": "CI checks, triage evidence"},
{"label": "Days 61–90", "title": "Review & improve", "detail": "Two cycles, next plan"}
],
"note": "Illustrative implementation choices, not a timetable required by GOST."
}
slide-22
Расположение повторяет карту требований на слайде 16. Теперь в каждом узле — сведения, которые можно проследить до конкретного продукта, работы и решения.
{
"id": "slide-22", "kind": "planning", "lang": "en",
"alt": "Five evidence categories mirror the planning requirements: baseline checks and gaps, resource estimates and assumptions, improvement priorities, implementation owners and milestones, and the importer scope with its rationale.",
"caption": "The same planning structure, now expressed as records a reviewer can follow.",
"sourceIds": ["G24", "EX"],
"nodes": [
{"label": "5.1.3.1", "title": "Current-state record", "detail": "Checks and known gaps"},
{"label": "5.1.3.2", "title": "Resource record", "detail": "96 h and assumptions"},
{"label": "5.1.3.3", "title": "Improvement plan", "detail": "Priorities and sequence"},
{"label": "5.1.3.4", "title": "Implementation plan", "detail": "Owners and milestones"},
{"label": "5.1.3.5", "title": "Scope record", "detail": "Importer 2.0 and rationale"}
],
"note": "Five information categories, not five compulsory isolated files. A summary links to the underlying evidence."
}
slide-23
Две узкие пары показывают содержательное совпадение без заявления об эквивалентности документов. Связующий текст обозначает общую задачу, а не процент покрытия.
{
"id": "slide-23", "kind": "crosswalk", "lang": "en",
"alt": "Two partial overlaps are shown: GOST 5.1.3.4 and NIST SSDF PO.2.1 share a concern with roles and responsibility; GOST 5.1.2.3 and SAMM Strategy and Metrics share a concern with an improvement roadmap. Scope and evidence expectations still differ.",
"caption": "Bounded comparison: a shared concern is useful, but does not establish full equivalence.",
"sourceIds": ["G24", "N11", "SAMM"],
"rows": [
{"left": "GOST 5.1.3.4", "bridge": "Roles & responsibility", "right": "SSDF PO.2.1"},
{"left": "GOST 5.1.2.3", "bridge": "Improvement roadmap", "right": "SAMM Strategy & Metrics"}
],
"note": "Partial overlap in both rows. Compare the full wording, scope and evidence expectations."
}
slide-24
Возвращение к исходной схеме завершает учебную историю. Устранён разрыв в организации работы, но схема не выдаёт решение о безопасности конкретного выпуска.
{
"id": "slide-24", "kind": "release", "lang": "en",
"alt": "The importer scenario returns with a connected path: identify the input and covered parser, retain the finding evidence, assign time and ownership for investigation, and record a release decision under the team's policy. This is a review of the process, not proof that a release is safe.",
"caption": "Return to Friday's release: can the team follow the finding through an owned, evidenced decision?",
"sourceIds": ["G24", "EX"],
"gap": false,
"nodes": [
{"label": "SCOPE", "title": "Input file", "detail": "Relevant scenario"},
{"label": "VERSION", "title": "Parser", "detail": "Covered component"},
{"label": "EVIDENCE", "title": "Finding", "detail": "Recorded result"},
{"label": "CAPACITY", "title": "Investigate", "detail": "Owner and time"},
{"label": "POLICY", "title": "Decide", "detail": "Decision and review"}
],
"note": "A usable decision process does not predetermine whether the release should proceed."
}
ru-sdl-timeline
Русская версия шкалы поддерживает §2 самостоятельной лекции. Она сохраняет то же различение публикаций, редакций и появления практик, что и английский слайд.
{
"id": "ru-sdl-timeline", "kind": "timeline", "lang": "ru",
"alt": "Выбранные публикации и редакции: исследование жизненного цикла 2004 года; SDL, Touchpoints и CLASP в 2006 году; руководство SDL-Agile v5.2 в 2012 году; сингапурский Security-by-Design в 2017 году; SAMM v2.0 в 2020 году; SSDF v1.1 в 2022 году. Это не даты первого возникновения всех идей.",
"caption": "Выбранные публикации и редакции из истории методологий. Обзор рассматривает 28 подходов; шкала не исчерпывает их историю.",
"sourceIds": ["MLR", "MSH", "SAMM20", "N11"],
"axis": [2004, 2022],
"nodes": [
{"year": 2004, "label": "2004", "title": "Жизненный цикл", "detail": "Jones и Rastogi"},
{"year": 2006, "label": "2006", "title": "SDL / Touchpoints", "detail": "CLASP"},
{"year": 2012, "label": "2012", "title": "SDL-Agile", "detail": "Руководство v5.2"},
{"year": 2017, "label": "2017", "title": "Security-by-Design", "detail": "Сингапурский framework"},
{"year": 2020, "label": "2020", "title": "SAMM v2.0", "detail": "Развитие возможностей"},
{"year": 2022, "label": "2022", "title": "SSDF v1.1", "detail": "NIST SP 800-218"}
],
"note": "Год публикации или редакции не обязательно совпадает с началом применения практики."
}
ru-gost-timeline
Шкала дополняет точную таблицу §4. История проектов атрибутирована Варенице, а даты принятого документа проверяются по окончательному стандарту.
{
"id": "ru-gost-timeline", "kind": "timeline", "lang": "ru",
"alt": "В апреле 2013 года началась НИР, в августе появился первый проект; в 2014–2015 годах продолжались рассмотрение и доработка; 1 июня 2016 года Росстандарт утвердил ГОСТ Р 56939-2016; 1 июня 2017 года стандарт введён в действие. Проектные этапы приведены по докладу Вареницы, две последние даты — по окончательному стандарту.",
"caption": "Подготовка проекта, утверждение и введение стандарта в действие — разные этапы.",
"sourceIds": ["TRANS", "GOSTH", "G16"],
"axis": [2013, 2017],
"nodes": [
{"year": 2013, "label": "2013", "title": "НИР и первый проект", "detail": "Апрель · август", "tone": "account"},
{"year": 2014.5, "label": "2014–2015", "title": "Обсуждение и доработка", "detail": "Рабочие редакции", "tone": "account"},
{"year": 2016, "label": "1 июня 2016", "title": "Утверждение", "detail": "Росстандарт · № 458-ст", "tone": "formal"},
{"year": 2017, "label": "1 июня 2017", "title": "Введение в действие", "detail": "ГОСТ Р 56939-2016", "tone": "formal"}
],
"note": "Проектные этапы: доклад Вареницы. Формальные даты: окончательный стандарт."
}
ru-process-loop
Схема §7 показывает организационную устойчивость практики, не противопоставляя редакцию 2016 года якобы исключительно разовым мероприятиям.
{
"id": "ru-process-loop", "kind": "loop", "lang": "ru",
"alt": "Поддерживаемый процесс соединяет событие, назначенную работу, зафиксированное решение и пересмотр порядка работы. В центре сохраняется связь с версией продукта и свидетельствами результата.",
"caption": "Учебная модель поддерживаемого процесса: действия, решения и обратная связь остаются связанными.",
"sourceIds": ["G24", "EX"],
"center": "Версия + свидетельства",
"nodes": [
{"label": "01", "title": "Событие", "detail": "Изменение, релиз, риск"},
{"label": "02", "title": "Исполнение", "detail": "Работа и ответственный"},
{"label": "03", "title": "Решение", "detail": "Результат и действия"},
{"label": "04", "title": "Пересмотр", "detail": "Следующий цикл работы"}
],
"note": "Запуск инструмента — одно из действий; результаты ещё нужно обработать."
}
ru-planning-evidence
Карта §16 объединяет пять категорий информации. Она подчёркивает содержательные связи и не требует пяти изолированных документов.
{
"id": "ru-planning-evidence", "kind": "planning", "lang": "ru",
"alt": "В выбранной области применения анализ исходного состояния и анализ ресурсов поддерживают план развития и план реализации процессов. Все пять категорий информации связаны с продуктом и обоснованием области.",
"caption": "Пять связанных результатов планирования по процессу 5.1 ГОСТ Р 56939-2024.",
"sourceIds": ["G24"],
"nodes": [
{"label": "5.1.3.1", "title": "Исходное состояние", "detail": "Практики и пробелы"},
{"label": "5.1.3.2", "title": "Анализ ресурсов", "detail": "Люди, время, средства"},
{"label": "5.1.3.3", "title": "План развития", "detail": "Приоритеты и очередь"},
{"label": "5.1.3.4", "title": "План реализации", "detail": "Работы, сроки, участники"},
{"label": "5.1.3.5", "title": "Область применения", "detail": "Состав и обоснование"}
],
"note": "Пять категорий сведений не означают пять обязательных отдельных файлов."
}
ru-testing-map
Схема §9 связывает метод проверки с объектом внимания. Размещение блоков не изображает стадии зрелости, гарантированное покрытие или обязательный порядок проверок.
{
"id": "ru-testing-map", "kind": "flow", "lang": "ru",
"alt": "Четыре взаимодополняющих направления проверки: анализ архитектуры рассматривает решения и границы доверия; статический анализ исследует исходный код; динамические проверки и фаззинг исследуют выполняемую программу; тестирование на проникновение рассматривает сценарии атакующего в заданных условиях.",
"caption": "Разные методы отвечают на разные вопросы о продукте; их результаты полезны в сочетании.",
"sourceIds": ["G24", "EX"],
"nodes": [
{"label": "АРХИТЕКТУРА", "title": "Решения", "detail": "Границы доверия"},
{"label": "СТАТИЧЕСКИЙ АНАЛИЗ", "title": "Исходный код", "detail": "Дефекты реализации"},
{"label": "ДИНАМИКА И ФАЗЗИНГ", "title": "Поведение", "detail": "Входы и исполнение"},
{"label": "ПЕНТЕСТ", "title": "Сценарии атаки", "detail": "Заданные условия"}
],
"note": "Связанные виды проверки, а не обязательная последовательность или измерение покрытия."
}
ru-response-cycle
Цикл для §18 объединяет работу с сообщениями, решениями, исправлениями и последующим сопровождением. Это учебная схема; конкретные правила задаются применимым процессом и продуктом.
{
"id": "ru-response-cycle", "kind": "loop", "lang": "ru",
"alt": "Работа с недостатком связывает регистрацию и анализ сообщения, решение об ответственных и действиях, исправление с проверкой, а затем обновление и сопровождение. Версия продукта и принятое решение должны оставаться прослеживаемыми.",
"caption": "Учебная схема работы с недостатком на протяжении сопровождения продукта.",
"sourceIds": ["G24", "EX"],
"center": "Версия + решение",
"nodes": [
{"label": "01", "title": "Сообщение", "detail": "Регистрация и анализ"},
{"label": "02", "title": "Решение", "detail": "Действия и участники"},
{"label": "03", "title": "Исправление", "detail": "Изменение и проверка"},
{"label": "04", "title": "Сопровождение", "detail": "Обновление и обратная связь"}
],
"note": "Конкретный порядок зависит от продукта, риска и применимых условий."
}
ru-practical-plan
Схема §22 демонстрирует одну проверяемую цепочку в практической работе. Сохранена формулировка самостоятельного упражнения про сервис обработки файлов, без переноса часов и сроков английского примера.
{
"id": "ru-practical-plan", "kind": "flow", "lang": "ru",
"alt": "Для сервиса обработки файлов выявленный пробел — отсутствие общего порядка обработки предупреждений — связывается с улучшением, задачей с участником и сроком, затем с сохранённым результатом проверки реального изменения.",
"caption": "Практическая работа: проследите связь от выявленного пробела до результата исполнения.",
"sourceIds": ["G24", "EX"],
"nodes": [
{"label": "ПРОБЛЕМА", "title": "Пробел", "detail": "Нет порядка обработки"},
{"label": "ПРИОРИТЕТ", "title": "Улучшение", "detail": "Согласовать действия"},
{"label": "ИСПОЛНЕНИЕ", "title": "Работа", "detail": "Участник и срок"},
{"label": "ПРОВЕРКА", "title": "Результат", "detail": "Реальное изменение"}
],
"note": "Каждая связь должна объясняться исходным состоянием, областью и доступными ресурсами."
}
Исходный Markdown целиком
# EP01 — Каталог учебных визуализаций
Дата: 2026-09-06. Автор учебного материала: Vitaliy Pikov.
Этот файл задаёт содержание локальных SVG-иллюстраций для английской презентации и самостоятельной русской лекции. Каждая JSON-запись описывает одну иллюстрацию: подписи, доступное текстовое описание, пояснение и идентификаторы источников из каталога EP01. Английские и русские версии предназначены для соответствующего языка материала.
Схемы показывают связи и учебные примеры; расстояния, размеры блоков и стрелки не измеряют эффективность, безопасность или нормативную эквивалентность. Исключения — хронологические координаты шкал и диаграмма явно заданного учебного бюджета времени. Годы на шкале методологий обозначают выбранные публикации и редакции, а не обязательные даты возникновения идей. Пример на 90 дней и 96 человеко-часов не является требованием ГОСТ.
## slide-03
Четыре связанные области дают зрителю маршрут серии. Подпись явно относит группировку к учебному объяснению автора; она не вводит новую классификацию стандарта.
```json
{
"id": "slide-03", "kind": "flow", "lang": "en",
"alt": "Four connected teaching groups: Organize, Engineer, Verify and Sustain. These are the author's guide to the series, not categories defined by GOST.",
"caption": "An author's teaching guide to the connections between the 25 processes.",
"sourceIds": ["G24"],
"nodes": [
{"label": "01", "title": "Organize", "detail": "Plans, skills, owners"},
{"label": "02", "title": "Engineer", "detail": "Design, code, builds"},
{"label": "03", "title": "Verify", "detail": "Review, analyze, test"},
{"label": "04", "title": "Sustain", "detail": "Updates and improvement"}
],
"note": "Teaching groups, not an official GOST classification or a prescribed sequence."
}
```
## slide-04
Условный импортёр связывает техническое предупреждение с организационной проблемой. Разрыв расположен перед расследованием: информация уже получена, но дальнейшая работа не согласована.
```json
{
"id": "slide-04", "kind": "release", "lang": "en",
"alt": "A file reaches the C++ parser, analysis produces a finding, and the path toward investigation and a release decision is interrupted by unclear ownership and capacity.",
"caption": "Illustrative case: a finding is useful only when the team can act on it.",
"sourceIds": ["EX"],
"gap": true,
"nodes": [
{"label": "01", "title": "Input file", "detail": "Engineering data"},
{"label": "02", "title": "Parser", "detail": "C++ importer"},
{"label": "03", "title": "Finding", "detail": "Possible memory error"},
{"label": "04", "title": "Investigate", "detail": "Owner? Capacity?"},
{"label": "05", "title": "Decide", "detail": "Release evidence?"}
],
"note": "The team has a warning; it still needs an agreed response."
}
```
## slide-05
Шкала показывает выборку публикаций из обзора, не превращая историю в цепочку «один подход заменил другой». Координаты опираются на годы; подписи отделяют публикацию от появления практики.
```json
{
"id": "slide-05", "kind": "timeline", "lang": "en",
"alt": "Selected publication and edition milestones: lifecycle research in 2004; SDL, Touchpoints and CLASP publications in 2006; SDL-Agile guidance v5.2 in 2012; Singapore Security-by-Design in 2017; SAMM v2.0 in 2020; SSDF v1.1 in 2022.",
"caption": "Selected publications and editions from the methodology landscape; the review covers 28 approaches.",
"sourceIds": ["MLR", "MSH", "SAMM20", "N11"],
"axis": [2004, 2022],
"nodes": [
{"year": 2004, "label": "2004", "title": "Lifecycle research", "detail": "Jones and Rastogi"},
{"year": 2006, "label": "2006", "title": "SDL / Touchpoints", "detail": "CLASP"},
{"year": 2012, "label": "2012", "title": "SDL-Agile", "detail": "Guidance v5.2"},
{"year": 2017, "label": "2017", "title": "Security-by-Design", "detail": "Singapore framework"},
{"year": 2020, "label": "2020", "title": "SAMM v2.0", "detail": "Capability improvement"},
{"year": 2022, "label": "2022", "title": "SSDF v1.1", "detail": "NIST SP 800-218"}
],
"note": "Publication dates are not necessarily the dates when the practices first appeared."
}
```
## slide-08
Отдельные узлы проекта, утверждения и введения в действие защищают от смешения событий. Группировка 2014–2015 годов обозначена диапазоном, а не выдуманной точной датой.
```json
{
"id": "slide-08", "kind": "timeline", "lang": "en",
"alt": "GOST development milestones: research began in April 2013 and a first draft followed in August; review and revision continued in 2014–2015; Rosstandart approved the standard on 1 June 2016; it became effective on 1 June 2017. Project milestones come from Varenitsa's historical account, while the final two dates are formal publication facts.",
"caption": "From research to an effective standard: different events, different dates.",
"sourceIds": ["TRANS", "GOSTH", "G16"],
"axis": [2013, 2017],
"nodes": [
{"year": 2013, "label": "2013", "title": "Research & first draft", "detail": "April start · August draft", "tone": "account"},
{"year": 2014.5, "label": "2014–2015", "title": "Review & revision", "detail": "Working drafts", "tone": "account"},
{"year": 2016, "label": "1 June 2016", "title": "Approved", "detail": "Rosstandart · 458-st", "tone": "formal"},
{"year": 2017, "label": "1 June 2017", "title": "Effective", "detail": "GOST R 56939-2016", "tone": "formal"}
],
"note": "Project history: Varenitsa's account. Approval and effective dates: the final standard."
}
```
## slide-11
Хронология ограничивает заявления о заимствовании. Линия означает течение времени, а не документально доказанную связь происхождения ГОСТ и SSDF.
```json
{
"id": "slide-11", "kind": "timeline", "lang": "en",
"alt": "On a common time axis, GOST R 56939 was approved in 2016; the first public SSDF draft appeared in 2019, final SSDF 1.0 in 2020, and final SSDF 1.1 in 2022. The timeline does not assert ancestry between the documents.",
"caption": "Chronology helps test an ancestry claim; similarity alone cannot establish one.",
"sourceIds": ["G16", "N19", "N20", "N11"],
"axis": [2016, 2022],
"nodes": [
{"year": 2016, "label": "2016", "title": "GOST R 56939", "detail": "Approved", "tone": "gost"},
{"year": 2019, "label": "2019", "title": "SSDF public draft", "detail": "11 June", "tone": "ssdf"},
{"year": 2020, "label": "2020", "title": "SSDF 1.0", "detail": "Final white paper", "tone": "ssdf"},
{"year": 2022, "label": "2022", "title": "SSDF 1.1", "detail": "NIST SP 800-218", "tone": "ssdf"}
],
"note": "Dates establish sequence, not a proven line of influence."
}
```
## slide-12
Сравнение обложек и смысла «следует» содержательнее графика роста числа заголовков. Девять групп мер и двадцать пять процессов не являются сопоставимыми единицами прогресса.
```json
{
"id": "slide-12", "kind": "editions", "lang": "en",
"alt": "The 2016 edition has nine groups of measures; clause 4.2 assigns recommendation status to a term that expresses a requirement under clause 4.7 of the 2024 edition. The 2024 edition has 25 named processes. Structural counts do not measure a change in security.",
"caption": "These labels compare the normative force of one term in the original text.",
"sourceIds": ["G16", "G24"],
"nodes": [
{"label": "2016", "title": "9 groups of measures", "detail": "Recommendation · clause 4.2"},
{"label": "2024", "title": "25 named processes", "detail": "Requirement · clause 4.7"}
],
"note": "Different structural units: 25 minus 9 is not a measure of improvement."
}
```
## slide-13
Обратная связь отличает поддерживаемый порядок работы от отдельного запуска инструмента. Версия продукта и свидетельства находятся в центре, потому что связывают действия с конкретным состоянием ПО.
```json
{
"id": "slide-13", "kind": "loop", "lang": "en",
"alt": "A repeating process connects a trigger, assigned work, a recorded decision and review. Product version and evidence remain at the centre of the cycle.",
"caption": "A teaching model of repeatable work: actions, decisions and feedback remain connected.",
"sourceIds": ["G24", "EX"],
"center": "Version + evidence",
"nodes": [
{"label": "01", "title": "Trigger", "detail": "Change, release, new risk"},
{"label": "02", "title": "Assigned work", "detail": "Perform and review"},
{"label": "03", "title": "Recorded decision", "detail": "Finding and response"},
{"label": "04", "title": "Review & improve", "detail": "Update the next cycle"}
],
"note": "Running a tool is one action inside the process."
}
```
## slide-15
Короткий путь сопоставления заменяет абстрактный список действий конкретным вопросом на каждом шаге. Последний узел разрешает обоснованный частичный результат.
```json
{
"id": "slide-15", "kind": "flow", "lang": "en",
"alt": "The comparison method proceeds from reading actors, actions and conditions, to examining differences, demonstrating an implementation, and stating a bounded conclusion.",
"caption": "Compare what the documents ask people to do and what would demonstrate the result.",
"sourceIds": ["G24", "N11"],
"nodes": [
{"label": "01", "title": "Read", "detail": "Actor, action, conditions"},
{"label": "02", "title": "Compare", "detail": "Shared intent, differences"},
{"label": "03", "title": "Demonstrate", "detail": "Example and evidence"},
{"label": "04", "title": "Conclude", "detail": "State the limits"}
],
"note": "Partial overlap is useful; it does not establish full equivalence."
}
```
## slide-16
Обе аналитические работы образуют основание двух планов. Область применения окружает карту; порядок узлов не изображает обязательную очерёдность внедрения.
```json
{
"id": "slide-16", "kind": "planning", "lang": "en",
"alt": "Within the defined scope, current-state analysis and resource analysis support both the process improvement plan and the process implementation plan. The five nodes carry clauses 5.1.2.1 through 5.1.2.5.",
"caption": "Five planning requirements connected by their information dependencies.",
"sourceIds": ["G24"],
"nodes": [
{"label": "5.1.2.1", "title": "Current state", "detail": "Periodically analyze"},
{"label": "5.1.2.2", "title": "Resource needs", "detail": "Periodically analyze"},
{"label": "5.1.2.3", "title": "Improvement plan", "detail": "Develop capabilities"},
{"label": "5.1.2.4", "title": "Implementation plan", "detail": "Organize the work"},
{"label": "5.1.2.5", "title": "Scope", "detail": "Define the boundary"}
],
"note": "Both plans take the analyses into account. This is a map of connections, not a required sequence."
}
```
## slide-17
Видимая граница помогает отличить состав продукта от связанного контекста разработки. Исключение требует обоснования и не определяется лишь возрастом прототипа.
```json
{
"id": "slide-17", "kind": "boundary", "lang": "en",
"alt": "Importer 2.0 contains the parser, service API and shipped libraries. Repository, CI configuration and release workflow form connected development context. Excluding a retired prototype requires evidence that it has no code or dependency path into the release.",
"caption": "Illustrative scope: record what is included, what is connected and why an exclusion is justified.",
"sourceIds": ["G24", "EX"],
"title": "Importer 2.0",
"components": ["Parser module", "Service API", "Shipped libraries"],
"context": ["Repository", "CI configuration", "Release workflow"],
"exclusion": "Retired prototype: no code or dependency path into release",
"note": "Keep a versioned scope record and the selection rationale."
}
```
## slide-19
Единственная диаграмма объёма в наборе использует заданные в учебном примере числа. Общий ноль и одинаковая единица делают соотношение трудозатрат честным и понятным.
```json
{
"id": "slide-19", "kind": "bars", "lang": "en",
"alt": "An illustrative 90-day effort allocates 60 person-hours to engineering, 24 to AppSec, and 12 to release coordination and sponsor decisions, for a total of 96 person-hours. Tools and infrastructure are assessed separately.",
"caption": "Illustrative total effort for the 90-day plan; validate the estimates with the people doing the work.",
"sourceIds": ["G24", "EX"],
"unit": "person-hours", "total": 96,
"nodes": [
{"label": "Engineering", "value": 60, "unit": "person-hours"},
{"label": "AppSec", "value": 24, "unit": "person-hours"},
{"label": "Release & sponsor", "value": 12, "unit": "person-hours"}
],
"note": "A teaching estimate, not a benchmark or a GOST percentage. Tools and infrastructure are separate."
}
```
## slide-20
Переход от возможности к исполнимой задаче и свидетельству результата раскрывает разницу двух планов. Общий трекер может хранить эти связи без требования отдельных файлов.
```json
{
"id": "slide-20", "kind": "flow", "lang": "en",
"alt": "A process improvement goal, repeatable parser checks, is linked to an implementation task with an owner and milestone, and then to evidence of coverage and triage decisions. Current-state and resource analysis support the entire chain.",
"caption": "Connect the capability in the improvement plan to executable work and its evidence.",
"sourceIds": ["G24", "EX"],
"nodes": [
{"label": "IMPROVEMENT PLAN", "title": "Capability", "detail": "Repeatable parser checks"},
{"label": "IMPLEMENTATION PLAN", "title": "Task", "detail": "Owner and milestone"},
{"label": "RESULT", "title": "Evidence", "detail": "Coverage and decisions"}
],
"note": "Shared foundation: current-state analysis and resource analysis. The plans may be linked in one tracker."
}
```
## slide-21
Каждый период заканчивается проверяемым результатом. Шкала представляет только учебный пример, не обязательную частоту анализа и не обещание полного внедрения за квартал.
```json
{
"id": "slide-21", "kind": "roadmap", "lang": "en",
"alt": "The illustrative plan has three equal 30-day periods: establish scope, baseline and ownership; integrate parser checks and record decisions; then review two release cycles, close gaps and update the next plan.",
"caption": "A 90-day example for the importer: each stage produces something the team can review.",
"sourceIds": ["G24", "EX"],
"nodes": [
{"label": "Days 1–30", "title": "Establish baseline", "detail": "Scope, owners, capacity"},
{"label": "Days 31–60", "title": "Integrate & record", "detail": "CI checks, triage evidence"},
{"label": "Days 61–90", "title": "Review & improve", "detail": "Two cycles, next plan"}
],
"note": "Illustrative implementation choices, not a timetable required by GOST."
}
```
## slide-22
Расположение повторяет карту требований на слайде 16. Теперь в каждом узле — сведения, которые можно проследить до конкретного продукта, работы и решения.
```json
{
"id": "slide-22", "kind": "planning", "lang": "en",
"alt": "Five evidence categories mirror the planning requirements: baseline checks and gaps, resource estimates and assumptions, improvement priorities, implementation owners and milestones, and the importer scope with its rationale.",
"caption": "The same planning structure, now expressed as records a reviewer can follow.",
"sourceIds": ["G24", "EX"],
"nodes": [
{"label": "5.1.3.1", "title": "Current-state record", "detail": "Checks and known gaps"},
{"label": "5.1.3.2", "title": "Resource record", "detail": "96 h and assumptions"},
{"label": "5.1.3.3", "title": "Improvement plan", "detail": "Priorities and sequence"},
{"label": "5.1.3.4", "title": "Implementation plan", "detail": "Owners and milestones"},
{"label": "5.1.3.5", "title": "Scope record", "detail": "Importer 2.0 and rationale"}
],
"note": "Five information categories, not five compulsory isolated files. A summary links to the underlying evidence."
}
```
## slide-23
Две узкие пары показывают содержательное совпадение без заявления об эквивалентности документов. Связующий текст обозначает общую задачу, а не процент покрытия.
```json
{
"id": "slide-23", "kind": "crosswalk", "lang": "en",
"alt": "Two partial overlaps are shown: GOST 5.1.3.4 and NIST SSDF PO.2.1 share a concern with roles and responsibility; GOST 5.1.2.3 and SAMM Strategy and Metrics share a concern with an improvement roadmap. Scope and evidence expectations still differ.",
"caption": "Bounded comparison: a shared concern is useful, but does not establish full equivalence.",
"sourceIds": ["G24", "N11", "SAMM"],
"rows": [
{"left": "GOST 5.1.3.4", "bridge": "Roles & responsibility", "right": "SSDF PO.2.1"},
{"left": "GOST 5.1.2.3", "bridge": "Improvement roadmap", "right": "SAMM Strategy & Metrics"}
],
"note": "Partial overlap in both rows. Compare the full wording, scope and evidence expectations."
}
```
## slide-24
Возвращение к исходной схеме завершает учебную историю. Устранён разрыв в организации работы, но схема не выдаёт решение о безопасности конкретного выпуска.
```json
{
"id": "slide-24", "kind": "release", "lang": "en",
"alt": "The importer scenario returns with a connected path: identify the input and covered parser, retain the finding evidence, assign time and ownership for investigation, and record a release decision under the team's policy. This is a review of the process, not proof that a release is safe.",
"caption": "Return to Friday's release: can the team follow the finding through an owned, evidenced decision?",
"sourceIds": ["G24", "EX"],
"gap": false,
"nodes": [
{"label": "SCOPE", "title": "Input file", "detail": "Relevant scenario"},
{"label": "VERSION", "title": "Parser", "detail": "Covered component"},
{"label": "EVIDENCE", "title": "Finding", "detail": "Recorded result"},
{"label": "CAPACITY", "title": "Investigate", "detail": "Owner and time"},
{"label": "POLICY", "title": "Decide", "detail": "Decision and review"}
],
"note": "A usable decision process does not predetermine whether the release should proceed."
}
```
## ru-sdl-timeline
Русская версия шкалы поддерживает §2 самостоятельной лекции. Она сохраняет то же различение публикаций, редакций и появления практик, что и английский слайд.
```json
{
"id": "ru-sdl-timeline", "kind": "timeline", "lang": "ru",
"alt": "Выбранные публикации и редакции: исследование жизненного цикла 2004 года; SDL, Touchpoints и CLASP в 2006 году; руководство SDL-Agile v5.2 в 2012 году; сингапурский Security-by-Design в 2017 году; SAMM v2.0 в 2020 году; SSDF v1.1 в 2022 году. Это не даты первого возникновения всех идей.",
"caption": "Выбранные публикации и редакции из истории методологий. Обзор рассматривает 28 подходов; шкала не исчерпывает их историю.",
"sourceIds": ["MLR", "MSH", "SAMM20", "N11"],
"axis": [2004, 2022],
"nodes": [
{"year": 2004, "label": "2004", "title": "Жизненный цикл", "detail": "Jones и Rastogi"},
{"year": 2006, "label": "2006", "title": "SDL / Touchpoints", "detail": "CLASP"},
{"year": 2012, "label": "2012", "title": "SDL-Agile", "detail": "Руководство v5.2"},
{"year": 2017, "label": "2017", "title": "Security-by-Design", "detail": "Сингапурский framework"},
{"year": 2020, "label": "2020", "title": "SAMM v2.0", "detail": "Развитие возможностей"},
{"year": 2022, "label": "2022", "title": "SSDF v1.1", "detail": "NIST SP 800-218"}
],
"note": "Год публикации или редакции не обязательно совпадает с началом применения практики."
}
```
## ru-gost-timeline
Шкала дополняет точную таблицу §4. История проектов атрибутирована Варенице, а даты принятого документа проверяются по окончательному стандарту.
```json
{
"id": "ru-gost-timeline", "kind": "timeline", "lang": "ru",
"alt": "В апреле 2013 года началась НИР, в августе появился первый проект; в 2014–2015 годах продолжались рассмотрение и доработка; 1 июня 2016 года Росстандарт утвердил ГОСТ Р 56939-2016; 1 июня 2017 года стандарт введён в действие. Проектные этапы приведены по докладу Вареницы, две последние даты — по окончательному стандарту.",
"caption": "Подготовка проекта, утверждение и введение стандарта в действие — разные этапы.",
"sourceIds": ["TRANS", "GOSTH", "G16"],
"axis": [2013, 2017],
"nodes": [
{"year": 2013, "label": "2013", "title": "НИР и первый проект", "detail": "Апрель · август", "tone": "account"},
{"year": 2014.5, "label": "2014–2015", "title": "Обсуждение и доработка", "detail": "Рабочие редакции", "tone": "account"},
{"year": 2016, "label": "1 июня 2016", "title": "Утверждение", "detail": "Росстандарт · № 458-ст", "tone": "formal"},
{"year": 2017, "label": "1 июня 2017", "title": "Введение в действие", "detail": "ГОСТ Р 56939-2016", "tone": "formal"}
],
"note": "Проектные этапы: доклад Вареницы. Формальные даты: окончательный стандарт."
}
```
## ru-process-loop
Схема §7 показывает организационную устойчивость практики, не противопоставляя редакцию 2016 года якобы исключительно разовым мероприятиям.
```json
{
"id": "ru-process-loop", "kind": "loop", "lang": "ru",
"alt": "Поддерживаемый процесс соединяет событие, назначенную работу, зафиксированное решение и пересмотр порядка работы. В центре сохраняется связь с версией продукта и свидетельствами результата.",
"caption": "Учебная модель поддерживаемого процесса: действия, решения и обратная связь остаются связанными.",
"sourceIds": ["G24", "EX"],
"center": "Версия + свидетельства",
"nodes": [
{"label": "01", "title": "Событие", "detail": "Изменение, релиз, риск"},
{"label": "02", "title": "Исполнение", "detail": "Работа и ответственный"},
{"label": "03", "title": "Решение", "detail": "Результат и действия"},
{"label": "04", "title": "Пересмотр", "detail": "Следующий цикл работы"}
],
"note": "Запуск инструмента — одно из действий; результаты ещё нужно обработать."
}
```
## ru-planning-evidence
Карта §16 объединяет пять категорий информации. Она подчёркивает содержательные связи и не требует пяти изолированных документов.
```json
{
"id": "ru-planning-evidence", "kind": "planning", "lang": "ru",
"alt": "В выбранной области применения анализ исходного состояния и анализ ресурсов поддерживают план развития и план реализации процессов. Все пять категорий информации связаны с продуктом и обоснованием области.",
"caption": "Пять связанных результатов планирования по процессу 5.1 ГОСТ Р 56939-2024.",
"sourceIds": ["G24"],
"nodes": [
{"label": "5.1.3.1", "title": "Исходное состояние", "detail": "Практики и пробелы"},
{"label": "5.1.3.2", "title": "Анализ ресурсов", "detail": "Люди, время, средства"},
{"label": "5.1.3.3", "title": "План развития", "detail": "Приоритеты и очередь"},
{"label": "5.1.3.4", "title": "План реализации", "detail": "Работы, сроки, участники"},
{"label": "5.1.3.5", "title": "Область применения", "detail": "Состав и обоснование"}
],
"note": "Пять категорий сведений не означают пять обязательных отдельных файлов."
}
```
## ru-testing-map
Схема §9 связывает метод проверки с объектом внимания. Размещение блоков не изображает стадии зрелости, гарантированное покрытие или обязательный порядок проверок.
```json
{
"id": "ru-testing-map", "kind": "flow", "lang": "ru",
"alt": "Четыре взаимодополняющих направления проверки: анализ архитектуры рассматривает решения и границы доверия; статический анализ исследует исходный код; динамические проверки и фаззинг исследуют выполняемую программу; тестирование на проникновение рассматривает сценарии атакующего в заданных условиях.",
"caption": "Разные методы отвечают на разные вопросы о продукте; их результаты полезны в сочетании.",
"sourceIds": ["G24", "EX"],
"nodes": [
{"label": "АРХИТЕКТУРА", "title": "Решения", "detail": "Границы доверия"},
{"label": "СТАТИЧЕСКИЙ АНАЛИЗ", "title": "Исходный код", "detail": "Дефекты реализации"},
{"label": "ДИНАМИКА И ФАЗЗИНГ", "title": "Поведение", "detail": "Входы и исполнение"},
{"label": "ПЕНТЕСТ", "title": "Сценарии атаки", "detail": "Заданные условия"}
],
"note": "Связанные виды проверки, а не обязательная последовательность или измерение покрытия."
}
```
## ru-response-cycle
Цикл для §18 объединяет работу с сообщениями, решениями, исправлениями и последующим сопровождением. Это учебная схема; конкретные правила задаются применимым процессом и продуктом.
```json
{
"id": "ru-response-cycle", "kind": "loop", "lang": "ru",
"alt": "Работа с недостатком связывает регистрацию и анализ сообщения, решение об ответственных и действиях, исправление с проверкой, а затем обновление и сопровождение. Версия продукта и принятое решение должны оставаться прослеживаемыми.",
"caption": "Учебная схема работы с недостатком на протяжении сопровождения продукта.",
"sourceIds": ["G24", "EX"],
"center": "Версия + решение",
"nodes": [
{"label": "01", "title": "Сообщение", "detail": "Регистрация и анализ"},
{"label": "02", "title": "Решение", "detail": "Действия и участники"},
{"label": "03", "title": "Исправление", "detail": "Изменение и проверка"},
{"label": "04", "title": "Сопровождение", "detail": "Обновление и обратная связь"}
],
"note": "Конкретный порядок зависит от продукта, риска и применимых условий."
}
```
## ru-practical-plan
Схема §22 демонстрирует одну проверяемую цепочку в практической работе. Сохранена формулировка самостоятельного упражнения про сервис обработки файлов, без переноса часов и сроков английского примера.
```json
{
"id": "ru-practical-plan", "kind": "flow", "lang": "ru",
"alt": "Для сервиса обработки файлов выявленный пробел — отсутствие общего порядка обработки предупреждений — связывается с улучшением, задачей с участником и сроком, затем с сохранённым результатом проверки реального изменения.",
"caption": "Практическая работа: проследите связь от выявленного пробела до результата исполнения.",
"sourceIds": ["G24", "EX"],
"nodes": [
{"label": "ПРОБЛЕМА", "title": "Пробел", "detail": "Нет порядка обработки"},
{"label": "ПРИОРИТЕТ", "title": "Улучшение", "detail": "Согласовать действия"},
{"label": "ИСПОЛНЕНИЕ", "title": "Работа", "detail": "Участник и срок"},
{"label": "ПРОВЕРКА", "title": "Результат", "detail": "Реальное изменение"}
],
"note": "Каждая связь должна объясняться исходным состоянием, областью и доступными ресурсами."
}
```
SHA-256: 1c0680685a15e27e060713065bb7f2e2e3f13f49afa8032b1d3cd0c9260837ad
15EP01 — Where Secure Development BeginsREADME.md
EP01 — Where Secure Development Begins
Проект первого выпуска для репетиции. Серия Secure Software Development in Practice. Автор: Vitaliy Pikov. Подготовлено 6 сентября 2026 года.
Тема: введение в серию, история безопасной разработки, создание редакции ГОСТ 2016 года и процесс 5.1 «Планирование процессов разработки безопасного программного обеспечения» ГОСТ Р 56939-2024. Материалы выступления — на английском. 29 слайдов, рабочая длительность 42 минуты 20 секунд; окончательная длительность определяется репетицией и монтажом, увеличение автором разрешено.
Начать подготовку
- Открыть веб-презентацию. По умолчанию — последовательное чтение всех слайдов; режим Presentation — выступление с навигацией. Кнопка Speaker notes показывает полный текст речи. Управление: стрелки, Page Up / Page Down, Home / End; Escape возвращает к чтению.
- Прочитать план и режиссуру, затем полный английский сценарий по слайдам.
- Сделать пробную запись по памятке для репетиции и сверить её с расчётом хронометража.
- Для студентов, слушателей и специалистов использовать самостоятельную русскую лекцию или её Markdown-версию. Её можно читать без исходной записи и передавать партнёрам как учебный материал. Рабочие документы автора и английская речь собраны отдельно в HTML-обзоре комплекта.
Комплект
| Файл | Назначение |
|---|---|
| EP01-script-en.md | Канонический редактируемый текст: содержание слайдов, полная речь, источники, подсказки автору |
| EP01-plan.md | Результаты обучения, драматургия, границы, поминутный план |
| EP01-sources.md | Источники, версии, проверенные тезисы, использование архива, ограничения |
| EP01-history-research.md | Полный разбор двух PDF, карта 28 методологий, история ГОСТ с 2013 года и исправленные расхождения |
| PVS-2025-07-02-lecture.md | Самостоятельный учебный материал из двух основных частей: исторический доклад Виталия Вареницы и совместный практический разбор Андрея Карпова и Виталия Пикова. Введение, практикум и общие вопросы обозначены отдельно; первоисточник указан в заключительном примечании |
| PVS-2025-07-02-lecture.html | Та же учебная лекция с оглавлением и оформлением для чтения и печати; готовый файл для передачи слушателям и партнёрам |
| review.html | Обзор переработки, полная английская речь и архив всех Markdown-документов |
| EP01-planning-example.md | Заполненный учебный пример пяти связанных записей и распределения 96 часов |
| EP01-planning-worksheet.md | Англоязычный рабочий лист для зрителя |
| EP01-rehearsal.md | Английские термины, произношение, репетиция и запись |
| EP01-cover-design.md | Стиль обложек серии, исходные фотографии, точный запрос генерации |
| EP01-visuals.md | Канонический каталог 23 учебных SVG: 16 визуальных слайдов и 7 рисунков самостоятельной русской лекции; подписи, альтернативные описания, источники и границы выводов |
| EP01-publishing-draft.md | Название, описание, план глав и закреплённый комментарий YouTube |
| EP01-timing.md | Измеренный объём сценария и расчёт длительности при разных темпах |
| assets/ep01-cover.png | Сгенерированная титульная обложка с портретом автора |
Как редактировать
Изменять содержание и речь в EP01-script-en.md, сохраняя поля Seconds, Section, Layout, Lead, Items, Sources, Speech, Cue и связи с иллюстрациями. Плановая общая длительность задаётся строкой Target: mm:ss; число слайдов определяется автоматически, номера идут подряд от 1. Для контакта на последнем слайде используется поле Contact: имя | видимый адрес | HTTPS URL. Содержание рисунков редактируется в JSON-блоках EP01-visuals.md; текст русской лекции и ссылки на её рисунки — в PVS-2025-07-02-lecture.md.
Собирать комплект из папки EP01 в таком порядке:
py -3.14 build-visuals.py
py -3.14 build-content.py
py -3.14 build-review.py
build-visuals.py создаёт локальные SVG из каталога; build-content.py обновляет assets/episode-data.js и EP01-timing.md, проверяя сумму времени; build-review.py обновляет обе HTML-страницы из актуальных Markdown и данных выпуска. Источники для отображения задаются в build-content.py; подробная методическая запись — в EP01-sources.md. Изменение только готового HTML или SVG без соответствующего Markdown-источника не является завершённой правкой.
Для двух HTML-материалов выполнить py -3.14 build-review.py (нужны библиотеки markdown и beautifulsoup4, доступные в этой среде). Генератор находится в репозитории, читает актуальные Markdown и данные слайдов, не зависит от временных HTML предыдущих задач. --check проверяет сборку без записи. После браузерной проверки --archive "V:\tmp\codex\YYYY-MM-DD\YYYY-MM-DD-тема.html" --qa-text "Результат проверки" создаёт новую архивную копию; существующий архив не перезаписывается. После изменений перезагрузить страницу.
Презентация использует обычные HTML, CSS и JavaScript, локальные файлы и системные шрифты. Сервер, сборщик и интернет для чтения не требуются. Для проверки через локальный сервер: python -m http.server 8765 --bind 127.0.0.1 --directory .; открыть http://127.0.0.1:8765/. Это локальный просмотр, а не публикация сайта. Политика конкретного встроенного браузера может ограничивать открытие локальных файлов.
Визуальная подача
На слайдах 03, 04, 05, 08, 11, 12, 13, 15, 16, 17, 19, 20, 21, 22, 23 и 24 текстовые списки дополнены или заменены объясняющей графикой: шкалами времени, границами области, циклами работы, картой планирования и сопоставлением требований. На слайдах 04 и 24 повторяется одна история импортёра; на слайдах 16 и 22 — одна структура требований и соответствующих свидетельств. Диаграмма 60 + 24 + 12 = 96 человеко-часов обозначена учебной оценкой.
В русской лекции — семь рисунков: история методологий, подготовка ГОСТ, поддерживаемый процесс, направления проверок, свидетельства планирования, сопровождение и практическая работа. Их содержание сохраняется синхронно в Markdown и HTML. Локальные SVG не требуют внешних сервисов; при передаче Markdown вместе с ним передаются рисунки по его относительным ссылкам.
Основной видимый текст и подписи используют начертания 600/700. Схемы заменяют часть плотного текста, а подробное объяснение остаётся в речи и лекции. Браузерная проверка всех 29 слайдов при 720p, Full HD и 4K и мобильного чтения выполнена: результаты проверки. После будущих правок проверку повторять; качество фактической записи и печати оценивается отдельно.
Шкала SDL показывает шесть выбранных публикаций/редакций 2004–2022, включая Singapore Security-by-Design 2017 года. Даты взяты из Table II обзора с указанными уточнениями, а Figure 2 не копируется: её расхождения сохранены в исследовательской записке. Дата публикации не подменяет дату появления идеи.
Полная расшифровка вебинара от 2 июля 2025 года прочитана до последней метки 02:07:28. История теперь охватывает ранние обсуждения, НИР, роль разработчика и рецензентов, замысел семейства документов, международные связи и переход между редакциями. Сверка окончательных текстов уточнила девять групп мер 2016 года и различную модальность слова «следует». Из дискуссии в практику включены анализ уже работающих процессов, ресурсные оценки, регулярность проверок и использование существующих систем для свидетельств.
Заключительный слайд 25 содержит имя Vitaliy Pikov, активную ссылку pikov.art и анонс EP02 Security Training That Changes Engineering Decisions: роли и навыки, практическое задание до/после обучения, свидетельства прогресса. Его слот — 40:35–53:00.
Оба переданных TXT сохранены с исходными именами и содержимым. «Пересказ» используется как вспомогательная навигация, а не самостоятельное доказательство; расшифровка содержит ошибки распознавания и единый технический ярлык участника. Неподтверждённые утверждения и исторические условия сертификации не выдаются за действующие универсальные правила.
Файлы PowerPoint и PDF не создавались по выбору автора. Видео, внешняя рецензия и финальная репетиция ещё не выполнены. Пример вымышленный; английские переводы положений — рабочие авторские. Этот выпуск не заявляет полного соответствия ГОСТ и не решает вопрос уникальности всех 25 процессов.
Исходный Markdown целиком
# EP01 — Where Secure Development Begins
**Проект первого выпуска для репетиции.** Серия *Secure Software Development in Practice*. Автор: Vitaliy Pikov. Подготовлено 6 сентября 2026 года.
Тема: введение в серию, история безопасной разработки, создание редакции ГОСТ 2016 года и процесс **5.1 «Планирование процессов разработки безопасного программного обеспечения»** ГОСТ Р 56939-2024. Материалы выступления — на английском. **29 слайдов, рабочая длительность 42 минуты 20 секунд**; окончательная длительность определяется репетицией и монтажом, увеличение автором разрешено.
## Начать подготовку
1. Открыть [веб-презентацию](index.html). По умолчанию — последовательное чтение всех слайдов; режим Presentation — выступление с навигацией. Кнопка Speaker notes показывает полный текст речи. Управление: стрелки, Page Up / Page Down, Home / End; Escape возвращает к чтению.
2. Прочитать [план и режиссуру](EP01-plan.md), затем [полный английский сценарий по слайдам](EP01-script-en.md).
3. Сделать пробную запись по [памятке для репетиции](EP01-rehearsal.md) и сверить её с [расчётом хронометража](EP01-timing.md).
4. Для студентов, слушателей и специалистов использовать [самостоятельную русскую лекцию](PVS-2025-07-02-lecture.html) или её [Markdown-версию](PVS-2025-07-02-lecture.md). Её можно читать без исходной записи и передавать партнёрам как учебный материал. Рабочие документы автора и английская речь собраны отдельно в [HTML-обзоре комплекта](review.html).
## Комплект
| Файл | Назначение |
|---|---|
| [EP01-script-en.md](EP01-script-en.md) | Канонический редактируемый текст: содержание слайдов, полная речь, источники, подсказки автору |
| [EP01-plan.md](EP01-plan.md) | Результаты обучения, драматургия, границы, поминутный план |
| [EP01-sources.md](EP01-sources.md) | Источники, версии, проверенные тезисы, использование архива, ограничения |
| [EP01-history-research.md](EP01-history-research.md) | Полный разбор двух PDF, карта 28 методологий, история ГОСТ с 2013 года и исправленные расхождения |
| [PVS-2025-07-02-lecture.md](PVS-2025-07-02-lecture.md) | Самостоятельный учебный материал из двух основных частей: исторический доклад Виталия Вареницы и совместный практический разбор Андрея Карпова и Виталия Пикова. Введение, практикум и общие вопросы обозначены отдельно; первоисточник указан в заключительном примечании |
| [PVS-2025-07-02-lecture.html](PVS-2025-07-02-lecture.html) | Та же учебная лекция с оглавлением и оформлением для чтения и печати; готовый файл для передачи слушателям и партнёрам |
| [review.html](review.html) | Обзор переработки, полная английская речь и архив всех Markdown-документов |
| [EP01-planning-example.md](EP01-planning-example.md) | Заполненный учебный пример пяти связанных записей и распределения 96 часов |
| [EP01-planning-worksheet.md](EP01-planning-worksheet.md) | Англоязычный рабочий лист для зрителя |
| [EP01-rehearsal.md](EP01-rehearsal.md) | Английские термины, произношение, репетиция и запись |
| [EP01-cover-design.md](EP01-cover-design.md) | Стиль обложек серии, исходные фотографии, точный запрос генерации |
| [EP01-visuals.md](EP01-visuals.md) | Канонический каталог 23 учебных SVG: 16 визуальных слайдов и 7 рисунков самостоятельной русской лекции; подписи, альтернативные описания, источники и границы выводов |
| [EP01-publishing-draft.md](EP01-publishing-draft.md) | Название, описание, план глав и закреплённый комментарий YouTube |
| [EP01-timing.md](EP01-timing.md) | Измеренный объём сценария и расчёт длительности при разных темпах |
| [assets/ep01-cover.png](assets/ep01-cover.png) | Сгенерированная титульная обложка с портретом автора |
## Как редактировать
Изменять содержание и речь в `EP01-script-en.md`, сохраняя поля `Seconds`, `Section`, `Layout`, `Lead`, `Items`, `Sources`, `Speech`, `Cue` и связи с иллюстрациями. Плановая общая длительность задаётся строкой `Target: mm:ss`; число слайдов определяется автоматически, номера идут подряд от 1. Для контакта на последнем слайде используется поле `Contact: имя | видимый адрес | HTTPS URL`. Содержание рисунков редактируется в JSON-блоках [EP01-visuals.md](EP01-visuals.md); текст русской лекции и ссылки на её рисунки — в `PVS-2025-07-02-lecture.md`.
Собирать комплект из папки EP01 в таком порядке:
```powershell
py -3.14 build-visuals.py
py -3.14 build-content.py
py -3.14 build-review.py
```
`build-visuals.py` создаёт локальные SVG из каталога; `build-content.py` обновляет `assets/episode-data.js` и `EP01-timing.md`, проверяя сумму времени; `build-review.py` обновляет обе HTML-страницы из актуальных Markdown и данных выпуска. Источники для отображения задаются в `build-content.py`; подробная методическая запись — в `EP01-sources.md`. Изменение только готового HTML или SVG без соответствующего Markdown-источника не является завершённой правкой.
Для двух HTML-материалов выполнить `py -3.14 build-review.py` (нужны библиотеки `markdown` и `beautifulsoup4`, доступные в этой среде). Генератор находится в репозитории, читает актуальные Markdown и данные слайдов, не зависит от временных HTML предыдущих задач. `--check` проверяет сборку без записи. После браузерной проверки `--archive "V:\tmp\codex\YYYY-MM-DD\YYYY-MM-DD-тема.html" --qa-text "Результат проверки"` создаёт новую архивную копию; существующий архив не перезаписывается. После изменений перезагрузить страницу.
Презентация использует обычные HTML, CSS и JavaScript, локальные файлы и системные шрифты. Сервер, сборщик и интернет для чтения не требуются. Для проверки через локальный сервер: `python -m http.server 8765 --bind 127.0.0.1 --directory .`; открыть `http://127.0.0.1:8765/`. Это локальный просмотр, а не публикация сайта. Политика конкретного встроенного браузера может ограничивать открытие локальных файлов.
## Визуальная подача
На слайдах **03, 04, 05, 08, 11, 12, 13, 15, 16, 17, 19, 20, 21, 22, 23 и 24** текстовые списки дополнены или заменены объясняющей графикой: шкалами времени, границами области, циклами работы, картой планирования и сопоставлением требований. На слайдах 04 и 24 повторяется одна история импортёра; на слайдах 16 и 22 — одна структура требований и соответствующих свидетельств. Диаграмма 60 + 24 + 12 = 96 человеко-часов обозначена учебной оценкой.
В русской лекции — **семь рисунков**: история методологий, подготовка ГОСТ, поддерживаемый процесс, направления проверок, свидетельства планирования, сопровождение и практическая работа. Их содержание сохраняется синхронно в Markdown и HTML. Локальные SVG не требуют внешних сервисов; при передаче Markdown вместе с ним передаются рисунки по его относительным ссылкам.
Основной видимый текст и подписи используют начертания **600/700**. Схемы заменяют часть плотного текста, а подробное объяснение остаётся в речи и лекции. Браузерная проверка всех 29 слайдов при 720p, Full HD и 4K и мобильного чтения выполнена: [результаты проверки](EP01-visual-review.md). После будущих правок проверку повторять; качество фактической записи и печати оценивается отдельно.
Шкала SDL показывает шесть выбранных публикаций/редакций **2004–2022**, включая Singapore Security-by-Design 2017 года. Даты взяты из Table II обзора с указанными уточнениями, а Figure 2 не копируется: её расхождения сохранены в [исследовательской записке](EP01-history-research.md). Дата публикации не подменяет дату появления идеи.
Полная расшифровка вебинара от 2 июля 2025 года прочитана до последней метки 02:07:28. История теперь охватывает ранние обсуждения, НИР, роль разработчика и рецензентов, замысел семейства документов, международные связи и переход между редакциями. Сверка окончательных текстов уточнила девять групп мер 2016 года и различную модальность слова «следует». Из дискуссии в практику включены анализ уже работающих процессов, ресурсные оценки, регулярность проверок и использование существующих систем для свидетельств.
Заключительный слайд **25** содержит имя Vitaliy Pikov, активную ссылку [pikov.art](https://pikov.art) и анонс EP02 **Security Training That Changes Engineering Decisions**: роли и навыки, практическое задание до/после обучения, свидетельства прогресса. Его слот — 40:35–53:00.
Оба переданных TXT сохранены с исходными именами и содержимым. «Пересказ» используется как вспомогательная навигация, а не самостоятельное доказательство; расшифровка содержит ошибки распознавания и единый технический ярлык участника. Неподтверждённые утверждения и исторические условия сертификации не выдаются за действующие универсальные правила.
Файлы PowerPoint и PDF не создавались по выбору автора. Видео, внешняя рецензия и финальная репетиция ещё не выполнены. Пример вымышленный; английские переводы положений — рабочие авторские. Этот выпуск не заявляет полного соответствия ГОСТ и не решает вопрос уникальности всех 25 процессов.
SHA-256: b8f080c8d95903f7511b580261f4d891a4c76c63b18914537b4b72110d2e0087
Где лежат результаты
Материалы открываются по относительным ссылкам на сайте и в локальной копии. Полный текст речи и Markdown-документов также включён в эту страницу.
- 01
Самостоятельная учебная лекция
История методологий и стандартов, процессы безопасной разработки и практические примеры.
PVS-2025-07-02-lecture.md - 02
Учебная лекция для чтения в браузере
Страница для читателя: содержание, полный текст и библиография.
PVS-2025-07-02-lecture.html - 03
- 04
Английская речь по каждому слайду
Редактируемый источник содержания презентации и полной речи.
EP01-script-en.md - 05
История и границы источников
Сопоставление исторического рассказа, исследовательских публикаций и нормативных источников.
EP01-history-research.md - 06