Про статический анализатор конфигов Nginx от Яндекс (https://github.com/yandex/gixy) я пару раз упоминал у себя на канале, но уже давненько

2019
https://t.me/tech_b0lt_Genona/890

2021
https://t.me/tech_b0lt_Genona/2529

Это хороший инструмент, но он несколько лет уже не развивается.

Есть форк, который развивается и поддерживается
https://github.com/dvershinin/gixy
https://pypi.org/project/gixy-ng/

Но есть ещё один форк
https://github.com/MegaManSec/Gixy-Next

И мотивация его появления интересна

> After some time, the maintainer of gixy-ng began to commit AI-generated changes to the codebase which introduced obvious regressions, broke critical behavior of the tool (which anybody using the tool would have picked up), added random AI-tooling artifacts, and introduced code which simply did not do what it was supposed to do. Most importantly, the maintainer also added marketing for their business to all documentation, all output, and all source code of gixy-ng.

Вот два поста в блоге автора Gixy-Next по этому поводу

Gixy-Next: an overview of a Gixy fork with updated, improved, and new checks
https://joshua.hu/gixy-ng-new-version-gixy-updated-checks

From gixy-ng to Gixy-Next: rescuing Gixy from AI slop
https://joshua.hu/gixy-ng-ai-slop-gixy-next-maintained

Gixy-Next поддерживает следующие проверки

- [add_header_content_type] Setting Content-Type via add_header
- [add_header_multiline] Multiline response headers
- [add_header_redefinition] Redefining of response headers by "add_header" directive
- [alias_traversal] Path traversal via misconfigured alias
- [allow_without_deny] Allow specified without deny
- [default_server_flag] Missing default_server flag
- [error_log_off] error_log set to off
- [hash_without_default] Missing default in hash blocks
- [host_spoofing] Request's Host header forgery
- [http_splitting] HTTP Response Splitting
- [if_is_evil] If is evil when used in location context
- [invalid_regex] Invalid regex capture groups
- [low_keepalive_requests] Low keepalive_requests
- [merge_slashes_on] Enabling merge_slashes
- [missing_worker_processes] Missing worker_processes
- [origins] Problems with referer/origin header validation
- [proxy_buffering_off] Disabling proxy_buffering
- [proxy_pass_normalized] proxy_pass path normalization issues
- [regex_redos] Regular expression denial of service (ReDoS)
- [resolver_external] Using external DNS nameservers
- [return_bypasses_allow_deny] Return directive bypasses allow/deny restrictions
- [ssrf] Server Side Request Forgery
- [stale_dns_cache] Outdated/stale cached DNS records used in proxy_pass
- [try_files_is_evil_too] try_files directive is evil without open_file_cache
- [unanchored_regex] Unanchored regular expressions
- [valid_referers] none in valid_referers
- [version_disclosure] Using insecure values for server_tokens
- [worker_rlimit_nofile_vs_connections] worker_rlimit_nofile must be at least twice worker_connections

Как и много лет назад я рекомендую к использованию такие инструменты.

Узнал из поста в TG канале Swordfish Security.

В самом конце 2025 года информационным письмом №ИН-017-56/118 Банк России опубликовал обновленный методический документ "Профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций".

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

Во-первых, описываемый процесс разработки безопасного ПО адаптирован под ГОСТ 56939-2024.

Документ обновлен, в том числе с учётом практики применения "ГОСТ Р 56939-2024. Национальный стандарт Российской Федерации. Защита информации. Разработка безопасного программного обеспечения. Общие требования".

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

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

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

Это ровно то, что перечисляется в разделе 7.4. ГОСТ Р 71207-2024. Можно только отметить, что про "межпроцедурный и межмодульный контекстно-чувствительный анализ помеченных данных" сказано и другими словами:

Статический анализ кода проводится с использованием автоматизированных средств и направлен на идентификацию потенциально опасных фрагментов кода, в том числе: а) вызовов функциональных объектов (функций, методов, процедур) с передачей им в качестве аргументов данных, вводимых пользователем или принимаемых из внешних источников;

В общем, ГОСТ Р 56939-2024 и ГОСТ Р 71207-2024 будут всё активнее влиять на подходы к разработке ПО. Уместно, ещё вспомнить и приказ ФСТЭК №117.

P.S. Хотите организовывать статический анализ по ГОСТ – используйте PVS-Studio :)

Мы иногда во внутреннем чате обмениваемся фрагментами кода с неочевидными ошибками, которые обнаруживаются с помощью PVS-Studio в каком-нибудь открытом проекте. Мол, кто быстро сообразит, что не так с кодом?

Вчера коллега поделился вот таким фрагментом кода из проекта SereneDB:

template <typename T>
struct NumericParameter : public Parameter {
  using ValueType = T;
  ....
  std::string name() const override {
    if constexpr (std::is_same_v<ValueType, int16_t>) {
      return "int16";
    } else if constexpr (std::is_same_v<ValueType, uint16_t>) {
      return "uint16";
    } else if constexpr (std::is_same_v<ValueType, int32_t>) {
      return "int32";
    } else if constexpr (std::is_same_v<ValueType, uint32_t>) {
      return "uint32";
    } else if constexpr (std::is_same_v<ValueType, int64_t>) {
      return "int64";
    } else if constexpr (std::is_same_v<ValueType, uint64_t>) {
      return "uint64";
    } else if constexpr (std::is_same_v<ValueType, size_t>) {
      return "size";
    } else if constexpr (std::is_same_v<ValueType, double>) {
      return "double";
    } else {
      static_assert("unsupported ValueType");
    }
  }
  ....
};

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

Ответ:

Анализатор PVS-Studio выдаёт предупреждение V591 Non-void function should return a value. parameters.h 222

На первый взгляд предупреждение странное и смахивает на ложное срабатывание, ведь не может быть, что функция закончила работу, не вернув значение с помощью оператора return. Если выбирается ветка else, то там static_assert, и код просто не должен скомпилироваться. Во всех остальных случаях есть return "что-то";.

Но есть нюанс!

Ещё раз посмотрите на эту строчку:

static_assert("unsupported ValueType");

static_assert используется неправильно: пропущен bool-constexpr. Вернее, строковый литерал неявно конвертируется в значение true, и static_assert никогда не прервёт компиляцию. В итоге else-ветка функции ничего не возвращает, и её поведение будет не определено для всех специализаций NumericParameter, кроме указанных ранее в цепочке if constexpr.

Правильный вариант:

static_assert(false, "unsupported ValueType");

P.S. Анализатор PVS-Studio внимательнее не только меня, но и LLM (см. комментарий на habr)

Обновлённое подробное описание PVS-Studio на начало 2026 года с точки зрения
• ГОСТ Р 71207—2024 — Статический анализ программного обеспечения,
• ГОСТ Р 56939—2024 — РБПО,
• приказа ФСТЭК №117,
• и т.д.

P.S. Команда PVS-Studio будет со стендом на ТБ Форум 2026 (18—20 февраля 2026, МВЦ "Крокус Экспо", павильон 2, зал 10). Я там тоже буду. Приходите задавать вопросы на тему публикации, стандартов и вообще.

Буду рад присланным идеям диагностических правил статического анализатора для языков Go, JavaScript, TypeScript. Такие ошибки, как деления на 0, не интересны. С ними и так всё понятно. Интересны разновидности опечаток (в духе забытого throw), паттерны неправильного использования функций и т.п. Заранее спасибо.

Даже немного не верится, но мы добрались до двух последних процессов ГОСТ Р 56939-2024!

Записи вебинаров:

Вебинар 24. Поиск уязвимостей в программном обеспечении при эксплуатации

Вебинар 25. Обеспечение безопасности при выводе программного обеспечения из эксплуатации

Другие записи можно найти на странице "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024".

Однако, нам сложно остановиться :) Поэтому вас ждёт ещё несколько дополнительных встреч. Уже запланировано:

• 04.02.2026 в 16:00 по МСК - Безопасность frontend-приложений: особенности, угрозы и анализаторы класса FAST (Frontend Application Security Testing)

• 11.02.2026 в 16:00 по МСК - PVS-Studio Atlas — новая платформа контроля качества кода

Компания FuncSafety, с которой мы делали совместный вебинар, запустила канал, посвященный Функциональной Безопасности: https://t.me/funcsafety

СВД Встраиваемые Системы приглашает 13 февраля / 12.00 на экспертный вебинар по разработке ПО с требованиями функциональной безопасности — без мистики, только проверенные методологии, стандарты и практика.

P.S. Мы сотрудничаем c СВД Встраиваемые Системы и благодарны им за отзыв, оставленный в конце 2025 года.

Выражаем благодарность команде отдела сертификационных испытаний АО Центр «Атомзащитаинформ». Отдел провёл испытания статического анализатора кода PVS-Studio и составил краткое ревью. Лаборатория считает целесообразным рассматривать PVS-Studio как SAST-средство, пригодное для встраивания в цикл разработки для выявления опечаток, логических ошибок, мёртвого кода и потенциальных уязвимостей. В частном порядке вы можете ознакомиться с отзывом, написав нам в поддержку.

Из недостатков отмечено ограничение по языкам. На данный момент продукт поддерживает только C, C++, C#, Java. Однако, забегая вперёд, могу сказать, что уже ведётся разработка по поддержке JavaScript, TypeScript и Go. Весной мы планируем организовать программу раннего доступа (EAP).

Большой брат, биг-дата, ИИ...

Месяц звонки из "Яндекс для Бизнеса" (на телефоне распознается). Обычно не отвечаем, а сегодня ответили, чтобы отстали уже.

Хотели предложить для нашей компании Яндекс.Такси. Которым мы пользуемся сто лет.

Вот такая вот подготовительная работа и анализ потенциальный клиентов...

В ходе бонусного вебинара команда PVS-Studio представила новый продукт — PVS-Studio Atlas, предназначенный для работы с результатами анализа кода: просмотра, аналитики, разметки и формирования отчётов для сертификационных лабораторий и ФСТЭК.

P.S. Тестировании Atlas Viewer доступно на странице PVS-Studio Beta.

Разбираем изменения в OWASP Top 10 версии 2025 года на примерах и рассматриваем, как SAST может помочь избежать уязвимостей.

Только ленивый не писал и не обсуждал недавнюю новость, что оркестр из агентов Opus’а написал компилятор для C. Ссылка №1, №2, №3. Мне близка вот эта мысль:

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

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

10 бесплатных уроков, около 6 часов видео. В формате лайвкодинга Юрий Минаев (архитектор в компании PVS-Studio) показывает весь процесс разработки на C++ выдуманного языка программирования. Вы разберётесь, что такое язык и как формально описать его так, чтобы машина могла его понимать. Шаг за шагом вы реализуете лексер, вспомните основы грамматики и метод рекурсивного спуска, добавите в язык переменные и функции, научитесь вызывать их и корректно определять тип возвращаемого значения. Финальной частью станет написание собственного эвалюатора.

Запись вебинара: Статический анализ кода в методическом документе ЦБ РФ "Профиль защиты".

Описание. Методический документ "Профиль защиты (ПЗ) прикладного ПО автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций", опубликованный в декабре 2025 года, уточнил и расширил многие меры, направленные на разработку безопасных программных продуктов. Например, перечислены требования, предъявляемые к инструментальным средствам статического анализа кода. В ходе вебинара рассмотрели эти новые требования, а также причины, по которым полезно изучить ГОСТ Р 56939—2024 и ГОСТ Р 71207—2024 при реализации требований безопасности, изложенных в ПЗ.

Примечание. По окончании вебинара был задан вопрос о сертификации средств статического анализа. В качестве ответа уместно привести цитату из статьи "Итоги этапа «Домашнее задание» испытаний статических анализаторов под патронажем ФСТЭК России":

Важно отметить, что в настоящий момент ФСТЭК России не предъявляет каких-либо специальных требований к инструментам статического анализа, на соответствие которым возможно проводить сертификационные испытания инструментов. Как следствие, любые требования заказчиком наличия сертификата ФСТЭК России на инструмент статического анализа являются его частной инициативой (подробнее — в эфире канала AMLive, выпуск «Как встроить безопасность в процесс разработки ПО: практика, ошибки, решения»).