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

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

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

Мы долго к этому шли и вот, 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-м приказе.

И для примера ещё один фрагмент обсуждений

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

РБПО-041. Процесс 6 — Разработка, уточнение и анализ архитектуры программного обеспечения
Цели шестого процесса по ГОСТ Р 56939-2024:

5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.
5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.

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

Также это хороший момент заложить в архитектуру защитные/компенсационные механизмы. Например, если критической частью системы является сохранённая информация в базе данных, то второстепенно, на каком языке разрабатывается проект или требования к интерфейсу. Важнее сразу продумать, как будет осуществляться резервное копирование базы данных (как часто, куда, как делать это наиболее эффективно, как обеспечить безопасность хранения копий и т.д.). Вопросы резервного копирования следует продумывать ещё до начала разработки.

5.6.3.1 Требования к принципам проектирования архитектуры ПО должны содержать информацию, позволяющую на начальном этапе проектирования ПО получить представление о принятых подходах и принципах проектирования архитектуры ПО (например, инкапсуляция, уникальность, разделение задач, применение заимствованных компонентов и т. п.), в том числе с точки зрения безопасности («нулевое доверие», «протоколирование событий», «резервное копирование», «формирование перечня недопустимых событий», «приоритетное использование языков с безопасной моделью памяти» и т. п.).

Чтобы не забыть про какой-то важный элемент построения безопасной архитектуры, есть смысл предварительно обратиться к другим документам:

1. Проектируя ГИС, следует сразу ознакомиться с приказом ФСТЭК 117. Он вступит в силу 1 марта 2026 года, но прочитать его стоит уже сейчас.

2. Создавая ПО для встраиваемых систем, стоит сразу заглянуть в ГОСТ Р 51904-2002. Программное обеспечение встроенных систем. Общие требования к разработке и документированию.

3. Не забыть про какую-то из угроз поможет ГОСТ Р 58412-2019. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.

4. Описать архитектуру и другие сущности поможет ГОСТ Р 58609-2019. Состав и содержание информационных элементов жизненного цикла (документации). См. раздел 10.74 — Описание архитектуры программного продукта.

5. И так далее в зависимости от типа проекта.

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

5.7.1.1 Создание условий для снижения количества недостатков, связанных с особенностями реализации архитектуры ПО и логики его функционирования, выработка мер по нейтрализации угроз безопасности, связанных с особенностями реализации архитектуры ПО.

5.7.1.2 Уточнение модели угроз и описания поверхности атаки по результатам разработки кода и его изменений.

При построении этого процесса важным руководствующим документом является уже упомянутый в предыдущем посте ГОСТ Р 58412-2019: Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.

Собственно, ГОСТ Р 56939-2024 прямо на него ссылается в примечании к п.5.7.3.1:

При составлении перечня угроз безопасности и их описания рекомендуется учитывать положения ГОСТ Р 58412, а также угрозы безопасности информации Банка данных угроз безопасности информации ФСТЭК России, других источников (например, методологии STRIDE, Open Web Application Security Project (OWASP), DREAD и пр.). В модели угроз рекомендуется указывать использованную при моделировании методологию, в том числе в случае ее собственной разработки.

Зачем определять поверхности атаки? Давайте просто всё защищать, проверять и тестировать... В том-то дело, что так не получится, так как ресурсы и время ограничены. Современные программные системы содержат огромные объёмы собственного и стороннего кода. Просто невозможно и избыточно педантично изучать и проверить весь код. Необходимо выделить функции/модули, которые взаимодействуют с внешним миром и, скорее всего, будут подвергаться атаке. На них и следует сосредоточиться в первую очередь с точки зрения противостояния угрозам и более тщательного анализа/проверки/тестирования.

Ссылки по теме:
1. Павел Довгалюк. Зачем искать поверхность атаки для своего проекта.
2. SafeCode 2024. Павел Довгалюк – Анализ поверхности атаки приложений и программных систем.
3. Сигалов Даниил. Диссертация. Методы выявления поверхности атаки веб-приложений при помощи анализа клиентского JavaScript-кода.
4. OWASP. What is Attack Surface Analysis and Why is it Important.

РБПО-043. Процесс 7 — Моделирование угроз и разработка описания поверхности атаки (часть 2/3)
Каковы основные способы определения поверхности атаки?

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

Статический анализ кода. Его перечисляют как один из методов поиска поверхности атаки, но это не совсем верно. Инструменты статического анализа занимаются собственно поиском проблем на поверхности атаки. Это требует развёрнутого пояснения, которое я вынесу в следующий пост.

Инструменты поиска точек входа:
1. Attack Surface Analyzer;
2. Nikto web server scanner.

Динамический анализ кода. Основным представителем является инструмент Natch, разработанный в ИСП РАН:
1. Павел Довгалюк. Как найти поверхность атаки незнакомых приложений с помощью Natch.
2. Павел Довгалюк. Разглядываем CodeScoring с помощью Natch.
3. SafeCode. Иван Васильев – Пример практического использования Natch для анализа.

В начале не понял, а потом как понял! :)))

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

Это четвёртый процесс в ГОСТ Р 56939-2024. Пара примечаний к тому, что обсуждалось на встрече.

Мой коллега Глеб немного рассказал, как у нас происходит подготовка окружения и выпуск новых релизов, но как-то выпало, собственно, как мы их именуем и управляем разными версиями. Причина в том, что именно этот момент у нас устроен очень просто. У нас один продукт — PVS-Studio — в одном варианте исполнения. Мы просто выпускаем новую версию каждые два месяца, меняя её номер :)

У нас одна сборка для всех вариантов использования: Team, Enterprise, триальная версия, бесплатная версия для открытых проектов. Отличается только вводимый лицензионный ключ. Мы храним и выдаём по необходимости предыдущие версии дистрибутива или бета-версию с исправленной ошибкой. Но это всё непрерывная череда версий одной линии программного кода.

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

Более интересно устроен наш процесс работы с документацией. У нас свой путь, варианта которого не было в презентации. У нас есть приложение для преобразования специально оформленных Microsoft Word (docx) файлов в документацию для сайта и включения в дистрибутив.

Как ни крути, с документами Word работать проще всего: почти не требуется обучение (только прочитать правила оформления), их легко оформлять, легко редактировать и видеть изменения, вносимые коллегами (режим правки). В общем, такой способ в своё время был выбран из-за удобства написания статей/документации и за многие годы хорошо себя показал. Всё автоматизировано. Достаточно заложить в главную ветку новые/исправленные docx файлы и, пройдя различные проверки и конвертацию, они автоматически появятся на сайте.

Причём в этот инструмент встроен тоже своего рода статический анализатор для документов :) Он проверяет формат вставленных картинок, правильное написание особых слов/терминов (например, что написано PVS-Studio, а не Pvs-Studio), длину строк кода в примерах, наличие русских букв в англоязычных документах и т.д.

P.S. Давно не предлагал скачать и попробовать PVS-Studio. Хороший момент. От меня промокод firefly для получения лицензии на 1 месяц. Скачать и попробовать.