SAST и DAST спешат на помощь (часть 3 из 3)
При этом такую ошибку можно моментально обнаружить с помощью статического или динамического анализа.
Статический анализатор PVS-Studio сразу предупреждает об аномалии в коде с помощью сообщения: V742 Function receives an address of a 'char' type variable instead of pointer to a buffer. Inspect the first argument.
Или достаточно воспользоваться динамическим анализом. AddressSanitizer (gcc ключ: fsanitize=address). Он сразу покажет проблему уже на первом самом простом тесте
Юнит-тесты и динамический анализ работают в паре. Санитайзер обнаруживает проблему на этапе запуска юнит-теста. Не будет теста — ошибка всплывёт гораздо позже.
Заключение
Статический и динамический анализ хорошо дополняют юнит-тесты и другие методы выявления ошибок. При этом нет какого-то лучшего метода или инструмента. Статические и динамические анализаторы имеют свои слабые стороны и дополняют друг друга. В свою очередь, юнит-тесты могут выявить ошибки в логике, где, скорее всего, будут бессильны анализаторы.
Используйте всё. По началу это потребует вложений, но со временем окупит себя ранним выявлением большого процента багов на самых ранних этапах разработки. Чем раньше ошибка обнаружена, тем проще и дешевле её исправление (подход shift-left testing).
При этом такую ошибку можно моментально обнаружить с помощью статического или динамического анализа.
Статический анализатор PVS-Studio сразу предупреждает об аномалии в коде с помощью сообщения: V742 Function receives an address of a 'char' type variable instead of pointer to a buffer. Inspect the first argument.
Или достаточно воспользоваться динамическим анализом. AddressSanitizer (gcc ключ: fsanitize=address). Он сразу покажет проблему уже на первом самом простом тесте
Test1.Юнит-тесты и динамический анализ работают в паре. Санитайзер обнаруживает проблему на этапе запуска юнит-теста. Не будет теста — ошибка всплывёт гораздо позже.
Заключение
Статический и динамический анализ хорошо дополняют юнит-тесты и другие методы выявления ошибок. При этом нет какого-то лучшего метода или инструмента. Статические и динамические анализаторы имеют свои слабые стороны и дополняют друг друга. В свою очередь, юнит-тесты могут выявить ошибки в логике, где, скорее всего, будут бессильны анализаторы.
Используйте всё. По началу это потребует вложений, но со временем окупит себя ранним выявлением большого процента багов на самых ранних этапах разработки. Чем раньше ошибка обнаружена, тем проще и дешевле её исправление (подход shift-left testing).
👍7
Раздутый C++ код (часть 1 из 2)
Есть такая старая программистская байка, что нельзя платить программистам за строки кода, так как тогда они будут писать длинный бестолковый код и любить метод copy-paste. Будущее наступило. Этими "программистами" является генеративный ИИ (GenAI), которому как раз платят за строки кода.
Я проверил VibeTensor с помощью статического анализатора PVS-Studio, а также посмотрел С++ код глазами. Было интересно узнать, как много ошибок в нём можно найти с помощью классического обзора кода и статического анализа.
Так вот, у меня нет ответа на этот вопрос. Непонятно, потому что главная проблема этого кода в том, что он ужасно раздут. Это сильно мешает его обзору. Мне тяжело продираться сквозь это болото, а вместе со мной "вязнет" и статический анализатор.
Впрочем, ожидать большого количества ошибок здесь тоже не стоит: по-настоящему полезного кода в этом проекте кот наплакал. Как же так? Проект вроде не такой уж маленький. Проанализированных C++ файлов более 400, а количество строк кода — около 100,000.
Да, но это только кажется, что там есть что смотреть и анализировать. Повторюсь: основная проблема качества этого кода — его избыточность. Она выражена как в постоянном повторении блоков кода, так и просто в бессмысленных лишних действиях, растягивающих код.
Раньше бы сказали, что этот проект писался методом copy-paste. В данном случае это не так, но генерация кода приводит ровно к таким же последствиям. Вместо выноса обобщённой функциональности в функции, вновь и вновь генерируется код для решения схожим проблем.
Например, я уже писал в статье "C++: Пиши, сокращай, оптимизируй", про блок кода, который встречается 9 раз и при этом сам растянут. Скоро напишу другую статью, а пока рассмотрю ещё один пример.
Есть такая старая программистская байка, что нельзя платить программистам за строки кода, так как тогда они будут писать длинный бестолковый код и любить метод copy-paste. Будущее наступило. Этими "программистами" является генеративный ИИ (GenAI), которому как раз платят за строки кода.
Я проверил VibeTensor с помощью статического анализатора PVS-Studio, а также посмотрел С++ код глазами. Было интересно узнать, как много ошибок в нём можно найти с помощью классического обзора кода и статического анализа.
Так вот, у меня нет ответа на этот вопрос. Непонятно, потому что главная проблема этого кода в том, что он ужасно раздут. Это сильно мешает его обзору. Мне тяжело продираться сквозь это болото, а вместе со мной "вязнет" и статический анализатор.
Впрочем, ожидать большого количества ошибок здесь тоже не стоит: по-настоящему полезного кода в этом проекте кот наплакал. Как же так? Проект вроде не такой уж маленький. Проанализированных C++ файлов более 400, а количество строк кода — около 100,000.
Да, но это только кажется, что там есть что смотреть и анализировать. Повторюсь: основная проблема качества этого кода — его избыточность. Она выражена как в постоянном повторении блоков кода, так и просто в бессмысленных лишних действиях, растягивающих код.
Раньше бы сказали, что этот проект писался методом copy-paste. В данном случае это не так, но генерация кода приводит ровно к таким же последствиям. Вместо выноса обобщённой функциональности в функции, вновь и вновь генерируется код для решения схожим проблем.
Например, я уже писал в статье "C++: Пиши, сокращай, оптимизируй", про блок кода, который встречается 9 раз и при этом сам растянут. Скоро напишу другую статью, а пока рассмотрю ещё один пример.
👍3
Раздутый C++ код (часть 2 из 2)
А вот другой пухлый код, где PVS-Studio выдаёт сразу три предупреждения:
• V547 [CWE-570] Expression 'is_empty' is always false. tensor_bindings.cc 3007
• V547 [CWE-570] Expression 'print_size' is always false. tensor_bindings.cc 3015
• V547 [CWE-571] Expression '!parts.empty()' is always true. tensor_bindings.cc 3023
Код, на который выданы предупреждения, на первый взгляд умный, с массивом, с циклом... А если присмотреться — лабуда.
Если присмотреться получше, то всё это можно сократить в три раза:
Вот что здесь интересно: если рассуждать об анализе исходного варианта, то вроде как ошибок не находится. Код сложный, правильно работает, выхода за границу массива нет. Почтение к ИИ.
Когда же код схлопывается до своей сути, то понимаешь, что там и ошибаться то негде. Он просто написан длиннее. Не к чему тут относиться с почтением.
Итого: нет в проекте никаких настоящих 100,000 строк С++ кода. Думаю, что если вынести дубликаты в функции и провести рефакторинг, количество кода сократится раз в 5. Проект на 20,000 строк кода — это баловство. Вот и вижу в нём не ошибки, а проблему раздутого кода и предупреждения анализатора про большое количество ложных/истинных условий и т.п.
А вот другой пухлый код, где PVS-Studio выдаёт сразу три предупреждения:
• V547 [CWE-570] Expression 'is_empty' is always false. tensor_bindings.cc 3007
• V547 [CWE-570] Expression 'print_size' is always false. tensor_bindings.cc 3015
• V547 [CWE-571] Expression '!parts.empty()' is always true. tensor_bindings.cc 3023
Код, на который выданы предупреждения, на первый взгляд умный, с массивом, с циклом... А если присмотреться — лабуда.
bool is_empty = false; // handled above; always false here
bool print_size = is_empty && (self.sizes().size() != 1);
bool suppress_dtype_non_empty = (!is_empty) &&
(self.dtype() == ScalarType::Float32 ||
self.dtype() == ScalarType::Int64 ||
self.dtype() == ScalarType::Bool);
bool print_dtype = !suppress_dtype_non_empty;
if (is_empty) {
// For empty tensors, only print dtype when dtype != default float32
print_dtype = (self.dtype() != ScalarType::Float32);
}
std::string out = "tensor(";
out += body;
std::vector<std::string> parts;
if (print_size) {
parts.push_back(std::string("size=") + format_sizes(self.sizes()));
}
if (print_dtype) {
parts.push_back(std::string("dtype=") + dtype_name(self.dtype()));
}
// Always include device suffix for CUDA tensors
parts.push_back(std::string("device='cuda:") +
std::to_string((int)self.device().index) + "'");
if (!parts.empty()) {
out += ", ";
for (std::size_t i = 0; i < parts.size(); ++i) {
if (i) out += ", ";
out += parts[i];
}
}
out += ")";
return out;
Если присмотреться получше, то всё это можно сократить в три раза:
std::string out = "tensor(" + body + ", ";
if (self.dtype() != ScalarType::Float32 &&
self.dtype() != ScalarType::Int64 &&
self.dtype() != ScalarType::Bool)
{
out += std::string("dtype=") + dtype_name(self.dtype()) + ", ";
}
out += "device='cuda:" + std::to_string((int)self.device().index) + "')";
return out;Вот что здесь интересно: если рассуждать об анализе исходного варианта, то вроде как ошибок не находится. Код сложный, правильно работает, выхода за границу массива нет. Почтение к ИИ.
Когда же код схлопывается до своей сути, то понимаешь, что там и ошибаться то негде. Он просто написан длиннее. Не к чему тут относиться с почтением.
Итого: нет в проекте никаких настоящих 100,000 строк С++ кода. Думаю, что если вынести дубликаты в функции и провести рефакторинг, количество кода сократится раз в 5. Проект на 20,000 строк кода — это баловство. Вот и вижу в нём не ошибки, а проблему раздутого кода и предупреждения анализатора про большое количество ложных/истинных условий и т.п.
👏4
Forwarded from feelin (Valerii Filatov)
GuardConf 2026
12 ноября этого года в Москве пройдёт конференция GuardConf 2026, посвящённая разработке и защите софта.
В этом году я состою в программном комитете, и мы с коллегами прямо сейчас собираем программу — на прошлой неделе открыли Call For Papers. Если есть практический опыт, которым хочется поделиться, можно податься с докладом на один из двух треков:
• Инструменты разработчика: качество кода, инженерные практики, автоматизация, безопасность, Open Source, производительность, AI и другие инструменты.
• Стратегия и управление: архитектура, технический долг, масштабирование систем и команд, процессы разработки, AI в инженерных процессах.
Подробнее про конференцию можно прочитать на сайте, там же уже открыта форма регистрации. А по поводу спикерства можно написать мне напрямую.
Увидимся в ноябре!
🎤 feelin
12 ноября этого года в Москве пройдёт конференция GuardConf 2026, посвящённая разработке и защите софта.
В этом году я состою в программном комитете, и мы с коллегами прямо сейчас собираем программу — на прошлой неделе открыли Call For Papers. Если есть практический опыт, которым хочется поделиться, можно податься с докладом на один из двух треков:
• Инструменты разработчика: качество кода, инженерные практики, автоматизация, безопасность, Open Source, производительность, AI и другие инструменты.
• Стратегия и управление: архитектура, технический долг, масштабирование систем и команд, процессы разработки, AI в инженерных процессах.
Подробнее про конференцию можно прочитать на сайте, там же уже открыта форма регистрации. А по поводу спикерства можно написать мне напрямую.
Увидимся в ноябре!
Please open Telegram to view this post
VIEW IN TELEGRAM
guardconf.ru
Guardconf 2026. Для команд, создающих софт
Конференция для CTO, CPO, руководителей разработки, разработчиков и продуктовых команд. 12 ноября в Москве разберем технологии, инструменты и практические решения для развития программных продуктов, их защиты и монетизации.
🔥3👍1
Forwarded from PVS-Studio: поиск ошибок в коде
На следующей неделе сразу два интересных вебинара 🔥
1️⃣ Как разговорить человека и договориться
Small talk — это не просто короткая беседа, а способ устанавливать контакт, создавать доверие и открывать новые возможности для общения. На вебинаре разберём, как легко начинать и поддерживать такие разговоры, а также как использовать small talk в рабочих ситуациях — от нетворкинга и новых знакомств до сложных обсуждений, переговоров и договорённостей.
🗓 27 августа в 14:00
Регистрация по ссылке🔗
2️⃣ Агенты пишут код, а кто его проверяет?
Третий вебинар цикла "Качество и безопасность ПО в эпоху GenAI". Мы разберём, как выглядит работа с агентами в продакшене уже сегодня: от планирования и итераций до ревью, файлов-памяти и автоматизации проверки кода, а также обсудим, как контролировать результат такой разработки.
🗓 28 августа в 15:00
Регистрация по ссылке🔗
Присоединяйтесь и приглашайте коллег!
📲 Мы в MAX
#вебинар #ai #smalltalk
1️⃣ Как разговорить человека и договориться
Small talk — это не просто короткая беседа, а способ устанавливать контакт, создавать доверие и открывать новые возможности для общения. На вебинаре разберём, как легко начинать и поддерживать такие разговоры, а также как использовать small talk в рабочих ситуациях — от нетворкинга и новых знакомств до сложных обсуждений, переговоров и договорённостей.
🗓 27 августа в 14:00
Регистрация по ссылке
2️⃣ Агенты пишут код, а кто его проверяет?
Третий вебинар цикла "Качество и безопасность ПО в эпоху GenAI". Мы разберём, как выглядит работа с агентами в продакшене уже сегодня: от планирования и итераций до ревью, файлов-памяти и автоматизации проверки кода, а также обсудим, как контролировать результат такой разработки.
🗓 28 августа в 15:00
Регистрация по ссылке
Присоединяйтесь и приглашайте коллег!
#вебинар #ai #smalltalk
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Бестиарий программирования
Раздутый C++ код (часть 2 из 2) А вот другой пухлый код, где PVS-Studio выдаёт сразу три предупреждения: • V547 [CWE-570] Expression 'is_empty' is always false. tensor_bindings.cc 3007 • V547 [CWE-570] Expression 'print_size' is always false. tensor_bindings.cc…
Расписал эту тему поподробнее: Опухший C++ код
👍3
Сегодня День рождения моего любимого писателя Говарда Филлипса Лавкрафта. В его честь я позволю себе шалость и презентую обзор материалов по РБПО в его литературном стиле. Заодно пригодится тем, кто пропустил предыдущие посты про РБПО-вебинары. Встречайте неименуемый ужас творений беспечных программистов.
В тёмных коридорах современной разработки ПО, куда редко проникает свет тестирования и куда не доносится эхо код-ревью, зародилось нечто. Оно притаилось в недрах непроверенных библиотек. Нечто, что шепчет сквозь строки небезопасного кода. Древние именовали это Багом. Современные адепты тайных знаний зовут Уязвимостью.
Долгие годы человеческие умы пытались объять необъятное — описать ритуалы, способные защитить творения рук наших от порождений Хаоса. Так в 2016 году был создан первый фолиант — ГОСТ Р 56939, призванный оградить код от тварей из бездны. Но время шло, и Древние Стандарты ветшали. Они молчали о кошмарах цепочек поставок, о тёмной магии CI/CD, о незримой Поверхности Атаки, сквозь которую сущности извне проникают в наш мир.
И тогда, в конце 2024 года, был явлен новый манускрипт — ГОСТ Р 56939–2024 «Разработка безопасного программного обеспечения», начертанный коллективным разумом посвящённых в тайны РБПО.
Перед вами не просто выжимка. Это ключ к запретному знанию, запертому на странице сайта древних Единорогов. Это труд жреца статического анализа из ордена PVS-Studio, который осмелился не просто прочесть Писания, но и сопроводить их голосами тридцати экспертов, чьи разумы соприкоснулись с Истиной.
Узрите! Разработка безопасного программного обеспечения (РБПО) по ГОСТ Р 56939—2024!
Новый ГОСТ говорит нам о 25 процессах. Не об абстрактных идеях, а о конкретных ритуалах, каждый из которых — это грань защитного пентакля, оберегающего ваше творение от Хаоса.
О тех, кто должен познать страх (процессы 1–2: Планирование и Обучение). Безумец тот, кто решит, что способен в одиночку противостоять Тьме. Фолиант гласит: внедрение обрядов безопасности потребует ресурсов. 10–15% бюджета — такова цена жертвы, которую нужно принести, чтобы ваша команда не стала слепыми котятами, играющими с неведомыми силами. В полном тексте хроник вы найдёте отсылки к курсам, чтобы ваши адепты не накликали беду неосторожным заклинанием.
Картография незримого (процессы 6–7: Архитектура и Поверхность Атаки). Самые страшные угрозы проникают не через щели в коде, а через изъяны в фундаменте вашего творения. Гайд научит вас видеть незримое — определять ту самую Поверхность Атаки, через которую Древнее Зло может просочиться в реальность. Ибо бессмысленно проверять каждую строку, если дверь в подвал распахнута настежь. В полном тексте — откровения о taint-анализе и инструменте Natch, чьё имя звучит как шёпот ангела во тьме.
Некрономикон кодирования (процессы 8–10: Правила, Экспертиза и Статический анализ). Код, написанный без правил, подобен безумным письменам на стенах Жёлтых домов. Даже несовершенный стандарт лучше, чем хаос, где каждая переменная названа именем Древнего Бога. Гайд поведает о «форматировании таблицей» — древнем заклинании против опечаток, и о том, как Статический Анализ (вкупе с фолиантом ГОСТ Р 71207–2024) становится вашим всевидящим оком, способным узреть дефекты там, где человеческий разум меркнет.
Скверна цепочки поставок (процессы 16–17). Величайший ужас современности таится не в вашем коде, а в том, что вы заимствуете у чужих культов. Зловещие артефакты, проникающие под видом безобидных библиотек, — вот истинный лик страха. Треть кошмаров из списка OWASP Top 10 — это порождения данной скверны. Познайте суть SCA, поиска закладок и атак через галлюцинации ИИ. Узрите сущности в лучах сверкающего CodeScoring.
…и это лишь начало. Остальные главы Послания охватывают ужасы фаззинг-тестирования, кошмар неправильной сборки, муки проигнорированных уязвимостей и даже мрачный ритуал вывода ПО из эксплуатации, когда нужно уничтожить все следы, чтобы никто не вызвал то, что спало.
Ф’нглуи мглв’нафх РБПО Р’льех вгах’нагл фхтагн!
В тёмных коридорах современной разработки ПО, куда редко проникает свет тестирования и куда не доносится эхо код-ревью, зародилось нечто. Оно притаилось в недрах непроверенных библиотек. Нечто, что шепчет сквозь строки небезопасного кода. Древние именовали это Багом. Современные адепты тайных знаний зовут Уязвимостью.
Долгие годы человеческие умы пытались объять необъятное — описать ритуалы, способные защитить творения рук наших от порождений Хаоса. Так в 2016 году был создан первый фолиант — ГОСТ Р 56939, призванный оградить код от тварей из бездны. Но время шло, и Древние Стандарты ветшали. Они молчали о кошмарах цепочек поставок, о тёмной магии CI/CD, о незримой Поверхности Атаки, сквозь которую сущности извне проникают в наш мир.
И тогда, в конце 2024 года, был явлен новый манускрипт — ГОСТ Р 56939–2024 «Разработка безопасного программного обеспечения», начертанный коллективным разумом посвящённых в тайны РБПО.
Перед вами не просто выжимка. Это ключ к запретному знанию, запертому на странице сайта древних Единорогов. Это труд жреца статического анализа из ордена PVS-Studio, который осмелился не просто прочесть Писания, но и сопроводить их голосами тридцати экспертов, чьи разумы соприкоснулись с Истиной.
Узрите! Разработка безопасного программного обеспечения (РБПО) по ГОСТ Р 56939—2024!
Новый ГОСТ говорит нам о 25 процессах. Не об абстрактных идеях, а о конкретных ритуалах, каждый из которых — это грань защитного пентакля, оберегающего ваше творение от Хаоса.
О тех, кто должен познать страх (процессы 1–2: Планирование и Обучение). Безумец тот, кто решит, что способен в одиночку противостоять Тьме. Фолиант гласит: внедрение обрядов безопасности потребует ресурсов. 10–15% бюджета — такова цена жертвы, которую нужно принести, чтобы ваша команда не стала слепыми котятами, играющими с неведомыми силами. В полном тексте хроник вы найдёте отсылки к курсам, чтобы ваши адепты не накликали беду неосторожным заклинанием.
Картография незримого (процессы 6–7: Архитектура и Поверхность Атаки). Самые страшные угрозы проникают не через щели в коде, а через изъяны в фундаменте вашего творения. Гайд научит вас видеть незримое — определять ту самую Поверхность Атаки, через которую Древнее Зло может просочиться в реальность. Ибо бессмысленно проверять каждую строку, если дверь в подвал распахнута настежь. В полном тексте — откровения о taint-анализе и инструменте Natch, чьё имя звучит как шёпот ангела во тьме.
Некрономикон кодирования (процессы 8–10: Правила, Экспертиза и Статический анализ). Код, написанный без правил, подобен безумным письменам на стенах Жёлтых домов. Даже несовершенный стандарт лучше, чем хаос, где каждая переменная названа именем Древнего Бога. Гайд поведает о «форматировании таблицей» — древнем заклинании против опечаток, и о том, как Статический Анализ (вкупе с фолиантом ГОСТ Р 71207–2024) становится вашим всевидящим оком, способным узреть дефекты там, где человеческий разум меркнет.
Скверна цепочки поставок (процессы 16–17). Величайший ужас современности таится не в вашем коде, а в том, что вы заимствуете у чужих культов. Зловещие артефакты, проникающие под видом безобидных библиотек, — вот истинный лик страха. Треть кошмаров из списка OWASP Top 10 — это порождения данной скверны. Познайте суть SCA, поиска закладок и атак через галлюцинации ИИ. Узрите сущности в лучах сверкающего CodeScoring.
…и это лишь начало. Остальные главы Послания охватывают ужасы фаззинг-тестирования, кошмар неправильной сборки, муки проигнорированных уязвимостей и даже мрачный ритуал вывода ПО из эксплуатации, когда нужно уничтожить все следы, чтобы никто не вызвал то, что спало.
Ф’нглуи мглв’нафх РБПО Р’льех вгах’нагл фхтагн!
🔥12😁7
Записи двух новых вебинара. Первый, продолжение смежных с РБПО тем – рассматриваем инструменты и подходы. Гостем стал Алексей Дьяков из Guardant и рассказал о защите ПО (противодействию пиратству).
Второй вебинар о том, как ставить грамотные цели и достигать их. Гость – Александр Швец (CTO Авито Товары).
Мы открыты к сотрудничеству и приглашаем гостей для участия в вебинарах, посвященных GameDev, управлению командой, GenAI т.д. Подробнее.
Второй вебинар о том, как ставить грамотные цели и достигать их. Гость – Александр Швец (CTO Авито Товары).
Мы открыты к сотрудничеству и приглашаем гостей для участия в вебинарах, посвященных GameDev, управлению командой, GenAI т.д. Подробнее.
⚡4
Релиз PVS-Studio 8.00 с поддержкой языков Go, JS, TS
Мы выпустили восьмую версию PVS-Studio, где расширен список анализируемых языков программирования:
C, C++, C#, Java, Go, JavaScript, TypeScript.
PVS-Studio разрабатывается компанией ООО "ПВС", основанной в 2008 году. Сведения о PVS-Studio включены в единый реестр российских программ для ЭВМ и баз данных на основании приказа Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 18.03.2021 №156, запись в реестре №9837 от 18.03.2021.
Инструментальное средство PVS-Studio разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207-2024. Уровень совместимости с отраслевым стандартом зависит от языка.
C, C++, C#, Java
Статический анализатор кода PVS-Studio для языков C, C++, C# и Java удовлетворяет функциональным требованиям к инструментам, требуемых для проведения исследований согласно разделу 4.2 «Статический анализ объекта оценки (САО)» методического документа «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении» (утверждён ФСТЭК России 12 мая 2026 г.) для 6, 5 и 4 уровня доверия (по 3, 2 и 1 уровню информация будет представлена позже).
В том числе PVS-Studio соответствует дополнительным требованиям к исследованиям (усиления) для 4-го уровня доверия, заключающихся в соответствии требованиям ГОСТ Р 71207-2024 «Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования».
PVS-Studio выявляет критические ошибки и может использоваться при разработке безопасного программного обеспечения согласно требованиям ГОСТ Р 56939-2024.
Go, JavaScript, TypeScript
На данный момент реализованы легковесные движки анализаторов для этих языков. В первой редакции анализаторы содержат по 41 диагностическому правилу, CLI для каждого анализатора, а также плагины для интегрированных сред разработки WebStorm и GoLand.
Некоторые другие новшества
Добавлена поддержка компиляторов kcc ARMV7 и TI C2000-CGT на всех платформах с помощью мониторинга/трассировки компиляции.
Появилась поддержка плагина PVS-Studio для Qt Creator версий 20.x.
Вскоре стартует программа раннего доступа Atlas Server, платформы для автоматической проверки качества и безопасности исходного кода.
Ссылки:
1. Все варианты загрузки PVS-Studio.
2. Запросить триальный ключ.
3. Раздел о сертификации.
4. Контакты: форма обратной связи / запросить ВКС / телефон +7(903)844-02-22.
Мы выпустили восьмую версию PVS-Studio, где расширен список анализируемых языков программирования:
C, C++, C#, Java, Go, JavaScript, TypeScript.
PVS-Studio разрабатывается компанией ООО "ПВС", основанной в 2008 году. Сведения о PVS-Studio включены в единый реестр российских программ для ЭВМ и баз данных на основании приказа Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 18.03.2021 №156, запись в реестре №9837 от 18.03.2021.
Инструментальное средство PVS-Studio разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207-2024. Уровень совместимости с отраслевым стандартом зависит от языка.
C, C++, C#, Java
Статический анализатор кода PVS-Studio для языков C, C++, C# и Java удовлетворяет функциональным требованиям к инструментам, требуемых для проведения исследований согласно разделу 4.2 «Статический анализ объекта оценки (САО)» методического документа «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении» (утверждён ФСТЭК России 12 мая 2026 г.) для 6, 5 и 4 уровня доверия (по 3, 2 и 1 уровню информация будет представлена позже).
В том числе PVS-Studio соответствует дополнительным требованиям к исследованиям (усиления) для 4-го уровня доверия, заключающихся в соответствии требованиям ГОСТ Р 71207-2024 «Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования».
PVS-Studio выявляет критические ошибки и может использоваться при разработке безопасного программного обеспечения согласно требованиям ГОСТ Р 56939-2024.
Go, JavaScript, TypeScript
На данный момент реализованы легковесные движки анализаторов для этих языков. В первой редакции анализаторы содержат по 41 диагностическому правилу, CLI для каждого анализатора, а также плагины для интегрированных сред разработки WebStorm и GoLand.
Некоторые другие новшества
Добавлена поддержка компиляторов kcc ARMV7 и TI C2000-CGT на всех платформах с помощью мониторинга/трассировки компиляции.
Появилась поддержка плагина PVS-Studio для Qt Creator версий 20.x.
Вскоре стартует программа раннего доступа Atlas Server, платформы для автоматической проверки качества и безопасности исходного кода.
Ссылки:
1. Все варианты загрузки PVS-Studio.
2. Запросить триальный ключ.
3. Раздел о сертификации.
4. Контакты: форма обратной связи / запросить ВКС / телефон +7(903)844-02-22.
🔥5
Мы обновили информационное письмо и страницу на сайте, посвящённую теме сертификационных испытаний ПО.
👍2🔥2
Красивое.
Код содержит ошибку, но при это работает правильно! :)
Видите, что не так?
Про эту и другие ошибки в пректе ShadPS4.
// Table 8.13 Data and Image Formats
//[Sea Islands Series Instruction Set Architecture]
//All values are under 64
static const size_t amd_gpu_data_format_bit_size = 6;
//All values are under 16
static const size_t amd_gpu_number_format_bit_size = 4;
static auto surface_format_table = []() constexpr {
std::array<vk::Format,
1 << amd_gpu_data_format_bit_size * 1 << amd_gpu_number_format_bit_size>
result;
for (auto& entry : result) {
entry = vk::Format::eUndefined;
}
for (const auto& supported_format : SurfaceFormats()) {
result[GetSurfaceFormatTableIndex(supported_format.data_format,
supported_format.number_format)] =
supported_format.vk_format;
}
return result;
}();
Код содержит ошибку, но при это работает правильно! :)
Видите, что не так?
Про эту и другие ошибки в пректе ShadPS4.
😁1
Forwarded from PVS-Studio: поиск ошибок в коде
1️⃣ 8 сентября состоится второй вебинар серии "Надежность, качество, безопасность ПО: Методология и инструменты!" — "Автоматизация контроля качества и безопасности ПО".
На примере статического анализа посмотрим, почему Best Practices давно перестали быть недостижимым идеалом. А также разберём, почему контроль должен повторяться вместе с релизом, что меняется в процессе разработки и как облачный контур (на примере Apsafe) встраивает проверки в этот ритм без перестройки CI/CD.
🗓 08.09 в 12:00
Регистрация по ссылке
2️⃣ 9 сентября приглашаем на вебинар "Применение ЗОСРВ "Нейтрино" и PVS-Studio для разработки ПО согласно требованиям МЭК 61508".
На вебинаре разберем подходы к разработке функционально безопасного ПО для ЗОСРВ «Нейтрино» в соответствии с требованиями МЭК 61508 и покажем, какую роль в этом процессе играют инструменты статического анализа.
🗓 09.09 в 12:00
Регистрация по ссылке
3️⃣ 11 сентября будет вебинар "Каждая идиома когда-то была проблемой".
Красивый и надёжный код почти никогда не рождается с первого раза. Сначала появляются ошибки, а уже потом – идиомы, которые помогают их избегать. На вебинаре рассмотрим реальные фрагменты кода из открытых проектов на языке C++, найдем в них проблемные места с помощью статического анализа, и разберём более 10 идиом и паттернов, которые позволят защитить ваш код.
🗓11.09 в 15:00
Регистрация по ссылке
Приглашайте коллег и приходите сами! Ждем вас!
#вебинар #PVS_Studio
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Forwarded from PVS-Studio: поиск ошибок в коде
Анализаторы кода легко и быстро умеют находить множество ошибок, не очевидных с первого взгляда. Попробуйте посоревноваться с PVS-Studio в прозорливости!
Мы сделали новые квизы для языков Go и JS/TS🔥
Вас ждут 10 фрагментов кода, в которых наш анализатор нашёл ошибки. Все они взяты из известных Open Source проектов. Ваша задача — успеть найти ошибку за 60 секунд (не переживайте, фрагменты небольшие).
Время посоревноваться с анализатором! А потом можно и его проверить😉
- Найдите ошибки в JS & TS коде
- Найдите ошибки в Go коде
#квиз #js #ts #go
Мы сделали новые квизы для языков Go и JS/TS
Вас ждут 10 фрагментов кода, в которых наш анализатор нашёл ошибки. Все они взяты из известных Open Source проектов. Ваша задача — успеть найти ошибку за 60 секунд (не переживайте, фрагменты небольшие).
Время посоревноваться с анализатором! А потом можно и его проверить
- Найдите ошибки в JS & TS коде
- Найдите ошибки в Go коде
#квиз #js #ts #go
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Пресс-релиз PVS-Studio 8.00: анализаторы для JavaScript, TypeScript и Go, плагины для WebStorm и GoLand и многое другое.
Обратите внимание на раздел про поиск пасхалок в анализаторе :)
Обратите внимание на раздел про поиск пасхалок в анализаторе :)
🔥1
Подборка:
1) PVS-Studio 8.00: анализаторы JavaScript, TypeScript и Go, новые IDE плагины для WebStorm и GoLand (vk)
2) Go-Go-Gadg...Error? Смотрим, как ошибаются Go разработчики! (vk)
3) Агенты пишут код, а кто его проверяет? (vk)
4) Как разговорить человека и договориться (vk)
1) PVS-Studio 8.00: анализаторы JavaScript, TypeScript и Go, новые IDE плагины для WebStorm и GoLand (vk)
Вышел новый релиз PVS-Studio — 8.00. В нём: новые анализаторы для проектов на JavaScript, TypeScript и Go, новые IDE плагины для WebStorm и GoLand, расширение поддержки MISRA C++ 2023 и другие изменения. Подробнее о них рассказываем в видео!
2) Go-Go-Gadg...Error? Смотрим, как ошибаются Go разработчики! (vk)
В Go разработчики ошибаются как и в любом другом языке: опечатки, дубликаты, нерабочие условия проверок и тому подобное.
Но почему? Ведь многие используют тот же go vet который прекрасно находит всё это… ведь так... да? На вебинаре разобрали частые и типовые ошибки Go разработчиков в известных проектах, а также узнали, какие ошибки не могут найти стандартные инструменты и подходы (и что с этим делать).
3) Агенты пишут код, а кто его проверяет? (vk)
AI-агенты постепенно меняют привычный процесс разработки: человек всё меньше пишет код напрямую и всё больше выступает в роли оркестратора — ставит задачи, направляет агентов, проверяет результат и выстраивает вокруг них целую экосистему инструментов.
4) Как разговорить человека и договориться (vk)
Small talk — это не просто короткая беседа, а способ устанавливать контакт, создавать доверие и открывать новые возможности для общения. На вебинаре разберём, как легко начинать и поддерживать такие разговоры, а также как использовать small talk в рабочих ситуациях — от нетворкинга и новых знакомств до сложных обсуждений, переговоров и договорённостей.
🔥4
Настало время статей про баги в открытых проектах на TypeScript: Проверка исходников VSCode.
🔥2