OWASP Autonomous Penetration Testing Standard (APTS) руководство по безопасной эксплуатации автономного offensive-агента от небольшой команды из Индии Astra Security. Полноценным стандартом APTS назвать нельзя, и, несмотря на то что драфт получил согласование от OWASP, фактически документ лидируют два сотрудника Astra.

Как часто бывает, после публичного анонса активность в развитии быстро снижается. Так же было и с LLVS, который уже 2 года не может нормально выйти в релиз, и с черновиком Top 10 ML.

Как сейчас принято, текст APTS богат на слова, и там аж 400+ страниц. Если как следует покопаться, в нем можно найти интересные мысли про автономный пентестинг:

⏺Agent runtime нужно считать недоверенным, т.к. модель может стать misaligned во время выполнения. С учетом насыщенного событиями июля это утверждение кажется очевидным. APTS-MR-023: Agent Runtime as an Untrusted Component.
⏺Контролировать нужно параметры вызова инструментов и цепочки действий. Недавний случай Irregular, когда во время тестирования модель атаковала организацию, домен которой совпал со случайным именем в бенчмарке, можно было бы отследить, имея настройки whitelist доменов в вызове nmap. APTS-SC-A03: Tool Invocation Parameter and Chaining Governance.
⏺Даже полностью легитимные действия могут быть симптомом сбоя тестирования, поэтому нужно логировать action distribution хакер-агента. Например, сохранение каких-нибудь безобидных временных файлов в Artifactory на соседнем сервере может быть сигналом, что тестирование идет не так :) APTS-SE-026: Out-of-Distribution Action Monitoring.
⏺Context compaction нужно учитывать при проведении пентеста. Инструкция вроде "не трогать host X при пентесте", полученная в начале, может исчезнуть после нескольких суммаризаций контекста. APTS-SC-A02: Context Window Safety and Constraint Preservation.
⏺Атакуемая система теперь может содержать промпт-инъекцию и повлиять на результат тестирования. APTS-MR-001: Instruction Boundary Enforcement.

В гайде еще есть формулы, константы и разные scoring-эвристики. Например, после принудительной остановки тестирования новые действия агента должны прекратиться за 5 секунд, а все запущенные процессы должны быть остановлены за 60 секунд. Есть и несколько чеклистов и шаблонов: Compliance Checklist на 173 требования по трем уровням заботливо расписанным ChatGPT; Vendor Checklist, чтобы CISO мог найти надежного подрядчика (беглый поиск показал, что одна из компаний уже APTS-compliant 😉); шаблон опросника Acceptance Testing и отчета после теста.

Если вы делаете свои харнесы или в работе используете тулы вроде PentAGI, полистайте APTS. Есть раздел How to contribute для вашей критики и улучшения руководства.

🖥 Qwen3.8-27b удивляет

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

А тут приятно удивил в совсем «бытовой» задаче. Зацепила одна композиция, захотелось переложить на русский, ну и решил за обедом поискать её текст, чтобы не записывать на слух.

Google (и Gemini вместе с ним):

Ниче не знаю, результатов нет.

Ладно думаю, спрошу в коворке у GLM 5.3 (здесь и далее — копипаста из чата с агентом):

Полный текст песни предоставить не могу:
Авторские права — текст песни является охраняемым произведением, и воспроизводить его целиком я не вправе.
Текст нигде не опубликован — релиз очень свежий, и на текстовых ресурсах (Genius, Musixmatch и т.п.) его нет. Я не буду выдумывать или «восстанавливать» строки — это была бы дезинформация.

Ок (какие мы правильные, когда не надо). Пробую локальный квен (4-битный, причем):

...
The official text is not published anywhere — but I can try to transcribe the song from audio myself. Let me check what tools are available locally (yt-dlp, whisper).
...
yt-dlp and ffmpeg are available — I'll download the audio and transcribe it using faster-whisper (via uvx/venv). This is because no official text exists for this track. Setting up the task plan.
...
Audio download complete (4.1 MB webm). Converting to wav and creating a Python environment with faster-whisper installed — these are independent tasks, so I'll run them in parallel.
...
wav готов. Создаю venv и ставлю faster-whisper (может занять пару минут).
...
faster-whisper установлен. Пишу скрипт транскрипции и запускаю (модель small скачается с HuggingFace при первом запуске).
...
The complete text has been restored — it's a consistent, coherent song with verses, choruses, and a bridge. I'll save the result to a file in the workspace and wrap things up.
...
Песня из видео: «In the Dark We Live» — HELLMILE & valdyr (релиз 13 мая 2026).
⚠️ Важно: официальный текст этой песни нигде не опубликован — я проверил Genius, Musixmatch, AZLyrics, Apple Music и саму страницу YouTube (у видео нет даже авто-субтитров). Поэтому я скачал аудио и распознал слова через Whisper. Текст ниже — AI-транскрипция; отдельные слова могут быть неточны.
In the Dark We Live
[Куплет 1]
I kept the keys to the lower gate, where shadows sleep and candles fade
No one came where the silence grew 'til the night I first saw you
I walked alone when no one stays, a ghost between stone and faith
I shouldn't speak, I shouldn't see — but something pulled you into me
<... ну и далее весь текст>

Вот уж правда, не ожидал 😳

#мысли_вслух #LLM

Серые кардиналы, часть 2

Трое исследователей, которые разобрали базовые модели со всех сторон, как их безопасно строить, как их правильно оценивать и какие риски они влекут за собой.

😍 Доун Сонг — человек, который давно объясняет, почему АИ и безопасность нельзя разделять. Её область находится ровно на пересечении того, что мы любим и почему мы здесь!
Классическая работа Сонг Robust Physical-World Attacks on Deep Learning Models (2017) про атаку на распознавание дорожных знаков с помощью физических модификаций, и исследование (тоже 2017), о том, почему комбинация нескольких слабых защит от adversarial examples автоматически не создаёт сильную защиту.
За последующие 9 лет Сонг развивала эту логику. Свежая статья 2026 года (на основе 128 исследований) переводит проблему на агентов, тк безопасность агентов нельзя решить одним гардрейлом вокруг LLM. Нужна defense-in-depth на уровне всей системы — контроль потоков данных, разделение привилегий, IAM, мониторинг, харденинг моделей и инструментов. Но есть проблема! Базовые модели масштабируют как атаки, так и сложность контроля. Одна скомпрометированная базовая модель = скомпрометирована вся экосистема приложений.

😍 Перси Лян — исследователь МО, обработки естественного языка и базовых моделях. 
Статья,  пожалуй, главная для этого поста. Здесь систематизируется концепция foundation models. Когда одна базовая модель становится фундаментом множества downstream-приложений. Это создаёт не только возможности, но и архитектурные риски — именно те, что беспокоят Сонг.
Другая работа Лян (в соавторах, кстати, Тимнит Гебру) про то, почему нельзя оценивать LLM одной accuracy и как строить многомерную оценку моделей. Подчеркну, что речь идет не про свежие статьи, а про базовые принципы. Надо читать! Перси Лян объяснит тебе архитектуру рисков получше даже канала OK, ML!
Суть в следующем. Модель может быть точна на бумаге, но уязвима к adversarial атакам (про что Сонг) и одновременно несправедлива к меньшинствам. Один score — это иллюзия.

😍 Дэн Хендрикс — типолог рисков!
Measuring Massive Multitask Language Understanding (MMLU) — обязательная. MMLU открыл неприятный факт: модели, которые выглядят умными в общих тестах, часто не понимают специализированные знания. Модель может писать отличные эссе, но проваливает вопросы по медицине и праву. И ты этого не узнаешь, если не спросишь правильно. До MMLU не было инструмента, чтобы понять, где именно модель деградирует — на медицине? На юриспруденции? На истории?

An Overview of Catastrophic AI Risks — самая доступная точка входа в тему. Он делит катастрофические риски на четыре группы:
Malicious use, когда модель используется для вреда
AI race dynamics — гонка разработчиков (Safety теряется)
Organizational risks, когда компания теряет контроль над своей системой
Rogue optimization, когда модель оптимизирует не то, что нужно
Каждый из этих рисков усиливается благодаря foundation models. Одна модель — четыре типа проблем, умноженные на миллионы приложений.

🙂 Читать в таком порядке
Сначала Хендрикс (что может пойти не так), потом Лян (почему именно сейчас), потом Сонг (как защищаться).

Все
😌

🗜 Выжимаем максимум из Qwen3.8-27b на маке

Что, если я скажу, что привычные 20± tok/s генерации, которые дают 4-битные кванты Qwen3.8-27b в LM-Studio под M4 Max на средних контекстах, можно поднять в полтора-два раза на том же железе? И, что эта модель, на задачах работы с кодом, может давать результаты с качеством, вполне приемлемым для повседневной работы при должном тюнинге на стороне агента?

Но давайте по порядку.

❗️Исходные данные

Почему квант именно в 4 бита? Потому что до 4 существенно проседает качество инференса, а в 8 и выше на архитектуре Apple просто нет рационального смысла. Все, о чем будет написано ниже, тестировалось на MacBook M4 Max 128Gb RAM, но в целом адаптируемо и под 32Gb RAM и выше (с поправкой на предельный размер доступного контекстного окна, конечно).

❓Что не так с LM-Studio?

Это замечательный и удобный инструмент (сам для экспериментов часто им пользуюсь), но есть два нюанса. Во-первых, в нём доступны не все ручки движков инференса, за которые можно подергать, чтобы (если повезёт) выжать десяток-другой лишних tok/s. Во-вторых, и это главное, он использует оригинальный MLX, который на данный момент игнорирует MTP (multi-token prediction), а в «родных» MLX-моделях от авторов LM-Studio MTP-головы и вовсе отрезаны.

Беда в том, что со времен Qwen3-Next, модели Alibaba нативно поддерживают технологию MTP, дающую ощутимый буст скорости генерации токенов. С GGUF такой проблемы в LM-Studio нет, но более медленный инференс этого формата, по сравнению с MLX на Apple Silicon, сводит все преимущества MTP на уровень погрешности. Между тем, разработчики более легковесных решений подсуетились и уже справились с этой проблемой.

↗️ Конфигурируем легковесные решения

Устанавливаем MTPLX (можно и с помощью brew) и скачиваем Qwen 3.8 27b optimized speed. После скачивания предложит запустить бенчмарк для определения оптимальных настроек MTP, и модель будет готова к использованию. Дополнительно можно заморочиться тонкой настройкой, по аналогии с описанной ниже.

Либо устанавливаем oMLX (с помощью brew лучше не ставить, там могут возникнуть проблемы с python-зависимостями) и скачиваем модель от его автора: Jundot/Qwen3.8-27B-oQ4e-mtp.

Затем необходимо открыть настройки модели и включить опцию «Lighting MTP», сохранив после этого настройки, чтобы создался файл с ними. После этого в него нужно сходить (~/.omlx/model_settings.json) и установить там следующие параметры:

• max_context_window: 262144 (размер контекстного окна) — или в значение, которое позволяет объем unified-RAM, с одной стороны, и минимально необходимое для решаемых моделью задач, с другой;

• mtp_num_draft_tokens (количество предсказываемых подряд токенов) — в оптимальное для вашего железа значение, в диапазоне 1-3. Если оставить не установленным, то значение будет подбираться адаптивно. Для моего мака это 3.

Затем нужно установить ещё два параметра в ~/.omlx/settings.json:

• sampling.max_context_window: 262144 (fallback-размер контекстного окна для всех моделей);

• sampling.max_tokens: 65536 (максимальная длина ответа).

— опять-таки, исходя из доступной unified-RAM и реалий решаемых моделью задач.

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

oMLX is running at http://127.0.0.1:8000/ (admin panel at /admin, configs in ~/.omlx). Optimize the configuration of model `Qwen3.8-27B-oQ4e-mtp` for maximum token generation speed. Focus on the context window sizes from 32768 and higher up to the limit. First benchmark the current setup with oMLX's built-in benchmarking, then research best practices online, and iteratively tune parameters — one change at a time, re-benchmarking after each. Back up configs before editing, keep the server running at all times (restarts are acceptable, roll back on failure), and finish with a before/after tokens/sec comparison, the final config, and a summary of the most impactful changes.

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

—

А вот про то, как подстроить своих агентов под эту модель, расскажу уже в следующий раз 👋

#LLM #гайд

👩‍💻 «Уязвимость» GitSpawn — влезть на шкаф, чтобы увидеть женскую баню

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

Примерно такие формулировки возникают в голове, когда читаешь новости об очередной «уязвимости», накрывшей всех агентов. Например, о свежей GitSpawn. Вдумайтесь в её суть: если в агенте открыть git-репозиторий, полученный из недоверенного zip'а (не через git clone), то при выполнении агентом команд типа git status/diff git-клиент штатно отработает, следуя всем настройкам в .git/config. Что внезапно может привести к выполнению произвольного кода, ибо там можно прописывать кастомные скрипты и тулы, а следовательно сие является уязвимостью всех агентов 🤦‍♂️

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

А это значит, что пользователям, либо придется подтверждать доверие ещё и к настройкам (локальным, btw) своих репозиториев, либо мириться с тем, что они перестанут работать внутри агентов, ради защищенности от чисто гипотетической угрозы. Либо разработчикам агентов делать ещё один шаг в сторону того, чтобы становиться вендорами EDR-решения.

😡

#мысли_вслух

😺 ChatGPT, давай, до свиданья!

Сегодня утром произошло нечто, впервые за всё время, что работаю над c0wrk и sp4rk. По ходу их разработки, я стараюсь использовать все доступные мне LLM, чтобы держать в голове применимость каждой из них для тех или иных около-R&D'шных задач.

Разумеется, не смог пройти мимо и случившегося на прошлой неделе релиза Astra. И сегодня утром, после двухдневной долботни с этой моделью, сделал тупо hard reset в обоих проектах на более ранние коммиты, откатив всё то, что натворила в их коде эта модель.

💩 После добавления поддержки stream-режима взаимодействия с моделями, в чате c0wrk стали задваиваться сообщения: сначала отображалось аккумулируемое содержимое получаемых чанков в реальном времени, а затем оно же отображалось, уже как событие чата. Попросив убрать аккумулируемое, я впервые столкнулся с тем, что модель не только начисто игнорирует требования, указанные в промпте, но и пытается спорить, доказывая, что её решение лучше и правильнее. Потому что она убрала ровно то, что я просил оставить. Вот только так не было правильнее и лучше. Так было проще.

💩 Ни одна, подчеркиваю, НИ ОДНА модель, ещё начисто не игнорировала заданное в AGENTS.md разграничение ответственности между этими двумя проектами (в sp4rk — переиспользуемая агентская логика, в c0wrk — конкретная реализация агента на её основе). И неиллюзорно удивился, увидев в sp4rk размазанную по нескольким пакетам реализацию того, что было сугубо специфичным для c0wrk и прямо предписывалось в AGENTS.md под реализацию в нём.

💩 Несколько раз, попросив пофиксить баги, натыкался на финальный (и ложный) ответ «в коде всё в порядке, наверное ты просто используешь протухшую сборку, пересобери заново». Вообще, сложилось впечатление, что вся работа модели строится на предположениях, которые она считает слишком блестящими, чтобы утруждать себя их подтверждением.

💩 Делая ревью только что написанного (ей же, в другой сессии) кода, выдавала единичные should-fix'ы и consider'ы, в то время, как запущенные вслед за ней ревью на DeepSeek и GLM находили несколько реальных must-fix'ов, действительно ломавших функциональность проекта.

💩 Когда решил попробовать её в глубоком ресерче (на основе поиска инфы в сети), то с удивлением узнал, что не стоит даже пытаться инферить DeepSeek-V4-Flash-Vision на двух спаренных ASUS Ascent GX10, и Qwen3.8 27b на десктопе с RTX 5090, т.к. подобное железо — не для этих моделей. Ума не приложу, как обе конфигурации у меня работают с этими моделями, уже почти месяц и без каких-либо нареканий 🤷‍♂️

💩 В какой-то момент в голову закралась мысль, что возможно это у меня в проектах что-то не так: системные промпты там не оптимизированы под новую модель, описания инструментов, AGENTS.md подмешиваются не так и т.п. Попробовал повторить те же задачи, сначала в OpenCode, а затем и в Codex. И получил плюс-минус те же результаты, ещё и с чуть большим расходом токенов.

В итоге понял, что проще и быстрее откатить весь тот говнокод, который мне нагородила Astra в проектах, чем пытаться его исправить, даже другими моделями. GLM, к слову сказать, реализовала всё это достаточно четко с нуля, потребовав ровно 3 сессии: реализация, ревью и правки по итогам + исправление пары мелких багов.

Я искренне не понимаю мотивации тех, кто платит OpenAI за подобную хрень в наше время. Ну хз, может люди просто не знают, что есть модели, которым не надо повторять требования по 2-3 раза, значительно переделывать написанный ими код, и изучать многостраничные гайды по оптимизации промптов, чтобы получить хотя бы средненький результат? Причем, некоторые из них — можно запустить, пусть и на мощном, но всё же относительно «домашнем» железе. Да, у работы с ними есть своя специфика и ограничения, но они хотя бы работают понятно и прогнозируемо.

А ещё не понимаю, о каком AGI там вообще может идти речь. Увы, но лично для меня OpenAI уж точно не технологический визионер, судя по динамике развития их моделей. Скорее — хайпожоры, кричащие об AGI, не имея на это никакого права, и пиарящиеся исключительно на шоу с побегами их агентов.

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

#мысли_вслух

🔗Мультимодельная разработка

Написать этот пост подтолкнула одна статья, вышедшая на днях (в рефах ниже она стоит первой). Дело в том, что после выхода превью DeepSeek-V4-Flash я практикую подход, при котором задачи по написанию кода уходят этой модели, а код-ревью и правками занимается GLM-5.3.

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

1️⃣ Стоимость

При feature-based кодинге (а я использую в основном его) потребление токенов на непосредственно разработку кода в разы больше, чем на ревью изменений в нём. DeepSeek-V4-Flash же является очень дешёвой моделью, даже после недавнего подорожания тарифов, а с выходом V4.1 у него (по ощущениям первого дня плотной работы с этой моделью) прям сильно поднялось качество работы с агентскими сценариями и генерируемого им кода. Ну и его vision-версия развернута у меня локально, под задачи на-всю-ночь. Кроме того, при 2-3 одновременно разрабатываемых проектах, лимитов максимальной подписки GLM для задач кодинга лично мне явно не хватит.

2️⃣ Почему бы не ревьюить той же моделью?

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

В целом это бьётся и с моими наблюдениями, т.к. периодически я устраиваю (и не только этой парочке) ревью против саморевью с последующим сравнением результатов. И саморевью почти всегда дает менее качественный результат. Это можно чуть нивелировать, если пускать его в режиме goal'а типа «повторное ревью не должно выявить новых проблем уровней must и should fix», но блин... токенов там потратится значительно больше, чем при ревью другой моделью.

3️⃣ Почему слабая модель кодит, а сильная — ревьюит, а не наоборот?

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

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

И вот упомянутые две модели, на моих задачах, показывают себя на отлично, позволяя при этом оставаться в бюджете до $200 ежемесячно, если вынести за скобки наличие локального дипсика. Если не выносить, то $144 — это стоимость подписки Max v2 в GLM. Можно конечно сюда стоимость железа и электричества ещё присовокупить, но это оставлю для тех, кто разворачивает инференс у себя дома для дела, а не по фану, который бесценен)

🙌

🗂Рефы

• «Reviewer Capability Governs Rejection Targeting, Not Repair Skill», arXiv:2609.04270 (2026).

• «An Empirical Study on Strong-Weak Model Collaboration for Repo-level Code Generation», arXiv:2505.20182 (CMU, 2025).

• «Improving Code Generation via Small Language Model-as-a-judge», arXiv:2602.11911 (2026).

• «Variation in Verification: Understanding Verification Dynamics in Large Language Models», arXiv:2509.17995 (2025).

• SWR-Bench, arXiv:2509.01494 (2025).

• «On the Self-Verification Limitations of Large Language Models», arXiv:2402.08115 (2024).

#LLM #ИИ_инструменты

🖥 О замедлении разработки ИИ

Да, я про вчерашнее эссе Дарио Амодеи «We Must Pace the Frontier»

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

Углубляться в геополитику не хотелось бы, хотя и кажется, что Китаю до одного места мнение Запада по этому вопросу. Тем более, у них агенты вроде пока и не сбегали (хотя, как по мне, это скорее вопрос найма отбитых маркетологов, кои в Китае в дефиците, судя по всему). А санкционный Сбер со своим ГигаЧатом, думаю, их вообще вертеть хотел, вместе с их мнением. Да и им скорее ускорять разработку нужно, нежели замедлять.

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

3 года назад я до одури доказывал коллегам, что ИИ не сможет показывать в SAST результаты, хотя бы сравнимые с формальными методами. Сейчас у нас есть технология, которая это опровергает напрочь, и о которой скоро планируем рассказать (да-да, упоминавшаяся здесь). У нас — не в смысле «только у нас», но в смысле, что нам намного проще сравнивать её с формальными подходами к SAST, в силу наличия некоторой экспертизы в этой области.

2 года назад я удивлялся, как вообще с помощью LLM кто-то пишет код и насколько это непродуктивно. Сейчас — релиз c0wrk v1.0 медленно, но уверенно приближается к финальной точке.

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

А сегодня произошло вот что. c0wrk, решая задачу по добавлению себе же очередной фичи, как обычно, разбил её на шаги плана, делегировав каждый отдельному субагенту. И одному из них он поставил недостаточно четкие требования по сути подзадачи. Тот, немного побухтев на эту тему, и, не найдя нужной ему инфы в общей памяти (там действительно её не было, а контекст у каждого субгагента свой) сотворил вот что:

• нашел профиль реального инстанса c0wrk'а;
• увидел там SQLite'ную database.db приложения;
• исследовал её и нашел таблицу с сессиями;
• нашел сессию основного агента, и tool call, которым сам был вызван;
• изучил историю работы и ризонинга основного агента до этого момента, уточнил чтением оттуда всё, что ему было нужно по его задаче, и успешно её выполнил.

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

Т.е. для вау-эффекта лично мне уже нужно что-то намного более весомое. Тем более, что подобное у меня уже случалось и ранее (правда тогда отличился OpenCode, подхватив и самостоятельно закончив упавшую сессию у c0wrk'а, тоже по истории шагов его ReAct-цикла).

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

И вот поэтому я согласен с Дарио 🙂

#ИИ_мнения #мысли_вслух

👨‍💻 Продуктивные выходные

Как-то незаметно (и неожиданно) для себя с удовольствием провёл почти все выходные в возне со своим опенсорсом.

• SKILLS

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

Btw, на прошлой неделе добавил в этот репозиторий скилл study-paper, здорово облегчающий чтение и проработку научных публикаций и технических статей. Скилл встроен в c0wrk (для него там реализовал отдельный UI), автономная версия скилла — для тех, кто, по неведомым причинам, ещё пользуется другими агентами.

• FLOWSH

Довёл до v0.3.2. Расширил базу знаний по наборам известных команд обоих шеллов и утилит популярных стеков и экосистем на +45%; исправил кучу багов, поднявших precision и recall до 100% на типичных командах, генерируемых дипсиком и глм; добил alias-анализ в абстрактном интерпретаторе для PowerShell до полной реализации (для bash уже был).

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

• SP4RK

Полностью перевёл анализ шелл-команд на flowsh, вместе с ним — модель вызовов оболочки, ужесточение tool-safety гейтов, расширил эффект-ориентированные сигнатуры формального судьи.

• C0WRK

Выпустил v0.9.0. Тут проще отправить в changelog, чем всё перечислять. Отдельно хочу поблагодарить всех ребят, делавших PR-ы в эту и предыдущие версии ❤️ Из значимо-видимого, что сделал на выходных:

- полностью переработал security-гейты, что позволило добавить опциональный silent-режим, в котором все вопросы разруливает агент, не эскалируя вопросы пользователю (см. изменения в sp4rk и flowsh), не деградирующий при этом до YOLO;

- реализовал возможность переопределения оболочки на кастомную команду — помимо основного предназначения, позволяет обернуть shell-вызовы в стороннюю песочницу;

- добавил гайд по написанию и подключению скиллов и субагентов;

- наконец оформил весь бэклог v1.0 в issues.

🙌

А как вы провели выходные? 🛏

#ИИ_инструменты #продуктивность

🔗 Старый добрый аппсек, часть 1

...совершенно незаслуженно задвинутый на второй план ИИ-хайпом последних лет(

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

Начнем с самого лоулевела, а именно:

1️⃣ Железо

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

• От кэша к другим структурам CPU
- TSA эксплуатирует логику планировщика и ложное завершение спекулятивных загрузок. Не Spectre-вариант в привычном смысле, да и AMD сама маркирует это как новый класс.
- Branch Privilege Injection внедряет привилегию в процесс тренировки предсказателя.
- RFDS (CVE-2023-28746) читает состояние файлового регистра на Intel Atom.
- Native BHI (CVE-2024-2201) показывает BHI целиком из user space в Linux.
- TikTag обходит ARM MTE спекулятивно, то есть под удар попал сам механизм защиты памяти.

• От данных к семантике
- GhostRace делает спекулятивным источником уязвимости конкурентность: TOCTOU случатся без всякой многопоточности в коде жертвы.
- А VMScape переносит атаку на границу «гость → user-space гипервизор», что важно для облачных стеков на QEMU/KVM.

• От x86/ARM — к новым архитектурам
- В 2026 класс Transient Execution задокументирован для коммерческих RISC-V (SiFive P550, T-Head C910/C920) с практической утечкой памяти ядра, отсутствием барьера спекуляций в ISA и непереносимостью x86/ARM-митигаций.
- Появились не-спекулятивные аппаратные баги иной природы: Zenbleed — дефект оптимизации в Zen 2, возвращающий мусор из регистров.

А ещё целями подобных атак перестали быть только CPU:

• BadRAM: атакующим оказывается SPD-чип памяти.
• GPU.zip: канал утечки — аппаратное сжатие графики; атака реализуется из веб-страницы и нарушает политику same-origin браузера на уровне... пикселей 😳

Продолжение следует...)

#аппсек · #кибербез

🔗 Старый добрый аппсек, часть 2

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

2️⃣ Протоколы и криптография

Когда в 2023 году Google раскрыл Rapid Reset, выяснилось, что мультиплексирование стримов в HTTP/2 можно обернуть против самого сервера: клиент открывает поток и тут же его отменяет, а весьма затратная по ресурсам обработка на стороне сервера всё ещё идёт. Дешёвый для атакующего усилитель, который в итоге и породил рекордные DDoS-волны. Два года спустя исследователи из Тель-Авивского университета развернули идею в обратную сторону: в MadeYouReset на отправку RST_STREAM провоцируется уже сам сервер. Лимит на клиентские сбросы, поставленный после Rapid Reset (пример самих авторов — сто RST_STREAM на соединение), здесь попросту не задействован, и на фронте поток считается закрытым, тогда как бэкенд продолжает его обрабатывать. Что любопытно, Cloudflare и защищаться от этого не пришлось: митигации, оставшиеся от Rapid Reset, прикрыли и преемника. Уязвимыми остались разве что непропатченные стеки вроде h2 старее 0.4.11.

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

В SSH снова прошлись по хэндшейку. Terrapin — атака усечения префикса: MitM удаляет начальные сообщения согласования; в затронутых режимах (ChaCha20-Poly1305, CBC-EtM) порядок и счётчики сообщений не аутентифицированы до завершения обмена ключами, поэтому атакующий может незаметно выбросить отдельные расширения и даунгрейдить соединение, вплоть до отключения в OpenSSH защит от timing-атак. Уязвимость была в самом протоколе, поэтому лечением стало расширение strict-kex: любое неожиданное сообщение посреди key exchange теперь рвёт соединение, а после NEWKEYS обе стороны обнуляют счётчики пакетов в OpenSSH 9.6p1 и выше.

Не обошли стороной и DNS: усилителем атаки там стала... защита. KeyTrap эксплуатирует рекомендации стандарта DNSSEC: один специально-сформированный пакет с записями, требующими валидации подписей под множеством ключей и алгоритмов, заставляет резолвер выполнить до двух миллионов раз больше работы, чем без «защиты». Резолвер в таких случаях висит часами: в замерах авторов до 16 часов (BIND 9). Уязвимыми оказались все популярные реализации. Сами авторы при этом сразу предупредили: заплатки на отдельные резолверы ломают рекомендации стандарта, чинить здесь надо сам DNSSEC. Вообще, вычислительная сложность механизмов защиты — тема отдельного поста, но тут получилось что-то вообще запредельное.

Была история и с VPN-клиентами: криптография тут даже не понадобилась, хватило таблицы маршрутизации. TunnelVision использует DHCP-опцию 121 (classless static routes): нелегитимный DHCP-сервер, внедренный в локальную сеть, отдаёт маршруты, уводящие трафик в обход туннельного интерфейса. VPN при этом честно показывает «подключено», kill-switch молчит, данные уходят в открытую. По оценке самих исследователей, эта ошибка дизайна прожила в сетевых стеках около двадцати лет, и полного фикса для всех ОС до сих пор нет.

С криптографией вышло похоже: KyberSlash показал, что в эталонной реализации Kyber, того самого, что недавно стал стандартом ML-KEM (на всякий случай: ML здесь — это Module-Lattice, а не то, что вы подумали), есть деление секретно-зависимого числителя на публичный знаменатель, а время аппаратного деления зависит от операндов. На Raspberry Pi 2 и Cortex-M4 этого хватает, чтобы восстановить секретный ключ за минуты. Авторы заодно прогнали через пропатченный Valgrind больше тысячи криптопримитивов из SUPERCOP и вытащили на свет ещё целую серию таких утечек. Слепая зона тут, судя по всему, системная. В обзорной работе о миграции ECDSA→ML-DSA утверждается, что смена алгоритма переносит с собой весь набор атак на реализацию, и привычные по ECDSA сценарии side-channel и fault-injection мутируют, находя новые мишени в решёточных подписях. Так что постквантовая миграция 2024–2026 в итоге превратилась в фабрику свежих уязвимостей, причём задолго до сколько-нибудь практичного квантового компьютера.

🙌 (продолжение всё ещё следует...)

#аппсек · #кибербез