Warning: Undefined array key 0 in /var/www/tgoop/function.php on line 65

Warning: Trying to access array offset on null in /var/www/tgoop/function.php on line 65
- Telegram Web
Telegram Web
Дочитал книгу "Безопасный C++"

Приведён хороший и достаточно редкий материал. Признаюсь – некоторые темы прошли мимо осознания :) Например, раздел про криптографию не очень мне понятен и интересен/полезен. Зато очень зашла тема про выполнение произвольного кода и как от этого защищаться. Раздел 4.3 – сборка и укрепление, тоже прям хорош.

Как видите, книга с подписью для моего коллеги Михаила Гельвиха. Приятно знать, что Сергеем оценён его вклад в рецензирование книги.

В общем книга достойна внимания и знакомства с ней.
👍12🔥3🙏1
Интеграция результатов анализа PVS-Studio в CyberCodeReview
CyberCodeReview — это ASOC-платформа для анализа защищённости кода и приложений.
РБПО-067. Процесс 22 — Обеспечение поддержки программного обеспечения при эксплуатации пользователями

Цели 22-го процесса ГОСТ Р 56939-2024:
Обеспечение технической поддержки ПО при его эксплуатации с целью устранения вы являемых в ходе использования и обновления ПО недостатков.

Поддержка является неотъемлемой частью жизненного цикла ПО. Она есть практически в любом проекте, у которого есть пользователи/клиенты. Поэтому речь опять, скорее, будет идти не о том, что надо внедрять процесс, а в том, чтобы навести в нём большую прозрачность и определённость.

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

Также требуется проработать процедуру оповещения пользователей о выпуске обновлений (включая обновления безопасности) и необходимости их установки. Эта процедура нужна и важна для любого приложения, но, когда мы говорим о РБПО, критичность этого действия возрастает. Мало исправить уязвимость в коде и выложить исправленный дистрибутив, необходимо ещё, чтобы пользователи как можно быстрее его установили.

Подробнее, что именно следует подготовить, смотри в п.5.22.3 - Артефакты реализации требований. Это один из самым больших разделов про артефакты среди других процессов.

Мы в компании ПВС очень много внимания и ресурсов уделяем поддержке. При этом у нас есть специфика, что наши пользователи в основном программисты. У этой особенности есть две стороны: приятная (сообщения о недостатках почти всегда сформулированы чётко, с примерами) и сложная (почти каждый вопрос требует мини-исследования, к которому привлекается кто-то из наших программистов). В общем, не получается разрешить часть обращений предложением "проверьте, что вилка вставлена в розетку" :)

Кое-что про нашу поддержку:
1. Пример, когда исследование проблемы, описанной пользователем, сложнее, чем кажется в начале. Ложные срабатывания в PVS-Studio: как глубока кроличья нора.
2. Шуточный доклад Юрия Минаева "Не связывайтесь с поддержкой C++ программистов".
3. Когда баг не там, где кажется. Один день из поддержки пользователей PVS-Studio.
4. Работа нашей поддержки.

Теперь вернёмся обратно к теме построения процесса поддержки. На эту тему есть следующие хорошие материалы:
1. ГОСТ Р ИСО/МЭК 14764-2002. Информационная технология. Сопровождение программных средств.
2. Wikipedia. Сопровождение программного обеспечения.
3. Роль технической поддержки программного продукта в SDLC.

Примеры разделов на сайте компаний про сопровождение ПО:
1. Лаборатории Касперского. Правила поддержки Программного Обеспечения Лаборатории Касперского.
2. Открытая мобильная платформа. Техническая поддержка программных продуктов.
3. РЕД СОФТ. Положение о технической поддержке операционной системы "РЕД ОС".
4. Киберпротект. Положение о сопровождении ПО.
5. Securitm. Правила технической поддержки.
Forwarded from PVS-Studio
А теперь время хорошей новости! 🔥

Друзья, коллеги, Java-разработчики, приглашаем вас на наш митап — Карты, деньги, JVM!

На митапе обсудим внутренности JVM и компилятора: разберём, как JVM оптимизирует динамические вызовы, чем MethodHandle лучше рефлексии, и как компилятор обрабатывает код — от фронтенда до практического применения.

Вас ждут два интересных доклада от разработчиков PVS-Studio, нетворкинг и вкусная пицца ❤️

🗓 30 октября
📍Санкт-Петербург + онлайн

Подробное расписание и регистрация по ссылке 🔗

#мероприятия #митап #java
Please open Telegram to view this post
VIEW IN TELEGRAM
10
РБПО-068. Процесс 23 — Реагирование на информацию об уязвимостях

Цели 23-го процесса ГОСТ Р 56939-2024:
Обеспечение выявления и устранения уязвимостей при эксплуатации ПО.

Основная суть — быстро и адекватно реагировать на информацию об уязвимостях, полученную от пользователей или из иных источников.

Конечно, иногда информация об угрозе не будет соответствовать действительности, и многие замеченные дефекты безопасности невозможно в реальности эксплуатировать как уязвимость. Однако требуется построить систематическую обработку такой информации и её анализ, чтобы не пропустить действительно критичные моменты.

Часто этот процесс отсутствует. Вернее, к полученной информации о угрозах относятся точно так же, как и к сообщениям об ошибках. Дефекты безопасности попадают в багтрекеры наравне с другими багами и ждут своей очереди… и иногда очень долго. Другими словами, часто в компаниях выстроен 22-й процесс "Обеспечение поддержки программного обеспечения при эксплуатации пользователями", но не выстроен 23-й.

На практике это может выглядеть следующим образом. Я открываю задачу в багтрекере проекта о том, что в некоторых функциях не происходит очистка приватных данных. Компилятор в процессе оптимизации удалит вызов функции memset для зануления буфера, т.к. затем этот буфер более не используется. В общем, речь про CWE-14: Compiler Removal of Code to Clear Buffers.

Я не утверждаю, что это прям ужас-ужас какая ошибка. Она может ни на что не влиять и, скорее всего, эти незатёртые данные невозможно как-то заполучить и использовать. И тем не менее это вполне себе дефект безопасности, который, согласно ГОСТ Р 71207-2024, можно классифицировать как критическую ошибку (6.3.г — Ошибки некорректного использования системных процедур и интерфейсов, связанных с обеспечением информационной безопасности (шифрования, разграничения доступа и пр.)). Если речь идёт о РБПО, то такую ошибку следует просто на всякий случай сразу исправить и жить дальше спокойно. Тем более, что правка несложная.

Однако отсутствие процесса реагирования потенциальные уязвимости приводит к тому, что эта ошибка прождала своего исправления 9 лет. Это не придуманная история, а реальный случай — 1000 глаз, которые не хотят проверять код открытых проектов.

Или, например, я месяц ждал реакции от разработчиков на информацию о дефектах, которые я затем описал в статье "Релиз PVS-Studio для macOS: 64 weaknesses в Apple XNU Kernel". Так ничего не дождался и опубликовал статью. Моё письмо или потеряли, или оно в спам попало, или пылится среди других. И подобных случаев на нашей практике много.

Чтобы такого не происходило, согласно ГОСТ Р 56939-2024, следует разработать и внедрить регламент (п.5.23.3.1):
- обязанности сотрудников и их роли при реагировании на информацию об уязвимостях ПО;
- правила реагирования на информацию об уязвимостях;
- правила оценки актуальности и критичности уязвимости с точки зрения безопасности ПО;
- периодичность проведения поиска известных (подтвержденных) уязвимостей в общедоступных источниках информации об уязвимостях ПО.

Рассматриваемый процесс также пересекается c композиционным анализом (см. РБПО-061), если речь идёт о нахождении уязвимостей в сторонних используемых компонентах.

По каждому случаю должна быть проведена работа по оценке актуальности и критичности. Т.е. должен появится артефакт, подтверждающий выполнение оценки актуальности и критичности уязвимости с точки зрения безопасности. Он должен содержать (п.5.23.3.4):
- информацию об оценке актуальности уязвимости;
- информацию об оценке уровня критичности уязвимости ПО;
- решение по результатам анализа актуальности и критичности уязвимости.

Дополнительные ссылки:
1. Терминология. Уязвимость нулевого дня.
2. Станислав Мриль. Всё об управлении уязвимостями в 2025: Vulnerability Management.
3. Positive Technologies: раскрытие уязвимостей и опыт взаимодействия исследователей и вендоров в 2022–2023 годах.
4. Руслан Рахметов. Поиск и предотвращение уязвимостей в ПО: эффективные методики.
5. Порядок подачи уязвимости в базу ФСТЭК России: пошаговая инструкция.
РБПО-069. Процесс 24 — Поиск уязвимостей в программном обеспечении при эксплуатации

Цели 24-го процесса ГОСТ Р 56939-2024:
Организация систематического и углубленного поиска ошибок и уязвимостей в ПО при его эксплуатации в целях упреждающего реагирования: обработки ошибок кода ПО и его конфигураций (настроек) до того, как они будут выявлены сторонними лицами и повлекут инциденты информационной безопасности.

С выпуском очередной версии ПО работы, направленные на обеспечение безопасности, не заканчиваются. Необходимо постоянно актуализировать информацию об уязвимостях созданного ПО из открытых источников на регулярной основе на всем протяжении срока действия его технической поддержки. Для этого выстраивается процесс регулярного поиск в открытых источниках информации об уязвимостях самого ПО и его сторонних компонентов.

Контроль уязвимостей в сторонних компонентах может показаться избыточным, ведь для этого есть процесс 16 — композиционный анализ (см. РБПО-061). Как я понимаю, здесь речь о следующем:

1. SCA инструменты могут быть ещё не в курсе выявления и эксплуатации какой-то уязвимости. И если вдруг удалось выяснить, например, на форуме хакеров, что некий компонент уязвим, то можно предпринять действия, не дожидаясь появления соответствующей CVE. Собственно, можно стать инициатором пополнения базы CVE новой уязвимостью и тем самым обезопасить не только свой проект, но и помочь другим.

2. В процессе разработки сменяются версии используемых библиотек. Однако важно следить не только за уязвимостями в библиотеках, используемых на данный момент. У клиентов могут функционировать приложения предыдущих версий, построенные на более ранних версиях библиотек. Нужно отслеживать обнаружение уязвимостей и в этих старых версиях библиотек, чтобы выпустить соответствующие пакеты обновления для старых версий продукта или уведомить пользователей о необходимости срочно перейти на новые версии ПО.

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

Ещё одним способом упреждения уязвимостей являются публичные программы поиска уязвимостей за вознаграждение:
Проверки кода ПО и настроек конфигураций ПО при его эксплуатации могут выполняться как собственными силами разработчика, так и с привлечением сторонних организаций и исследователей, в том числе в рамках публичных программ поиска уязвимостей за вознаграждение (программ багбаунти).

К сожалению, пока Госдума отклонила законопроект о легализации "белых" хакеров:
На заседании во вторник, 8 июля 2025, Госдума отклонила законопроект, который должен был легализовать в России деятельность «белых» хакеров. Решение было принято после соответствующей рекомендации профильного комитета Госдумы по государственному строительству и законодательству.

Речь идет о хакерах, которых компании самостоятельно привлекают к тестированию своих информсистем на уязвимости. Вопрос легализации их деятельности в России публично обсуждается с лета 2022 года, когда Минцифры занялось проработкой возможности ввести в правовое поле понятие bug bounty — поиск уязвимостей в софте за вознаграждение.

Так что учитывайте, что сейчас этот метод, к сожалению, не регламентируется и не оформлен юридически.

Дополнительные ссылки:

1. Елена Дмитриева. Обзор программ и площадок баг-баунти в России: практика, кейсы, суммы гонораров.
2. TAdviser. Подборка: Белые хакеры в России.
3. Круглые столы: Взгляд разработчиков, пользователей, хакеров, Багбаунти: опыт hh.ru и Rambler&Co, Багбаунти: опыт Ozon и Wildberries на Standoff Bug Bounty.
4. Как пентестеры помогают бизнесу найти уязвимости в IT-системах.
👍1
Сегодня мы запускаем HiveTrace Red — продукт автоматического тестирования LLM и агентных систем.

Всё началось с курьёзных случаев, когда чатбот продавал автомобиль за доллар или выдавал несуществующие скидки на авиабилеты. С ростом возможностей ИИ-систем мы видим, что адверсарное тестирование становится таким же необходимым этапом безопасной разработки, как code review или аудит зависимостей библиотек.

🔹 HiveTrace Red генерирует и запускает десятки атак: token smuggling, roleplay, context switching и другие.
🔹 Цели тестирования могут варьироваться от раскрытия конфиденциальной информации и генерации вредоносного контента до проверки репутационных рисков и симуляции DoS атак.
🔹 Инструмент автоматически анализирует ответы моделей и формирует отчёты, совместимые с OWASP и MITRE, а в будущем добавим новые российские стандарты.
🔹 Совместное использование с основной платформой HiveTrace позволяет закрыть полный цикл разработки и эксплуатации AI-систем "обнаружить — проверить — предотвратить".

Сегодня мы открываем Open Source ядро продукта, которое можно использовать как on-prem с локальными моделями, так и через API облачных сервисов для генерации и оценки атак. Параллельно идёт разработка enterprise-функций и интеграций с облачными платформами. При создании инструмента мы опирались на опыт собственных red team-проектов последних двух лет, а в основе HiveTrace Red лежит форк проекта RuRedTeam Юрия Лебединского.

Используйте продукт, чтобы увидеть, насколько устойчив ваш ИИ-ассистент к промпт-атакам. На днях анонсируем вебинар, где подробно покажем, как работает HiveTrace Red.
💯4
Коллеги, приглашаю на мероприятие "Безопасная разработка в АСУ ТП".

На митапе обсудим современные угрозы для АСУ ТП, методы киберзащиты и роль статического анализа кода в предотвращении сбоев и атак, с акцентом на отечественные стандарты и практики безопасной разработки.

Кому будет полезно:

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

- руководители отделов разработки и АСУ ТП – обсудят опыт коллег и смогут применять лучшие практики для своей инфраструктуры;

- инженеры по АСУ ТП – узнают о новых методах киберзащиты, актуальных угрозах и инструментах обеспечения безопасности систем;

- системные архитекторы – смогут понять, как интегрировать безопасные практики в жизненный цикл разработки и эксплуатации АСУ ТП;

- представители отраслей энергетики, нефтяной и газовой промышленности, металлургии, химической промышленности, транспорта и логистики – там, где широко применяются АСУ ТП;

- CISO и специалисты по ИБ – получат информацию о специфике защиты АСУ ТП;

- разработчики и аудиторы ПО – особенно те, кто работает по ГОСТ и другим отечественным стандартам.

📍Где: Москва, пр-т Мира, 119 строение 461, Москва (павильон «Умный город», ВДНХ)

🗓Когда: 24.10.2025 (чт) 17:00

Подробности по ссылке
🔥9
РБПО-070. Процесс 25 — Обеспечение безопасности при выводе программного обеспечения из эксплуатации

Цели 25-го процесса ГОСТ Р 56939-2024:
Недопущение реализации угроз безопасности, связанных с эксплуатацией неподдерживаемой версии ПО.

Самый короткий раздел среди прочих. Поэтому приведу требования и артефакты целиком:
5.25.2 Требования к реализации
5.25.2.1 Разработать регламент вывода ПО из эксплуатации.
5.25.2.2 Информировать пользователя о планах прекращения технической поддержки ПО (версии ПО) и своевременно уведомлять об этом.

5.25.3 Артефакты реализации требований
5.25.3.1 Регламент вывода ПО из эксплуатации должен содержать описание условий, при которых ПО (версию ПО) необходимо выводить из эксплуатации, обязанности сотрудников и их роли при осуществлении вывода ПО из эксплуатации ПО и порядок оповещения пользователей о планах прекращения технической поддержки ПО (версии ПО).

Понятно, что для некоторых приложений/сфер этот раздел не очень существенен, а для других наоборот. Например, слышал в каком-то докладе на Kaspersky Certification Day, что вывод ПО из эксплуатации может быть непростым процессом для изделий по линии МО.

Примеры мер, которые может включать вывод ПО из эксплуатации:
1. Выгрузка данных, которые не должны быть утеряны при завершении эксплуатации ПО;
2. Полное удаление (затирание) данных, учётных записей, настроек ПО;
3. Или, наоборот, сбор/архивирование данных с целью использования их в других системах. Шифрование архивов. Создание плана миграции данных;
4. Строгий контроль доступа к архиву (принцип минимальных привилегий);
5. Физическое уничтожение носителей информации;
6. Убедиться, что разработанные процедуры соответствуют требованиям, установленным нормативными документами и ТЗ;
7. Проверить, что соблюдены юридические, нормативные и договорные обязательства по хранению данных;
8. Создание плана коммуникации для уведомления пользователей и заинтересованных сторон;
9. Освобождение ресурсов, например отключение виртуальных машин и серверов (back end);
10. Возможно освобождение доменных имён. Или, наоборот, продление их использования с целью предотвращения захвата этих имён злоумышленниками и распространение через них вредоносного ПО под видом обновлений/новых версий выведенного из эксплуатации ПО.
11. Формирование акта о выводе. Документ, подтверждающий, что все этапы плана выполнены, данные обработаны в соответствии с политиками, а риски сведены к минимуму.
Фёдор Сазонов: зачем нужна новая IDE на IntelliJ Platform? | Подкаст – Разбаговка #2

В новом выпуске поговорили с CEO OpenIDE, Фёдором Сазоновым. Обсудили язык Java, устройство современных инструментов разработки и то, что на самом деле важно, когда создаёшь среду для других программистов.

Документация: Работа PVS-Studio в IntelliJ IDEA и Android Studio и OpenIDE.

Содержание:
- Как ты попал в IT?
- Почему Java?
- Про IT курсы
- Про доклады и IT-конференции
- Каково тебе быть CEO?
- PVS-Studio: В чём проблемы рефлексии в Java?
- Что такое OpenIDE?
- Чем IntelliJ лучше, чем Visual Studio Code?
- JetBrains будет обучать нейросети на нашем коде?
- Какие планы у OpenIDE?
- Про плагины для OpenIDE и маркетплейс
- Есть ли конкуренция между аналогами IDEA?
- Можно ли контрибьютить в OpenIDE?
- Что изменилось в IntelliJ, чтобы получилась OpenIDE?
- Какую IDE используют разработчики OpenIDE?
- Про Visual Studio Code и Eclipse
🔥3
РБПО-071. Послесловие

На этом я заканчиваю обзор ГОСТ Р 56939-2024. Возможно, я буду постепенно дополнять эту подборку постов, но в целом все процессы кратко рассмотрены. За деталями приглашаю всех на цикл "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024".

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

Приглашаю всех познакомиться с нашим статическим анализатором PVS-Studio, который может закрыть не только 10-й процесс, но будет полезен и в ряде других:

1. Обучение сотрудников (п.5.2). Формирование у программистов понимание антипаттернов и уязвимых конструкций, что улучшает их техническую экспертизу;

2. Моделирование угроз и разработка описания поверхности атаки (п.5.7). Дополняет процесс, выявляя потенциальные уязвимости, которые формируют поверхность атаки;

3. Экспертиза исходного кода (п.5.9). Позволяет усилить проверку стороннего кода, который команда включает в проект. Например, его можно использовать для выбора сторонних библиотек, оценивая качество их кода;

4. Поиск уязвимостей в программном обеспечении при эксплуатации (п.5.24). Можно просматривать ранее отключённые предупреждения PVS-Studio с целью дополнительного выявления дефектов в коде.

PVS-Studio — статический анализатор кода для поиска ошибок и потенциальных уязвимостей.

• Поддерживает: C, C++, C#, Java
• Совместим с ГОСТ Р 71207-2024 (Статический анализ кода)
• Соответствует требованиям "Методики выявления уязвимостей и недекларированных возможностей в программном обеспечении" от 25 декабря 2020 г.
• Может применяться для РБПО согласно ГОСТ Р 56939-2024
• Участвует в инициативе ФСТЭК по испытанию статических анализаторов
• Включён в Реестр российского ПО: запись № 9837
👍5🔥3
Запись "Управление доступом и контроль целостности кода при разработке программного обеспечения" из цикла "Вокруг РБПО за 25 вебинаров". Это 14-й процесс ГОСТ Р 56939-2024.

Приглашённый эксперт: Роман Байталов – архитектор системных решений в GitFlic.

Примечание. Во время демонстрации работы GitFlic с PVS-Studio часть срабатываний не попала в SARIF-отчёт, потому что при запуске утилиты plog-converter не был указан флаг -a. Без него утилита включает в отчёт только срабатывания диагностических правил общего назначения уровней 1 и 2. Чтобы сохранить все срабатывания из исходного отчёта, нужно передать флагу -a значение ALL. Подробнее о флагах утилиты plog-converter можно прочитать в нашей документации.
PVS-Studio 7.39: OWASP Top Ten 2021, улучшения в плагине для Visual Studio Code, расширение поддержки MISRA и не только

- Покрытие OWASP Top Ten 2021 Java анализатором
- Запуск анализа в режиме мониторинга компиляции в плагине для Visual Studio Code
- Поддержка генерации отчёта MISRA Compliance для новых версий стандарта MISRA
- Поддержан анализ проектов на основе сборочной системы MSBuild, использующих формат решений SLNF
- Механизм перезаписи более приоритетных настроек для файлов конфигурации диагностик .pvsconfig
- Breaking changes
- Новые диагностические правила
🔥3
Когда добавляется новое диагностическое правило, это сразу понятно, заметно и есть про что написать. А есть важные, но незаметные работы. Например, недавно мы переписали движок парсинга C и C++ кода. Прошло для мира это почти незаметно, т.к. главной целью, как ни странно, было чтобы ничего не изменилось :). Причина — максимальная совместимость, чтобы свести к минимуму поломки у клиентов.

Сейчас так же тихо для C и C++ начата переделка механизма анализа потока данных. Будем переходить от "исторически сложившихся механизмов" к полноценному IR для вычислений.

Это улучшит вычисления для того, что называется страшным словосочетанием "межпроцедурный контекстно-чувствительный анализ". На практике это учёт того, что возвращает функция в зависимости от переданных аргументов:
int get(int a, int b = 7)
{
return a + 2 - b;
}

int main()
{
int a = 5;
auto divider = get(a, 1);
return a / divider;
}


PVS-Studio выдаёт предупреждение: V609 Divide by zero. Denominator 'divider' == 0.

А если вот так, то уже всё хорошо:
int main()
{
int a = 5;
auto divider = get(a, 1);
return a / divider;
}

Вернее, хорошо, что больше нет деления на ноль. Зато выявляется другой дефект: результат деления 5/6 не имеет смысла, так как в результате целочисленного деления всегда будет получаться 0. Про это уже будет другое предупреждение: V1064 The 'a' operand of integer division is less than the 'divider' one. The result will always be zero.
👍7
Вы уже знаете, а возможно и нет, что вместе с Центральным университетом мы проводим встречи Клуба С++-разработчиков.

Хочется, чтобы на встречах звучали разнообразные доклады. Поэтому приглашаем докладчиков с C++ темами. Можно рассказать, чем вы занимаетесь, какие необычные задачи решаете на работе, про какие-то особенности языка и т.д.

Приглашаем присылать ваши идеи и темы докладов для обсуждения. Контакт: Волкова Дарья / @daryavolkovaa / volkova@viva64.com

Как это было – предыдущая встреча 4 октября.
5
2025/10/24 18:22:54
Back to Top
HTML Embed Code: