РБПО-051. Процесс 9 — Экспертиза исходного кода (часть 3/3)

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

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

Думаю, суть описана достаточно и понятно. Конкретика уже зависит от ваших нужд, предпочтений, возможностей, типа проекта и т.д. Если хочется от чего-то оттолкнуться, то уже в который раз рекомендую книгу Стива Макконнелла "Совершенный код" ("Code Complete", Steve McConnell). В ней очень много и хорошо написано про обзоры кода.

Проводя обзор кода, важно не забывать про такие высокоуровневые задачи, как:

• обучение членов команды, передача опыта и знаний о проекте новым сотрудникам;
• поиск высокоуровневых ошибок, недостатков выбранных архитектурных решений, неэффективных/опасных подходов в реализации.

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

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

Здесь, думаю, программистам всё тоже понятно. Остановлюсь только на пункте "вопросы к частям кода, экспертиза которых затруднена и требует дополнительных разъяснений".

Считается, что на обзорах кода тот, кто написал код, не может давать разъяснения, как он работает. Если код непонятен коллегам, значит его надо переписать или снабдить комментариями. Код должен стать самодостаточным для понимания.

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

P.S. Про написание комментариев. Комментарии должны отвечать не на вопрос "что делаем?", а на вопрос "зачем/почему делаем?". Подробнее — в главе N53 "60 антипаттернов для С++ программиста".

Безопасность приложений: инструменты и практики для Java-разработчиков

Статья является переработкой совместного вебинара компаний ООО "ПВС" и Axiom JDK (АО Аксиом). Текстовый вариант содержит дополнительные ссылки, а некоторые моменты рассмотрены более подробно. Полную запись вебинара доступна здесь: "Безопасность приложений: инструменты и практики для Java-разработчиков". Подробнее про плагин PVS-Studio для OpenIDE здесь.

Запись вебинара N7. Моделирование угроз и разработка описания поверхности атаки
Приглашённый эксперт — Екатерина Рудина, аналитик Департамента перспективных технологий «Лаборатории Касперского».

Вышел новый релиз PVS-Studio — 7.38. Новое ядро для C и C++ анализатора, механизм пользовательских аннотаций в Java анализаторе, улучшение анализа заражённых данных. Больше подробностей в этом пресс-релизе.

Пример стандарта кодирования для кода на языке C++

Приложение к посту РБПО-045 и предстоящему вебинару про 8-й процесс "Формирование и поддержание в актуальном состоянии правил кодирования" (подписаться на цикл вебинаров).

Для примера, как может выглядеть стандарт кодирования в компании, решил выложить наш собственный документ из базы знаний. Документ приводится как есть, за мелкими исключениями. Заменил на (DEL): имена, некоторые названия, внутренние ссылки и аналогичные элементы.

Это стандарт кодирования для C++ кода. C# стандарт у нас весьма похож на этот, поэтому публиковать его смысла не вижу. Java команда придерживается Google Java Style Guide с небольшими модификациями.

Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам
Случайно наткнулся на собственную статью 2017 года и захотелось её сюда разместить. Текст остаётся актуальным спустя почти 10 лет :)

Увесистый вебинар почти на 3 часа, но материал стоит того, чтобы посмотреть его целиком.

Сертификация ПО согласно требованиям ФСТЭК и Минобороны

Докладчик: Виталий Вареница — ведущий специалист ЗАО «НПО «Эшелон» по сертификации и тестированию на проникновение ПО. Заместитель генерального директора. Руководитель испытательной лаборатории.

P.S. Весь цикл вебинаров про РБПО.

РБПО-052. Процесс 10 — Статический анализ исходного код (часть 1/4)

Цели десятого процесса по ГОСТ Р 56939-2024:

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

Я в затруднении :) Это процесс, про который я могу написать очень много. Или, наоборот, мало, сведя всё к списку ссылок на другие материалы, где так или иначе мы разбирали соответствующие темы.

Попробую сделать что-то среднее. Начну с ссылок, а затем всё же бегло пройдусь по пунктам десятого процесса.

Начнём с темы статического анализа в целом:
- РБПО-020. Термин: статический анализ исходного кода программы.
- Терминология. Статический анализ кода.
- Почему обзоры кода — это хорошо, но недостаточно.
- Как внедрить статический анализатор кода в legacy проект и не демотивировать команду.

Рассмотрение 10-го процесса в ГОСТ Р 56939-2024 неразрывно связано с другим ГОСТ Р 71207-2024 — Статический анализ программного обеспечения. В нём говорится про то же самое, только более подробнее и конкретней.

В общем-то, можно сразу идти изучать ГОСТ Р 71207-2024 и внедрять описанные в нём рекомендации и процессы. А затем уже вернуться к артефактам ГОСТ Р 56939-2024 (п. 5.10.3).

Про ГОСТ Р 71207-2024 мы много писали и рассказывали. Поэтому как раз предлагаю начать с изучения этих материалов:
- Обзорный доклад: Использование статического анализатора в разработке безопасного программного обеспечения (ГОСТ Р 71207-2024) на примере PVS-Studio
- Поподробнее про C++: Cтатический анализ C++ кода по ГОСТ Р 71207-2024 на примере PVS-Studio

Если мало, то вот цикл из 5 вебинаров :)
- Общее описание и актуальность
- Терминология
- Критические ошибки
- Технологии анализа кода
- Процессы

Это ещё не все ссылки, но для первого поста достаточно. Если сразу будет слишком много ссылок, то вообще никто ничего открывать не будет :)

Опубликована запись подкаста: sysadmins №60. Прохождение сертификации ФСТЭК

Наступил тот самый момент, когда нашим дорогим подписчикам можно узнать детали ещё одной тайны мироздания – как получить сертификат ФСТЭК на свою разработку.

Вместе с Никитой Молчаном из лаборатории Атомзащитаинформ, Даниилом Скалацким из Angie Software и Андреем Карповым из PVS-Studio выясняли, в чём разница между лицензированием, аттестацией и сертификацией, зачем, кому и для чего оно надо, как проводится экспертиза и, самое главное, что ждёт рискнувшего и как заполучить вожделенный сертификат.

P.S. В начале подкаста я немного запутался. Я говорил, мол до этого говорили про статический анализ, а теперь про сертификацию. На самом деле в прошлый тема была более общая: №58. РБПО. А именно статический анализ был в другом подкасте - Ever Secure | Статический анализ по-серьезному.

РБПО-053. Процесс 10 — Статический анализ исходного код (часть 2/4)

Вторая порция ссылок по теме статического анализа и PVS-Studio:
1. Страница на сайте PVS-Studio, посвященная совместимости с ГОСТ Р 71207-2024
2. Модельные варианты ошибок в статических анализаторах
3. SAST как Quality Gate
4. PVS-Studio в CI/CD. Автоматизация регулярного статического анализа на примере интеграции с Jenkins
5. Подкаст. Статический анализ кода / Виды анализа и диагностики / Поиск кадров в регионах
6. Unreal Engine 5. Lyra Game code review. Часть 3. Статический анализ кода с PVS-Studio
7. Рецепты для регулярного статического анализа кода
8. Статический анализ Pull Request'ов — ещё один шаг к регулярности
9. Безболезненное внедрение статического анализа и победа над ложными срабатываниями
10. Что нельзя найти с помощью статического анализа
11. Под капотом SAST: как инструменты анализа кода ищут дефекты безопасности

Не знаете, как приятно и полезно провести вечер 11 сентября в Питере? Все просто — прийти в "Failover Bar" и послушать доклад!

Буду выступать с докладом "Статический анализ кода по ГОСТ Р 71207-2024: что и как год спустя".

В апреле 2024 года впервые вступил в действие ГОСТ Р 71207 — Статический анализ программного обеспечения. Доклад, во-первых, кратко познакомит с сутью этого стандарта, понятием критических ошибок и требованиями, которые предъявляются к процессам и инструментам. Во-вторых, рассмотрим, что этот стандарт означает для индустрии статических анализаторов в целом и для инструмента PVS-Studio в частности. Затронем инициативу ФСТЭК по испытаниям статических анализаторов в 2025 году.

🗓11 сентября в 19:00

Обратите внимание, что сейчас "Failover Bar" расположен по другому адресу:
📍Санкт-Петербург, ул. 2 Советская, 18

Вход свободный. Напитки и еда за свой счет.
Регистрация не требуется 👍

РБПО-054. Процесс 10 — Статический анализ исходного код (часть 3/4)

Вернёмся к ГОСТ Р 56939-2024. По порядку пройдёмся по артефактам.

5.10.3.1 Регламент проведения статического анализа исходного кода ПО должен содержать следующие сведения:

Здесь сразу предлагаю открыть ГОСТ Р 71207-2024 и заимствовать для составления регламента из пятого раздела "Требования к внедрению и порядку выполнения статического анализа".

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

На тему критических ошибок предлагаю заглянуть в 6 раздел ГОСТ Р 71207-2024 "Классификация критических ошибок, находимых статическими анализаторами".

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

Про периодичность — см. опять 5 раздел ГОСТ Р 71207-2024.

- критерии пересмотра конфигурации и параметров настройки инструментов статического анализа.

П.5.10.3.2:

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

Думаю, тут всё понятно. Давайте лучше вернёмся к пункту "критерии выбора инструментов статического анализа".

Выбор — интересный вопрос. Статических анализаторов много: List of tools for static code analysis, AppSec Каталог - SAST.

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

В данный момент нет явных ограничений на используемые инструменты. Однако к выбору надо подходит вдумчиво. Подробнее эта тема раскрыта в "Методической рекомендации № 2025-07-011".

В том числе там говорится про испытания статических анализаторов кода. Публикации на эту тему:

- ФСТЭК России объявила о начале масштабных испытаний статических анализаторов
- Испытания статических анализаторов (BIS Journal — "Информационная безопасность бизнеса", № 2(57) 2025, стр. 72–82)
- Итоги этапа «Домашнее задание» испытаний статических анализаторов под патронажем ФСТЭК России
- Мой комментарий касательно PVS-Studio в Telegram-канале

В общем, с точки зрения ГОСТ Р 56939-2024 и ГОСТ Р 71207-2024 сейчас лучше выбирать анализаторы, участвующие в испытаниях. Например, PVS-Studio :) Конечно, неизвестно, как он покажет себя на испытания. Но у него точно больше потенциала соответствовать, чем у условных Sonar, Coverity и т.д. Хотя бы потому, что они не участвуют в испытаниях и вряд ли их будут дотачивать под требования этих стандартов.

Роман Карпов, Директор по стратегии и развитию технологий Axiom JDK.
Зачем Java-разработчику знать регуляторику. Часть 1, Часть 2.

РБПО-055. Процесс 10 — Статический анализ исходного код (часть 4/4)

Продолжаем рассматривать артефакты десятого процесса ГОСТ Р 56939-2024.

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

Про настройку анализаторов — см. п.5.4 в ГОСТ Р 71207–2024. Что такое критические ошибки, я уже разбирал, но на всякий случай ещё раз дам отсылки.

- В ГОСТ Р 71207-2024 смотри раздел 6.
- Страница терминология PVS-Studio: критические ошибки (потенциальные уязвимости).
- Фильтрация предупреждений PVS-Studio, выявляющих критические ошибки (согласно классификации ГОСТ Р 71207-2024)
- Вебинар — Критические ошибки

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

На тему разметки можно за основу взять "Инструкцию по проведению разметки результатов статического анализа ядра Linux", составленную "Центром исследований безопасности системного программного обеспечения".

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

P.S.
Предлагаю скачать и попробовать статический анализатор кода PVS-Studio. От меня промокод firefly для получения лицензии на месяц. Бесплатные лицензии для студентов и преподавателей.

PVS-Studio включён в Реестр российского ПО: запись № 9837. Совместим с ГОСТ Р 71207-2024 (Статический анализ кода). Соответствие требованиям "Методики выявления уязвимостей и недекларированных возможностей в программном обеспечении" от 25 декабря 2020 г. Может применяться для РБПО согласно ГОСТ Р 56939-2024. Участвует в инициативе ФСТЭК по испытанию статических анализаторов.

Выложена запись вебинара "Техническая сторона первого этапа испытаний статических анализаторов кода под эгидой ФСТЭК". Скачать файлы презентаций.

Завершился этап «Домашнее задание» в рамках испытаний статических анализаторов ФСТЭК России. Эксперты подготовили набор синтетических тестов для проверки выявления критических ошибок по ГОСТ Р 71207-2024. Однако на практике возникло много технических вопросов. На вебинаре эксперты PVS-Studio, Positive Technologies и АО «НПО «Эшелон» обсудили эти нюансы и поделились полученным опытом.

РБПО-056. Процесс 11 — Динамический анализ кода программы

Цели 10-го процесса ГОСТ Р 56939-2024:

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

В том числе этот процесс подразумевает и фаззинг-тестирование (п.5.11.2.2):

Определить инструменты динамического анализа и фаззинг-тестирования, порядок их применения.

Определение этих терминов в ГОСТ Р 56939-2024:

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

п.3.22 фаззинг-тестирование программы: Вид работ по исследованию программы, основанный на передаче программе случайных или специально сформированных входных данных, отличных от данных, предусмотренных алгоритмом работы программы.

Также термин динамический анализ кода программы мы уже рассматривали ранее: РБПО-016, 017, 018.

Лекция про фаззинг от ИПС РАН: "Особенности фаззинг-тестирования при проведении сертификационных испытаний", "Подходы к фаззинг-тестированию управляемого кода" и т.д.

Инструментов достаточно много, например:
• Valgrind
• AddressSanitizer
• ThreadSanitizer
• MemorySanitizer
• ИСП Fuzzer

Далее смотрите здесь:
• AppSec Каталог: DAST
• AppSec Каталог: Fuzzing

Но учтите, что очень скоро выйдет ГОСТ "Динамический анализ программного обеспечения". Описанные в нём требования к инструментальным средствам могут сказаться на подходе к их выбору.

Согласно плану ФСТЭК на 2025 год по разработке проектов национальных стандартов, в декабре 2025 года уже начнутся работы по издательскому редактированию и подготовке к утверждению проекта этого стандарта. Однако пока стандарт не опубликован, говорить про него рано.

Тема динамического анализа и фаззинг-тестирования, как я понимаю, весьма обширная, поэтому разные специалисты понимают её по-разному и, соответственно, по-разному подходят к реализации этого процесса. Видимо, поэтому, например, недавно вышла методическая рекомендация № 2025-07-010, уточняющая, что должно включать фаззинг-тестирование:

Тип недостатка: Применение средств фаззинг-тестирования, не реализующих генетические алгоритмы фаззинг-тестирования (в том числе за счет инструментирования тестируемого кода).

Дополнительные ссылки:

1. Осипов Станислав. Особенности подачи входных данных при фаззинге в режиме Persistent Mode на примере Libfuzzer + CURL.
2. Чат сообщества ФСТЭК России и ИСП РАН в области разработки безопасного и качественного ПО. Динамика::Доверенная разработка.
3. Positive Hack Days. Фаззинг как основа эффективной разработки на примере LuaJIT.
4. Центр исследований безопасности системного программного обеспечения. Методика фаззинг-тестирования ядра.
5. Никита Догаев. Fuzzing-тестирование. Практическое применение.
6. Николай Шаплов. Как работает fuzzing-тестирование. Рассказ простым языком.

РБПО-057. Процесс 12 — Использование безопасной системы сборки программного обеспечения

Цели 12-го процесса ГОСТ Р 56939-2024:

Обеспечение безопасности при сборке ПО, недопущение привнесения в код ошибок, об условленных небезопасными преобразованиями кода.

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

Моё поверхностное представление: разработать регламент использования ключей оптимизации. Чтобы в последний момент кто-то не решил: "А давайте при сборке релиза впишем -o3 вместо -o2" (имеются в виду настройки оптимизации). Такие непродуманные и непроверенные действия могут приводить к неожиданным сбоям в работе приложений.

В стандарте ГОСТ Р 56939-2024 ничего не сказано про использование безопасных компиляторов или ГОСТ Р 71206-2024: "Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования". Однако, мне кажется, он присутствует меж строк :)

Область применения ГОСТ Р 71206-2024 (раздел 1):

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

Настоящий стандарт предназначен для разработчиков компиляторов, а также для разработки безопасного программного обеспечения при выборе и оценке средств компиляции.

На данный момент существуют следующие компиляторы, выполняющие требования к функциям безопасности из ГОСТ Р 71206-2024:
• SAFEC (на основе GCC);
• Safelang (на основе Clang).

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

Впрочем, безопасные системы сборки это не только С/С++ и ГОСТ Р 71206. Есть разработки, например, и в мире Java. Из статьи "Безопасность приложений: инструменты и практики для Java-разработчиков" (как Axiom JDK поддерживает безопасную разработку):

5.12. — Использование безопасной системы сборки программного обеспечения.
Мы используем свой проверенный компилятор для сборки JDK. Мы создали свои доверенные Gradle и Maven, которые собрали своим компилятором Java. Эти сборки позволяют гарантировать чистоту сборочного конвейера. Дополнительно они вносят в JAR-файлы библиотек подписи с информацией, что сборка библиотеки произведена компанией Axiom JDK.

Дополнительные ссылки:
1. Рекомендации по обеспечению безопасности системы сборки.
2. Как обеспечить безопасность сборки ПО: управляем внешними зависимостями.

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

В конце я говорил, что иногда сообщения анализатора приводят к упрощению/сокращению кода и есть статья с примером. Вот она: Статический анализатор подталкивает писать чистый код.

Буду выступать на этой конференции с докладом: MISRA — альтернативный взгляд на разработку безопасного ПО.

P.S. Мы сейчас активно продолжаем увеличивать покрытие стандарта MISRA C 2023 в PVS-Studio. Планируем завершить работы в этом направлении до конца 2025 года.