Методическая рекомендация № 2025-07-011 | Уровень критичности: 3

Область: Инструментальный анализ

Тип недостатка: Необоснованный выбор инструментов, в том числе инструментов статического анализа исходного кода, для выстраивания и выполнения процессов РБПО.

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

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

- инструменты должны удовлетворять частным техническим требованиям, если они заданы ФСТЭК России (например, требованиям Методики ВУ и НДВ ФСТЭК России к статическим анализаторам исходного кода, написанного на ЯП высокого уровня)

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

Также при сертификации процессов безопасной разработки контролируется использование организацией инструмента (-ов) статического анализа, соответствующего требованиям ГОСТ Р 71207-2024.

В указанном ГОСТ приведены как требованиям к методам статического анализа, так и алгоритм выбора и конфигурирования инструмента, алгоритм проверки соответствия инструмента требованиям ГОСТ, а также базовые численные критерии.

В настоящий момент под патронажем ФСТЭК России проводятся публичные испытания статических анализаторов (для 6 ЯП). В рамках данных испытаний создаются как публичная база тестов, так и методология оценки соответствия инструментов требованиям ГОСТ. Данная методология будет являться опорной (либо - прототипом, для инструментов статического анализа иных ЯП) для проверки соответствия тех или иных инструментов статического анализа требованиям ГОСТ.

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

Рекомендации:

- ознакомиться с требованиям ГОСТ к инструментам и методологией оценки соответствия инструментов этим требованиям

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

Дополнительные информационные материалы:

- ответ представителя ФСТЭК России на вопрос о наличии требования сертифицированности инструментов

- ГОСТ Р 71207-2024 "Статический анализ программного обеспечения"

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

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

Рассмотрим применение статических анализаторов кода вообще и PVS-Studio в частности с точки зрения выявления поверхности атаки.

Многие статические анализаторы умеют выполнять Taint-анализ для выявления проблемы использования недостоверных данных. В терминологии ГОСТ Р 71207-2024 это называется анализ помеченных данных (п.3.1.3):

Статический анализ, при котором анализируется течение потока данных от источников до стоков.
Примечание.
1) Под источниками понимаются точки программы, в которых данные начинают иметь пометку — некоторое заданное свойство. Под стоками понимаются точки программы, в которых данные перестают иметь пометку.
2) Распространённая цель анализа помеченных данных — показать, что помеченные данные не могут попасть из источников — точек ввода пользователя в стоки — процедуры записи на диск или в сеть. Факт такого попадания означает утечку конфиденциальных данных.

Taint-анализ помогает выявлять код, неустойчивый к XSS-атакам (межсайтовый скриптинг), XEE-атакам (billion laughs attack), XXE-атакам (XML External Entity) и т.д.

Чтобы выявить поступление недостоверных данных и их небезопасную обработку, анализатор должен заранее знать, собственно, откуда они могут поступить и что такое небезопасная обработка. Для этого разработчики анализаторов закладывают в анализаторы соответствующую информацию о функциях стандартных и наиболее часто используемых библиотек. Например, что функция fread читает внешние данные, а fwrite записывает их вовне.

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

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

Поэтому в ГОСТ Р 71207-2024 явно написано (п.7.6):

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

В PVS-Studio, например, реализована эта требуемая стандартом разметка истоков и стоков данных для всех поддерживаемых языков (C, C++, C#, Java).

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

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

Сегодня буду ведущим пятого вебинара. Приглашаю регистрироваться👀

Я всё про РБПО. А ведь PVS-Studio – это не только ценный SAST, но и 3-4 килограмма ценных, легкоусваиваемых детекторов для GameDev проектов. Для разнообразия статья: На защите GameDev'a: статический анализ и Unity.

Сегодня презентуют: OpenIDE — профессиональные инструменты без ограничений. В свою очередь, мы сегодня опубликовали статью про плагин: PVS-Studio доступен в OpenIDE :)

РБПО-045. Процесс 8 — Формирование и поддержание в актуальном состоянии правил кодирования (часть 1/4)

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

5.8.1.1 Обеспечение эффективной и единообразной организации оформления и использования исходного кода в соответствии с предъявляемыми к ПО требованиями.

Основное время при работе с кодом программисты тратят не на его написание, а на чтение! Это подтверждено исследованиями, да и вы сами, если программируете и присмотритесь к своей работе, это заметите.

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

Есть сразу несколько причин, почему так происходит:

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

2. Часто приходится сопровождать чужой код, из-за чего бывает трудно найти нужное место и понять, как всё устроено.

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

4. В legacy-проектах можно по аналогии с годичными кольцами деревьев наблюдать изменение в стиле написания кода. Чаще всего это связано с появлением новых версий языка и библиотек. Эта разнородность тоже добавляет сложность к пониманию старых частей проекта.

5. Известно, что с ростом проекта плотность ошибок растёт нелинейно. Т.е. чем больше кода, тем выше вероятность, что при написании или изменении кода будет внесена ошибка. Это объясняется ростом взаимосвязей разных частей проекта, которые сложно учитывать. Рост сложности понимания влияет и на рост процента времени, который приходится тратить человеку прежде чем сделать правку.

6. Думаю, вы и сами сможете добавить пару пунктов к этому списку.

Из сказанного вытекает, что требуется делать код по возможности простым для восприятия (чтения). Также очень важно, чтобы весь код был единообразно оформлен. Если оформление единообразно, то проще прочитать, понять и исправить код коллег.

Это можно достичь, сформировав, приняв и поддерживая в актуальном состоянии правила кодирования. Что, собственно, и описано в пункте 5.8 ГОСТ-а, который мы рассматриваем. Т.е. следует разработать регламент оформления кода и систематически его придерживаться.

РБПО-046. Процесс 8 — Формирование и поддержание в актуальном состоянии правил кодирования (часть 2/4)

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

Они не правы. Я считаю, что даже не очень хороший стандарт лучше, чем его отсутствие. Однако я не говорю, что надо мучиться и преодолевать неудобства. Можно и нужно совершенствовать регламенты. Собственно, это даже отражено в названии рекомендуемого восьмого процесса РБПО — формирование и поддержание в актуальном состоянии правил кодирования.

В любом случае, код должен оформляться единообразно. Иначе неизбежны проблемы при совместной разработке и поддержке проекта. А мы в рамках темы РБПО говорим о проектах, где участвуют много разработчиков, а не об индивидуальном пет-проекте.

Есть ещё одна проблема, которая возникает, если нет единого подхода к написанию и оформлению кода: как вносить правки в код коллег, оформленный в их собственном стиле? Хорошего варианта нет:

1. Написать нужный код в своём стиле. Постепенно получится каша из несвязанных стилей. Это то же самое, когда вообще ни у кого нет никакого стиля написания кода. Код со временем при совместной работе будет становиться всё хуже и непонятнее всем сразу.

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

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

Если я всё ещё не убедил, расскажу последнюю историю. Общаясь с одним человеком, который проработал в коммерческой компании почти с момента её основания до становления успешным большим бизнесом, я спросил, что бы он устроил по-другому в работе, если бы вернулся лет на 15 назад? Ответ, в том числе, содержал следующий момент:

Я бы настоял принять единый стандарт кодирования на всю компанию. Мы упустили этот момент, и сейчас мы по факту имеем свои собственный стандарты кодирования для С++ и Java в разных командах, работающих над своими проектами. Это очень неудобно, но сейчас внедрять единый стиль и переформатировать код всех этих проектов нереально.

В общем, чем раньше вы позаботитесь о единообразии, тем лучше!

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

Помимо докладов, Вера Багно (App-Sec-инженер компании Swordfish Security), провела демонстрацию работы с AppSec.Hub. Напоминаю, что PVS-Studio интегрируется с AppSec.Hub — подробнее ознакомиться с документацией можно по ссылке, а запись соответствующего вебинара доступна здесь.

Найди Волли Единорога ;)

РБПО-047. Процесс 8 — Формирование и поддержание в актуальном состоянии правил кодирования (часть 3/4)

Артефакты реализации требований (что, собственно, представляет собой регламент):

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

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

Думаю, лучше всего начать с такой замечательной книги, как "Совершенный код" Стива Макконнелла ("Code Complete", Steve McConnell).

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

C++ программисты могут почерпнуть идеи из вот этого документа с хорошими мыслями и отсылками к другим стандартам: Coding Standards.

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

Вообще, стоит проговорить, что существует множество разных стандартов кодирования, таких как MISRA C/C++, CWE (Common Weakness Enumeration), OWASP Application Security Verification Standard (ASVS), SEI CERT Coding Standard и так далее. Но с точки зрения рационального использования времени бессмысленно их читать для составления правил кодирования, а затем вручную контролировать их выполнение. Для этого есть статические анализаторы кода. Собственно, в 8 главе стандарта есть даже их упоминание:

Примечание — Допускается реализовывать проверку правил кодирования средствами компиляции или статического анализа.

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

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

1. Лекция 8. Стандарт кодирования PVS-Studio и приёмы при разработке эффективных С++ диагностик. Видео 2019 года, поэтому кое-что у нас уже поменялось. Сейчас я бы рассказал немного по-другому и привёл бы иные примеры. Тем более учитывая, что за это время мы переписали ядро C++ анализатора. Но в целом ok, полезное. Предлагаю к просмотру.

2. Wikipedia. Стандарт оформления кода. См. отсылки на стандарты.

Появился проект ГОСТа на SCA:
Защита информации. Разработка безопасного программного обеспечения.
Композиционный анализ программного обеспечения. Общие требования.

Торжественный запуск PVS-Studio на испытаниях статических анализаторов кода под эгидой ФСТЭК

Сейчас начинается OWASP AI Agentic Top 10 Project Kick-off - Global Call https://www.youtube.com/watch?v=mMLG6YNm6A8
Будет представлена альфа версия будущего Top 10 для агентов от OWASP