Стоматологические услуги для компиляторов на примере LLVM 21
Прям мини детектив о появлении различных багов :) Рекомендую погрузиться.
И хорошая демонстрация, что статический анализатор PVS-Studio полезен даже самым опытным разработчикам.
Прям мини детектив о появлении различных багов :) Рекомендую погрузиться.
И хорошая демонстрация, что статический анализатор PVS-Studio полезен даже самым опытным разработчикам.
PVS-Studio
Стоматологические услуги для компиляторов на примере LLVM 21
С последней проверки проекта LLVM инструментом PVS-Studio прошло уже больше года и аж два релиза, так что пришло время снова стать трудолюбивой птичкой и покопаться в свежей версии LLVM 21.
👍4
Выложена запись "Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения" из цикла "Вокруг РБПО за 25 вебинаров". Это 20-й процесс ГОСТ Р 56939-2024.
Приглашённый внешний эксперт: Игорь Хмелёв, заместитель директора по специальным разработкам НПО «Эшелон».
Приглашённый внешний эксперт: Игорь Хмелёв, заместитель директора по специальным разработкам НПО «Эшелон».
🔥2
Forwarded from СВД ВС
Безопасность = качество? Часть 2 🔐
В прошлый раз мы говорили про концепцию, которая объясняет финансовую сторону вопроса верификации, мотивирующая внедрять практики РБПО.
Сегодня поговорим про другую концепцию, дополняющую и расширяющую "1:10:100". 💰
Речь о концепции «Shift-left» (или по-русски — «сдвиг-влево»).
📌 В чём суть?
Процесс разработки, по крайней мере в рамках одного цикла (при использовании scrum-методологии например), разворачивается в прямую линию из отдельных этапов.
Упрощённый пример:
Требования (0) → Проектирование (1) → Разработка (2) → Верификация (3) → Внедрение (4) → Работа (5)
Главный принцип:
👉 Чем ближе к этапу №0 внедряются практики безопасности, тем надёжнее и качественнее итоговое решение.
Перейдём к конкретному примеру. Когда вы — молодец?
👍 На этапе требований (0):
Если вы видите небезопасное требование и отбрасываете его, не внося в архитектуру — вы молодец!
👍 На этапе проектирования (1):
Если вы задумываетесь, как каждое архитектурное решение повлияет на безопасность — вы молодец!
👍 На этапе разработки (2):
Если вы используете статический анализ, проводите качественный код-ревью, применяете ручной анализ где нужно и ответственно подходите к использованию opensource-кода — вы молодец!
👍 На этапе верификации (3):
Если вы тестируете продукт на стендах, используя лучшие практики динамического анализа, а не «в полях» — вы молодец!
🎯 Итог:
Да, это всё непросто и требует усилий. Но именно так рождается безопасный продукт, который действительно помогает вашим заказчикам и укрепляет вашу репутацию. 💪
#ДайджестРБПО
В прошлый раз мы говорили про концепцию, которая объясняет финансовую сторону вопроса верификации, мотивирующая внедрять практики РБПО.
Сегодня поговорим про другую концепцию, дополняющую и расширяющую "1:10:100". 💰
Речь о концепции «Shift-left» (или по-русски — «сдвиг-влево»).
📌 В чём суть?
Процесс разработки, по крайней мере в рамках одного цикла (при использовании scrum-методологии например), разворачивается в прямую линию из отдельных этапов.
Упрощённый пример:
Требования (0) → Проектирование (1) → Разработка (2) → Верификация (3) → Внедрение (4) → Работа (5)
Главный принцип:
👉 Чем ближе к этапу №0 внедряются практики безопасности, тем надёжнее и качественнее итоговое решение.
Перейдём к конкретному примеру. Когда вы — молодец?
Если вы видите небезопасное требование и отбрасываете его, не внося в архитектуру — вы молодец!
Если вы задумываетесь, как каждое архитектурное решение повлияет на безопасность — вы молодец!
Если вы используете статический анализ, проводите качественный код-ревью, применяете ручной анализ где нужно и ответственно подходите к использованию opensource-кода — вы молодец!
Если вы тестируете продукт на стендах, используя лучшие практики динамического анализа, а не «в полях» — вы молодец!
🎯 Итог:
Да, это всё непросто и требует усилий. Но именно так рождается безопасный продукт, который действительно помогает вашим заказчикам и укрепляет вашу репутацию. 💪
#ДайджестРБПО
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4⚡1👌1
Выложена запись "Безопасная поставка программного обеспечения пользователям" из цикла "Вокруг РБПО за 25 вебинаров". Это 21-й процесс ГОСТ Р 56939-2024.
Приглашённые эксперты: Мария Рачева и Александр Гадай из компании Swordfish Security.
P.S. В ходе вебинара упоминался приказ ФСТЭК №117, который вступит в силу 1 марта 2026. Некоторые мои соображения по этой теме: Аутсорсинг и приказ ФСТЭК N 117, теория РБПО, инструменты.
Приглашённые эксперты: Мария Рачева и Александр Гадай из компании Swordfish Security.
P.S. В ходе вебинара упоминался приказ ФСТЭК №117, который вступит в силу 1 марта 2026. Некоторые мои соображения по этой теме: Аутсорсинг и приказ ФСТЭК N 117, теория РБПО, инструменты.
👍2⚡1👌1
Forwarded from Ever Secure (Aleksey Fedulaev)
#созвон_сообщества
Запись созвона
Гости выпуска: Андрей Карпов (Co-Founder PVS-Studio).
Дмитрий Шмойлов (Head of software security Kaspersky Lab)
Тема: Разбираем новый ГОСТ Р 56939-2024 - РБПО
На созвоне поговорили про ГОСТ Р 56939-2024 и построении процессов вокруг него
Приятного просмотра:
-📹 Youtube
-📺 VK
👀 @ever_secure | 💪 Мерч | 💳 Поддержать
Запись созвона
Гости выпуска: Андрей Карпов (Co-Founder PVS-Studio).
Дмитрий Шмойлов (Head of software security Kaspersky Lab)
Тема: Разбираем новый ГОСТ Р 56939-2024 - РБПО
На созвоне поговорили про ГОСТ Р 56939-2024 и построении процессов вокруг него
Приятного просмотра:
-
-
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
У нас в блоге появился новый жанр – отзывы клиентов. Представлю первые два из них от компании Eltex и СВД ВС. Большое им спасибо, что нашли время дать обратную связь.
Читать далее: Как крупнейший в РФ производитель сетевого оборудования Eltex сделал разработку безопаснее благодаря PVS-Studio.
Читать далее: Как СВД ВС использует PVS-Studio в сертифицируемой разработке защищённой ОС.
"На начальном этапе нас поразила скорость работы. Другие анализаторы могли увеличивать время сборки до 30 минут, а PVS-Studio добавлял буквально пару минут. Это стало весомым преимуществом. Кроме того, интеграция через CMake идеально легла в наши процессы", — Павел Ильченко, руководитель группы Security, Eltex.
Читать далее: Как крупнейший в РФ производитель сетевого оборудования Eltex сделал разработку безопаснее благодаря PVS-Studio.
"Наши разработчики привыкли работать с кодом в системе контроля версий. С PVS-Studio это гораздо проще, возможно, именно потому, что не нужно отправлять что-то на удалённый сервер, чтобы посмотреть результат. Быстро формируется прекрасный HTML-отчёт, и с ним сразу можно работать", — Евгений Дужак, руководитель группы СЗИ, СВД ВС.
Читать далее: Как СВД ВС использует PVS-Studio в сертифицируемой разработке защищённой ОС.
👍6
Открытая конференция ИСП РАН 2025 завершилась. Было приятно встретить множество знакомых лиц и пообщаться с столь концентрированным РБПО сообществом :)
Узнал о компании ЕС-лизинг у которой есть различные наработки в сфере руководств, например по методикам выявления уязвимостей и НДВ или о прядке работы с продуктом Code Scoring. Есть заготовки формуляров, ведомостей и т.д., о которых часто спрашивают слушатели нашего цикла про РБПО. По крайней мере, я сделал такой вывод из беглого знакомства. Надо будет попробовать сделать с ними вебинар, чтобы они поподробнее рассказали, что и как.
Показали некоторым сертификационным лабораториям прототип нашего нового инструмента для работы по разметке сообщений. Скоро про него начнём рассказывать публично, просьба немного потерпеть.
Но думаю, подписчикам в первую очередь интересно услышать про результаты испытаний статических анализаторов. Про это будет следующий пост.
Узнал о компании ЕС-лизинг у которой есть различные наработки в сфере руководств, например по методикам выявления уязвимостей и НДВ или о прядке работы с продуктом Code Scoring. Есть заготовки формуляров, ведомостей и т.д., о которых часто спрашивают слушатели нашего цикла про РБПО. По крайней мере, я сделал такой вывод из беглого знакомства. Надо будет попробовать сделать с ними вебинар, чтобы они поподробнее рассказали, что и как.
Показали некоторым сертификационным лабораториям прототип нашего нового инструмента для работы по разметке сообщений. Скоро про него начнём рассказывать публично, просьба немного потерпеть.
Но думаю, подписчикам в первую очередь интересно услышать про результаты испытаний статических анализаторов. Про это будет следующий пост.
👍8
Об итогах испытаний статических анализаторов исходного кода при организационной и методической поддержке ФСТЭК России в 2025 году (часть 1 из 6)
Если читатель ждёт судьбоносных новостей о том, как что-то изменилось в сфере статического анализа и инструментария, то их нет. Не имея опыта организации таких испытаний, мы все (организаторы, вендоры, жюри и т.д.) недооценили сложность и попытались сразу откусить непосильно большой кусок.
Многое из задуманного не реализовано. Что-то формулировалось или менялось на ходу, когда становилось понятно, что выбранный ранее сценарий не получается на практике. Поэтому, хотя какие-то частичные результаты получены, опираться на них для окончательных выводов нерационально. Поэтому в докладах и нет утверждений, что какой-то инструмент прошёл или не прошёл испытания и что именно является окончательными критериями отбора.
Откуда непредвиденная сложность и дополнительные затраты времени, из-за которых не удалось провести планируемый объём испытаний? Один пример.
Анализаторы должны запускаться на отечественной ОС. Непосредственно перед началом этапа по проверке открытых проектов регулятор выбрал несколько важных для индустрии проектов. Хорошие проекты, нормальный выбор. Но на практике оказывается, что некоторые из этих проектов сходу не получается собрать на целевой операционной системе. И вместо анализа команды участников на площадке испытаний занимались попыткой собрать эти проекты. В результате досборку и анализ некоторых из них пришлось перенести другой день.
В ретроспективе выглядит так, что такую нестыковку можно было предвидеть и избежать. Но в ходе реального процесса получилось так, как получилось, и это только один пример нестыковки. Никто не виноват, но незапланированное замедление. Польза – опыт, но часть времени уже ушло.
Итак, в испытаниях участвовали [в скобка указано сокращение, которое я буду использовать далее для краткости]:
1) ООО «ПВС», PVS-Studio. [PVS]
2) АО «НПО «Эшелон», АК-ВС 3. [Echelon]
3) АО «Позитив Текнолоджиз», Positive Technologies Application Inspector. [PT]
4) АО «СОЛАР СЕКЬЮРИТИ», Solar AppScreene. [Solar]
5) ИСП РАН, Svace. [ISP RAS]
6) Базальт СПО представляет CodeChecker, включающей связку из: clang-static-analyzer, clang-tidy, cppcheck и gcc. [Basealt]
Echelon, PT, Solar и ISP RAS заявили к испытаниям все языки: C/C++, C#, Java, Go, Python, JavaScript. PVS языки: C/C++, C#, Java. Набор от Basealt испытывался только на C/C++.
С записью докладов, посвящённых испытаниям, можно познакомиться здесь (06:05:10 - приблизительно начало).
Соответствующие презентации лежат здесь (в папке 2. 16-17 Стат. анализаторы).
Если читатель ждёт судьбоносных новостей о том, как что-то изменилось в сфере статического анализа и инструментария, то их нет. Не имея опыта организации таких испытаний, мы все (организаторы, вендоры, жюри и т.д.) недооценили сложность и попытались сразу откусить непосильно большой кусок.
Многое из задуманного не реализовано. Что-то формулировалось или менялось на ходу, когда становилось понятно, что выбранный ранее сценарий не получается на практике. Поэтому, хотя какие-то частичные результаты получены, опираться на них для окончательных выводов нерационально. Поэтому в докладах и нет утверждений, что какой-то инструмент прошёл или не прошёл испытания и что именно является окончательными критериями отбора.
Откуда непредвиденная сложность и дополнительные затраты времени, из-за которых не удалось провести планируемый объём испытаний? Один пример.
Анализаторы должны запускаться на отечественной ОС. Непосредственно перед началом этапа по проверке открытых проектов регулятор выбрал несколько важных для индустрии проектов. Хорошие проекты, нормальный выбор. Но на практике оказывается, что некоторые из этих проектов сходу не получается собрать на целевой операционной системе. И вместо анализа команды участников на площадке испытаний занимались попыткой собрать эти проекты. В результате досборку и анализ некоторых из них пришлось перенести другой день.
В ретроспективе выглядит так, что такую нестыковку можно было предвидеть и избежать. Но в ходе реального процесса получилось так, как получилось, и это только один пример нестыковки. Никто не виноват, но незапланированное замедление. Польза – опыт, но часть времени уже ушло.
Итак, в испытаниях участвовали [в скобка указано сокращение, которое я буду использовать далее для краткости]:
1) ООО «ПВС», PVS-Studio. [PVS]
2) АО «НПО «Эшелон», АК-ВС 3. [Echelon]
3) АО «Позитив Текнолоджиз», Positive Technologies Application Inspector. [PT]
4) АО «СОЛАР СЕКЬЮРИТИ», Solar AppScreene. [Solar]
5) ИСП РАН, Svace. [ISP RAS]
6) Базальт СПО представляет CodeChecker, включающей связку из: clang-static-analyzer, clang-tidy, cppcheck и gcc. [Basealt]
Echelon, PT, Solar и ISP RAS заявили к испытаниям все языки: C/C++, C#, Java, Go, Python, JavaScript. PVS языки: C/C++, C#, Java. Набор от Basealt испытывался только на C/C++.
С записью докладов, посвящённых испытаниям, можно познакомиться здесь (06:05:10 - приблизительно начало).
Соответствующие презентации лежат здесь (в папке 2. 16-17 Стат. анализаторы).
👍12❤1❤🔥1👌1
Об итогах испытаний статических анализаторов исходного кода при организационной и методической поддержке ФСТЭК России в 2025 году (часть 2 из 6)
По итогам можно сказать, что все инструменты успешно запускаются на отечественных ОС ALT Linux или Astra Linux. Из таблицы видно, что PVS-Studio выполнил без аномалий анализ всех проектов для всех заявленных языков (C/C++, C#, Java). Нет подсвеченных красных ячеек, которые свидетельствуют об аварийном завершении проверки, о слишком длительной проверке или об аномальном количестве срабатываний.
Например, C/C++ анализаторам PT и Echelon не удалось выполнить проверку большого проекта ceph. Или что-то пошло не так. Для Java проекта netty анализтор Solar выдал 150491 срабатываний, что превышает количество строк в проекте. И так далее.
У PVS-Studio получились хорошие количественные показатели по предупреждениям и времени работы по всем заявленным языкам. Столь же аккуратные результаты демонстрирует ISP RAS.
Однако это не значит, что у команды PVS-Studio всё прям идеально шло. Например, выяснилось, что мы не поддерживаем формат C# проекта SignalR (.slnf). Мы дорабатывали утилиту командной строки и перезапускали анализ этого проекта на одной из дополнительных встреч.
По итогам можно сказать, что все инструменты успешно запускаются на отечественных ОС ALT Linux или Astra Linux. Из таблицы видно, что PVS-Studio выполнил без аномалий анализ всех проектов для всех заявленных языков (C/C++, C#, Java). Нет подсвеченных красных ячеек, которые свидетельствуют об аварийном завершении проверки, о слишком длительной проверке или об аномальном количестве срабатываний.
Например, C/C++ анализаторам PT и Echelon не удалось выполнить проверку большого проекта ceph. Или что-то пошло не так. Для Java проекта netty анализтор Solar выдал 150491 срабатываний, что превышает количество строк в проекте. И так далее.
У PVS-Studio получились хорошие количественные показатели по предупреждениям и времени работы по всем заявленным языкам. Столь же аккуратные результаты демонстрирует ISP RAS.
Однако это не значит, что у команды PVS-Studio всё прям идеально шло. Например, выяснилось, что мы не поддерживаем формат C# проекта SignalR (.slnf). Мы дорабатывали утилиту командной строки и перезапускали анализ этого проекта на одной из дополнительных встреч.
👍10😁4
Об итогах испытаний статических анализаторов исходного кода при организационной и методической поддержке ФСТЭК России в 2025 году (часть 3 из 6)
Для начала шпаргалка для тех, кто путается в TP, TN, FP, FN :)
TP – True Positive – сколько ошибок выявлено.
TN – True Negative – сколько обманок обнаружено.
FP – False Positive – ложноположительные срабатывания (ошибки первого рода) (требование ГОСТ: не более 50 %).
FN – False Negative – ложноотрицательные срабатывания, т. е. пропуски заведомо известных ошибок (ошибки второго рода) (требование ГОСТ: не более 50 %).
TP обратно пропорционально FN.
TN обратно пропорционально FP.
Результат по основной формуле для C/C++ говорит, что все анализаторы не уложились в показатель: не более 50% False Positive (FP). Показатель FP обратно пропорционален True Negative (TN), который, как видно из графика, получился маленьким у всех анализаторов.
Кстати, даже я при всей вовлечённости в процесс и тому, что приводится формула, не до конца понимаю, что, собственно, изображено на графике и как его осознать :)
Впрочем, TN в любом случае у всех маленький (большой FP). Это говорит о том, что в сумме участниками были предоставлены синтетические тесты, на которых другим вендорам было тяжело. Это подсветило для каждого его слабые места и показало, куда стоит развивать инструменты.
Примечание. Результаты по бинарному принципу (см. 9 слайд презентации) другие, но не сильно лучше: только Svace укладывается в диапазон.
Для начала шпаргалка для тех, кто путается в TP, TN, FP, FN :)
TP – True Positive – сколько ошибок выявлено.
TN – True Negative – сколько обманок обнаружено.
FP – False Positive – ложноположительные срабатывания (ошибки первого рода) (требование ГОСТ: не более 50 %).
FN – False Negative – ложноотрицательные срабатывания, т. е. пропуски заведомо известных ошибок (ошибки второго рода) (требование ГОСТ: не более 50 %).
TP обратно пропорционально FN.
TN обратно пропорционально FP.
Результат по основной формуле для C/C++ говорит, что все анализаторы не уложились в показатель: не более 50% False Positive (FP). Показатель FP обратно пропорционален True Negative (TN), который, как видно из графика, получился маленьким у всех анализаторов.
Кстати, даже я при всей вовлечённости в процесс и тому, что приводится формула, не до конца понимаю, что, собственно, изображено на графике и как его осознать :)
Впрочем, TN в любом случае у всех маленький (большой FP). Это говорит о том, что в сумме участниками были предоставлены синтетические тесты, на которых другим вендорам было тяжело. Это подсветило для каждого его слабые места и показало, куда стоит развивать инструменты.
Примечание. Результаты по бинарному принципу (см. 9 слайд презентации) другие, но не сильно лучше: только Svace укладывается в диапазон.
👍9❤1