Бестиарий программирования

У нас в блоге появился новый жанр – отзывы клиентов. Представлю первые два из них от компании Eltex и СВД ВС. Большое им спасибо, что нашли время дать обратную связь.

"На начальном этапе нас поразила скорость работы. Другие анализаторы могли увеличивать время сборки до 30 минут, а PVS-Studio добавлял буквально пару минут. Это стало весомым преимуществом. Кроме того, интеграция через CMake идеально легла в наши процессы", — Павел Ильченко, руководитель группы Security, Eltex.

Читать далее: Как крупнейший в РФ производитель сетевого оборудования Eltex сделал разработку безопаснее благодаря PVS-Studio.

"Наши разработчики привыкли работать с кодом в системе контроля версий. С PVS-Studio это гораздо проще, возможно, именно потому, что не нужно отправлять что-то на удалённый сервер, чтобы посмотреть результат. Быстро формируется прекрасный HTML-отчёт, и с ним сразу можно работать", — Евгений Дужак, руководитель группы СЗИ, СВД ВС.

Читать далее: Как СВД ВС использует PVS-Studio в сертифицируемой разработке защищённой ОС.

#созвон_сообщества
Запись созвона

Гости выпуска: Андрей Карпов (Co-Founder PVS-Studio).
Дмитрий Шмойлов (Head of software security Kaspersky Lab)
Тема: Разбираем новый ГОСТ Р 56939-2024 - РБПО

На созвоне поговорили про ГОСТ Р 56939-2024 и построении процессов вокруг него

Приятного просмотра:
- 📹 Youtube
- 📺 VK

👀@ever_secure | 💪 Мерч | 💳Поддержать

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

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

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

Безопасность = качество? Часть 2 🔐

В прошлый раз мы говорили про концепцию, которая объясняет финансовую сторону вопроса верификации, мотивирующая внедрять практики РБПО.

Сегодня поговорим про другую концепцию, дополняющую и расширяющую "1:10:100". 💰
Речь о концепции «Shift-left» (или по-русски — «сдвиг-влево»).

📌 В чём суть?
Процесс разработки, по крайней мере в рамках одного цикла (при использовании scrum-методологии например), разворачивается в прямую линию из отдельных этапов.

Упрощённый пример:
Требования (0) → Проектирование (1) → Разработка (2) → Верификация (3) → Внедрение (4) → Работа (5)

Главный принцип:
👉 Чем ближе к этапу №0 внедряются практики безопасности, тем надёжнее и качественнее итоговое решение.

Перейдём к конкретному примеру. Когда вы — молодец?

👍 На этапе требований (0):
Если вы видите небезопасное требование и отбрасываете его, не внося в архитектуру — вы молодец!
👍  На этапе проектирования (1):
Если вы задумываетесь, как каждое архитектурное решение повлияет на безопасность — вы молодец!
👍На этапе разработки (2):
Если вы используете статический анализ, проводите качественный код-ревью, применяете ручной анализ где нужно и ответственно подходите к использованию opensource-кода — вы молодец!
👍На этапе верификации (3):
Если вы тестируете продукт на стендах, используя лучшие практики динамического анализа, а не «в полях» — вы молодец!

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

#ДайджестРБПО

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

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

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

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

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

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

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

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

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

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

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

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

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

Ой, забыл написать, что выложена запись 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-файлов как причина появления уязвимостей.

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

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

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

Вместе с экспертами из ФанкСэйфети разбирались с такими сущностями, как ГОСТ Р МЭК 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 с высоты полёта. Читайте: "Превратили PVS-Studio в город".

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

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

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

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

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

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

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

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

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

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

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

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