Так что, встретив путеводитель Дмитрия Свиридкина по UB на GitHub (ubbook), я с большим любопытством с ним ознакомился. Выписал для себя ряд интересных мыслей, которые со временем станут основой новых диагностических правил. В общем, я получил от чтения и удовольствие, и пользу.
После я задумался. Во-первых, у меня тоже есть кое-что на тему неопределённого поведения. Во-вторых, таким ценным и интересным материалом хочется поделиться с как можно большим количеством программистов, для чего нужно перевести его на английский язык. Впрочем, думал я недолго и решил попробовать реализовать это на практике.
Я связался с Дмитрием и предложил сотрудничество по редактированию, дополнению и переводу его материала. Он согласился, и мы приступили к работе над этой электронной книгой, которую со временем попробуем превратить в печатную. Приглашаю посмотреть, что у нас получилось. Запасайтесь печеньками и вниманием для приятного и вдумчивого чтения.
В общем, перед вами переработанная и расширенная ubbook.
Видел аналогичный вопрос на stackoverflow про Cppcheck (название топика: Why are pointers difficult for static analysis even in simple cases). И пример там схожий был и Cppcheck аналогично баг не находил. Сейчас топик удалён. Не Вы случаем были? :)
А ответ, это не совсем простой пример, как может казаться со стороны. Знаем про такое, будем со временем дорабатывать.
Над этим начинанием пока не работаем, так как собственно как я понимаю совсем недавно прозвучало в анонсах задач ФСТЭК на 2025-2030 год. Я думаю, имеется в виду доклад от ФСТЭК про совершенствование безопасности системного ПО, где говорилось про "развитие набора квалифицированных тестов для инструментов жизненного цикла безопасного ПО". Примем мы какое-то участие во всём этом пока не понятно. Мы просто не знаем, как и что будет.
Другое дело, что мы уже поработали и продолжим работу над лучшим соответствием критерием, изложенным в ГОСТ. Добавим новые детекторы для выявления критических ошибок, можно поработать над анализом косвенных вызовов и так далее.
... ГОСТируют только вещи планируемые к регулировке со стороны государства - зачем регулировать разработку подобной штуки? Затем чтобы применять ее в госсекторе. Как применять ее в госсекторе? Наверное навязывать всем разработчикам задействованным в госсекторе и выполняющим госзаказы...
А я думал, чтобы болты с гайками сходились :)
Прочитай ГОСТ :) Там совершенно адекватные вещи про улучшение процессор разработки ПО. Если не понятна актуальность, что могло быть не так со статическим анализом, то некоторые моменты я здесь разбирал.
Это не так работает. Сейчас в целом идёт тренд на стандартизацию и регулирование процессов безопасной разработки ПО. ГОСТ про статический анализ – это небольшая часть этого процесса. Будут вводиться новые требования и стандарты. Например, буквально вчера 20.12.2024 введён в действие обновлённая версия ГОСТ Р 56939-2024 – Защита информации. Разработка безопасного программного обеспечения. Общие требования.
Странные мысли. Мы 15 лет успешно разрабатываем и продаём PVS-Studio без всяких ГОСТ. Однако, раз уж стандарт появился, странно не обратить на это внимание и не доработать напильником PVS-Studio, чтобы ему соответствовать. Благо хоть это и потребовало несколько месяцев доработок, ничего сверх особенного не пришлось делать. Анализатор уже был мощен, просто нужно было например, классифицировать предупреждения по типу перечисленным там критических ошибок. Естественно такой классификации в инструменте до ГОСТ не существовало и не могло существовать.
Мне кажется, Вы не улавливаете суть анализа помеченных данных. По и отдельности процедуры-источники и процедуры-стоки чувствительных данных могут быть корректны. А при взаимодействии - нет.
Условно говоря, функция записи на диск не виновата, что с её помощью в файл записываете в открытом виде секретный пароль пользователя.
Если открыть первую часть, то можно прочитать :)
В общем, перед вами переработанная и расширенная ubbook.
Плюс перевод на английский.
Да. Я про него и подумал :)
Многословно слишком, NaN какой-то приплетён... Кстати, ради интереса напиши, что если попробовать как-то так сделать:
Кстати, с синтетическими тестами надо быть аккуратными :) Помню была у меня одна старая заметка: Почему я не люблю синтетические тесты. :)
Видел аналогичный вопрос на stackoverflow про Cppcheck (название топика: Why are pointers difficult for static analysis even in simple cases). И пример там схожий был и Cppcheck аналогично баг не находил. Сейчас топик удалён. Не Вы случаем были? :)
А ответ, это не совсем простой пример, как может казаться со стороны. Знаем про такое, будем со временем дорабатывать.
И есть Бесплатная лицензия PVS-Studio для Open Source.
Над этим начинанием пока не работаем, так как собственно как я понимаю совсем недавно прозвучало в анонсах задач ФСТЭК на 2025-2030 год. Я думаю, имеется в виду доклад от ФСТЭК про совершенствование безопасности системного ПО, где говорилось про "развитие набора квалифицированных тестов для инструментов жизненного цикла безопасного ПО". Примем мы какое-то участие во всём этом пока не понятно. Мы просто не знаем, как и что будет.
Другое дело, что мы уже поработали и продолжим работу над лучшим соответствием критерием, изложенным в ГОСТ. Добавим новые детекторы для выявления критических ошибок, можно поработать над анализом косвенных вызовов и так далее.
ГОСТ на болты
А я думал, чтобы болты с гайками сходились :)
Прочитай ГОСТ :) Там совершенно адекватные вещи про улучшение процессор разработки ПО. Если не понятна актуальность, что могло быть не так со статическим анализом, то некоторые моменты я здесь разбирал.
Это не так работает. Сейчас в целом идёт тренд на стандартизацию и регулирование процессов безопасной разработки ПО. ГОСТ про статический анализ – это небольшая часть этого процесса. Будут вводиться новые требования и стандарты. Например, буквально вчера 20.12.2024 введён в действие обновлённая версия ГОСТ Р 56939-2024 – Защита информации. Разработка безопасного программного обеспечения. Общие требования.
Гм.. Раз была лицензия в конторе, так быть может основные ошибки уже были исправлены? :) Ну или вариант, код уже был качественным, что тоже бывает.
Странные мысли. Мы 15 лет успешно разрабатываем и продаём PVS-Studio без всяких ГОСТ. Однако, раз уж стандарт появился, странно не обратить на это внимание и не доработать напильником PVS-Studio, чтобы ему соответствовать. Благо хоть это и потребовало несколько месяцев доработок, ничего сверх особенного не пришлось делать. Анализатор уже был мощен, просто нужно было например, классифицировать предупреждения по типу перечисленным там критических ошибок. Естественно такой классификации в инструменте до ГОСТ не существовало и не могло существовать.
PVS-Studio в контексте РБПО: PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения).
Большой обзор PVS-Studio с точки зрения ГОСТ: PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения).
Это компилируется в C (хотя и с варнингом, GCC: incompatible integer to pointer conversion assigning to 'int *' from 'int' [-Wint-conversion]).
И не компилируется в C++. И это замечательно.
Спасибо.
P.S. У нас ещё есть "Бесплатное использование PVS-Studio студентами и преподавателями" :)
Возьмётесь? :)
Проверяем, но реже.
Проверка компилятора GCC 13 с помощью PVS-Studio.
Проверка компилятора GCC 10 с помощью PVS-Studio.
Мне кажется, Вы не улавливаете суть анализа помеченных данных. По и отдельности процедуры-источники и процедуры-стоки чувствительных данных могут быть корректны. А при взаимодействии - нет.
Условно говоря, функция записи на диск не виновата, что с её помощью в файл записываете в открытом виде секретный пароль пользователя.
Taint-анализ (анализ помеченных данных, taint checking).
Нет. Это выходит далеко за пределы методологии статического анализа кода.
А теперь все 100 больших и маленьких багов в DPDK!