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

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

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

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

5.25.2 Требования к реализации
5.25.2.1 Разработать регламент вывода ПО из эксплуатации.
5.25.2.2 Информировать пользователя о планах прекращения технической поддержки ПО (версии ПО) и своевременно уведомлять об этом.

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

Понятно, что для некоторых приложений/сфер этот раздел не очень существенен, а для других наоборот. Например, слышал в каком-то докладе на Kaspersky Certification Day, что вывод ПО из эксплуатации может быть непростым процессом для изделий по линии МО.

Примеры мер, которые может включать вывод ПО из эксплуатации:
1. Выгрузка данных, которые не должны быть утеряны при завершении эксплуатации ПО;
2. Полное удаление (затирание) данных, учётных записей, настроек ПО;
3. Или, наоборот, сбор/архивирование данных с целью использования их в других системах. Шифрование архивов. Создание плана миграции данных;
4. Строгий контроль доступа к архиву (принцип минимальных привилегий);
5. Физическое уничтожение носителей информации;
6. Убедиться, что разработанные процедуры соответствуют требованиям, установленным нормативными документами и ТЗ;
7. Проверить, что соблюдены юридические, нормативные и договорные обязательства по хранению данных;
8. Создание плана коммуникации для уведомления пользователей и заинтересованных сторон;
9. Освобождение ресурсов, например отключение виртуальных машин и серверов (back end);
10. Возможно освобождение доменных имён. Или, наоборот, продление их использования с целью предотвращения захвата этих имён злоумышленниками и распространение через них вредоносного ПО под видом обновлений/новых версий выведенного из эксплуатации ПО.
11. Формирование акта о выводе. Документ, подтверждающий, что все этапы плана выполнены, данные обработаны в соответствии с политиками, а риски сведены к минимуму.

Фёдор Сазонов: зачем нужна новая IDE на IntelliJ Platform? | Подкаст – Разбаговка #2

В новом выпуске поговорили с CEO OpenIDE, Фёдором Сазоновым. Обсудили язык Java, устройство современных инструментов разработки и то, что на самом деле важно, когда создаёшь среду для других программистов.

Документация: Работа PVS-Studio в IntelliJ IDEA и Android Studio и OpenIDE.

Содержание:

- Как ты попал в IT?
- Почему Java?
- Про IT курсы
- Про доклады и IT-конференции
- Каково тебе быть CEO?
- PVS-Studio: В чём проблемы рефлексии в Java?
- Что такое OpenIDE?
- Чем IntelliJ лучше, чем Visual Studio Code?
- JetBrains будет обучать нейросети на нашем коде?
- Какие планы у OpenIDE?
- Про плагины для OpenIDE и маркетплейс
- Есть ли конкуренция между аналогами IDEA?
- Можно ли контрибьютить в OpenIDE?
- Что изменилось в IntelliJ, чтобы получилась OpenIDE?
- Какую IDE используют разработчики OpenIDE?
- Про Visual Studio Code и Eclipse

РБПО-071. Послесловие

На этом я заканчиваю обзор ГОСТ Р 56939-2024. Возможно, я буду постепенно дополнять эту подборку постов, но в целом все процессы кратко рассмотрены. За деталями приглашаю всех на цикл "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024".

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

Приглашаю всех познакомиться с нашим статическим анализатором PVS-Studio, который может закрыть не только 10-й процесс, но будет полезен и в ряде других:

1. Обучение сотрудников (п.5.2). Формирование у программистов понимание антипаттернов и уязвимых конструкций, что улучшает их техническую экспертизу;

2. Моделирование угроз и разработка описания поверхности атаки (п.5.7). Дополняет процесс, выявляя потенциальные уязвимости, которые формируют поверхность атаки;

3. Экспертиза исходного кода (п.5.9). Позволяет усилить проверку стороннего кода, который команда включает в проект. Например, его можно использовать для выбора сторонних библиотек, оценивая качество их кода;

4. Поиск уязвимостей в программном обеспечении при эксплуатации (п.5.24). Можно просматривать ранее отключённые предупреждения PVS-Studio с целью дополнительного выявления дефектов в коде.

PVS-Studio — статический анализатор кода для поиска ошибок и потенциальных уязвимостей.

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

О книге написали. Приятно. Книга «Экскурс в неопределённое поведение C++». Секреты укрощения единорога.

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

Приглашённый эксперт: Роман Байталов – архитектор системных решений в GitFlic.

Примечание. Во время демонстрации работы GitFlic с PVS-Studio часть срабатываний не попала в SARIF-отчёт, потому что при запуске утилиты plog-converter не был указан флаг -a. Без него утилита включает в отчёт только срабатывания диагностических правил общего назначения уровней 1 и 2. Чтобы сохранить все срабатывания из исходного отчёта, нужно передать флагу -a значение ALL. Подробнее о флагах утилиты plog-converter можно прочитать в нашей документации.

Напоминаю про митап "Безопасная разработка в АСУ ТП". Москва, пр-т Мира, 119 строение 461, Москва (павильон «Умный город», ВДНХ). 24.10.2025 (чт) 17:00.

PVS-Studio 7.39: OWASP Top Ten 2021, улучшения в плагине для Visual Studio Code, расширение поддержки MISRA и не только

- Покрытие OWASP Top Ten 2021 Java анализатором
- Запуск анализа в режиме мониторинга компиляции в плагине для Visual Studio Code
- Поддержка генерации отчёта MISRA Compliance для новых версий стандарта MISRA
- Поддержан анализ проектов на основе сборочной системы MSBuild, использующих формат решений SLNF
- Механизм перезаписи более приоритетных настроек для файлов конфигурации диагностик .pvsconfig
- Breaking changes
- Новые диагностические правила

Когда добавляется новое диагностическое правило, это сразу понятно, заметно и есть про что написать. А есть важные, но незаметные работы. Например, недавно мы переписали движок парсинга C и C++ кода. Прошло для мира это почти незаметно, т.к. главной целью, как ни странно, было чтобы ничего не изменилось :). Причина — максимальная совместимость, чтобы свести к минимуму поломки у клиентов.

Сейчас так же тихо для C и C++ начата переделка механизма анализа потока данных. Будем переходить от "исторически сложившихся механизмов" к полноценному IR для вычислений.

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

int get(int a, int b = 7)
{
  return a + 2 - b;
}
    
int main()
{
  int a = 5;
  auto divider = get(a, 1);
  return a / divider;
}

PVS-Studio выдаёт предупреждение: V609 Divide by zero. Denominator 'divider' == 0.

А если вот так, то уже всё хорошо:

int main()
{
  int a = 5;
  auto divider = get(a, 1);
  return a / divider;
}

Вернее, хорошо, что больше нет деления на ноль. Зато выявляется другой дефект: результат деления 5/6 не имеет смысла, так как в результате целочисленного деления всегда будет получаться 0. Про это уже будет другое предупреждение: V1064 The 'a' operand of integer division is less than the 'divider' one. The result will always be zero.

Вы уже знаете, а возможно и нет, что вместе с Центральным университетом мы проводим встречи Клуба С++-разработчиков.

Хочется, чтобы на встречах звучали разнообразные доклады. Поэтому приглашаем докладчиков с C++ темами. Можно рассказать, чем вы занимаетесь, какие необычные задачи решаете на работе, про какие-то особенности языка и т.д.

Приглашаем присылать ваши идеи и темы докладов для обсуждения. Контакт: Волкова Дарья / @daryavolkovaa / volkova@viva64.com

Как это было – предыдущая встреча 4 октября.

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

Приглашённый внешний эксперт: Антон Володченко, руководитель разработки продуктов в CodeScoring.

Сегодня (29.10) в 16:00 состоится вебинар "Использование инструментов композиционного анализа". Если вы хотели что-то узнать про предстоящий ГОСТ на композиционный анализ, то это самое подходящее место и эксперты. Приходите слушать и задавать вопросы.

Приглашённые эксперты:
• Алексей Смирнов, основатель и генеральный директор CodeScoring
• Антон Володченко, руководитель разработки продуктов в CodeScoring

Регистрация на этот и последующие вебинары доступна по ссылке🔗

А вот и запись вебинара "Использование инструментов композиционного анализа".

Коллега нашла редкий интересный вариант ошибки, связанной с макросом. Интересен баг тем, что изначально глядя на код (не прочитав тестовое описание), я не смог его заметить! Хотя глаз у меня натренирован. Более того, мне пришлось дважды прочитать предупреждение анализатора, приведённое в статье, прежде чем я наконец увидел, что же не так.

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

Предупреждение PVS-Studio: V1040 Possible typo in the spelling of a pre-defined macro name. The '__WIN_32__' macro is similar to '__WIN32__'. inet_drv.c 13506

Опечатка. Лишнее подчёркивание в имени макроса. Подробнее про эту и другие интересные ошибки можно прочитать в статье "Наследие кода: разбор С и С++ модулей Erlang, которые работают десятилетиями".

Русский перевод и адаптация OWASP Application Security Verification Standard

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

Пятая версия стандарта верификации требований к безопасности приложений опирается на предыдущие версии ASVS, начиная с первой, вышедшей в 2008 году, и до четвертой, в 2019 году.

После выхода версии ASVS 4.0 в 2019 году и ее незначительного обновления (v4.0.3) в 2021 году, версия 5.0 является значительным шагом вперед — она была модернизирована, чтобы учесть последние достижения в области безопасности программного обеспечения.

ASVS 5.0 стал результатом масштабного вклада руководителей проекта, членов рабочей группы и широкого сообщества OWASP, направленного на обновление и совершенствование этого важного стандарта.

Область действия ASVS
Область действия ASVS определяется его названием: Приложение (Application), Безопасность (Security), Верификация (Verification) и Стандарт (Standard). Он устанавливает, какие требования включены в стандарт, а какие — исключены из него, с глобальной целью определения основополагающих принципов безопасности, которые должны быть достигнуты. Область действия также учитывает требования к документации, которые служат основой для требований к реализации.

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

Приложение
ASVS определяет «Приложение» как разрабатываемый программный продукт, в который должны быть интегрированы механизмы безопасности. ASVS не регламентирует процессы жизненного цикла разработки и не указывает на методы сборки приложения в CI/CD. Его задача — описать требуемый уровень защищённости, который должен быть достигнут в конечном продукте.

Компоненты для обработки HTTP-трафика (WAF, балансировщики нагрузки, прокси) могут считаться частью приложения в контексте безопасности, поскольку некоторые механизмы безопасности напрямую зависят от них или могут быть реализованы с их помощью. Это касается требований по кешированию, rate limiting, а также фильтрации входящих/исходящих подключений по источнику и получателю.

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

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

Безопасность
Каждое требование должно иметь очевидное влияние на безопасность. Отсутствие требования должно привести к снижению уровня защищённости приложения, а реализация требования должна либо уменьшить вероятность возникновения риска безопасности, либо смягчить последствия.

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

Верификация
Требование должно быть верифицируемым, а его проверка должна приводить к однозначному решению: «не выполнено» или «выполнено».

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

PDF RU

Аутсорсинг и приказ ФСТЭК №117, теория РБПО, инструменты (часть 1 из 2)

Аутсорсинговые и аутстаффинговые компании, как правило, сами не выступают инициаторами закупки и внедрения таких инструментов, как анализатор PVS-Studio. Если заказчик говорит им использовать статический анализатор при разработке, то они используют. Если не говорит, то не используют. Это ни хорошо ни плохо, просто решает конкретные поставленные и оплаченные задачи.

Однако в 2026 году, когда заказчик придёт за разработкой безопасного ПО (РБПО), не получится сказать: "Да, с завтрашнего дня у нас все специалисты по РБПО и внедрены новые процессы".

Культура РБПО требует обучение сотрудников, владение определёнными инструментарием. А для этого инструменты надо использовать на практике какое-то время. Нужны разработанные регламенты, распределены роли и т.д. Ко всему этому надо готовится заранее. Это сложно и требует предварительных вложений, но зато может стать вашим конкурентным преимуществом при выборе исполнителя заказчиком.

Какие предпосылки к запросу на РБПО?

Приказ ФСТЭК России от 11.04.2025 №117 — "Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений". Приказ вступает в силу с 1 марта 2026 г.

Процитирую фрагмент из пункта №50:

В случае самостоятельной разработки оператором (обладателем информации) программного обеспечения, предназначенного для использования в информационных системах, должны быть реализованы меры, предусмотренные разделами 4 и 5 ГОСТ Р 56939-2024.
В случае привлечения оператором (обладателем информации) для разработки программного обеспечения подрядной организации по решению руководителя (ответственного лица) в техническое задание на разработку программного обеспечения могут быть включены требования по разработке безопасного программного обеспечения в соответствии с ГОСТ Р 56939-2024.

Пятый раздел ГОСТ Р 56939-2024 описывает 25 процессов, каждый из которых из ниоткуда не появится и не заработает. Поэтому есть смысл заранее подойти к изучению стандарта и по возможности внедрять или готовиться внедрять описанные там процессы.

Аутсорсинг и приказ ФСТЭК №117, теория РБПО, инструменты (часть 2 из 2)

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

Для обучения предлагаю ознакомить команду с подборкой материалов на нашем сайте "Компетенция: теория разработки безопасного ПО (РБПО)". Это не универсальная подборка, и уклон в ней сделан в сторону методологии статического анализа кода, однако она позволит получить общее представление о РБПО.

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

Дополнительное обучение сотрудников можно организовать на базе обучающих курсов по РБПО в УЦ МАСКОМ.

Есть смысл начать внедрять фундаментальные практики РБПО, такие как статический, динамический и композиционный анализ кода. Их называют тремя китами РБПО.

В качестве статического анализатора предлагаем изучить и внедрить PVS-Studio. По промокоду rbpo2025 предоставим полнофункциональный триал на месяц. Также можно заранее обсудить с нашим отделом продаж условия приобретения лицензий. Телефон: +7(903)844-02-22.

PVS-Studio может закрыть 10 процесс из ГОСТ Р 56939 (Статический анализ исходного кода) для языков C, C++, C#, Java. Основные характеристики:

• работает под управлением операционных систем Windows, macOS, Linux (в том числе поддерживаются российские дистрибутивы: Astra Linux, РЕД ОС);

• включён в реестр российского ПО: запись N 9837;

• совместим с ГОСТ Р 71207-2024 (Статический анализ кода);

• соответствие требованиям "Методики выявления уязвимостей и недекларированных возможностей в программном обеспечении" от 25 декабря 2020 г.;

• работает в закрытом контуре;

• участвует в инициативе ФСТЭК по испытанию статических анализаторов.

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

Старайтесь не писать строки кода, которые не помещаются на экран (часть 1 из 2)

Встретили баг, который одновременно демонстрирует, как "код-колбаса" притягивает ошибку, эффект последний строки и проблему неудачного copy-paste.

Мы не только реализуем в PVS-Studio новые диагностические правила, но и постепенно дорабатываем старые. Например, недавно в C#-анализаторе мы улучшили одну из самых старых диагностик — V3001, научив её корректнее определять случаи, когда дополнительные скобки ни на что не влияют. Результат — выявление новых багов, с одним из которых мы сейчас вас познакомим.

Ошибка найдена в проекте Space Engineers, который входит в базу проектов для регрессионного тестирования нашего анализатора. Мы используем старую зафиксированную версию проекта, так как нам нужно анализировать отличие работы анализатора на одном и том же коде. Но если заглянуть в свежую версию исходного кода, то можно обнаружить, что ошибка по-прежнему присутствует. См. функцию Contains в BoundingBox.cs.

Видите ошибку? Думаю, нет.

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

return (double)this.Min.X + (double)num > (double)sphere.Center.X ||
       (double)sphere.Center.X > (double)this.Max.X - (double)num ||
       ((double)this.Max.X - (double)this.Min.X <= (double)num ||
        (double)this.Min.Y + (double)num > (double)sphere.Center.Y) ||
       ((double)sphere.Center.Y > (double)this.Max.Y - (double)num ||
        (double)this.Max.Y - (double)this.Min.Y <= (double)num ||
       ((double)this.Min.Z + (double)num > (double)sphere.Center.Z ||
        (double)sphere.Center.Z > (double)this.Max.Z - (double)num)) ||
       (double)this.Max.X - (double)this.Min.X <= (double)num ?
         ContainmentType.Intersects : ContainmentType.Contains;

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

Старайтесь не писать строки кода, которые не помещаются на экран (часть 2 из 2)

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

(double)this.Max.X - (double)this.Min.X <= (double)num

Она повторяет третью строчку. Условие выше заключено в дополнительные скобки, но они ни на что не влияют, так как все проверки объединяются с помощью оператора ИЛИ.

На самом деле в последнем случае должна проверяться координата Z:

(double)this.Max.Z - (double)this.Min.Z <= (double)num

Анализатор PVS-Studio замечает это и выдаёт предупреждение: V3001 There are identical sub-expressions '(double)this.Max.X - (double)this.Min.X <= (double)num' to the left and to the right of the '||' operator.

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

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

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

Всё то же самое, и анализатор указал на вторую ошибку точно таким же предупреждением.

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

1. Форматированию кода таблицей.

2. Вынесению единообразного кода в функции.

3. Удалению лишних операций. Например, вместо того, чтобы везде выполнять приведение типа (double)num можно было сразу объявить переменную num как double.

4. Регулярному использованию статического анализатора PVS-Studio для дополнительного контроля.