Экскурс в неопределенное поведение C++
В прошлом году я помог Дмитрию Свиридкину подготовить и опубликовать цикл из 12 статей «Путеводитель C++ программиста по неопределённому поведению». Теперь этот расширенный, доработанный и обобщенный материал доступен в виде печатной книги:
Экскурс в неопределенное поведение C++ / Д. О. Свиридкин, А. Н. Карпов, – СПб.: БХВ-Петербург, 2025. – 384 с. – (Профессиональное программирование)
ISBN 978-5-9775-2073-7
Книгу можно найти в offline и online магазинах.
В прошлом году я помог Дмитрию Свиридкину подготовить и опубликовать цикл из 12 статей «Путеводитель C++ программиста по неопределённому поведению». Теперь этот расширенный, доработанный и обобщенный материал доступен в виде печатной книги:
Экскурс в неопределенное поведение C++ / Д. О. Свиридкин, А. Н. Карпов, – СПб.: БХВ-Петербург, 2025. – 384 с. – (Профессиональное программирование)
ISBN 978-5-9775-2073-7
Книга представляет собой обширный справочник типичных, а также очень редко встречающихся ошибок, характерных для программ на C++, Rust и других языках для низкоуровневого и системного программирования, в частности на ассемблере. Все рассмотренные проблемы так или иначе связаны с неопределенным, неуточненным и определяемым реализацией поведением языковых конструкций. Наибольшее внимание уделено неопределенному поведению, возможным признакам его присутствия в программах и методам поиска, диагностики и устранения такого поведения.
Книгу можно найти в offline и online магазинах.
👍12❤4
РБПО-049. Процесс 9 — Экспертиза исходного кода (часть 1/3)
Цели девятого процесса по ГОСТ Р 56939-2024:
Хотя это явно не сказано в стандарте, но, как я понимаю, здесь подразумевают три схожих, но не идентичных направления работ.
Первый вид работ — экспертиза кода, создаваемого в компании штатными разработчиками. Другими словами, это классические обзоры кода (code review), только более упорядоченные, чем обычно это бывает при разработке ПО. Именно к этому относятся артефакты из п 5.9.3., такие как "описание основных проверок (например сценариев, шаблонов, чек-листов) и т.д. К этой теме я вернусь в следующей части.
Про второй и третий вид работ говорит вот этот комментарий:
Второй вид работ — экспертиза стороннего кода, который команда включает в проект. Понятно, что нереально проводить полноценный обзор кода подключаемых библиотек. Здесь скорее идёт речь о таких вещах, как определение для заимствованного кода поверхности атаки (см. процесс 7) с помощью инструментов и привлечения экспертов.
В случае, если стоит выбор среди несколько схожих по функциональности библиотек (компонентов), то экспертиза кода экспертом и с помощью статического анализа поможет выбрать наиболее качественную, а значит более безопасную реализацию. См. также статью "Почему важно проводить статический анализ открытых библиотек, которые вы добавляете в свой проект".
Третий вид работ — дополнительный ручной анализ собственного кода, для которого отсутствует инструменты статического анализа. Т.е. если у вас есть немного кода на языке, для которого нет анализатора, то вы должны вручную проверить всё то, что проверял бы анализатор. В принципе, этот тот же обор кода, но чек-лист в этом случае может содержать больше пунктов. Например, если в других частях проекта анализаторы кода следят за правилами именования переменных, то на обзоре кода вы должны следить за этим сами. Если непокрытого анализатором кода много, то у вас проблема, с которой предстоит что-то сделать.
Что делать, если подключается сторонняя библиотека на языке, для которого у вас нет анализатора? Смотрите, с точки зрения РБПО, если вы включили в проект сторонний код, то теперь это ваш код, за который вы ответственны. Следовательно, вы должны выбрать дополнительный инструмент статического анализа и включить его в свои процессы разработки.
Что делать, если библиотека обязательно нужна большая (ручной обзор невозможен) и при этом она на языке, для которого статического анализатора не существует в природе? Вот тут даже не знаю, что ответить. Понятно, что есть проблема, но как её решить затрудняюсь подсказать. Возможно, надо подумать в сторону каких-то компенсационных мер... Хз. Может, кто-то в комментариях подскажет, что следует делать в таком случае.
Цели девятого процесса по ГОСТ Р 56939-2024:
Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.
Хотя это явно не сказано в стандарте, но, как я понимаю, здесь подразумевают три схожих, но не идентичных направления работ.
Первый вид работ — экспертиза кода, создаваемого в компании штатными разработчиками. Другими словами, это классические обзоры кода (code review), только более упорядоченные, чем обычно это бывает при разработке ПО. Именно к этому относятся артефакты из п 5.9.3., такие как "описание основных проверок (например сценариев, шаблонов, чек-листов) и т.д. К этой теме я вернусь в следующей части.
Про второй и третий вид работ говорит вот этот комментарий:
Требования настоящего подраздела затрагивают анализ исходного кода ПО разработчиком, непосредственно не участвовавшем в разработке анализируемого кода ПО, а также анализ кода ПО, для которого отсутствуют инструменты статического анализа или результаты их работы нуждаются в подтверждении.
Второй вид работ — экспертиза стороннего кода, который команда включает в проект. Понятно, что нереально проводить полноценный обзор кода подключаемых библиотек. Здесь скорее идёт речь о таких вещах, как определение для заимствованного кода поверхности атаки (см. процесс 7) с помощью инструментов и привлечения экспертов.
В случае, если стоит выбор среди несколько схожих по функциональности библиотек (компонентов), то экспертиза кода экспертом и с помощью статического анализа поможет выбрать наиболее качественную, а значит более безопасную реализацию. См. также статью "Почему важно проводить статический анализ открытых библиотек, которые вы добавляете в свой проект".
Третий вид работ — дополнительный ручной анализ собственного кода, для которого отсутствует инструменты статического анализа. Т.е. если у вас есть немного кода на языке, для которого нет анализатора, то вы должны вручную проверить всё то, что проверял бы анализатор. В принципе, этот тот же обор кода, но чек-лист в этом случае может содержать больше пунктов. Например, если в других частях проекта анализаторы кода следят за правилами именования переменных, то на обзоре кода вы должны следить за этим сами. Если непокрытого анализатором кода много, то у вас проблема, с которой предстоит что-то сделать.
Что делать, если подключается сторонняя библиотека на языке, для которого у вас нет анализатора? Смотрите, с точки зрения РБПО, если вы включили в проект сторонний код, то теперь это ваш код, за который вы ответственны. Следовательно, вы должны выбрать дополнительный инструмент статического анализа и включить его в свои процессы разработки.
Что делать, если библиотека обязательно нужна большая (ручной обзор невозможен) и при этом она на языке, для которого статического анализатора не существует в природе? Вот тут даже не знаю, что ответить. Понятно, что есть проблема, но как её решить затрудняюсь подсказать. Возможно, надо подумать в сторону каких-то компенсационных мер... Хз. Может, кто-то в комментариях подскажет, что следует делать в таком случае.
👍1
РБПО-050. Процесс 9 — Экспертиза исходного кода (часть 2/3)
Продолжим читать девятый раздел ГОСТ Р 56939-2024. Требования к реализации:
На языке программистов: разработать порядок и чек-листы проведения обзоров кода (code review). Скорее всего, практика обзоров кода так или иначе уже существует в вашей компании, а с внедрением РБПО просто пришло время её формализовать, сделать более чёткой/строгой и обязательной.
Очевидный, но от этого не менее важный пункт, что надо процесс не только разработать, но и внедрить его регулярное выполнение. Надеюсь, с этим сложностей быть не должно, поскольку code review — одна из старейших базовых практик написания качественного кода.
Дениел Фридмен и Джеральд Вайнеберг (Daniel Freedman and Gerald Weinberg)
Речь про системы автоматизирования обзоров кода (здесь не путать со статическим анализом), в том числе позволяющие делать это удалённо.
Примером такой системы является RBCommons. Мы пробовали её в далёком 2016 году, но она не прижилась. Сейчас единого подхода нет, действуем из соображений удобства. Кто-то собирается просто в офисе возле компьютера. Кто-то созванивается в Zoom с демонстрацией экрана. Кто-то в GitHub смотрит PR коллег. В общем, мы ценим процесс обзор кода, но пока не чувствуем потребности в жёсткой автоматизации. Возможно, коллектив ещё небольшой, квалифицированный, и у нас просто нет проблемы, что кто-то игнорирует процессы обзора кода.
Продолжим читать девятый раздел ГОСТ Р 56939-2024. Требования к реализации:
5.9.2.1 Разработать регламент проведения экспертизы исходного кода ПО.
На языке программистов: разработать порядок и чек-листы проведения обзоров кода (code review). Скорее всего, практика обзоров кода так или иначе уже существует в вашей компании, а с внедрением РБПО просто пришло время её формализовать, сделать более чёткой/строгой и обязательной.
5.9.2.2 Проводить экспертизу определенных областей кода ПО (в первую очередь для модулей (компонентов) ПО, составляющих поверхность атаки) в соответствии с регламентом проведения экспертизы исходного кода ПО.
Очевидный, но от этого не менее важный пункт, что надо процесс не только разработать, но и внедрить его регулярное выполнение. Надеюсь, с этим сложностей быть не должно, поскольку code review — одна из старейших базовых практик написания качественного кода.
Неформальные процедуры обзоров передавались от человека человеку в общей культуре программирования задолго до того, как информация об этом стала появляться в печатных материалах. Необходимость обзоров была настолько очевидна лучшим программистам, что они редко упоминали об этом в статьях и книгах, тогда как худшие программисты считали, что они настолько хороши, что их работа не нуждается в обзорах.
Дениел Фридмен и Джеральд Вайнеберг (Daniel Freedman and Gerald Weinberg)
5.9.2.3 Проводить экспертизу кода рекомендуется с использованием программных средств, автоматизирующих проведение экспертизы и интегрированных с системой контроля версий разрабатываемого ПО.
Речь про системы автоматизирования обзоров кода (здесь не путать со статическим анализом), в том числе позволяющие делать это удалённо.
Примером такой системы является RBCommons. Мы пробовали её в далёком 2016 году, но она не прижилась. Сейчас единого подхода нет, действуем из соображений удобства. Кто-то собирается просто в офисе возле компьютера. Кто-то созванивается в Zoom с демонстрацией экрана. Кто-то в GitHub смотрит PR коллег. В общем, мы ценим процесс обзор кода, но пока не чувствуем потребности в жёсткой автоматизации. Возможно, коллектив ещё небольшой, квалифицированный, и у нас просто нет проблемы, что кто-то игнорирует процессы обзора кода.
РБПО-051. Процесс 9 — Экспертиза исходного кода (часть 3/3)
Теперь перейдём к артефактам реализации требований девятого процесса ГОСТ Р 56939-2024:
Думаю, суть описана достаточно и понятно. Конкретика уже зависит от ваших нужд, предпочтений, возможностей, типа проекта и т.д. Если хочется от чего-то оттолкнуться, то уже в который раз рекомендую книгу Стива Макконнелла "Совершенный код" ("Code Complete", Steve McConnell). В ней очень много и хорошо написано про обзоры кода.
Проводя обзор кода, важно не забывать про такие высокоуровневые задачи, как:
• обучение членов команды, передача опыта и знаний о проекте новым сотрудникам;
• поиск высокоуровневых ошибок, недостатков выбранных архитектурных решений, неэффективных/опасных подходов в реализации.
Это я вот к чему. Есть риск увлечься на обзорах вопросами оформления кода и поиском опечаток. Это, конечно, тоже полезно и является частью процесса обзоров. Однако часть опечаток помогут найти статические анализаторы кода. Тем более что некоторые опечатки человеку сложно заметить. Вопросы оформления помогают решить правила кодирования (см. предыдущий восьмой процесс) и утилиты автоформатирования. А вот обучение, передача опыта, обсуждение алгоритмов и выявление высокоуровневых недостатков в безопасности и в целом — это всё остаётся только на людях. Полезно не забывать про всё это во время обзора кода.
Здесь, думаю, программистам всё тоже понятно. Остановлюсь только на пункте "вопросы к частям кода, экспертиза которых затруднена и требует дополнительных разъяснений".
Считается, что на обзорах кода тот, кто написал код, не может давать разъяснения, как он работает. Если код непонятен коллегам, значит его надо переписать или снабдить комментариями. Код должен стать самодостаточным для понимания.
Полностью поддерживаю эту идею. На практике, конечно, это тяжело воплотить. Слишком жёсткий подход будет затягивать цикл обзоров фрагмента кода и делать этот процесс в целом очень медленным и трудозатратным. А иногда надо просто что-то быстро сделать, а не заниматься созданием некого идеального кода :) Так что везде нужен баланс. Однако идея хорошая, и по возможности стоит приближаться к её воплощению в реальности :)
P.S. Про написание комментариев. Комментарии должны отвечать не на вопрос "что делаем?", а на вопрос "зачем/почему делаем?". Подробнее — в главе N53 "60 антипаттернов для С++ программиста".
Теперь перейдём к артефактам реализации требований девятого процесса ГОСТ Р 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 здесь.
Статья является переработкой совместного вебинара компаний ООО "ПВС" и Axiom JDK (АО Аксиом). Текстовый вариант содержит дополнительные ссылки, а некоторые моменты рассмотрены более подробно. Полную запись вебинара доступна здесь: "Безопасность приложений: инструменты и практики для Java-разработчиков". Подробнее про плагин PVS-Studio для OpenIDE здесь.
Хабр
Безопасность приложений: инструменты и практики для Java-разработчиков
Тема безопасной разработки программного обеспечения интересует всё большее количество разработчиков и руководителей. Дополнительным стимулом стал вышедший в конце 2024 года обновлённый ГОСТ Р 56939, в...
🔥7
Запись вебинара N7. Моделирование угроз и разработка описания поверхности атаки
Приглашённый эксперт — Екатерина Рудина, аналитик Департамента перспективных технологий «Лаборатории Касперского».
Приглашённый эксперт — Екатерина Рудина, аналитик Департамента перспективных технологий «Лаборатории Касперского».
PVS-Studio
Вебинар 7. Моделирование угроз и разработка описания поверхности атаки
В рамках седьмого вебинара цикла участники обсудили тему «Моделирование угроз и разработка описания поверхности атаки» вместе с приглашённым экспертом — Екатериной Рудиной, аналитиком Департамента перспективных технологий«Лаборатории Касперского».
❤1❤🔥1⚡1👍1
Вышел новый релиз PVS-Studio — 7.38. Новое ядро для C и C++ анализатора, механизм пользовательских аннотаций в Java анализаторе, улучшение анализа заражённых данных. Больше подробностей в этом пресс-релизе.
PVS-Studio
PVS-Studio 7.38: новое ядро C++ анализатора, пользовательские аннотации в Java, улучшение taint-анализа и многое другое
Вышел новый релиз PVS-Studio — 7.38. Новое ядро для C и C++ анализатора, механизм пользовательских аннотаций в Java анализаторе, улучшение анализа заражённых данных, и это ещё не всё! Больше...
styleguides.pdf
620.3 KB
Пример стандарта кодирования для кода на языке C++
Приложение к посту РБПО-045 и предстоящему вебинару про 8-й процесс "Формирование и поддержание в актуальном состоянии правил кодирования" (подписаться на цикл вебинаров).
Для примера, как может выглядеть стандарт кодирования в компании, решил выложить наш собственный документ из базы знаний. Документ приводится как есть, за мелкими исключениями. Заменил на (DEL): имена, некоторые названия, внутренние ссылки и аналогичные элементы.
Это стандарт кодирования для C++ кода. C# стандарт у нас весьма похож на этот, поэтому публиковать его смысла не вижу. Java команда придерживается Google Java Style Guide с небольшими модификациями.
Приложение к посту РБПО-045 и предстоящему вебинару про 8-й процесс "Формирование и поддержание в актуальном состоянии правил кодирования" (подписаться на цикл вебинаров).
Для примера, как может выглядеть стандарт кодирования в компании, решил выложить наш собственный документ из базы знаний. Документ приводится как есть, за мелкими исключениями. Заменил на (DEL): имена, некоторые названия, внутренние ссылки и аналогичные элементы.
Это стандарт кодирования для C++ кода. C# стандарт у нас весьма похож на этот, поэтому публиковать его смысла не вижу. Java команда придерживается Google Java Style Guide с небольшими модификациями.
⚡1
Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам
Случайно наткнулся на собственную статью 2017 года и захотелось её сюда разместить. Текст остаётся актуальным спустя почти 10 лет :)
Случайно наткнулся на собственную статью 2017 года и захотелось её сюда разместить. Текст остаётся актуальным спустя почти 10 лет :)
🔥8
Увесистый вебинар почти на 3 часа, но материал стоит того, чтобы посмотреть его целиком.
Сертификация ПО согласно требованиям ФСТЭК и Минобороны
Докладчик: Виталий Вареница — ведущий специалист ЗАО «НПО «Эшелон» по сертификации и тестированию на проникновение ПО. Заместитель генерального директора. Руководитель испытательной лаборатории.
P.S. Весь цикл вебинаров про РБПО.
Сертификация ПО согласно требованиям ФСТЭК и Минобороны
Докладчик: Виталий Вареница — ведущий специалист ЗАО «НПО «Эшелон» по сертификации и тестированию на проникновение ПО. Заместитель генерального директора. Руководитель испытательной лаборатории.
P.S. Весь цикл вебинаров про РБПО.
🔥11👍2👏1
РБПО-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 вебинаров :)
- Общее описание и актуальность
- Терминология
- Критические ошибки
- Технологии анализа кода
- Процессы
Это ещё не все ссылки, но для первого поста достаточно. Если сразу будет слишком много ссылок, то вообще никто ничего открывать не будет :)
Цели десятого процесса по ГОСТ Р 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 вебинаров :)
- Общее описание и актуальность
- Терминология
- Критические ошибки
- Технологии анализа кода
- Процессы
Это ещё не все ссылки, но для первого поста достаточно. Если сразу будет слишком много ссылок, то вообще никто ничего открывать не будет :)
🔥3
Опубликована запись подкаста: sysadmins №60. Прохождение сертификации ФСТЭК
P.S. В начале подкаста я немного запутался. Я говорил, мол до этого говорили про статический анализ, а теперь про сертификацию. На самом деле в прошлый тема была более общая: №58. РБПО. А именно статический анализ был в другом подкасте - Ever Secure | Статический анализ по-серьезному.
Наступил тот самый момент, когда нашим дорогим подписчикам можно узнать детали ещё одной тайны мироздания – как получить сертификат ФСТЭК на свою разработку.
Вместе с Никитой Молчаном из лаборатории Атомзащитаинформ, Даниилом Скалацким из Angie Software и Андреем Карповым из PVS-Studio выясняли, в чём разница между лицензированием, аттестацией и сертификацией, зачем, кому и для чего оно надо, как проводится экспертиза и, самое главное, что ждёт рискнувшего и как заполучить вожделенный сертификат.
P.S. В начале подкаста я немного запутался. Я говорил, мол до этого говорили про статический анализ, а теперь про сертификацию. На самом деле в прошлый тема была более общая: №58. РБПО. А именно статический анализ был в другом подкасте - Ever Secure | Статический анализ по-серьезному.
🔥6
РБПО-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: как инструменты анализа кода ищут дефекты безопасности
Вторая порция ссылок по теме статического анализа и 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
Вход свободный. Напитки и еда за свой счет.
Регистрация не требуется 👍
Буду выступать с докладом "Статический анализ кода по ГОСТ Р 71207-2024: что и как год спустя".
В апреле 2024 года впервые вступил в действие ГОСТ Р 71207 — Статический анализ программного обеспечения. Доклад, во-первых, кратко познакомит с сутью этого стандарта, понятием критических ошибок и требованиями, которые предъявляются к процессам и инструментам. Во-вторых, рассмотрим, что этот стандарт означает для индустрии статических анализаторов в целом и для инструмента PVS-Studio в частности. Затронем инициативу ФСТЭК по испытаниям статических анализаторов в 2025 году.
🗓11 сентября в 19:00
Обратите внимание, что сейчас "Failover Bar" расположен по другому адресу:
📍Санкт-Петербург, ул. 2 Советская, 18
Вход свободный. Напитки и еда за свой счет.
Регистрация не требуется 👍
👍5
РБПО-054. Процесс 10 — Статический анализ исходного код (часть 3/4)
Вернёмся к ГОСТ Р 56939-2024. По порядку пройдёмся по артефактам.
Здесь сразу предлагаю открыть ГОСТ Р 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 и т.д. Хотя бы потому, что они не участвуют в испытаниях и вряд ли их будут дотачивать под требования этих стандартов.
Вернёмся к ГОСТ Р 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 и т.д. Хотя бы потому, что они не участвуют в испытаниях и вряд ли их будут дотачивать под требования этих стандартов.
РБПО-055. Процесс 10 — Статический анализ исходного код (часть 4/4)
Продолжаем рассматривать артефакты десятого процесса ГОСТ Р 56939-2024.
Про настройку анализаторов — см. п.5.4 в ГОСТ Р 71207–2024. Что такое критические ошибки, я уже разбирал, но на всякий случай ещё раз дам отсылки.
- В ГОСТ Р 71207-2024 смотри раздел 6.
- Страница терминология PVS-Studio: критические ошибки (потенциальные уязвимости).
- Фильтрация предупреждений PVS-Studio, выявляющих критические ошибки (согласно классификации ГОСТ Р 71207-2024)
- Вебинар — Критические ошибки
На тему разметки можно за основу взять "Инструкцию по проведению разметки результатов статического анализа ядра Linux", составленную "Центром исследований безопасности системного программного обеспечения".
P.S.
Предлагаю скачать и попробовать статический анализатор кода PVS-Studio. От меня промокод firefly для получения лицензии на месяц. Бесплатные лицензии для студентов и преподавателей.
PVS-Studio включён в Реестр российского ПО: запись № 9837. Совместим с ГОСТ Р 71207-2024 (Статический анализ кода). Соответствие требованиям "Методики выявления уязвимостей и недекларированных возможностей в программном обеспечении" от 25 декабря 2020 г. Может применяться для РБПО согласно ГОСТ Р 56939-2024. Участвует в инициативе ФСТЭК по испытанию статических анализаторов.
Продолжаем рассматривать артефакты десятого процесса ГОСТ Р 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. Участвует в инициативе ФСТЭК по испытанию статических анализаторов.
👍4
Выложена запись вебинара "Техническая сторона первого этапа испытаний статических анализаторов кода под эгидой ФСТЭК". Скачать файлы презентаций.
Завершился этап «Домашнее задание» в рамках испытаний статических анализаторов ФСТЭК России. Эксперты подготовили набор синтетических тестов для проверки выявления критических ошибок по ГОСТ Р 71207-2024. Однако на практике возникло много технических вопросов. На вебинаре эксперты PVS-Studio, Positive Technologies и АО «НПО «Эшелон» обсудили эти нюансы и поделились полученным опытом.
👍3
РБПО-056. Процесс 11 — Динамический анализ кода программы
Цели 10-го процесса ГОСТ Р 56939-2024:
В том числе этот процесс подразумевает и фаззинг-тестирование (п.5.11.2.2):
Определение этих терминов в ГОСТ Р 56939-2024:
Также термин динамический анализ кода программы мы уже рассматривали ранее: РБПО-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-тестирование. Рассказ простым языком.
Цели 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-тестирование. Рассказ простым языком.
🔥2🙏1
РБПО-057. Процесс 12 — Использование безопасной системы сборки программного обеспечения
Цели 12-го процесса ГОСТ Р 56939-2024:
Я не очень понимаю наполнение этого процесса и его глубину. Думаю, мы исправим это, пригласив кого-то из экспертов на соответствующий 11-й вебинар цикла "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024".
Моё поверхностное представление: разработать регламент использования ключей оптимизации. Чтобы в последний момент кто-то не решил: "А давайте при сборке релиза впишем -o3 вместо -o2" (имеются в виду настройки оптимизации). Такие непродуманные и непроверенные действия могут приводить к неожиданным сбоям в работе приложений.
В стандарте ГОСТ Р 56939-2024 ничего не сказано про использование безопасных компиляторов или ГОСТ Р 71206-2024: "Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования". Однако, мне кажется, он присутствует меж строк :)
Область применения ГОСТ Р 71206-2024 (раздел 1):
На данный момент существуют следующие компиляторы, выполняющие требования к функциям безопасности из ГОСТ Р 71206-2024:
• SAFEC (на основе GCC);
• Safelang (на основе Clang).
Впрочем, безопасные системы сборки это не только С/С++ и ГОСТ Р 71206. Есть разработки, например, и в мире Java. Из статьи "Безопасность приложений: инструменты и практики для Java-разработчиков" (как Axiom JDK поддерживает безопасную разработку):
Дополнительные ссылки:
1. Рекомендации по обеспечению безопасности системы сборки.
2. Как обеспечить безопасность сборки ПО: управляем внешними зависимостями.
Цели 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. Как обеспечить безопасность сборки ПО: управляем внешними зависимостями.