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

Меня вновь позвали на подкаст Ever Secure. Присоединяйтесь сегодня вечером (11 ноября в 19:00 по МСК).

Запись "Функциональное тестирование" из цикла "Вокруг РБПО за 25 вебинаров". Это 18-й процесс ГОСТ Р 56939-2024, до рассмотрения которого мы добрались вместе с УЦ МАСКОМ.

А ещё на подходе:

Сегодня! Совместный вебинар с CyberCodeReview "Статический анализ и ASOC: нулевая терпимость к ошибкам в проекте". (13 ноября в 15:00, онлайн)

Вебинар "Особенности разработки встроенного ПО по требованиям ФБ" (20 ноября в 15:00, онлайн). ГОСТ Р МЭК 61508, SIL (УПБ), встроенное ПО, MISRA C и т.д.

Митап "Сплошные плюсы. Клуб С++ разработчиков" (25 ноября в 18:00, Москва, оффлайн).

Я там сделаю доклад "Неопределённое поведение: если про него не думаете, это не значит, что его нет".

Второй доклад будет от Александра Асонова(НИЦ «Курчатовский институт») – "Российские операционные системы реального времени семейства Багет".

Приглашаю регистрироваться!

Вроде чёрная пятница, а распродажу PVS-Studio не устроишь. Подобные решения не покупают импульсивно, да и процесс растянут во времени.

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

Заметка о том, что мы тоже допускаем ошибки. Никто не совершенен.

if (Workbench.versionInfo.version >= '1.44.0') {

А ещё в статье можно найти пасхалку, вернее намёк на вектор развития PVS-Studio 😉

ФСТЭК сообщила о введении требований для подрядчиков с доступом к IT-инфраструктуре КИИ

19 ноября. / D-Russia /. В 2026 году ожидается принятие ряда нормативных правовых актов, в которых, в частности, будет прописано выполнение подрядчиками требований, предъявляемых к владельцам значимых объектов критической информационной инфраструктуры (ЗО КИИ), сообщила начальник управления Федеральной службы по техническому и экспортному контролю (ФСТЭК) Елена Торбенко на SOC-Форуме во вторник, пишет «Интерфакс».

Таким образом, на подрядчиков распространятся нормы 187-ФЗ «О безопасности КИИ».

Ранее эксперт рассказывал D-Russia.ru, что распространение требований на подрядные организации уже предусмотрено приказом ФСТЭК, который вступит в силу с марта 2026.

Всего было выявлено более 1,1 тысячи нарушений в обеспечении безопасности объектов КИИ (период не уточняется – ред.), по словам Торбенко. 98% нарушений традиционно связаны с несоответствием фактического состава ЗО КИИ сведениям, включенным в реестр таких объектов, сказала Торбенко.

Также к типовым нарушениям она отнесла отсутствие контроля за действиями подрядчиков, имеющих доступ к IT-инфраструктуре ЗО КИИ.

Особо Торбенко отметила невыполнение владельцами ЗО КИИ требований указа президента №250, запрещающего использование на ЗО КИИ средств защиты информации производства компаний из недружественных стран. Этот указ был принят в 2022 году, а срок его исполнения наступил 1 января 2025 года.

«С момента принятия указа прошло 3,5 года, и было достаточно времени, чтобы решить, как его выполнить, – сказала Торбенко. – В течение года не штрафовали за неисполнение этого указа, теперь органы прокуратуры указали, что мы поступали неправильно. Поэтому владельцам ЗО КИИ необходимо спланировать в ближайшее время исполнение указа №250».

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