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

Начало в 16:00 по МСК

Напоминаю про вебинар! Время заварить чай и подключаться! :)

РБПО-035. Процесс 2 — Обучение сотрудников (часть 4/4)
Закончим рассматривать артефакты процесса обучения, перечисленные в ГОСТ Р 56939-2024.

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

Перечисленное говорит само за себя, но не забывайте, что речь идёт про процесс, а не про разовую акцию повышения квалификации сотрудников, которые трудятся в компании на данный момент. Есть смысл "вшить" это в матрицы компетенций. Это будет помогать адаптировать (обучать) как новых сотрудников, так и постепенно повышать уровень компетенций опытных членов команды. Заодно естественным образом разделится, что должен изучать программист, а что — специалист ИБ. У них будут разные матрицы компетенций.

Тема матриц компетенций интересная, но большая и выходит за рамки этого цикла публикаций. Думаю, на эту тему можно многое почерпнуть из записей докладов конференций TeamLead Conf и подобных (например 1, 2, 3). Ещё добавлю, что мы её внедрили и довольны результатами.

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

Когда вас условно (или буквально) посетит команда аудиторов, вам должно быть, что ей показать :) Начинайте централизовано собирать отчётную информацию и, видимо, есть смысл назначить кого-то ответственным за эти процесс. Иначе в нужный момент вспомнить всё, что было, и предоставить подтверждающие документы будет сложно.

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

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

И последний пункт артефактов:

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

Пока здесь я постепенно прохожу по каждому процессу ГОСТ Р 56939-2024, параллельно выкладываем обзорные доклады про этот стандарт. Четвёртый из пяти:
Процессы РБПО 5.11-5.25 в ГОСТ Р 56939-2024
(рекомендую смотреть на скорости 1,25 - 1,5)

В программе:
Андрей Карпов: Типовые паттерны опечаток и как их избежать.
Марк Шевченко: Верификация программ и доказательство корректности .NET-кода.
Роман Гапонов: Все о Code Review: лучшие практики и анти-паттерны.

РБПО-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-загрузок - задача