Продолжение
— «Сначала заявка во ФСТЭК с РБПО, потом в лабораторию, органы и т.д». Нет. Нет. Это неправильно. В 55-м положении четко прописано сейчас в обновлении, что заявку во ФСТЭК подают заявители с испытательной лаборатории. Более того, в заявке стоят две подписи. Подпись разработчика заявителя и начальника испытательной лаборатории. Для чего это ФСТЭК сделал?

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

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

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

— Только после этого уже там подключаются все остальные участники, потому что у нас участников 4, минимум 4. Это заявитель, это федеральный орган ФСТЭК, это испытательные лаборатория и это назначенный орган сертификации. Вот эти четыре участника процесса, сертификации и следовательской информации, они у нас прописаны в явном виде в положении сертификации в 55-м приказе.

И для примера ещё один фрагмент обсуждений

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

РБПО-041. Процесс 6 — Разработка, уточнение и анализ архитектуры программного обеспечения
Цели шестого процесса по ГОСТ Р 56939-2024:

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

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

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

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

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

1. Проектируя ГИС, следует сразу ознакомиться с приказом ФСТЭК 117. Он вступит в силу 1 марта 2026 года, но прочитать его стоит уже сейчас.

2. Создавая ПО для встраиваемых систем, стоит сразу заглянуть в ГОСТ Р 51904-2002. Программное обеспечение встроенных систем. Общие требования к разработке и документированию.

3. Не забыть про какую-то из угроз поможет ГОСТ Р 58412-2019. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.

4. Описать архитектуру и другие сущности поможет ГОСТ Р 58609-2019. Состав и содержание информационных элементов жизненного цикла (документации). См. раздел 10.74 — Описание архитектуры программного продукта.

5. И так далее в зависимости от типа проекта.

РБПО-042. Процесс 7 — Моделирование угроз и разработка описания поверхности атаки (часть 1/3)
Описание термина поверхность атаки см. здесь. Цели седьмого процесса по ГОСТ Р 56939-2024:

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

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

При построении этого процесса важным руководствующим документом является уже упомянутый в предыдущем посте ГОСТ Р 58412-2019: Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.

Собственно, ГОСТ Р 56939-2024 прямо на него ссылается в примечании к п.5.7.3.1:

При составлении перечня угроз безопасности и их описания рекомендуется учитывать положения ГОСТ Р 58412, а также угрозы безопасности информации Банка данных угроз безопасности информации ФСТЭК России, других источников (например, методологии STRIDE, Open Web Application Security Project (OWASP), DREAD и пр.). В модели угроз рекомендуется указывать использованную при моделировании методологию, в том числе в случае ее собственной разработки.

Зачем определять поверхности атаки? Давайте просто всё защищать, проверять и тестировать... В том-то дело, что так не получится, так как ресурсы и время ограничены. Современные программные системы содержат огромные объёмы собственного и стороннего кода. Просто невозможно и избыточно педантично изучать и проверить весь код. Необходимо выделить функции/модули, которые взаимодействуют с внешним миром и, скорее всего, будут подвергаться атаке. На них и следует сосредоточиться в первую очередь с точки зрения противостояния угрозам и более тщательного анализа/проверки/тестирования.

Ссылки по теме:
1. Павел Довгалюк. Зачем искать поверхность атаки для своего проекта.
2. SafeCode 2024. Павел Довгалюк – Анализ поверхности атаки приложений и программных систем.
3. Сигалов Даниил. Диссертация. Методы выявления поверхности атаки веб-приложений при помощи анализа клиентского JavaScript-кода.
4. OWASP. What is Attack Surface Analysis and Why is it Important.

РБПО-043. Процесс 7 — Моделирование угроз и разработка описания поверхности атаки (часть 2/3)
Каковы основные способы определения поверхности атаки?

Привлечение эксперта. Тут, думаю, всё понятно. Эксперты изучают архитектуру проекта, код, используемые библиотеки и указывают на наиболее вероятные точки будущих атак. Эксперты не смогут внимательно просмотреть миллионы строк кода, но зато смогут подсветить высокоуровневые проблемы.

Статический анализ кода. Его перечисляют как один из методов поиска поверхности атаки, но это не совсем верно. Инструменты статического анализа занимаются собственно поиском проблем на поверхности атаки. Это требует развёрнутого пояснения, которое я вынесу в следующий пост.

Инструменты поиска точек входа:
1. Attack Surface Analyzer;
2. Nikto web server scanner.

Динамический анализ кода. Основным представителем является инструмент Natch, разработанный в ИСП РАН:
1. Павел Довгалюк. Как найти поверхность атаки незнакомых приложений с помощью Natch.
2. Павел Довгалюк. Разглядываем CodeScoring с помощью Natch.
3. SafeCode. Иван Васильев – Пример практического использования Natch для анализа.

В начале не понял, а потом как понял! :)))

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

Это четвёртый процесс в ГОСТ Р 56939-2024. Пара примечаний к тому, что обсуждалось на встрече.

Мой коллега Глеб немного рассказал, как у нас происходит подготовка окружения и выпуск новых релизов, но как-то выпало, собственно, как мы их именуем и управляем разными версиями. Причина в том, что именно этот момент у нас устроен очень просто. У нас один продукт — PVS-Studio — в одном варианте исполнения. Мы просто выпускаем новую версию каждые два месяца, меняя её номер :)

У нас одна сборка для всех вариантов использования: Team, Enterprise, триальная версия, бесплатная версия для открытых проектов. Отличается только вводимый лицензионный ключ. Мы храним и выдаём по необходимости предыдущие версии дистрибутива или бета-версию с исправленной ошибкой. Но это всё непрерывная череда версий одной линии программного кода.

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

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

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

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

P.S. Давно не предлагал скачать и попробовать PVS-Studio. Хороший момент. От меня промокод firefly для получения лицензии на 1 месяц. Скачать и попробовать.

Методическая рекомендация № 2025-07-011 | Уровень критичности: 3

Область: Инструментальный анализ

Тип недостатка: Необоснованный выбор инструментов, в том числе инструментов статического анализа исходного кода, для выстраивания и выполнения процессов РБПО.

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

- инструменты должны быть открытыми, либо отечественной разработки, обеспечивающие реализацию требований ФСТЭК России и национальных стандартов

- инструменты должны удовлетворять частным техническим требованиям, если они заданы ФСТЭК России (например, требованиям Методики ВУ и НДВ ФСТЭК России к статическим анализаторам исходного кода, написанного на ЯП высокого уровня)

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

Также при сертификации процессов безопасной разработки контролируется использование организацией инструмента (-ов) статического анализа, соответствующего требованиям ГОСТ Р 71207-2024.

В указанном ГОСТ приведены как требованиям к методам статического анализа, так и алгоритм выбора и конфигурирования инструмента, алгоритм проверки соответствия инструмента требованиям ГОСТ, а также базовые численные критерии.

В настоящий момент под патронажем ФСТЭК России проводятся публичные испытания статических анализаторов (для 6 ЯП). В рамках данных испытаний создаются как публичная база тестов, так и методология оценки соответствия инструментов требованиям ГОСТ. Данная методология будет являться опорной (либо - прототипом, для инструментов статического анализа иных ЯП) для проверки соответствия тех или иных инструментов статического анализа требованиям ГОСТ.

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

Рекомендации:

- ознакомиться с требованиям ГОСТ к инструментам и методологией оценки соответствия инструментов этим требованиям

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

Дополнительные информационные материалы:

- ответ представителя ФСТЭК России на вопрос о наличии требования сертифицированности инструментов

- ГОСТ Р 71207-2024 "Статический анализ программного обеспечения"

- пресс-релиз о ходе испытаний статических анализаторов под патронажем ФСТЭК России

РБПО-044. Процесс 7 — Моделирование угроз и разработка описания поверхности атаки (часть 3/3)

Рассмотрим применение статических анализаторов кода вообще и PVS-Studio в частности с точки зрения выявления поверхности атаки.

Многие статические анализаторы умеют выполнять Taint-анализ для выявления проблемы использования недостоверных данных. В терминологии ГОСТ Р 71207-2024 это называется анализ помеченных данных (п.3.1.3):

Статический анализ, при котором анализируется течение потока данных от источников до стоков.
Примечание.
1) Под источниками понимаются точки программы, в которых данные начинают иметь пометку — некоторое заданное свойство. Под стоками понимаются точки программы, в которых данные перестают иметь пометку.
2) Распространённая цель анализа помеченных данных — показать, что помеченные данные не могут попасть из источников — точек ввода пользователя в стоки — процедуры записи на диск или в сеть. Факт такого попадания означает утечку конфиденциальных данных.

Taint-анализ помогает выявлять код, неустойчивый к XSS-атакам (межсайтовый скриптинг), XEE-атакам (billion laughs attack), XXE-атакам (XML External Entity) и т.д.

Чтобы выявить поступление недостоверных данных и их небезопасную обработку, анализатор должен заранее знать, собственно, откуда они могут поступить и что такое небезопасная обработка. Для этого разработчики анализаторов закладывают в анализаторы соответствующую информацию о функциях стандартных и наиболее часто используемых библиотек. Например, что функция fread читает внешние данные, а fwrite записывает их вовне.

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

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

Поэтому в ГОСТ Р 71207-2024 явно написано (п.7.6):

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

В PVS-Studio, например, реализована эта требуемая стандартом разметка истоков и стоков данных для всех поддерживаемых языков (C, C++, C#, Java).

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

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

Сегодня буду ведущим пятого вебинара. Приглашаю регистрироваться👀

Я всё про РБПО. А ведь PVS-Studio – это не только ценный SAST, но и 3-4 килограмма ценных, легкоусваиваемых детекторов для GameDev проектов. Для разнообразия статья: На защите GameDev'a: статический анализ и Unity.

Сегодня презентуют: OpenIDE — профессиональные инструменты без ограничений. В свою очередь, мы сегодня опубликовали статью про плагин: PVS-Studio доступен в OpenIDE :)

РБПО-045. Процесс 8 — Формирование и поддержание в актуальном состоянии правил кодирования (часть 1/4)

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

5.8.1.1 Обеспечение эффективной и единообразной организации оформления и использования исходного кода в соответствии с предъявляемыми к ПО требованиями.

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

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

Есть сразу несколько причин, почему так происходит:

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

2. Часто приходится сопровождать чужой код, из-за чего бывает трудно найти нужное место и понять, как всё устроено.

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

4. В legacy-проектах можно по аналогии с годичными кольцами деревьев наблюдать изменение в стиле написания кода. Чаще всего это связано с появлением новых версий языка и библиотек. Эта разнородность тоже добавляет сложность к пониманию старых частей проекта.

5. Известно, что с ростом проекта плотность ошибок растёт нелинейно. Т.е. чем больше кода, тем выше вероятность, что при написании или изменении кода будет внесена ошибка. Это объясняется ростом взаимосвязей разных частей проекта, которые сложно учитывать. Рост сложности понимания влияет и на рост процента времени, который приходится тратить человеку прежде чем сделать правку.

6. Думаю, вы и сами сможете добавить пару пунктов к этому списку.

Из сказанного вытекает, что требуется делать код по возможности простым для восприятия (чтения). Также очень важно, чтобы весь код был единообразно оформлен. Если оформление единообразно, то проще прочитать, понять и исправить код коллег.

Это можно достичь, сформировав, приняв и поддерживая в актуальном состоянии правила кодирования. Что, собственно, и описано в пункте 5.8 ГОСТ-а, который мы рассматриваем. Т.е. следует разработать регламент оформления кода и систематически его придерживаться.