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

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

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

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

Контроль уязвимостей в сторонних компонентах может показаться избыточным, ведь для этого есть процесс 16 — композиционный анализ (см. РБПО-061). Как я понимаю, здесь речь о следующем:

1. SCA инструменты могут быть ещё не в курсе выявления и эксплуатации какой-то уязвимости. И если вдруг удалось выяснить, например, на форуме хакеров, что некий компонент уязвим, то можно предпринять действия, не дожидаясь появления соответствующей CVE. Собственно, можно стать инициатором пополнения базы CVE новой уязвимостью и тем самым обезопасить не только свой проект, но и помочь другим.

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

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

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

Ещё одним способом упреждения уязвимостей являются публичные программы поиска уязвимостей за вознаграждение:

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

К сожалению, пока Госдума отклонила законопроект о легализации "белых" хакеров:

На заседании во вторник, 8 июля 2025, Госдума отклонила законопроект, который должен был легализовать в России деятельность «белых» хакеров. Решение было принято после соответствующей рекомендации профильного комитета Госдумы по государственному строительству и законодательству.

Речь идет о хакерах, которых компании самостоятельно привлекают к тестированию своих информсистем на уязвимости. Вопрос легализации их деятельности в России публично обсуждается с лета 2022 года, когда Минцифры занялось проработкой возможности ввести в правовое поле понятие bug bounty — поиск уязвимостей в софте за вознаграждение.

Так что учитывайте, что сейчас этот метод, к сожалению, не регламентируется и не оформлен юридически.

Дополнительные ссылки:
1. Елена Дмитриева. Обзор программ и площадок баг-баунти в России: практика, кейсы, суммы гонораров.
2. TAdviser. Подборка: Белые хакеры в России.
3. Круглые столы: Взгляд разработчиков, пользователей, хакеров, Багбаунти: опыт hh.ru и Rambler&Co, Багбаунти: опыт Ozon и Wildberries на Standoff Bug Bounty.
4. Как пентестеры помогают бизнесу найти уязвимости в IT-системах.

Сегодня мы запускаем HiveTrace Red — продукт автоматического тестирования LLM и агентных систем.

Всё началось с курьёзных случаев, когда чатбот продавал автомобиль за доллар или выдавал несуществующие скидки на авиабилеты. С ростом возможностей ИИ-систем мы видим, что адверсарное тестирование становится таким же необходимым этапом безопасной разработки, как code review или аудит зависимостей библиотек.

🔹 HiveTrace Red генерирует и запускает десятки атак: token smuggling, roleplay, context switching и другие.
🔹 Цели тестирования могут варьироваться от раскрытия конфиденциальной информации и генерации вредоносного контента до проверки репутационных рисков и симуляции DoS атак.
🔹 Инструмент автоматически анализирует ответы моделей и формирует отчёты, совместимые с OWASP и MITRE, а в будущем добавим новые российские стандарты.
🔹 Совместное использование с основной платформой HiveTrace позволяет закрыть полный цикл разработки и эксплуатации AI-систем "обнаружить — проверить — предотвратить".

Сегодня мы открываем Open Source ядро продукта, которое можно использовать как on-prem с локальными моделями, так и через API облачных сервисов для генерации и оценки атак. Параллельно идёт разработка enterprise-функций и интеграций с облачными платформами. При создании инструмента мы опирались на опыт собственных red team-проектов последних двух лет, а в основе HiveTrace Red лежит форк проекта RuRedTeam Юрия Лебединского.

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

Коллеги, приглашаю на мероприятие "Безопасная разработка в АСУ ТП".

На митапе обсудим современные угрозы для АСУ ТП, методы киберзащиты и роль статического анализа кода в предотвращении сбоев и атак, с акцентом на отечественные стандарты и практики безопасной разработки.

Кому будет полезно:

- CTO – получат понимание рисков, связанных с дефектами в коде, и смогут оценить, как внедрение анализа кода влияет на устойчивость и надежность программных продуктов;

- руководители отделов разработки и АСУ ТП – обсудят опыт коллег и смогут применять лучшие практики для своей инфраструктуры;

- инженеры по АСУ ТП – узнают о новых методах киберзащиты, актуальных угрозах и инструментах обеспечения безопасности систем;

- системные архитекторы – смогут понять, как интегрировать безопасные практики в жизненный цикл разработки и эксплуатации АСУ ТП;

- представители отраслей энергетики, нефтяной и газовой промышленности, металлургии, химической промышленности, транспорта и логистики – там, где широко применяются АСУ ТП;

- CISO и специалисты по ИБ – получат информацию о специфике защиты АСУ ТП;

- разработчики и аудиторы ПО – особенно те, кто работает по ГОСТ и другим отечественным стандартам.

📍Где: Москва, пр-т Мира, 119 строение 461, Москва (павильон «Умный город», ВДНХ)

🗓Когда: 24.10.2025 (чт) 17:00

Подробности по ссылке

РБПО-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 процессов, каждый из которых из ниоткуда не появится и не заработает. Поэтому есть смысл заранее подойти к изучению стандарта и по возможности внедрять или готовиться внедрять описанные там процессы.