Не забываем про GameDev. Запись очередного вебинара – "Оптимизация игр: работа со строками".
В своей разминочной части я упоминал доклад Антона Полухина – "Как делать не надо: C++ велосипедостроение для профессионалов". Хоть доклад уже бородатого 2017 года, всё равно рекомендую к просмотру.
В своей разминочной части я упоминал доклад Антона Полухина – "Как делать не надо: C++ велосипедостроение для профессионалов". Хоть доклад уже бородатого 2017 года, всё равно рекомендую к просмотру.
👍5
Тяжела и неказиста жизнь ложных срабатываний анализатора. Встретился вот такой необычный случай при проверке Java проекта LanguageTool:
Предупреждение PVS-Studio: V6007 Expression 'word.endsWith("ني")' is always false. ArabicTagger.java 428
Если смотреть на строковые константы так, как привыкли носители английского, французского, немецкого или русского языка – сообщение анализатора действительно кажется справедливым. Однако, здесь стоит помнить о том, что в арабском языке написание и чтение происходит справа-налево. А значит, там, где не носитель арабского языка ожидает конец литерала, на самом деле столкнётся с его началом. И в этой ситуации анализатор оказался не носителем арабского языка.
К слову, если учесть RTL (right-to-left, справа-налево) написание слова, здесь окажется, что условие на самом деле всегда истинно, а не ложно.
А как Java обрабатывает языки с письмом справа налево? Секрет в том, что Java работает не с "визуальным" представлением текста, а с его Unicode-кодировкой. В Unicode символы любых языков — как с направлением слева направо, так и справа налево — хранятся в логическом порядке, то есть в том порядке, в котором они вводятся и читаются носителями языка.
Это означает, что Java не требуется выполнять какие-либо специальные преобразования для работы с RTL-текстом. Строка остаётся обычной последовательностью Unicode-кодовых точек, а такие операции, как получение длины строки, доступ к символам или выделение подстроки, работают одинаково для всех языков.
Поэтому, для вот такой проверки:
Результатом будет
Случай познавательный и интересный для нас, хотя с ходу пока не понятно, как быть с такими ситуациями. Выписали в todo на обдумывание.
public String getEnclitic(AnalyzedToken token) {
....
if (word.endsWith("ه")) {
suffix = "ه";
....
else if ((word.equals("عني") ||
word.equals("مني")) &&
word.endsWith("ني") // <=
) {
suffix = "ني";
}
....
}Предупреждение PVS-Studio: V6007 Expression 'word.endsWith("ني")' is always false. ArabicTagger.java 428
Если смотреть на строковые константы так, как привыкли носители английского, французского, немецкого или русского языка – сообщение анализатора действительно кажется справедливым. Однако, здесь стоит помнить о том, что в арабском языке написание и чтение происходит справа-налево. А значит, там, где не носитель арабского языка ожидает конец литерала, на самом деле столкнётся с его началом. И в этой ситуации анализатор оказался не носителем арабского языка.
К слову, если учесть RTL (right-to-left, справа-налево) написание слова, здесь окажется, что условие на самом деле всегда истинно, а не ложно.
А как Java обрабатывает языки с письмом справа налево? Секрет в том, что Java работает не с "визуальным" представлением текста, а с его Unicode-кодировкой. В Unicode символы любых языков — как с направлением слева направо, так и справа налево — хранятся в логическом порядке, то есть в том порядке, в котором они вводятся и читаются носителями языка.
Это означает, что Java не требуется выполнять какие-либо специальные преобразования для работы с RTL-текстом. Строка остаётся обычной последовательностью Unicode-кодовых точек, а такие операции, как получение длины строки, доступ к символам или выделение подстроки, работают одинаково для всех языков.
Поэтому, для вот такой проверки:
System.out.println("مرحباً بالجميع".endsWith("بالجميع"));Результатом будет
true, хотя если читать слева направо, то строка начинается, а не закачивается с "بالجميع".Случай познавательный и интересный для нас, хотя с ходу пока не понятно, как быть с такими ситуациями. Выписали в todo на обдумывание.
👀8
На днях на конференции ко мне подошёл человек, который поблагодарил за цикл вебинаров, посвящённых РБПО. Я спрашиваю: "А напишешь отзыв?" Он: "Напишу!"
Естественно, захотелось поделиться этим приятным отзывом. Артур, спасибо за душевные слова.
Ещё раз спасибо за развёрнутый тёплый отзыв. От себя присоединяюсь к благодарности ко всем, кто помогает организовать этот цикл и гостям, которые соглашаются выступить с докладом.
Естественно, захотелось поделиться этим приятным отзывом. Артур, спасибо за душевные слова.
Данный отзыв не столько про вебинар "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024", сколько про специалистов, которые проводят эту серию вебинаров.
Когда мне было предложено ввести процессы РБПО в организации, я столкнулся с тем, что фронт работ настолько большой, что в одиночку пройти этот путь вызывало большие опасения. С чего начать? На что обратить внимание? Какие инструменты использовать? Честно говоря, забросить это дело было проще простого. Но мне посоветовали ознакомиться с серией "Вокруг РБПО за 25 вебинаров". И самое главное, почему я благодарен — люди своим примером показывают, что РБПО — это не страшно, что все процессы достижимы и их внедрение всего лишь вопрос времени и усилий, вложенных в нужное русло. В этом деле важно понимать, что есть сообщество, которое приветствует вопросы, и помогает разобраться во всех тонкостях. За это огромное спасибо всем участникам вебинаров!
Вебинары я смотрю не в прямом эфире, но тем не менее, я задаю себе список вопросов, которые я бы хотел получить от каждого выпуска. И по их окончании, я замечаю, что либо вопросов не остается, либо ответы на них уже понятны. Это лишний раз подтверждает то, что спикеры — высокопрофессиональные специалисты, которые не просто рассказывают про ГОСТ, а по-настоящему пережили этот путь и стремятся поделиться как своим личным опытом, так и болью, с которой пришлось столкнуться.
Что же касается самих вебинаров, их структура проста и понятна. Спикеры рассказывают все простым языком, с пояснениями и примерами, так что места для разночтений попросту не остается. Отдельно хотелось бы отметить вебинары по статическому, динамическому и композиционному анализам. Так как остальные процессы так или иначе присутствуют, пожалуй, в любой зрелой организации, внедрение данных проверок оказалось новшеством.
Также хотелось бы поблагодарить организаторов за высокий уровень проведения вебинаров. Здесь не только про качество самих выступлений, но и про техническую составляющую — выступления просто приятно смотреть и слушать.
Муратов Артур. Электронные офисные системы. Инженер-разработчик.
Ещё раз спасибо за развёрнутый тёплый отзыв. От себя присоединяюсь к благодарности ко всем, кто помогает организовать этот цикл и гостям, которые соглашаются выступить с докладом.
👍18❤2
Запись последнего в этом году (но не в цикле РБПО) вебинара на тему "Реагирование на информацию об уязвимостях". В этот раз помочь разобрать 23-й процесс ГОСТ Р 56939-2024 нам помог Дмитрий Частухин, важный технический директор Hexway.
Ссылки, которые были приведены в ходе вебинара:
1. Vampy. Документация.
2. Раздел документации PVS-Studio об интеграции результатов анализа в Hexway VamPy.
3. Карта российского рынка информационной безопасности 2025.
И ещё некоторые дополнительные ссылки:
1. Терминология. Уязвимость нулевого дня.
2. Станислав Мриль. Всё об управлении уязвимостями в 2025: Vulnerability Management.
3. Positive Technologies: раскрытие уязвимостей и опыт взаимодействия исследователей и вендоров в 2022–2023 годах.
4. Руслан Рахметов. Поиск и предотвращение уязвимостей в ПО: эффективные методики.
5. Порядок подачи уязвимости в базу ФСТЭК России: пошаговая инструкция.
Ссылки, которые были приведены в ходе вебинара:
1. Vampy. Документация.
2. Раздел документации PVS-Studio об интеграции результатов анализа в Hexway VamPy.
3. Карта российского рынка информационной безопасности 2025.
И ещё некоторые дополнительные ссылки:
1. Терминология. Уязвимость нулевого дня.
2. Станислав Мриль. Всё об управлении уязвимостями в 2025: Vulnerability Management.
3. Positive Technologies: раскрытие уязвимостей и опыт взаимодействия исследователей и вендоров в 2022–2023 годах.
4. Руслан Рахметов. Поиск и предотвращение уязвимостей в ПО: эффективные методики.
5. Порядок подачи уязвимости в базу ФСТЭК России: пошаговая инструкция.
⚡3👍3🔥2👌1🏆1
Про помощь пользователям, чтобы они помогли анализатору или про ошибки при поиске ошибок :)
Анализатор сложный, полезный, но ограниченный инструмент. Кроме простых случаев, он не может распознать высокоуровневый замысел и назначение пользовательских сущностей. Особенно, если не видит их реализацию.
Другими словами, PVS-Studio понимает, что вот такая функция
Сообщение PVS-Studio: V586 The 'xx_free' function is called twice for deallocation of the same memory space. Inspect the first argument. Check lines: 14, 15.
Однако, анализатор легко запутать или спрятать от него содержимое
Таким образом, если помочь анализатору, он поможет вам выявить больше ошибок. См. раздел "Как разметить пары аллокаторов/деаллокаторов" на странице документации "Аннотирование C и C++ кода в формате JSON".
Бывает нужно подсказать информацию не только про функции, но и про классы. Такой механизм в PVS-Studio тоже есть. Вернее, кхм... он как бы есть, но оказывается не всегда работает. Спасибо клиенту, который указал нам на баг в анализаторе. Оказывается, не срабатывает разметка классов, как аналогов
Чиним. Правка должна войти в первый релиз 2026 года.
Итог. Прошу не забывать про механизмы аннотаций. Они могут помочь улучшить качество, глубину и точность анализа. А если что-то идёт не так, просим писать нам в поддержку.
Анализатор сложный, полезный, но ограниченный инструмент. Кроме простых случаев, он не может распознать высокоуровневый замысел и назначение пользовательских сущностей. Особенно, если не видит их реализацию.
Другими словами, PVS-Studio понимает, что вот такая функция
xx_free это прослойка и по сути является вызовом функции free:void xx_free(void *p)
{
free(p);
}
int main()
{
int *p = (int *)malloc(sizeof(int));
if (p == NULL)
return 1;
*p = 1;
xx_free(p);
xx_free(p);
return 0;
}
Сообщение PVS-Studio: V586 The 'xx_free' function is called twice for deallocation of the same memory space. Inspect the first argument. Check lines: 14, 15.
Однако, анализатор легко запутать или спрятать от него содержимое
xx_free. В этом случае на помощь приходит механизм аннотаций. Можно подсказать анализатору, что xx_free это, по сути, free.Таким образом, если помочь анализатору, он поможет вам выявить больше ошибок. См. раздел "Как разметить пары аллокаторов/деаллокаторов" на странице документации "Аннотирование C и C++ кода в формате JSON".
Бывает нужно подсказать информацию не только про функции, но и про классы. Такой механизм в PVS-Studio тоже есть. Вернее, кхм... он как бы есть, но оказывается не всегда работает. Спасибо клиенту, который указал нам на баг в анализаторе. Оказывается, не срабатывает разметка классов, как аналогов
std::shared_ptr.foo main()
{
// Нет срабатывания, если проаннотировать XPtr как shared_ptr
XPtr<Data> pData;
printf("Identifier = %lld", pData->GetUniqueID());
// Есть предупреждение про разыменование нулевого указателя
std::shared_ptr<Data> pData2;
printf("Identifier = %lld", pData2->GetUniqueID()); // V522
}
Чиним. Правка должна войти в первый релиз 2026 года.
Итог. Прошу не забывать про механизмы аннотаций. Они могут помочь улучшить качество, глубину и точность анализа. А если что-то идёт не так, просим писать нам в поддержку.
👍7
Вышел новый релиз PVS-Studio — 7.40. Пресс-релиз.
Кратко про новое:
- Плагин PVS-Studio поддерживает свежевыпущенную IDE Visual Studio 2026.
- Плагина PVS-Studio поддерживает Qt Creator версий 18.x. Прекращена поддержка плагина для версий Qt Creator 13.x.
- В C#-анализаторе PVS-Studio появилась возможность проверять проекты на .NET 10.
- В игровом движке Unreal Engine версии 5.5 появился новый инструмент Horde — платформа, позволяющая использовать циклы CPU на других машинах, чтобы распределить нагрузку. В связи с этим мы расширили раздел документации об использовании PVS-Studio для анализа Unreal Engine проектов, добавив инструкцию об использовании анализатора в распределённой системе сборки Unreal Build Accelerator.
- Подтверждена техническая совместимость анализатора PVS-Studio с Astra Linux. Сертификат №31190/2025.
Кратко про новое:
- Плагин PVS-Studio поддерживает свежевыпущенную IDE Visual Studio 2026.
- Плагина PVS-Studio поддерживает Qt Creator версий 18.x. Прекращена поддержка плагина для версий Qt Creator 13.x.
- В C#-анализаторе PVS-Studio появилась возможность проверять проекты на .NET 10.
- В игровом движке Unreal Engine версии 5.5 появился новый инструмент Horde — платформа, позволяющая использовать циклы CPU на других машинах, чтобы распределить нагрузку. В связи с этим мы расширили раздел документации об использовании PVS-Studio для анализа Unreal Engine проектов, добавив инструкцию об использовании анализатора в распределённой системе сборки Unreal Build Accelerator.
- Подтверждена техническая совместимость анализатора PVS-Studio с Astra Linux. Сертификат №31190/2025.
❤🔥5👍3
Пришло время традиционных предновогодних статей о наиболее интересных багах, найденных нами в открытых проектах. Начнём с Java.
PVS-Studio
10 самых интересных ошибок в Java проектах за 2025 год
2025 год подходит к концу. Minecraft моды, каталонский язык и неочевидные взаимодействия с тернарным оператором — с чем только не успел познакомиться наш анализатор. А значит, самое время вам об этом...
🔥5
Forwarded from Искусство. Код... ИИ?
В Китае, на Тэнчунском научном форуме, представили доклад «Технологические прогнозы и видение будущего до 2049 года». Сам доклад охренеть, какой здоровый, но некто Руи Ма заботливо разложила его по полочкам в своем блоге. Прочесть однозначно стоит, но ценность там, не столько в визионерских тезисах самого доклада, сколько в 5 редлайнах, определяющих их суть.
Если воспринимать это не как «вау, китайцы опять мечтают», а как инженерный документ о ставках, то становится чётко видно, что почти каждый пункт — это вариация одной схемы:
• строим плотную инфру сенсоров/связи/вычислений,
• запускаем в неё агентов/модели,
• собираем обратную связь из реального мира,
• замыкаем цикл оптимизации,
• получаем систему, которая сама себя поддерживает, расширяет и отчасти проектирует.
И тут стоит отличать здравый инженерный подход от хайповой религии. На Западе обсуждение ИИ слишком часто сваливается в: «AGI завтра всех заменит» и «давайте срочно всё остановим». У китайцев же тон другой: прогресс они считают неизбежным, поэтому ключевой вопрос — не «стоит ли», а «как это все заменеджить». Риски признаются, но трактуются как задачи управления: архитектурой, протоколами, сертификацией, ограничениями инфры.
Второй редлайн — «интеллект без тела не взрослеет». Они постоянно возвращаются к физике: роботам нужна тактильность и манипуляция, воздушной мобильности — батареи и управление трафиком, «зеркальному миру» — дешёвое построение цифровых двойников и поток реальных данных, медицине — клиническая валидация, энергии — синтез и распределение. Это хороший холодный душ для тех, кто продолжает верить, что ещё один скачок параметров решит всё. Не решит.
Третий редлайн — конвергенция. Они не мыслят «ИИ в отрыве от всего». Там всё время склеивается: связь ⇔ вычисления ⇔ энергия ⇔ материалы ⇔ автономные машины ⇔ биология и связанные с этим риски. Это неприятно для людей, которые хотят простых историй уровня «мы внедрим ИИ в процесс и станет хорошо». Нет, станет сложнее. Вероятностный слой управления, встроенный в критическую инфраструктуру, умножает поверхность атаки, резко усложняет верификацию и размывает ответственность. И это как раз то место, которое вызывает больше всего вопросов в визионерских роадмапах. Там обычно красиво рисуют «появится автономность», но редко считают цену отказа, цену ошибки и цену злоупотребления.
Четвёртое — «агентный интернет», как смена субъектности. Здесь явно описывается будущее, где основными активными участниками сети являются ИИ-агенты: они торгуются, планируют, согласуют, управляют ресурсами. Это выглядит логичным продолжением автоматизации, но здесь же сидит и главный риск: когда «действуют агенты», границы безопасности и доверия перестают быть вопросами периметра.
Наивно полагать что сегодняшние проблемы с безопасностью исчерпали весь свой потенциал. Мы просто пока не доросли до уровня, где главными дефектами являются действия агентов, а не огрехи кода или инфры. Уязвимость агентной логики... ммм, точно будет весело🫡
И последнее — символическая дата здесь вторична. Ценность доклада не в точности прогнозов (она наверняка будет околонулевая), а в том, что он показывает именно инженерную картину мира: не «сделаем прорыв», а «соберём систему из взаимодополняющих элементов».
⚠ TL;DR: главная мысль доклада не в конкретных фантазиях про 2049-й, а в одной скучной, но здравой идее: ИИ — не продукт и не философия, а слой управления сложными системами, который обязан приземляться на физический мир (энергия, материалы, связь, и т.п) с четкой оценкой рисков.
Иначе, он так и останется лишь дорогой игрушкой для красивых презентаций.
Если воспринимать это не как «вау, китайцы опять мечтают», а как инженерный документ о ставках, то становится чётко видно, что почти каждый пункт — это вариация одной схемы:
• строим плотную инфру сенсоров/связи/вычислений,
• запускаем в неё агентов/модели,
• собираем обратную связь из реального мира,
• замыкаем цикл оптимизации,
• получаем систему, которая сама себя поддерживает, расширяет и отчасти проектирует.
И тут стоит отличать здравый инженерный подход от хайповой религии. На Западе обсуждение ИИ слишком часто сваливается в: «AGI завтра всех заменит» и «давайте срочно всё остановим». У китайцев же тон другой: прогресс они считают неизбежным, поэтому ключевой вопрос — не «стоит ли», а «как это все заменеджить». Риски признаются, но трактуются как задачи управления: архитектурой, протоколами, сертификацией, ограничениями инфры.
1️⃣ Взрослые системы всегда упираются в реалии эксплуатации, а не в красивые демки.
Второй редлайн — «интеллект без тела не взрослеет». Они постоянно возвращаются к физике: роботам нужна тактильность и манипуляция, воздушной мобильности — батареи и управление трафиком, «зеркальному миру» — дешёвое построение цифровых двойников и поток реальных данных, медицине — клиническая валидация, энергии — синтез и распределение. Это хороший холодный душ для тех, кто продолжает верить, что ещё один скачок параметров решит всё. Не решит.
2️⃣ Мир слишком аналоговый, грязный и дорогой.
Третий редлайн — конвергенция. Они не мыслят «ИИ в отрыве от всего». Там всё время склеивается: связь ⇔ вычисления ⇔ энергия ⇔ материалы ⇔ автономные машины ⇔ биология и связанные с этим риски. Это неприятно для людей, которые хотят простых историй уровня «мы внедрим ИИ в процесс и станет хорошо». Нет, станет сложнее. Вероятностный слой управления, встроенный в критическую инфраструктуру, умножает поверхность атаки, резко усложняет верификацию и размывает ответственность. И это как раз то место, которое вызывает больше всего вопросов в визионерских роадмапах. Там обычно красиво рисуют «появится автономность», но редко считают цену отказа, цену ошибки и цену злоупотребления.
3️⃣ Эти цены в реальности и определяют, что будет внедрено, а что останется слайдами в докладе.
Четвёртое — «агентный интернет», как смена субъектности. Здесь явно описывается будущее, где основными активными участниками сети являются ИИ-агенты: они торгуются, планируют, согласуют, управляют ресурсами. Это выглядит логичным продолжением автоматизации, но здесь же сидит и главный риск: когда «действуют агенты», границы безопасности и доверия перестают быть вопросами периметра.
4️⃣ Они становятся вопросами протоколов взаимодействия и формальных ограничений на поведение агентов.
Наивно полагать что сегодняшние проблемы с безопасностью исчерпали весь свой потенциал. Мы просто пока не доросли до уровня, где главными дефектами являются действия агентов, а не огрехи кода или инфры. Уязвимость агентной логики... ммм, точно будет весело
И последнее — символическая дата здесь вторична. Ценность доклада не в точности прогнозов (она наверняка будет околонулевая), а в том, что он показывает именно инженерную картину мира: не «сделаем прорыв», а «соберём систему из взаимодополняющих элементов».
5️⃣ По-другому — большие технологические эпохи и не собираются.
Иначе, он так и останется лишь дорогой игрушкой для красивых презентаций.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤2👍1🤨1
Go разработчики постоянно сталкиваются с предупреждениями встроенного статического анализатора. А что делать, если его возможностей не хватает или нужно искать что-то специфичное для вашего проекта? Go предоставляет мощные инструменты для разбора и анализа кода. В этой статье мы поговорим о них и даже сделаем своё первое диагностическое правило.
Кстати говоря, я думаю вы уже поняли, что мы разрабатываем свой статический анализатор для Go. Если вы хотите поучаствовать в EAP, то следите за нашими новостями.
PVS-Studio
Как сделать свой статический анализатор для Go?
Go разработчики постоянно сталкиваются с предупреждениями встроенного статического анализатора. А что делать, если его возможностей не хватает или нужно искать что-то специфичное для вашего проекта...
Forwarded from PVS-Studio: поиск ошибок в С/С++, С# и Java
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣4❤1
Forwarded from Технологический Болт Генона
Про статический анализатор конфигов Nginx от Яндекс (https://github.com/yandex/gixy) я пару раз упоминал у себя на канале, но уже давненько
2019
https://t.iss.one/tech_b0lt_Genona/890
2021
https://t.iss.one/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
Как и много лет назад я рекомендую к использованию такие инструменты.
2019
https://t.iss.one/tech_b0lt_Genona/890
2021
https://t.iss.one/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
Как и много лет назад я рекомендую к использованию такие инструменты.
👍1🤨1
Узнал из поста в TG канале Swordfish Security.
В самом конце 2025 года информационным письмом №ИН-017-56/118 Банк России опубликовал обновленный методический документ "Профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций".
Кто о чём, а мне больше всего интересны отсылки к РБПО, статическому анализу кода и соответствующим стандартам. Пересечение большое.
Во-первых, описываемый процесс разработки безопасного ПО адаптирован под ГОСТ 56939-2024.
Во-вторых, прописано необходимость использования статических анализаторов кода, что логично, т.к. это 10-й процесс ГОСТ 56939-2024. При этом, хотя я не нашёл в документе упоминание ГОСТ Р 71207-2024 "Статический анализ программного обеспечения", он оказал влияние и видны заимствования оттуда.
Например, говорится, что инструменты статического анализа должны реализовывать следующие методы анализа:
Это ровно то, что перечисляется в разделе 7.4. ГОСТ Р 71207-2024. Можно только отметить, что про "межпроцедурный и межмодульный контекстно-чувствительный анализ помеченных данных" сказано и другими словами:
В общем, ГОСТ Р 56939-2024 и ГОСТ Р 71207-2024 будут всё активнее влиять на подходы к разработке ПО. Уместно, ещё вспомнить и приказ ФСТЭК №117.
P.S. Хотите организовывать статический анализ по ГОСТ – используйте PVS-Studio :)
В самом конце 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 :)
👍3🔥2👨💻1👀1
Мы иногда во внутреннем чате обмениваемся фрагментами кода с неочевидными ошибками, которые обнаруживаются с помощью PVS-Studio в каком-нибудь открытом проекте. Мол, кто быстро сообразит, что не так с кодом?
Вчера коллега поделился вот таким фрагментом кода из проекта SereneDB:
Признаюсь честно, я два раза прочитал этот фрагмент, но так и не увидел ошибку. И засчитал себе поражение. Раз так, думаю, это достойно публикации в канал, чтобы и вы могли испытать свою внимательность :)
Ответ:
Анализатор PVS-Studio выдаёт предупреждение V591 Non-void function should return a value. parameters.h 222
На первый взгляд предупреждение странное и смахивает на ложное срабатывание, ведь не может быть, что функция закончила работу, не вернув значение с помощью оператора . Если выбирается ветка , то там , и код просто не должен скомпилироваться. Во всех остальных случаях есть .
Но есть нюанс!
Ещё раз посмотрите на эту строчку:
static_assert используется неправильно: пропущен . Вернее, строковый литерал неявно конвертируется в значение , и никогда не прервёт компиляцию. В итоге else-ветка функции ничего не возвращает, и её поведение будет не определено для всех специализаций , кроме указанных ранее в цепочке .
Правильный вариант:
Вчера коллега поделился вот таким фрагментом кода из проекта 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");
}
}
....
};
Признаюсь честно, я два раза прочитал этот фрагмент, но так и не увидел ошибку. И засчитал себе поражение. Раз так, думаю, это достойно публикации в канал, чтобы и вы могли испытать свою внимательность :)
Ответ:
На первый взгляд предупреждение странное и смахивает на ложное срабатывание, ведь не может быть, что функция закончила работу, не вернув значение с помощью оператора
returnelsestatic_assertreturn "что-то";Но есть нюанс!
Ещё раз посмотрите на эту строчку:
static_assert("unsupported ValueType");bool-constexprtruestatic_assertNumericParameterif constexprПравильный вариант:
static_assert(false, "unsupported ValueType");
🔥17
Продолжаем цикл вебинаров по РБПО. Хотя скорее уже заканчиваем, так как осталось рассмотреть два процесса. Дополнительно будет пара бонусных вебинаров, но всё равно марафон подходит к завершению.
Сегодня 21.01 в 16:00 ждём вас на "Процесс 24. Поиск уязвимостей в программном обеспечении при эксплуатации". Смотреть записи прошедших вебинаров и участвовать в новых.
P.S. Скоро возобновляем встречи клуба С++ программистов в Москве "Сплошные плюсы". Приглашаем докладчиков. Контакт для тех кто хочет что-то рассказать на тему C++: Волкова Дарья - Telegram: @daryavolkovaa
Сегодня 21.01 в 16:00 ждём вас на "Процесс 24. Поиск уязвимостей в программном обеспечении при эксплуатации". Смотреть записи прошедших вебинаров и участвовать в новых.
P.S. Скоро возобновляем встречи клуба С++ программистов в Москве "Сплошные плюсы". Приглашаем докладчиков. Контакт для тех кто хочет что-то рассказать на тему C++: Волкова Дарья - Telegram: @daryavolkovaa
🔥5👍3
Обновлённое подробное описание PVS-Studio на начало 2026 года с точки зрения
• ГОСТ Р 71207—2024 — Статический анализ программного обеспечения,
• ГОСТ Р 56939—2024 — РБПО,
• приказа ФСТЭК №117,
• и т.д.
P.S. Команда PVS-Studio будет со стендом на ТБ Форум 2026 (18—20 февраля 2026, МВЦ "Крокус Экспо", павильон 2, зал 10). Я там тоже буду. Приходите задавать вопросы на тему публикации, стандартов и вообще.
• ГОСТ Р 71207—2024 — Статический анализ программного обеспечения,
• ГОСТ Р 56939—2024 — РБПО,
• приказа ФСТЭК №117,
• и т.д.
P.S. Команда PVS-Studio будет со стендом на ТБ Форум 2026 (18—20 февраля 2026, МВЦ "Крокус Экспо", павильон 2, зал 10). Я там тоже буду. Приходите задавать вопросы на тему публикации, стандартов и вообще.
PVS-Studio
Статический анализатор кода PVS-Studio в 2026: ГОСТ Р 71207, ГОСТ Р 56939, приказ ФСТЭК №117
Инструментальное средство PVS-Studio разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207—2024. Выявляет критические ошибки и может использоваться при...
🔥6
Бестиарий программирования pinned «Обновлённое подробное описание PVS-Studio на начало 2026 года с точки зрения • ГОСТ Р 71207—2024 — Статический анализ программного обеспечения, • ГОСТ Р 56939—2024 — РБПО, • приказа ФСТЭК №117, • и т.д. P.S. Команда PVS-Studio будет со стендом на ТБ Форум…»