РБПО-036. Процесс 3 — Формирование и предъявление требований безопасности к программному обеспечению

Обеспечение безопасности ПО посредством предъявления к нему требований и управления требованиями в процессе изменения (разработки) ПО. (ГОСТ Р 56939—2024, п. 5.3.1.1)

Этот процесс я понимаю так: необходимо спланировать и разработать регламент, как будет ставиться ТЗ для внутренних/внешних команд и контролироваться ход выполнения работ. Управление процессом рекомендуется осуществлять с использованием средств автоматизации: системы управления изменениями, системы управления задачами и т. д.

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

Оговаривается состав команды, чтобы не было такого, что в начале обсуждают команду высокооплачиваемых квалифицированных специалистов, а затем передают стажёрам на полставки :))

5.3.3.2 Набор требований безопасности ПО должен содержать следующую информацию:
...
• сведения о сотрудниках (подразделениях), предъявивших требования;
• сведения о сотрудниках (подразделениях), принявших требования к реализации.

Полный список артефактов приводить здесь не буду и отсылаю за ним к стандарту. В целом про этот процесс я мало что могу написать. Я не эксперт в данной теме и, наверное, не осознаю всю глубину этого процесса и его наполнение. Постараемся с чей-то помощью подробнее его раскрыть на третьем вебинаре серии "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024".

О, в нас верят :)

ФСТЭК России объявила о начале масштабных испытаний статических анализаторов

На встрече обсудили цели и задачи испытаний, критерии оценок, инфраструктуру, сроки, состав жюри и тесты для испытаний. Было принято решение провести мероприятие на базе кафедры ИУ10 «Защита информации» МГТУ им. Н. Э. Баумана в два этапа: «домашнее задание» (завершается 15 мая) и основной этап испытаний (июль-октябрь). Итогом станет аналитический доклад от ФСТЭК России на Открытой конференции по результатам испытаний (декабрь 2025 г.).

Делайте ставки, господа!

Мой прогноз такой:

- Svace и PVS-Studio поделят первое и второе место
- Третье место будет у Clang Static Analyzer
- Synopsys Coverity - техническое поражение из-за неявки
- `cppcheck` - почётное последнее место

via

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

Комментарий не соответствует картинке. Авторы картинки считают что TN 41.5% это плохо. Ну и абстрактно звучит плохо. 41.5% разыменований нулевых указателей не обнаружено, если я правильно понял метрику

TN - это насколько верно, что нет предупреждений, где нет ошибок. Неудачная метрика :) Но раз надо было предоставить, то вот. По простому: это обратная метрика к FP (ложноположительным срабатываниям).

Обнаружен 81,5% (TP) нулевых указателей в тестах, где надо было их обнаружить. Т.е. в тестах выявляется 81,5% имеющихся там ошибок.

И это разные наборы тестов. Первый набор тестов используется для подсчёта TP (и FN). А второй набор тестов для FP (и TN).

Ещё были тесты дополнительного набора, но это уже другая история.

РБПО-037. Процесс 4 — Управление конфигурацией программного обеспечения
Цели четвёртого процесса по ГОСТ Р 56939-2024:

5.4.1.1 Осуществление уникальной идентификации ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).
5.4.1.2 Контроль реализации изменений ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).

Для небольших компаний с одним-двумя проектами под одну платформу первый пункт может смотреться избыточным. Нумеруем релизы и всё. Что ещё нужно?

Процесс обретает значимость и пользу, когда компания разрабатывает линейку различных (иногда схожих) продуктов под разные платформы. Могут существовать различные конфигурации для различных пользователей. Возможно одновременное использование разных версий продукта в разных (а иногда и в одной) компании.

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

При разработке регламента идентификации ПО (версий ПО, модулей ПО) можно оттолкнуться от ГОСТ 19.103-77. Единая система программной документации. Обозначение программ и программных документов.

ГОСТ Р 56939-2024 даёт следующее определение управлению конфигурацией программного обеспечения:

3.19 управление конфигурацией программного обеспечения: Скоординированные действия, направленные на формирование и контроль конфигурации программного обеспечения.

Если честно, это определение мало что даёт :) Поэтому вот дополнительные ссылки:
• Управление конфигурацией.
• Конфигурационное управление.

Запись второй встречи цикла «Вокруг РБПО за 25 вебинаров. ГОСТ Р 56939-2024». Процесс N2: Обучение сотрудников.

РБПО-038. Процесс 5 — Управление недостатками и запросами на изменение программного обеспечения (часть 1/3)
Цели пятого процесса по ГОСТ Р 56939-2024:

5.5.1.1 Обеспечение управления недостатками ПО.
5.5.1.2 Обеспечение управления запросами на изменение ПО.

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

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

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

Требования к реализации:

5.5.2.1 Разработать регламент управления недостатками ПО.
5.5.2.2 Разработать регламент управления запросами на изменение ПО.
5.5.2.3 Контролировать реализацию изменений, связанных с недостатками ПО.
5.5.2.4 Контролировать реализацию запросов на изменение в рамках жизненного цикла ПО.
5.5.2.5 Использовать средства автоматизации для управления недостатками и запросами на изменение разрабатываемого ПО.

Примечание — В качестве средств автоматизации рекомендуется использовать системы управления изменениями, системы управления задачами, системы контроля версий и т. п. При этом рекомендуется обеспечивать взаимосвязь (перекрестные ссылки) между такими системами при исправлении недостатков.

Дополнительные ссылки:
1. Александр Мешков. Как выстроить эффективный процесс управления дефектами?
2. Wikipedia. Система управления версиями.
3. Андрей Рассамакин. Управление инцидентами и проблемами — понятия и принципы.
4. AppSec Table Top: методология безопасной разработки от Positive Technologies. См. инициативы: Система контроля версий — стр. 49, Порядок работы с дефектами — стр. 78.

РБПО-039. Процесс 5 — Управление недостатками и запросами на изменение программного обеспечения (часть 2/3)
Рассмотрим артефакты 5-го процесса ГОСТ Р 56939-2024.

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

5.5.3.2 Регламент управления запросами на изменение ПО должен содержать:
- порядок идентификации запросов на изменение ПО;
- порядок управления запросами на изменение ПО, включающий сведения о действиях, выполняемых при осуществлении запроса на изменение, тестировании, принятии решения о закрытии запроса на изменение.

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

У нас нет именно документа-регламента, т.к. мы пока не планируем проходить сертификацию, но есть заготовленные чек-листы для различных типов задач. Если до этого дойдёт, то думаю, эти чек-листы как раз и станут основой регламента. Как я понимаю, основная идея регламента — не пропустить этап (например, тестирование) и быть уверенным, что если задача закрыта, то значит она сделана. Для этого и нужны чек-листы.

Пример одной нашей заготовки, из которой формируется задача, когда выходит новая версия IDE Qt Creator. Т.е. на основании этой заготовленного чек-листа ставится задача провести работы по проверке совместимости PVS-Studio с новой версией Qt Creator и в случае необходимости что-то доработать. Ссылки заменил на жирный шрифт.

Описание всех указанных ниже действий можно найти в документации. В случае возникновения вопросов можно обращаться к ___. На выполнение задачи стоит закладывать не менее двух дней, т.к. часто бывают неожиданные сюрпризы. Начинать стоит только после появления дистрибутива по этой ссылке.

Примечание. Ниже не описание задачи. Как и что делать описано отдельно во внутренней статье. Это именно чек-лист, чтобы что-то не забыть. То, что вне контекста отдельные пункты смотрятся непонятно, это нормально.

Шаблон этой задачи (чек-лист)

✅Узнать требуемую версию Qt
✅Заложить новые компоненты на наше зеркало
✅Qt (Windows, Linux, macOS)
✅Qt Creator (Windows, Linux, macOS)
✅Добавить новую версию Qt в сборочное окружение
✅Windows-контейнер
✅Linux-контейнер
✅Сборочный сервер на macOS
✅Добавить CMake пресет для новой версии
✅Фиксы по коду (Windows, Linux, macOS)
✅Оттестировать новую версию на всех платформах:
✅Windows
✅Linux
✅macOS
✅Добавить новую версию в manifest плагина (extension_manifest.json)
✅Добавить / модифицировать тесты
✅Код-ревью с ___. При его отсутствии (на усмотрение тимлида)
✅Модифицировать pipeline сборки на сервере:
✅Добавить новую версию
✅Убрать прошлую
✅Проверить и актуализировать документацию по разработке плагина
✅Добавить упоминание новой версий в документации плагина
✅Удостовериться, что новая версия плагина добавляется в дистрибутив
✅Добавить новую версию плагина на страницу beta-загрузок - задача

Завтра 16.07.2025 в 16:00 по МСК состоится третий вебинар на тему "Формирование и предъявление требований безопасности к программному обеспечению".

Приглашённый гость: Павлов Артем. Начальник отдела управления испытаниями и контроля качества департамента испытаний ООО "ЦБИ", на базе которого была создана испытательная лаборатория. Участник от организации в ТК362 ФСТЭК России по разработке отечественных стандартов.

Приглашаю зарегистрироваться: Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024.

P.S. Для тех, кто уже регистрировался на предыдущие вебинары этой серии, повторная регистрация не требуется.

РБПО-040. Процесс 5 — Управление недостатками и запросами на изменение программного обеспечения (часть 3/3)
Продолжим рассматривать артефакты 5-го процесса ГОСТ Р 56939-2024.

5.5.3.3 Артефакты реализации требований, подтверждающие реализацию управления недостатками ПО, должны содержать зафиксированные факты изменений, связанных с недостатками, включающие следующую информацию:
- уникальный идентификатор недостатка ПО;
- описание недостатка ПО;
- версию ПО (модуля ПО, компонента ПО), к которому относится недостаток ПО;
- приоритет выполнения действий с недостатком ПО;
- текущий статус обработки изменений, связанных с недостатками ПО.

5.5.3.4 Артефакты реализации требований, подтверждающие реализации управления запросами на изменение ПО, должны содержать следующую информацию:
- уникальный идентификатор запроса на изменение ПО;
- краткую характеристику запроса на изменение ПО;
- версию ПО (модуля ПО, компонента ПО), к которому относится запрос на изменение;
- приоритет выполнения действий с запросом на изменение ПО;
- текущий статус обработки запроса на изменение ПО.

Всё это само собой будет реализовано при аккуратном использовании, наверное, любого багтрекера (системы автоматизации для управления недостатками и запросами на изменение).

Каждой задаче (тикету) автоматически присваивается уникальный идентификатор. Краткая характеристика запроса на изменение ПО, естественно, должна присутствовать при постановке задачи. Если кто-то напишет в названии задачи "Сделать X", а в описании "см. subj", то за такое надо ..... ........ ........ (принять административные меры) и без регламента :)

Естественно, указывается версия ПО, модуля и т.д., когда описывается баг, чтобы его можно было воспроизвести. Ну или где какая новая функциональность нужна. Здесь вроде всё тоже очевидно. Достаточно просто сформулировать всё это в виде регламента и договориться, как что называется и нумеруется (см. четвёртый процесс в ГОСТ Р 56939-2024 и ГОСТ 19.103-77 — Обозначение программ и программных документов).

"Приоритет выполнения действий с запросом на изменение ПО". Кажется, в любом багтрекере необходимо установить уровень важности задачи/бага. Единственное, это хороший момент более чётко сформулировать, кто и как решает, каков будет этот приоритет. Этот пункт ещё пересекается с 23-м процессом "Реагирование на информацию об уязвимостях", но про это мы поговорим позже.

"Текущий статус обработки запроса на изменение ПО". Здесь каждый сам формирует статусы задач, теги, принципы смены этих статусов и какие комментарии надо писать в процессе работы над задачей. Думаю, самые важные моменты:
• задача не должна теряться;
• открыв задачу, любой член команды должен по описанию и комментариям понять, в чём её суть и что сейчас происходит с задачей;
• задача должна закрываться, когда она сделана и всё, что нужно, было проверено.

Презентация для тех, кто сейчас на моём докладе, но не видит код на экране :)

У нас радостная весть!

ФСТЭК России согласовал программу повышения квалификации М-БРПО «Специалист по процессам разработки безопасного программного обеспечения»🎉

Мы долго к этому шли и вот, 25 июня 2025 года, программа была согласована!

Ключевые особенности программы:
• Соответствие требованиям ФСТЭК России и актуальным стандартам в области безопасной разработки ПО.
• Углублённое изучение процессов обеспечения безопасности на всех этапах жизненного цикла ПО.
• Практико-ориентированный подход с разбором реальных кейсов и применением современных инструментов защиты.
После успешного завершения обучения слушатели получат удостоверение о повышении квалификации, подтверждающее их компетенции в области безопасной разработки программного обеспечения.

Дата старта ближайшего потока: 04.08.2025
Запись на курс доступна по ссылке Специалист по процессам разработки безопасного программного обеспечения | Форма обучения очная 200 часов / 20 дней

Запись третьего вебинара цикла "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024": Формирование и предъявление требований безопасности к программному обеспечению.

Приглашенный эксперт — Артем Павлов, начальник отдела управления испытаниями и контроля качества департамента испытаний ООО "ЦБИ".