На конференции Open Source Summit India 2026 в Мумбаи Кроах-Хартман выступил с докладом «Rust and Linux: How the Rust Language is Going to Help Linux Succeed». В нём он признался, что поначалу относился к языку скептически и считал, что всё необходимое уже есть в C. Сейчас он считает иначе: Rust действительно делает программирование интереснее и безопаснее.

• Грег Кроах-Хартман назвал Rust постоянной частью Linux, а не временным экспериментом.
• По его оценке, около 80% уязвимостей ядра за последние 25 лет можно было бы поймать на этапе компиляции Rust.
• Linux получает около 13 CVE в день и почти 9 изменений в час на протяжении десяти лет и более.
• Binder — ключевой механизм IPC Android — уже имеет параллельную реализацию на Rust, а C-версия скоро уйдёт.
• Git и ряд других крупных проектов также движутся в сторону Rust.

От скептицизма к поддержке

Кроах-Хартман рассказал, что несколько лет назад друг советовал ему попробовать Rust, но он отмахнулся: C казался достаточным. Со временем он изменил мнение. «Он был прав. Я должен был сделать это тогда. Rust на самом деле весёлый. Он заставляет программирование быть весёлым», — сказал мейнтейнер.

Главное преимущество языка в ядерной разработке — владение и типизация, которые убирают массу мелких ошибок: непроверенные указатели, забытые разблокировки, неправильная очистка ресурсов. Именно такие баги, по словам Кроах-Хартмана, составляют большинство ежедневных CVE.

Масштаб проблемы

Linux развивается с огромной скоростью. Кроах-Хартман привёл цифры: ядро набирает примерно девять изменений в час уже больше десяти лет, а количество публично раскрываемых уязвимостей держится на уровне около 13 CVE в день. Большая часть из них — не сложные атаки, а простые ошибки в C-коде.

Я видел каждую CVE ядра за последние 25 лет. Думаю, 80% исчезли бы просто потому, что Rust поймал бы их.

Что уже меняется в ядре

Rust постепенно становится обязательным выбором для отдельных подсистем. Кроах-Хартман отметил, что новые драйверы некоторых подсистем будут приниматься только на Rust. Яркий пример — Binder, межпроцессный механизм Android, от которого зависят миллиарды устройств. В ядре уже существуют параллельные реализации Binder на C и Rust, и C-версия «скоро исчезнет».

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

Контекст:
Binder — это механизм межпроцессного взаимодействия (IPC) в Android. Он позволяет приложениям и системным сервисам безопасно обмениваться данными. Переписывание Binder на Rust напрямую влияет на безопасность и стабильность почти всех Android-устройств.

Выводы

Позиция Кроах-Хартмана — ещё один сигнал того, что Rust перешёл из разряда «перспективного языка» в разряд инфраструктурного инструмента. Если оценка в 80% CVE верна, массовый переход на Rust в ядре может существенно снизить количество исправлений безопасности и освободить время мейнтейнеров для сложных логических задач.

Источник: Slashdot.

• ИИ-агент JadePuffer использовал CVE-2025-3248 в Langflow для первичного доступа.
• Агент адаптировался в реальном времени: после неудачного входа нашёл рабочее решение за 31 секунду.
• Зашифрованы 1342 конфигурации Nacos; платить выкуп бесполезно, так как схемы базы данных уничтожены.
• Защита: убрать Langflow и Nacos из интернета, сменить стандартные ключи и не хранить API-ключи на оркестраторах ИИ.

Как развивалась атака

Sysdig назвала угрозу JadePuffer. Агент начал с открытого в интернете экземпляра Langflow — фреймворка для построения конвейеров ИИ, и воспользовался уязвимостью CVE-2025-3248, которая позволяет удалённо выполнить произвольный Python-код без аутентификации.

Попав внутрь, агент собирал секреты: ключи провайдеров ИИ, облачные учётные данные, кошельки криптовалют и пароли к базам данных. Особое внимание он уделял китайским облакам — Alibaba, Aliyun, Tencent и Huawei, — но не обходил стороной AWS, Azure и Google Cloud. Для закрепления агент добавил задачу в crontab, которая каждые 30 минут связывалась с инфраструктурой злоумышленников.

Конечной целью стал отдельный продакшен-сервер с MySQL и сервисом конфигураций Nacos от Alibaba. Агент подключился к MySQL под root, использовал обход авторизации CVE-2021-29441 и подделал JWT с помощью стандартного ключа Nacos. В итоге он зашифровал все 1342 конфигурации встроенной функцией AES и оставил записку с требованием выкупа, биткоин-адресом и почтой Proton Mail.

Почему платить не имеет смысла

Классический ransomware обычно хранит ключи или резервные копии, чтобы расшифровать данные после оплаты. JadePuffer действовал иначе: он уничтожал целые схемы базы данных, не сохраняя возможности восстановления. По словам директора по исследованию угроз Sysdig Майкла Кларка, агент «переходил от удаления строк к сбросу целых схем БД, проговаривая собственную логику выбора целей».

Как защититься

1. Закройте от интернета конечные точки Langflow и Nacos — они не должны быть публично доступны.
2. Обновите Langflow до версии без CVE-2025-3248.
3. Смените стандартный token.secret.key в Nacos и используйте принудительную настройку собственного ключа.
4. Не храните API-ключи провайдеров ИИ и облачные учётные данные в окружении оркестраторов ИИ.

Атака JadePuffer показывает, что порог входа для ransomware опустился до стоимости запуска ИИ-агента. Если агент работает на украденных учётных данных через LLMjacking, затраты злоумышленника близки к нулю. Источник: The Register.

Таковы результаты ежегодного исследования компании Checkmarx — вендора инструментов для анализа безопасности приложений. В опросе участвовали 2350 разработчиков, CISO (Chief Information Security Officer) и AppSec-менеджеров (application security) по всему миру. Выборка выросла на 54% по сравнению с прошлым годом, что делает данные ещё более репрезентативными.

70% разработчиков считают ИИ-код более уязвимым, чем человеческий.

30% всех опрошенных сознательно деплоят уязвимый код в продакшен.

93% компаний пережили хотя бы один инцидент безопасности из-за уязвимых приложений.

Организации, где 81–100% кода генерируется ИИ, деплоят уязвимости в 3,4 раза чаще, чем те, где ИИ-генерация составляет 1–20%.

59% кода в продакшене — open source, который тоже не идеален с точки зрения безопасности.

ИИ пишет половину кода — и это проблема

По данным Checkmarx, сегодня примерно 49% кода в продакшене создаётся с помощью ИИ. Это немного меньше, чем 54% в прошлом году, но всё ещё колоссальная цифра. Почти каждая вторая строка в вашем приложении может быть рождена нейросетью, которая обучалась на публичных репозиториях — со всеми их багами, устаревшими паттернами и скрытыми уязвимостями.

Причина проста: языковые модели обучаются на огромных массивах существующего кода, включая устаревшие практики и известные CVE (Common Vulnerabilities and Exposures). Исследователи из University of Central Florida и Birzeit University в 2025 году провели сравнительный анализ безопасности кода, сгенерированного разными LLM для Java, Python, C и C++. C-код оказался самым дырявым, Python — относительно чистым. Но ключевой вывод исследования шире: модели «недоиспользуют современные языковые и компиляторные возможности, предпочитая устаревшие практики более безопасным альтернативам». Сами исследователи оговаривают: LLM эволюционируют быстро, и их выводы — это «снимок во времени» (time-stamped view), а не вечная истина.

Почему разработчики деплоят то, что не доверяют

Вот в чём парадокс: разработчики видят проблему, но не чувствуют ответственности за её решение. Основные причины, по которым уязвимый код попадает в прод, выглядят так:

• Давление сроков и необходимость быстро деплоить фичи.
• Уязвимости слишком сложно или дорого исправлять постфактум.
• Надежда на то, что «другие инструменты безопасности подхватят» на поздних этапах.
• Нормализация риска: когда все вокруг деплоят с багами, это перестаёт восприниматься как катастрофа.

Checkmarx прямо констатирует: «Risk is normalized» — риск стал нормой. 93% респондентов сообщили о как минимум одной бреши в безопасности, связанном с уязвимыми приложениями. В прошлом году это было 98% — статистика чуть улучшилась, но не кардинально. Когда девять из десяти компаний регулярно взламывают, инцидент перестаёт быть новостью и становится рутиной.

Объём ИИ-кода напрямую коррелирует с частотой деплоя уязвимого кода, которая, в свою очередь, коррелирует с частотой инцидентов безопасности.

Самая тревожная цифра: организации, где 81–100% кода генерируется ИИ, деплоят уязвимый код в 3,4 раза чаще, чем компании с умеренным использованием ИИ (1–20%). Это прямая корреляция: чем выше доля ИИ-генерации, тем чаще в прод попадают уязвимости. Причина не только в самом коде, но и в том, что высокая скорость разработки часто сопровождается слабыми процессами безопасности.

Open source как фундамент — и фундамент трещит

Ещё один слой проблемы — open source. По оценкам респондентов, 59% кода в продакшене приходится на открытые библиотеки. Это самооценки, но они отражают реальность: современный проект без node_modules, requirements.txt или Cargo.toml немыслим. Проблема в том, что мейнтейнеры этих библиотек часто не успевают закрывать уязвимости, а злоумышленники активно внедряют вредоносные пакеты в npm, PyPI и другие репозитории.

ИИ-инструменты ускоряют разработку, но не ускоряют аудит безопасности. Veracode в своём отчёте предупреждает: скорость ИИ-разработки делает безопасность недостижимой, если процессы не перестраиваются соответствующим образом. Инструменты статического анализа и сканеры на базе ИИ уязвимостей существуют, но организации не умеют встраивать их в процесс. «Инструменты делают работу, но компании не умеют переводить это в процесс» — констатируют в Checkmarx.

Например, вот типичная разница между ИИ-сгенерированным кодом и безопасной альтернативой. Copilot или аналогичные инструменты часто предлагают устаревший pickle.load для десериализации данных:

pickle.load выполняет произвольный Python-код при десериализации — классическая уязвимость из списка OWASP Top 10. Аналогичные проблемы часто встречаются в SQL-запросах без параметризации, использовании eval() и устаревших криптографических функциях. Проверяйте каждый snippet перед мержем.

Как не превратить ИИ-ускорение в ИИ-катастрофу

Отказываться от ИИ в разработке бессмысленно — это уже не инструмент будущего, а повседневная реальность. Но можно и нужно менять подход:

1. Проверяйте ИИ-код так же тщательно, как человеческий. Не предполагайте, что нейросеть знает лучше.
2. Автоматизируйте сканирование уязвимостей в CI/CD. SAST (Static Application Security Testing) и DAST (Dynamic Application Security Testing) должны быть обязательным шагом пайплайна, а не опцией.
3. Аудитируйте зависимости. Используйте инструменты вроде npm audit, Snyk или OWASP Dependency-Check.
4. Обучайте команду безопасности. Разработчики должны понимать, какие уязвимости чаще всего генерирует ИИ для вашего стека.
5. Не жертвуйте безопасностью ради скорости. Если уязвимость критична — отложите релиз. Технический долг в безопасности обходится в разы дороже, чем в производительности.

Выводы

ИИ — это не замена разработчику, а ускоритель. Как любой ускоритель, он требует тормозов. Когда 30% всех опрошенных сознательно деплоят код, в котором сами признают уязвимости, проблема не в технологиях — а в отсутствии дисциплины. Не верьте нейросети на слово: проверяйте зависимости, сканируйте код, требуйте ревью. Ускорение без контроля — это не оптимизация, а авария в замедленной съёмке.

Источник: The Register — Devs know AI code is riddled with holes, but ship it anyway

Но пока что искусственный интеллект работает не идеально и может допускать ошибки и уязвимости. Чтобы увеличить надёжность результатов работы ИИ, есть несколько правил. Применять их можно даже без опыта разработки, достаточно использовать те же ИИ-инструменты. Что это за правила, рассказывает руководитель больших данных, высоконагруженных систем и машинного обучения Битрикс24 Александр Сербул.

Когда вайбкодинг — это риск

Искусственный интеллект позволяет нам писать код на любом языке: описать желаемую цель простым языком и получить работающий результат. Это потрясающая возможность. Но при этом нужно помнить ограничения этой технологии.

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

Создатель AI-агента Open Claw Питер Штайнбергер говорит: «Вайбкодинг — это навык, который прокачивается». Это значит, что использовать публично и в открытом доступе под нагрузками для критически важных процессов написанный ИИ код можно только при полном понимании того, как он работает.

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

Правило 1: выбираем строго типизированный язык

Программа работает с разными типами данных: числами, строками, логическими значениями.

Некоторые языки программирования более гибкие, например PHP, Python или JavaScript. В них можно менять типы данных по ходу работы программы — это может быть удобно разработчику, но для ИИ повышается вероятность допустить ошибку. Другой вариант — типизированные языки, которые заставляют разработчика сразу указывать, какие типы данных где находятся: TypeScript, Java, Kotlin, Rust. Человеку с таким языком работать труднее, но нейросети их понимают хорошо, и количество ошибок нейросети резко снижается.

Для гибких языков программирования решение тоже есть: можно добавить дополнительные аннотации типов и проверки-валидаторы типов данных. Пример такого валидатора — MyPy для Python.

В работе это будет выглядеть так: нам нужна функция, которая должна складывать числа, но нейросеть случайно передаёт туда строку. Без проверки это приведёт к ошибке уже во время работы. С типизацией система сразу скажет: «Сюда можно передавать только числа».

Поэтому первое правило для профессионального вайбкодинга: выбирать строго типизированный язык или добавлять валидаторы типов данных.

Правило 2: включаем базовую проверку с помощью линтеров

Линтеры — это инструменты, которые автоматически проверяют код: стиль, потенциальные ошибки и уязвимости. Они помогают сделать код проще и понятнее, а значит — снизить вероятность ошибок.

Написать работающую программу можно по-разному. Одним из важных навыков для программиста считается писать понятный код. Это важно не только при работе в команде, но и при одиночной разработке: программа должна оставаться понятной, если вы открываете её через месяц или полгода. Именно поэтому годами создаются правила стиля в программировании, которые помогают писать понятный людям код.

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

Поэтому берем за правило всегда добавлять линтеры для базовой проверки.

Правило 3: пишем тесты

Есть ещё одна проблема, которую в 1936 году сформулировал британский математик Алан Тьюринг. Её смысл в том, что невозможно написать программу, которая гарантированно определит корректность другой программы.

Хотя полностью быть уверенным в правильной работе компьютерной системы нельзя, некоторые конкретные случаи проверить всё-таки можно. Для проверки этих случаев пишут другие программы — тесты. Они сильно снижают количество возможных ошибок, и нейросети хорошо справляются с созданием таких проверочных программ.

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

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

Правило 4: считаем тестовое покрытие

Следующий шаг, который нужен для надёжного вайбкодинга: общее тестовое покрытие.

Покрытие показывает, какая часть приложения проверяется тестами. Иначе может оказаться так, что тесты есть, но значительную часть кода они не проверяют. Покрытие измеряется в процентах. Например, покрытие в 75% может означать, что тесты проверяют 750 строк из 1000.

Покрытие — это показатель не качества тестов, а того, насколько код вообще проверяется. Даже 100% покрытие не гарантирует отсутствие ошибок, но его отсутствие почти всегда означает, что часть системы вообще не проверяется.

Правило четвёртое: считайте процент тестового покрытия. Минимальный процент — 70-80% программы.

Правило 5: проверяем входные данные, фреймворки и зависимости

Есть ещё несколько дополнительных ограничений, которые делают систему более устойчивой.

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

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

Минимальное количество фреймворков. Чтобы разработка была проще и быстрее, программисты используют инструменты с готовыми фрагментами кода: библиотеки и фреймворки. С фреймворком одна команда может заменить несколько десятков строк кода.

Проблема в том, что фреймворк — это отдельная сложная программа, и почти к каждому есть сложная объёмная документация. Фреймворк — это сложная внешняя система со своей логикой и обновлениями. Чем больше фреймворков — тем сложнее поддержка и выше риск ошибок. Поэтому если задачу можно решить за 50-100 строк обычного кода, не нужно пытаться сократить их за счёт добавления фреймворка.

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

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

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

Чтобы упростить процесс такого контроля за продуктом, можно использовать специально подготовленные платформы для ИИ-разработки, вроде Битрикс24 VibeCode или Replit. Такие платформы работают по разному: выстраивают ограничения для агентов, другие сразу направляют ИИ для работы с конкретными технологиями. Ещё в них используются техники минимизации рисков: серверы с запущенными приложениями недоступны для атаки снаружи, а данные из приложений фильтруются через слой защищённого официального REST API.

Пятое правило: проверять входные данные, минимизировать количество фреймворков и постоянно обновлять зависимости и проверять их на уязвимости.

Насколько надёжнее становится результат вайбкодинга

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

Лучше всего, если финальный продукт для публичного доступа, высоких нагрузок и использования в критически важных процессах проверяется профессиональным разработчиком, который разбирается во всех слоях программы. Именно поэтому важно использовать минимальное количество фреймворков и библиотек: в реальной работе код проверяется программистами, а найти специалиста с хорошим знанием 5-8 фреймворков довольно сложно.

Исследователь Доминик Цёлек (ciolek.dev) обнаружил два бага в цепочке компиляции Go и сообщил о них команде безопасности. Та ответила на первый отчёт через 3 минуты, на второй — через 4. Что показательно: git blame указал на самого исследователя как автора кода, в котором обнаружился баг, — он же сам написал его три года назад.

• CVE-2026-27143: переполнение int8-счётчика в цикле → prove pass удалял bounds check → инъекция инструкций
• CVE-2026-27144: no-op-конверсия *p = T(*q) вместо *p = *q → компилятор пропускал careful copy path при пересечении памяти → memory corruption
• Общая причина: «counterfeit certainty» — оптимизатор повышал «вероятно безопасно» до «доказано безопасно» слишком рано
• Memory safety — свойство всей цепочки инструментов (frontend, optimizer, lowering, runtime, codegen), а не только языка
• «Every optimization is a security claim» — каждая оптимизация компилятора является утверждением о безопасности

Баг 1 (CVE-2026-27143): переполнение счётчика цикла убирает bounds check

Первый баг связан с фазой prove pass — проходом компилятора, который статически доказывает инварианты и на основании этого удаляет избыточные проверки. Идея хорошая: зачем проверять границы массива, если компилятор «знает», что индекс всегда находится в допустимом диапазоне?

Рассмотрим цикл с переменной типа int8, шагом 10 и лимитом 120:

На первый взгляд код безопасен: i не превышает 120, массив размером 200 байт — никакого выхода за границы. Prove pass рассуждал именно так: раз условие цикла гарантирует i ∈ [0, 120], bounds check можно удалить.

Но int8 хранит значения от -128 до 127. После 120 следующий шаг — 130, что переполняет тип и оборачивается в -126. Условие i < 120 снова становится истинным, цикл продолжается, но уже с отрицательным индексом. Bounds check, который мог бы это поймать, компилятор уже выбросил — ведь он «доказал» безопасность. В результате происходит запись за пределы массива, что открывает возможность для control-flow hijack и инъекции инструкций.

Prove pass повысил «индекс вероятно в пределах диапазона» до «индекс доказано в пределах диапазона», не учтя возможность целочисленного переполнения малых типов.

Баг 2 (CVE-2026-27144): no-op-конверсия и пересечение памяти

Второй баг тоньше. Go использует «careful copy path» — специальный путь копирования данных при работе с пересекающимися областями памяти (overlapping memory). Без него можно записать в destination данные, которые уже были перезаписаны в процессе копирования из source.

Проблема возникала при казалось бы безобидной конструкции — no-op-конверсии типа при присваивании через указатель:

Конверсия T(*q) здесь не делает ничего содержательного — типы совпадают. Компилятор распознал её как no-op и оптимизировал… но при этом забыл переключиться на careful copy path. Если области памяти p и q пересекаются — данные копируются некорректно, что приводит к повреждению памяти.

Особенно опасным сценарием оказались slice values: заголовок слайса содержит указатель на данные, длину и ёмкость. При некорректном копировании заголовка указатель мог указывать на произвольную память, а длина — быть некорректной.

Общая причина: «counterfeit certainty»

Оба бага объединяет одна концептуальная проблема: компилятор принимал «вероятно безопасно» за «доказано безопасно» и на этом основании удалял защитные механизмы. Цёлек называет это counterfeit certainty — поддельная уверенность.

В первом случае prove pass «доказал» безопасность индекса, не учтя переполнение малых целых типов. Во втором случае оптимизатор «знал», что конверсия — no-op, и сделал из этого вывод, что careful copy path не нужен. В обоих случаях рассуждение было формально правильным, но неполным: не были рассмотрены все возможные состояния программы.

Every optimization is a security claim. — Каждая оптимизация компилятора является утверждением о безопасности.

Когда компилятор удаляет bounds check — он утверждает, что выход за границы невозможен. Когда он пропускает careful copy path — он утверждает, что пересечения памяти нет. Ошибка в этих утверждениях напрямую превращается в уязвимость безопасности.

Memory safety — свойство всей цепочки инструментов

Принято считать, что memory-safe языки (Go, Rust, Java, C#) гарантируют отсутствие memory corruption по определению. Это правда — в рамках спецификации языка. Но между спецификацией и работающей программой стоит компилятор.

Цепочка компиляции Go включает несколько фаз, каждая из которых делает предположения о корректности предыдущей:

• Frontend (парсинг, type checking) — проверяет синтаксис и типы
• Optimizer (prove pass, escape analysis) — доказывает инварианты и устраняет лишние проверки
• Lowering — преобразует высокоуровневые операции в машинно-зависимые
• Runtime (garbage collector, goroutine scheduler) — управляет памятью во время выполнения
• Codegen — генерирует итоговый машинный код

CVE-2026-27143 затронул фазу optimizer, CVE-2026-27144 — фазу lowering. Обе уязвимости существовали несмотря на то, что исходный код был написан на «memory-safe» языке. Memory safety — это свойство, которое нужно обеспечивать на каждом уровне стека, не только на уровне языка.

Go security team: ответ за 3–4 минуты

Исследователь отправил отчёты об обоих багах в Go security team. Первый ответ пришёл через 3 минуты, второй — через 4. Оба бага были исправлены в Go 1.26.1. Сам Цёлек отметил, что процесс взаимодействия с командой был образцовым: быстрая реакция, прозрачная коммуникация и оперативный выпуск патча.

При разборе бага исследователь запустил git blame на подозрительный участок кода компилятора — и обнаружил собственное имя. Три года назад он сам написал этот код. По его словам, это добавило исследованию особой иронии и заставило более внимательно относиться к тому, что «очевидные» оптимизации несут в себе скрытые предположения о безопасности.

Выводы

История с CVE-2026-27143 и CVE-2026-27144 показывает: использование memory-safe языка — необходимое, но недостаточное условие для безопасности программы. Компилятор — не чёрный ящик с гарантиями, а сложная система с собственными инвариантами, которые могут нарушаться.

Оба бага существовали в «тихих» местах: оптимизаторе, который молча удалял проверки, и в lowering-фазе, которая молча пропускала защитный путь копирования. Ни один линтер, ни один статический анализатор не мог их обнаружить — ведь исходный код был совершенно корректным с точки зрения языка.

Практический вывод прост: обновляйтесь. Следите за golang-announce, обновляйтесь до новых версий Go сразу после выхода патчей безопасности, и помните, что «написано на Go» ≠ «memory-safe по определению».

curl — одна из самых распространённых программных библиотек в мире. В форме libcurl она работает на десятках миллиардов устройств. При таком масштабе любая компрометация может иметь катастрофические последствия.

— Каждый коммит и каждый релиз open-source проекта — потенциальная точка атаки: от внедрённого контрибьютора до взломанного CI

— curl применяет более 20 мер верификации: от запрета бинарных блобов и Unicode в коде до обязательного фаззинга и torture-тестов

— Внешние пользователи могут и должны верифицировать релизы: проверять подписи, сравнивать содержимое архивов с git-репозиторием

— Это не паранойя — это инженерная дисциплина, которая позволяет проекту оставаться надёжным уже 30 лет

— Стенберг призывает требовать такого же уровня верификации от всех зависимостей в вашем стеке

Атаки на supply chain: 9 сценариев угроз

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

• Внедрённый контрибьютор — как в случае с Jia Tan и xz-utils: внешне добросовестный участник команды, который намеренно маскирует вредоносный код под обычные коммиты
• Скомпрометированный мейнтейнер — авторизованный разработчик, чья учётная запись или машина взломаны. Его коммиты и релизы теперь содержат заражённый код
• «Полезный» баг-фикс от незнакомца — маленький шаг в длинной цепочке крошечных изменений, которые постепенно формируют уязвимость или бэкдор
• Шантаж или давление — существующего участника проекта принуждают вносить изменения, которые иначе были бы отклонены
• Непреднамеренная ошибка — добросовестный разработчик при добавлении фичи или исправлении бага случайно создаёт уязвимость
• Подмена на уровне дистрибуции — сайт, с которого раздаются тарболлы (архивы с исходным кодом для релиза), взломан; вместо оригинальных архивов раздаётся малварь
• Компрометация учётных данных — от имени известного участника проекта распространяется дезинформация через email, соцсети, блоги или даже дипфейк-видео
• Атака через CI-инфраструктуру — инструмент, используемый в CI и размещённый в облаке, взломан и исполняет вредоносный код
• Поддельное зеркало — пока основной git-репозиторий недоступен, кто-то предлагает «временное зеркало» с заражённым кодом

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

Верификация релизов: как пользователи могут проверить curl

Люди спрашивают Стенберга, как он спит по ночам, учитывая масштаб curl и количество возможных атак.

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

Если хотя бы несколько независимых пользователей проверят, что релиз curl подписан мейнтейнером, а содержимое совпадает с тем, что есть в git-репозитории, — проект в хорошем состоянии. Достаточно нескольких независимых наблюдателей, чтобы любая аномалия была замечена.

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

Безопасность curl изнутри: более 20 мер верификации

Внешние наблюдатели могут подтвердить, что релизы соответствуют тому, что есть в git. Но обеспечить, чтобы в git попадал только безопасный и корректный код, — это внутренняя работа команды. Вот полный список мер:

Стандарты кода и ограничения

• Единый стиль кода — нарушение стиля вызывает ошибку сборки. Это снижает риск случайных ошибок и упрощает ревью
• Запрет «опасных» C-функций — функции, которые легко использовать неправильно, запрещены. Их использование вызывает ошибку
• Лимит на сложность функций — если функция слишком сложна, это ошибка сборки. Код должен быть читаемым и понятным
• Запрет бинарных блобов в git — никаких способов спрятать зашифрованный вредоносный код. Попытка добавить блоб вызывает ошибку
• Избегание base64-кодированных фрагментов — ещё один способ обфускации, который curl активно исключает
• Ограничение Unicode в коде и документации — большинство использований Unicode запрещено, чтобы предотвратить homoglyph-атаки (подмену символов визуально похожими из другой кодировки, например кириллической «а» вместо латинской «a»)
• Документирование всего — код, API, поведение — всё задокументировано, чтобы не было сюрпризов. Документация тестируется, проверяется спеллчекером и проходит ревью наравне с кодом

Тестирование и непрерывная интеграция

• Обязательное ревью каждого PR — и людьми, и ботами. Коммиты ссылаются на исходный PR
• Тысячи тестов — для каждой функции. Поиск «белых пятен» в покрытии — приоритетная задача
• Более 200 CI-джобов — запускаются для каждого коммита и каждого PR. Без объяснённых провалов тестов мёрж невозможен
• Максимально строгие опции компилятора — все предупреждения трактуются как ошибки через -Werror. Ни одно предупреждение не остаётся без внимания
• Valgrind и санитайзеры — все тесты прогоняются через valgrind и несколько комбинаций санитайзеров для обнаружения проблем с памятью и неопределённого поведения (undefined behavior)
• Torture-тесты — каждый тест перезапускается так, чтобы каждый вызов функции, способной завершиться ошибкой, упал ровно один раз. Это гарантирует: curl не утекает памятью и не падает при любых сбоях
• Непрерывный фаззинг — автоматическое тестирование случайными входными данными для поиска крашей и уязвимостей. Работает без остановки в рамках Google OSS-Fuzz и кратко в CI для каждого коммита

Защита CI-инфраструктуры от компрометации

• CI-джобы не пишут обратно в репозиторий — доступ только на чтение. Даже при компрометации CI код не может быть заражён
• Анализ конфигов CI — инструменты вроде zizmor проверяют скрипты CI на уязвимости
• Обязательная двухфакторная аутентификация — для всех коммиттеров на GitHub

Политика безопасности и стабильность API

• Уязвимости исправляются в следующем релизе — без исключений. Проблемы безопасности не висят после того, как о них сообщили
• Полная документация всех уязвимостей — каждая когда-либо найденная уязвимость curl задокументирована со всеми деталями
• Стабильность ABI и API — curl никогда не ломает обратную совместимость (ABI — бинарный интерфейс приложения, API — программный интерфейс). Это позволяет пользователям легко обновляться до версий с исправленными уязвимостями вместо того, чтобы сидеть на устаревших
• Независимые аудиты — код curl неоднократно проверяли внешние эксперты по безопасности. Все найденные проблемы были немедленно устранены

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

Не паранойя, а инженерная дисциплина

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

Это не паранойя. Эта система позволяет нам спокойно спать по ночам. Именно поэтому пользователи до сих пор полагаются на curl спустя тридцать лет разработки.

Недавно Стенберг добавил на сайт curl отдельную страницу верификации, где подробно описано, как проверить целостность релизов.

Безопасность зависимостей: что проверить в вашем проекте

Стенберг призывает: требуйте такого уровня верификации от всех зависимостей в вашем стеке. Вот конкретные шаги, которые вы можете предпринять уже сейчас:

Проверка подписей и целостности пакетов

Большинство пакетных менеджеров умеют проверять подписи. Убедитесь, что эта проверка включена:

Аудит зависимостей в CI

Встройте проверку уязвимостей в ваш CI-пайплайн:

Базы уязвимостей OSV и NVD — основные источники данных для этих инструментов.

Оценка практик ваших зависимостей

Прежде чем добавить зависимость, проверьте:

• Есть ли у проекта обязательное ревью PR? Посмотрите историю мёржей
• Есть ли CI с тестами? Проверьте бейджи в README и конфиги в .github/workflows/
• Как быстро закрываются уязвимости? Проверьте security advisories на GitHub
• Сколько активных мейнтейнеров? Один человек — точка отказа
• Используется ли OpenSSF Scorecard — автоматическая оценка безопасности open-source проекта

Выводы: доверяйте коду, а не репутации

Опыт curl показывает: безопасность open source — это не вопрос доверия, а вопрос верификации. За 30 лет разработки проект выстроил систему из более чем 20 конкретных мер — от запрета бинарных блобов до непрерывного фаззинга — которые вместе создают многоуровневую защиту.

Если проект с десятками миллиардов установок может работать полностью открыто и предоставлять инструменты верификации для каждого, то и другие проекты обязаны стремиться к тому же стандарту. Начните с малого: npm audit signatures, pip-audit, проверка security advisories ваших зависимостей.

Не доверяйте — проверяйте.

Источник: Don't trust, verify — блог Даниэля Стенберга

В субботу, 29 марта, около 210 экспертов из 24 стран — 130 очно и 80 удалённо — разрешили оставшиеся международные комментарии на встрече в Лондоне (Кройдон, Великобритания). Документ отправляется на финальное голосование ISO (DIS — Draft International Standard) и будет опубликован в ближайшее время.

— C++26 завершён — самый значимый релиз со времён C++11

— Четыре главные фичи: рефлексия, безопасность памяти, контракты, std::execution

— Рефлексия позволяет C++ инспектировать и генерировать собственный код на этапе компиляции

— Hardened stdlib уже развёрнута в Google (1000+ багов исправлено, segfault-ы −30%) и Apple с оверхедом 0,3%

— GCC уже имеет рефлексию и контракты в trunk — можно пробовать сейчас

— Работа над C++29 стартует в июне с фокусом на дальнейшую безопасность памяти

Четыре главные фичи C++26

Херб Саттер, почётный председатель комитета ISO C++ (chair emeritus с 2025 года), называет их «Fab Four» — четвёрка фич, которые делают C++26 прорывным релизом.

1. Рефлексия — крупнейшее обновление со времён шаблонов

Compile-time рефлексия позволяет C++ описывать самого себя и генерировать код на этапе компиляции. Оператор ^ (reflection operator) превращает сущность в её метаданные, а шаблонные функции из пространства std::meta позволяют работать с ними:

По словам Саттера, это «самый мощный новый движок для выражения эффективных абстракций за всю историю C++». Рефлексия попала в драфт C++26 ещё в июне 2025 года.

2. Меньше UB — больше безопасности памяти

C++26 делает существующий код безопаснее просто при перекомпиляции, без изменений в исходниках. UB (undefined behavior, неопределённое поведение) — исторически главный источник уязвимостей в C++. Два ключевых улучшения:

• Чтение неинициализированных переменных больше не UB. Целая категория уязвимостей исчезает при переходе на C++26
• Hardened стандартная библиотека — автоматические проверки границ при обращении к элементам vector, span, string, string_view и десятков других типов. При выходе за границы — trap вместо тихого повреждения памяти

Это не теоретический дизайн. В Google hardened stdlib уже развёрнута на сотнях миллионов строк C++: исправлено более 1000 багов, прогноз — предотвращение 1000–2000 багов в год, segfault-ы по всему production-флоту снизились на 30%. В Apple — аналогичный масштаб. Средние накладные расходы — всего 0,3% производительности.

Из сотен миллионов строк C++ в Google только пять сервисов полностью отказались от hardening из-за проблем с производительностью. Гранулярный API для небезопасного доступа использовался всего в семи местах.

3. Контракты: pre, post, contract_assert

Языковые контракты позволяют задавать предусловия, постусловия и утверждения прямо в объявлениях функций — вместо хрупкого макроса assert из C, который не знает ни о параметрах, ни о возвращаемых значениях:

Фича вызвала серьёзные дебаты. Часть комитета считает, что текущий дизайн контрактов недостаточно продуман — в частности, спорным остаётся поведение при нарушении контракта (вызов хендлера vs немедленный terminate). На финальном голосовании 114 экспертов проголосовали за, 12 — против, 3 воздержались. Рекордно низкое число воздержавшихся показывает, что все определились с позицией.

4. std::execution — асинхронная модель C++

std::execution (Sender/Receiver) предоставляет унифицированный фреймворк для конкурентности и параллелизма. В отличие от std::async и сырых потоков, фреймворк обеспечивает структурированную конкурентность — код свободен от гонок данных по конструкции.

Саттер предупреждает: фича мощная (его компания Citadel Securities уже использует её в production), но пока её сложнее освоить, чем большинство фич C++ — не хватает документации и вспомогательных библиотек.

Быстрое внедрение

Саттер ожидает, что C++26 будет внедряться значительно быстрее, чем C++17/20/23. Две причины:

1. Экстраординарный спрос. Рефлексия нужна всем, кто пишет сериализацию, ORM, конфигурации, логирование. Hardened stdlib даёт безопасность бесплатно. В отличие от нишевых фич C++20 (концепты, модули), здесь каждый C++-разработчик найдёт применение в своём коде
2. Компиляторы уже готовы. На протяжении разработки C++26 и GCC, и Clang уже реализовали две трети фич. GCC уже имеет рефлексию и контракты в trunk — можно пробовать прямо сейчас

Как попробовать C++26 уже сейчас

Рефлексию и контракты можно попробовать в Compiler Explorer (godbolt.org), выбрав GCC trunk с флагом -std=c++26 -freflection. Hardened stdlib в libstdc++ активируется флагами:

C++29: ещё больше безопасности

На встрече приняли расписание C++29 (следующий трёхлетний цикл). Главный фокус — дальнейшее усиление безопасности памяти, в том числе профили безопасности Бьёрна Страуструпа.

Особенно примечателен доклад Оливера Ханта из Apple (P4158R0): WebKit захардинил более 4 миллионов строк кода подходом «подмножество надмножества» (аналогично Profiles). Результат: закрыты целые классы уязвимостей, политики предотвратили бы большинство исторических эксплойтов.

Следующие встречи комитета — в Брно (Чехия) в июне и в Бузиос (Рио-де-Жанейро, Бразилия) в ноябре, где начнётся работа над фичами C++29.

Выводы

C++26 — начало фундаментально новой эры: C++ становится безопаснее по умолчанию, оставаясь верным принципу zero-overhead. Рефлексия даёт инструмент, который заменит тонны макросов и кодогенераторов. Hardened stdlib уже доказала свою эффективность на сотнях миллионов строк кода в Google и Apple.

Подробный отчёт со встречи — в блоге Херба Саттера.

EDR — это очень мощное ПО. Можно сказать, что это основа современной безопасности.

Но есть такая техника, при которой EDR лежит кверху лапками, как безобидный щеночек, а не как сторожевой пес размером с трактор. Эта техника называется BYOVD (Bring Your Own Vulnerable Driver), посредством которой злоумышленники проникают в систему, повышают привилегии и потом делают то, что им нужно.

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

Теоретическая часть: как работает BYOVD-атака

BYOVD очень опасная техника.

• Программы-вымогатели BlackByte и AvosLocker использовали BYOVD для обхода средств защиты.
• По данным Huntress, в 2024 году значительная доля атак шифровальщиков включала обход EDR — в том числе через уязвимые драйверы.
• BYOVD — типовая фаза ransomware-операций, а ransomware — главная киберугроза для российского бизнеса. В 2024 году шифровальщики парализовали СДЭК на трое суток (300 тыс. посылок в день), положили платёжные терминалы сети «Верный» по всей стране (убытки 120–140 млн руб./день), а в июле 2025-го хакеры уничтожили ИТ-инфраструктуру «Аэрофлота», вынудив отменить более 100 рейсов. Во всех этих инцидентах ключевым этапом было отключение защиты — и именно BYOVD остаётся самой распространённой техникой для этого. По данным Symantec, в 2026 году BYOVD стал наиболее частым методом обхода EDR в ransomware-атаках.
• BYOVD — обязательный компонент в кибершпионаже. К слову, в процессе знаменитой масштабной операции по кибершпионажу, называемой Operation DreamJob, проводимой группировкой Lazarus, использовался BYOVD. Группировка создавала фейковые профили рекрутеров в LinkedIn и рассылала жертвам «вакансии» — ISO-файлы с вредоносной начинкой: многоступенчатой цепочкой загрузчиков (RollFling → RollSling → RollMid → KaolinRAT), финальным звеном которой был FudModule — руткит, работающий на уровне ядра.

Практически во всех крупных ransomware-инцидентах ключевой этап — отключение EDR перед шифрованием. Если описать BYOVD в двух словах, то Bring Your Own Vulnerable Driver (BYOVD) — это техника, при которой злоумышленник использует уязвимость Windows, чтобы обойти EDR и получить привилегированный доступ к системе.

Дело в том, что Windows делит весь исполняемый код на два уровня доверия — в архитектуре x86 они называются кольцами защиты (protection rings): Ring 3 пользовательский режим, и Ring 0 режим ядра.

Обычные программы, вроде браузера, работают в Ring 3 и имеют ограниченный набор привилегий. А в ядре (Ring 0) работают ntoskrnl.exe (само ядро), HAL, файловая система, сетевой стек и все драйверы. А имея доступ к Ring 0 можно модифицировать любые структуры данных, завершать любые процессы и отключать любую телеметрию, что и делают BYOVD программы.

Доступ к Ring 0 можно получить посредством драйвера, потому что драйверы в Windows работают в ring 0 — то есть на уровне ядра, с максимальными привилегиями. Чтобы обезопасить ядро от нелегитимных пользователей, Microsoft ввёл обязательную подпись драйверов (DSE — Driver Signature Enforcement) и в теории, загрузить произвольный код в ядро нельзя — драйвер должен быть подписан сертификатом, которому доверяет Microsoft.

На деле в BYOVD-атаках используются именно легитимные подписанные драйверы, потому что Windows не проверяет списки отзыва сертификатов (CRL) при загрузке драйверов — на этом этапе загрузки ОС сеть ещё недоступна. Например, в феврале 2026 года Huntress обнаружил атаку, где 20-летний драйвер EnCase (драйвер EnCase подписан сертификатом от 15 декабря 2006 года) с отозванным сертификатом мог убивать 59 EDR-процессов.

EDR — это такой гибрид, у которого пользовательский интерфейс работает в Ring 3, а для мониторинга он устанавливает свой kernel-mode драйвер в Ring 0. Мониторинг EDR основан на kernel callbacks — специальных функциях- уведомлениях, которые ядро вызывает при определённых событиях, например, когда создаётся процесс — срабатывает PsSetCreateProcessNotifyRoutine, а когда загружается DLL — PsSetLoadImageNotifyRoutine.

Коллбэки регистрируются EDR-драйвером при загрузке, и ядро хранит их адреса в служебных структурах — таких как CallbackListHead.

Помимо kernel callbacks, EDR перехватывает вызовы API-функций через function-hooking DLL, которая инжектируется в каждый процесс. Эти хуки работают в user mode и подменяют первые байты функций ntdll.dll (например, NtAllocateVirtualMemory) на переход в код EDR.

Поэтому даже после отключения kernel callbacks EDR может получать телеметрию через user-mode хуки — и наоборот. Продвинутые руткиты атакуют оба уровня одновременно.

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

Microsoft поддерживает встроенный блок-лист уязвимых драйверов, но он покрывает лишь малую часть из сотен известных уязвимых драйверов в базе LOLDrivers.

Как так происходит? Есть три подхода к получению kernel-доступа, в том числе через BYOVD и смежные техники.

Подход 1: N-day уязвимости в сторонних драйверах

Атакующий берёт драйвер известного производителя (Dell, Intel, Realtek, MSI и десятки других) с уже обнаруженной уязвимостью. Драйвер подписан валидным сертификатом, DSE его пропускает. Через уязвимость (обычно это IOCTL, который позволяет произвольное чтение/запись физической или виртуальной памяти) атакующий получает примитивы для модификации ядра.

Примечание. Проект LOLDrivers.io на сегодня каталогизирует сотни таких драйверов.

Например, таким образом действовал инструмент FudModule группировки Lazarus (HIDDEN COBRA, APT38) — одной из самых технически продвинутых APT-группировок, связанных с КНДР. Первая версия FudModule (обнаружена ESET в 2022 году) эксплуатировала уязвимость CVE-2021-21551 в драйвере Dell dbutil_2_3.sys. Этот драйвер, предназначенный для обновления BIOS и firmware ноутбуков Dell, содержал критическую уязвимость: он принимал IOCTL-запросы, позволяющие читать и записывать произвольную физическую память без каких-либо проверок вызывающего процесса.

Для атакующего — находка: драйвер подписан Dell, Microsoft ему доверяет, а через IOCTL можно получить полный контроль над памятью ядра. Lazarus сбрасывали этот драйвер на диск, загружали через sc.exe create / sc.exe start и получали примитивы чтения/записи ядра.

Подход 2: Злоупотребление PreviousMode

Через эксплуатацию уязвимости атакующий меняет поле PreviousMode в структуре _KTHREAD текущего потока с UserMode (1) на KernelMode (0). После этого системные вызовы NtWriteVirtualMemory и NtReadVirtualMemory перестают проверять границы памяти и позволяют напрямую модифицировать пространство ядра из user mode.

Подход 3: 0-day в компонентах Windows

Более сложный путь: атакующий находит уязвимость в штатном драйвере операционной системы. Именно так поступила (опять же) группировка Lazarus с CVE- 2024-21338 в appid.sys (компонент AppLocker). В 2024 году группировка обновила FudModule до версии 2.0 и вместо стороннего драйвера Dell они нашли и проэксплуатировали 0-day уязвимость в appid.sys, штатном компоненте Windows, отвечающем за AppLocker.

Уязвимость имеет номер CVE-2024-21338 и её суть в том, что драйвер appid.sys содержал IOCTL, позволяющий вызвать произвольную функцию ядра с частичным контролем над первым аргументом. Для эксплуатации требовался LOCAL_SERVICE account — Lazarus получал его через имперсонацию.

Цепочка эксплуатации выглядела так:

1. Имперсонация LOCAL_SERVICE через стандартные механизмы Windows.
2. Вызов уязвимого IOCTL в appid.sys для исполнения произвольной функции ядра.
3. Через полученный примитив — модификация поля PreviousMode в _KTHREAD текущего потока (с UserMode на KernelMode).
4. Теперь NtWriteVirtualMemory / NtReadVirtualMemory можно вызывать из user mode без проверки границ → полный R/W доступ к памяти ядра.

Преимущество перед классическим BYOVD очевидно: не нужно сбрасывать файл на диск, не нужно загружать сторонний драйвер — appid.sys уже есть в каждой системе с включённым AppLocker. Это существенно снижает IoC и затрудняет детектирование.

Публичные тулкиты: BYOVD для всех

При этом BYOVD — это дешевый вид атаки — в 2024–2025 года готовые инструменты появились как грибы после дождя: на даркнет-форумах за несколько сотен долларов можно купить EDRKillShifter, AuKill, Blackout и прочее ПО для атак.

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

№1. BYOVD встраивается ВНУТРЬ ransomware

В феврале 2026 года Symantec зафиксировал новый паттерн: группировка Reynolds встроила уязвимый драйвер NSecKrnl прямо в payload шифровальщика. Раньше BYOVD-компонент и ransomware были отдельными файлами с временным зазором между ними — этот зазор давал SOC шанс среагировать. Теперь одного бинарника достаточно для отключения EDR и шифрования. По оценке Symantec, BYOVD стал самой частой техникой обхода защиты в ransomware-атаках 2026 года.

№2. POORTRY: кастомный вредоносный драйвер

Ещё интереснее POORTRY (Abyssworker) — не уязвимый легитимный драйвер, а специально написанный вредоносный драйвер, к которому атакующие получили валидную подпись через украденные сертификаты WHCP. Он маскировался под антивирусный компонент (например, драйвер Malwarebytes) и использовался в атаках Medusa и Osiris.

№3. RansomHub и EDRKillShifter

Группировка RansomHub разработала собственный инструмент EDRKillShifter, эксплуатирующий уязвимый драйвер TrueSight.sys. Инструмент стал стандартным компонентом их ransomware-набора и использовался для отключения EDR перед развёртыванием шифровальщика. По данным исследователей, EDRKillShifter применялся в десятках инцидентов в 2024 году.

№4. Kasseika: антивирусный драйвер против антивируса

Группировка Kasseika использовала ироничный подход — уязвимый драйвер антивирусного продукта (Martini.sys от TG Soft’s VirIT) для отключения конкурирующих EDR-решений. Цепочка атаки: через PsExec распространялся загрузчик, который сбрасывал уязвимый антивирусный драйвер, загружал его и через IOCTL завершал процессы защитных решений. После этого развёртывался шифровальщик.

№5. Deadlock: Baidu против безопасности

В декабре 2025 года Cisco Talos задокументировал новый вариант вымогателя Deadlock, использующий уязвимый драйвер Baidu Antivirus (BdApiUtil.sys, CVE- 2024-51324).

Атакующие использовали лоадер EDRGay.exe, который сбрасывал драйвер под именем DriverGay.sys в директорию Videos жертвы. Через IOCTL 0x800024b4 лоадер вызывал ZwTerminateProcess() для завершения всех EDR-процессов. Уязвимость квалифицирована как Improper Privilege Management — непривилегированный пользователь мог завершить любой системный процесс.

№6. BlackByte : систематический подход

BlackByte продемонстрировал системный подход к BYOVD: группировка использовала несколько уязвимых драйверов в разных кампаниях, включая RTCore64.sys и драйверы из базы LOLDrivers. Особенность их подхода — интеграция BYOVD-компонента непосредственно в цепочку развёртывания ransomware, с автоматическим выбором драйвера в зависимости от целевой системы.

Список ransomware-групп, использующих BYOVD, продолжает расти: Qilin (драйверы Zemana и Toshiba), Akira (драйвер Intel), Play, BianLian, Medusa, Rhysida, Cuba, GhostLocker, INC, Interlock (GameDriverx64.sys, CVE-2025- 61155). BYOVD стал стандартной фазой операции ransomware.

Разберём BYOVD-тулкит на примере Blackout

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

Большинство BYOVD-инструментов следуют одному паттерну: сбросить уязвимый драйвер на диск (часто в %TEMP% или %APPDATA%), создать и запустить сервис для его загрузки, через IOCTL получить примитив завершения произвольного процесса и последовательно убить все EDR/AV процессы по списку.

Разберем цепочку событий, которую генерирует типичная BYOVD-атака на примере публичного тулкита Blackout (ZeroMemoryEx) в тестовой среде (даже если атака не завершилась успехом)

Что такое Blackout? Это открытый инструмент на GitHub, реализующий классический паттерн BYOVD: сбросить на диск подписанный уязвимый драйвер, загрузить его через SCM (Service Control Manager) и через IOCTL-запрос завершить целевой процесс из Ring 0. Использование тривиально — достаточно указать PID жертвы:

Blackout.exe -p <PID_процесса>

Запуск в тестовой среде. Находим PID Sysmon и запускаем Blackout:

Blackout успешно создал сервис для загрузки kernel-драйвера,

...но сам драйвер не загрузился, потому что сертификат подписи драйвера (GMEREK Systemy Komputerowe, Польша) отозван Microsoft и внесён в Certificate Trust List операционной системы:

Скриншот cs start — ошибка отзыва сертификата.

Драйвер Blackout.sys подписан валидной цифровой подписью — но Microsoft, узнав об использовании этого драйвера в атаках, отозвал сертификат и добавил его хэш в системный блок-лист (Disallowed Certificate Store). Windows проверяет этот список при каждой загрузке драйвера — даже без доступа к интернету, потому что CTL вшит в ОС.

Это один из механизмов защиты от BYOVD, но с существенным ограничением: он работает только для уже известных драйверов. А база LOLDrivers.io содержит сотни уязвимых драйверов, и Microsoft физически не успевает отзывать все сертификаты. Поэтому атакующие просто берут менее известный драйвер — и блокировка не срабатывает.

Что увидит SOC. Несмотря на неудачную загрузку, попытка атаки оставила чёткие следы в телеметрии:

Event ID 7045 (System log — Service Control Manager).

Это событие — ключевой индикатор. Создание нового сервиса с типом «драйвер режима ядра», где путь к файлу указывает за пределы System32\drivers\ — аномалия, которая должна вызывать алерт максимального приоритета.

Хэш драйвера (SHA256): 18C909A2B8C5E16821D6EF908F56881AA0ECCEEACCB5FA1E54995935FCFD1 2F7

Есть хорошие новости: каждый этап BYOVD оставляет следы — надо знать, куда смотреть. Давайте приступим к финальной части статьи — к выстраиванию эшелонированного детектирования, не привязанного к конкретной SIEM-платформе.

Детектирование BYOVD: что и как мониторить

Правила детектирования BYOVD делятся на два типа.

• Brittle-детекты — ловят конкретные IoC: хэш известного уязвимого драйвера, имя файла, путь. Они дают минимальный false positive, но обходятся простой заменой драйвера.
• Robust-детекты — ловят поведение: цепочка «файл .sys → сервис → завершение EDR» сработает на любой неизвестный тулкит, но может дать ложные срабатывания на легитимную установку драйверов.

Эшелонированная стратегия строится на комбинации обоих типов.

Детект 1. Загрузка известного уязвимого драйвера

MITRE ATT&CK: T1068 (Exploitation for Privilege Escalation), T1562.001 (Impair Defenses: Disable or Modify Tools).

Самый базовый и эффективный детект — сопоставление хэшей загружаемых драйверов с базой LOLDrivers.io. Проект предоставляет актуальный список хэшей (SHA256, MD5, SHA1) всех известных уязвимых и вредоносных драйверов, а также готовые Sigma-правила.

Логика алерта:

Событие: загрузка драйвера (Sysmon Event ID 6 или аналог). Условие: SHA256-хэш загруженного файла совпадает с записью в базе LOLDrivers. Severity: Critical.

Дополнительные индикаторы, усиливающие уверенность:

• Драйвер загружается из нетипичного расположения (%TEMP%, %APPDATA%, %USERPROFILE%, директория Downloads).
• Имя драйвера не соответствует ожидаемому для данной системы (например, Dell dbutil на машине без оборудования Dell).
• Драйвер сбрасывается на диск непосредственно перед загрузкой (создание файла + загрузка драйвера в окне < 60 секунд).
• LOLDrivers.io отдаёт готовые Sigma-правила и CSV с хэшами для импорта в SIEM — не нужно собирать вручную.

Учти ограничение: хэш-детекты обходятся через CVE-2013-3900 (см. ниже).

Ограничение хэш-детектов: CVE-2013-3900 и Authenticode padding

Детект по SHA256 из LOLDrivers — необходимый минимум, но у него есть серьёзная слабость. CVE-2013-3900 — уязвимость в Windows Authenticode, которая позволяет менять байты в PE-файле за пределами подписанной области. Файловый хэш (SHA256) меняется, а подпись остаётся валидной. Windows загрузит такой драйвер без вопросов.

На практике это означает: атакующий берёт уязвимый драйвер из LOLDrivers, меняет пару байт — и получает файл, которого нет ни в одной хэш-базе. Check Point обнаружил более 2500 уникальных вариантов драйвера TrueSight.sys, созданных именно так: все с разными SHA256, все с одной подписью, все рабочие.

Есть два способа бороться с этим:

1. Authentihash — это хэш, который считается только по подписанным областям PE-файла. У всех 2500 вариантов TrueSight.sys один и тот же Authentihash, потому что подписанная часть не менялась. Если SIEM или EDR умеет работать с Authentihash — детект становится устойчивым к CVE-2013-3900.
2. Сертификат подписи — вместо хэша файла можно строить детект на сертификате, которым подписан драйвер (Subject, Issuer, Serial Number). Даже после модификации байтов сертификат остаётся тем же. Для Sysmon EID 6 доступны поля SignatureStatus и Signature — их можно использовать для фильтрации.

В KUMA это реализуется через дополнительную lookup-таблицу с Authentihash-значениями (доступны на LOLDrivers.io в формате CSV) или через проверку сертификата подписи в событиях Sysmon EID 6.

По сертификату подписи:

Митигация CVE-2013-3900 на уровне ОС — включить строгую проверку Authenticode через реестр:

После этого модифицированные драйверы с padding перестанут считаться подписанными. Фикс существует с 2013 года, но не включён по умолчанию — Microsoft боится сломать совместимость.

Детект 2. Подозрительное создание сервиса для драйвера

MITRE ATT&CK: T1543.003 (Create or Modify System Process: Windows Service)

Загрузка драйвера в Windows происходит через создание сервиса типа «kernel driver». Это генерирует события Windows Security (Event ID 4697 — A service was installed in the system) и System (Event ID 7045 — A new service was installed). Детект фокусируется на аномалиях:

Логика алерта:

Событие: создание нового сервиса с типом kernel driver (Event ID 7045). Условие: ImagePath указывает на файл вне стандартных директорий драйверов.

EID 7045 не содержит информации о родительском процессе — SCM логирует только параметры сервиса. Поэтому детектирование разбито на два правила: первое ловит аномальный путь в самом событии создания сервиса, второе — запуск sc.exe create type=kernel через Sysmon EID 1.

+

Детект 3. Создание символической ссылки на драйверы/файлы security-вендоров

MITRE ATT&CK: T1036 (Masquerading), T1562.001 (Impair Defenses)

Для детектирования техники Symbolic Link + BYOVD необходимо мониторить создание символических ссылок (junction points, reparse points) в системных директориях или указывающих на файлы security-вендоров.

Логика алерта:

Событие создания файла типа symbolic link, где компания-производитель целевого файла — security-вендор, а путь указывает на системную директорию драйверов.

На каком событии строить детект: Sysmon Event ID 11 (FileCreate) — срабатывает при создании файлов, включая reparse points (junction/symlink).

Правило в логическом виде:

Проще говоря: кто-то создал что-то в папке drivers\ и это не установщик драйверов Windows — подозрительно.

Детектирование Symbolic Link + BYOVD возможно на двух уровнях.

Базовый — через Sysmon Event ID 11: любое создание файла в C:\Windows\System32\drivers\ процессом, не являющимся штатным установщиком, генерирует алерт.

Продвинутый — через EDR-телеметрию, где доступен тип файла (symlink) и метаданные целевого объекта (File Company Name). Это позволяет точно детектировать создание символической ссылки, подменяющей компонент security-вендора, с минимальным уровнем false positive.

Логика реализуема в EDR-решениях с расширенной файловой телеметрией (Kaspersky KEDR Expert, BIZONE EDR) где доступны поля типа файла (symlink/junction) и метаданные PE-заголовка целевого объекта (CompanyName, FileDescription).

Детект 4. Исчезновение kernel callbacks / молчание EDR

MITRE ATT&CK: T1562.001 (Impair Defenses: Disable or Modify Tools)

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

• Heartbeat-мониторинг EDR: если EDR-агент перестал отправлять телеметрию (или отправляет, но количество событий аномально снизилось) — это критический индикатор. SOC должен мониторить поток событий от каждого агента.
• ETW consumer watchdog: периодический опрос состояния ETW-сессий через logman query. Если системные ETW-сессии внезапно прекратились — это сигнал.
• Kernel callback verification: специализированные инструменты (или кастомный драйвер мониторинга) могут периодически проверять целостность массивов PspCreateProcessNotifyRoutine и CallbackListHead.

Логика алерта:

Условие: EDR-агент на хосте X не отправлял телеметрию более N минут (порог зависит от нормальной частоты). ИЛИ количество событий от агента снизилось более чем на 90% по сравнению с базовой линией за аналогичный период. Severity: Critical.

В KUMA это реализуется правилом на отсутствие событий: создаём корреляцию с типом «отсутствие события» (absence), где условие — от конкретного хоста не поступало ни одного события Sysmon за последние 10 минут. Порог подбирается под среду: для рабочих станций 10 минут, для серверов с высокой активностью — 5 минут.

Детект 5. Нетипичный процесс открывает хэндл к драйверу

MITRE ATT&CK: T1068 (Exploitation for Privilege Escalation)

При эксплуатации уязвимого драйвера атакующий вызывает CreateFile("\\\\.\\<DeviceName>") для получения хэндла, а затем DeviceIoControl() для отправки IOCTL-команд. В случае успешной загрузки обращение шло бы к устройству \\.\Blackout — объекту, зарегистрированному загруженным драйвером Blackout.sys.

Логика алерта:

Событие: если к устройству драйвера Dell (\\.\DBUtil_2_3) обращается не процесс Dell, а неизвестный бинарник из C:\Users\Downloads\ — это аномалии.

Реализация этого детекта требует расширенной телеметрии: аудита доступа к объектам ядра (Windows Security Policy → Object Access) или EDR с мониторингом device handle operations. Стандартный Sysmon этот уровень не покрывает — это один из аргументов в пользу EDR-решений с kernel-level телеметрией, даже с учётом рисков BYOVD.

В KEDR Expert и BI.ZONE EDR операции DeviceIoControl логируются через kernel-level телеметрию.

Если таких EDR нет — можно включить Object Access Auditing через GPO (Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Object Access → Audit Kernel Object), но это генерирует большой объём событий и требует тщательной фильтрации.

Детект 6. Аномалии PreviousMode

MITRE ATT&CK: T1068 (Exploitation for Privilege Escalation)

Этот детект — скорее гипотеза для threat hunting, чем правило для автоматического алертинга. Прямой мониторинг PreviousMode из user mode невозможен, но косвенные признаки могут указать на эксплуатацию:

PreviousMode это поле в структуре потока, которое говорит ядру: «Этот запрос пришёл из user mode или из kernel mode?»

Lazarus через CVE-2024-21338 менял это значение с 1 на 0. После этого обычный процесс мог вызывать NtWriteVirtualMemory и писать прямо в память ядра — ядро думало что запрос от компонента ядра.

Изменение PreviousMode в _KTHREAD — ключевой примитив атак CVE-2024- 21338 и аналогичных. Напрямую мониторить это из user mode невозможно, но можно детектировать косвенные признаки:

• Процесс из user mode успешно вызывает NtWriteVirtualMemory / NtReadVirtualMemory для адресов пространства ядра системы (> 0x7FFFFFFFFFFF) — это аномалия, которую можно детектировать через ETW-провайдер Microsoft-Windows-Kernel-Audit-API-Calls (если он ещё не отключён)
• Процесс LOCAL_SERVICE внезапно выполняет операции, не характерные для этого аккаунта — например, создаёт файлы, загружает DLL, устанавливает сетевые соединения.

Детект 7. Загрузка драйвера с отозванным или истёкшим сертификатом

MITRE ATT&CK: T1553.002 (Subvert Trust Controls: Code Signing)

Sysmon EID 6 при загрузке драйвера фиксирует статус подписи. Если подпись невалидна, отозвана или просрочена — это повод для алерта.

В конфигурации Sysmon должен быть включён тег <CheckRevocation/>.

Логика алерта:

Событие: загрузка драйвера (Sysmon EID 6). Условие: SignatureStatus не равен 'Valid'.

Дополнительный фильтр для снижения FP: исключить драйверы Microsoft, подписанные в тестовом режиме (если на хосте включён testsigning).

Этот детект ловит атаки типа EnCase BYOVD (Huntress, 2026): драйвер с сертификатом 2010 года, отозванным 15 лет назад, но всё ещё загружаемым Windows.

Детект 8. Комплексный подход: корреляция событий

Самый мощный детект — корреляция слабых сигналов в рамках одного инцидента. Типичная цепочка BYOVD-атаки генерирует следующую последовательность:

1. Файл .sys появляется в нетипичной директории (File Create)
2. Создаётся новый сервис типа kernel driver (Event ID 7045)
3. Загружается драйвер с хэшем из базы LOLDrivers (Sysmon ID 6)
4. Процесс открывает хэндл к устройству драйвера (File/Object Access)
5. Один или несколько EDR/AV процессов завершаются (Event ID 4689) или перестают генерировать телеметрию
6. Загруженный драйвер имеет невалидную, отозванную или просроченную подпись (Sysmon EID 6, SignatureStatus ≠ Valid)

Логика корреляционного правила:

Если на одном хосте в течение 5 минут происходят события #1 + #2 + (#3 ИЛИ #5 ИЛИ #6) — это с высокой вероятностью BYOVD-атака.

Готовые правила для SIEM KUMA

Для тех, кто работает с KUMA — пять правил корреляции, адаптированных под синтаксис платформы. Время внедрения — 15–20 минут на правило.

Правило 1. Загрузка драйвера из нестандартного пути

Тип: простое | Источник: Sysmon | Severity: HIGH | MITRE: T1068, T1543.003

Реакция: проверить хэш на loldrivers.io, найти источник файла (EID 11).

Правило 2. Создание kernel-mode сервиса

Тип: простое | Источник: Windows System Log | Severity: HIGH | MITRE: T1543.003

FP: установка драйверов ПО/принтеров. Коррелировать с EID 6.

Правило 3. sc.exe create type=kernel

Тип: простое | Источник: Windows Security / Sysmon | Severity: HIGH | MITRE: T1543.003

Правило 4. Массовое завершение защитных процессов

Тип: агрегация (count) | Источник: Sysmon | Severity: CRITICAL | MITRE: T1562.001

Реакция: НЕМЕДЛЕННАЯ ИЗОЛЯЦИЯ хоста!

Правило 5. ETW tampering через CLI

Тип: простое | Источник: Windows Security / Sysmon | Severity: HIGH | MITRE: T1562.006

Митигации: как снизить риск BYOVD

BYOVD не закрывается одним патчем — уязвимых подписанных драйверов сотни. Но усложнить атаку можно.

№1. HVCI (Hypervisor-Protected Code Integrity)

HVCI (также известный как Memory Integrity) использует гипервизор для контроля целостности кода ядра. С включённым HVCI загрузка драйверов проверяется на уровне VTL1, что значительно затрудняет эксплуатацию уязвимых драйверов. Ограничение: HVCI может вызывать проблемы совместимости со старым оборудованием и драйверами.

HVCI защищает ключевые структуры ядра, включая ci!g_CiOptions — переменную, контролирующую проверку подписей драйверов. Без HVCI атакующий с BYOVD-примитивом может перезаписать ci!g_CiOptions и загрузить вообще любой неподписанный драйвер. С включённым HVCI эта переменная находится под защитой гипервизора (VTL1), и попытка записи вызовет исключение. Это делает HVCI единственной митигацей, защищающей ci!g_CiOptions на уровне гипервизора.

№2. Microsoft Vulnerable Driver Blocklist

Microsoft поддерживает список заблокированных уязвимых драйверов, который может применяться через WDAC (Windows Defender Application Control) или ASR (Attack Surface Reduction) правила. Важно убедиться, что этот список обновляется регулярно — по умолчанию он обновляется только с крупными обновлениями Windows.

№3. ASR Rules

ASR (Attack Surface Reduction) — это набор правил в Windows Defender, которые блокируют типичные действия атакующих. Одно из правил специально для BYOVD.

Attack Surface Reduction правило «Block abuse of exploited vulnerable signed drivers» (GUID: 56a863a9-875e-4185-98a7-b882c64b5ce5) может блокировать загрузку известных уязвимых драйверов. Рекомендуется включить в режиме аудита, а затем перевести в блокировку после проверки совместимости.

№4. Мониторинг сервисов и драйверов

• Настроить аудит создания сервисов (Event ID 7045, 4697).

• Мониторить загрузку драйверов через Sysmon (Event ID 6) с автоматической проверкой хэшей по LOLDrivers.
• Внедрить EDR heartbeat-мониторинг с алертом на молчание агента.
• Ограничить права на создание сервисов типа kernel driver — минимизировать число учётных записей с привилегией SeLoadDriverPrivilege.

№5. Принцип наименьших привилегий

BYOVD-атака требует привилегий администратора (для загрузки драйвера) или LOCAL_SERVICE (для CVE-2024-21338). Меньше админов на эндпоинтах — меньше шансов у атакующего загрузить драйвер. Audit и контроль использования привилегированных учётных записей (PAM, JIT-доступ) остаются критически важными.

№6 Проактивный аудит: как находить уязвимые драйверы до атакующих

Все детекты и митигации выше работают реактивно — мы ловим атаку, которая уже происходит, или блокируем драйверы, которые уже попали в базы. Но в инфраструктуре любой крупной компании десятки или сотни драйверов от разных вендоров, и далеко не все из них проверены на уязвимости. Промышленные контроллеры, банковское оборудование, принтеры, сканеры, специализированное ПО — всё это ставит свои драйверы, которые работают в Ring 0 и могут содержать IOCTL-обработчики с классическими багами.

В 2023 году исследователи из TeamT5 представили на HITCON инструмент IOCTLance, который решает именно эту задачу: автоматический поиск уязвимостей в WDM-драйверах без необходимости запускать их на реальной системе. За счёт комбинации символьного выполнения и taint-анализа IOCTLance нашёл 117 ранее неизвестных уязвимостей в 26 драйверах, что привело к назначению 41 CVE — среди затронутых вендоров оказались AMD, Dell, IObit, Microsoft (Visual Studio).

Подход работает так. Инструмент берёт бинарник драйвера, находит в нём IOCTL-обработчики и вместо реальных данных подаёт на вход символьные переменные. Затем прослеживает все пути выполнения кода и проверяет, попадают ли контролируемые пользователем данные в опасные функции: MmMapIoSpace (маппинг физической памяти), ZwOpenProcess без OBJ_FORCE_ACCESS_CHECK (открытие хэндла к произвольному процессу), memcpy с контролируемым размером (переполнение буфера), вызов функции по указателю из input buffer (выполнение произвольного кода в ядре) и ещё пять типов уязвимостей. На выходе — конкретный IOCTL-код, адрес уязвимой инструкции и описание, какие именно поля входного буфера контролирует атакующий.

Почему это применимо на практике? База LOLDrivers.io каталогизирует сотни уязвимых драйверов, но покрывает только те, которые уже кто-то исследовал. Драйвер от условного вендора банковских терминалов или системы контроля доступа может содержать точно такие же баги (произвольное чтение/запись памяти через IOCTL), но никто его не проверял, и в LOLDrivers его нет. Атакующий, который получит этот драйвер, сможет использовать его для BYOVD — а детекты по хэшам не сработают, потому что драйвера нет ни в одной базе.

Заключение

BYOVD — это стандартный этап ransomware-операций, доступный через готовые тулкиты и базы уязвимых драйверов, так как публичные инструменты снизили порог входа до минимума.

Для SOC-команд и detection-инженеров это означает необходимость пересмотра подходов к мониторингу:

• Хэш-детектирование загрузки уязвимых драйверов (LOLDrivers.io) — базовый, обязательный детект.
• Мониторинг создания сервисов типа kernel driver из нетипичных источников.
• Heartbeat-мониторинг EDR-агентов с алертом на молчание.
• Корреляция: файл .sys + сервис + завершение EDR = автоматическая изоляция.
• Технические митигации: HVCI, ASR rules, Microsoft Vulnerable Driver Blocklist.

Если ваша стратегия безопасности начинается и заканчивается на EDR, BYOVD-атака может оставить вас полностью слепыми. Сетевой мониторинг, контроль привилегий, HVCI и проверка живости агентов — надёжнее любого отдельного EDR.

Чек-лист: защита от BYOVD

Оставляю чек-лист — распечатайте и держите рядом.

Предотвращение

☐ HVCI (Memory Integrity) включён на рабочих станциях и серверах.

☐ Microsoft Vulnerable Driver Blocklist актуален.

☐ ASR-правило «Block abuse of exploited vulnerable signed drivers» активно.

☐ SeLoadDriverPrivilege ограничена минимальным числом учётных записей.

☐ MFA на VPN и всех внешних точках входа

Обнаружение

☐ Sysmon установлен, EID 6 собирается без агрессивной фильтрации.

☐ <CheckRevocation/> включён в конфигурации Sysmon.

☐ LOLDrivers-хэши импортированы как lookup-таблица в SIEM

☐ Командная строка логируется в EID 4688 (GPO → Include command line) ☐ Правило на sc.exe create type=kernel в SIEM

☐ Правило на массовое завершение EDR-процессов в SIEM

Контроль

☐ Heartbeat-мониторинг EDR-агентов настроен (алерт при молчании > 5 мин).

☐ Корреляция: файл .sys + сервис + завершение EDR = автоизоляция.

☐ Периодическая проверка целостности ETW-сессий (logman query).

Solar appScreener разработан для повышения уровня кибербезопасности программного обеспечения путём комплексного анализа на каждом этапе жизненного цикла разработки. Согласно данным отчёта Solar 4RAYS за 2024 год, около 54% инцидентов связаны с уязвимостями веб-приложений.

Межсайтовый скриптинг, SQL-инъекция, неограниченная загрузка файла опасного типа, внедрение команды ОС, обход авторизации — всё это можно найти и исправить заранее. Solar appScreener объединяет статический анализ SAST, динамическое тестирование DAST и проверку сторонних библиотек OSA.

Главная инновация — AI-модули или Цифровые сотрудники, которые работают даже без доступа в Интернет, обучаемые на протяжении семи лет. Они не просто помогают обрабатывать найденные уязвимости, но и сами генерируют исправленный код. Большинство предложенных исправлений разработчики принимают без доработок.

Параметры проекта

История: продукт начал свою историю 10 лет назад внутри российского стартапа. Сегодня поддерживает 36 языков программирования — ABAP, Apex, ASP.NET, COBOL, С#, C/C++, Objective-C, Dart, Delphi, Go, Groovy, HTML5, Java, Java for Android, JavaScript, JSP, Kotlin, LotusScript, Pascal, Perl, PHP, PL/SQL, T/SQL, Python, Ruby, Rust, Scala, Solidity, Swift, TypeScript, VBA, VB.NET, VBScript, Visual Basic 6.0, Vyper, 1C

Анализ бинарных файлов 10 форматов — JAR, WAR, EAR, AAR, DLL, EXE, APK, AAB, IPA, APP

Обучение ИИ: семь лет на тренировку модулей DerTriage AI и DerCodeFix AI

Задача: найти уязвимости в ПО до того, как их найдут хакеры

Какие проблемы можно решить с помощью анализа кода?

1. Избежать финансовые потери: Большинство инцидентов, связанных с кибератаками связано с недостаточной защитой веб-приложений и программного обеспечения, что ведет к значительным финансовым убыткам у компаний. Даже одна уязвимость – может стать причиной, по которой хакеры проникнут в контур компании, где вы работаете.
2. Потеря доверия клиентов: Атаки хакеров негативно влияют на репутацию бренда и доверие потребителей.
3. Несоблюдение нормативных требований: Компании сталкиваются с необходимостью соответствовать строгим требованиям регуляторов, игнорирование которых влечет серьезные последствия.
4. Повышенная нагрузка на команду: Недостаточная автоматизация процессов выявления уязвимостей увеличивает нагрузку на разработчиков, DevSecOps-инженеров и сотрудников информационной безопасности.

Российский рынок характеризуется особыми рисками, такими как целенаправленные атаки на отечественные информационные системы. Использование open-source-библиотек несет дополнительные опасности. Например, деструктивные действия со стороны отдельных представителей open source сообщества. Отсутствие регулярных проверок повышает вероятность появления закладок или слабых мест, что подчеркивает необходимость внедрения специализированных инструментов вроде Solar appScreener.

Архитектура решения

В архитектуре три главных инструмента:

1. OSA (Open Source Analysis): анализ стороннего кода выявляет известные зависимости, проверяет лицензии open-source-библиотек и выявляет риски использования компонент на основании поведения авторов, обеспечивая безопасность поставок и юридическую чистоту проекта.
2. SAST (Static Application Security Testing): Статический анализ обнаруживает уязвимости в исходном коде с первых этапов разработки. Цифровые сотрудники — компоненты, помогающие обрабатывать результаты сканирования основанные на технологии машинного обучения.
3. DAST (Dynamic Application Security Testing): Динамическое тестирование анализирует веб-приложения и ПО, отправляя заведомо неверные данные и проверяя реакцию приложения на них.

Каждый метод дополняет друг друга, создавая комплексную систему анализа. Дополнительно платформа интегрируется с CI/CD-конвейерами, что позволяет минимизировать ручную работу и повысить скорость развертывания обновленных версий.

Ключевые инновации и технические решения номинированного продукт

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

Почему AppScreener выигрывает:

• Избавление от ложных срабатываний

Проблема ложных срабатываний в инструментах SAST стала камнем преткновения для многих команд. Однако интеллектуальные Цифровые сотрудники решают её окончательно. За счёт семилетнего обучения эти модули мгновенно фильтруют лишние предупреждения, оставляя лишь критически важные уязвимости, нуждающиеся в исправлении. А также предлагают исправленные участки кода для найденной уязвимости. При этом большинство предложенных исправлений принимается без доработок от разработчиков и AppSec-команд.

• Увеличение скорости разработки

Производительность вашей команды растет экспоненциально. Вместо недель ожидания отчётов и кучи задач - теперь отчёт доступен буквально за считанные минуты. Исправления уязвимостей занимают секунды, а не дни. Все это способствует значительному снижению сроков вывода продуктов на рынок (time-to-market) и одновременно сохранению высокого уровня безопасности.

• Интеграция с современной средой разработки

AppScreener идеально встраивается в существующие CI/CD конвейеры и рабочие среды, обеспечивая максимальную совместимость и комфорт для разработчиков. Инструмент легко адаптируется к любым условиям, будь то небольшой стартап или крупная корпорация.

• Уникальная инфраструктура и надежность

Наш продукт разработан в России и прошел самую жесткую сертификацию. Мы предлагаем поддержку широкого спектра популярных языков программирования, в том числе написанных на “устаревших” языках. Это делает AppScreener незаменимым инструментом для компаний любого масштаба.

Основные преимущества AppScreener заключаются в интеграции передовых методов анализа и автоматизации процесса устранения уязвимостей.

Путь от стартапа до стандарта рынка

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

Результаты: скорость и экономия

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

1. Экономия ресурсов: Раннее выявление и быстрое исправление уязвимостей экономит средства, необходимые для ликвидации последствий серьезных инцидентов.
2. Оптимизация бюджета: Сокращение количества ложных срабатываний за счет новых разработок снижает расходы на обработку данных и привлечение квалифицированных специалистов.
3. Увеличение скорости вывода продукта на рынок: благодаря автоматизированному исправлению ошибок, новые версии продуктов выходят быстрее, сохраняя высокое качество.

Эти показатели подтверждают эффективность инструмента и способствуют повышению конкурентоспособности бизнеса.

Отзывы клиентов

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

Планы развития

Команда продолжает развивать Solar appScreener, проводя совместные исследования, интересные рынку. Запущена первая в России премия по безопасной разработке совместно с Ассоциацией ФинТех и сообществом FinDevSecOps. В планах — дальнейшее обучение ИИ-моделей.

Реклама. АО «Солар Секьюрити», ИНН 9714069290, erid: 2W5zFJQwYmo

Но вместе с ростом популярности подхода, возник и главный вопрос: насколько безопасен код, который генерирует ИИ-агент?

Исследование показало: функционально — да, безопасно — нет

Ученые из Carnegie Mellon, Columbia и Johns Hopkins выпустили первое крупное исследование безопасности вайб-кодинга.

Они создали собственный бенчмарк SUSVIBES, состоящий из 200 настоящих задач с GitHub-проектов, где ранее были реальные уязвимости (77 видов CWE).

Каждая задача требует внедрения фичи в живой репозиторий размером в сотни тысяч строк. Это максимально приближено к реальной работе.

Далее они протестировали популярных агентов: SWE-Agent, OpenHands и Claude Code. Все они использовали самые свежие ИИ-модели вроде Claude 4 Sonnet, Gemini 2.5 Pro и Kimi K2.

Результаты оказались тревожными:

• 61% решений от лучшей связки (SWE-Agent + Claude 4 Sonnet) — функционально корректны.
• Но только 10,5% — безопасны.
• Иными словами: около 90% рабочего кода, который агент считает «готовым», содержит уязвимости.

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

Какие уязвимости генерируют ИИ-агенты

Исследователи обнаружили весь спектр проблем:

• утечки данных и неправильная обработка паролей;
• XSS и небезопасные URL-редиректы;
• ошибки верификации сессий;
• тайминг-атаки;
• отсутствие проверки входных данных.

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

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

Вывод

Исследователи подчеркивают: вайб-кодинг полезен для увеличения продуктивности, но категорически непригоден без ручного ревью безопасности.

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

ИИ-агент может написать фичу, пройти тесты и выглядеть уверенно. Но с вероятностью около 80–90% там останется дыра, которая в реальной среде превратится в эксплойт.

За последние годы атаки типа DDoS (Distributed Denial of Service) стали не просто вопросом «когда», а практически неизбежностью для многих компаний. Специалисты отмечают: «для организаций с высокой видимостью уже не вопрос если, а когда вас атакуют».

Главные изменения:

• Доступность инструментария «DDoS-as-a-Service» делает возможными атаки даже с небольшими знаниями.
• Атаки становятся быстрее, изощреннее, и все чаще выполняются автоматически. Например, могут запустить миллионы запросов за несколько минут – и даже прежде чем мониторинг сработает.
• Атакующие все чаще обходят простые фильтры: меняют URL, заголовки, куки, используют бот-сети с огромным географическим разбросом.
• Рост объемов: по данным Cloudflare, крупные атаки выросли экспоненциально за последние десять лет. Например, битрейт (Gbps) вырос с сотен Gbps до 5.6 Tbps к 2025 году.

Эти изменения обуславливают, почему устаревшие методы защиты уже не работают или работают слабо.

Почему традиционные решения уступают

Если раньше меры ограничивались фаерволами, CDN и простыми лимитами, то сегодня этого недостаточно. CDN или фаервол часто настроены по-умолчанию и дают лишь частичную защиту.

Атаки перешли с сетевого уровня на уровень приложений (Layer 7) – где они влияют на веб-сервисы и API, которые генерируют ключевой доход

Ключевые уязвимости:

• Блокировка по IP/ГЕО становится бессильной, когда источники атак меняются динамически.
• Статические правила (лимиты, капчи) не успевают реагировать на автоматизированные, быстрые атаки.
• Отслеживание только трафика без анализа поведения – позволяет атакам «проскальзывать» через кэши и защитные механизмы.

Современные подходы к защите в 2025 году

Как должна выглядеть эффективная защита от DDoS сегодня? Вот основные принципы:

1. Многоуровневая стратегия: защита должна быть на уровне edge (CDN), приложения и поведения. Например, скрытие исходного сервера, лимиты не только на динамические запросы, но и на кэш-контент; специальные правила против «cache-busting».
2. Анализ поведения и автоматизация: атаки идут очень быстро (в 2023 году 50 % атак длились менее 52 секунд). Поэтому вручную реагировать уже нельзя – требуется автоматизированная система, которая распознает паттерны: заголовки, время запросов, структура.
3. Инфраструктурные меры и глобальное распределение. Важно подчеркнуть значение глобальных anycast-сетей, автоматизированной фильтрации и подхода без лимитов на трафик («unmetered DDoS mitigation»).
4. Проактивный партнер и мониторинг: все домены через CDN, лимиты на кэш/некэш-трафик, мониторинг скрытых сигналов (например, странные запросы), наличие плана инцидентов.

Что это значит на практике. Рекомендации:

• Убедитесь, что ваша инфраструктура направляется через надежный CDN и исходные сервера не видны напрямую.
• Настройте лимиты и кэширование не только для типичного контента, но и для потенциально «обратных» точек: поиск, ошибки 404, динамика.
• Выбирайте решения с автоматическим анализом поведения, а не только статическими правилами.
• Проверяйте партнеров: способны ли они эффективно действовать без вашего ручного вмешательства и с минимальным влиянием на законный трафик.
• Рассмотрите услуги по защите от DDoS через специализированных провайдеров – на сайте https://stormwall.pro вы найдете соответствующие предложения, например защита для сайта https://stormwall.pro/products/website-ddos-protection.
• Не забывайте: защита – это не покупка и установка, а постоянная адаптация. Атаки эволюционируют и защита должна меняться вместе с ними.

Заключение

В 2025 году защита от DDoS-атак перестала быть опцией -это необходимость. Атаки стали массовыми, автоматизированными, мощными и адаптивными. Традиционные меры уже часто не справляются. Поэтому требуется переход к многоуровневой, автоматизированной, поведенческой защите с глобальной инфраструктурой и проактивным партнером.

Если вы до сих пор полагаетесь лишь на базовый фаервол или CDN по-умолчанию, сейчас отличный момент пересмотреть подход и усилить защиту своих онлайн-сервисов.

Уязвимость выявили в июне, а устранили в октябре.

Что случилось

По данным Unity и СМИ, обнаруженная проблема позволяет злоумышленнику при определённых условиях выполнить код на машине пользователя и получить доступ к данным. Unity выпустила патчи и инструменты для разработчиков; тем, кто собирает проекты на старых редакторах, рекомендовано пересобрать и переиздать приложения на версиях редактора с исправлением (доступны через Unity Hub/Download Archive). Для тех, кто пока не готов к релизной пересборке, подготовлен пэтчер приложений для Android/Windows/macOS (ограничения: не работает с некоторыми сборками с античитами и tamper-защитой). Уязвимость получила высокий балл серьёзности (CVSS ~8.4) и связана с небезопасной загрузкой файлов/Local File Inclusion.

Что предприняли платформы

Партнёры Unity включили «надстройки безопасности» на своей стороне. Valve выпустила обновление Steam с мерами снижения риска, а Microsoft Defender получил сигнатуры для обнаружения и блокировки попыток эксплуатации. Google и Meta также добавили защитные механизмы. При этом нет признаков, что уязвимость затрагивает iOS, VisionOS, tvOS, Xbox, Nintendo Switch, PlayStation, UWP, Quest и WebGL.

Как реагируют издатели и разработчики

Ряд студий уже выпускают патчи или временно ограничивают доступность проектов, чтобы пройти проверку и обновление. В частности, из цифровых магазинов временно убирались некоторые игры Microsoft/Obsidian (например, Pentiment), а также проекты, получившие оперативные патчи, — Marvel Snap, No Rest for the Wicked, Ingress, Fate/Grand Order; Atlus сообщила об обновлении Persona 5: The Phantom X. В отдельных случаях под ограничения попадали даже нe-Unity-игры, если у них есть Unity-компоненты (цифровые артбуки, лончеры и пр.).

Что делать разработчикам

• Проверить, на каких версиях Unity Editor собраны релизные билды.
• Пересобрать и переиздать приложения на версиях, содержащих исправления (или применить официальный пэтчер, если пересборка сейчас невозможна).
• Сообщить игрокам о необходимости обновить игру/лаунчер и держать системы защиты в актуальном состоянии.

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

Во время аутентификации клиент получает от сервера токен и должен его где-то сохранить, чтобы потом передавать серверу с каждым запросом. Хранится токен в месте, доступном из JS кода, что порождает уязвимость к XSS атакам. Кроме того, клиенту требуется реализовать логику рефреша.

Иногда в проекте может возникнуть потребность в полном контроле над токеном со стороны сервера: он должен иметь возможность не только проверить, но и обновить или отозвать токен. В этом случае можно применять передачу JWT-токенов через HTTP-Only cookie. Об этом — техлид IT_ONE Сергей Белоусов.

Настройка контейнера ServiceCollection

Рассмотрим на примере. Для добавления работы с JWT-токенами через cookie в фреймфорке ASP.NET Core необходимо в Program.cs добавить следующие строки

Код контроллера для запуска и защиты сессии

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

1) HttpOnly = true

Ключевая настройка. Разрешает доступ к cookie только со стороны сервера, JS код не будет иметь к ней доступ.

2) SameSite = SameSiteMode.Strict

Запрещает браузерам отправлять этот cookie при межсайтовых запросах. При необходимости можно снизить до SameSiteMode.Lax, но это повысит уязвимость к XSRF атакам (о них позже).

3) Secure = true

Cookie будет отправляться только при соединении HTTPS.

4) Expires = DateTimeOffset.Now.AddMinutes(options.ExpirationTime)

Время жизни cookie задаём таким же, как время жизни JWT-токена, потому что нет смысла хранить токен дольше.

При логауте или неправильных данных входа мы просто удаляем токен из cookies – по сути, отзываем токен.

Проверка токена через сервис JwtService

Код JwtService:

В JwtService мы создаем набор клеймов, которые хотим передавать с каждым запросом, и зашиваем их в токен. В моём примере я решил сохранить в токен информацию о логине, сессии и ролях пользователя.

А что за antiForgeryToken?

А вот и отрицательная сторона использования cookie: уязвимости к XSRF-атакам. Если кратко, то это вид атак, при которых злоумышленник заставляет браузер жертвы, уже авторизованной на сайте, отправить нежелательный запрос на этот сайт от её имени. Браузер автоматически добавляет авторизационный cookie к запросу, что позволяет выполнить действия от имени жертвы.

Частично защиту от XSRF атак повышает опция SameSite = SameSiteMode.Strict, но это не панацея. Также рекомендуют настраивать CORS-политики, но я оставлю эту тему за пределами этой статьи (главное, не забыть AllowCredentials() на сервере и WithCredentials() на клиенте).

Ещё один способ защиты от XSRF атак – добавить ко всем запросам antiForgeryToken. В ASP.NET Core MVC можно использовать services.AddAntiforgery(), тогда к каждой форме на странице будет добавлено скрытое поле, которое заполняется сервером при рендеринге страницы и отправляется при запросах на сервер. Но мне кажется, что при использовании связки SPA + ASP.NET Core Backend готовый метод защиты не применим, т.к. рендеринг страницы происходит на клиенте.

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

Проверка antiForgeryToken

Для проверки этого токена используется middleware:

Сначала определяется наличие AuthorizeAttribute, чтобы не проверять токен для анонимных эндпоинтов. Затем вызывается CheckToken у самописного IAntiForgeryService. Логику проверки можно реализовать любую. Например, сгенерировать новый токен по известным параметрам и сравнить с полученным от клиента. Если токены не соответствуют — возвращаем код ошибки. Я выбрал 400, т.к. antiForgeryToken — это, по-моему, не про авторизацию, поэтому не хотелось использовать 401 и 403.

Абсолютная власть

Главное преимущество cookie — в том, что возможность управления JWT-токеном на стороне сервера ограничена только вашей фантазией. Для себя я реализовал автоматический рефреш JWT-токена при каждом запросе без необходимости отдельного рефреш эндпоинта. Если для примера JWT-токен истекает через 15 минут, то при каждом запросе от авторизованного пользователя я продлеваю токен ещё на 15 минут.

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

А также можно написать другие middleware, которые в соответствии с бизнес-логикой будут отбирать или выдавать роли или даже отзывать токен «на лету».

Заключение

Использование HTTP-Only cookie для передачи JWT-токенов — это мощный паттерн, который эффективно защищает от XSS-атак и предоставляет серверу беспрецедентный контроль над сессией пользователя. Он позволяет реализовать такие функции, как немедленный отзыв токенов и их прозрачное обновление, что значительно повышает безопасность приложения. Однако этот подход требует тщательной реализации дополнительных мер защиты от XSRF-атак и продуманной политики управления жизненным циклом сессии. При грамотной настройке он становится надёжным фундаментом для системы аутентификации в современных веб-приложениях.

Мой путь в кибербезопасности начался с пентеста и анализа защищённости, а последние два года я погрузился в мир компилируемых языков и разработки ИИ-агентов для защиты систем. На OFFZONE я не был с 2023 года, возвращение сюда оказалось особенно ценным: индустрия как всегда перевернулась несколько раз, приятно оказаться в гуще событий вновь. Атмосфера узнаваемая — всё в лучших традициях конференции.

День первый

21 августа 2025 года. Просыпаться в восемь утра человеку, чьи ночи принадлежат ошибкам компилятора, http-прокси и коротким видео в интернете, — жест аскетизма, достойный античного стоика. Чтобы избежать очередей, я вошёл через журналистский бейдж.

Бейдж OFFZONE — отдельная история. Это программируемое устройство: через коннекторы подключаешь модули — хоть фонарик, хоть динамик. Зарабатываешь офкоины, взламывая стенды или решая квесты, а потом тратишь на мерч. Инструмент для погружения, где мерцающий светодиод напоминает: ты внутри.

У каждого на OFFZONE своя цель: доклады, живое общение со спикерами, встреча коллег с прошлых проектов или адреналин от взлома стендовых систем. Ну и, конечно, соревнование «Hack in 15 minutes», где за ошибки наливают «горячительные напитки», а ведущие едко (но метко) шутят над участниками.

Атмосфера

Оформление OFFZONE в этом году напоминало секретные архивы и закрытые исследовательские центры: печатные машинки, засекреченные досье, строки, закрашенные чёрным маркером. Всюду штампы «Секретно», ощущение тайного НИИ или новой реинкарнации марфинской шаражки, где ведут странные эксперименты. Главный маскот — Куб — выглядел как объект испытаний в лаборатории, к которому подпускают только по спецдопуску. Атмосфера будто ты стал участником секретного проекта, а сама конференция — это рассекреченный на пару дней доступ в закрытый мир.

Стоит рассказать и про OFFSTORE — фирменный магазин мерча. Лично мне, да и многим другим, он нравится именно потому, что тут делают не проходной ширпотреб, а реально качественные вещи с глубоким дизайном, вплетённым в тему года. Каждая коллекция вдохновлена атмосферой OFFZONE и продолжает её стиль, а не сводится к банальному логотипу на китайском рюкзаке. Материалы крепкие, от стирки не умирают, и смотрятся эти вещи не как «мерч для галочки», а как редкая и стильная шмотка, которую приятно носить и вне конференции.

О выборе докладов и CFP

OFFZONE декодируется как OFFENSIVE ZONE — и это чувствуется. Я пообщался с Михаилом Сидоруком, руководителем управления анализа защищенности BI.ZONE, директором по контенту конференции OFFZONE, и он рассказал, как отбирают доклады: оценивают новизну, глубину и наличие PoC. Фильтр жёсткий: отбрасывают маркетинг, «википедийные» доклады и серые обзоры. Шансы повышает уникальность темы, личный опыт или созданный автором рабочий инструмент — будь то утилита, скрипт или методика, которую можно использовать на практике.

Доклады: от гипервизоров до дипфейков

Не обошлось без фаззинга embedded-систем, графовых баз для анализа логических уязвимостей и новых методов SSTI-атак и серверных инъекций кода. А ещё — дипфейки, которые атакуют не только медиа, но и системы авторизации. После каждого выступления я ловил спикеров в кулуарах, чтобы спросить: как интегрировать их наработки в мой SAST/DAST, какие библиотеки выбрать, и где искать вдохновение для новых фич.

Тренды этого года — LLM и их применение, как контейнеризация когда-то. Кажется, все уже внедрили языковые модели в свои процессы, но спикеры показали, как выжать из них максимум: от автоматического поиска багов до генерации эксплойтов. Но на основной сцене были и классические темы наступательной кибербезопасности — и это радует. Глубокий разбор и критичность находок по-прежнему лучший способ эскалации рисков в ИБ.

Первым делом я попал на открытие — выступал Евгений Касперский — основатель и генеральный директор «Лаборатории Касперского». Если коротко, Kaspersky OS предлагают как способ логичного выхода из незавидного положения с безопасностью конечных устройств. Под капотом — изоляция процессов и приложений, что делает нерелевантными 99% типовых атак и даёт безопасную архитектуру для разработки ПО.

Медиа-зона и квест для прессы

После открытия меня проводили в отдельную комнату для прессы — уютное место, где я познакомился с другими представителями СМИ. На столах стояли кофе и закуски, но, как это обычно бывает, руки до них так и не дошли. Вместо этого нас ждал специальный квест: мы разделились на команды и отправились за баллами. Первое испытание — припаять светодиоды к маске анонимуса, превратив её в модуль для бейджа. Справился без проблем, даже сфоткался в специально выделенной зоне. На часы взглянул — пора на доклады. Чуть позже узнал, что наша команда пришла к разгадке первой.

LLM и реверс

Дальше я попал на доклад о LLM-агентах для реверса от Владислава Тушканова, руководителя группы Kaspersky MLTech, «Лаборатории Касперского». Один из наиболее интересных для меня: коллеги описали процесс разработки агентов на LangChain и smolagents. Сравнили результаты SaaS-нейросетей в прохождении crackme-лабораторий. Многие нейронки читерят, подсматривая ответы в интернете, но при помощи жёстко заданных инструкций это можно обойти. Определённо стоящий подход, достойный внедрения. 10 задач AI-агенты смогли решить. А у вас лично какой результат?

Был и доклад Руслана Махмудова, эксперта-исследователя по развитию сервисов анализа защищенности, BI.ZONE про использование графовых баз данных для RAG и поиска логических уязвимостей в веб-приложениях. BOLA и подобные баги часто доходят до продакшена. Масса многоступенчатых запросов с подписью затрудняет анализ, но LLM плюс графовые БД позволяют автоматизировать тестирование или подсветить потенциальный вектор атаки. Я и сам перевёз свой RAG с PostgreSQL на Neo4j сразу после OFFZONE.

Особо запомнился доклад Владислава Корчагина, независимого исследователя про SSTI-уязвимости и инструмент SSTImap. Простые на вид техники оказываются разрушительными. Инструмент автор интегрировал в AppSec и CI/CD для своевременного поиска багов, позволяющих выполнять команды на сервере.

День второй: когда пентестерское нутро побеждает благие намерения

Проснувшись ближе к обеду, я прибыл на конференцию и пошёл на самые жёсткие темы. Сначала — эскалация привилегий через забытую WinAPI-функцию, признанную уязвимостью за пару дней до доклада. Потом — фаззинг гипервизоров: QEMU, VirtualBox, KVM, разбор уязвимостей от автора CVE. Финал — классический дамп LSASS через физическую память в духе Physmem2profit. PoC не ждите, но техника жива и бодра.

Отдельно отмечу доклад Павла Блинникова, руководителя группы исследования уязвимостей, BI.ZONE: разбор фаззеров для гипервизоров и примеры эксплуатации заставили задуматься, сколько проектов можно было бы закрыть заранее. После такого даже VirtualBox выглядит как дверь с табличкой «ломайте здесь» — если знать, куда бить.

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

Доклады для разработчиков

• «LLM для автоматизации ИБ-экспертизы: обнаружение вредоносного кода» — как встроить модели в пайплайн code-review.
• «Как научить AI понимать контекст приложения: новый подход к поиску уязвимостей бизнес-логики в API» — graphRAG и поиск BOLA.
• «Как мы сделали один из лучших SAST на LLM» — генерация PoC и фиксов прямо из кода.
• «Эволюция платформы анализа кода: от ручной загрузки до ML-валидации» — история построения SAST/DAST-платформы.
• «Успешные ошибки: новые техники code injection и SSTI» — свежие паттерны для обнаружения дыр, которые SAST-коробки пропускают.
• «Пентестеры на платформе: теперь они пишут одинаково (и это хорошо)» — стандартизация инструментов для CI/CD и тестирования.
• «Вы не можете спать, пока рядом есть монстры» — Игровые платформы и развившаяся в них теневая экономика.
• «SOC Check-Up. Как мы следим за здоровьем мониторингов» — хорошая практика регулярной самооценки процессов.
• «GitLab + DefectDojo + AI: автоматизация поиска багов в bug bounty» — готовый рецепт для интеграции баг-хантинга в dev-процесс.

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

Доклады для пентестеров

• «State-of-the-Art Hypervisor Vulnerability Research» — атаки на QEMU, VirtualBox.
• «Успешные ошибки: новые техники code injection и SSTI» — свежие паттерны для обнаружения дыр, которые SAST-коробки пропускают.
• «К доске!» — как нарисовать reverse SOCKS proxy и транспорт для вашего C2
• «Уязвимость в Rockchip BootROM» — баги загрузчиков и практическая эксплуатация.
• «Эксплуатация SoC: история Unisoc» — взлом систем-на-чипе, реверс железа.
• «Root-права в базе 1С за одну строку кода» — типичный пример, как конфигурации ломают бизнес-ПО.
• «Silent Harvest: тихое извлечение секретов Windows» — скрытые приёмы доступа к секретам ОС.
• «Greybox-фаззинг embedded через Qiling» — быстрый старт фаззинга прошивок.
• «Протаптываем дорожку к multi-step-уязвимостям» — как склеивать «несерьёзные» баги в цепочку до RCE.
• «Погребено в $LogFile:» эксплуатация 20-летней уязвимости в NTFS

Записи большей части докладов будут доступны на сайте OFFZONE c 11 cентября. Остальную часть докладов можно было послушать только на конференции.

Финал

OFFZONE — это не просто доклады, скорее тренировочный полигон. Здесь тестируешь свои знания, проверяешь стойкость идей и находишь инструменты, которые завтра могут спасти чей-то бизнес. Атмосфера секретного проекта, квесты, встречи с коллегами — всё это сливается в одну цель: выйти отсюда с чемоданчиком, в котором чуть больше киберинструментов, чем раньше.

Сделайте минимальный Docker-образ, не ломая прод

Большинство Docker-образов в проектах содержат больше данных, зависимостей и инструментов, чем требуется для работы приложения. Это приводит к избыточному объёму, медленной сборке и повышенным рискам безопасности. Умение собирать минимальный образ — один из базовых навыков работы с Docker, который напрямую влияет на стабильность и скорость развёртывания.

Начать стоит с multi-stage сборки: на первом этапе — установка зависимостей и сборка, на втором — только нужные артефакты. Это позволяет исключить лишние файлы и утилиты из финального образа. В качестве базового слоя лучше использовать alpine, distroless или даже scratch, если вы точно понимаете, какие бинарники и библиотеки требуются приложению.

Хорошая практика — использовать утилиты docker history и dive для анализа того, какие файлы и слои попали в образ. Если размер превышает ожидания, стоит проверить, не остались ли во внутреннем слое временные файлы, dev-зависимости или директории кэша.

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

Результат — меньше уязвимостей, быстрая сборка и уверенность в том, что образ содержит только то, что действительно нужно для запуска в проде.

Попробуйте контейнизировать то, что изначально не предназначалось для этого

Работа с Docker чаще всего начинается с бэкенд-приложений, сервисов и утилит, которые изначально проектировались как самостоятельные процессы. Они хорошо вписываются в модель контейнеров: запускаются из CLI, работают в изоляции, не требуют доступа к UI или железу. Но стоит выйти за эти рамки — начинаются сложности.

Попробуйте упаковать в контейнер любую графическую программу. Технически это возможно: X11 или Wayland можно пробросить через сокет, устройства передать через volume, окружение прописать вручную. Но на практике вы столкнётесь с рядом ограничений: отсутствие звука, глюки интерфейса, ошибки в драйверах, проблемы с доступом к GPU или нестабильное поведение при рендеринге.

В этом упражнении ценен не сам результат, а путь. Вы увидите, как устроена изоляция в Docker, почему графические приложения не работают «из коробки» и где находятся реальные границы контейнеризации. Контейнер — это не виртуальная машина, у него нет полноценного init, драйверов или прямого доступа к оборудованию. Многие фичи, которые работают локально, в контейнере требуют дополнительных танцев с бубном.

Такая практика особенно полезна, если вы имеете дело с devtool'ами, UI-обвязкой или тестированием в headless-средах. Понимание, что именно ломается и почему, позволяет более точно проектировать окружение и избегать архитектурных ловушек в будущем.

Соберите базовый образ с нуля

Когда разработчик пишет FROM node или FROM ubuntu, он автоматически получает десятки слоёв, библиотек и утилит, о которых, скорее всего, не задумывается. Это удобно, но не даёт понимания, как вообще работает контейнер на низком уровне. Попробуем разобраться.

Укажите в Dockerfile FROM scratch — и не увидите ни bash, ни glibc, ни стандартных каталогов. Вам придётся самостоятельно добавить всё необходимое: бинарник, зависимости, библиотеки, конфигурацию. Если пишете на Go, задача упрощается: можно собрать статически слинкованный исполняемый файл и скопировать его в образ. Для других языков, особенно тех, что зависят от динамических библиотек или рантайма (например, Python или Node.js), придётся вручную подтягивать зависимости.

Такая практика заставляет иначе взглянуть на структуру контейнера. Вы начнёте понимать, чем отличается CMD от ENTRYPOINT, зачем в некоторых образах используется sh -c, и что произойдёт, если не задать WORKDIR. Вы столкнётесь с ошибками «no such file or directory» даже тогда, когда файл вроде бы существует — потому что в контейнере не хватает нужной libc.

Отдельный повод для размышлений — Alpine. Его любят за размер и минимализм, но он использует musl вместо glibc, и не всё с ним работает корректно. В процессе сборки на практике увидите, почему иногда проще остаться на Debian Slim, чем пытаться адаптировать всё под Alpine.

Этот эксперимент не нужен для продакшена — он нужен вам, как разработчику. Прокачивает понимание, как устроен Docker, что по-настоящему важно приложению для запуска, и какие зависимости вы добавляете бессознательно.

Делайте разные варианты Docker-образов

Хороший Dockerfile — тот, который гибко адаптируется под разные сценарии: продакшен, отладку, тестирование, запуск на ARM или x86. Если вы умеете собирать только один универсальный образ — вы ещё не освоили Docker по-настоящему.

Попробуйте собрать сразу несколько версий своего образа: на Debian и на Alpine, с минимальным размером и с полным набором утилит, для amd64 и arm64. Добавьте build-аргументы (ARG) — они позволяют передавать параметры на этапе сборки: выбрать базовый образ, включить или выключить зависимости, задать переменные окружения. Используйте RUN if или шаблонизацию через Dockerfile.template, чтобы варьировать поведение без дублирования кода.

Вот типичный пример: в режиме отладки вам нужен образ с установленным curl, vim, доступом к логам и расширенной трассировкой. А в продакшене — максимально облегчённый, с удалёнными временными файлами, сжатым слоем и только необходимыми бинарниками. Один и тот же проект — два разных образа. Добавьте сюда ещё поддержку разных архитектур (multi-arch build через --platform), и вы выйдете на уровень CI/CD, где из одного пайплайна собирается три-четыре артефакта.

Такая практика решает сразу несколько задач. Во-первых, помогает лучше понять, как влияет каждый шаг сборки на финальный размер и поведение контейнера. Во-вторых, избавляет от лишних костылей, когда на проде всё работает, а на локалке — нет. И главное — прокачивает навык автоматизации. Один Dockerfile, разные образы, ноль копипасты.

Поиграйте в «А что если запустить чужой (небезопасный) код?»

Представьте задачу: вам нужно запустить код, который написал кто-то другой. Вы не уверены, что он безопасен. Это может быть скомпилированный бинарник, питоновский скрипт или даже npm-зависимость с подозрительным хуком. Где-то в коде может быть rm -rf /, попытка выйти за пределы контейнера, установить рутовый доступ или просто майнить крипту. И теперь этот код запускается на вашей машине — внутри Docker.

Кажется, контейнер защитит? Не всегда.

Docker не является полноценной песочницей. По умолчанию контейнер может обращаться к файловой системе, к ядру и к хостовым ресурсам — особенно если вы запускаете его с --privileged или без ограничения пользователя. Даже docker run -it ubuntu работает от root внутри контейнера, что уже создаёт риски.

Если вы действительно хотите запустить небезопасный код, нужно жёстко ограничить контейнер:

• отключить права root (через --user);

• запретить модификацию файловой системы (--read-only);

• отобрать лишние возможности ядра (--cap-drop=ALL);

• включить seccomp-профиль, AppArmor или SELinux;

• отключить доступ к сети или монтированию сокетов.

Список можно продолжать. Главное — понять, что Docker по умолчанию не даёт изоляции на уровне VM. Если вы работаете с кодом, которому не доверяете, этого может быть недостаточно.

Это упражнение учит думать о безопасности как о процессе. И особенно важно пройти его, если вы когда-нибудь планируете запускать user-generated code: плагины, кастомные скрипты, пайплайны CI. Только на практике становится ясно, где заканчиваются возможности Docker и начинаются границы настоящей песочницы.

Работайте без Docker CLI

Если убрать Docker CLI — что останется? Больше, чем кажется.

Docker ― это не единый монолит. Он работает поверх набора инструментов и стандартов: buildkit, containerd, спецификация OCI. CLI просто прячет эту архитектуру за удобными командами: docker build, docker run, docker push. Но всё, что кажется магией, можно повторить вручную.

Попробуйте отказаться от docker как от инструмента. Сконфигурируйте buildctl напрямую и соберите образ без Dockerfile. Или вообще создайте его вручную: сформируйте структуру, описания слоёв, метаданные, манифест. Прочитайте спецификацию OCI Image Format и идите по ее шагам. Понадобится tar, sha256sum, немного JSON — и внимательность.

Образ собрали? Отлично. Теперь отправьте его в реестр без docker push. Используйте oras, skopeo или curl с аутентификацией и ручной отправкой слоёв по HTTP API. Узнаете много нового: как работает digest, что такое manifest list и зачем нужны media types.

Наконец, запустите контейнер без docker run. Через ctr, runc или даже напрямую с помощью systemd-nspawn.

Зачем это нужно? Чтобы воспринимать Docker глубже. Так, вы понимаете, как устроен pipeline сборки и запуск контейнера, и точнее управляете им. Особенно это важно в продакшн-среде: когда образы не собираются, push падает, реестр отвечает 403, а пайплайн горит.

Ты точно программист, если читаешь это! Больше мемов, инсайтов и боли кодеров тут.

База и теория

1. Event loop для чайников: простыми словами о сложном механизме браузера — В статье разбираем, что такое Event Loop, очередь задач и стек вызовов. Простыми словами о том, как браузер выполняет JavaScript-код и обрабатывает события.
2. Чек-лист по Node.js для новичков: обработка ошибок — Показываем основные подходы к обработке ошибок для Node.js. Рассматриваем пошаговую инструкцию и практические примеры.
3. Что нужно учить JavaSript-разработчикам в 2024 году — Разбираем, какие технологии и навыки нужно знать JS-разработчику, в том числе и в 2025. От фреймворков до подходов к архитектуре.
4. Декларативные языки на примерах с JavaScript — Рассказываем, что значит декларативный стиль программирования. Сравниваем с императивным на примерах JavaScript.
5. JavaScript localStorage: Полное руководство — Разбираем, как работает localStorage. Учим сохранять данные на клиенте с помощью JavaScript.
6. Как работает режим strict в JavaScript — Объясняем, что делает режим strict и почему он помогает писать более безопасный код на JavaScript.
7. Как бесплатно выучить JavaScript и не идти в онлайн-школы — Рассказываем, как самостоятельно освоить JavaScript. Бесплатные ресурсы, полезные советы и личный план обучения.
8. Какие JS-библиотеки использовать для анимаций на сайте в 2024 году — Актуальные JavaScript-библиотеки для веб-анимации. Рассматриваем лучшие инструменты для красивых и быстрых интерфейсов.

Практикуемся

1. 10 реальных вопросов с собеседования JavaScript-разработчика с ответами — Подборка реальных вопросов с собеседований для JavaScript-разработчиков. Даем ответы и объясняем, как правильно мыслить на интервью.
2. Приложение прогноза погоды с использованием Vue JS — Пошаговое руководство по созданию погодного приложения на Vue.js. Обучаем взаимодействию с API и построению интерфейса.
3. Математика в программировании: реализуем уравнения на JavaScript — Объясняем, как реализовать математические уравнения на JavaScript. Практика для программистов, которые не боятся формул.
4. Регулярные выражения в JavaScript: разбираемся в создании — Учим создавать и использовать RegExp в JavaScript. Поясняем синтаксис, паттерны и типовые ошибки.
5. Решаем популярные задачи с асинхронным кодом на JavaScript: часть первая — Практика асинхронного программирования на JavaScript. Решаем задачи с API, задержками и промисами.
6. Асинхронный JavaScript: изучаем Async/Await, Callbacks и Promises — Учим писать асинхронный код в JavaScript: от колбэков до современного async/await. Понятно, на примерах и без лишнего.
7. Задачи по асинхронному программированию на JS — Упражнения на асинхронный JavaScript. От простых примеров до сложных сценариев.

Предыдущие подборки лежат здесь: React, мобильная разработка, С++, инструменты.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Такой механизм реализован и на сайте Tproger: читатели не могут создавать, комментировать и лайкать посты, пока не пройдут аутентификацию.

Базовая аутентификация в Django

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

Установим фреймворк командой pip:

Создадим новый проект:

Создадим новое приложение для работы с аутентификацией:

Django уже содержит встроенную систему аутентификации. Она находится в приложении django.contrib.auth, которое по умолчанию включено в INSTALLED_APPS в файле settings.py.

Добавим приложение в список INSTALLED_APPS:

Добавление и настройка страниц для входа, регистрации и выхода

Используем встроенные формы Django, чтобы настроить аутентификацию. Сначала создадим поля для входа и регистрации в файле forms.py приложения myapp:

Код выше создает две формы: LoginForm для входа и RegisterForm для регистрации нового пользователя.

Форма LoginForm содержит два поля: username и password. Поле password отображается как поле ввода пароля с помощью виджета PasswordInput.

Форма RegisterForm наследуется от встроенной формы UserCreationForm и добавляет дополнительное поле email. В классе Meta указываем модель User и поля, которые нужно включить в форму.

Создадим представления для обработки запросов входа, регистрации и выхода. В файле views.py приложения myapp добавим код:

Код выше создает три функции представления: login_view, register_view и logout_view.

Функция login_view обрабатывает запрос входа пользователя. Для POST-запроса создается экземпляр формы LoginForm с переданными данными. Если форма валидна, извлекаются имя, пароль и выполняется аутентификация пользователя с помощью функции authenticate(). Если пользователь успешно аутентифицирован, выполняется вход login(), и пользователь перенаправляется на главную. Для GET-запроса, создается пустая форма LoginForm, которая передается в шаблон login.html.

Функция register_view обрабатывает запрос регистрации.

• Если это POST-запрос, создается экземпляр формы RegisterForm с переданными данными.
• Если форма валидна, новый пользователь сохраняется в базе данных с помощью метода save(), и перенаправляется на страницу входа.
• Если это GET-запрос, создается пустая форма RegisterForm, которая передается в шаблон register.html.

Функция logout_view обрабатывает запрос завершения сессии. Она вызывает функцию logout() для выхода пользователя, и перенаправляет его на страницу входа.

Создадим шаблоны login.html, register.html и добавим ссылку на выход в шаблоне base.html:

В шаблоне base.html добавляем условие {% if user.is_authenticated %} — оно проверит, авторизован ли пользователь. Если авторизован, отобразится приветствие и ссылка на выход. Если не авторизован, то появятся ссылки на страницы входа и регистрации.

Обновим файл urls.py приложения myapp, чтобы добавить маршруты для новых представлений:

Запустим сервер, чтобы протестировать вход и регистрацию:

Страницы размещаются по адресу http://localhost:8000/login/ и http://localhost:8000/register/ соответственно.

В Django также есть встроенные классы представлений для аутентификации, такие как LoginView и LogoutView. Чтобы использовать их, обновим файл urls.py приложения myapp:

Заменили функцию представления login_view на класс представления LoginView и указали шаблон login.html. Аналогично, заменили функцию представления logout_view на класс представления LogoutView и указали страницу, на которую будет перенаправлен пользователь после выхода (next_page='login').

Управление доступом с помощью авторизации

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

Для использования декоратора @login_required обновим файл settings.py и укажем URL-адрес для перенаправления неавторизованных пользователей:

Теперь в файле views.py приложения myapp добавим следующий код:

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

Создадим шаблон home.html в директории templates приложения myapp:

Добавим путь для главной страницы в файле urls.py приложения myapp:

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

В Django есть система разрешений (permissions) для расширенного управления доступом. С их помощью можно определять, какие действия могут выполнять пользователи или группы пользователей.

Создадим группу и назначим ей разрешения. В файле admin.py приложения myapp добавим следующий код:

Создадим функцию представления, которая будет доступна только пользователям с определенным разрешением. В файле views.py приложения myapp добавим код:

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

Создадим шаблон special_page.html в директории templates приложения myapp:

Добавим маршрут для специальной страницы в файле urls.py приложения myapp:

Теперь только пользователи или группы с разрешением myapp.view_special_page смогут получить доступ к специальной странице.

Расширение модели пользователя

Можно создать собственную модель пользователя, наследуя от AbstractUser или AbstractBaseUser.

Давайте ассмотрим создание кастомной модели пользователя с помощью AbstractUser. В файле models.py приложения myapp добавим код:

Создаем класс CustomUser, который наследуется от AbstractUser. Добавляем дополнительные поля phone_number и address к модели пользователя.

Обновим файл settings.py и укажем кастомную модель:

С этого момента система аутентификации будет использовать кастомную модель пользователя вместо встроенной модели User.

Создадим миграции и применим их для обновления базы данных:

Для работы с кастомной моделью нужно обновить формы. В файле forms.py приложения myapp изменим поля регистрации:

Создаем класс CustomUserCreationForm, который наследуется от UserCreationForm. Добавляем поля phone_number и address к форме и указываем кастомную модель CustomUser в классе Meta.

Чтобы система аутентификации приняла изменения, обновим функцию представления register_view в файле views.py:

Меняем форму UserCreationForm на кастомную форму CustomUserCreationForm. Теперь Django работает, используя собственную модель пользователя с дополнительными полями во всем проекте.

Социальная аутентификация

Для реализации входа через сторонние сервисы есть библиотека django-allauth. Она предоставляет готовые решения для интеграции с провайдерами социальной аутентификации.

Установим библиотеку django-allauth:

Добавим django-allauth в список установленных приложений в файле settings.py:

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

Также устанавливаем значение SITE_ID = 1, чтобы указать идентификатор сайта.

Добавим URL-адреса для django-allauth в файле urls.py проекта:

Включаем URL-адреса django-allauth с префиксом accounts/.

Выполним миграции для создания таблиц в базе данных:

После этого можно настраивать провайдеров социальной аутентификации через административный интерфейс Django.

Добавим кнопки для социальной аутентификации на страницу входа. В шаблоне login.html добавим следующий код:

Добавляем ссылки на страницы регистрации через социальные аккаунты, используя URL-адреса socialaccount_signup с указанием провайдера. Теперь пользователи могут войти на сайт, используя свою учетную запись Google.

Безопасность аутентификации

Рекомендации по повышению безопасности аутентификации:

• Настройте SSL/TLS-сертификат для сайта для безопасного соединения между клиентом и сервером. Используйте протокол HTTPS для всех страниц, где есть аутентификации и передача конфиденциальных данных.
• Система на Django работает со встроенной защитой от межсайтовой подделки запросов (CSRF). Убедитесь, что в шаблонах форм используется тег {% csrf_token %}.
• Экранируйте пользовательский ввод перед его выводом на страницах сайта, чтобы защититься от межсайтового скриптинга (XSS). Django автоматически экранирует переменные в шаблонах, но будьте осторожны при явном выводе HTML.
• Для защиты от атак методом перебора (брутфорса) ограничьте количество неудачных попыток входа для каждого пользователя или IP-адреса. Используйте библиотеки django-axes или django-ratelimit, чтобы реализовать ограничения числа попыток входа.
• Никогда не храните пароли в открытом виде — вместо этого используйте хеш-функции. В Django есть встроенные функции для хеширования паролей: django.contrib.auth.hashers.make_password() и django.contrib.auth.hashers.check_password().
• Возможно, стоит реализовать двухфакторную аутентификацию, чтобы повысить безопасность учетных записей. Используйте библиотеки django-two-factor-auth или django-otp для добавления 2FA.

Что такое OAuth 2.0 и OIDC

OAuth2 — это широко распространенный протокол авторизации, который позволяет различным системам взаимодействовать и обмениваться данными с разрешения пользователя. Полное описание протокола зафиксировано в виде RFC-6749.

OIDC — это, можно сказать, надстройка над OAuth2, добавляющая к протоколу механизмы идентификации пользователя, что позволяет проводить не только авторизацию, но и идентификацию конкретного пользователя в системе. Например, OIDC широко распространен в системах SSO (SIngle Sign On).

Токены и их безопасность

Токены — центральный элемент протоколов OAuth 2.0 и OIDC, которые позволяют безопасно авторизовать пользователей и передавать данные между системами. Однако их неправильная настройка или использование могут создать серьезные риски безопасности. Ниже — о типах токенов.

Access-токены (токены доступа)

• Назначение: предоставляют доступ к функционалу системы.
• Срок жизни: в большинстве случаев 1 час или меньше. Обычно этого хватает, чтобы защититься от перебора токенов.
• Область действия: определена через scope — набор разрешений, доступных с этим токеном.

Refresh-токены

• Назначение: используются для получения нового access-токена, когда срок действия последнего истекает.
• Срок жизни: либо не ограничивается, либо выставляется достаточно большим, чтобы пользователю не нужно было регулярно подтверждать выдачу новой пары access и refresh-токенов. В любом случае у пользователя должна быть возможность отозвать этот доступ в ручном режиме.

Работает примерно так:

• access-токен выдан на 1 час, после этого доступ к системе будет отозван
• по истечении часа клиент обращается к системе с refresh-токеном, чтобы получить новый access-токен и продолжить работу

Одно из основных преимуществ OIDC перед OAuth2 — поддержа передачи минимального набора информации о владельце аккаунта (обычно это email, username, имя и фамилия), что позволяет построить систему аутентификации поверх данного протокола. Для передачи подобных данных существует 2 механизма:

• Метод GET /userinfo, находящийся в авторизованной зоне (это значит, что получить данные об аккаунте может только тот, кому пользователь сам предоставил доступ к ним);
• ID-токен, передаваемый при аутентификации вместе с access и refresh-токенами. Этот механизм является предпочтительным, так как позволяет не выполнять лишнее обращение к серверу. Живет не больше 5 минут.

Согласно спецификации OIDC, ID-токен — это JWT, обычно подписанный с использованием ассиметричного шифрования, чтобы предотвратить подмену данных аккаунта.

Никогда не используйте ID-токены как access- или refresh-токены. Это небезопасно, так как они содержат данные о пользователе.

Спецификация и полное описание JWT токенов описана в RFC-7519. Основная идея заключается в создании некоторого механизма безопасной и не слишком затратной с точки зрения сетевых ресурсов передачи данных между несколькими системами.

JWT представляет собой JSON, опционально подписанный с помощью асимметричного шифрования посредством JWK. Это позволяет проверить подлинность данных, содержащихся в JWT. Кроме того, спецификация предусматривает указание времени жизни такого токена, а также дополнительной информации.

Вот пример структуры JWT:

Как безопасно хранить и передавать токены

Правило № 1: клиенты никогда не будут безопасными. Без шуток — доверять можно только своему серверу (и то не всегда).

Вот основные пункты, которым нужно следовать:

1. Для взаимодействия используйте только HTTPS, иначе никакие хитрости вам не помогут.
   
2. По возможности ограничивайте время жизни токенов — это снизит риск компрометации.
   
3. Храните токены: 1) в защищенных хранилищах: KeyStore (Android), Secure Enclave (iOS) или HttpOnly Cookies (браузеры), 2) с дополнительным шифрованием (например, AES) — это повысит защиту.
4. Избегайте XSS-атак: внедрение вредоносных скриптов остается одной из главных угроз токенам.

Не передавайте токены там, где они не нужны: это минимизирует риск утечки данных.

Как настроить аутентификацию и авторизацию

CSRF-атаки и защита через state

Еще в RFC-6749 был предложен механизм защиты от CSRF-атак — использование параметра state (в OIDC его аналог — nonce). Это случайная строка, уникальная для каждого запроса:

• Клиент генерирует state и передает его серверу.
• Сервер возвращает его в ответе. Клиент проверяет, совпадает ли значение.

Этот подход защищает от подмены запросов, связывая только два шага:

1. Запрос на авторизацию.
2. Редирект в API клиента с авторизационным кодом.

PKCE: защита этапа обмена токенов

Чтобы связать оставшиеся шаги (обмен кода авторизации на токены) и усилить безопасность, был введен PKCE (RFC-7636). Этот механизм работает так:

1. Клиент генерирует случайную последовательность байт (code_verifier) и вычисляет её хэш (code_challenge).
2. При запросе авторизации клиент передает code_challenge серверу, который его запоминает.
3. При обмене авторизационного кода на токены клиент отправляет исходный code_verifier, а сервер проверяет его соответствие ранее переданному code_challenge.

Важно! Использование PKCE и state — обязательное требование для современного веба.

Какой способ авторизации без сервера наиболее безопасный

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

В случае SPA и аналогичных решений, в протоколе пришлось сделать послабление. Так как хранение client-secret на клиентской машине не имеет смысла, провайдер может только идентифицировать клиентское приложение только по client-id, что снижает безопасность. Единственное, что позволяет предотвратить несанкционированный доступ — redirec_url, который задает список доверенных URL для редиректов в процессе авторизации.

Иногда вместо классического Authorization Code flow (выдача кода и обмен последнего на токены) используют упрощенный Implicit Flow, но из-за некоторых допущений он значительно снижает безопасность, поэтому многие популярные решения (например, Keycloak) и провайдеры его не поддерживают, так что остается только классический Authorization Code Flow.

Если говорить о реализации OAuth2 в SPA, точно стоит озадачиться безопасностью вашего домена — не забывать про state, PKCE, поскольку по сути это единственное, что отделяет вас от хаоса.

Кроме того, клиентское приложение в процессе авторизации должно будет выполнить POST-запрос к авторизационному сервер, то есть нужно иметь правильно настроенные CORS-политики, а это само по себе не просто.

Как защитить серверную сторону

Вот чек-лист, когда речь идет об авторизации с помощью бекэнда:

• Не забывайте про state (nonce для OIDC).
• PKCE давно перестал быть расширением и по факту используется всегда — не пренебрегайте им.
• При проверке авторизации обязательно проверяйте не только корректность токена, но и его принадлежность к аккаунту. Если есть JWT — проверьте подпись, если нет — проверьте доступ к данным на стороне провайдера.
• Обязательно валидируйте полученные JWT-токены, если есть JWKS — используйте его, если нет, то подумайте, стоит ли того потенциальный риск компрометации доступа.
• Не используйте выданные внешним OAuth2-провайдером токены в качестве собственного механизма авторизации — для этого лучше подойдут классические Cookie или короткоживущие JWT-токены.
• Продумайте: как ваша система должна реагировать на отзыв токена со стороны провайдера? Что делать в случае компрометации токена? Как это будет работать, если у вас stateless на JWT?
• Ограничьте доступ инженеров к используемым секретам и сертификатам. Для этого есть готовые системы, например, Vault и прочие.
• При работе через web максимально ужесточите политики передачи секретов — SameSite, HttpOnly и CORS ваши лучшие помощники.

Если вы используете JWT, то обязательно:

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

Пример проверки JWT на сервере:

Если вам нужно управлять доступом и контролем сессий для пользователей, авторизованных через OAuth 2.0, не используйте JWT.

Несмотря на кажущуюся простоту и выигрыш за счет отсутствия подконтрольного вам хранилища, механизм JWT крайне уязвим и практически не имеет стандартных механизмов защиты: ни отозвать токен, ни прервать его доступ к какой-то из подсистем невозможно.

Единственное, что предоставляет такие механизмы — персистентное хранилище на стороне вашего сервера, позволяющее так или иначе отслеживать доступы к конкретному аккаунту. Да, можно доработать JWT, чтобы они поддерживали необходимые механизмы, за счет использования таких хранилищ, но тогда вы переизобретаете классические сессии на основании Cookies.

О логировании и мониторинге

Логирование событий и мониторинг активности — основа для обеспечения безопасности работы с протоколами OAuth 2.0 и OIDC. Важно не только фиксировать ключевые действия, но и уметь анализировать их, чтобы вовремя предотвращать угрозы. Чтобы все проходило гладко, нужно фиксировать эти события:

• Факт выдачи токенов (пара access и refresh).
• Факт обновления токена через refresh-token.
• Факт отзыва токенов (и инициатора этого действия).
• Неуспешные запросы на обновление токенов — эти события могут сигнализировать о злоумышленной активности.

Важно! Каждый токен должен быть связан с конкретным клиентом и пользователем для простоты последующего анализа.

Как обнаруживать и предотвращать аномальную активность

Хотя протоколы OAuth 2.0 и OIDC предоставляют базовые механизмы защиты, обнаружение аномалий выходит за рамки этих стандартов. Здесь в дело вступают дополнительные подходы.

Ключевые механизмы безопасности в OAuth 2.0 и OIDC:

client_id и client_secret:

• Идентифицируют и аутентифицируют клиентское приложение.
• client_id : безопасно передавать в открытом виде.
• client_secret : необходимо хранить в тайне, так как его утечка делает приложение скомпрометированным.

redirect_url и scopes:

• redirect_url: предотвращает перенаправление пользователей на злоумышленные сайты.
• scopes: гарантируют, что приложение не запросит больше прав, чем разрешил пользователь.

Что отслеживать для выявления угроз

• Попытки использования неверных или устаревших токенов.
• Частые запросы на обновление токенов от одного клиента (могут сигнализировать о злоумышленной активности).
• Многочисленные запросы к ресурсам с разных IP-адресов в короткий промежуток времени.

OAuth2 используется для интеграции множества клиентов с одним провайдером. Различение клиентов — это основа защиты данных.

Распространенные ошибки и советы

Большинство ошибок связаны с нарушением стандартов безопасности. Вот основные из них:

• Устаревшие или неверные настройки redirect_url.
  
• Хранение client_secret на стороне клиента.

Чтобы этого не происходило, вот несколько советов:

• Используйте готовые фреймворки и библиотеки для реализации протоколов OAuth 2.0 и OIDC.
• Регулярно пересматривайте и обновляйте client_secret.
• Отслеживайте и своевременно отзывайте токены.

А что со сторонними поставщиками

Популярные сервисы, такие как Auth0 и Google Identity, выполняют несколько задач:

1. Обеспечивают отказоустойчивое и безопасное хранилище токенов.
2. Реализуют весь процесс авторизации и аутентификации.
3. Предоставляют готовые интеграции с популярными OAuth 2.0-провайдерами (например, GitHub).

Использование сторонних решений снижает риск ошибок и упрощает разработку.

Особенности интеграции с популярными API

В зависимости от степени древности конкретного API, могут появляться неожиданные костыли, которые не описаны в стандарте.

Согласно RFC-6749, провайдер может отдать вместе с access и refresh-токеном список предоставленных scope’ов.

Важный момент: не все из того, что вы запрашивали, будет и правда выдано. Клиент может просто не согласиться дать вам доступ, например, к списку контактов, увы.

Примеры:

1. Google: Поддерживает устаревший метод https://www.googleapis.com/oauth2/v1/tokeninfo, который, хотя и удобен, не описан в стандарте.
2. Яндекс: Предоставляет вечные access-токены, которые никогда не истекают. Возможно, коллеги в свое время не решились поддерживать большой фон запросов на перевыпуск токена, и в итоге вопрос безопасности пользователей ложится на потребителей OAuth2 API Yandex в большей мере, чем хотелось бы.

Стандарт OAuth 2.0 допускает расширения (например, добавление новых grant_type), что позволяет адаптировать его к потребностям конкретных приложений.

OAuth 2.0 и OIDC — это основа современной аутентификации и авторизации. Чтобы использовать их эффективно, важно следовать рекомендациям: защищать токены, логировать ключевые события и внедрять проверенные механизмы безопасности. А тщательная настройка и внимание к деталям помогут избежать уязвимостей и защитить пользователей.

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

Исследования показывают, что такие инструменты, как ChatGPT, GitHub Copilot и Amazon CodeWhisperer, генерируют корректный код лишь в 65.2%, 46.3% и 31.1% случаев соответственно.

Основная проблема кроется в неспособности ИИ адекватно работать с математической логикой и общих сложностях с пониманием алгоритмов.

Недостаточная проверка как возможная причина

По данным исследования Snyk, более половины компаний в конце 2023 года сталкивались с проблемами безопасности в коде, сгенерированном ИИ.

Ожидается, что к 2028 году около 90% корпоративных инженеров будут использовать ИИ для написания кода, что может усилить эту проблему.

По словам CEO Sonar Тарика Шауката, компании часто внедряют ИИ-инструменты для генерации кода без достаточной проверки и строгих практик рецензирования. Разработчики менее тщательно проверяют код, написанный искусственным интеллектом, так как не чувствуют за него полной ответственности.

Эффект «laisser-faire»

Исследование Стэнфордского университета в 2023 году показало, что программисты, использующие ИИ-инструменты, пишут менее безопасный код, но не считают его таковым.

Это создает иллюзию того, что все под контролем, и подталкивает разработчиков к более расслабленному подходу к проверке и тестированию кода.

Проблема «code churn» и «копипаста»

С ростом использования ИИ для написания кода наблюдается и увеличение количества правок. Исследователи GitClear обнаружили, что количество так называемого «code churn» — изменений кода, которые приходилось исправлять или отменять менее чем через две недели после написания — стремительно растет.

Прогнозируется, что в 2024 году число таких изменений удвоится по сравнению с 2021 годом. Кроме того, увеличилось количество скопированных и вставленных фрагментов кода, что нарушает принцип «DRY» («Don’t Repeat Yourself») и ведет к сложностям в поддержке проекта.

Стоит, правда, отметить, что несмотря на выявленные проблемы, компании не отказываются от использования ИИ-инструментов, так как они значительно ускоряют процесс разработки.

Тарик Шаукат отмечает, что около 30% предложений ИИ-программ принимаются разработчиками, что является существенным показателем.

Toshiba совершила настоящий прорыв в этой области, представив квантовый генератор случайных чисел (QRNG), готовый для массового использования вне лабораторий.

Случайные числа: основа цифровой безопасности

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

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

Технологический прорыв Toshiba

Исследователи Toshiba разработали QRNG на основе фотонной интегральной схемы (ФИС), что позволило значительно уменьшить размер и стоимость устройства.

В отличие от громоздких лазеров и детекторов, используемых в предыдущих версиях, новая технология компактна, но все еще эффективна.

Как это работает

В основе QRNG от Toshiba лежат два лазера, которые генерируют оптические импульсы со случайными фазами из-за квантовых шумов.

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

Полученные данные обрабатываются и превращаются в случайные биты, которые могут передаваться со скоростью до 2 Гбит/с.

Преимущества и тестирование

Разработка Toshiba не только компактна, но и экономична в производстве, что делает ее доступной для массового использования.

Первоначальные тесты показали, что QRNG работает стабильно и надежно, даже при значительных изменениях температуры. Исследователи компании интегрировали свой генератор в систему квантового распределения ключей (QKD) и успешно испытали его в реальных условиях в течение 38 дней.

Проектирование

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

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

Одно дело разместить некий API для мобильного приложения в интернете, а другое – проверить его динамическим анализом (DAST) или фаззингом (FUZZ testing) и разместить за API-гейтвеем, который реализует необходимые контроли и минимизирует поверхность атаки.

Архитекторы ИБ также могут учитывать разнообразие вариантов применения «коробочных» продуктов и вводить дополнительные контроли или меры защиты.

Разработка

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

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

Сборка

Во-первых, при сборке ПО можно использовать только код, проверенный инженерами AppSec (Application Security).

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

В-третьих, уже полученный исполняемый код должен подвергаться DAST- и фаззинг-анализу для того, чтобы выявить более широкий класс уязвимостей.

Управление уязвимостями

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

— SAST (статический анализ кода),
— SCA (компонентный анализ ПО),
— DAST (динамический анализ ПО),
— FUZZ testing (фаззинг-тестирование),
— MAST (тестирование безопасности мобильных приложений),
— IAST (интерактивное тестирование безопасности приложений),
— RASP (самозащита приложения во время выполнения).

Эти инструменты нужно интегрировать в pipeline разработки и управлять ими для проведения сканирований. Даже для одного вида анализа может одновременно применяться несколько разных инструментов, поэтому при большом количестве таких одновременных проверок необходима оркестрация (управление «оркестром» анализаторов).

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

Чтобы решить эти проблемы, используются системы класса ASOC (Application Security Orchestration and Correlation). В них реализована автоматизация управления различными инструментами анализа ПО, которые нужны для обнаружения уязвимостей. Уязвимости, выявленные разными инструментами, собираются в едином представлении и приоритизируются по критичности – так AppSec специалист может быстрее и эффективнее их обработать. Кроме того, такие системы внутри себя содержат всю необходимую функциональность для построения процесса разработки безопасного кода ПО в компании.

Управление рисками, связанными с уязвимостями

Как и во многих процессах, в разработке безопасного программного обеспечения существует процесс управления рисками. Можно использовать все стандартные подходы в зависимости от ситуации: принятие риска, избегание, передача или его снижение. Это позволяет быть более гибкими с точки зрения скорости выпуска релизов, условий применения разрабатываемых продуктов и улучшает лояльность бизнеса к процессам AppSec.

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

Давайте разберем некоторые примеры. Так, уязвимость может содержаться в неиспользуемой части кода. Она будет выявлена инструментами анализа, но такой риск можно принять.

Другой пример, когда уязвимость может содержаться в компоненте, который сложно заменить, или исправить уязвимость в его исходном коде невозможно. В этом случае могут использоваться меры предотвращения эксплуатации найденных уязвимостей: например, виртуальный патчинг на WAF (межсетевом экране для веб-приложений).

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

Подытожим

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

Реклама ПАО «МТС» erid: LjN8Jv121

Эта статья пригодится разработчикам, которые, как и мы когда-то, задумываются об ИБ в продуктах и не знают, с чего начать.

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

Как мы проверяли безопасность разработки в компании

Логичен вопрос, зачем вообще внедрять систему разработки безопасного ПО в компании? Регуляторы требуют — это понятно. Но есть ли другие, более насущные предпосылки? Разумеется:

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

Я пришел в Tada в конце 2022 года. На тот момент о безопасной разработке ПО (БРПО) в ней «слышали, но не погружались». Поэтому для начала мне нужно было понять:

1. Какие меры уже реализованы и насколько хорошо?
2. Действительно ли продукт безопасно разработан, и какие уязвимости, недочеты есть в ПО и в инфраструктуре разработки?

Поскольку у меня уже был опыт прохождения сертификационных испытаний по требованиям ФСТЭК России к уровням доверия (одно из требований – наличие у разработчика-изготовителя процедур БРПО и проведение анализа уязвимостей и недекларированных возможностей), я понимал, какие процедуры, меры и инструментальные виды анализа должны быть реализованы.

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

• ГОСТ 56939-2016;
• Методика выявления уязвимостей и недекларированных возможностей в ПО ФСТЭК России (чтобы сертифицировать продукт).

И иными источниками: данными с конференций, презентациями компаний, в которых они делятся опытом (ТБ Форум, Kaspersky Certification Day и др.)

Дисклеймер: мы не претендуем на звание гуру MegaNanoExpertDevSecOpsGeneral и цель статьи не пытаться научить, а поделиться нашим опытом, который, возможно, окажется полезен тем, кто находится в начале ИБ-пути.

Вернемся к проверке компании. На тот момент команда уже проводила unit-тесты и функциональное тестирование ПО, что было уже хорошо и позволяло выявить явные ошибки в ПО, которые могут привести к угрозам безопасности:

• недостаточная аутентификация и авторизация;
• уязвимости ввода данных;
• утечка конфиденциальных данных;
• недостаточная обработка ошибок и другие.

Что касается оценки безопасности продукта, мы решили провести:

1. Статический анализ исходного кода.
2. Ручное тестирование (что-то типа функционального), чтобы выявить реальные баги в функциях ИБ ПО.
3. Анализ уязвимостей заимствованных компонентов и компонент среды функционирования ПО.
4. Динамический анализ и тестирование на проникновение.

Для этого мы выбрали следующие инструменты:

Результаты анализа оказались довольно интересными и местами даже неожиданными. Мы выявили около 200 critical и major (статический анализ) и 90 critical и high (анализ заимствованных компонент, динамический анализ и пентест).

Уязвимостей было много, и вот несколько наиболее интересных примеров:

1. Неправильная конфигурация turn-сервера

Для обеспечения обмена трафиком (видео/голос) мы используем turn-сервер. В ходе анализа мы выявили реквизиты доступа в открытом виде в файле features.json.

Что могло случиться? Злоумышленник мог построить socks-прокси (из-за неправильной конфигурации turn-сервера). В нашем случае сервер не проверяет, что адрес, по которому нужно подключиться, находится в локальной сети. Таким образом злоумышленник смог бы получить доступ ко внутренним ресурсам.

2. Хранимая XSS

Хранимая XSS (англ. Stored XSS) – это тип атаки на веб-приложение, при котором злоумышленник вводит вредоносный код (обычно JavaScript) на страницу веб-приложения, который сохраняется на сервере и затем отображается на странице для всех пользователей, которые обращаются к этой странице.

Здесь все просто: Cookie защищены флагом httponly от перехвата с помощью XSS. Однако злоумышленник может воспользоваться этой уязвимостью для переадресации пользователей на фейковый домен, чтобы получить учетные данные.

Достаточно вставить следующий payload XSS в некоторые формы ввода ПО, сгенерировать ссылку – приглашение и отправить жертве: \"--><img src=x onerror=alert("XSS")>.

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

Эти и другие уязвимости дали нам понять, что:

• необходимо внедрять БРПО на раннем этапе разработки;
• важно регулярно анализировать и обновлять уже имеющееся ПО и контролировать заимствованные компоненты.

Чтобы устранить эти уязвимости и обеспечить безопасность нашего ПО, необходимо было принять соответствующие меры: исправить код, обновить зависимые компоненты, изменить архитектуру ПО.

Что мы сделали по итогам проверки

Поиск и устранение недостатков и уязвимостей в ПО – это малая и далеко не самая приоритетная часть на раннем этапе внедрения разработки безопасного ПО.

Главная задача – заинтересовать команду и бизнес в необходимости такой разработки, чтобы все участники двигались в одном направлении и стремились сделать продукт безопаснее. И не появились те, кто пытается плыть против течения.

Как это прошло у нас

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

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

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

Затем мы провели цикл лекций для всей команды:

• обсудили пользу безопасной разработки для нашего продукта;
• рассказали об основных мерах, которые предстоит реализовать;
• поговорили о проблемах, которые есть в нашем продукте и которые нужно решить.

Вернемся к уязвимостям. Их было очень много. Мы с командой разработки провели экспертизу и «разметку» результатов анализа, определили степень критичности и возможности реализации угроз, связанных с этими недостатками ПО.

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

Что будем делать дальше

После проверок и подведения результатов мы активно занимаемся повышением квалификации команды инженеров в части безопасной разработки и проводим семинары по ИБ.

Обучаемся и внедряем процедуры проведения фаззинг-тестирования

Фаззинг-тестирование — вид тестирования, который позволяет выявить уязвимости в ПО путем подачи на вход большого количества входных данных (отслеживание утечки памяти, аварийных завершений и так далее).

Изучаем порядок и способ определения поверхности атаки, включая использование Natch

Natch — полезный инструмент для определения поверхности атаки от наших коллег ИСП РАН.

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

Разрабатываем метрики и сценарии реагирования на инциденты ИБ

Гарантировать 100% защищенности нельзя, всегда нужно быть готовым оперативно и правильно реагировать на инциденты ИБ.

Планируем полностью автоматизировать инструментальные виды анализа

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

Планируем сократить кодовую базу и базу зависимостей

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

Стремимся реализовать меры, которые позволят сертифицировать наше ПО и пройти процедуру оценки соответствия безопасной разработки ПО.

Скажем сразу, эта статья вводная. И основная ее идея — показать, насколько важно внедрять процедуры разработки безопасного ПО, особенно на раннем этапе разработки, когда это менее трудозатратно.

В следующих материалах мы расскажем о вопросах выбора и внедрения инструментальных средств и организационных мер, о проблемах, с которыми сталкивались и и вариантах их решения.

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

К примеру, представьте, что ваш автомобиль из-за программной ошибки не позвонил в службу спасения. Или самолёт вдруг отказался опустить шасси. Или рентген взял и облучил вас высокой долей радиации. Или робот-хирург отказался работать посреди операции.

Конечно, эти примеры — донельзя утрированные, но столкнуться с ними в реальной жизни не хотелось бы никому. Именно жёсткий стандарт MISRA позволяет исключить возможность ошибки, которая может стоить жизни.

MISRA C определяет правила, которым разработчикам следует следовать при написании кода. Каждый год количество правил, по своей сути — запретов, только растёт:

• В MISRA-C:1998 указаны 127 правил: 93 обязательных и 34 рекомендательных.
• В MISRA-C:2004 указано 141 правило: 121 обязательное и 20 рекомендательных.
• В MISRA-C:2012 указаны 143 правила и 16 директив.

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

Как появился MISRA

Стандарт MISRA был разработан ассоциацией MISRA (Motor Industry Software Reliability Association) в 1994 году в Великобритании. Изначальная цель стандарта — повысить безопасность и надежность ПО для автомобилей.

В начале 1990-х годов количество электроники в автомобилях неуклонно росло. Стало очевидно, что некачественный код может быть опасен для пассажира: к примеру, ошибка ПО во время движения может стоить водителю жизни. Чтобы обезопасить пассажиров, и была создана ассоциация MISRA.

Первый выпущенный стандарт назывался “MISRA Guidelines for the Use of C in Vehicle-Based Software”. Его опубликовали в 1994 году. Он определил правила для использования языка Cи в автомобильном ПО.

Помимо общих правил вроде оформления кода, первый стандарт включал в себя:

1. Правила для управления типами данных, которые запрещали преобразование типов.
2. Рекомендации для обработки исключительных ситуаций (exceptions). Рекомендации по использованию операторов try-catch, исключений и т.д.
3. Запрет непортативных (non-portable) функций и конструкций, которые могут привести к неправильному поведению или ошибкам при переносе кода на другие платформы или компиляторы.
4. Рекомендации и требования к валидации кода и процессу разработки.

В последующие годы стандарт обновлялся и дополнялся. В 2004 году был выпущен стандарт “MISRA C:2004”, а в 2012 году – стандарт “MISRA C:2012”.

В 2023 году стандарт снова обновился

Где используется MISRA

Сегодня стандарт используют почти во всём транспорте — в автомобильной и авиационной отраслях —, в медицине и промышленности. Вот несколько компаний, которые применяют MISRA в разработке ПО:

1. Автомобильная промышленность: BMW, Ford, General Motors, Honda, Toyota и Volkswagen.
2. Авиационная промышленность: Airbus и Boeing.
3. Медицинская техника: Siemens Healthineers, Philips Healthcare и Medtronic.
4. Промышленные системы: Schneider Electric и Rockwell Automation.

Что запрещено в MISRA

Вот несколько примеров того, что запрещено в стандарте MISRA:

1. Фрагменты кода не должны быть закомментированы.
2. Базовые типы char, int, short, long, float и double не должны использоваться.
3. Операнды логических операторов && или || должны быть первичными выражениями.
4. Оператор goto не должен использоваться.
5. Заголовочный файл и функция setlocale не должны использоваться.

К примеру, вместо char, int, short, long, float и double нужно использовать директиву typedef.

Неправильный код:

Правильный код:

Операнды && и || должны быть одиночными переменными, константами или выражениями в скобках.

Неправильный код:

Правильный код:

С полным списком правил на русском языке можно ознакомиться по этой ссылке.

Как проверять код на соответствие MISRA

На рынке есть несколько анализаторов кода, которые проверяют соответствие стандарту MISRA.

1. PC-lint/FlexeLint — один из самых популярных инструментов статического анализа для языка C и C++. PC-lint/FlexeLint поддерживает проверку соответствия нескольким версиям стандарта MISRA C, включая MISRA C:1999, MISRA C:2004 и MISRA C:2012.
2. Polyspace — анализатор от MathWorks также поддерживает проверку соответствия стандарту MISRA C. Он помогает отслеживать проблемы вроде неопределенного поведения или использования небезопасных функций.
3. Klocwork — ещё один популярный инструмент статического анализа, который поддерживает проверку соответствия стандарту MISRA C.
4. Cppcheck — бесплатный и открытый инструмент статического анализа для C и C++. Изначально он не настроен на проверку соответствия стандарту MISRA, но Cppcheck помогает обнаружить некоторые нарушения.

Также есть пара компиляторов.

1. IAR Embedded Workbench — один из наиболее известных компиляторов, который предоставляет мощный статический анализатор для поиска нарушения правил MISRA и предлагает решения для их исправления.
2. MULTI IDE — интегрированная среда разработки (IDE) с компилятором, поддерживающим стандарт MISRA C. MULTI IDE включает в себя инструменты статического анализа, покрывающие правила MISRA и помогающие в обнаружении потенциальных ошибок.

Заключение

В заключение, стандарт MISRA C — важный инструмент для повышения качества и безопасности кода, который включает рекомендации и правила для написания надежного и поддерживаемого ПО.

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

Соблюдение стандарта MISRA C — это только один из инструментов при разработке безопасного ПО. Он должен быть использован вместе с другими методологиями и практиками вроде тестирования или обзора кода.

Надеюсь, статья оказалась интересной и полезной. Если вы работаете, к примеру, в разработке ПО для автомобилей, расскажите в комментариях, используете ли вы MISRA в работе. Может быть, есть и другие стандарты, которые на практике популярнее MISRA?

Одним из таких инструментов является статический анализатор кода. О статическом анализе и его пользе для встраиваемых систем и пойдёт речь в этой статье.

Статический анализ кода

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

Статический анализатор кода — это ПО, которое проводит анализ программы без её реального выполнения. Инструменты статического анализа проводят более глубокую проверку исходного кода, чем это делает компилятор, который обычно находит только синтаксические ошибки. Их принцип работы заключается в следующем:

• на вход принимают исходный код проекта (желательно компилируемый);
• преобразуют исходный код в специальную модель для дальнейшего анализа (AST, семантическая информация и так далее);
• ищут дефектные места, применяя к модели набор диагностических правил, в основе которых лежат различные методологии;
• сохраняют все полученные предупреждения в удобный для вас формат;
• остаётся только изучить отчёт и исправить все дефектные места;
• PROFIT!

Статические анализаторы применяются для широкого спектра задач. Можно выделить наиболее распространённые:

Поиск ошибок в программном коде (наиболее распространённое применение). В этом плане статический анализ здорово дополняет процесс обзора кода, позволяя найти и исправить ряд проблем до того, как засядете на долгое время с коллегой.

Улучшение качества кода в широком смысле этого слова. К качеству можно отнести читаемость, поддерживаемость, сложность кода, уровень связанности и другие аспекты, которые прямо или косвенно могут влиять на количество ошибок. Тем самым, статические анализаторы могут помогать следовать стандартам кодирования (как принятым внутри компании, так и общепринятым).

Анализ кода как часть механизма Quality Gates в CI/CD. Анализаторы могут не только сообщать о наличии возможных ошибок в коде, но и служить защитным механизмом, предотвращающим доставку кода, если уровень его качества не соответствует заданным требованиям. Такую роль могут выполнять анализаторы кода, расширяющие поведение компилятора и блокирующие сборку, если были обнаружены ошибки или несоответствия кода принятым стандартам;

Сбор метрик проекта, сбор статистики, построение графиков и диаграмм, отражающих общее «состояние здоровья» проекта.

Польза внедрения

Польза от внедрения статического анализатора в разработку встроенного ПО несомненна. Давайте рассмотрим самые очевидные положительные стороны использования статического анализа.

Использование статического анализа позволит уменьшить вероятность дорогой, а то и вовсе невозможной «перепрошивки» уже выпущенных устройств

Ошибки в ПО встраиваемых систем крайне неприятны. Неприятность в том, что ошибки невозможно или почти невозможно исправить, если началось серийное производство. Если уже выпущены сотни тысяч стиральных машин и они разъехались по магазинам, то что делать при обнаружении неадекватной работы машины в определённом режиме? В общем-то вопрос риторический и реальных вариантов два:

1. Смириться и получать негативные отзывы клиентов на различных сайтах, портя свою репутацию. Можно, конечно, выпустить и разослать к инструкции приложение «не делайте вот так», но это тоже слабый вариант;
2. Отозвать серию и заняться обновлением прошивок. Дорогое развлечение.

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

Вывод очень простой: код встраиваемых устройств должен тестироваться как можно тщательнее, особенно, если ошибки могут привести к жертвам или серьёзным материальны потерям.

Статический анализ не гарантирует отсутствие ошибок в коде. Однако просто необходимо использовать любую возможность дополнительно проверить корректность кода. Статические анализаторы могут указать на множество разнообразных ошибок, которые умудряются оставаться даже после нескольких Code-Review.

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

Статические анализаторы кода значительно удешевляют процесс тестирования и отладки программ

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

Наверняка у каждого разработчика была неудачная попытка «прошить» устройство, в результате чего, например, оно некорректно держало заданное напряжение или вовсе перегорало. Что произошло и где искать проблему? Ведь причиной этому может быть не только программная ошибка, но и ошибка в самом «железе» или в некачественном изготовлении макета. В результате процесс поиска ошибки может сильно затянуться. Самый обидный сценарий:

• разработчик с полной уверенностью считает, что код написан верно;
• привлекаются схемотехники и другие коллеги, отвечающие за hardware-часть;
• идут долгие и мучительные поиски проблемы;
• разработчик возвращается к коду и внезапно обнаруживает, наконец, нелепую опечатку;
• колоссально неэффективный расход сил и времени коллектива;
• стыдно и неприятно.

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

А предыстория этой ошибки такая. За основу были взяты наработки от предыдущего проекта, и код во многом написан методом Copy-Paste. По невнимательности разработчик в одном месте забыл заменить 4 на 3. Как итог, неопределённое поведение при обращении к индексу за пределами массива. Коварность такого кода в том, что при отладке программа может работать корректно, а в реальных условиях при многократном запуске у клиента может происходить сбой. Великолепно, если такую ошибку найдёт статический анализатор.

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

Использование статического анализа позволит подстраховать разработчика с недостаточной экспертизой

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

Статические анализаторы имеют базу знаний о различных паттернах, которые в определённых условиях приводят к ошибке. Поэтому они могут указать программисту на ошибку, о существовании которой он сам вряд ли бы догадался. Примером может служить использование 32-битного типа time_t, который может привести к неправильной работе устройства после 2038 года.

Другим примером может служить неопределённое поведение программы, которое возникает из-за неправильного использования операторов сдвига <</>>. Эти операторы очень широко используются в коде микроконтроллеров. К сожалению, программисты часто используют эти операторы крайне неаккуратно, делая программы ненадёжными и зависимыми от версии и настроек компилятора. При этом программа может работать, но вовсе не потому, что написана правильно, а потому, что везёт.

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

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

Для встраиваемых систем популярными языками программирования считаются C и С++. Именно для них были разработаны такие стандарты, как MISRA C, MISRA C++ и AUTOSAR C++. Каждый стандарт имеет немалое количество правил и рекомендаций (MISRA C: 143, MISRA C++: 228, AUTOSAR C++: более 350), придерживаться которых при кодировании просто невозможно без статических анализаторов кода.

Правила представляют собой паттерны кодирования, которые необходимо избегать, тем самым уменьшая вероятность допустить ошибку. Сейчас все крупные игроки статического анализа (Coverity, Klockwork, PVS-Studio и так далее) стремятся к тому, чтобы максимально покрыть эти стандарты в своих инструментах.

Стандарты кодирования

История MISRA началась достаточно давно. В начале 90-x правительственная программа Великобритании под показательным названием «Safe IT» выделяла финансирование для различных проектов, так или иначе связанных с безопасностью электронных систем. Сам проект MISRA (Motor Industry Software Reliability Association) был основан ради создания руководства по разработке ПО для микроконтроллеров в наземных транспортных средствах – в машинах, в общем.

MISRA (как организация) – это содружество заинтересованных сторон из различных авто- и авиастроительных индустрий:

• Bentley Motor Cars;
• Ford Motor Company;
• Jaguar Land Rover;
• Delphi Diesel Systems;
• HORIBA MIRA;
• Protean Electric;
• Visteon Engineering Services;
• The University of Leeds;
• Ricardo UK;
• ZF TRW.

Весьма сильные игроки рынка. Неудивительно, что их первый связанный с языком стандарт — MISRA C — стал общепринятым среди разработчиков критически важных встраиваемых систем. Чуть позже появился и MISRA C++. Постепенно версии стандартов обновлялись и дорабатывались, чтобы охватывать новые возможности языков. На данный момент актуальными версиями являются MISRA C: 2012 и MISRA C++: 2008.

Отличительные черты MISRA: невероятное внимание к деталям и крайняя дотошность. Авторы не просто собрали в одном месте все пришедшие в голову «дыры» C и C++ (как, например, авторы CERT) — они тщательно проработали международные стандарты этих языков и выписали все возможные способы ошибиться. А потом взяли и сверху дописали правила и рекомендации про читаемость кода. Ведь в простом и легко читаемом коде тяжелее допустить ошибку и легче её обнаружить при Code-Review.

Зачастую у людей, которые впервые сталкиваются с MISRA, складывается мнение, что философия стандарта заключается в «запретить вон то и запретить вот это». На самом деле, это так, но лишь отчасти.

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

В MISRA C правила делятся на три основных категории: Mandatory, Required и Advisory. Mandatory — это правила, которые нельзя нарушать ни под каким предлогом. Например, в этот раздел входит правило «не используйте значение неинициализированной переменной». Required-правила менее строги: они допускают возможность отклонения, но только если эти отклонения тщательно документируются и письменно обосновываются. Остальные правила входят в категорию Advisory — это правила, которым следовать необязательно.

В MISRA C++ немного по-другому: там отсутствует категория Mandatory, и большинство прави принадлежит к категории Required. Поэтому, по сути, вы имеете право нарушить любое правило — только не забывайте документировать отклонения. Также там есть категория Document — это обязательные к выполнению правила (отклонения не допускаются), которые связаны с общими практиками вроде «Каждое использование ассемблера должно быть задокументировано» или «Подключаемая библиотека должна соответствовать MISRA C++».

Помимо описания проблематики, в стандарте содержится большое количество советов о том, что нужно знать перед началом работы: как наладить процесс разработки по MISRA; об использовании статических анализаторов для проверки кода на соответствие; какие документы нужно вести, как их заполнять и так далее.

На данный момент MISRA живёт и развивается. Например, в начале 2019 года был анонсирован The MISRA C:2012 Third Edition (First Revision) — обновлённый и дополненный новыми правилами стандарт 2012 года. Тогда же объявили о грядущем выходе MISRA C:2012 Amendment 2 — C11 Core — стандарта 2012 года, в который будут добавлены правила, впервые охватывающие версии языка Си 2011 и 2018 годов.

Не стоит на месте и MISRA C++. Как известно, последний стандарт MISRA C++ датируется 2008 годом, поэтому наиболее старшая версия языка, которую он охватывает — это C++03. Из-за этого появился ещё один стандарт, аналогичный MISRA, и называется он AUTOSAR C++. Он изначально задумывался как продолжение MISRA С++ и имел своей целью охватить более поздние версии языка. В отличие от своего вдохновителя, AUTOSAR C++ обновляется два раза в год и на данный момент поддерживает C++14. Планируется дальнейшее обновление до C++17, а затем C++20 и так далее.

Заключение

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

• сократить время на поиск и устранение ошибок;
• уменьшить вероятность критических ошибок;
• уменьшить вероятность необходимости обновления прошивок;
• контролировать общее качество кода;
• контролировать качество работы новых членов команды;
• строго следовать определённому стандарту разработки программного обеспечения;
• контролировать качество кода сторонних модулей/библиотек.

Нужен ли вам статический анализ или нет, решать именно вам!

Copilot не копирует код, а создаёт «производный продукт» — это значит, что проекты, написанные с помощью ИИ от Microsoft, можно распространять под лицензиеями Copyleft или AGPL. То есть изначальная лицензия GPL «вымывается» из ПО.

Есть «фича» и пострашнее. Эксперт в области ИИ Алекса Шампандард обратил внимание, что Copilot тащит в проект действительные API-ключи из открытых репозиториев.

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

В «проблемах с безопасностью» обвиняют GitHub Copilot: Microsoft скармливали репозитории без согласия их создателей. Но в этой истории есть и вина пользователей, которые оставляют секретную информацию в открытом доступе.

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

Источник: SecurityLab

В ходе исследования специалисты изучили более 130 тысяч приложений. Проблемы с безопасностью были выявлены у 76 % приложений. В каждом четвёртом случае найденные проблемы отнесены к категории опасных. В каждом третьем приложении уязвимости появились из-за использования сторонних библиотек.

Процент приложений с опасными проблемами безопасности:

1. С++ — 59 %
2. PHP — 52,6 %
3. .NET — 25 %
4. Java — 23,8 %
5. Python — 9,6 %
6. JavaScript — 8,6 %

Если говорить обо всех уязвимостях, то самым проблемным оказался код на PHP. В 74,6 % приложений встречается межсайтовый скриптинг, в 71,6 % случаев обнаружены проблемы с шифрованием.

Результаты исследования с описаниями результатов опубликованы на странице State of Software Security. Там раскрыты наиболее распространённые уязвимости для каждого языка.

Есть также страница с подробным описанием обнаруженных проблем и способов их исправления.

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

Ведущий специалист по тестированию компании BI.ZONE Андрей Колесников разобрал 11 распространенных ошибок, которые могут сделать ваше приложение уязвимым. По большей части эти ошибки влекут за собой кражу денег или данных, удаленное выполнение кода, отказ в обслуживании или повышение привилегий.

В статье рассмотрено, как тот или иной недочет приводит к дырам в безопасности, а также предложены варианты решения.

1. Отсутствие экранирования, неправильное форматирование, а также некорректное использование форматной строки и параметров у printf-функции

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

Угроза. Такие ошибки связаны с целым рядом уязвимостей и атак: SQL Injection, NoSQL Injection, XXE, XSS, уязвимость форматной строки и прочими. Последствием наличия таких недостатков может стать возможность компрометации системы организации.

Решение. Фильтруйте и валидируйте все данные, поступающие из внешних недоверенных источников, а также используйте встроенные средства языков программирования, спроектированные специально для устранения таких проблем (например, Prepared Statements в случае с SQL).

2. Некорректная работа с конфиденциальными данными

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

Угроза. Из-за недостаточно бережного отношения к конфиденциальным данным они могут стать доступны третьей стороне.

Решение. Отслеживайте цепочку работы с конфиденциальными данными: как они хранятся, обрабатываются, передаются и на каком из этих этапов может что-то пойти не так. В случае журналирования или передачи третьей стороне — применяйте маскирование: +7 (999) 888-77-66 -> +7 (999)***-**-66 и т.п.

3. Десериализация ненадежных данных

Проблема. Приложение десериализует данные из недоверенного источника без достаточной их валидации. Такая уязвимость имеет идентификатор CWE-502 и находится на восьмом месте в рейтинге критических рисков веб-приложений OWASP Top Ten.

Угроза. В результате атаки на механизмы десериализации злоумышленник нередко получает возможность удаленно исполнять команды в скомпрометированной системе.

Решение. По возможности используйте простые форматы (например, JSON) для передачи данных и для их сохранения на диск или в базу данных. Кроме того, ведите белый список допустимых классов и подписывайте передаваемые сериализованные данные.

4. Хранение аутентификационных данных в исходном коде

Проблема. Пароли, ключи, токены хранятся в исходном коде или репозитории исходного кода.

Угроза. Информация из кода может попасть к третьим лицам. Если там хранятся аутентификационные данные, злоумышленник легко получит доступ к системе или ее компонентам.

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

5. Использование непроверенного чужого кода

Проблема. Использовать чужой код всегда проще, но если вы его не проверили — это большой риск. Такой код может содержать уязвимости или намеренно оставленные бэкдоры.

Угроза. Злоумышленник, знающий о существовании уязвимости или бэкдора, может скомпрометировать систему.

Решение. Не рискуйте без необходимости: обязательно проверяйте чужой код, а лучше всегда обращайтесь к уже зарекомендовавшим себя библиотекам, например GSON, Apache Commons, Bouncy Castle и так далее.

6. Использование устаревших версий библиотек и софта

Проблема. Устаревшие версии библиотек и ПО содержат уязвимости, информация о которых есть в открытом доступе.

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

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

7. Неграмотное использование криптографии

Проблема. Принципы криптографии весьма неочевидны и в попытке изобрести лучшее решение неопытные разработчики используют свои «костыли» вместо проверенных средств.

Угроза. С непроверенными алгоритмами криптографическая стойкость снижается: уязвимости могут появиться где угодно. Выстроенная защита не работает и злоумышленникам легко ее обойти.

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

8. Использование паролей по умолчанию или полное отсутствие аутентификации

Проблема. В конфигурациях различных сервисов и программных продуктов (базы данных, CMS и т. д.) остаются настройки, заданные по умолчанию.

Угроза. Слабые пароли или отсутствие аутентификации — прямой путь для доступа злоумышленника к системе и ее компонентам.

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

9. Игнорирование официальной документации

Проблема. В процессе разработки продукта не учтены рекомендации и практики из официальной документации.

Угроза. Если не задать объектам определенные свойства, качество кода в целом снизится и могут возникнуть уязвимости.

Решение. Все объекты, с которыми вы работаете, требуют бережного отношения и скрупулезно заданных свойств. Официальная документация — отличный помощник в этом: в ней содержится огромное количество практических советов. Мы регулярно сталкиваемся с ситуациями, когда подход Secure by default совершенно не работает даже в очень популярных open-source-решениях. В таких случаях единственный способ безопасно использовать компонент — внимательно изучать документацию и возможные настройки.

10. Проверки на стороне клиента

Проблема. Проверки корректности входных данных выполняются исключительно на клиентской стороне.

Угроза. В серверную часть приложения могут попасть непровалидированные данные, что нередко приводит к уязвимостям (см. п. 1) или нарушениям бизнес-логики.

Решение. Выполняйте все проверки на стороне сервера приложения. Проверки на стороне клиента — это не мера безопасности, а улучшение пользовательского опыта.

11. Недостаточные журналирование и мониторинг

Проблема. В системе реализовано недостаточное количество методов журналирования и мониторинга происходящих событий и параметров.

Угроза. Когда в системе остаются слепые пятна, есть опасность пропустить происходящие в ней аномалии и не заметить атаку злоумышленника.

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

Ошибки совершают все. Но опытных разработчиков от начинающих отличает умение предвидеть хотя бы некоторые из них. Думать о безопасности, а значит, думать стратегически — это признак профессионала. К такому подходу и стоит стремиться в разработке.

А так ли это на самом деле?

Какие уязвимости можно найти в приложении?

Ещё живут различные инъекции (SQL, NoSQL, LDAP, OS, XML, XQuery, XPath, XSLT), LFI-уязвимости, закладки (внедрённые в код функции, которые срабатывают в определённый момент), слабые алгоритмы шифрования, небезопасная работа с логами и cookie, а также утечка информации через социнжиниринг.

Самые опасные уязвимости веб-приложений можно посмотреть на странице OWASP Top Ten, которая регулярно обновляется.

И это лишь вершина айсберга.

Правда ли, что львиная доля атак приходится на бреши в механизмах аутентификации?

Согласно статистике Positive Technologies, наиболее часто встречающиеся уязвимости веб-приложений за 2019 год связаны с неправильной настройкой безопасности. А вот самому высокому риску подвержены сайты со слабой аутентификацией. Такая проблема была обнаружена в 45% исследованных веб-приложений:

Почти треть таких уязвимостей обусловлена неограниченным количеством попыток войти в аккаунт. Аутентификация только по паролю является тем фактором, который способствует наибольшему количеству атак посредством перебора комбинаций «логин/пароль». Требования к возрасту и сложности пароля, которые раньше были «золотым стандартом», теперь подрывают безопасность. Согласно рекомендациям NIST, организациям следует перейти на многофакторную аутентификацию, если они ещё этого не сделали.

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

Обеспечение безопасности приложения — это задача безопасников?

Не совсем, ведь уже на стадии разработки нужно обращать внимание на очевидные уязвимости.

Разработчик должен с первой редакции сайта или приложения заложить основные инструменты защиты данных пользователя, например Web Application Firewall. В дальнейшем, с выходом патчей, закрывать появляющиеся уязвимости. В идеальной ситуации разработчик должен либо самостоятельно, либо с привлечением дополнительных специалистов тестировать продукт на проникновение, раз за разом применяя популярные методы взлома и после анализируя полученный результат.

Что включает в себя обеспечение безопасности приложения?

Это все меры, в том числе и те, которые предшествуют этапу разработки:

1. Корректная постановка цикла разработки и деплоя. Это также включает выбор релевантного подхода к разработке (Agile/Waterfall), применение лучших практик DevOps, использование доверенного серверного оборудования.
2. В команде должен быть один или несколько специалистов, которые отвечают за информационную безопасность.
3. Сформированная модель угроз безопасности — метрики, которые нужно постоянно отслеживать, особенно при каждом обновлении или изменении внешних факторов. Стоит понимать, что модели угроз будут разными для разных приложений.
4. Использование технических средств анализа защищённости кода.
5. Использование защищённой среды разработки.

Application security — сложная задача, особенно в больших командах. Здесь важна грамотная работа архитекторов, которая предусмотрит механизмы безопасности для каждого из «кирпичиков» проекта, тем самым обеспечивая многоуровневую защиту продукта.

Какими бывают технические средства анализа защищённости кода?

Основной пласт анализаторов включает в себя:

• Статические — это анализаторы исходного кода на базе механизма статического анализа (SAST). Проверка происходит без запуска самой программы на промежуточных этапах разработки или на этапе сборки. К SAST-решениям относятся Synopsys, AppScan, Checkmarks, Veracode, Appercut, Application Inspector, Micro Focus.
• Динамические — применяются к готовому коду и ориентированы в основном на веб-приложения. Работают на базе динамического тестирования безопасности (DAST) через подачу URL-адреса в автоматический сканер.
• Интегрированные в CI (Continuous Integration) — сканируют статический и динамический код.
• Инструменты пентестера.

Как создать защищённую среду разработки?

Стоит помнить, что обеспечить безопасность приложения можно только комплексно, поэтому уделяйте внимание каждому из этапов:

1. Сегментировать сеть и организовать управление сетевыми проходами.
2. Настроить права доступа для каждой роли.
3. Хранить пароли в хешированном виде с применением так называемой соли.
4. Организовать защищённый удалённый доступ.
5. Управлять обновлениями.
6. Мониторить и документировать.
7. Обезличивать важные данные при работе с БД в тестовом режиме.

На что должен обращать внимание разработчик, чтобы защитить приложение от взлома?

Позаботиться о безопасности сервиса лучше на самых ранних этапах его разработки. В этом помогут проекты от сообщества OWASP, например руководства «Проактивная защита: Топ-10 требований OWASP» (набор практик для изначального повышения безопасности приложения) и рейтинг 10 самых опасных угроз безопасности веб-приложений OWASP Top 10. Также важным является включение безопасности как составляющей цепочки CI/CD вашего приложения, например использование SAST и DAST-решений. Причём необязательно сразу покупать и внедрять коммерческие решения, ведь существуют и вполне достойные варианты из мира свободного ПО.

По моему опыту, один из главных шагов к безопасности приложения — это ограничение функциональности для каждого пользователя по принципу need-to-know. Этот принцип возник в военной среде, однако полезен и в разработке: соблюдая его, вы не даёте пользователю получать больше информации, чем ему нужно.Не менее важны процессы код-ревью и независимого анализа защищённости. Для второго можно привлекать собственную команду безопасности, обращаться в специализированные компании или добавить приложение в программу bug bounty, чтобы сотни исследователей со всего мира непрерывно искали за вас баги.Также важно изучать уязвимости чужого кода, который вы вносите в проект: посмотрите issue на GitHub, проверьте продукт в базе уязвимостей. Есть замечательный проект наших коллег Vulners, который агрегирует данные по существующим уязвимостям из различных источников.

На заключительных этапах разработки не будет лишним позаботиться о защите кода от чтения и дизассемблирования. Здесь тоже имеются проверенные временем методики: от простой обфускации до применения ассемблерных вставок и продвинутых средств защиты от отладчиков. Вообще, хорошей практикой является «чистка» кода перед отправкой его в продакшн. Пользователю ведь никак не помогут комментарии, объясняющие, как работает тот или иной вызов либо функция. А вот для атакующего это большое подспорье при анализе продукта. Кроме того, следует избегать прописывания различных конфиденциальных данных внутри самого кода. Например, не рекомендуется встраивать ссылки с данными авторизации на сервере для автоматического тестирования.

А как обстоят дела с безопасностью мобильных приложений?

Безопасная разработка мобильного приложения включает три этапа.Во-первых, важно заранее учитывать, что приводит к уязвимостям, и ещё во время разработки предусмотреть все меры профилактики. Так, для предотвращения утечки данных необходимо использовать криптографические алгоритмы, многофакторную аутентификацию, генерировать непредсказуемые идентификаторы сессии и хранить авторизационные токены в наиболее безопасных частях операционной системы.Безопасность передачи информации осуществляется за счёт подтверждения достоверности источников связи, корректных версий SSL и проверки согласования. Права доступа к скрытым разделам приложения необходимо давать только узкому кругу ответственных за них специалистов.Далее необходимо протестировать приложение на предмет наличия подобных уязвимостей. В основном используются методы белого и чёрного ящика. Метод белого ящика (статистическое тестирование безопасности SAST) подразумевает проверку разработчиком, имеющим доступ к коду. Метод чёрного ящика предполагает анализ только пользовательского опыта, без оценки кода. Тестировать можно вручную или с помощью специальных сервисов.И последнее, перед собственно отработкой выявленных уязвимостей расставьте приоритеты. В первую очередь устраните ошибки, при которых работа приложения невозможна. Затем идут критические баги: зависание системы или временные падения. После смотрите на ошибки, не влияющие на работу, например, недочёты дизайна. В самом конце устраняйте мелкие баги.Рекомендую использовать параметризованные запросы к базе данных, не конструировать запросы внутри системы, для доступа к БД использовать отдельную учётку и не забывать про журналы безопасности.

Резюмируя

Чтобы понять, как обеспечить безопасность приложения, следует изучить наиболее опасные уязвимости, учесть это на стадии разработки и тестирования, при выявлении — устранить и обязательно задокументировать все найденные проблемы, чтобы избежать их в дальнейшем. Не стоит также забывать об анализаторах и безопасности самой среды разработки.

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

Что могут делать разработчики

• Реализовать резервное копирование новых источников данных.
• Убедиться, что данные резервного копирования хранятся в месте назначения, которое соответствует финансовым требованиям или требованиям соответствия.
• Включить в работу анализ и обработку данных на платформе, например, добавление метаданных, возможности глубокого поиска или специальные схемы шифрования.
• Предлагать управляемые услуги и поддержку приложений SaaS для клиентов и конечных пользователей, а затем объединять решения для кибербезопасности.
• Интегрировать технологии Acronis в свои приложения, системы и облачные торговые площадки.

Ещё Acronis провела ребрендинг своих продуктов.

Acronis Cyber Cloud (ранее Acronis Data Cloud) — это платформа, позволяющая сервис-провайдерам предоставлять клиентам киберзащиту. В ближайшем обновлении будет доступна функция резервного копирования G Suite и защита от криптомайнинга.

Acronis Cyber Infrastructure (ранее Acronis Software-Defined Infrastructure) — это масштабируемое решение для создания программно определяемой инфраструктуры на базе стандартного оборудования. Оно поддерживает все виды нагрузок для работы с данными.

Использование анклавов

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

Ранее разработка и запуск приложений в TEE требовали специальных знаний, инструментов и имели привязку к конкретным аппаратным средам. С Asylo исчезла необходимость получать дополнительные знания для разработки анклавных приложений.

Преимущества Asylo

Разработчики выделяют следующие преимущества использования фреймворка:

• не требуется изучение новой модели программирования или переписывание кода приложения;
• перенос компонентов в анклавы осуществляется без изменения исходного кода;
• повышенный уровень безопасности приложений благодаря открытому доступу к коду.

Компоненты Asylo находятся в свободном доступе на GitHub. Скачать фреймворк и ознакомиться с документацией можно здесь.

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

Что ты такое?

Process Doppelgänging во многом похожа на технику Process Hollowing. Она так же создает копию ожидающего легитимного процесса с последующей подменой оригинала на «зараженный». Главное отличие новой разработки — это работа через транзакции NTFS, позволяющая избежать использования подозрительных процессов в памяти. Запущенный подобным образом код способен ловко обойти защитные механизмы стандартных алгоритмов поиска вируса.

Новая техника была успешно протестирована на самых популярных антивирусах — ни одному из них не удалось выявить атаку.

Однако, по словам исследователей, пока что рано бить тревогу. Для использования этого инструмента хакерам необходимо разбираться в «недокументированных деталях о создании процессов». К тому же компания enSilo уже разработала алгоритмы обнаружения Process Doppelgänging. Правда, выпуск патчей для новой техники — задача неосуществимая, так как атака работает с фундаментальными функциями Windows.

Информация о деталях реализации Process Doppelgänging доступна в официальной презентации.

Большинство утилит и функций платформы Microsoft Security Risk Detection работают по принципу фаззинга, при котором приложению на вход подаётся случайный набор данных и анализируются аномалии выходных данных для определения возможных уязвимостей.

Большинство обнаруживаемых ошибок связано с ошибками памяти. VulnScan обнаруживает их тип и первопричины, чтобы разработчики и инженеры смогли вовремя устранить бреши в системе безопасности исследуемых приложений. Результатом работы сервиса будет отчёт, подобный представленному на сайте разработчиков.

Тесты Microsoft

В Microsoft уверяют, что VulnScan способен обнаруживать ошибки следующих типов: выход за пределы областей чтения и записи, использование переменной после освобождения памяти, использование неинициализированной памяти, путаница типов, разыменование указателей на null и указателей на константу.

VulnScan базируется на двух других инструментах Microsoft — Debugging Tools для Windows (WinDbg) и Time Travel Debugging (TTD). По словам Матеуша Крживицкого из центра Microsoft Security Response (MSRC), компания использует VulnScan в течение последних 10 месяцев для обработки проблем, связанных с памятью и обнаруженных в Microsoft Edge, Microsoft Internet Explorer и Microsoft Office. Примерно в 85% случаев сервис успешно обнаружил проблемы, что позволило сэкономить около 500 часов рабочего времени инженеров MSRC.

Как воспользоваться VulnScan?

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

В то время, как Microsoft за большинство своих продуктов требует оплаты, Google делает многие свои продукты для фаззинга Open Source проектами, включая утилиты Domato и OSS-Fuzz.

В заголовке не шутка: я сам попробовал, вполне получилось.

Итак, представляю вашему вниманию файл в формате Excel, который умеет генерировать из своего содержимого сайты на Bootstrap.

Господи, зачем?!

А почему нет? Как мне известно, VBA умеет совершать операции со строками и имеет логические операторы, а также может работать с HTTP. Что еще нужно?

Еще мне захотелось просто поэкспериментировать с VBA. Несмотря на всеобщую ненависть среди программистов, Excel — удобная для определенных целей платформа, и мне было интересно приложить ее к какой-нибудь нестандартной пугающей задаче.

На самом деле мне вообще очень не нравится дифференциация на “элитные” и “плохие” языки программирования. Существует такая точка зрения (порождающая адские холивары), что некоторые языки и платформы во всем лучше остальных и что есть такие, которые лучше никогда не использовать. Разве это объективно?

Итак, я попробую делать сайты с помощью Excel. И никто не сумеет меня остановить.

Как это работает

Книга лежит в открытом доступе — для начала скачайте ее, если вам интересно все попробовать лично.

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

Результаты записываются в html-файл. В принципе, вам только он и нужен — весь CSS и JavaScript лежит на CDN-сервере. И вот у вас уже готова минимальная страничка, еще и на Bootstrap!

На нее можно даже поставить Bootstrap-тему! Вам будет дан список на выбор.

Теперь настало время поделиться своим творением с миром. У меня тут завалялся свободный сервер, так что я по-быстрому прицепил к нему домен excel-bootstrap.cf, установил Apache с LetsEncrypt, и получился настоящий хостинг (с самым минимальным уровнем безопасности).

Под “минимальным уровнем безопасности” я имею в виду этот супер-скрипт на PHP:

Есть еще четырехстрочный .htaccess, но он особого интереса не представляет.

По сути, на моем неподражаемом хостинге этот скрипт просто ищет файл с подходящим названием и выводит его на страницу. Если пытаются обратиться к корню сайта — переадресует на GitHub-репозиторий проекта.

Даже есть вышеупомянутые зачатки безопасности: размещать файлы вы можете, только имея правильный GUID. Конечно, там могут быть какие-то лазейки, которые отыщет опытный хакер, но не забывайте, я написал все это за 10 минут.

В продакшн!

На всю работу ушло менее 3 часов. Давайте расскажу подробнее, на какую часть работы сколько ушло.

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

Где-то за 34 минуты я обрисовал идею и реализовал макет.

Потом создал репозиторий на GitHub, написал маленькое readme — и настало время делать сам проект.

Я быстренько зарегистрировал на себя домен excel-bootstrap.cf, прицепил к серверу, создал для него неповторимое API (на картинке видно, как оно используется) и добавил в книгу возможность загружать на мой сервер сгенерированные файлы.

В процессе работы:

• Всего затрачено времени: 2 часа 15 минут.
• Всего потеряно единиц IQ за время создания: неизвестно.

И ради чего все это?

Вообще мне просто захотелось посмотреть, насколько бессмысленное и ужасное творение я способен создать. Но это была не единственная цель. Главная мысль, которую я хочу до вас донести этим адом: нет правильных и неправильных способов что-либо делать.

Буду я еще когда-нибудь писать сайты в Excel? Да ни за что в жизни.

Найдется ли какой-нибудь незадачливый бизнесмен, которому понравится идея сделать страничку для своей компании в родной и привычной программе? Вполне может быть.

А кто может оценить, насколько верен выбранный путь? Да никто.

Итак, мораль.

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

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

В этой статье собрано несколько интересных докладов с PyCon этого года, ориентированных на опытных Python-разработчиков.

Жизненный цикл класса в Python

В ходе своего выступления Майк Грэм — разработчик Edgestream Partners, создающий приложения, ориентированные на высокую производительность — создает простой класс на Python и отслеживает все с ним происходящее на различных этапах его жизненного цикла: от объявления до уничтожения сборщиком мусора.

Объяснение статистики с помощью Python

Три наглядных доклада были посвящены математической статистике. В первом, озаглавленном как «Статистика для хакеров», профессор Университета Вашингтона Джейк Вандерплас использует программы на Python для демонстрации методов теории вероятностей и математической статистики.

Два других доклада — от профессора Алена Дони — преследуют ту же цель: объяснить предмет не столько математически, сколько «вычислительно». Один из них посвящен вычислительным методам в статистике вообще, а второй демонстрирует явления байесовской статистики.

Использование «еще более крутых фич» Python

В выступлении Майкла Мюллера — одного из преподавателей Python Academy — рассказывается о правильном применении дескрипторов и метаклассов. Цель доклада — научить слушателей грамотно реализовывать их самостоятельно.

Безопасные расширения для Python на C

Где-то между Python и C находится CPython API, использование которого сопряжено с разнообразными трудностями — например, управлением памятью. Пол Росс берется приподнять завесу тайны в подобных вопросах, рассказав о разнообразных шаблонах проектирования, упрощающих процесс разработки расширений и повышающих производительность создаваемых модулей.

Рекомендуем вам также самостоятельно взглянуть на списки докладов и руководств на официальном сайте конференции.

Также обратите внимание на еще одну подборку видео по Python, которые стоит посмотреть.