РБПО-021. Термин: статический анализ исходного кода программы (часть 2/3)
Внедрение статического анализа в процесс разработки это:

1. Выявление ошибок в программах и "кода с запахом" (например, непереносимый или сложный для понимания код).

2. Обнаружение критических ошибок (потенциальных уязвимостей).

3. Один из ключевых процессов для построения РБПО.

4. Рекомендации по оформлению кода. Некоторые статические анализаторы позволяют проверять, соответствует ли исходный код принятому в компании стандарту оформления. Имеется в виду контроль количества отступов в различных конструкциях, использование пробелов/символов табуляции и так далее.

5. Подсчёт метрик. Метрика программного обеспечения — это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.

6. Проверка соответствия текста программы определённым стандартам кодирования (MISRA, CWE, SEI CERT, и т.д.).

7. Контроль качества кода во времени. Собирая статистику, можно узнать, растёт или уменьшается плотность ошибок со временем. Это позволяет отвечать на вопросы о том, какие изменения в процессе разработки проекта пошли на пользу, а какие нет.

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

4 и 5 июня буду в Москве для участия в вечерних митапах. А днём пока свободен и открыт к предложениям ещё где-то поучаствовать: внезапный подкаст, рассказ вашим коллегам в офисе про статический анализ :). Если есть подходящая идеи - напишите.

РБПО-022. Термин: статический анализ исходного кода программы (часть 3/3)
Как и у любой другой методологии выявления ошибок, у статического анализа есть свои сильные и слабые стороны. Важно понимать, что нет одного идеального метода обеспечения качества кода. Для разных классов программного обеспечения разные методики будут давать разные результаты. Добиться высокого качества программы можно только в случае, если использовать сочетание различных методик.

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

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

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

3. Можно легко и быстро обнаруживать опечатки и последствия использования copy-paste. Как правило, нахождение этих ошибок иными способами является крайне неэффективной тратой времени и усилий. Обидно после часа отладки обнаружить, что ошибка заключается в выражении вида strcmp(str_a, str_a). Обсуждая типовые ошибки, про такие ляпы, как правило, не вспоминают. Но на практике на их выявление тратится существенное время.

Дополнительные ссылки:
• Как внедрить статический анализатор кода в legacy проект и не демотивировать команду.
• Внедряйте статический анализ в процесс, а не ищите с его помощью баги.

РБПО-023. Термин: уязвимость программы

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

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

Меня бомбит, когда пишут, что кто-то нашёл 100 уязвимостей в таком-то проекте с помощью инструмента X. Не 100 уязвимостей он нашёл, а 100 ошибок в лучшем случае. Какая-то из них, возможно, действительно является уязвимостью. Но, скорее всего, нет. Найти настоящую уязвимость ещё постараться надо. Понятно, что "нашли много уязвимостей" звучит пугающе, но стоит понимать, что, скорее всего, перед вами жёлтый заголовок. Подобный случай я рассматривал в статье "GPT-3 нашёл 213 Security Vulnerabilities... Или не нашёл".

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

Ещё лучше организовать процесс написания кода так, чтобы потенциальные уязвимости появлялись как можно реже. В этом с точки зрения РБПО поможет обучение сотрудников, стандарт написания кода и т.д.

P.S. Та уязвимость, которая только что была обнаружена, называется уязвимость нулевого дня. Термин означает, что у разработчиков было 0 дней на исправление дефекта: уязвимость или атака становится публично известна до момента выпуска производителем ПО исправлений ошибки.

РБПО-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/