Бестиарий программирования

Запись последнего в этом году (но не в цикле РБПО) вебинара на тему "Реагирование на информацию об уязвимостях". В этот раз помочь разобрать 23-й процесс ГОСТ Р 56939-2024 нам помог Дмитрий Частухин, важный технический директор Hexway.

Ссылки, которые были приведены в ходе вебинара:
1. Vampy. Документация.
2. Раздел документации PVS-Studio об интеграции результатов анализа в Hexway VamPy.
3. Карта российского рынка информационной безопасности 2025.

И ещё некоторые дополнительные ссылки:
1. Терминология. Уязвимость нулевого дня.
2. Станислав Мриль. Всё об управлении уязвимостями в 2025: Vulnerability Management.
3. Positive Technologies: раскрытие уязвимостей и опыт взаимодействия исследователей и вендоров в 2022–2023 годах.
4. Руслан Рахметов. Поиск и предотвращение уязвимостей в ПО: эффективные методики.
5. Порядок подачи уязвимости в базу ФСТЭК России: пошаговая инструкция.

На днях на конференции ко мне подошёл человек, который поблагодарил за цикл вебинаров, посвящённых РБПО. Я спрашиваю: "А напишешь отзыв?" Он: "Напишу!"

Естественно, захотелось поделиться этим приятным отзывом. Артур, спасибо за душевные слова.

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

Когда мне было предложено ввести процессы РБПО в организации, я столкнулся с тем, что фронт работ настолько большой, что в одиночку пройти этот путь вызывало большие опасения. С чего начать? На что обратить внимание? Какие инструменты использовать? Честно говоря, забросить это дело было проще простого. Но мне посоветовали ознакомиться с серией "Вокруг РБПО за 25 вебинаров". И самое главное, почему я благодарен — люди своим примером показывают, что РБПО — это не страшно, что все процессы достижимы и их внедрение всего лишь вопрос времени и усилий, вложенных в нужное русло. В этом деле важно понимать, что есть сообщество, которое приветствует вопросы, и помогает разобраться во всех тонкостях. За это огромное спасибо всем участникам вебинаров!

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

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

Также хотелось бы поблагодарить организаторов за высокий уровень проведения вебинаров. Здесь не только про качество самих выступлений, но и про техническую составляющую — выступления просто приятно смотреть и слушать.

Муратов Артур. Электронные офисные системы. Инженер-разработчик.

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

Тяжела и неказиста жизнь ложных срабатываний анализатора. Встретился вот такой необычный случай при проверке Java проекта LanguageTool:

public String getEnclitic(AnalyzedToken token) {
  ....
  if (word.endsWith("ه")) {
    suffix = "ه";
  ....
  else if ((word.equals("عني") ||
            word.equals("مني")) &&
            word.endsWith("ني")   // <=
  ) {    
    suffix = "ني";
  }
  ....
}

Предупреждение PVS-Studio: V6007 Expression 'word.endsWith("ني")' is always false. ArabicTagger.java 428

Если смотреть на строковые константы так, как привыкли носители английского, французского, немецкого или русского языка – сообщение анализатора действительно кажется справедливым. Однако, здесь стоит помнить о том, что в арабском языке написание и чтение происходит справа-налево. А значит, там, где не носитель арабского языка ожидает конец литерала, на самом деле столкнётся с его началом. И в этой ситуации анализатор оказался не носителем арабского языка.

К слову, если учесть RTL (right-to-left, справа-налево) написание слова, здесь окажется, что условие на самом деле всегда истинно, а не ложно.

А как Java обрабатывает языки с письмом справа налево? Секрет в том, что Java работает не с "визуальным" представлением текста, а с его Unicode-кодировкой. В Unicode символы любых языков — как с направлением слева направо, так и справа налево — хранятся в логическом порядке, то есть в том порядке, в котором они вводятся и читаются носителями языка.

Это означает, что Java не требуется выполнять какие-либо специальные преобразования для работы с RTL-текстом. Строка остаётся обычной последовательностью Unicode-кодовых точек, а такие операции, как получение длины строки, доступ к символам или выделение подстроки, работают одинаково для всех языков.

Поэтому, для вот такой проверки:

System.out.println("مرحباً بالجميع".endsWith("بالجميع"));

Результатом будет true, хотя если читать слева направо, то строка начинается, а не закачивается с "بالجميع".

Случай познавательный и интересный для нас, хотя с ходу пока не понятно, как быть с такими ситуациями. Выписали в todo на обдумывание.

Не забываем про GameDev. Запись очередного вебинара – "Оптимизация игр: работа со строками".

В своей разминочной части я упоминал доклад Антона Полухина – "Как делать не надо: C++ велосипедостроение для профессионалов". Хоть доклад уже бородатого 2017 года, всё равно рекомендую к просмотру.

Бестиарий программирования pinned a photo

Об итогах испытаний статических анализаторов исходного кода при организационной и методической поддержке ФСТЭК России в 2025 году (часть 6 из 6)

Итоги по испытаниям

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

На данный момент беспроблемные запуски нагрузочных тестов продемонстрировали:

Для C/C++: ISP RAS, PVS, Solar.
Для C#: ISP RAS, PT, PVS, Echelon, Solar.
Для Java: ISP RAS, PVS, Echelon.
Для Go: ISP RAS, PT, Echelon, Solar.
Для Python: ISP RAS, Solar.
JavaScript: ISP RAS, PT, Solar.

Синтетические тесты в каком-то виде были проведены только для языков C/C++ и Java. Делать глобальные заключения, основываясь на приведённых данных, нерационально. В целом можно сказать, что все анализаторы в какой-то степени решают задачи, поставленные в тестах. Для уточнения требуются дополнительные исследования и новый раунд испытаний.

Информации по синтетическим тестам для языков C#, Go, Python, JavaScript нет. Для какого-то представления можно только взглянуть на этап домашнего задания. Подробнее касательно PVS-Studio на этапе домашнего задания см. этот пост и вебинар.

Мы для себя по итогу испытаний выписали большой пул задач по доработке PVS-Studio, которыми будем заниматься в 2026. Например, мы начали внедрять альтернативный IR подход для решения задач анализа потока данных в C++ анализатор. Так что в целом испытания пошли нам и, думаю, другим анализаторам на пользу.

Блок Б целиком не вошёл в оценку. Т. е. не выполнен анализ работы детекторов на реальных проектах. Соответственно, все числовые данные, представленные в презентации, сделаны на основе синтетических тестов.

Общие выводы

Если говорить о подходах к выбору анализаторов кода, как я понимаю, пока ничего не изменилось. По-прежнему актуальна методическая рекомендация ФСТЭК № 2025-07-011. Можно выбирать разные удобные вам инструменты, обращая внимание на отмеченные в рекомендации нюансы. Также смотри выдержку из эфира AM Live "Разработка безопасного программного обеспечения (РБПО)".

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

Об итогах испытаний статических анализаторов исходного кода при организационной и методической поддержке ФСТЭК России в 2025 году (часть 5 из 6)

Про Java я затрудняюсь что-то сказать. Были исключены тесты на разыменования нулевой ссылки, выход за границу контейнера и т. д., как не входящие согласно ГОСТ 71207-2024 в список критических ошибок. Жаль, зря только делали. Мы почему-то думали, что раз они были в домашнем задании как расширение, то перейдут и на основной этап.

Жаль, что не добрались до C#. Мне кажется, PVS-Studio мог бы хорошо здесь себя показать.

До оценки синтетических наборов тестов для Go, Python и JavaScript дело тоже не дошло. Но в этом мы и не участвовали (спойлер: пока по крайней мере).

Итоги по доработке ГОСТ Р 71207-2024

Обсуждалась возможность доработки стандарта. Некоторые моменты действительно, на мой взгляд, следует изменить или уточнить. Основное: меня смущает пункт про долю FP срабатываний не более 50% при тестировании открытых проектов (см. 10 раздел стандарта)

Эти числа малоосмысленны вне контекста (типа, качества) исследуемых отрытых проектов (п. 10.2.в) и вне настройки анализаторов. Возьмём проект nginx. Это проект чем только не проверялся :) Странно ожидать, что, запустив на нём анализатор кода, мы получим, скажем, 200 предупреждений, 100 из которых окажутся прям истинными критическими ошибками.

Показатель 50% TP возможен только в случае какого-то особого консервативного режима работы. Это когда анализатор выдаёт на весь проект только два предупреждения, одно из которых будет верным :) Однако это не то, что мы хотим от статического анализа. От него должна быть польза, а не просто выполнение какой-то метрики. Здесь уместно вспомнить пост "Почему фолзят SAST’ы? Часть 1, Часть 2".

Об итогах испытаний статических анализаторов исходного кода при организационной и методической поддержке ФСТЭК России в 2025 году (часть 4 из 6)

Вернёмся к графикам по основной формуле. Оставив за скобками ISP RAS (Svace), результаты PVS, Echelon, Solar, PT выглядят как-то уж совсем скромно в сравнении с набором открытых анализаторов Basealt (clang-static-analyzer, clang-tidy, cppcheck и gcc). Не могут все эти коммерческие инструменты, развиваемые десятилетиями, оказаться настолько хуже.

Почему так получилось? Формула подсчёта. Всё подсчитывалось открыто, но неожиданно в последний момент появились веса для методов анализа. Рискну предположить, что это меняет картину.

Радикальным смотрится и динамическая оценка веса конкретного теста: больше инструментов прошло тест, меньше вес теста. Спорный подход. Получается, что большой вклад вносят экзотические сложные тесты. Но поиск экзотики вовсе не означает, что на практике она столь полезна.

Возможно, именно динамическая оценка оказала значимое влияние на результаты ISP RAS. Команда ИСП РАН писала сложные тесты и, как звучало на докладе, хочется видеть больше именно таких сложных тестов. Получается, это своего рода бонус за создание таких тестов.

На мой взгляд, это рискованная дорога. Если ценятся сложные/экзотические тесты, которые только твой инструмент и может пройти, то все начнут писать только такие тесты. Ведь если тест проходят и другие, у него будет низкий вес. В результате получится набор тестов, в котором каждый в основном будет находить только то, что создала его команда. Ведь можно, основываясь на тонкостях работы анализатора или его сильных сторонах, написать такой тест, с которым другим будет тяжело.

Плюс это уводит в сторону от основной задачи тестов: проверки технологий анализа кода. Вместо технологий начинают проверяться предельные/краевые возможности инструмента.

В общем, на приведённые числа интересно посмотреть, но какие-то выводы из них нужно делать очень аккуратно или вообще не делать.

Об итогах испытаний статических анализаторов исходного кода при организационной и методической поддержке ФСТЭК России в 2025 году (часть 3 из 6)

Для начала шпаргалка для тех, кто путается в TP, TN, FP, FN :)

TP – True Positive – сколько ошибок выявлено.
TN – True Negative – сколько обманок обнаружено.
FP – False Positive – ложноположительные срабатывания (ошибки первого рода) (требование ГОСТ: не более 50 %).
FN – False Negative – ложноотрицательные срабатывания, т. е. пропуски заведомо известных ошибок (ошибки второго рода) (требование ГОСТ: не более 50 %).
TP обратно пропорционально FN.
TN обратно пропорционально FP.

Результат по основной формуле для C/C++ говорит, что все анализаторы не уложились в показатель: не более 50% False Positive (FP). Показатель FP обратно пропорционален True Negative (TN), который, как видно из графика, получился маленьким у всех анализаторов.

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

Впрочем, TN в любом случае у всех маленький (большой FP). Это говорит о том, что в сумме участниками были предоставлены синтетические тесты, на которых другим вендорам было тяжело. Это подсветило для каждого его слабые места и показало, куда стоит развивать инструменты.

Примечание. Результаты по бинарному принципу (см. 9 слайд презентации) другие, но не сильно лучше: только Svace укладывается в диапазон.

Об итогах испытаний статических анализаторов исходного кода при организационной и методической поддержке ФСТЭК России в 2025 году (часть 2 из 6)

По итогам можно сказать, что все инструменты успешно запускаются на отечественных ОС ALT Linux или Astra Linux. Из таблицы видно, что PVS-Studio выполнил без аномалий анализ всех проектов для всех заявленных языков (C/C++, C#, Java). Нет подсвеченных красных ячеек, которые свидетельствуют об аварийном завершении проверки, о слишком длительной проверке или об аномальном количестве срабатываний.

Например, C/C++ анализаторам PT и Echelon не удалось выполнить проверку большого проекта ceph. Или что-то пошло не так. Для Java проекта netty анализтор Solar выдал 150491 срабатываний, что превышает количество строк в проекте. И так далее.

У PVS-Studio получились хорошие количественные показатели по предупреждениям и времени работы по всем заявленным языкам. Столь же аккуратные результаты демонстрирует ISP RAS.

Однако это не значит, что у команды PVS-Studio всё прям идеально шло. Например, выяснилось, что мы не поддерживаем формат C# проекта SignalR (.slnf). Мы дорабатывали утилиту командной строки и перезапускали анализ этого проекта на одной из дополнительных встреч.

Об итогах испытаний статических анализаторов исходного кода при организационной и методической поддержке ФСТЭК России в 2025 году (часть 1 из 6)

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

Многое из задуманного не реализовано. Что-то формулировалось или менялось на ходу, когда становилось понятно, что выбранный ранее сценарий не получается на практике. Поэтому, хотя какие-то частичные результаты получены, опираться на них для окончательных выводов нерационально. Поэтому в докладах и нет утверждений, что какой-то инструмент прошёл или не прошёл испытания и что именно является окончательными критериями отбора.

Откуда непредвиденная сложность и дополнительные затраты времени, из-за которых не удалось провести планируемый объём испытаний? Один пример.

Анализаторы должны запускаться на отечественной ОС. Непосредственно перед началом этапа по проверке открытых проектов регулятор выбрал несколько важных для индустрии проектов. Хорошие проекты, нормальный выбор. Но на практике оказывается, что некоторые из этих проектов сходу не получается собрать на целевой операционной системе. И вместо анализа команды участников на площадке испытаний занимались попыткой собрать эти проекты. В результате досборку и анализ некоторых из них пришлось перенести другой день.

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

Итак, в испытаниях участвовали [в скобка указано сокращение, которое я буду использовать далее для краткости]:
1) ООО «ПВС», PVS-Studio. [PVS]
2) АО «НПО «Эшелон», АК-ВС 3. [Echelon]
3) АО «Позитив Текнолоджиз», Positive Technologies Application Inspector. [PT]
4) АО «СОЛАР СЕКЬЮРИТИ», Solar AppScreene. [Solar]
5) ИСП РАН, Svace. [ISP RAS]
6) Базальт СПО представляет CodeChecker, включающей связку из: clang-static-analyzer, clang-tidy, cppcheck и gcc. [Basealt]

Echelon, PT, Solar и ISP RAS заявили к испытаниям все языки: C/C++, C#, Java, Go, Python, JavaScript. PVS языки: C/C++, C#, Java. Набор от Basealt испытывался только на C/C++.

С записью докладов, посвящённых испытаниям, можно познакомиться здесь (06:05:10 - приблизительно начало).

Соответствующие презентации лежат здесь (в папке 2. 16-17 Стат. анализаторы).

Открытая конференция ИСП РАН 2025 завершилась. Было приятно встретить множество знакомых лиц и пообщаться с столь концентрированным РБПО сообществом :)

Узнал о компании ЕС-лизинг у которой есть различные наработки в сфере руководств, например по методикам выявления уязвимостей и НДВ или о прядке работы с продуктом Code Scoring. Есть заготовки формуляров, ведомостей и т.д., о которых часто спрашивают слушатели нашего цикла про РБПО. По крайней мере, я сделал такой вывод из беглого знакомства. Надо будет попробовать сделать с ними вебинар, чтобы они поподробнее рассказали, что и как.

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

Но думаю, подписчикам в первую очередь интересно услышать про результаты испытаний статических анализаторов. Про это будет следующий пост.