🙃 Эй, чем сегодня займемся, Брэйн?

Чёт стало скучно. Этот бесконечный цикл: обсудить и поставить задачу агенту → провести ревью → объяснить агенту, почему он на этот раз тупой → проверить фиксы → обновить спеки → прогнать на CI → повторить с новой задачей 🫠

В общем, чтобы было веселее, сделал скилл, который... ну, тут наверное проще показать, чем объяснять 🙈

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

Сразу пять способов обойти PickleScan

Исследователи обнаружили сразу 5 уязвимостей, позволяющих создавать вредоносные pickle-файлы, которые успешно проходят проверку PickleScan как безопасные (тут по ссылке инструмент указан HF как официальный для скана pickle), а затем при десериализации выполняют произвольный код. Обычно мы про формат pickle 🥒 говорим скрипя зубами, а тут вообще его сканер попался! PickleScan используется при проверке моделей в ML-регистрах, CI/CD-пайплайнах и проектах, работающих с Python-моделями. Если он был единственным рубежом защиты, ранее проверенные модели стоит считать потенциально ненадежными и пересканировать.

Самая опасная — CVE-2026-56315 (CVSS 9.8). 🥒 Оказалось, что в блок-лист сканера не попали несколько модулей стандартной библиотеки Python, содержащих функции для запуска системных команд. Кроме того, найдены четыре независимых обхода через idlelib, torch.jit, numpy.f2py и profile (CVE-2025-71376, CVE-2025-71370, CVE-2025-71365, CVE-2025-71341).

Основная проблема в том, что PickleScan использует deny-list. Такой подход практически невозможно поддерживать в актуальном состоянии, так как достаточно пропустить одну новую функцию или нестандартный путь вызова, и 🍆 финита ля комедия - защита перестает работать.

По факту это далеко не первый раунд обходов PickleScan  — до этого уже были обходы от Sonatype (4 штуки, CVE-2025-1716/1889/1944/1945) и от JFrog (3 штуки, CVE-2025-10155/10156/10157), плюс отдельная история с CRC в ZIP-архивах.

🥒 Хороший пример того, почему в security критически важных инструментов allow-list значительно надежнее, чем бесконечное поддержание актуальности deny-list. Но даже allow-list для pickle — это полумера, тк сама механика __reduce__ слишком гибкая. 🤩 Поэтому в рекомендациях исследователей закономерно звучит совет переходить на safetensors/ONNX, где код просто негде исполнять (по ссылке в разделе best practices).
 
Все
🕺

❓ Являются ли CVE'хами ложно-отрицательные срабатывания SAST?

Хочу немного дополнить пересланный выше 👆пост, и немного порассуждать вокруг вопроса, волновавшего, лично меня, с самого начала упомянутой истории с байпассами PickleScan.

Дело в том, что назначение CVE на каждый вид байпасса в SAST-инструменте — несправедливо и категорически неадекватно, как в рамках текущей экосистемы CVE, так и с позиции здравого смысла.

CVE (Common Vulnerabilities and Exposures) — это идентификатор для конкретной, известной уязвимости в программном продукте, которая существует в коде и может быть эксплуатирована.

False Negative (FN) в SAST — это отсутствие события, уязвимость, которую не удалось обнаружить. Заводить CVE на «отсутствие сигнала» — это все равно что заводить уголовное дело на сигнализацию в магазине, которая не сработала на конкретного воришку. База данных MITRE по их же политике предназначена для «воришек», а не ограничений функциональности средств анализа.

В общем виде задача детектирования уязвимости эквивалентна проблеме остановки → является неразрешимой задачей. И множество FN в ЛЮБОМ анализаторе бесконечно. Поэтому любой SAST-движок — это всегда эвристический компромисс между фолзами обоих родов, подробно рассказывал об этом ранее.

Если заводить CVE на каждый FN от анализатора, то мы столкнемся с абсурдом: каждая реальная уязвимость в мире потенциально будет иметь множество CVE: один на саму уязвимость (непосредственно в коде), а остальные — на все SAST-инструменты, которые ее не нашли. Это сделает базу CVE бесконечной и бесполезной, так как она захламится мета-проблемами.

Важный нюанс здесь: кто принимает решения на основе SAST?

Если инженер видит, что SAST ничего не нашел, и на этом основании утверждает, что код безопасен — это процессная ошибка самого разработчика или секчемпа.

SAST — это инструмент снижения рисков, а не гарантия безопасности (в отличие, скажем, от формальной верификации, или доказательного SAST, о котором фантазировал недавно). Ожидать от эвристического анализатора, так или иначе работающего на поиск признаков уязвимости, 100% покрытия — по меньшей мере наивно (по большей — просто тупо).

Искажение принимаемых решений по безопасности из-за FN — это проблема культуры DevSecOps и системы компенсирующих мер (ручной код-ревью, динамический анализ DAST, пентесты). Перекладывать эту ответственность на вендора SAST путем заведения CVE — это попытка решить внутреннюю организационную проблему техническим костылем, не более того.

⚠ TL;DR: если заводите CVE на ложно-отрицательное срабатывание в SAST-инструменте, будьте готовы к тому, что после исправления, ложно-положительных, требующих рутинного триажа с вашей же стороны, в нём станет на порядок-другой больше. Потому что этот компромисс именно так и работает.

А ещё лучше — поправьте свои процессы DevSecOps 🙂 Это прям реально нужно, раз FN от анализатора в них сейчас равноценен CVE.

Разработчики 🆚 ресерчеры

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

Различие между ними изучено достаточно хорошо. Ещё в 1991 году профессор Стэнфорда Джеймс Марч описал дилемму «exploration–exploitation» Exploration — это поиск нового, эксперимент, риск и открытие. Exploitation — исполнение, оптимизация, доведение до совершенства известного. И это, как мне кажется, прям идеально укладывается на реалии R&D.

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

• Разработческий майндсет — exploitation: умение декомпозировать сложную проблему на выполнимые шаги, доводить гипотезные PoC'и до релиза, принимать архитектурные компромиссы и добиваться воспроизводимого качества.

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

Отличительные черты

• Исследовательский майндсет: толерантность к неопределённости, способность формулировать проверяемые гипотезы, понимать, чем они отличаются от фичей, и безжалостно их опровергать; навык быстрого входа в незнакомый домен, умение эффективно читать научную литературу и отделять сигнал от шума. Ключевой операционный скилл — мышление вне коробки: задавать вопросы, на которые ещё никто не пытался ответить, решать неразрешимые задачи, смотреть на систему снаружи, а не изнутри. Ключевой софт-скилл — безжалостность к опровержению. Исследователь должен быть готов к тому, что 9 из 10 не то, что гипотез — целых исследований, будут однажды прекращены или отправлены «под стол». Если у исследователя каждый результат его работы залетает в прод, это значит лишь то, что он ставит перед собой недостаточно амбициозные цели.

• Разработческий майндсет: системное мышление, умение смотреть на систему изнутри, с учетом всех причинно-следственных связей, допущений и tribal-knowledge; параноидальное внимание к edge-кейсам, дисциплина тестирования и документирования, навык оценки сроков и трудозатрат, способность принимать решения при неполноте данных и нести за них ответственность. Ключевой операционный скилл — декомпозиция задач, позволяющая получать понятные и прогнозируемые результаты в плане. Разработчик, ссылающийся на её отсутствие, сродни художнику, который жалуется, что ему дали чистый холст вместо «картинки по номерам». Ключевой софт-скилл — готовность к критике, как к способу стать лучше (ибо код-ревью и критикующие коллеги тут случаются чаще).

Как прокачивать

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

Разработческий майндсет формируется через участие в опенсорс-проектах с жёстким код-ревью, привычку доводить пет-проекты до состояния «может использоваться кем-то ещё», регулярное решение алгоритмических задач с ограничением по времени (да-да, олимпиады, Codeforces и LeetCode). Главное упражнение: взять чужой исследовательский прототип и превратить его в готовую к проду систему — с полной реализацией всех фичей, обозреваемостью, тестами, обработкой ошибок и документацией.

Ни один майндсет не правильнее и не ценнее другого. Исследователь без разработчика производит красивые, но бесполезные артефакты; разработчик без исследователя эффективно строит не то, что нужно бизнесу и пользователям. Подлинный инженер живёт в постоянном конфликте между exploration и exploitation и использует его как источник энергии, а не выбирает одну сторону и окапывается в ней. Инженер R&D — не должность, не диплом и даже не состояние души.

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

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

🖥 Скилл `code-review`

Казалось бы, зачем ещё один скилл для ревью изменений в коде? Но вот нет, существующие — то не покрывают логические ошибки, то полностью забивают на безопасность, то не дают рекомендаций по исправлению, и т.п.

В конце-концов, кто я такой, чтобы не следовать принципу NIH (Not Invented Here)? 🤓

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

Лежит здесь, агностичен относительно конкретных агентов и экосистем, предназначен для полноценного ревью изменений (локальных, в конкретных коммитах, ветках или PR/MR), помимо обычных проверок, покрывает также весь OWASP для веб и агентских приложений.

Пример реального отчета скину в комменты.

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

Крайне рекомендую к просмотру 🙂

🖼 Изображения с текстом ради экономии токенов: не всё так просто

На прошлой неделе буквально в каждом релевантном паблике проскочил проект pxpipe — тула, позволяющая экономить расход токенов за счет преобразования контекстного текста в изображения, при работе с VLM. Ещё дальше зашел Can Bölük (боюсь пытаться написать это по-русски) — автор кодинг-агента oh-my-pi. Это вообще мой кумир, кроме шуток и без сарказма. Подписки на обновы в его проекте в принципе достаточно, чтобы быть в курсе вообще всех инноваций, которым можно найти хоть какое-то применение в кодинг-агентах. Так вот он, примерно в одно время с автором pxpipe, вообще сделал этот подход одной из стратегий сжатия контекста (SnapCompact) в своём агенте.

Идея превращать текст в изображения перед отправкой в VLM звучит безусловно прикольно. Механика проста: текстовый токен — дискретная единица из словаря ~50K–200K, один токен в среднем кодирует ~2.5-3 символа для плотного контента (код, JSON). Визуальный токен — патч, скажем, в 28×28 пикселей в непрерывном пространстве эмбеддингов, и может принимать любое значение. Плотность — на порядок выше. По формуле Anthropic, изображение 1568×728 стоит ~1522 токена и вмещает ~28 000 символов — сжатие ~4.6× по входным токенам.

Ну, зашибись же? Вот... не совсем.

Коэффициент экономии 10× по входным токенам — действительно имеет место, но он относится к специализированной модели DeepSeek-OCR с кастомным энкодером, обученным именно на оптическое сжатие. Для VLM общего назначения (Claude, GPT) реальный выигрыш скромнее — 2–3×. pxpipe на реальном трафике Claude Code показал −68% входных токенов, а академическое исследование зафиксировало лишь ~2× без потери качества. SWE-bench Lite: 10/10 задач решены на обоих arms, стоимость $27 vs $53 (−49%) — но это лишь 10 задач, как-то маловато для статистической значимости.

О чём ещё постоянно забывают упомянуть хайп-посты на эту тему — это «налог» на декодирование. Чтение плотного изображения является вычислительно тяжёлой задачей: модель тратит лишние thinking-токены на распознавание. Для SnapCompact его автор провел тщательные замеры: output-токены +333%, thinking-токены +561%. При ценах Anthropic на Sonnet ($3/$15) один проход оказался на 28% дороже текста. Независимый эксперимент PageWatch подтвердил картину: GPT-5 экономит −40% prompt-токенов, но completion-токены выросли у всех моделей, съедая всю экономию. Выгода появляется только в очень длинных сессиях с переиспользованием KV-кэша.

Другой проблемой являются конфабуляции (эх, прочитал бы это старина Зигмунд): при ошибках чтения модель не признаётся в неуверенности, и выдаёт правдоподобные, но неверные значения. Аудит pxpipe: точное воспроизведение hex-строк — лишь 38%, с систематической путаницей глифов (0⇆O, 6⇆8, 5⇆S, camelCase→lowercase). Opus 4.8 набрал 0/15 на hex-recall и поэтому отключён в pxpipe по умолчанию. Из реальных примеров: модель «вспомнила» имя человека из истории чата — уверенно, но неверно. Fable 5 читает рендеры почти идеально: 100/100 на novel arithmetic, 98/98 на gist recall. GPT-5.6 тоже силён. При этом Opus 4.8 ошибается в ~7% случаев, а вот GPT-5.5 деградирует примерно вхлам на контексте в изображениях. Универсального решения нет — метод не модель-агностический.

Попутно выяснилось, что помимо дискриминации китайцев, Anthropic ещё и молча уменьшает изображения больше ~1.15 MP (downscale ~0.555×), но выставляет счёт за полные пиксели ↗️ Без коррекции геометрии (≤1568×728) экономия размывается, а ёмкость страницы падает с ~92 000 до ~28 000 символов — нужно в 3.3× больше изображений.

Отдельной болью является выбор подходящего шрифта для рендера текста в изображение. Ниже 35–40 px² на символ наступает обрыв: транскрипция падает с 0.79 до 0.02. Мельче — уже не дешевле, с учетом стоимости ошибок. Шрифт 4×6 даёт 102K символов на страницу, но модель читает лишь 2% — экономия токенов тут оборачивается полной потерей смысла (здравого, по крайней мере).

⚠ TL;DR: так что метод прикольный, идея заслуживает внимания, но... относиться к этому стоит, скорее, как ко временному багу тарификации, не более того.

В c0wrk, пожалуй, я это тянуть не буду 🙂

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

🧩 Принципы и паттерны безопасной разработки: DIP

Часть 4.

Принцип инверсии зависимостей (Dependency Inversion Principle, DIP) утверждает: модули верхнего уровня не должны зависеть от модулей нижнего уровня, оба должны зависеть от абстракций. При этом не абстракции должны зависеть от деталей, а детали — от абстракций.

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

💡 Пример

// С нарушением DIP
class DataBinder {
    void bind(Object target, Map<String,String> params) {
        for (PropertyDescriptor pd :
                Introspector.getBeanInfo(target.getClass())
                    .getPropertyDescriptors()) {
            if (params.containsKey(pd.getName()))
                pd.getWriteMethod().invoke(target, params.get(pd.getName()));
        }
    }
}

// С соблюдением DIP
interface BindablePropertyResolver {
    List<BindableProperty> resolve(Class<?> type);
}

class DataBinder {
    private final BindablePropertyResolver resolver;

    void bind(Object target, Map<String,String> params) {
        for (BindableProperty bp : resolver.resolve(target.getClass())) {
            if (params.containsKey(bp.name()) && bp.isSafe())
                bp.set(target, params.get(bp.name()));
        }
    }
}

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

Помимо архитектурного разделения, главным правилом остается биндинг входных данных строго к выделенным DTO (Data Transfer Objects), а не к доменным сущностям или объектам фреймворка. DTO содержит только явно разрешенные поля, что исключает динамический биндинг опасных свойств.

Нарушения DIP провоцируют:

• CWE-913: Improper Control of Dynamically-Managed Code Resources
• CWE-470: Use of Externally-Controlled Input to Select Classes or Code
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

🐛 Жизненное

CVE-2022-22965 — Spring Framework RCE, она же Spring4Shell (CVSS 9.8).

Механизм привязки параметров (data binding) в Spring MVC — высокоуровневый модуль, отвечающий за маппинг HTTP-параметров в свойства Java-объектов. Внутри он напрямую зависит от низкоуровневого Java Beans Introspection API (CachedIntrospectionResults → java.beans.Introspector), рекурсивно обходящего цепочки геттеров/сеттеров.

На JDK 8 существовал чёрный список: Spring блокировал доступ к class.classLoader. Но в JDK 9 у Class появился новый геттер — getModule(). Через него открылся обходной путь class.module.classLoader, не попавший в чёрный список. Цепочка:

class.module.classLoader.resources.context.parent.pipeline.first.*

позволяла модифицировать конфигурацию Tomcat AccessLogValve — атакующий менял путь, паттерн и суффикс лога, записывая на диск JSP-файл (web shell).

Нарушение DIP здесь в том, что data binding напрямую зависел от конкретного механизма интроспекции (низкоуровневая деталь), без абстракции, определяющей контракт: какие свойства разрешено связывать. Когда деталь (набор доступных PropertyDescriptor-ов) изменилась из-за развития JDK — поверхность атаки расширилась без единого изменения в коде самого Spring.

🔧 Как пофиксили

Spring не стал внедрять глобальный белый список (чтобы не сломать обратную совместимость), и добавил чёрный, на уровне интроспекции. Доступ к свойствам Class, classLoader и protectionDomain был полностью заблокирован, что разорвало опасную цепочку... до следующего витка развития JDK, видимо 😬

💻 Как насчет композиционных языков?

Оставим это на правах домашнего задания: подумать, как Rust поощряет DIP через трейты, а Go — делая упор на простоту, снижение шаблонного кода и неявные интерфейсы.

⚠ TL;DR: Если модуль верхнего уровня напрямую зависит от деталей реализации нижнего — любое изменение внизу может молча расширить поверхность атаки наверху. Инвертируйте зависимость: пусть высокоуровневый модуль определяет контракт допустимых данных, а низкоуровневый — реализует его. А на входе всегда используйте DTO.

#безопасность_кода #гайд

✨ sp4rk: SDK для разработки ИИ-агентов на Go

Выделил из c0wrk в отдельный проект sp4rk SDK, на котором он основан. Умеет практически* всё, что нужно для построения мультиагентных систем на Go, и предоставляет два API (можно смешивать):

• классический — для полного контроля над всеми компонентами и их конфигурацией;
• «текучий» (fluent) — для быстрого построения агентов из заготовленных блоков.

Например, игрушечный триажер тикетов для Github-репозитория, с MCP, сессионной памятью, DAG-планированием и рефлексией в случае проблем, во fluent-варианте выглядит так:

system := "You are a triage agent. Use the github tools, verify each result, then call finish with a short report."

task := "Find the 5 most recent open issues in v0lka/sp4rk with the `error-handling` label, summarize each in one line, and save the digest as a fact for the next step."

github := mcp.ServerEntry{
    Transport: "stdio",
    Command:   "npx",
    Args:      []string{"-y", "@modelcontextprotocol/server-github"},
    Env:       map[string]string{"GITHUB_PERSONAL_ACCESS_TOKEN": "${…}"},
}

result, err := sp4rk.NewF().
    Anthropic(os.Getenv("ANTHROPIC_API_KEY"), "claude-sonnet-5").
    MCPServer("github", github).
    MemoryTools().
    AutoApprove().
    MaxSteps(25).
    System(system).
    Task(context.Background(), task).
    Plan().
    Reflect().
    MaxRetries(2).
    Execute()

Больше примеров — есть в /examples и документации.

Ещё даже не бета (выйдет вместе с бетой c0wrk), но уже достаточно стабильный, чтобы пробовать.

* — практически, потому что пока не реализованы потоковые ответы LLM, и сейчас поддерживаются только синхронные. Это есть в планах, до релиза v1.

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

😸 Как улучшить работу агента с codebase-memory-mcp?

MCP codebase-memory-mcp — добротный инструментарий, позволяющий экономить тонны токенов на исследования кодовой базы и получать парой вызовов своих инструментов то, на что у агента ушли бы десятки [rip]grep, glob, read_file, etc.

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

Ситуацию можно исправить, если добавить в AGENTS.md проекта или агента (или в правила агента, или во что угодно, что гарантировано попадет в контекстное окно любой сессии) следующую подсказку:

## Codebase navigation via `codebase-memory-mcp` (if available)

If the `codebase-memory-mcp` MCP server is connected (e.g. its tools appear with an `[MCP]` prefix), prefer it for code discovery, call-graph tracing, and architecture questions instead of broad manual `grep`/`glob` sweeps. **Every project-scoped tool requires a project identifier.** Calling such a tool without the correct identifier returns an error of the form `project not found or not indexed` (with a hint listing the available projects).

### Project identifier

The identifier is derived from the repository's **absolute path**: replace every path separator (`/`) with `-` and drop the leading slash.

| Repository path                     | Project identifier                       |
| ----------------------------------- | ---------------------------------------- |
| `/path/to/repo`                     | `path-to-repo`                           |

`index_repository` accepts an optional `name` argument that overrides this derived identifier. **Do not set it** — it creates a separate project entry alongside the path-derived one and breaks the predictable identifier rule. Always let the identifier be derived from the path.

### Required workflow

1. **Verify the project is indexed** — call `list_projects` first (it takes no arguments). Compute the expected identifier from the repo path (rule above) and check it against the returned `projects[].name` list (or match by `root_path`).
2. **Index if absent** — if the project is missing, call `index_repository(repo_path=<absolute path>)` (omit `name`). Read the returned `project` field to confirm the actual identifier; it equals the path-derived form. Use `mode="fast"` for a quick pass, `"full"` when you need similarity/semantic edges.
3. **Pass the identifier to the tools** — supply it as the `project` argument to every project-scoped tool. Without it, the tool errors out and will not query the graph.

### Tools by purpose

- **Discover** — `search_graph` (BM25 + semantic + regex over functions/classes/routes), `search_code` (grep augmented by the call graph), `get_architecture` (packages, clusters, layers, hotspots).
- **Read code** — `get_code_snippet` (read a function/class by `qualified_name`; resolve it first via `search_graph`).
- **Trace relationships** — `trace_path` (callers/callees, data flow, cross-service hops), `query_graph` (raw Cypher for multi-hop/aggregate queries).
- **Change & impact** — `detect_changes` (diff vs a git ref + blast radius), `get_graph_schema` (node labels / edge types).
- **Index management** — `index_repository`, `index_status`, `list_projects`, `delete_project`, `ingest_traces` (runtime traces), `manage_adr` (Architecture Decision Records).

🙌

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