Итоги испытаний статических анализаторов исходного кода при организационной и методической поддержке ФСТЭК России

Итоги испытаний статических анализаторов исходного кода при организационной и методической поддержке ФСТЭК России

Одним из ключевых событий Открытой конференции Института системного программирования РАН им. В. П. Иванникова, прошедшей 9–10 декабря 2025 года, стало подведение итогов испытаний статических анализаторов, организованных при поддержке ФСТЭК России.

В 2025 году коллективы-участники испытаний и автор этой статьи посвятили организации и проведению испытаний значимую часть своего рабочего и личного времени. По итогам были получены интереснейшие и важные результаты, и одновременно с этим стало очевидно — мы только в начале пути. Приобретённый опыт позволит внести необходимые улучшения в ГОСТ Р 71207–2024, доработать тестовую базу и методологию испытаний, подойти к организации следующего цикла испытаний с существенно более точной оценкой ресурсозатрат. Наиболее подробную информацию о задачах и целях, ходе и результатах испытаний, с «человеческими» комментариями их непосредственных участников, вы можете получить, ознакомившись с «первоисточником» — видеозаписью подведения итогов на сайте Открытой конференции [1]. Дальнейшее развитие системы испытаний статических анализаторов (далее — СА) будет освещаться на портале РБПО.рф [2].

Обобщённый опыт организации и проведения испытаний

Вместо предисловия важно отметить, что организация и модерация испытаний явились для меня личным вызовом, потребовавшим существенных затрат времени и нервов, в том числе на принятие решений в ситуациях, когда идеального решения не существует, и от практически любого принятого решения обязательно останутся недовольные. Тем не менее итоги испытаний признаны успешными и полезными, работа будет продолжена. Поэтому я хочу выразить искреннюю признательность всем, принявшим участие в планировании, организации, проведении и всестороннем обеспечении испытаний, и особенно — лично Д. Н. Шевцову и И. C. Гефнер (ФСТЭК России), А. А. Белеванцеву (ИСП РАН), А. В. Кузнецову и А. И. Буркэ (НТЦ Фобос-НТ / ИСП РАН), Е. А. Погорелко (МГТУ им. Н. Э. Баумана) и Н. А. Костригину (Базальт СПО) — порой нам даже было весело (рис. 1).

Рисунок 1. Порой нам было даже весело

Далее представлены наиболее значимые тезисы, описывающие полученный опыт:

1. Задуманный объём испытаний существенно превысил возможности коллективов по формированию комплекта тестов и последующей оценке и кросс-верификации результатов работы инструментов СА.

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

3. Важно фиксировать все обсуждения и принятые решения в протоколах — особенно в отношении тех решений, которые теоретически могут повлиять на подчёркивание тех или иных сильных (и в особенности — слабых) сторон инструментов.

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

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

Тем не менее определённая польза от данной активности была получена в любом случае. Помимо того, что ряд коллективов в ходе разметки выявил некоторые недостатки в своих инструментах СА, коллеги ИСП РАН самостоятельно выполнили «вдумчивую разметку» всего объёма срабатываний детекторов, соответствующих категории ГОСТ (рис. 2).

Рисунок 2. Результаты данной разметки представлены на портале Центра исследований безопасности системного ПО

Результаты данной разметки представлены на портале Центра исследований безопасности системного ПО [6] и могут быть использованы в качестве «эталона» при сравнительном анализе в ходе выбора инструмента СА.

6. ГОСТ Р 71207–2024 «Статический анализ исходного кода» требует внесения ряда доработок и уточнений, в том числе в терминах и определениях, для устранения неоднозначностей трактовок.

7. Необходимо выполнить более точный маппинг детекторов, реализованных инструментами СА, на методы анализа и типы ошибок, заявленные в ГОСТ. Эта кропотливая, но необходимая работа позволит повысить доверие к результатам последующих циклов испытаний за счёт минимизации коллизий срабатывания «не того детектора» в «том месте» кода, где заложена ошибка.

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

9. Штатные особенности работы ряда инструментов анализа должны получить оценку «баг или фича» с целью либо верного учета данных особенностей при оценке результатов испытаний, либо — доработки инструментов до стандартного для методологии испытаний уровня возможностей.

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

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

Результаты испытаний

Данный раздел практически полностью состоит из слайдов с итоговыми количественными оценками (выборочно), без каких-либо пояснений, поскольку полноценный контекст их формирования слишком объёмен для текстового представления в рамках одной статьи. Всех желающих разобраться подробнее с принципами подсчёта результатов, а также ознакомиться со всем множеством результатов, я вновь приглашаю ознакомиться с материалами по ссылкам [1] и [4].

Зафиксирую единственный принципиально важный для восприятия результатов тезис-предупреждение — приведённые далее оценки следует трактовать в качестве приблизительных, в силу:

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

Для предоставленных цифр доверительный интервал оценивается в 7%, за исключением особо обозначенных случаев. Вся разметка выполнялась публично и была доступна для всех участников испытаний, все спорные вопросы разбирались участниками испытаний публично (рис. 3–6).

Рисунок 3. Результаты по основной формуле для языка программирования (ЯП) Си/Си++

Рисунок 4. Результаты по дополнительной формуле для ЯП Си/Си++

Рисунок 5. Результаты по основной формуле для ЯП Java

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

В теории на рис. 6 показано заявленное участниками испытаний число срабатываний детекторов по ГОСТ. На практике:

• не все инструменты имеют механизмы фильтрации по типам детекторов;
• не все разработчики качественно отделили детекторы out-of-scope от ГОСТ;
• некоторые инструменты действительно выдают очень много срабатываний.

Планы по подготовке и проведению следующего цикла испытаний

Дальнейшие планы, озвученные И. С. Гефнер в ходе Открытой конференции, включают в себя:

• доработку и уточнение ГОСТ Р 71207–2024 «Статический анализ исходного кода»;
• доработку методологии испытаний и комплекта тестов с приоритетом создания «сложных», комплексных тестов, позволяющих испытывать инструменты в условиях, приближенных к «боевым»;
• разработку и стандартизацию формата представления результатов статического анализа (по аналогии с форматом SARIF);
• выработку механизма поддержки и развития репозитория комплекта тестов (действующий репозиторий [7] создан и поддерживается коллективом Базальт СПО);

и, главное, подготовку и проведение следующего цикла испытаний в 2027 году.

Вместо выводов. Личная позиция модератора

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

Желания «перекрасить» и продавать открытый или даже проприетарный иностранный инструмент, либо взять опенсорс «asis» и, не вкладываясь в его развитие, получить коммерческий результат, понятны с тактической точки зрения конкретного бизнеса.

Но стратегический негативный эффект от таких действий для отрасли и государства противоречит поставленной Президентом РФ цели достижения технологической независимости.

Испытания СА должны способствовать развитию и конкуренции отечественных школ создания инструментов СА и усложнять рыночную деятельность в указанных выше случаях — разумеется, за исключением случаев, когда открытый инструмент СА «из коробки» существенно лучше платного.

Поэтому я искренне рассчитываю, что органы по сертификации, аккредитованные в области сертификации процессов РБПО, будут опираться на методологию и результаты испытаний, в качестве минимально приемлемой, при оценке реализации процесса № 10 «Статический анализ исходного кода» (ГОСТ Р 56939–2024) разработчиками программного обеспечения и, в особенности, средств защиты информации.

Источники

[1] Секция «Разработка безопасного ПО: качество, доверие, сообщество»

[2] https://рбпо.рф/news/rbpo-isprasopen‑2025

[3] https://ib-bank.ru/rbpos

[4] https://t.me/sdl_community/9420

[5] https://t.me/sdl_community/7859

[6] https://clck.ru/3RSsMi

[7] https://altlinux.space/rbpo-community

Валерий Филатов, Developer Advocate

Комментарий PVS-Studio по итогам испытаний статических анализаторов

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

Один из главных вызовов — неопределённость. Стандарт оперирует рядом понятий, имеющих критическое значение для реализации (например, «перехват сборки»), но не даёт им устойчивых, верифицируемых определений. В таких условиях даже добросовестные участники вынуждены действовать по собственному усмотрению.

Ещё более тревожен перекос в содержании перечня критических ошибок. Фокус на Cи C++ делает стандарт узким для современной многоплатформенной разработки. Тот же nullpointerdereference в Java или C# — регулярно обнаруживаемый дефект — почему-то не попадает в категорию «критических». Если цель стандарта — не просто формальное соответствие, а реальное повышение отказоустойчивости и безопасности, такой список требует расширения.

Процесс испытаний также показал: без чёткого плана, стабильных критериев и заранее верифицированной тестовой базы любая оценка рискует стать субъективной. Анализ зрелых open-source-проектов — хороший жест, но плохой фильтр: когда код и так качественный, разница между инструментами стирается. А гигантский объём предупреждений, выдаваемых анализаторами, оказался неподъёмным для ручной разметки — и потому остался недостаточно изученным.

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

Наталья Быханова, руководитель группы разработки ядер анализа

Комментарий от компании Солар

Хочется поблагодарить организаторов и участников испытаний — это был полезный опыт. Мы проанализировали ход и итоги испытаний, определили точки роста, а также наметили векторы взаимодействия с ГОСТ.

Мы будем и дальше совершенствовать механизмы поиска дефектов и уязвимостей в коде. Стало очевидно, что в ряде сценариев инструменту необходимо иметь возможность настройки точности анализа. В настоящее время мы используем политику, ориентированную на выдачу большего числа false positive с целью не пропустить true positive. Мы добавим возможность управления этой политикой и поработаем над снижением количества false positive. Кроме того, из-за особенностей интерфейса не удалось в полной мере учесть наши результаты — этот момент также будет доработан, в том числе за счёт добавления механизмов фильтрации.

Мы планируем принимать участие в формировании ГОСТ. Нашими ключевыми целями являются:

1. Разработка комплектов тестов для будущих испытаний, снижение однотипных сценариев.
2. Внедрение тестов разного уровня сложности.
3. ГОСТ без фиксированных методов. Фиксированным должен быть результат.
4. Кроме того, мы поддерживаем инициативу создания единого формата отчёта о результатах анализа — это позволит быстрее и качественнее проводить верификацию и сравнение результатов.

Виталий Вареница, заместитель генерального директора

Комментарий от АО «НПО «Эшелон»

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

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

Результаты представлены не по всем заявленным языкам программирования

Изначально в рамках испытаний проверка соответствия статических анализаторов требованиям ГОСТ Р 71207-2024 планировалась в отношении следующих языков программирования: C/C++, C#, Java, Go, JavaScript и Python. Однако в итоговых материалах результаты были опубликованы только для языков C/C++ и Java, по остальным же языкам результаты отсутствовали. Так, значительная часть проделанной работы фактически не была отражена в опубликованных материалах, что не позволяет в полной мере оценить возможности анализаторов.

Проблемы критериев оценивания и начисления баллов

Одной из наиболее острых проблем стала методика оценивания. На старте испытаний участникам была озвучена простая и понятная логика: если анализатор проходит тест — начисляется балл, если не проходит — балл не начисляется. Однако при озвучивании результатов была представлена система с использованием весов, о которой ранее не сообщалось. Суть её сводилась к следующему: если тест успешно прошли все анализаторы, баллы за него никто не получал. Баллы начислялись только в том случае, если хотя бы один из участников тест не прошёл. Например, если из 50 тестов 40 были корректно пройдены всеми анализаторами, а один из анализаторов прошел только эти 40 тестов, то его итоговый результат оказывался равным нулю. Формально он становился в одном ряду с инструментом, который не нашёл ни одного дефекта, хотя фактически демонстрировал корректную работу на некотором объёме тестов. На наш взгляд подобная методика оценки искажает восприятие результатов и отчасти не отражает реального уровня инструментов. Отсутствие заранее зафиксированных и публично обсуждённых критериев оценивания усложняет воспроизводимость и интерпретацию результатов испытаний.

Проблемы со сборкой компонентов на отечественных ОС

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

Недостаточное количество экспертов на этапе кросс-верификации

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

К моменту подведения итогов было видно, что значительная часть компонентов не прошла полноценную экспертную кросс-верификацию.

Нечёткое техническое задание на разработку тестов и общая нехватка времени на подготовку

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

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

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

Заключение

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

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

Для специалистов, интересующихся тематикой статического анализа исходного кода, практическими примерами и разбором подобных вопросов, рекомендуем профильный Telegram-канал @AK_BC_3, посвящённый статическому анализу.