РБПО-019. Термин: поверхность атаки
Важное понятие, которого не было в ГОСТ Р 56939-2016.

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

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

В общем виде термин "поверхность атаки" включает в себя очень много чего. Пример описания:

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

Однако в рамках РБПО речь идёт именно о слабых местах ПО. Мы ещё вернёмся к этой теме, а пока предлагаю для ознакомления следующую статью: Зачем искать поверхность атаки для своего проекта.

РБПО-020. Термин: статический анализ исходного кода программы (часть 1/3)

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

Небольшое отступление
Обзор кода (code review) — один из самых старых и полезных методов выявления дефектов. Он заключается в совместном внимательном чтении исходного кода и высказывании рекомендаций по его улучшению. В процессе обзора выявляются уже имеющиеся ошибки или же участки кода, которые могут стать ошибочными в будущем. Также считается, что автор кода во время обзора не должен давать объяснений, как работает та или иная часть программы. Алгоритм работы должен быть понятен непосредственно из текста программы и комментариев. Если это условие не выполняется, то код должен быть доработан.

Как правило, обзор кода хорошо работает, так как программисты намного легче замечают ошибки в чужом коде. Более подробно с методикой code review можно познакомиться в замечательной книге Стива Макконнелла "Совершенный код" ("Code Complete", Steve McConnell).

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

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

Дополнительная ссылка: Джон Кармак. Статический анализ кода.

Раз в РБПО мы добрались до статического анализа, время изучить возможности PVS-Studio.
Поддерживает анализ кода на языке C, C++ (и диалекты C++/CLI, C++/CX), C#, Java. Совместим с ГОСТ Р 71207–2024 – Статический анализ ПО.

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

От меня промокод firefly для получения лецензии на 1 месяц. Скачать и попробовать.

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