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

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

На встрече обсудили цели и задачи испытаний, критерии оценок, инфраструктуру, сроки, состав жюри и тесты для испытаний. Было принято решение провести мероприятие на базе кафедры ИУ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": Формирование и предъявление требований безопасности к программному обеспечению.

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

Сплошные плюсы. Клуб С++ разработчиков. Стань докладчиком

Команда PVS-Studio вместе с Центральным университетом 7 августа устраивает очередную встречу "Клуба С++ разработчиков". Первый доклад будет от нашей команды, а второго докладчика мы хотим привлечь со стороны. Так интереснее и разнообразнее, чем если только мы будем рассказывать :)

Мы приглашаем докладчиков на это и последующие мероприятия. Можно рассказать что-то сложное и не очень, можно рассказать что-то специализированное, можно потренироваться выступать. Напишите нам тему, которая вам не даёт покоя и хочется про неё рассказать, и мы обсудим ваше участие в одной из встреч. Контакт – Симанихина Татьяна, DevRel PVS-Studio (simanikhina@viva64.com).

Например, на встрече 26 июня были доклады по таким темам:
– Типовые ошибки C и C++ программистов и как с ними бороться;
– Основы парсинга C++ кода.

Плагин PVS-Studio для OpenIDE
Анализатор PVS-Studio совместим с российской средой разработки OpenIDE.

OpenIDE — бесплатная лицензионно чистая IDE на базе IntelliJ IDEA Community Edition с открытым исходным кодом. Вся инфраструктура для сборки и работы OpenIDE расположена в России. Для отправки статистики, поиска обновлений, подключения плагинов и т.д. среда разработки обращается только к серверам на территории РФ. В маркетплейсе OpenIDE с самого первого дня доступно более 300 плагинов.

Теперь плагин PVS-Studio можно скачивать из маркетплейса дополнений OpenIDE.

Краткий экскурс в ГОСТ Р 56939-2024
Оформили и выложили пятую финальную часть моего рассказа про ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения. Поскольку все части записывались сразу, к моменту выхода этого заключительного видео, я понимаю, что сейчас бы немного по другому его рассказал. Видение меняется, появляется новая информация. Например, завершился этап домашнего задания испытаний анализаторов кода и про это стоило бы упомянуть. Но не страшно, про новое расскажем в рамках других митапов и вебинаров.

Все части:
1) Причины разработки и выпуска нового ГОСТ Р 56939-2024 на замену версии 2016 года
2) Содержание ГОСТ Р 56939-2024 и его структура
3) Процессы РБПО 5.1-5.10 в ГОСТ Р 56939-2024
4) Процессы РБПО 5.11-5.25 в ГОСТ Р 56939-2024
5) ГОСТ Р 56939-2024: вопросы сертификации, выводы и дополнительные ссылки

О пользе присутствия на вебинарах – возможность задавать вопросы
Цикл вебинаров про ГОСТ Р 56939-2024, это не только возможность послушать, но и задать вопросы. Поднимаются очень интересные темы. Поэтому приглашаю подключаться. Впереди ещё 22 вебинара. Что-бы заинтересовать, приведу пример.

Перед вами расшифровка фрагмента секции вопросов и ответов второго вебинара "Обучение сотрудников", где приглашённым гостем был Виталий Вареница (ЗАО "НПО "Эшелон").

Расшифровка автоматическая и в тексте будут неточности, плюс местами я вырезал для лаконичности. Однако в целом это демонстрирует, какие интересные темы обсуждаются! Подробнее смотрите в записи.

Зачитывается вопрос Антона из чата: «так, сначала за заявку в ФСТЭК с РБПО, потом лаборатория, органы по сертификации ФСТЭК. Это необходимо на первом этапе для подачи заявки…»

Виталий Пиков: Немного спутались понятия.

Виталий Вареница: — Да-да-да. У Антона классический микс. Значит, тут, смотрите, я предлагаю, сделать отдельный какой-нибудь вебинар. Знаете, про что? Сертификация СЗИ и РБПО. Потому что у вас точно этого в процессах нет. Ну, в 25 процессах этого нет. А 99% вендоров, которые к нам приходят, у них плюс-минус такие же вопросы. Это уже набитая шишка, по которой мы постоянно идем.

— Вот смотрите, для того, чтобы ответить, Антон, на ваш вопрос, мне нужно где-то минут 25−30 вам сказать о том, как процессы на самом деле устроены по сертификации средств защиты информации и по сертификации РБПО. Почему? Потому что, судя по вопросу, я вижу, что есть микс. И они, к сожалению, очень часто, когда общаемся мы на форумах различных, и даже с регуляторами иногда общаемся, регуляторы тоже имеют в виду одно у себя в презентации или на слайдах, но говорят немножко про другое. Для того, чтобы в этом разобраться, ну как бы нужно понимать, то есть пройти вот эти процессы от нуля до конца, ну желательно хотя бы не один раз. Поэтому здесь, ну как бы я попытаюсь вкратце ответить, но как бы история какая, значит, «необходим на первом этапе для подачи заявки», утверждает Антон, но история какая…

— Он необходим для подачи заявки, если вы подаетесь на сертификацию процесса безопасной разработки. Если вы поддаетесь на сертификацию средств защиты информации, он не необходим. Это некорректное утверждение. Значит, там есть требование какое при сертификации средств защиты информации? Вы, как вендор, как заявитель, должны иметь базовую лицензию на разработку средств защиты конфиденциальной информации. Почему? Потому что Антон написал, ему четвертый УД интересен.

— Вот. И там, да, действительно есть требование к персоналу, к людям, что вы, у вас должно быть не менее трех человек с таким-то опытом работы, с таким-то образованием, с такими-то требованиями по повышению квалификации. Сейчас подробнее грузить не буду. И тогда получается, что нужно это на этапе подачи заявки подтвердить, но опять подтверждается это чем? Лицензией.

— Лицензия на разработку с СЗК и есть, но ФСТЭК не перепроверяет ваших людей, их компетенции, курсы и так далее. Потому что это отдельный процесс лицензирования, который был проведен уже до того момента. До наличия лицензии вы заявку на сертификацию подать не сможете, ФСТЭК ее просто не примет у вас. Следующий момент, судя по вопросу. На первом этапе это нужно сначала подать, как так написано, во ФСТЭК.

Продолжение
— «Сначала заявка во ФСТЭК с РБПО, потом в лабораторию, органы и т.д». Нет. Нет. Это неправильно. В 55-м положении четко прописано сейчас в обновлении, что заявку во ФСТЭК подают заявители с испытательной лаборатории. Более того, в заявке стоят две подписи. Подпись разработчика заявителя и начальника испытательной лаборатории. Для чего это ФСТЭК сделал?

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

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

— Поэтому первое все равно все это изучает, анализирует, выдает какие-то рекомендации, вопросы, уточнения. Это не ФСТЭК и не органы по сертификации, а именно испытательная лаборатория. А уже потом, когда испытательная лаборатория через свои фильтры прогнала и сказала, что да, окей, теперь нам не стыдно это во ФСТЭК отправить для того, чтобы решение на сертификацию получить.

— Только после этого уже там подключаются все остальные участники, потому что у нас участников 4, минимум 4. Это заявитель, это федеральный орган ФСТЭК, это испытательные лаборатория и это назначенный орган сертификации. Вот эти четыре участника процесса, сертификации и следовательской информации, они у нас прописаны в явном виде в положении сертификации в 55-м приказе.