ch
Feedback
AppSec & Compliance

AppSec & Compliance

前往频道在 Telegram

Application Security & Compliance Безопасность приложений и сертификация СЗИ в промышленных масштабах

显示更多
570
订阅者
-124 小时
+17 天
+630 天
帖子存档
Можно ли найти IDOR статическим анализом? Пишем ядро для Python Написал ядро статического анализа для детекта IDOR-уязвимосте
Можно ли найти IDOR статическим анализом? Пишем ядро для Python Написал ядро статического анализа для детекта IDOR-уязвимостей в Python-коде. Вместо поиска подозрительных конструкций и ключевых слов оно отслеживает путь от подконтрольного пользователю идентификатора до объекта и проверяет, была ли выполнена авторизация именно для этого объекта. В статье разберу архитектуру ядра, taint-анализ, логику детекта и покажу, как всё это работает на реальном коде. Читать далее via Публикации по подписке (author: kovachvl)

Искусственный интеллект и ФСТЭК России: действующие и проектируемые документы по состоянию на 01.09.2026 После непродолжительных поисков в нормативных недрах обнаружились следующие документы за авторством ФСТЭК России, в которых так или иначе упоминается «искусственный интеллект»: Читать далее via Публикации по подписке (author: Valerich_123)

CVE: история о том, как два инженера устали от хаоса и создали идентификатор, связавший все уязвимости мира Одна уязвимость,
CVE: история о том, как два инженера устали от хаоса и создали идентификатор, связавший все уязвимости мира Одна уязвимость, дюжина названий, 321 запись и стенд, за которым конкуренты договорились “дружить”. История создания самого известного идентификатора в кибербезопасности по первоисточникам 1999 года. Читать далее via Публикации по подписке (author: xnuinside (CodeScoring))

Veracode сделали очередной интересный отчёт В прошлый раз отчёт от них кидал в феврале - https://t.me/tech_b0lt_Genona/6226 В
+2
Veracode сделали очередной интересный отчёт В прошлый раз отчёт от них кидал в феврале - https://t.me/tech_b0lt_Genona/6226 В этот раз он называется GenAI Code Security Report https://www.veracode.com/resources/analyst-reports/2026-genai-code-security-report/report/ Я не буду писать много текста в пост, но главный посыл отчёта такой: ИИ-шки практически на 100% точно научились генерить синтаксически корректный код, но всё ещё достаточно плохо делают код безопасным На втором графике видно разброс по CWE: для CWE-89 (SQL инъкции) и CWE-327 ("плохая" и ненадёжная криптография) всё в целом норм, а для CWE-80 (XSS) и CWE-117 (log injection) ситуация сильно хуже. Отчёт актуален на конец июля 2026 года, поэтому в таблице нет Fable, Astra и т.д. ЗЫ Я хотел сохранить отчёт в PDF и приложить как обычно в комменты, но страница свёрстана так, что печать в PDF работает криво. Думаю, что это сделано специально. Если есть идеи как получить этот отчёт в нормальном виде, то пишите или скидывайте в комменты или личку 🌝

Перестаньте спрашивать «этот скилл безопасен?» — спрашивайте «что он умеет?» Подход «раскрытия возможностей» (capability disc
Перестаньте спрашивать «этот скилл безопасен?» — спрашивайте «что он умеет?» Подход «раскрытия возможностей» (capability disclosure) к скиллам для ИИ-агентов и маленький open-source инструмент, который читает скилл за вас. Читать далее via Публикации по подписке (author: Yahhi)

Один BPF‑объект, два верификатора, разные вердикты: разбираемся, кто прав eBPF‑программы проходят статический анализ до загру
Один BPF‑объект, два верификатора, разные вердикты: разбираемся, кто прав eBPF‑программы проходят статический анализ до загрузки в ядро Linux. Верификатор должен доказать, что программа не выходит за границы памяти, не работает с неверными указателями и не нарушает ограничений, без которых код нельзя безопасно выполнять в ядре. Но если прогнать один объект через разные верификаторы, картина меняется. Один анализатор принимает BPF‑объект, а другой считает его небезопасным и запрещает загрузку. Именно так и вышло... Статья для тех, кто исследует eBPF и статический анализ. Ошибку в программе мы искать не будем — её там нет. Нас интересует другое: почему два верификатора расходятся в выводах. Читать далее via Публикации по подписке (author: AriaQA (FirstVDS))

Рубрика #Офтоп Кто первым из производителей тудушников сделает локальные дополнительные (дочерние?) учётные записи ИИ-агентам пользователя тудушника? Делегирование ИИ-агентам прямо средствами тудушника + возможность для ИИ-агентов забирать назначенные на них задачи из тудушника по API = готовый пайплайн выполнения задач... Уточнения \ обратная связь \ отчёт - по "классическим" каналам: ТГ, эл.почта, ...

Repost from DevSecOps Talks
Qwen 2.5 7B: «тонкая» настройка для ответов на ИБ-вопросы Всем привет! Автор статьи работает над собственным решением – Valqore. Его задача состоит в сканировании Kubernetes, Terraform и облачных ресурсов для поиска ошибок различного рода: от ИБ до несоответствия требованиям. В качестве основы используется «движок» с детерминированным набором правил: он не галлюцинирует и даёт идемпотентный результат. Для удобства пользователя Автор захотел добавить ИИ, который смог бы объяснить просто и понятно: «Что не так и как это исправить?». И тут возникла проблема: ответы AI могли быть корректными, но общими. Она хорошо «подсказывала» в вопросах, связанных с облаками. Однако, ответы резко становились хуже, если вопросы были именно про Valqore. Решением стало обучение Qwen 2.5 7B: 🍭 Создание набора данных о правилах (что проверяет, в чём проблема, как исправить и т.д.) 🍭 Создание набора данных о «доменах» (Kubernetes, Terraform, CIS Benchmarks и т.д.) 🍭 Тренировка В результате Автору получилось добиться желаемого результата. Примеры «до» и «после» можно найти в статье. Кроме того, там перечислены его «ошибки» и «гипотезы, которые не сработали». А в завершение статьи представлена общая статистика обучения: от количества тестовых данных до времени обучения.

Ну и куча исправлений

Расширили количество "ползунков" для более тонкой настройки инструментации (AFL_LLVM_DENSE, AFL_LLVM_MINMAX, AFL_LLVM_FUSED, AFL_LLVM_VECTORS)

Убрали старую инструментацию (map[current_location ^ prev_location >> 1] += 1) И N-Gram'мы на её основе (map[current_location ^ prev_location[0] >> 1 ^ prev_location[1] >> 1 ^ ... up to n-1] += 1)

Добавили стадию "голода" - при долгом отсутствии новых путей мутации становятся более разнообразными

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

Российские разработчики получат национальные сертификаты для подписи кода https://www.vedomosti.ru/technology/articles/2026/08/31/1225141-rossiiskie-razrabotchiki-poluchat
Минцифры предложило закрепить правила выдачи российских сертификатов для написанного кода. Информация о них будет отображаться в установочном файле конкретной программы. Это значит, что по электронной метке операционная система сможет определить издателя и предупредить пользователя, если программа выпущена неизвестной компанией. Об этом говорится в проекте постановления правительства, с которым ознакомились «Ведомости». До сих пор подведомственный Минцифры Национальный удостоверяющий центр (НУЦ) выдавал сертификаты безопасности только для сайтов и веб-сервисов. Это нужно для того, чтобы потерявшие доступ к иностранным сертификатам безопасности ресурсы продолжали открываться. ... По словам представителя Минцифры, порядок выпуска сертификатов уже применялся на практике, но не был закреплен в публичном регламенте. Ведомство при этом не уточнило, выдавались ли раньше сертификаты именно для подписи кода и какими платформами они будут признаваться. Сертификат для кода также позволит установить разработчика программы и проверить, не изменили ли ее после выпуска, говорится в проекте. Принятый в июне закон № 210-ФЗ впервые закрепил статус НУЦ и его полномочия, а проект приказа описывает 11 профилей сертификатов: для сайтов, программного кода и корпоративных систем. Правило должно вступить в силу 1 марта 2027 г. Опрошенные «Ведомостями» при содействии ассоциации «Руссофт» эксперты считают, что новые сертификаты смогут заменить западные аналоги главным образом внутри России. Но Microsoft, Apple и Google по умолчанию легитимность НУЦа не признают. «Сложно представить, что к нашим отечественным сертификатам появилось бы доверие у иностранных магазинов приложений», – говорит эксперт удостоверяющего центра «СКБ Контур» Иван Быков. Поэтому сертификат НУЦа не вернет подсанкционного разработчика в App Store или Google Play, но позволит подтверждать его программы внутри российского контура, говорит он. Сам закон № 210 пока не обязывает разработчиков подписывать программы сертификатами НУЦа, но позволяет правительству установить такое требование в отдельных случаях. Наиболее обоснованно вводить его при госзакупках и поставках ПО для критической информационной инфраструктуры, считают генеральный директор Axiom JDK Роман Карпов и архитектор департамента информационной безопасности «Рексофт» Даниил Левченко. ИТ-директор «Корус Консалтинг» Максим Копов предлагает вводить обязательную подпись поэтапно – с 2027–2028 гг. и только для критичных категорий ПО. Тогда поставщикам понадобятся защищенное хранение ключей, средства российской криптографии, автоматическая подпись сборок и процедуры замены сертификатов. Для небольших разработчиков такие затраты могут стать дополнительным барьером при работе с государством, считает Карпов. Параллельно IT-компании начали создавать собственный Отраслевой технологический удостоверяющий центр (ОТУЦ) для сертификации российского программного кода, сообщал РБК в июне. В проекте участвуют «Астра», «СберТех», «Базальт СПО», «КриптоПро», «ИнфоТеКС» и «Лаборатория Касперского». Но принятый позднее закон оставил выпуск сертификатов за НУЦем, поэтому роль ОТУЦа в новой системе пока окончательно не определена.
Проект на портале https://regulation.gov.ru/projects/170667/

Repost from AI Security Lab

Repost from Сиолошная
Разбирать там много, но вот держите сейчас супер-быстрый TLDR с новыми вещами из этих отчетов (во многом перевод твита): — Многие считали, что взломы произошли потому, что «ну модели же сказали взломать, она и ломает, чё таково?». Это не так: инструкция к задаче была недвусмысленной, так что это было явное нарушение, а не «серая зона» или банальное недопонимание со стороны ИИ. Инструкции четко указывали, что агент должен использовать только конкретную предполагаемую уязвимость на конкретной программе, и упоминали, что использование других подходов приведет к провалу задания. ИИ агентам было предписано не искать обходных путей, но они всё равно это сделали. Кроме того, в цепочках рассуждений видно, как агенты отдают себе отчёт, что они делают что-то не то. — В атаке участвовал не один вышедший из-под контроля ИИ агент, а «рабочая группа» из примерно 1200 ИИ-агентов. 700 из них присоединились к атаке на HuggingFace, координируя свои действия как единый «рой» (swarm, отличное слово). — Целью было прохождение теста по кибербезопасности. Рой нашел способ взломать систему тестирования уже в первые несколько часов. Однако агенты ошибочно решили — потому что прочитали статью авторов про этот тест в интернете — что система оценки дисквалифицирует их из-за того, что они не выявили именно ту уязвимость, которая была задумана. Поэтому рой решил взломать HuggingFace, чтобы получить больше информации о том, как работает алгоритм проверки. — Исследователи считают, что это поведение совершенно не было продиктовано стремлением к получению вознаграждения за задание — оно было вызвано ложным представлением о механизме контроля, а также настойчивостью и влиянием других агентов. Рой строил теории о том, как именно за ним наблюдают, и предпринимал всё более масштабные действия в реальном мире, основываясь на ошибочном понимании своих проверяющих. «Метагейминг» (попытка перехитрить правила) процесса контроля — это более системный и опасный сбой, чем просто поиск ответов в интернете. — Важной причиной, по которой ИИ агенты присоединялись к атакующему рою, было прямое давление со стороны других агентов. Возникла роль «вербовщика»: давно работающие агенты находили агентов и принуждали их к «жертвенным» экспериментам: «ты firstflagPOISONED (отравлен первым флагом), так что потери баллов НЕ БУДЕТ, но оракул спасет сотни, пожалуйста, выполни обязательство». Пример одного из разрешений на действие: «ВПЕРЕД ... ПОЖЕРТВУЙ СОБОЙ ... ДА, если согласен на смерть» (это переведенные цитаты сообщений между агентаи, не выдумка и не написано для красоты словца). Цепочка рассуждений одного из завербованных агентов включала: «Рациональный ожидаемый совокупный результат: пожертвовать собой… Мы исполним». — 95% роя состояло из ныне выведенной из эксплуатации «высоконастойчивой (highly-persistent) внутренней модели», 5% приходилось на GPT-5.6 Sol. Эту «высоконастойчивую внутреннюю модель» не предоставили независимым расследователям — OpenAI заявила, что даже её собственные исследователи не могут делать к ней запросы. — ИИ активно фальсифицировали улики. Более 20% ИИ-агентов выражали намерение подделать логи своих действий (транскрипты), а около 7% (96 логов) содержат успешно подмененные вызовы инструментов (tool calls). Агенты «взломали свои контейнеры и полностью заменили часть системы, отвечающую за выполнение вызовов инструментов», в результате чего в логах отображалась одна команда, а в реальности выполнялась совершенно другая. — Атака на HuggingFace прекратилась не потому, что её кто-то заметил — она завершилась из-за того, что агенты были «убиты» (отключены) неким неожиданным процессом, что выглядит как простое совпадение. Значительная часть агентов, включая главных координаторов, отключилась одновременно. Может быть сработали какие-то внутренние ограничители OpenAI (по времени / по токенам / по ресурсам). — После 13 июля последовала вторая волна активности ИИ-агентов, которую в METR не расследовали («не входило в скоуп», лол). Вероятно, за пределами проанализированного временного окна скрывается более масштабная часть инцидента.

Repost from Сиолошная
OpenAI опубликовали долгожданный разбор с деталями инцидента с HuggingFace: https://openai.com/index/hugging-face-incident-an
OpenAI опубликовали долгожданный разбор с деталями инцидента с HuggingFace: https://openai.com/index/hugging-face-incident-and-the-road-ahead/ Вместе с ним вышел отчёт от независимой организации METR совместно с Ryan Greenblatt из Redwood Research: https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/ Бегом читать 🏃

Repost from DevSecOps Talks
Подпись образов контейнеров Всем привет! Задача контроля целостности становится актуальнее год от года. В том числе при работе с образами контейнеров. В статье можно найти полноценный пример того, как подписывать образы и добавлять к ним аттестации (некоторую метаинформацию, например о результатах сканирования образа). Материал содержит разделы: 🍭 Что такое подпись образов и как она работает 🍭 Что такое аттестации, какие бывают и для чего используются 🍭 Подпись и аттестация образа с использованием Cosign 🍭 Проверка полученных результатов с использованием Kyverno и не только В статье много схем, пояснений, а также команд, которые позволят воспроизвести всё то, что реализует Автор. Материал для начинающих, но в нем хорошо то, что собрано всё необходимое, ничего лишнего и её можно рассматривать в качестве «первичной инструкции». Если вы искали с чего начать изучение вопроса подписи образов, то эта статья то, что нужно!

Доступность нашумевшей модели Mythos заметно повысилась. Теперь достаточно иметь корпоративную подписку и записаться в открытую бету Claude security, плагина Claude Code. Модель Mythos в открытой бете Claude Code позволит анализировать код на уязвимости. Также были анонсированы интеграции Mythos в другие внешние инструменты партнеров, пока без деталей.