РБПО-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-ключей и паролей.

Для разнообразия о GameDev. Приглашаю к прочтению статьи "Я отклоняю комиты с использованием кучи и прошу коллег переписать такую логику" и приглашаю 25 сентября на вебинар про оптимизацию игр.

РБПО-061. Процесс 16 — Использование инструментов композиционного анализа
Англоязычное название и сокращение — Software Composition Analysis (SCA).

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

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

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

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

Важно то, что к цепочкам поставок нужно относиться очень внимательно. Количество атак через них всё увеличивается, и этот тренд, видимо, ещё долго будет сохраняться. Свежий пример: В ходе атаки GhostAction скомпрометировано 817 репозиториев на GitHub.

Недавний круглый стол на рассматриваемую тему: Цепочка поставок как угроза: как контролировать риски стороннего ПО.

Иногда неприятности могут прийти оттуда, откуда и не ждёшь. Например, масла в огонь могут подливать AI-агенты, заимствующие несуществующие пакеты, которые можно заранее подготовить и подсунуть. Смотри интересный доклад Алексея Смирнова "О влиянии применения ассистентов программиста на процессы безопасной разработки".

Подборка SCA-инструментов. При этом, выбирая себе инструмент следует учитывать, что скоро появится ГОСТ — Композиционный анализ программного обеспечения. Уже есть проект этого стандарта. На мой взгляд, стоит обратить внимание на Codescoring.

P.S. В стандарте не упоминается SBOM (Software Bill of Materials), но это важная сущность в задаче контроля цепочек поставок. Это перечень компонентов, библиотек и зависимостей, которые входят в состав программного приложения, а также информация о лицензиях, версиях и других метаданных, связанных с этими компонентами. SBOM улучшает прозрачность (обеспечивает понимание того, из чего состоит программный продукт), ускоряет реагирование на инциденты, помогает управлять безопасностью.

Ссылки:
1. Wikipedia. Software composition analysis.
2. SCA на языке безопасника.
3. Алексей Смирнов — Проверка open source: защита цепочки поставок и эффективный композиционный анализ.
4. Инструкция по SCA: генерация SBOM, инструменты, отличия.
5. Построить SBoM, вырастить SDL-политики, воспитать культуру безопасной разработки / Алексей Смирнов.
6. Алексей Смирнов: Не проверив Open Source “под капотом” продукта, нельзя утверждать, что он безопасен.
7. Practical Guide to NTIA Compliant SBOM.
8. Методическая рекомендация № 2025-09-012. Алгоритм представления перечня заимствованных. программных компонентов с открытым исходным кодом (далее - SBOM).

Запись "Динамический анализ кода программы" из цикла "Вокруг РБПО за 25 вебинаров". Это одиннадцатый процесс ГОСТ Р 56939-2024. Приглашённые эксперты: Евгений Дужак (компания "СВД Встраиваемые системы"), Никита Чуманов и Артём Ежов (Центра сертификации АО «НПО «Эшелон»).

РБПО-062. Процесс 17 — Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок

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

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

Для этого требуется (п.5.17.2.1):

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

А иначе "Красивая иконка оказалась приманкой. Разработчик Ethereum потерял всё за один клик". Причём есть прогноз, что подобный обходной путь атаки будет набирать популярность.

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

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

Однако в 17-м процессе делается упор на договорные обязательства стороннего поставщика. Это логично. Если вы заказали качественное ПО, вы его и должны получить. Cм. артефакты в разделе 5.17.3. При это всегда помним: доверяй, но проверяй.

Из всех артефактов мне непонятен только п.5.17.3.5:

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

Если бы речь шла о поставке скомпилированных модулей/библиотек, то их проверка антивирусом мне понятна. Но я не понимаю, как связан антивирус и исходный код. Что надо им поверять? Возможно, формулировка неудачная, и буду рад, если кто-то пояснит в комментариях.

Ещё интересно, вот здесь про SBOM речь? П.5.17.3.3:

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

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

Дополнительные ссылки:
1. Атаки на цепочки поставок: как защитить своё программное обеспечение?
2. Open software supply chain attack reference (OSC&R).
3. AppSec Каталог - OSA.
4. Supply-Chain Фаервол.
5. Впервые цепочки поставок ПО были атакованы с использованием открытого кода (2023).
6. Ошибка в обработчике GitHub Actions привела к публикации вредоносных релизов Ultralytics.
7. Атака s1ngularity взломала 2180 GitHub-аккаунтов и раскрыла тысячи секретов.

РБПО-063. Процесс 18 — Функциональное тестирование

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

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

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

Включает разные виды тестирования, позволяющие убедиться, что "ПО делает то, что должно делать":

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

• Автоматизированное тестирование. Используются программные средства для выполнения тестов и проверки результатов выполнения, что помогает сократить время тестирования и упростить его процесс.

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

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

• Юзабилити-тестирование. Выполняется с целью определения, удобен ли некоторый созданный объект (веб-страница, пользовательский интерфейс и т.п.) для его предполагаемого применения.

• Интеграционные тесты. Проверяют взаимодействие и правильную работу двух или более программных модулей, компонентов или систем при их совместной работе. Примером такой проверки может служить тестирование совместимости плагина PVS-Studio с новой версией Qt Creator, которую я описывал в РБПО-039.

Для функционального тестирования PVS-Studio мы больше всего внимания уделяем регрессионным тестам. Это связано с особенностями проекта. Важно следить, что после правки, например, сбора какой-то информации из AST-дерева, не пропадут полезные срабатывания или, наоборот, не вылезут бессмысленные (ложные). Для этого у нас написаны специальные вспомогательные программы, которые запускают анализаторы на наборах открытых проектов (ядра анализаторов и наборы проектов различны для разных языков), а затем позволяют быстро изучать изменения в отчётах, которые выдают ядра анализатора. Если интересно, чуть подробнее познакомиться с нашей внутренней кухней тестирования можно в докладе "Специфика разработки и тестирования статического анализатора".

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

Дополнительные ссылки:
1. Евгений Балыков. Тестирование программных средств.
2. Блог IBS. Что такое функциональное тестирование?
3. Терминология PVS-Studio: Тестирование.
4. Telegram канал: Тестировщики нужны.
5. Алина Медник. Функциональное тестирование: что это, этапы, виды и инструменты использования.
6. Записи докладов конференции SQA Days (конференция в области обеспечения качества программного обеспечения).
7. Записи докладов конференции Heisenbug (конференция по тестированию программного обеспечения не только для тестировщиков).

Как так уж получается, что осенью плотность митапов повышается. Уже сегодня в 16:00 по Мск мы ждём вас на 12-й вебинар цикла "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024". Сегодняшняя тема: "Использование безопасной системы сборки программного обеспечения". Приглашённые эксперты: Игорь Хмелев (Заместитель директора специальных разработок "НПО "Эшелон") и Алексей Захаров (Директор по технологическому консалтингу Axiom JDK). Регистрация.

Завтра (25 сентября в 16:00 по Мск) состоится вебинар про оптимизацию в GameDev! Доклад №1: Кастомные аллокаторы в играх, Сергей Кушниренко, Senior Software Engineer в команде Age of Empires 2 (студия Forgotten Empires). Доклад №2: Оптимизация запуска мобильной игры в 2 раза, Андрей Зенкович, TeamLead в команде Playrix. Регистрация.

30 сентября в 19:00 по Мск я буду участвовать в подкасте Ever Secure. Тема: Любимые грабли программистов, и станет ли вайб-кодинг спасением или новым проклятием.

4 октября в 18:00 вновь пройдёт встреча в стенах Центрального Университета на третьем митапе "Сплошные плюсы. Клуб С++ разработчиков". Локация: Москва, ул. Гашека, д.7 стр. Программа и регистрация на сайте мероприятия.

Компетенция: теория разработки безопасного ПО (РБПО)

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