РБПО-053. Процесс 10 — Статический анализ исходного код (часть 2/4)

Вторая порция ссылок по теме статического анализа и PVS-Studio:
1. Страница на сайте PVS-Studio, посвященная совместимости с ГОСТ Р 71207-2024
2. Модельные варианты ошибок в статических анализаторах
3. SAST как Quality Gate
4. PVS-Studio в CI/CD. Автоматизация регулярного статического анализа на примере интеграции с Jenkins
5. Подкаст. Статический анализ кода / Виды анализа и диагностики / Поиск кадров в регионах
6. Unreal Engine 5. Lyra Game code review. Часть 3. Статический анализ кода с PVS-Studio
7. Рецепты для регулярного статического анализа кода
8. Статический анализ Pull Request'ов — ещё один шаг к регулярности
9. Безболезненное внедрение статического анализа и победа над ложными срабатываниями
10. Что нельзя найти с помощью статического анализа
11. Под капотом SAST: как инструменты анализа кода ищут дефекты безопасности

Не знаете, как приятно и полезно провести вечер 11 сентября в Питере? Все просто — прийти в "Failover Bar" и послушать доклад!

Буду выступать с докладом "Статический анализ кода по ГОСТ Р 71207-2024: что и как год спустя".

В апреле 2024 года впервые вступил в действие ГОСТ Р 71207 — Статический анализ программного обеспечения. Доклад, во-первых, кратко познакомит с сутью этого стандарта, понятием критических ошибок и требованиями, которые предъявляются к процессам и инструментам. Во-вторых, рассмотрим, что этот стандарт означает для индустрии статических анализаторов в целом и для инструмента PVS-Studio в частности. Затронем инициативу ФСТЭК по испытаниям статических анализаторов в 2025 году.

🗓11 сентября в 19:00

Обратите внимание, что сейчас "Failover Bar" расположен по другому адресу:
📍Санкт-Петербург, ул. 2 Советская, 18

Вход свободный. Напитки и еда за свой счет.
Регистрация не требуется 👍

РБПО-054. Процесс 10 — Статический анализ исходного код (часть 3/4)

Вернёмся к ГОСТ Р 56939-2024. По порядку пройдёмся по артефактам.

5.10.3.1 Регламент проведения статического анализа исходного кода ПО должен содержать следующие сведения:

Здесь сразу предлагаю открыть ГОСТ Р 71207-2024 и заимствовать для составления регламента из пятого раздела "Требования к внедрению и порядку выполнения статического анализа".

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

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

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

Про периодичность — см. опять 5 раздел ГОСТ Р 71207-2024.

- критерии пересмотра конфигурации и параметров настройки инструментов статического анализа.

П.5.10.3.2:

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

Думаю, тут всё понятно. Давайте лучше вернёмся к пункту "критерии выбора инструментов статического анализа".

Выбор — интересный вопрос. Статических анализаторов много: List of tools for static code analysis, AppSec Каталог - SAST.

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

В данный момент нет явных ограничений на используемые инструменты. Однако к выбору надо подходит вдумчиво. Подробнее эта тема раскрыта в "Методической рекомендации № 2025-07-011".

В том числе там говорится про испытания статических анализаторов кода. Публикации на эту тему:

- ФСТЭК России объявила о начале масштабных испытаний статических анализаторов
- Испытания статических анализаторов (BIS Journal — "Информационная безопасность бизнеса", № 2(57) 2025, стр. 72–82)
- Итоги этапа «Домашнее задание» испытаний статических анализаторов под патронажем ФСТЭК России
- Мой комментарий касательно PVS-Studio в Telegram-канале

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

Роман Карпов, Директор по стратегии и развитию технологий Axiom JDK.
Зачем Java-разработчику знать регуляторику. Часть 1, Часть 2.

РБПО-055. Процесс 10 — Статический анализ исходного код (часть 4/4)

Продолжаем рассматривать артефакты десятого процесса ГОСТ Р 56939-2024.

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

Про настройку анализаторов — см. п.5.4 в ГОСТ Р 71207–2024. Что такое критические ошибки, я уже разбирал, но на всякий случай ещё раз дам отсылки.

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

п.5.10.3.4 Отчеты по результатам проведения статического анализа должны включать:
- срабатывания инструментов статического анализа;
- результаты анализа (разметки) выявленных ошибок (срабатываний статического анализатора).

На тему разметки можно за основу взять "Инструкцию по проведению разметки результатов статического анализа ядра Linux", составленную "Центром исследований безопасности системного программного обеспечения".

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

P.S.
Предлагаю скачать и попробовать статический анализатор кода PVS-Studio. От меня промокод firefly для получения лицензии на месяц. Бесплатные лицензии для студентов и преподавателей.

PVS-Studio включён в Реестр российского ПО: запись № 9837. Совместим с ГОСТ Р 71207-2024 (Статический анализ кода). Соответствие требованиям "Методики выявления уязвимостей и недекларированных возможностей в программном обеспечении" от 25 декабря 2020 г. Может применяться для РБПО согласно ГОСТ Р 56939-2024. Участвует в инициативе ФСТЭК по испытанию статических анализаторов.

Выложена запись вебинара "Техническая сторона первого этапа испытаний статических анализаторов кода под эгидой ФСТЭК". Скачать файлы презентаций.

Завершился этап «Домашнее задание» в рамках испытаний статических анализаторов ФСТЭК России. Эксперты подготовили набор синтетических тестов для проверки выявления критических ошибок по ГОСТ Р 71207-2024. Однако на практике возникло много технических вопросов. На вебинаре эксперты PVS-Studio, Positive Technologies и АО «НПО «Эшелон» обсудили эти нюансы и поделились полученным опытом.

РБПО-056. Процесс 11 — Динамический анализ кода программы

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

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

В том числе этот процесс подразумевает и фаззинг-тестирование (п.5.11.2.2):

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

Определение этих терминов в ГОСТ Р 56939-2024:

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

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

Также термин динамический анализ кода программы мы уже рассматривали ранее: РБПО-016, 017, 018.

Лекция про фаззинг от ИПС РАН: "Особенности фаззинг-тестирования при проведении сертификационных испытаний", "Подходы к фаззинг-тестированию управляемого кода" и т.д.

Инструментов достаточно много, например:
• Valgrind
• AddressSanitizer
• ThreadSanitizer
• MemorySanitizer
• ИСП Fuzzer

Далее смотрите здесь:
• AppSec Каталог: DAST
• AppSec Каталог: Fuzzing

Но учтите, что очень скоро выйдет ГОСТ "Динамический анализ программного обеспечения". Описанные в нём требования к инструментальным средствам могут сказаться на подходе к их выбору.

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

Тема динамического анализа и фаззинг-тестирования, как я понимаю, весьма обширная, поэтому разные специалисты понимают её по-разному и, соответственно, по-разному подходят к реализации этого процесса. Видимо, поэтому, например, недавно вышла методическая рекомендация № 2025-07-010, уточняющая, что должно включать фаззинг-тестирование:

Тип недостатка: Применение средств фаззинг-тестирования, не реализующих генетические алгоритмы фаззинг-тестирования (в том числе за счет инструментирования тестируемого кода).

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

1. Осипов Станислав. Особенности подачи входных данных при фаззинге в режиме Persistent Mode на примере Libfuzzer + CURL.
2. Чат сообщества ФСТЭК России и ИСП РАН в области разработки безопасного и качественного ПО. Динамика::Доверенная разработка.
3. Positive Hack Days. Фаззинг как основа эффективной разработки на примере LuaJIT.
4. Центр исследований безопасности системного программного обеспечения. Методика фаззинг-тестирования ядра.
5. Никита Догаев. Fuzzing-тестирование. Практическое применение.
6. Николай Шаплов. Как работает fuzzing-тестирование. Рассказ простым языком.

РБПО-057. Процесс 12 — Использование безопасной системы сборки программного обеспечения

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

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

Я не очень понимаю наполнение этого процесса и его глубину. Думаю, мы исправим это, пригласив кого-то из экспертов на соответствующий 11-й вебинар цикла "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024".

Моё поверхностное представление: разработать регламент использования ключей оптимизации. Чтобы в последний момент кто-то не решил: "А давайте при сборке релиза впишем -o3 вместо -o2" (имеются в виду настройки оптимизации). Такие непродуманные и непроверенные действия могут приводить к неожиданным сбоям в работе приложений.

В стандарте ГОСТ Р 56939-2024 ничего не сказано про использование безопасных компиляторов или ГОСТ Р 71206-2024: "Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования". Однако, мне кажется, он присутствует меж строк :)

Область применения ГОСТ Р 71206-2024 (раздел 1):

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

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

На данный момент существуют следующие компиляторы, выполняющие требования к функциям безопасности из ГОСТ Р 71206-2024:
• SAFEC (на основе GCC);
• Safelang (на основе Clang).

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

Впрочем, безопасные системы сборки это не только С/С++ и ГОСТ Р 71206. Есть разработки, например, и в мире Java. Из статьи "Безопасность приложений: инструменты и практики для Java-разработчиков" (как Axiom JDK поддерживает безопасную разработку):

5.12. — Использование безопасной системы сборки программного обеспечения.
Мы используем свой проверенный компилятор для сборки JDK. Мы создали свои доверенные Gradle и Maven, которые собрали своим компилятором Java. Эти сборки позволяют гарантировать чистоту сборочного конвейера. Дополнительно они вносят в JAR-файлы библиотек подписи с информацией, что сборка библиотеки произведена компанией Axiom JDK.

Дополнительные ссылки:
1. Рекомендации по обеспечению безопасности системы сборки.
2. Как обеспечить безопасность сборки ПО: управляем внешними зависимостями.

Запись "Экспертиза исходного кода" из цикла "Вокруг РБПО за 25 вебинаров". Это девятый процесс ГОСТ Р 56939-2024.

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

Буду выступать на этой конференции с докладом: MISRA — альтернативный взгляд на разработку безопасного ПО.

P.S. Мы сейчас активно продолжаем увеличивать покрытие стандарта MISRA C 2023 в PVS-Studio. Планируем завершить работы в этом направлении до конца 2025 года.

Команда PVS-Studio просит присылать примеры ошибок, связанные с использованием вайб-кодинга (часть 1 из 2)

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

Есть две школы мысли.
Первая — это директора, HR-ы и "эффективные менеджеры", которые уже планируют сокращения IT-отделов. Они искренне верят, что ChatGPT скоро будет писать весь код, а программисты станут не нужны. Максимум оставят пару "промт-инженеров" и всё. Зачем платить разработчику, если можно просто попросить ИИ "сделать мне интернет-магазин"?
Вторая школа мысли сложна для понимания, потому что senior-программисты ржут так сильно, что не могут нормально объяснить.
(c) Мем с просторов интернета

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

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

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

Мой коллега, экспериментировавший с AI, недавно прислал вот такое описание бага:

"Произошёл забавный случай, как нейронка придумала мне ошибку. Я попросил нейронку для моего класса Warning реализовать методы сравнения".

public class Warning
{
  public string ErrorCode { get; set; }
  public string Message { get; set; }
  public uint Level { get; set; }
  public List<Position> Trace { get; set; }
}

public class Position
{
  public int Line { get; set; }
  public string FilePath { get; set; }
}

Фрагмент реализации от нейронки:

public bool Equals(Warning other)
{
  if (other is null) return false;
  if (ReferenceEquals(this, other)) return true;

  return ErrorCode == other.ErrorCode &&
         Message == other.Message &&
         Level == other.Level &&
         (Trace == other.Trace || 
          (Trace != null && other.Trace != null &&
           Trace.SequenceEqual(other.Trace)));
}

public override int GetHashCode()
{
  unchecked
  {
    int hash = 17;
    hash = hash * 23 + (ErrorCode?.GetHashCode() ?? 0);
    hash = hash * 23 + (Message?.GetHashCode() ?? 0);
    hash = hash * 23 + Level.GetHashCode();
    hash = hash * 23 + (Trace?.GetHashCode() ?? 0); 
    return hash;
  }
}

Факап в функции GetHashCode в строке:

hash = hash * 23 + (Trace?.GetHashCode() ?? 0);

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

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

Сейчас в PVS-Studio диагностики для такого случая нет — открыли TODO на создание. Это, конечно, даже ещё не начало пути, поэтому и просим присылать свои подобные случаи.

Команда PVS-Studio просит присылать примеры ошибок, связанные с использованием вайб-кодинга (часть 2 из 2)

Зачем статические анализаторы? Пусть ошибки ищет другой AI

Я не думаю, что классические статические анализаторы будут полностью замены инструментами на основе AI. Наоборот, потребность в них может только возрасти, как к детерминированному подходу к контролю создаваемого ПО.

Идея отдать код, сгенерированный одной AI-системой, на проверку другой AI-системе выглядит привлекательной. Но есть два больших но.

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

Второе. Не всех устраивает круговая безответственность.

Разработчик не виноват, что одна AI-система сгенерировала код с уязвимостью, а другая её не нашла. Вайб-кодинг допускает, что программист может не до конца понимать принципы работы созданного кода, тем более в разрезе его безопасности.

Создатели AI-систем не возьмут ответственность, что создают код без уязвимостей или умеют их выявлять. Мало ли как программист сформулировал задачу. Да и вообще, такая технология...

Никто не виноват, а уязвимости — вот они. Исправят, но что дальше? Какие действия предпринять, чтобы сделать разработку безопасной?

Общий ответ — строить процессы безопасной разработки, одним из которых как раз является статический анализ кода, причём классический или даже ГОСТ-овский — ГОСТ Р 71207-2024 :)

Классические анализаторы тоже не гарантируют, что будут найдены все потенциальные уязвимости. Зато они работают детерминировано!

Если ошибка не найдена, или наоборот анализатор выдал ложное срабатывание, он делает это по понятной для человека логике. Диагностики описаны в документации. В крайнем случае можно попросить разработчиков анализатора рассказать, как именно устроен детектор. И если нужно — предложить доработки для него.

В случае AI всё приблизительно и без ответственности. Ещё один вопрос: на каких данных системы обучаются? Не скармливает ли кто-то туда тайно специально уязвимый код как образцовый?

Используются ли внутри PVS-Studio какие-то AI-алгоритмы для поиска ошибок?

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

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

Присылайте примеры ошибок, возникших в результате использования вайб-кодинга

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

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

Всем заранее спасибо.

P.S. За примеры, которые понравятся, отправлю в подарок книгу про UB.

Идею предложили, которую дописал выше в «P.S.»: тем, кто пришлёт пример вайб-кодинг бага, который понравится, отправлю в подарок бумажную книгу 📘 про неопределённое поведение.

Интересный текст про белок-истеричек, которые увидели ложное срабатывание ;)
Владимир Кочетков. Почему фолзят SAST'ы? Часть 1, Часть 2.

РБПО-058. Процесс 13 — Обеспечение безопасности сборочной среды программного обеспечения

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

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

Это отчасти схоже с процессом 12, но только здесь не про сборку ПО, а про среду/инфраструктуру сборки в целом. Речь про предотвращение проблем, связанных с неожиданным изменением этой среды, или использование каких-то опасных инструментов/компонентов.

Для этого требуется в первую очередь:
1. Утвердить права доступа к среде сборки ПО и хранилищу результатов сборки ПО. Такие образом снижаются риски воздействия/подмены дистрибутива изнутри компании;
2. Обеспечивать регистрацию всех выполняемых действий при сборке ПО в журналах аудита. Также должны быть прописаны сроки хранения этих журналов;
3. Результаты сборки ПО должны помещаться в выделенное хранилище;
4. Если проект этого требует, обеспечивать возможность повторяемости сборки ПО;
5. Обеспечивать защиту каналов связи с внешними источниками данных для обеспечения конфиденциальности информации, обрабатываемой в сборочной среде.

Требуется также разработать схематическое изображение сборочной среды (серверы, узлы, контейнеры, связи, позволяющие отследить порядок сборочных действий, компоненты сборочной среды, инструменты статического анализа и т.д.). Рекомендуется использовать UML, IDEF, С4.

В целом польза такой схемы мне понятна. Она поможет понять новым сотрудникам и тем, кто занят аудитом, как в целом устроена среда сборки. Однако, видимо, откликается мой личный опыт времён обучения в университете, где IDEF в курсовых использовался просто потому, что он должен там быть :) Я к тому, что надо постараться, чтобы такая созданная схема была действительно полезна, а не просто нарисована. Что будет отличать одно от другого, к сожалению, затрудняюсь подсказать.

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

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

О проблематике, что динамический анализ — это широкое понятие (см. РБПО-056), хорошо написано в статье «Многоликий динамический анализ» Дмитрия Пономарёва. Статья опубликована BIS Journal N3 (58) 2025. Кстати, этот номер как раз посвящён динамическому анализу.

РБПО-059. Процесс 14 — Управление доступом и контроль целостности кода при разработке программного обеспечения

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

Обеспечение управления доступом к исходному коду и его целостности.

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

5.14.2.1 Разработать регламент доступа к исходному коду ПО и обеспечения его целостности.
Примечание — При разработке и реализации регламента доступа к исходному коду ПО рекомендуется руководствоваться принципами минимизации привилегий и разделения полномочий.

В том числе это и про систему контроля версий и правила работы с ней. Причём, выбирая систему контроля версий, теперь стоит учитывать, кто её разрабатывает. Рационально отдавать предпочтением отечественным разработкам, например, GitFlic.

Примечание. Я назвал платформу GitFlic по простой причине. Я про неё знаю, так как PVS-Studio интегрируется с ней. Разработчики могут получать результаты сканирования кода напрямую в интерфейсе GitFlic, что упрощает процесс разработки. Документация: Запуск PVS-Studio в GitFlic.

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

Но можно придумать, как скрыть закладки. Например, можно вспомнить приём использования невидимых символов, получивший название Trojan Source. За подробностями и примерами можно заглянуть в документацию PVS-Studio: V1076. Code contains invisible characters that may alter its logic. Consider enabling the display of invisible characters in the code editor. Сейчас этот метод уже не очень актуален, так как редакторы и другие инструменты знают про него и показывают такие символы. Но всегда придумают ещё что-то новое.

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

1. Atlassian. Что такое контроль версий?; Управление исходным кодом и т.д.
2. Yandex Cloud. Система контроля версий.
3. Wikipedia. List of version-control software.
4. Wikipedia. Comparison of version-control software.
5. AppSec Каталог. VCS.
6. Positive Technologies. Контроль целостности кода функций.

Сегодня пообсуждали в FailoverBar новый вызовов для статических анализаторов - вайб кодинг. Вот прям чувствуется есть интерес :) Надо развить эту тему :)

Запись "Статический анализ исходного кода" из цикла "Вокруг РБПО за 25 вебинаров". Это десятый процесс ГОСТ Р 56939-2024.

Этот вебинар прошёл без приглашённых экспертов, что не помешало ему занять 4 часа. Сразу ясно про что мы любим поговорить :)

Однако это не всё. Мы готовы провести дополнительный вебинар про статический анализ, чтобы познакомить подписчиков с другими инструментальными средствами. Приглашаю заинтересованных вендоров статических анализаторов написать нам и принять участие в вебинаре. Можно сделать теоретический доклад и/или рассказать про своё решение (доклад на 30-60 минут).

РБПО-060. Процесс 15 — Обеспечение безопасности используемых секретов

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

Обеспечение безопасного использования секретов.

Примечание — В данном подразделе под секретами понимаются данные в любом виде, которые могутиспользоваться для обеспечения аутентификации и/или целостности и/или конфиденциальности информации (пароли, цифровые сертификаты и т. п.), в том числе путем применения в соответствии с законодательством Российской Федерации средств криптографической защиты информации или иными методами.

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

Требования к реализации, изложенные в данном подразделе, применяются пользователями стандарта по их усмотрению и в необходимых им объемах.

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

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

Ещё на тему инструментария поиска секретов загляните сюда: AppSec Каталог - Secret Scanning.

Для хранения, управления и предоставления секретов использовать систему управления секретами.

Примером простых систем для решения части задач являются всем знакомые утилиты хранения паролей, такие как KeePass. Про комплексные решения можно легко найти информацию в Интернете. Статьям в духе "10 лучших программ для управления секретами" я не очень доверяю, так что лучше сами :) Для начала можно заглянуть сюда:

1. Обзор StarVault 1.2, системы управления секретами и защиты доступа.
2. Как управлять секретами, чтобы избежать утечки данных.
3. Управление секретами: путь от Opensource до Enterprise.
4. Управление секретами в РФ: Обзор российских сервисов для безопасного хранения API-ключей и паролей.