РБПО-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 стр. Программа и регистрация на сайте мероприятия.

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

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

Здесь что-то тема не пошла. Пробую на Хабре: https://habr.com/ru/companies/pvs-studio/articles/950552/ Но пока что-то и там тихо :(

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

Приглашённые эксперты: Игорь Хмелев (АО «НПО «Эшелон») и Алексей Захаров (Axiom JDK).

В ходе вебинара Алексей упоминал совместную статью. Вот она: "Безопасность приложений: инструменты и практики для Java-разработчиков".

РБПО-064. Процесс 19 — Нефункциональное тестирование

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

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

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

Можно сказать так: функциональное тестирование проверяет, что ПО делает то, что должно делать. А нефункциональное проверяет:

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

2) ПО не делает того, что не должно делать. Т.е. программа случайно или преднамеренно не содержит недекларированные возможности (НДВ).

В рассматриваемом разделе под нефункциональным тестированием понимаются следующие проверки:

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

Дополнительные ссылки:
1. QA_Bible. Нефункциональное тестирование (Non-Functional testing).
2. Ttestengineer ru. Нефункциональное тестирование — гайд.
3. Нефункциональные проверки при тестировании мобильных приложений.
4. Wikipedia. Non-functional testing.
5. Алексей Симкин. Гайд по тестированию локализации и интернационализации, а также большой и полезный checklist.

Запись вебинара "Оптимизация игр".

Вместе с экспертами из игровых студий — Forgotten Empires и Playrix — поговорили о тонкостях работы с памятью, кастомных аллокаторах, а также способах ускорить запуск мобильных игр.

Подножка для AI в виде UTF-8. Часть 1 из 3: предисловие

Публикую своё наблюдение в преддверии подкаста Ever Secure на тему "Любимые грабли программистов, и станет ли вайб-кодинг спасением или новым проклятием". Решил разместить здесь пример, который я, скорее всего, упомяну в подкасте. На слух может быть сложно понять суть бага, поэтому код для наглядности не помешает.

Я немного экспериментировал с генерацией кода с помощью GigaChat и DeepSeek. Это не рабочие задачи и не полноценное исследование. Мне просто было интересно найти примеры пересечения некой грани сложности при решении задачи, после которой начинаются проблемы с генерацией C++ кода.

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

Кстати, здесь вырисовывается потенциальная проблема при обучении программированию: слишком велик соблазн сразу получить ответ, так и не разобравшись, как всё работает. Видимо, придётся обратно возвращаться к написанию кода на бумаге :) Но сейчас не будем углубляться в эту тему.

Для одного из экспериментов я выбрал создание программы, которая будет читать файлы с исходным кодом и выполнять ряд операций над названиями переменных или их составными частями. Одна из задач — это получить из имени переменной RedColor три токена: RedColor, Red и Color.

Думаю, задача разбития на токены часто встречается в программировании, и существует много открытого кода на эту тему. Поэтому в такой постановке GigaChat и DeepSeek с этой задачей справляются хорошо.

Однако мир сложнее, и нужно работать не просто со стандартной ANSI кодировкой, но и, например, с UTF-8. Поэтому я начал просить писать код, обрабатывающий файлы в том числе в формате UTF-8. И в этот момент генераторы кода поплыли.

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

Подножка для AI в виде UTF-8. Часть 2 из 3: баги

Итак, приведённый ниже код сделал для меня GigaChat. Интересно, кстати, что пока он схалтурил: решил не делать настоящую конвертацию кода. Но при этом сам момент, что надо обрабатывать UTF-8, уже приводит к возникновению некорректного C++ кода.

....
// Вспомогательная функция для преобразования
// char-вектора в utf-8 строку
std::string to_utf8(const std::vector<char>& data)
{
  // Для простоты считаем, что вектор представлен в UTF-8 изначально
  return { data.begin(), data.end() };
}
....
// Главная функция для разделения строки на токены
std::vector<std::string_view>
  tokenize_string_giga(const std::vector<char>& input_data)
{
  std::string text = to_utf8(input_data);

  std::vector<std::string_view> result;

  size_t pos = 0;
  while (pos < text.size())
  {
    if (is_letter(text[pos]) || is_digit(text[pos]))
    {
      size_t begin_pos = pos++;

      // ищем конец текущего набора алфавитно-цифровых символов
      while (pos < text.size() &&
             (is_letter(text[pos]) || is_digit(text[pos])))
        ++pos;

      // Извлекаем полное слово
      std::string_view current_word =
        text.substr(begin_pos, pos - begin_pos);

      // Дробим слово на отдельные токены
      split_word_into_tokens(current_word, result);
    }
    else
    {
      ++pos; // пропускаем неалфавитно-цифровые символы
    }
  }

  return result;
}

Ошибка связана со временем жизни объекта. Обратите внимание на фрагмент, где извлекаются слова:

std::string_view current_word = text.substr(begin_pos, pos - begin_pos);

Функция substr создаёт временный объект типа std::string, который затем разрушается. В результате в current_word сохраняются указатели на уже разрушенный объект.

Естественно, я попробовал запустить PVS-Studio. Он выявляет эту ошибку следующим предупреждением: V1017 [CWE-416] Variable of the 'string_view' type references a temporary object which will be removed after evaluation of an expression. Tokenizer_giga.cpp 79

Что интересно, приблизительно на том же споткнулся и DeepSeek. Он сгенерировал больше кода, так как не поленился повозиться с UTF-8, поэтому приведу здесь сразу выжимку:

std::vector<std::string_view>
  tokenize_string(const std::vector<char>& buffer)
{
  std::vector<std::string_view> tokens;
  ....
  std::string utf8_text = detect_and_convert_to_utf8(buffer);
  ....
  std::string_view token(utf8_text.data() + token_start, pos - token_start);
  ....
  tokens.push_back(token);
  ....
  return tokens;
}

В функции создаётся локальная переменная utf8_text типа std::string. Её разбивают на токены и записывают указатели на них в выходной массив tokens. Естественно, после выхода из функции переменная utf8_text уничтожается и ссылки становятся невалидными. К сожалению, здесь PVS-Studio пока помочь не смог: у него не получилось сопоставить время жизни utf8_text и tokens.

Подножка для AI в виде UTF-8. Часть 3 из 3: осмысление

Было интересно наблюдать, как повышение сложности задачи привело к сбою в сгенерированном коде.

Наверное, нет одной причины, почему так получается, и влияние следующих моментов суммируется:

1. Более обобщённая, и, следовательно, менее чёткая постановка задачи.

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

3. Класс std::string_view относительно молодой (C++17), и ещё создан не такой огромный объём кода с его участием, как, например, с std::string.

4. Возможно, концепция времени жизни объектов сложна для обучения.

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

В противном случае остаётся или генерировать код, меняя формулировки, пока он не заработает, или самому делать обзор кода. Оба сценария так себе. Конечно, статический анализ не панацея, но если он поможет быстрее исправить ошибку, то замечательно. Собственно, так всегда и было :) В этом его суть.

P.S. Приглашаю в комментариях делится своими подобными случаями.

РБПО-065. Процесс 20 — Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения

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

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

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

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

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

Также процесс предписывает обеспечить возможность проверки целостности ПО (5.20.2.3-5.20.2.4):

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

Речь идёт о подписи в исполняемых файлах и/или контрольных суммах, которые можно проверить.

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

1. Мазеин Михаил. Задача готова! Или нет? Definition of Done и зачем он нужен.
2. Что такое приёмочное тестирование?
3. Wikipedia. Подпись исполняемого кода.
4. Автоматизация подписи кода в современных условиях.
5. УБИ.145: Угроза пропуска проверки целостности программного обеспечения.

РБПО-066. Процесс 21 — Безопасная поставка программного обеспечения пользователям

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

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

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

Например, меры защитят от того, чтобы кто-то в компании подменил дистрибутив. Это реализуется за счёт того, что:

• в регламенте прописаны обязанности и роли сотрудников. На основе этого будет построена политика прав доступа к хранилищам дистрибутивов;
• пользователям должна быть предоставлена процедура проверки подлинности ПО (обновлений ПО).

Описание 21-го процесса, пожалуй, получится самым коротким. Не знаю, что интересного про него написать, а просто пересказывать требования и артефакты не вижу смысла. Тогда уж лучше сразу ГОСТ смотреть. В Интернете по этой теме тоже ничего не находится. Странно даже. Попадаются статьи про "безопасные цепочки поставок", но это относится к 16 и 17 процессу.

Постараемся найти кого-то для цикла "РБПО за 25 вебинаров", кто раскроет эту тему. Иначе придётся импровизировать :)

P.S. Кстати, сегодня будет "Процесс 13. Обеспечение безопасности сборочной среды программного обеспечения". 16:00 по МСК.