РБПО-024. Термин: фаззинг-тестирование программы

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

Фаззинг-тестирование хоть и является разновидностью динамического анализа, но достаточно обособлено, поэтому его принято рассматривать как отдельный вид тестирования.
• Википедия. Фаззинг.
• Кирилл Мотков. Что такое фаззинг и зачем он нужен?
• Евгений Новиков. Фаззинг драйверов KasperskyOS.
• Максим Бакиров. Фаззинг или тестирование мусорными данными.

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

Теоретически можно находить цепочки слов, приводящие к аварийному падению парсера. Но нет смысла проводить атаку на анализатор, подсовывая ему на вход мусор с целью привести инструмент к падению (аварийной остановке). Точнее, делать это можно, но непонятно зачем.

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

Захожу на Habr, а там такая статья! Моё почтение автору.

Как манул единорога в горы водил: запускаем PVS-Studio на российских процессорах Эльбрус.

Запись вебинара "Эффективная разработка с Нейтрино и PVS-Studio: инструменты, безопасность и качество кода".

Нейтрино - POSIX совместимая встраиваемая ОС жесткого реального времени со встроенными средствами защиты информации от несанкционированного доступа.

РБПО-025. Термин: экспертиза исходного кода программы

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

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

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

На практике возможности ручного анализа ещё скромнее. Например, методика выявления уязвимостей и НДВ определяет этот порог в 10 KLOC. Если кода (на языке высокого уровня) больше, то проведение исследования невозможно.

См. также:
• Анастасия Камалова. Поиск уязвимостей в исходном коде с помощью ручного статического анализа.
• Андрей Карпов. Можно автоматизировать обзор кода?

РБПО-026. Раздел 4 – общие требования к разработке безопасного программного обеспечения (часть 1/2)
Четвёртый раздел ГОСТ Р 56939-2024 более подробно раскрывает, что понимается под РБПО и как эта практика описывается в виде процессов. Сформулированы основные цели РБПО:

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

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

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

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

Во-вторых, интересно, что в п. 4.4 сделана отсылка на стандарт, которого пока нет:

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

И действительно, если заглянуть в план ФСТЭК на 2025 год по разработке проектов национальных стандартов, то там есть ГОСТ Р "Защита информации. Разработка безопасного программного обеспечения. Методика оценки уровня внедрения процессов разработки безопасного программного обеспечения". В декабре 2025 года он должен быть направлен на издательское редактирование и подготовку к утверждению проекта национального стандарта. В общем, рекомендую отслеживать введение этого и других стандартов, которые могут сказаться на мире РБПО уже в 2025 и 2026 году.

РБПО-027. Раздел 4 – общие требования к разработке безопасного программного обеспечения (часть 2/2)
Когда я читал ГОСТ Р 56939-2024, первым местом, где я испытал уважение к описываемым в нём вещам, стал пункт 4.3.

Поскольку модель жизненного цикла ПО зависит от специфики, масштаба, сложности ПО и условий, в которых ПО создается и функционирует, приведенные в настоящем стандарте процессы намеренно не связываются с конкретной моделью жизненного цикла ПО. По тексту стандарта процессы могут быть соотнесены с обобщенными этапами жизненного цикла ПО (например, с этапом эксплуатации), что дает разработчику гибкость реализации процессов и используемых подходов, таких как изложенных в ГОСТ Р ИСО/МЭК 12207.

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

И последнее, на чём остановимся, прежде чем перейти к рассмотрению 25 процессов, это "артефакты", которые присутствуют в описание каждого из них. Пункт 4.11:

Пункт «Артефакты реализации требований» включает формулировки наименования артефактов, подтверждающих выполнение требований к реализации процессов РБПО, и их содержание. Под артефактами реализации требований в настоящем стандарте понимается любая информация (документы, отчеты, файлы, журналы, результаты работы инструментов, процессов), сохраненная в любом виде (электронном, физическом), на основании которой возможно подтвердить реализацию соответствующих требований.

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

РБПО-028. 25 процессов РБПО
Для начала приведу просто список, чтобы вы успели морально настроится к погружению :)

5.1. Планирование процессов разработки безопасного программного обеспечения.
5.2. Обучение сотрудников.
5.3. Формирование и предъявление требований безопасности к программному обеспечению.
5.4. Управление конфигурацией программного обеспечения.
5.5. Управление недостатками и запросами на изменение программного обеспечения.
5.6. Разработка, уточнение и анализ архитектуры программного обеспечения.
5.7. Моделирование угроз и разработка описания поверхности атаки.
5.8. Формирование и поддержание в актуальном состоянии правил кодирования.
5.9. Экспертиза исходного кода.
5.10. Статический анализ исходного кода.
5.11. Динамический анализ кода программы.
5.12. Использование безопасной системы сборки программного обеспечения.
5.13. Обеспечение безопасности сборочной среды программного обеспечения.
5.14. Управление доступом и контроль целостности кода при разработке программного обеспечения.
5.15. Обеспечение безопасности используемых секретов.
5.16. Использование инструментов композиционного анализа.
5.17. Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок.
5.18. Функциональное тестирование.
5.19. Нефункциональное тестирование.
5.20. Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения.
5.21. Безопасная поставка программного обеспечения пользователям.
5.22. Обеспечение поддержки программного обеспечения при эксплуатации пользователями.
5.23. Реагирование на информацию об уязвимостях.
5.24. Поиск уязвимостей в программном обеспечении при эксплуатации.
5.25. Обеспечение безопасности при выводе программного обеспечения из эксплуатации

Как с этим всем совладать? Хороший вопрос, который я рассмотрю в следующем посте.

А пока предлагаю записываться на вебинар: "Безопасность приложений: инструменты и практики для Java-разработчиков". Состоится 19 июня 11:00. Вебинар буду вести я и Алексей Захаров – Директор по технологическому консалтингу Axiom JDK.

Компания Axiom JDK, поставщик российской платформы Java, основана управляющей командой Центра Разработки Oracle в Санкт-Петербурге. Инженерное ядро сформировано из разработчиков, которые стояли у истоков создания Java в России и заботятся о безопасности платформы с 1997 г.

РБПО-029. Один из способов, который поможет совладать с ГОСТ Р 56939-2024
25 процессов РБПО, описанные в ГОСТ Р 56939-2024, "распаковываются" в длинный список задач, регламентов, списков прав доступа сотрудников, назначение ответственных и очень много чего ещё. Невозможно вручную вести учёт всего этого на бумажных носителях (журналах) или с помощью условных Excel-таблиц. Вернее, можно, но такие трудозатраты нерациональны, а программисты, посмотрев на всё это, начнут подыскивать более технологического работодателя :)

На помощь приходят специализированные системы, раскладывающие РБПО на составные части. Они помогут как внедрить новые процессы, так и в дальнейшем сопровождать их. Примером такой системы является SGRC SECURITM.

Облачный сервис и программное обеспечение SGRC SECURITM позволяет вам построить управление информационной безопасностью компании на базе риск-ориентированного подхода и единой информационной модели компании.

Нужные нормативные документы уже на борту: Приказы ФСТЭК РФ 17, 21, 31, 239, ФЗ-152, ГОСТ Р 57580.1, ISO 27001, NIST 800-53, NIST Cybersecurity Framework, The 20 CIS Controls и другие законодательные акты

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

Объединение требований. Не нужно тратить время на дублирующиеся требования из различных документов — они уже связаны между собой.

Почему я вспомнил именно про SGRC SECURITM? Всё просто: мы знакомы с этой системой, её разработчиками и интегрируемся с ней. Отчёты статического анализатора PVS-Studio могут загружаться и обрабатываться в ней. Подробнее эта тема раскрыта в вебинаре "Внедрение процессов безопасной разработки. Интеграция PVS-Studio и SGRC SECURITM". Описание:

Совместно с экспертом SECURITM Евгенией Карповой мы поговорили о том, как обеспечить соблюдение требований ГОСТ в области безопасной разработки программного обеспечения.
Показали реальные примеры использования PVS-Studio и SECURITM, дали рекомендации по настройке инструментов и рассказали, как оптимизировать процессы разработки для достижения высокого уровня безопасности.

РБПО-030. Процесс 1 - Планирование процессов разработки безопасного программного обеспечения (часть 1/2)
Важный, можно сказать, экзистенциальный пункт внедрения процессов для разработки безопасного ПО. Невозможно просто собрать коллег и сказать им: "С завтрашнего дня у нас РБПО по ГОСТ Р 56939-2024, приступайте". Вернее, сделать так можно, но ничего не произойдёт, или всё выльется в сплошную видимость. Внедрение РБПО требует планирования как с точки зрения регламентов и изменений в работе, так и с точки зрения планирования бюджетов.

Обеспечение потребностей в ресурсах, необходимых для реализации процессов разработки безопасного ПО (п. 5.1.1.1).

Некоторые эксперты в публикациях озвучивают оценку, что внедрение РБПО увеличивает стоимость разработки на 10-15%. На мой взгляд, оценка правдоподобна. Эти наценка складывается из приобретения лицензий на различные дополнительные инструментальные средства и из времени, которое будут затрачивать сотрудники на новые процессы и обязанности.

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

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

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

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

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

Напоминаю Java разработчикам, про сегодняшний совместный вебинар с Axiom JDK. Ждём в 11:00. Зарегистрироваться.

Вышел новый релиз PVS-Studio — 7.37. Встречайте расширенный механизм анализа помеченных данных, возможность выбора версии стандарта MISRA, поддержку анализа

- MSBuild проектов на основе SLNX и ещё много других обновлений!
- Расширение механизма анализа помеченных данных
- Выбор версии стандарта MISRA
- Анализ проектов на основе SLNX
- C23 и стандартная библиотека: улучшения в анализаторе C и C++
- PVS-Studio на Нейтрино
- Интеграция результатов анализа PVS-Studio в Securitm
- Настройка Security Related Issues в .pvsconfig
- Breaking Changes
- Новые диагностические правила
- Статьи
- Вебинары
- Доклады
- Подкасты

https://pvs-studio.ru/ru/blog/posts/1255/

РБПО-031. Процесс 1 - Планирование процессов разработки безопасного программного обеспечения (часть 2/2)
То, что внедрение РБПО по ГОСТ Р 56939-2024 требует планирования и выделения ресурсов, звучит ожидаемо и естественно. Стоило ли делать для этого отдельный пункт в стандарте?

Думаю, да. ГОСТ — это в том числе язык общения между исполнителями и заказчиками, между разными уровнями управления в больших компаниях. В этом смысле ГОСТ может оказаться помощником исполнителей и формализовать, что изменения требуют значительных вложений. Затраты времени и денег можно будет расписать и обосновать по пунктам, основываясь на 25 процессах ГОСТа. Они защищаю от необоснованных ожиданий руководства/заказчиков получить РБПО в рамках прежних бюджетов.

Примечание. Кстати, схожая мысль описана в статье "Зачем нужны ГОСТы для программной документации?".

На случай, если вы пропустили мой позапрошлый пост, то напомню про систему SGRC SECURITM, которая может помочь вам планировать и внедрять РБПО. Ссылка на наш совместный вебинар: "Внедрение процессов безопасной разработки. Интеграция PVS-Studio и SGRC SECURITM".

Одной из первых задач станет подбор инструментальных средств. Здесь вам пригодится эта подборка AppSec и DevSecOps решений (источник). Думаю, в некоторых постах я ещё вернусь к этому сайту, но уже сейчас рекомендую его посмотреть. Кстати, там есть кнопка "Предложить инструмент", так что не стесняйтесь расширять список.

Узкая, но важная тема, для тех, кто уже столкнулся или столкнётся с ГОСТ Р 71207-2024 – Статический анализ кода. Для приоритезации правок кода понадобится выделить предупреждения, предназначенные для выявления критических ошибок (определение – п. 3.1.13).

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

РБПО-xxx. Третий доклад
Появился третий устный доклад про РБПО. В нём обзорно рассмотрены процессы с 1 по 10. Постепенно я разберу их здесь более обстоятельно и снабжу различными отсылками. Доклад же предназначен для общего быстрого знакомства с темой.

Процессы РБПО 5.1-5.10 в ГОСТ Р 56939-2024.

РБПО-032. Процесс 2 — Обучение сотрудников (часть 1/4)
Если сотрудники не заботятся о безопасности, так как просто не знают, что это означает, не понимают, что пишут уязвимый код, то все остальные меры малоэффективны. Процессы РБПО требуют от команды определённой зрелости, осознанности решений и знаний инструментов/практик.

Малополезно просить сотрудника разработать правила кодирования (регламент оформления исходного кода и безопасного кодирования), если он понятия не имеет, что это такое, и не читал такие книги, как "Совершенный код" Стива Макконнелла и "Как написать безопасный код на C++, Java, Perl, PHP, ASP . NET" Ховарда М., Лебланка Д, Виега Д. Ну или хотя-бы "Веревка достаточной длины, чтобы выстрелить себе в ногу" Алена Голуба. Впрочем, именно эта книга мне не нравится, но это лучше, чем ничего.

Если он не в курсе обсуждаемых там подходов и рекомендаций, что он составит? Надёргает случайных рекомендаций из интернета? Просто опишет тот стиль, который сейчас у вас де-факто уже есть? Это можно сделать, но такой документ несёт формальный характер и не будет иметь отношения к безопасной разработке. Зачем тогда вообще его делать? Уж если заниматься РБПО, то надо делать это всерьёз и для реальной пользы. Нет смысла обманывать самих себя.

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

Условно обучение сотрудников можно разделить на два типа: самообразование и внешнее обучение. Собственно, это указано и в примечании ГОСТ Р 56939-2024 (п. 5.2.):

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

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

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

Во-вторых, может быть необходимо подтверждать компетенции сотрудников не только для себя. В случае сертификации необходимо предоставить соответствующие артефакты. Например (п.5.2.3.3):

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

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

Сегодня предлагаю вашему вниманию запись совместного с Axiom JDK вебинара на тему РБПО в мире Java. О Libercat, OpenIDE и т.д.

При построении РБПО не требуются сертификаты ФСТЭК для статических анализаторов и других инструментов разработки

Выдержка из эфира AM Live «Разработка безопасного программного обеспечения (РБПО)». Смотрите в vkvideo начиная с 1:54:10. На rutube начало в 2:06:58.

Дмитрий Пономарев. Сотрудник НТЦ Фобос-НТ / ИСП РАН / МГТУ им. Н. Э. Баумана ИУ10:

Какие требования к инструментам РБПО предъявляет ФСТЭК России? Сразу объясню почему его (вопрос) включили. В очередной раз, оказываясь в большой крупной организации на 6000 только разработчиков… Вопрос, а нам ИБ сказала, что ФСТЭК люто требует чтобы все анализаторы статические, фаззеры и прочие должны с быть с сертификатом ФСТЭК, иначе не считается.

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

Ирина Сергеевна, так всё-таки нужен сертификат ФСТЭК для фаззера и статического анализатора? Или не нужен? Или когда нужен?

Ирина Гефнер. Заместитель начальника Управления ФСТЭК России:

Не нужен сертификат ФСТЭК на инструмент разработки безопасного ПО.

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

И open-source – пожалуйста. Главное, чтобы инструмент позволял выполнять все требования и те виды тестирования и испытания кода, которые мы декларируем в своих документах. В ГОСТ-ах в частности. Если мы касаемся вопросов сертификации, то это методика выявления уязвимостей и НДВ, требования по безопасности информации. Это одно из основных правил и требований.
…