Идею предложили, которую дописал выше в «P.S.»: тем, кто пришлёт пример вайб-кодинг бага, который понравится, отправлю в подарок бумажную книгу 📘 про неопределённое поведение.
👍1
РБПО-058. Процесс 13 — Обеспечение безопасности сборочной среды программного обеспечения
Цели 13-го процесса ГОСТ Р 56939-2024:
Это отчасти схоже с процессом 12, но только здесь не про сборку ПО, а про среду/инфраструктуру сборки в целом. Речь про предотвращение проблем, связанных с неожиданным изменением этой среды, или использование каких-то опасных инструментов/компонентов.
Для этого требуется в первую очередь:
1. Утвердить права доступа к среде сборки ПО и хранилищу результатов сборки ПО. Такие образом снижаются риски воздействия/подмены дистрибутива изнутри компании;
2. Обеспечивать регистрацию всех выполняемых действий при сборке ПО в журналах аудита. Также должны быть прописаны сроки хранения этих журналов;
3. Результаты сборки ПО должны помещаться в выделенное хранилище;
4. Если проект этого требует, обеспечивать возможность повторяемости сборки ПО;
5. Обеспечивать защиту каналов связи с внешними источниками данных для обеспечения конфиденциальности информации, обрабатываемой в сборочной среде.
Требуется также разработать схематическое изображение сборочной среды (серверы, узлы, контейнеры, связи, позволяющие отследить порядок сборочных действий, компоненты сборочной среды, инструменты статического анализа и т.д.). Рекомендуется использовать UML, IDEF, С4.
В целом польза такой схемы мне понятна. Она поможет понять новым сотрудникам и тем, кто занят аудитом, как в целом устроена среда сборки. Однако, видимо, откликается мой личный опыт времён обучения в университете, где IDEF в курсовых использовался просто потому, что он должен там быть :) Я к тому, что надо постараться, чтобы такая созданная схема была действительно полезна, а не просто нарисована. Что будет отличать одно от другого, к сожалению, затрудняюсь подсказать.
Когда писал этот пост, думал, пойду посмотрю, что поисковики выдают по запросу "обеспечение безопасности сборочной среды программного обеспечения". К сожалению, ничего толкового. Так что в этот раз не смогу привести какие-то полезные ссылки. Регламенты и другие артефакты придётся реализовывать из собственных представлений и на основании советов, которые могут дать испытательные лабораторий.
Кстати, раз речь зашла про испытательные лаборатории и их роль в подготовке к сертификации, напоминаю, что недавно был вот такой подкаст: Процесс сертификации в системе ФСТЭК России — взгляд со стороны участников.
Цели 13-го процесса ГОСТ Р 56939-2024:
Обеспечение безопасности при сборке ПО, недопущение привнесения в результаты сборки ПО уязвимостей и ошибок со стороны сборочной среды.
Это отчасти схоже с процессом 12, но только здесь не про сборку ПО, а про среду/инфраструктуру сборки в целом. Речь про предотвращение проблем, связанных с неожиданным изменением этой среды, или использование каких-то опасных инструментов/компонентов.
Для этого требуется в первую очередь:
1. Утвердить права доступа к среде сборки ПО и хранилищу результатов сборки ПО. Такие образом снижаются риски воздействия/подмены дистрибутива изнутри компании;
2. Обеспечивать регистрацию всех выполняемых действий при сборке ПО в журналах аудита. Также должны быть прописаны сроки хранения этих журналов;
3. Результаты сборки ПО должны помещаться в выделенное хранилище;
4. Если проект этого требует, обеспечивать возможность повторяемости сборки ПО;
5. Обеспечивать защиту каналов связи с внешними источниками данных для обеспечения конфиденциальности информации, обрабатываемой в сборочной среде.
Требуется также разработать схематическое изображение сборочной среды (серверы, узлы, контейнеры, связи, позволяющие отследить порядок сборочных действий, компоненты сборочной среды, инструменты статического анализа и т.д.). Рекомендуется использовать UML, IDEF, С4.
В целом польза такой схемы мне понятна. Она поможет понять новым сотрудникам и тем, кто занят аудитом, как в целом устроена среда сборки. Однако, видимо, откликается мой личный опыт времён обучения в университете, где IDEF в курсовых использовался просто потому, что он должен там быть :) Я к тому, что надо постараться, чтобы такая созданная схема была действительно полезна, а не просто нарисована. Что будет отличать одно от другого, к сожалению, затрудняюсь подсказать.
Когда писал этот пост, думал, пойду посмотрю, что поисковики выдают по запросу "обеспечение безопасности сборочной среды программного обеспечения". К сожалению, ничего толкового. Так что в этот раз не смогу привести какие-то полезные ссылки. Регламенты и другие артефакты придётся реализовывать из собственных представлений и на основании советов, которые могут дать испытательные лабораторий.
Кстати, раз речь зашла про испытательные лаборатории и их роль в подготовке к сертификации, напоминаю, что недавно был вот такой подкаст: Процесс сертификации в системе ФСТЭК России — взгляд со стороны участников.
О проблематике, что динамический анализ — это широкое понятие (см. РБПО-056), хорошо написано в статье «Многоликий динамический анализ» Дмитрия Пономарёва. Статья опубликована BIS Journal N3 (58) 2025. Кстати, этот номер как раз посвящён динамическому анализу.
👍1
РБПО-059. Процесс 14 — Управление доступом и контроль целостности кода при разработке программного обеспечения
Цели 14-го процесса ГОСТ Р 56939-2024:
Другими словами, это процесс наведения порядка в плане того, кто и что может делать с кодом. Во-первых, это снижает риск внедрения человеком закладок в код, с которым он, по идее, и не должен был работать. Во-вторых, это в целом повод навести порядок: кто за что отвечает, как код резервно копируется и т.д. Всё это должно быть оформлено в виде регламента и внедрено на практике.
В том числе это и про систему контроля версий и правила работы с ней. Причём, выбирая систему контроля версий, теперь стоит учитывать, кто её разрабатывает. Рационально отдавать предпочтением отечественным разработкам, например, 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. Контроль целостности кода функций.
Цели 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 новый вызовов для статических анализаторов - вайб кодинг. Вот прям чувствуется есть интерес :) Надо развить эту тему :)
👍3
Запись "Статический анализ исходного кода" из цикла "Вокруг РБПО за 25 вебинаров". Это десятый процесс ГОСТ Р 56939-2024.
Этот вебинар прошёл без приглашённых экспертов, что не помешало ему занять 4 часа. Сразу ясно про что мы любим поговорить :)
Однако это не всё. Мы готовы провести дополнительный вебинар про статический анализ, чтобы познакомить подписчиков с другими инструментальными средствами. Приглашаю заинтересованных вендоров статических анализаторов написать нам и принять участие в вебинаре. Можно сделать теоретический доклад и/или рассказать про своё решение (доклад на 30-60 минут).
Этот вебинар прошёл без приглашённых экспертов, что не помешало ему занять 4 часа. Сразу ясно про что мы любим поговорить :)
Однако это не всё. Мы готовы провести дополнительный вебинар про статический анализ, чтобы познакомить подписчиков с другими инструментальными средствами. Приглашаю заинтересованных вендоров статических анализаторов написать нам и принять участие в вебинаре. Можно сделать теоретический доклад и/или рассказать про своё решение (доклад на 30-60 минут).
PVS-Studio
Вебинар 10. Статический анализ исходного кода
Эксперт PVS-Studio Глеб Асламов выступил с подробным разбором десятого процесса — «Статический анализ исходного кода». На вебинаре были детально рассмотрены возможности инструментов статического анализа, их применение и преимущества. Особое внимание уделили…
🔥6
РБПО-060. Процесс 15 — Обеспечение безопасности используемых секретов
Цели 15-го процесса ГОСТ Р 56939-2024:
Что-то является секретом, а что не очень — зависит от проекта и подхода к разработке. Например, хранить что-то просто в открытом виде в файлах, работа над которыми ведётся в закрытом контуре, скорее всего, более безопасно, чем если они хранятся на внешних ресурсах. Но это не точно :) Всё зависит от многих "если". Собственно, поэтому в стандарте есть примечание:
Выявлять "лежащие, где не надо" секреты можно, во-первых, внутренним аудитом. Во-вторых, стандарт рекомендует регулярно применять для этого средства статического или композиционного анализа.
Впрочем, абстрактный статический анализатор из коробки вряд ли сильно будет полезен, так как он не знает про особенности вашего проекта, что для вас является секретами и как они выглядят. Есть смысл дополнительно написать собственный мини-анализатор, который по шаблону ищет чувствительные для вас структуры данных.
Ещё на тему инструментария поиска секретов загляните сюда: AppSec Каталог - Secret Scanning.
Примером простых систем для решения части задач являются всем знакомые утилиты хранения паролей, такие как KeePass. Про комплексные решения можно легко найти информацию в Интернете. Статьям в духе "10 лучших программ для управления секретами" я не очень доверяю, так что лучше сами :) Для начала можно заглянуть сюда:
1. Обзор StarVault 1.2, системы управления секретами и защиты доступа.
2. Как управлять секретами, чтобы избежать утечки данных.
3. Управление секретами: путь от Opensource до Enterprise.
4. Управление секретами в РФ: Обзор российских сервисов для безопасного хранения API-ключей и паролей.
Цели 15-го процесса ГОСТ Р 56939-2024:
Обеспечение безопасного использования секретов.
Примечание — В данном подразделе под секретами понимаются данные в любом виде, которые могутиспользоваться для обеспечения аутентификации и/или целостности и/или конфиденциальности информации (пароли, цифровые сертификаты и т. п.), в том числе путем применения в соответствии с законодательством Российской Федерации средств криптографической защиты информации или иными методами.
Что-то является секретом, а что не очень — зависит от проекта и подхода к разработке. Например, хранить что-то просто в открытом виде в файлах, работа над которыми ведётся в закрытом контуре, скорее всего, более безопасно, чем если они хранятся на внешних ресурсах. Но это не точно :) Всё зависит от многих "если". Собственно, поэтому в стандарте есть примечание:
Требования к реализации, изложенные в данном подразделе, применяются пользователями стандарта по их усмотрению и в необходимых им объемах.
Выявлять "лежащие, где не надо" секреты можно, во-первых, внутренним аудитом. Во-вторых, стандарт рекомендует регулярно применять для этого средства статического или композиционного анализа.
Впрочем, абстрактный статический анализатор из коробки вряд ли сильно будет полезен, так как он не знает про особенности вашего проекта, что для вас является секретами и как они выглядят. Есть смысл дополнительно написать собственный мини-анализатор, который по шаблону ищет чувствительные для вас структуры данных.
Ещё на тему инструментария поиска секретов загляните сюда: AppSec Каталог - Secret Scanning.
Для хранения, управления и предоставления секретов использовать систему управления секретами.
Примером простых систем для решения части задач являются всем знакомые утилиты хранения паролей, такие как KeePass. Про комплексные решения можно легко найти информацию в Интернете. Статьям в духе "10 лучших программ для управления секретами" я не очень доверяю, так что лучше сами :) Для начала можно заглянуть сюда:
1. Обзор StarVault 1.2, системы управления секретами и защиты доступа.
2. Как управлять секретами, чтобы избежать утечки данных.
3. Управление секретами: путь от Opensource до Enterprise.
4. Управление секретами в РФ: Обзор российских сервисов для безопасного хранения API-ключей и паролей.
👍3
Для разнообразия о GameDev. Приглашаю к прочтению статьи "Я отклоняю комиты с использованием кучи и прошу коллег переписать такую логику" и приглашаю 25 сентября на вебинар про оптимизацию игр.
Хабр
Я отклоняю комиты с использованием кучи и прошу коллег переписать такую логику
Хочу поделиться своим опытом разработки крупных игровых проектов на C++, где производительность и стабильность — это не просто приятные бонусы, а абсолютно естественные требования к разработке. За...
🔥3👍1😐1
РБПО-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).
Англоязычное название и сокращение — 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).
👍1
Запись "Динамический анализ кода программы" из цикла "Вокруг РБПО за 25 вебинаров". Это одиннадцатый процесс ГОСТ Р 56939-2024. Приглашённые эксперты: Евгений Дужак (компания "СВД Встраиваемые системы"), Никита Чуманов и Артём Ежов (Центра сертификации АО «НПО «Эшелон»).
PVS-Studio
Вебинар 11. Динамический анализ кода программы
На одиннадцатом вебинаре цикла эксперты Центра сертификации АО «НПО «Эшелон» — Никита Чуманов и Артём Ежов, а также руководитель группы разработки СЗИ компании «СВД Встраиваемые системы» Евгений Дужак поделились профессиональными знаниями и практическим опытом…
👍1
РБПО-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-аккаунтов и раскрыла тысячи секретов.
Цели 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 (конференция по тестированию программного обеспечения не только для тестировщиков).
Цели 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 стр. Программа и регистрация на сайте мероприятия.
Завтра (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 стр. Программа и регистрация на сайте мероприятия.
👏1
Компетенция: теория разработки безопасного ПО (РБПО)
В нашей компании ООО "ПВС" существует матрица компетенций, на основании которой сотрудники проходят различные обучения, получают навыки и получают баллы для движения по сетке грейдов. Нам полезно развивать сотрудников, чтобы они лучше понимали суть РБПО, могли использовать некоторые подходы в работе, проводили доклады/вебинары на эту тему и т.д. Поэтому мы решили выделить и оформить сходную компетенцию, которую смогут получить заинтересованные сотрудники. Началом этого процесса стало составление списка полезных для нас материалов по теме РБПО. Всё это внутренняя кухня, однако сам список достаточно интересный и может быть полезен широкому кругу разработчиков и менеджеров. Поэтому мы решили опубликовать список ссылок на выбранные нами материалы в виде этой статьи.
В нашей компании ООО "ПВС" существует матрица компетенций, на основании которой сотрудники проходят различные обучения, получают навыки и получают баллы для движения по сетке грейдов. Нам полезно развивать сотрудников, чтобы они лучше понимали суть РБПО, могли использовать некоторые подходы в работе, проводили доклады/вебинары на эту тему и т.д. Поэтому мы решили выделить и оформить сходную компетенцию, которую смогут получить заинтересованные сотрудники. Началом этого процесса стало составление списка полезных для нас материалов по теме РБПО. Всё это внутренняя кухня, однако сам список достаточно интересный и может быть полезен широкому кругу разработчиков и менеджеров. Поэтому мы решили опубликовать список ссылок на выбранные нами материалы в виде этой статьи.
PVS-Studio
Компетенция: теория разработки безопасного ПО (РБПО)
В нашей компании ООО ПВС существует матрица компетенций, на основании которой сотрудники проходят различные обучения, получают навыки и получают баллы для движения по сетке грейдов. Нам полезно...
👍3
Бестиарий программирования pinned «Компетенция: теория разработки безопасного ПО (РБПО) В нашей компании ООО "ПВС" существует матрица компетенций, на основании которой сотрудники проходят различные обучения, получают навыки и получают баллы для движения по сетке грейдов. Нам полезно развивать…»
Здесь что-то тема не пошла. Пробую на Хабре: https://habr.com/ru/companies/pvs-studio/articles/950552/ Но пока что-то и там тихо :(
Хабр
Команда PVS-Studio просит присылать примеры ошибок, связанные с использованием вайб-кодинга
PVS-Studio, Вайб-кодинг Есть две школы мысли. Первая — это директора, HR-ы и "эффективные менеджеры", которые уже планируют сокращения IT-отделов. Они искренне верят, что ChatGPT скоро будет писать...
🔥3👍1👏1
Запись "Использование безопасной системы сборки программного обеспечения" из цикла "Вокруг РБПО за 25 вебинаров". Это 12-й процесс ГОСТ Р 56939-2024.
Приглашённые эксперты: Игорь Хмелев (АО «НПО «Эшелон») и Алексей Захаров (Axiom JDK).
В ходе вебинара Алексей упоминал совместную статью. Вот она: "Безопасность приложений: инструменты и практики для Java-разработчиков".
Приглашённые эксперты: Игорь Хмелев (АО «НПО «Эшелон») и Алексей Захаров (Axiom JDK).
В ходе вебинара Алексей упоминал совместную статью. Вот она: "Безопасность приложений: инструменты и практики для Java-разработчиков".
PVS-Studio
Вебинар 12. Использование безопасной системы сборки программного обеспечения
В рамках двенадцатого вебинара цикла специалисты Игорь Хмелев (АО «НПО «Эшелон») и Алексей Захаров (Axiom JDK) представили анализ темы использования безопасной системы сборки программного обеспечения, основанный на практических кейсах и профессиональном опыте.
🏆3👍1🔥1👏1
РБПО-064. Процесс 19 — Нефункциональное тестирование
Цели 19-го процесса ГОСТ Р 56939-2024:
Можно сказать так: функциональное тестирование проверяет, что ПО делает то, что должно делать. А нефункциональное проверяет:
1) как работает приложение в том числе в нестандартных условиях. Например, не генерирует ли приложение избыточно большие файлы логирования. И как оно будет себя вести, если из-за этих файлов исчерпается дисковое пространство.
2) ПО не делает того, что не должно делать. Т.е. программа случайно или преднамеренно не содержит недекларированные возможности (НДВ).
В рассматриваемом разделе под нефункциональным тестированием понимаются следующие проверки:
Дополнительные ссылки:
1. QA_Bible. Нефункциональное тестирование (Non-Functional testing).
2. Ttestengineer ru. Нефункциональное тестирование — гайд.
3. Нефункциональные проверки при тестировании мобильных приложений.
4. Wikipedia. Non-functional testing.
5. Алексей Симкин. Гайд по тестированию локализации и интернационализации, а также большой и полезный checklist.
Цели 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 — поговорили о тонкостях работы с памятью, кастомных аллокаторах, а также способах ускорить запуск мобильных игр.
🔥4
Подножка для AI в виде UTF-8. Часть 1 из 3: предисловие
Публикую своё наблюдение в преддверии подкаста Ever Secure на тему "Любимые грабли программистов, и станет ли вайб-кодинг спасением или новым проклятием". Решил разместить здесь пример, который я, скорее всего, упомяну в подкасте. На слух может быть сложно понять суть бага, поэтому код для наглядности не помешает.
Я немного экспериментировал с генерацией кода с помощью GigaChat и DeepSeek. Это не рабочие задачи и не полноценное исследование. Мне просто было интересно найти примеры пересечения некой грани сложности при решении задачи, после которой начинаются проблемы с генерацией C++ кода.
Если просить сгенерировать код уровня лабораторных и даже, наверное, некоторых курсовых работ, то проблем нет. Великолепно получается код сортировки массива или код подсчёта количества единичных бит в массиве байт. Причём для подсчёта единичных бит предлагаются такие интересные оптимизированные по скорости решения, про которые я даже не знал, хотя и читал давно в книге про различные подходы к этой задаче.
Кстати, здесь вырисовывается потенциальная проблема при обучении программированию: слишком велик соблазн сразу получить ответ, так и не разобравшись, как всё работает. Видимо, придётся обратно возвращаться к написанию кода на бумаге :) Но сейчас не будем углубляться в эту тему.
Для одного из экспериментов я выбрал создание программы, которая будет читать файлы с исходным кодом и выполнять ряд операций над названиями переменных или их составными частями. Одна из задач — это получить из имени переменной RedColor три токена: RedColor, Red и Color.
Думаю, задача разбития на токены часто встречается в программировании, и существует много открытого кода на эту тему. Поэтому в такой постановке GigaChat и DeepSeek с этой задачей справляются хорошо.
Однако мир сложнее, и нужно работать не просто со стандартной ANSI кодировкой, но и, например, с UTF-8. Поэтому я начал просить писать код, обрабатывающий файлы в том числе в формате UTF-8. И в этот момент генераторы кода поплыли.
Полагаю, количество открытого кода, учитывающего кодировки, в том числе и UTF-8, в несколько раз меньше. Дополнительно мои формулировки задания стали сложнее и от этого расплывчатее. Кстати, за пару подходов у меня не получилось добиться работающего кода. Думаю, это можно сделать, проведя ещё несколько генераций с уточнениями задания. Но у меня нет цели написать конечную программу и мне интересно экспериментировать именно со сбоями :)
Публикую своё наблюдение в преддверии подкаста Ever Secure на тему "Любимые грабли программистов, и станет ли вайб-кодинг спасением или новым проклятием". Решил разместить здесь пример, который я, скорее всего, упомяну в подкасте. На слух может быть сложно понять суть бага, поэтому код для наглядности не помешает.
Я немного экспериментировал с генерацией кода с помощью GigaChat и DeepSeek. Это не рабочие задачи и не полноценное исследование. Мне просто было интересно найти примеры пересечения некой грани сложности при решении задачи, после которой начинаются проблемы с генерацией C++ кода.
Если просить сгенерировать код уровня лабораторных и даже, наверное, некоторых курсовых работ, то проблем нет. Великолепно получается код сортировки массива или код подсчёта количества единичных бит в массиве байт. Причём для подсчёта единичных бит предлагаются такие интересные оптимизированные по скорости решения, про которые я даже не знал, хотя и читал давно в книге про различные подходы к этой задаче.
Кстати, здесь вырисовывается потенциальная проблема при обучении программированию: слишком велик соблазн сразу получить ответ, так и не разобравшись, как всё работает. Видимо, придётся обратно возвращаться к написанию кода на бумаге :) Но сейчас не будем углубляться в эту тему.
Для одного из экспериментов я выбрал создание программы, которая будет читать файлы с исходным кодом и выполнять ряд операций над названиями переменных или их составными частями. Одна из задач — это получить из имени переменной RedColor три токена: RedColor, Red и Color.
Думаю, задача разбития на токены часто встречается в программировании, и существует много открытого кода на эту тему. Поэтому в такой постановке GigaChat и DeepSeek с этой задачей справляются хорошо.
Однако мир сложнее, и нужно работать не просто со стандартной ANSI кодировкой, но и, например, с UTF-8. Поэтому я начал просить писать код, обрабатывающий файлы в том числе в формате UTF-8. И в этот момент генераторы кода поплыли.
Полагаю, количество открытого кода, учитывающего кодировки, в том числе и UTF-8, в несколько раз меньше. Дополнительно мои формулировки задания стали сложнее и от этого расплывчатее. Кстати, за пару подходов у меня не получилось добиться работающего кода. Думаю, это можно сделать, проведя ещё несколько генераций с уточнениями задания. Но у меня нет цели написать конечную программу и мне интересно экспериментировать именно со сбоями :)
🔥4