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

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».

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

Запись вебинара «Особенности разработки встроенного ПО по требованиям ФБ»

Вместе с экспертами из ФанкСэйфети разбирались с такими сущностями, как ГОСТ Р МЭК 61508, уровнями SIL, стандартом MISRA C, сертификацией по функциональной безопасности и т.д.

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

1) Говоря про безопасные и сертифицированные компиляторы, стоит отметить, что в 2024 году появился ГОСТ Р 71206-2024: "Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования". Также см. пост из цикла разбора РБПО: Процесс 12 — Использование безопасной системы сборки программного обеспечения и вебинар на эту тему.

2) Инструменты SAST и DAST не обязаны быть сертифицированы. Из методической рекомендация ФСТЭК № 2025-07-011 | Уровень критичности: 3

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

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

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

См. также выдержку из эфира AM Live "Разработка безопасного программного обеспечения (РБПО)". Анализатор PVS-Studio сейчас участвует в инициативе ФСТЭК по испытаниям статических анализаторов кода, но это другая история.

3) Был вопрос, связанный с объединением требований ФБ и ИБ в одном стандарте. Некоторые усилия в этом направлении предпринимаются, см. примеры ГОСТов ниже:

ГОСТ Р 59506-2021/IEC TR 63074:2019. Национальный стандарт Российской Федерации. Безопасность машин. Вопросы защиты информации в системах управления, связанных с обеспечением функциональной безопасности.

ГОСТ Р 71452— 2024/ IEC/PAS 63325:2020. Требования к функциональной безопасности и защите системы контроля промышленной автоматизации (IACS) на протяжении жизненного цикла.

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

Познавательная техническая заметка про PVS-Studio.

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

Ой, забыл написать, что выложена запись 19-го вебинара про нефункциональное тестирование из серии «Вокруг РБПО». И уже завтра (26.11.2025) в 16:00 по МСК пройдёт очередная онлайн встреча «Процесс 20. Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения». Подключайтесь.

P.S. Про 19 процесс РБПО. Сложно выявлять уязвимые сценарии взаимодействия с системой для их предотвращения, не имя представление о чём в целом речь. Поэтому приведу несколько ссылок, от чего можно оттолкнуться. Ссылки точно не претендует на полноту картины, но хотя бы подскажут с чего начать изучение темы нефункционального тестирования:

1. Server-Side Request Forgery (SSRF).
2. Межсайтовый скриптинг (XSS).
3. XEE-атака (billion laughs attack).
4. XXE-атака (XML External Entity).
5. Path Traversal.
6. ReDoS (Regular expression Denial of Service).
7. Уязвимость XSS в приложении ASP.NET: разбираем CVE-2023-24322 в CMS mojoPortal.
8. Обработка XML-файлов как причина появления уязвимостей.

Мы всё про ГОСТы и про ГОСТы... Для разнообразия рассмотрели в статье Cyber Resilience Act.

Cyber Resilience Act (CRA) — это нормативно-правовой акт (или же закон), который предъявляет требования к производителям ПО, выпускающим свои продукты на рынок стран Евросоюза. Требования касаются кибербезопасности разрабатываемого продукта.

Создание закона было инициировано Европейской комиссией. Он вступил в силу 10 декабря 2024 года, а его основным требованиям необходимо начать соответствовать через 36 месяцев с момента вступления в силу, т.е. с 11 декабря 2027 года. Но в нём есть положения, у которых более ранние сроки соответствия.

Продолжаем погружаться тематику разработки игр. Я буду на разогреве. Расскажу, как мы написали свой собственный класс строки, а потом удалили его.

Коллега сейчас обнаружил забавный факт, который идёт в копилку "PVS-Studio - двигатель прогресса".

Слышали ли вы про то, что злобные C и C++ компиляторы могут удалить вызов memset в конце функции во время оптимизаций? У нас даже про это диагностика есть, V597.

Проблема насущная и для её решения в стандарт C23 внесли новую функцию memset_explicit, которая теперь обязательна для реализации в стандартной библиотеке вместо memset_s. Так вот, автор предложения (Miguel Ojeda, P1315) в своём документе сослался на нашу диагностику (ссылка №3). И похоже, что он давно про нас знает, т.к. умудрился вставить ссылку ещё аж на старый сайт viva64.

Не зря столько лет говорим про memset. Приятно, что нас уже в проползалы затаскивают :)

Стоматологические услуги для компиляторов на примере LLVM 21

Прям мини детектив о появлении различных багов :) Рекомендую погрузиться.

И хорошая демонстрация, что статический анализатор PVS-Studio полезен даже самым опытным разработчикам.

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

Приглашённый внешний эксперт: Игорь Хмелёв, заместитель директора по специальным разработкам НПО «Эшелон».

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

Приглашённые эксперты: Мария Рачева и Александр Гадай из компании Swordfish Security.

P.S. В ходе вебинара упоминался приказ ФСТЭК №117, который вступит в силу 1 марта 2026. Некоторые мои соображения по этой теме: Аутсорсинг и приказ ФСТЭК N 117, теория РБПО, инструменты.