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

Порт пока закрывает не все сценарии. Самый заметный пробел связан с поддержкой джойстиков; также остаётся добавить поддержку пера и диалоговых окон.

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

Источники

• harmonyos: Port SDL3 to HarmonyOS/OpenHarmony. by icculus · Pull Request #16281 · libsdl-org/SDL · GitHub

Что ещё изменилось

MCP-сервер теперь раздаёт общий каталог навыков через путь /mcp. В поставку также добавили навык phoenix-error-analysis, а во внутрипроцессной диспетчеризации MCP-инструментов исправили передачу состояния жизненного цикла приложения.

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

Источники

• Release arize-phoenix: v20.11.0 · Arize-ai/phoenix · GitHub

Обновление затрагивает проекты, которые используют Metro для разработки и сборки. В релизе исправили Fast Refresh с ленивыми сегментированными бандлами, пропуск файлов, записанных в каталог во время его обхода FallbackWatcher, ошибки сокета при записи через HttpStore и обработку выражений с Platform.OS и Platform.select.

FallbackWatcher стал экономнее: потребление RSS при обходе файлов снизилось примерно на 34%, а пиковое использование heap — примерно на 41%. Также Metro отказался от зависимости image-size в пользу встроенных парсеров, чтобы устранить предупреждения CVE.

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

Источники

• Release v0.87.1 · react/metro · GitHub

Flatpak Builder — инструмент для разработчиков и сопровождающих Linux-приложений: он собирает их в пакеты формата Flatpak. Версия flatpak-builder 1.4.11 вышла 12 сентября. В ней полностью отключили Git-хуки при применении патчей. Изменение связано с уязвимостью CVE-2026-86320. Также разработчики исправили проблему GHSA-484h-v688-jq5j, из-за которой источник мог выйти за пределы base_dir в режиме песочницы.

Кроме того, flatpak-builder теперь раньше прерывает обработку некорректных контрольных сумм для архивов и файлов, проверяет наличие URL при разборе источников bzr и svn и пропускает уже перенесённые записи при миграции локалей.

Что делать

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

Источники

• Release 1.4.11 · flatpak/flatpak-builder · GitHub

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

Также команда отказалась от Swagger-компонентов в клиент-серверном режиме и заменила их реестром конечных точек на Go с поддержкой OpenAPI 3.2.1. В результате размер исполняемого файла уменьшился примерно на 4 МБ.

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

Релиз Crush 0.94.1 опубликован на GitHub.

Для программиста, который уже работает с агентами, это готовая замена самодельным файлам с инструкциями и длинным описаниям задачи в чате. Вместо «сделай мне функцию экспорта» агент получает конституцию проекта, спеку с пользовательскими историями, технический план и список задач в репозитории, и каждый шаг можно прочитать и поправить до того, как появится код. За год к базовой цепочке добавились команда сверки кода со спекой, расширения для багфикса и оценки идей, пресеты под стандарты команды и бандлы под роли. Spec Kit при этом не единственный репозиторий такого рода в топе GitHub: за ту же неделю звёзды собирали ещё десять проектов про агентов, от скиллов и надстроек над Claude Code и Codex до локального инференса и управления Blender; они разобраны во второй части.

• Spec Kit 1.0.0 вышел 21 августа 2026 года, текущий релиз 1.0.6 от 10 сентября; между ними шесть патч-релизов.
• Ставится через uv или с PyPI, командой specify init подключается к проекту под любой из более чем 30 агентов.
• Цепочка из шести слэш-команд: constitution, specify, plan, tasks, implement, converge; последняя сверяет код со спекой и дописывает недостающие задачи.
• Расширение bug ведёт исправление по шагам «оценить, починить, проверить», assess разбирает идею до решения «делать» или «не делать».
• Мейнтейнер пишет, что 1.0 больше не обещает стабильности API: ломающие изменения агент теперь переносит сам.
• Среди набравших звёзды за неделю: ponytail (135 тысяч, режет объём кода агента на 54% в замере автора), ECC (256 тысяч), skills (259 тысяч), humanizer (46 тысяч), archify (57 тысяч), HyperFrames, MiniMind, Magnitude, SGLang и blender-mcp.

Что такое Spec Kit и как он работает?

Spec Kit это утилита specify на Python плюс набор markdown-шаблонов и скриптов, которые она раскладывает в проект. После specify init в каталоге агента (например, .claude/ или .github/) появляются слэш-команды или скиллы с префиксом speckit, а в .specify/ лежат шаблоны документов. Дальше вся работа идёт внутри привычного агента.

Базовая цепочка описана в README репозитория и состоит из шести шагов. /speckit.constitution один раз на проект фиксирует принципы: стек, стиль, что запрещено. /speckit.specify превращает описание задачи в спеку с требованиями и пользовательскими историями, /speckit.plan пишет технический план под выбранный стек, /speckit.tasks режет план на задачи, /speckit.implement их выполняет. Замыкает цикл /speckit.converge: команда сравнивает кодовую базу со спекой, планом и задачами и дописывает в список то, что ещё не сделано. Шаги implement и converge повторяются, пока converge не сообщит, что всё сошлось.

Есть три необязательные команды. /speckit.clarify вытаскивает недосказанное из спеки вопросами, её рекомендуют запускать до плана. /speckit.analyze ищет расхождения между спекой, планом и задачами после tasks и до implement. /speckit.checklist генерирует чек-листы качества требований, в документации их называют «юнит-тестами для английского языка». Команда /speckit.taskstoissues, которая раскладывает задачи в GitHub Issues, в релизе 1.0.5 помечена как уходящая из ядра в отдельное расширение github-issues; пока она работает.

Что изменилось к версии 1.0?

Год назад Spec Kit был набором шаблонов под несколько команд и несколько агентов. К 1.0 вокруг ядра выросла система настройки из четырёх слоёв. Внизу ядро с встроенными командами и шаблонами, выше расширения, которые добавляют новые команды, ещё выше пресеты, которые переписывают шаблоны ядра и расширений, а на самом верху локальные правки конкретного проекта в .specify/templates/overrides/. Шаблоны разрешаются во время выполнения сверху вниз, побеждает первое совпадение.

Два расширения идут в комплекте и включаются по желанию. specify extension add bug добавляет цепочку из трёх команд для исправления ошибок: assess проверяет диагноз по отчёту, fix чинит именно найденную причину, test подтверждает, что исходный симптом исчез. Авторы объясняют это тем, что агент, который прыгает от баг-репорта сразу к патчу, часто чинит не то. Расширение assess работает ещё до спеки: intake, research, define, shape, decide, на выходе документированное решение «делать», «нужны уточнения» или «не делать». Идею с решением «делать» можно передать в /speckit.specify.

Пресеты ставятся командой specify preset add и меняют форму, а не набор возможностей: например, требуют в спеке трассируемость под регуляторику, добавляют обязательный этап проверки безопасности в план, переставляют задачи так, чтобы тесты шли первыми, или переводят весь процесс на другой язык. Бандлы собирают расширения, пресеты, шаги и рабочие процессы в один версионированный набор под роль: продакт-менеджер, аналитик, исследователь безопасности, разработчик. Ставится бандл одной командой specify bundle install, каталог бандлов у проекта свой, поверх пользовательского и встроенного. В релиз-нотах 1.0.x рядом с исправлениями регулярно идут обновления расширений сообщества, например Jira Mirror в 1.0.2, и правки в загрузчике бандлов.

Список агентов вырос до более чем 30. Для части из них, включая Claude Code, Codex CLI, Copilot и Devin, команды ставятся как скиллы, а не как файлы промптов, и вызываются как /speckit-specify или $speckit-specify, в зависимости от агента. Для остальных остаётся режим слэш-команд; переключатель --integration-options="--skills" есть у тех, кто поддерживает оба.

Почему 1.0 больше ничего не обещает?

Ведущий мейнтейнер проекта в записи к годовщине прямо говорит, что единица в номере версии здесь только число. Раньше мажорная версия была страховкой от стоимости изменений: ломающее изменение означало ручной обход всех мест вызова по гайду миграции, и семантическое версионирование превращало эту стоимость в сигнал. Теперь, по его словам, адаптация к ломающему изменению это одно предложение агенту, который правит места вызова быстрее, чем автор успевает описать их в changelog. Поэтому 1.0.0 у Spec Kit значит «хорошее место, чтобы начать», а не обещание замороженной формы. Это заявление проекта о себе, и для команд, которые встраивают Spec Kit в CI и внутренние инструменты, оно означает, что пинить версию всё равно придётся: за три недели после 1.0.0 вышло шесть патч-релизов.

Как установить и с чего начать?

В README рекомендуют менеджер uv, альтернатива pipx. Установка идёт с привязкой к тегу релиза, тег с ведущей буквой v, либо из PyPI, где пакет specify-cli обновлён до 1.0.6. Проверить, не вышла ли новая версия, можно командой specify self check.

Ключ --integration принимает имя агента из списка интеграций, например copilot, claude, codex, cursor-agent или gemini; полный перечень выдаёт specify integration list. Дальше запускается сам агент в каталоге проекта, и цепочка начинается с /speckit.constitution.

Кому это не нужно?

Spec Kit не единственный инструмент такого рода. Kiro от AWS делает то же самое внутри собственной IDE на базе VS Code, у Tessl это CLI и MCP-сервер к разным ассистентам, а сам фреймворк на момент разбора был в закрытой бете; в разборе трёх подходов на сайте Мартина Фаулера Spec Kit выделяют как самый агентонезависимый: это markdown и скрипты в репозитории, которые легко править. Обратная сторона та же: спека, план и задачи это документы, которые кто-то должен читать, и для правки в одну функцию цепочка из шести команд избыточна. Авторы и сами пишут в README, что не каждое изменение проходит полный цикл: небольшие исправления идут обычным путём через issue, pull request, ревью и тесты.

Какие ещё репозитории про ИИ-агентов набирали звёзды на этой неделе?

Подборку из десяти репозиториев, которые «за неделю разом собрали звёзды», опубликовал 10 сентября японский аккаунт So AInsight; прирост за неделю там не приведён, поэтому ниже суммарное число звёзд на 11 сентября по данным GitHub. Половина списка про то же, что и Spec Kit: как заставить агента работать по процессу, а не по настроению; остальное про инференс, обучение и управление другими программами.

1. skills, 259 тысяч звёзд. Скиллы Мэтта Покока, автора Total TypeScript, из его рабочего каталога .agents: небольшие, составные, под любую модель. В README автор прямо противопоставляет их Spec Kit, GSD и BMAD: те, по его словам, забирают процесс себе и делают ошибки в нём трудноразрешимыми.
2. ECC, 256 тысяч. Надстройка над Claude Code, Codex, OpenCode и Cursor с циклом «план, тест, реализация, ревью из свежего контекста, проверка, память, улучшение». Репозиторий под MIT, у автора есть платная версия ECC Pro как GitHub App для приватных репозиториев от $19 за место в месяц.
3. ponytail, 135 тысяч. Скилл, который заставляет агента думать «как самый ленивый сеньор»: перед кодом пройти лестницу из семи вопросов, от «нужно ли это вообще» до «есть ли это в стандартной библиотеке». Автор замерил на Claude Code и репозитории full-stack-fastapi-template по 12 тикетам: минус 54% строк, минус 22% токенов, минус 20% стоимости против агента без скилла; ранние цифры «на 80–94% меньше кода» он сам признал завышенными из-за некорректной базы.
4. archify, 57 тысяч. Скилл для Cursor, Claude Code, Codex CLI и OpenCode: агент описывает систему типизированным JSON, Node.js-компилятор превращает его в самодостаточный HTML с интерактивной схемой архитектуры, последовательности или потока данных, экспорт в PNG, SVG и WebM. Умеет сравнивать два снимка архитектуры до и после изменения.
5. humanizer, 46 тысяч. Скилл на чистом markdown, который переписывает текст агента так, чтобы в нём не было характерных следов машинного письма, без изменения смысла; ставится через npx skills add blader/humanizer или как плагин Claude Code.
6. HyperFrames, 49 тысяч. Проект HeyGen: пишешь HTML, получаешь видео. Рассчитан на агентов, которым нужно генерировать ролики с диаграммами и озвучкой без съёмки; TypeScript, Apache 2.0, Node 22 и новее.
7. MiniMind, 61 тысяча. Учебный проект: обучить языковую модель на 64 млн параметров с нуля на чистом PyTorch. Заявленные «2 часа» и «3 юаня» это оценка автора для одного прохода предобучения и дообучения минимальной версии на одной RTX 3090 и аренда GPU на это время; в репозитории полная цепочка от предобучения до DPO, GRPO и агентного RL, плюс версии с картинками и диффузией.
8. Magnitude, 4 тысячи. Локальный движок инференса: профилирует машину (Mac, NVIDIA, AMD или только CPU), подбирает подходящие модели, скачивает, настраивает и запускает их. Единственный проект списка с числом звёзд в тысячах, а не десятках тысяч.
9. SGLang, 36 тысяч. Зрелый фреймворк раздачи больших языковых и мультимодальных моделей под нагрузкой, существует с января 2024 года; в список попал, судя по всему, из-за очередного всплеска интереса, а не как новинка.
10. blender-mcp, 28 тысяч. MCP-сервер и аддон, через которые любая модель управляет Blender: создание сцен, моделирование и расстановка объектов по текстовому запросу. Сторонний проект, к Blender Foundation отношения не имеет, о чём README предупреждает отдельно.

Общий знаменатель списка тот же, что у Spec Kit 1.0: скиллы и надстройки, которые фиксируют процесс работы агента в репозитории, стали отдельной категорией инструментов, и у неё уже есть внутренняя полемика. Spec Kit и ECC предлагают полный цикл, skills и ponytail дают отдельные небольшие правила, которые сочетаются с чем угодно. Что выбирать, зависит от размера задачи: для мелких правок цепочка из шести команд избыточна, для новой функции с несколькими файлами спека и план окупаются тем, что их можно прочитать до кода.

Что смотреть дальше у Spec Kit: вынос /speckit.taskstoissues в расширение github-issues и следующие патч-релизы: между 1.0.1 и 1.0.6 паузы были от нескольких часов до десяти дней. Раздел экспериментальных целей из README никуда не делся, сроков по 1.1 или 2.0 GitHub не называет.

Источники: GitHub: репозиторий github/spec-kit, Релиз Spec Kit v1.0.0, Релиз Spec Kit v1.0.6, Manorrock: Spec Kit Turns One — and Ships 1.0.0, Документация: поддерживаемые агенты, Martin Fowler: Understanding Spec-Driven Development: Kiro, Spec-Kit, and Tessl, So AInsight в X: десять ИИ-инструментов, собравших звёзды на GitHub за неделю, GitHub: mattpocock/skills, GitHub: affaan-m/ECC, GitHub: DietrichGebert/ponytail, GitHub: tt-a1i/archify, GitHub: blader/humanizer, GitHub: heygen-com/hyperframes, GitHub: jingyaogong/minimind, GitHub: magnitudedev/magnitude, GitHub: sgl-project/sglang, GitHub: ahujasid/blender-mcp

Изображение на обложке: Логотип: GitHub

Для команд, которые пускают агента в репозиторий с .env, приватными схемами и внутренними документами, это способ формально закрыть ему доступ. Но по документации GitHub у механизма есть заметные дыры: в VS Code режимы Edit и Agent исключения пока не поддерживают, симлинки и репозитории на удалённых файловых системах не покрываются, а семантическая информация из IDE (типы, определения по наведению, свойства сборки) может просочиться в контекст даже для исключённого файла.

• Content exclusions стали GA для Copilot app и Copilot CLI; сайт GitHub и GitHub Mobile остаются в public preview.
• Политику настраивают администраторы репозитория, владельцы организации и enterprise; планы Copilot Business и Enterprise.
• Исключённые файлы не участвуют в inline-подсказках, не влияют на подсказки в других файлах, не попадают в ответы чата и не проверяются Copilot code review.
• Не покрыты: режимы Edit и Agent в VS Code, симлинки, репозитории на удалённых файловых системах; возможна утечка через семантику IDE.
• Клиент передаёт GitHub URL текущего репозитория, чтобы получить политику; GitHub заявляет, что эти URL не логируются.

Как работает исключение и что оно гарантирует

Механизм описан в документации GitHub: администратор задаёт пути и маски файлов на уровне репозитория, организации или enterprise. Клиент Copilot при запуске отправляет на GitHub URL текущего репозитория и получает применимую политику; по заявлению GitHub, эти URL не логируются. Дальше клиент обязан не показывать содержимое исключённых файлов модели: ни для автодополнения внутри них, ни как контекст для подсказок в соседних файлах, ни в ответах чата, ни в автоматическом ревью.

Слово «обязан» здесь важно. Это политика на стороне клиента, а не криптографическая изоляция: GA-статус означает, что GitHub заявляет поддержку в приложении и CLI и берёт на себя ответственность за её работу. До 2 сентября правила действовали в части IDE-сценариев и в code review, а для app и CLI были в предварительном статусе.

Где исключения не срабатывают

• VS Code: режимы Edit и Agent пока не поддерживают content exclusion. Именно в агентном режиме модель читает файлы активнее всего.
• Симлинки: если исключённый файл доступен по символической ссылке под другим путём, политика его не закроет.
• Удалённые файловые системы: репозитории на сетевых дисках и в remote-окружениях не покрываются.
• Семантика IDE: языковой сервер может отдать типы, hover-определения и свойства сборки из исключённого файла, и они попадут в контекст.

Практический вывод: исключение файлов снижает риск случайной утечки секрета в подсказку, но не заменяет хранение секретов вне репозитория. Файл .env с ключами в Git был плохой идеей и до Copilot; агент лишь делает цену ошибки заметнее. Как это выглядит на практике, показал недавний инцидент METR с украденным API-ключом.

Что настроить сегодня

1. В настройках репозитория, организации или enterprise добавить в исключения .env*, каталоги с ключами и сертификатами, приватные схемы данных и внутренние документы.
2. Проверить каждую поверхность отдельно: Copilot app, CLI, IDE, code review. Для VS Code помнить, что Edit и Agent исключения игнорируют.
3. Найти симлинки на чувствительные файлы (find . -type l) и репозитории на сетевых дисках: там политика не действует.
4. Убедиться, что тариф Business или Enterprise: на индивидуальных планах content exclusion недоступен.

Доступность оплаты планов Business и Enterprise из России GitHub в changelog не обсуждает. В тот же день GitHub выпустила и другое изменение для администраторов: managed settings теперь позволяют назначать командам любую модель Copilot по умолчанию с возможностью переопределения. Про то, что Copilot научился ставить approve на pull request, мы писали накануне; в связке с исключениями это означает, что ревьюер-агент может не видеть части файлов, которые одобряет.

Источники: GitHub Changelog: Content exclusions generally available in Copilot app and CLI, GitHub Docs: Content exclusion for GitHub Copilot

Изображение на обложке: GitHub

Для тех, кто пишет багрепорты из скриптов, собирает отчёты в CI или просто не хочет переключаться в браузер ради одной картинки, это закрывает давний разрыв между «вот команда, которая падает» и «вот как это выглядит». Единственное серьёзное исключение: GitHub Enterprise Server в этом релизе не поддерживается.

• Флаг --attach работает в gh issue create, edit, comment и в gh pr create, edit, comment; его можно повторять несколько раз.
• Форматы: PNG, JPEG, GIF, WebP, SVG для картинок и MP4, MOV, WebM для видео.
• Лимит на изображение и GIF 10 МБ; видео до 10 МБ на бесплатном плане и до 100 МБ на платных.
• Нужен OAuth-токен от gh auth login или classic personal access token и право записи в репозиторий.
• GitHub Enterprise Server не поддерживается; нужна версия gh 2.99.0.

Как это выглядит в командной строке

Минимальный пример из changelog: приложить скриншот к комментарию в issue.

Флаг повторяемый, поэтому к одному issue можно приложить сразу несколько файлов, указав --attach для каждого. Alt-текст задаётся после пути через решётку: --attach './login.png#The login error state'. Это тот же alt, который потом увидят читатели со скринридером, так что писать его стоит осмысленно.

Самая полезная деталь спрятана в обработке Markdown. Если в тексте issue или комментария уже стоит локальная ссылка вида , CLI перепишет её на адрес загруженного файла. Вложения, на которые в тексте ссылок нет, добавляются в конец Markdown. Значит, можно писать описание бага в редакторе с относительными путями к картинкам, а потом одной командой отправить и текст, и файлы.

Ограничения, о которых стоит знать заранее

Для загрузки нужен либо OAuth-токен, полученный через gh auth login, либо classic personal access token; другие типы токенов в changelog не упомянуты, и это стоит учитывать в CI. Кроме того, требуется право записи в репозиторий: приложить файл к чужому issue в проекте, где вы не участник, не получится, даже если оставлять комментарии там можно.

Лимиты размеров: 10 МБ для изображений и GIF, для видео 10 МБ на Free и 100 МБ на платных планах. GitHub Enterprise Server новую возможность не получил; сроки для самостоятельно развёрнутых инсталляций в публикации не названы.

Что ещё не сказано: как ведёт себя команда при превышении лимита, поддерживает ли она загрузку по URL вместо локального файла и когда флаг доберётся до gh release. Судя по тексту changelog, речь только об issue, pull request и комментариях.

Где это пригодится

• Тестовые пайплайны: упавший end-to-end тест прикладывает скриншот или запись браузера к автоматически созданному issue.
• Ревью интерфейсов: gh pr comment --attach с записью экрана вместо описания «нажмите сюда, потом сюда».
• Скрипты отчётов: график из matplotlib или диаграмма сборки уходит в комментарий к pull request без промежуточного хостинга.

Обновиться можно штатным способом: через менеджер пакетов, которым gh ставился, или скачав релиз 2.99.0 с GitHub.

Редакция проверит, появится ли поддержка Enterprise Server в следующих релизах gh.

Источник: Changelog GitHub: GitHub CLI media in issues, pull requests, and comments

Изображение на обложке: GitHub

Функция вышла в public preview для тарифов Copilot Pro, Pro+, Max, Business и Enterprise. По умолчанию она выключена: администраторам придётся включить её явно, и сделать это можно на уровне enterprise, организации или отдельного репозитория. GitHub при этом ничего не говорит о региональной доступности, поэтому для аккаунтов из России действуют те же условия, что и у самого Copilot: нужна платная подписка, а вопрос её оплаты публикация не затрагивает.

• Каждый обзор Copilot теперь содержит вердикт «готов к одобрению или нет»; сам по себе вердикт в merge-требования не засчитывается.
• Если администратор включит настройку, Copilot будет ставить настоящий approve, и он считается наравне с одобрением человека.
• Настройка выключена по умолчанию; управляется на уровне enterprise, организации и репозитория.
• В репозитории можно ограничить approve списком путей: за пределами списка Copilot только комментирует.
• Новый коммит после approve автоматически снимает одобрение, как и у обычных ревьюеров.

Вердикт и approve теперь разные вещи

До этого релиза Copilot code review оставлял замечания и общий комментарий, а решение «можно ли мержить» оставалось за людьми. Теперь в каждом обзоре появился approval assessment: Copilot пишет, считает ли он pull request готовым к одобрению. GitHub прямо оговаривает, что «одна только оценка готовности не засчитывается в merge-требования» (здесь и далее перевод редакции). Это информационный сигнал, и он появляется у всех, кто пользуется Copilot code review, без дополнительных настроек.

Второй уровень включается отдельно. Если администратор разрешил Copilot одобрять, то при положительной оценке Copilot отправляет обычный approve через штатный механизм ревью. Такой approve участвует в правилах защиты веток: если branch protection требует одно одобрение, оно будет выполнено. По нашей оценке, именно эта деталь и есть новость: Copilot code review теперь формально закрывает требование ревью.

Механика отзыва одобрения не изменилась. Как и у ревьюера-человека, approve Copilot снимается, когда в ветку приходит новый коммит. Поэтому сценарий «получил одобрение от бота, потом дописал что угодно и смержил» не работает: после каждого пуша Copilot будет пересматривать изменения заново.

Три уровня контроля и фильтр по путям

GitHub построил включение по каскаду. Администратор enterprise может запретить функцию всем организациям сразу. Администратор организации включает её выборочно для репозиториев. Администратор репозитория включает или выключает approve у себя и, что важнее, может задать список путей, к которым Copilot имеет право применять approve.

На практике это значит, что разумная конфигурация выглядит не как «Copilot одобряет всё», а как «Copilot одобряет документацию, тесты и локализацию, а к src/auth/ и инфраструктурному коду не прикасается». Если pull request задевает файлы вне списка, Copilot по-прежнему оставит замечания, но approve не поставит.

Что GitHub не сказал: по каким критериям Copilot принимает решение о готовности, как часто он ошибается и есть ли у компании собственные замеры доли ложных одобрений. Публикация описывает только механику и настройки. Пока функция в public preview, GitHub оставляет за собой право менять её поведение.

Что проверить у себя сегодня

1. Убедиться, что в организации функция по-прежнему выключена: она отключена по умолчанию, но проверить настройки Copilot в разделе организации стоит, особенно если администраторов несколько.
2. Если approve от Copilot нужен, включать его точечно: сначала в репозиториях без критичного кода и с фильтром по путям, а не на всю организацию.
3. Пересмотреть правила защиты веток. Если merge требует ровно одно одобрение и Copilot попадает в число допустимых ревьюеров, стоит поднять требование до двух или добавить в CODEOWNERS обязательного человека для чувствительных каталогов.
4. Договориться в команде, что approve Copilot не заменяет ревью человека для изменений в аутентификации, платежах, миграциях и CI-конфигурации.

Approve от Copilot снимается новым коммитом: как только в ветку приходит изменение, одобрение отзывается, и Copilot пересматривает pull request заново. Про истечение одобрения по времени GitHub ничего не пишет.

Почему это шаг дальше, чем автообзор

Автоматический обзор Copilot существует давно, и у многих команд он включён на каждый pull request. Но роль у него была совещательная: комментарии можно проигнорировать, а merge всё равно требовал одобрения человека. С 1 сентября GitHub позволяет передать ИИ часть формальной ответственности за merge-gate. Для маленьких команд и соло-проектов это удобно: правило «одно одобрение» перестаёт блокировать работу, когда второго человека просто нет. Для больших организаций это ещё один пункт в аудите доступов.

Следить стоит за двумя вещами: когда функция выйдет из public preview и появятся ли у GitHub публичные данные о точности вердиктов. Редакция проверит, изменятся ли значения по умолчанию к стабильному релизу.

Источник: Changelog GitHub: Copilot code review can now approve pull requests

Изображение на обложке: GitHub

В AutoGPT, где на момент интервью у репозитория было свыше 180 тысяч звёзд и 150 открытых PR, большая часть этих PR создана агентами: Copilot, OpenClaw, собственными инструментами команды и сторонними ботами. Большинство мейнтенеров реагируют просто: закрыть дверь, отключить пулреквесты, не тратить силы на чужой LLM-вывод. Но у Николаса Тиндла, одного из основателей ИИ-инженерии в AutoGPT, другой взгляд: «По сути, кто-то другой платит за ваши вычислительные ресурсы. Если контрибьютор хочет потратить свои токены на улучшение вашего проекта — пусть тратит. Главное, сделать так, чтобы единственный путь внутрь проходил через ваши правила.»

ИИ-first контрибьютор — это разработчик, который отдаёт написание кода, тестов или документации генеративной модели, либо самоходный агент, который клонирует репозиторий, ищет issue, пишет код и открывает PR. Для мейнтенера результат одинаков: в репозиторий приходит поток кода, который часто не учитывает контекст проекта и требует ревью.

Агенты не ищут документацию сами — они читают то, что лежит рядом с кодом. AGENTS.md и CLAUDE.md в нужных директориях работают лучше, чем вики.

Пропускные ворота должны быть автоматическими и однозначными: шаблон PR, тест-план, CI как стена, CLA как детектор человека.

Не все ворота стоит оставлять включёнными: автоматические комментарии об ошибках CI быстро превращаются в шум.

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

Мейнтенер всё ещё решает, что принимать: закрыть PR и переписать самому — тоже валидный выбор.

Проблема не в документации, а в её обнаружении

Первое, что пробовала сделать AutoGPT, — улучшить CONTRIBUTING.md, написать подробную вики и обновить гайды. Это не сработало. Дело в том, что агенты не ходят по ссылкам и не ищут документацию в разделах репозитория. Они смотрят на то, что находится в текущей директории и на один-два уровня выше. Если инструкция не лежит там, где агент работает, для него её не существует.

Сначала команда добавила файлы CLAUDE.md, потому что Claude открывал пулреквесты без достаточного контекста о репозитории. Потом выяснилось, что Copilot и Codex эти файлы игнорируют — они не Claude. Решением стал централизованный AGENTS.md, на который указывают все специфичные для модели файлы.

Важный нюанс: AGENTS.md действует внутри директории. Если агент работает в backend/, он видит правила для бэкенда. Если динамически загружается навык, связанный с фронтендом, агент может не знать, в какой директории искать инструкции — и навык сам должен ему подсказать путь. Поэтому в AutoGPT файл AGENTS.md лежит рядом с кодом, который он регулирует.

Навык — что это?
В терминологии агентских инструкций навык — это файл с описанием, по которому агент решает, когда загружать полный набор правил. Агент сканирует описания заранее и подключает нужный навык, когда задача совпадает. Например: «напиши Storybook-тест, если компонент лежит в этих папках».

Фронтенд-инженер AutoGPT устал от одного и того же класса сломанных PR в open source-проекте и оформил гайд как навык. Теперь каждый агент, который касается репозитория, видит триггер и выполняет правило. Бэкенд делает то же самое: не набрал 80% покрытия — PR не пройдёт.

Ворота для ИИ-контрибьюторов в open source

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

Шаблон пулреквеста как пропускной пункт

В шаблоне PR прямо написано: PR, не соответствующий шаблону, закрывается автоматически и без колебаний. Команда даже построила бота, который это делает. Но запускать его не понадобилось — само правило изменило поведение агентов. Агенты стали заполнять шаблон. А вот люди иногда его игнорировали, и это Тиндл считает полезным сигналом: «Если вы не следуете шаблону, вы, скорее всего, человек, и я отнесусь к вам мягче.»

Тест-план, который запускает код

В шаблоне есть раздел тест-плана, и его формулировка незаметно подсказывает агенту протестировать пулреквест. Эта фраза активирует навык test PR: агент устанавливает браузер, разворачивает приложение и проверяет изменение. Агент пришёл поставить галочку, а в итоге запустил код. После этого сломанные PR стали редкостью. Осталась другая проблема — PR, которые работают, но не вписываются в дорожную карту.

CI — стена, а не рекомендация

Codecov и другие проверки настроены как required checks. Агент открывает PR, через несколько минут видит, что мёрж заблокирован, загружает навык с тестами и добивается покрытия. Никто не просил — инфраструктура сама направила агента.

CLA (Contributor License Agreement) как детектор человека

AutoGPT использует двойную лицензию, но Тиндл советует лицензионное соглашение участника (Contributor License Agreement, CLA) любому проекту, даже MIT. Подписание требует браузера и OAuth-потока GitHub на отдельном домене. Сегодня агенты с этим справляются плохо — и это хорошо, потому что большинство мейнтенеров не хотят, чтобы агент ходил в GitHub от их имени. Если CLA не подписан в течение недели, PR закрывается с комментарием «подпишите CLA и переоткройте».

SHA коммита перед закрытием замечания

Часть агентов закрывает все треды ревью, не исправляя код. В AutoGPT есть навык pr-address, который описывает допустимую последовательность: исправить, закоммитить, запушить, ответить, потом разрешить тред. Ответ должен содержать полный SHA коммита, полученный через git rev-parse HEAD, чтобы агент не подсунул старый хеш. Навык явно называет антипаттерны: «Acknowledged» — не исправление, и ссылка на коммит, который не трогает указанную строку, тоже не считается.

Ворота, от которых пришлось отказаться

Когда CI падает, AutoGPT изначально запускала агента, который читал лог и писал комментарий, что сломалось. Первая версия использовала Claude Code внутри GitHub Actions с аутентификацией в CI — лишняя широкая учётная запись. Потом перешли на Copilot внутри рабочего процесса: тот же результат, но без лишних кредов.

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

Четыре ловушки, которые стоит записать

• Плохой AGENTS.md хуже, чем его отсутствие. В AutoGPT сначала разбросали файлы повсюду и засорили контекст. Если поведение агентов ухудшилось — перечитайте, что вы написали.
• GraphQL API GitHub быстро исчерпывает лимит запросов. Если каждый инструмент в команде ходит в CLI как отдельный пользователь, лимит закончится. Создайте GitHub App и аутентифицируйте CLI через неё.
• Сложное ревью стоит реальных денег. У AutoGPT PR проходит через клон ветки, восемь агентов с разными ролями, запуск стека и скриншоты. Круто, но дорого. Сейчас эту процедуру запускают только для совсем маленьких или крупных PR.
• Проверяйте авторизованные приложения. Каждый протестированный инструмент оставляет OAuth-разрешение. Если перестали использовать приложение — удалите его из настроек GitHub.

Не всё в open source решается воротами

Тиндл подчёркивает два тезиса, которые не связаны с инструментами. Первый: вы не обязаны принимать каждый пулреквест. Мёржить чужой LLM-вывод — асимметричная сделка: вы будете поддерживать этот код вечно. Закрыть PR и переписать решение самому — валидный выбор.

GitHub даёт мейнтенерам ручки: можно отключить пулреквесты целиком, ограничить создание issue только участникам с правами collaborator или требовать предварительного обсуждения. Если хотите — вообще закройте приём внешнего кода, как это сделали в SQLite: они принимают только баг-репорты. У вашего проекта тоже может быть своя граница.

Второй тезис: когда вы закрываете PR, но переписываете его идею сами, добавьте автора как соавтора, если это уместно. В AutoGPT 800 контрибьюторов, и один дополнительный соавтор ничего не стоит. Для большинства людей важно, что их проблему заметили и исправили.

Выводы

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

Тиндл советует мейнтенерам записываться в программу обратной связи GitHub — maintainers.github.com:

You've got to go there. You've got to sign up. It gets you all the connections you want at GitHub. That's where I learned about all this stuff, and where I share it.

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

Если тема интересна, загляните в разделы tproger: open source, GitHub и искусственный интеллект.

Источник: GitHub Blog — Your contributors are AI-first now. Is your project?

В этой статье разберём, почему стандартные assert-тесты и record-and-replay плохо справляются с автономными агентами, как теория графов помогает выделить обязательные этапы задачи и что из этого следует для российских команд, которые уже пробуют GitHub Copilot или собственных агентов в CI/CD.

Исследование, опубликованное 6 мая 2026 года в блоге GitHub, описывает метод валидации агентского поведения, который не требует ручного написания скриптов для каждого сценария и не верит агенту на слово. Вместо этого он строит модель «ground truth» из 2–10 успешных выполнений и проверяет новые запуски по структуре, а не по совпадению шагов.

• ИИ-агенты с Computer Use недетерминированы: один и тот же задача может решаться разными путями.
• GitHub предлагает Trust Layer — внешний слой валидации, который учится на успешных запусках и выделяет обязательные этапы.
• В основе — Prefix Tree Acceptor (PTA) и dominator analysis из теории компиляторов.
• В эксперименте метод показал 100% accuracy, precision, recall и F1 против 82,2%, 83,3%, 60,0% и 69,8% у самооценки агента.
• Trust Layer лучше определяет «не баг, а шум»: F1 52,2% против 0% у внутренней самопроверки агента.

Современная разработка всё чаще сталкивается с ситуацией, когда «правильно» нельзя описать одной последовательностью действий. Агент может открыть поиск в VS Code через горячую клавишу или через меню, подождать загрузки или успеть до неё, кликнуть мышью или использовать клавиатуру. Для человека результат одинаков. Для классического теста — разные выполнения, одно из которых рискует быть отмечено как регрессия.

Почему классические тесты сдаются

Привычные инструменты тестирования хороши, пока путь выполнения фиксирован. Как только поведение начинает ветвиться, они начинают ломаться не от плохой инженерии, а от неверной посылки: «правильность = точное совпадение последовательности состояний».

• Assertion-based testing требует вручную прописывать каждую проверку и не терпит допустимых альтернативных путей.
• Record-and-replay чувствителен к задержкам сети, рендерингу и незначительным изменениям интерфейса.
• Visual regression сравнивает скриншоты изолированно, не понимая контекста выполнения и семантики состояний.
• ML-оракулы — чёрный ящик: нужны тысячи примеров обучения, и невозможно объяснить, почему помечен конкретный прогон как ошибочный.

В России эта проблема особенно актуальна для команд, которые используют self-hosted runners или зеркала репозиториев. Сетевые лаги, доступ к зарубежным API и особенности локальной инфраструктуры добавляют ещё больше «шума», не связанного с качеством кода. В результате CI начинает «краснеть» по чужой вине, а разработчики привыкают игнорировать падения.

Что значит «правильно» для агента

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

• Обязательные состояния (essential states). Этапы, без которых успех невозможен. Например, открытие диалога поиска и появление результатов.
• Опциональные вариации (optional variations). Случайный шум: спиннер загрузки, небольшая задержка, временное уведомление.
• Сходящиеся пути (convergent paths). Разные последовательности действий, которые приводят к одному и тому же итоговому состоянию.

Ключевой инсайт: если состояние «спиннер загрузки» можно пропустить в быстром прогоне, оно не может быть обязательным. А вот состояние «диалог поиска открыт» доминирует результат: без него невозможно получить список найденного. Эта идея напрямую заимствована из теории компиляторов — dominator analysis.

Как устроен Trust Layer

Метод GitHub состоит из трёх шагов: собрать успешные выполнения, построить из них единую модель и выделить в ней обязательные состояния.

От трасс к графу

Вместо линейного скрипта каждое выполнение представляется как направленный граф. Узлы — наблюдаемые состояния: скриншоты интерфейса, снапшоты кода или структуры DOM. Рёбра — действия агента: клики, нажатия клавиш, вызовы API. Несколько успешных трасс объединяются в Prefix Tree Acceptor (PTA) — дерево, которое сохраняет общие префиксы и разветвляет пути там, где выполнения действительно расходятся.

Три уровня эквивалентности

Самая сложная часть — понять, когда два разных состояния на самом деле одно и то же. GitHub использует трёхуровневую проверку.

1. Визуальные метрики. Быстрые perceptual hash и SSIM ловят почти идентичные скриншоты.
2. Семантический анализ через LLM. Мультимодальная модель решает, значима ли разница: timestamp или декорация окна игнорируются, пропавшая кнопка или другое сообщение об ошибке — фиксируются.
3. Консервативное слияние. Состояния объединяются только при высокой уверенности, чтобы не потерять реальное расхождение.

Доминаторы выделяют суть

После слияния к графу применяется dominator analysis. Состояние A доминирует состояние B, если любой путь от начала к B проходит через A. Те состояния, которые доминируют успешное завершение задачи, становятся обязательными. Всё остальное автоматически классифицируется как опциональный шум.

При проверке нового прогона алгоритм не ищет точное совпадение. Он проверяет, что обязательные состояния появились в правильном порядке. Если эталонная последовательность A → B → C, а агент выполнил A → X → B → Y → C, тест проходит: X и Y считаются случайными вставками. Если пропущено B или нарушен порядок — фиксируется конкретная ошибка с пояснением, какое состояние не достигнуто.

Цифры: насколько это лучше

Авторы сравнили свой метод PTA (Dominator Tree) с самооценкой агента Computer-Use Agent (CUA) на наборе тестов кастомного расширения VS Code. Разница оказалась впечатляющей.

• Accuracy: CUA — 82,2%, PTA — 100% (+17,8 п. п.).
• Precision: CUA — 83,3%, PTA — 100% (+16,7 п. п.).
• Recall: CUA — 60,0%, PTA — 100% (+40,0 п. п.).
• F1-Score: CUA — 69,8%, PTA — 100% (+30,2 п. п.).

Ещё важнее метрика «не баг, а шум» (not-a-bug). Сам агент не смог корректно классифицировать такие сценарии: F1 оказался 0%. Trust Layer на основе структурного анализа достиг F1 52,2%. Это означает, что разработчики тратят меньше времени на разбор ложных падений.

We don’t need black-box models to judge other black-box models. We need structural guarantees developers can inspect, reason about, and trust.

Как это применить в своём CI/CD

Полноценная реализация Trust Layer требует исследовательского прототипа, но идеи можно перенести и в повседневную работу команд.

1. Собирайте «золотые» трассы. Сохраняйте 2–10 успешных выполнений критичного сценария, чтобы у будущих прогонов была эталонная структура.
2. Отделяйте «должен быть» от «может быть». Вместо проверки каждого шага фиксируйте ключевые чекпоинты: авторизация выполнена, данные сохранены, ответ получен.
3. Делайте тесты толерантными к порядку. Если несколько допустимых путей ведут к одному результату, проверяйте результат и наличие обязательных промежуточных состояний, а не точную последовательность.
4. Используйте семантику, а не пиксели. Визуальные регрессии должны понимать, что изменилось, а не просто считать разницу между скриншотами.
5. Не верьте агенту на слово. Внешняя валидация по состояниям среды надёжнее самооценки модели, особенно в недетерминированных задачах.

Для российских команд, работающих с ограниченным доступом к зарубежным API, важный вывод: если агент зависит от внешнего сервиса, валидация должна уметь отличать проблему сети от проблемы продукта. Иначе любой transient timeout будет превращаться в красный CI.

Выводы

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

Подход GitHub с Trust Layer, PTA и dominator analysis даёт объяснимую и лёгкую модель корректности, которую можно встроить в CI/CD. Она не требует тысяч примеров и не превращается в чёрный ящик. А главное — снижает количество ложных падений, за которыми теряются настоящие баги.

Источник: Validating agentic behavior when “correct” isn’t deterministic — The GitHub Blog.

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

Откуда взялась задача

Требований у меня было немного, но именно они всё и отсеяли: сервер должен стоять у меня, телеметрия парка не утекать на сторону, и всё это работать на смешанном парке сразу. Self-hosted-вариантов под такое оказалось немного, и те, что были, спотыкались об одно и то же: либо только маки, либо платные и при этом недоступны в России, либо разваливались на простом вопросе — а что с устройством, если агент две недели просидел офлайн. Ближе всего в этом поиске подобрался Fleet — серьёзный открытый проект, к нему я ещё вернусь ниже. Но развернуть его у себя оказалось тем ещё квестом: я в России, а fleetdm на российский IP не але, так что и сервер, и сборку агентов приходилось поднимать через VPN. Вдобавок агент на macOS в моём случае вставал через раз, а то и вовсе не ставился. Инструмент, который в итоге получился, я назвал RoutineOps; дальше по тексту буду говорить «агент», «сервер» и «панель».

Ещё одно соображение, которое я держал в голове: базовую защиту управляющего канала — mTLS, аудит, вменяемую политику паролей, подпись обновлений — я считаю БАЗОЙ, и держать её за пейволлом мне казалось неправильным. Это моё мнение, не претензия к рынку. Проект в итоге открыт под Apache-2.0; платный уровень существует, но вся базовая защита — в открытой части, и это не тема статьи.

Почему постоянный gRPC/mTLS-канал, а не опрос через VPN

Вечная головная боль: как дотянуться до ноутбука, который сейчас сидит в кафе за чужим NAT. Классических ответов два, и оба мне не понравились. Загнать всех в VPN — это лишняя инфраструктура и ещё одна точка отказа. Сделать агент, который раз в N минут дёргает HTTP-эндпоинт «не прилетело ли чего», — это шторм пустых запросов, а задержка команд упирается в период опроса.

Я пошёл третьим путём. Агент — Go-бинарь, который держит постоянный gRPC-стрим поверх mTLS наружу, по обычному интернету. Соединение инициирует сам агент: оно исходящее, а значит дружит с NAT. По этому же двунаправленному стриму сервер в любой момент проталкивает команду — запусти скрипт, заблокируй экран. Задержка доставки тут — это задержка сети, а не интервал, на который выставлен опрос.

Стек намеренно скучный — скучное не будит меня в три ночи.

- Агент и сервер — Go, сервер монолитом, без зоопарка микросервисов.

- Связь — gRPC + Protocol Buffers поверх mTLS: TLS 1.3, приватный CA с пиннингом на всём канале агентов.

- База — PostgreSQL 16, источник правды.

- Очередь задач — Redis + Asynq, с ретраями.

- Веб-интерфейс — React + TypeScript (Vite), раздаётся nginx-контейнером.

- Развёртывание — Docker Compose.

Порты минимальны: `443` — веб-интерфейс, REST API, enroll, отдача бинарей; `50051` — постоянный gRPC-канал агентов. Postgres и Redis наружу не торчат вообще. На парк до 50 устройств хватает 1 vCPU / 2 GB RAM / 20 GB SSD — и это стартовая планка. Heartbeat дешёвый, инвентарь редкий, поэтому один узел спокойно тянет тысячи устройств: предел задаёт железо машины, не архитектура.

Сертификат — это идентичность, и всё

Самый важный архитектурный вопрос: как агент доказывает, что он именно то устройство, за которое себя выдаёт. Ответ короткий. `device_id` — это CN клиентского сертификата, и только он. Идентификаторам в теле сообщений сервер не верит вообще. Прилетел heartbeat, а внутри указан чужой `device_id`? Игнорируется. Значение имеет одно — чем подписан TLS-хендшейк.

Отсюда и enrollment, устроенный так, чтобы приватный ключ устройства никогда не покидал устройство:

1. Админ в панели заводит устройство и получает одноразовый токен: TTL 24 часа, single-use, гонка при погашении закрыта на уровне БД.

2. Агент локально генерирует пару ключей и отправляет CSR на `POST /api/v1/enroll`.

3. Сервер подписывает сертификат своим приватным CA и сам проставляет CN. Повлиять на свой CN агент не может.

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

Вывод из эксплуатации — это отзыв сертификата

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

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

Heartbeat и инвентаризация разведены нарочно

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

Heartbeat — лёгкий и частый, примерно раз в 30 секунд, по постоянному стриму; по нему же едут задачи. Дёшево, потому что данных в нём кот наплакал. Инвентаризация — тяжёлая и редкая, примерно раз в 5 минут: ОС, железо, серийник, установленное ПО (на Linux — из dpkg/rpm/pacman/apk), версия агента.

Такое разделение держит постоянный канал дешёвым при любом размере парка. Если устройство пропало с радаров и heartbeat не приходит дольше порога (порог настраивается через `AGENT_UNREACHABLE_MINUTES`) — поднимается алерт `agent_unreachable`, с подавлением дребезга от сна и modern standby, иначе каждый закрытый на ночь ноут спамил бы в Tele... Max :).

Результаты скриптов идемпотентны. У каждого запуска есть `run_id`, и повторная доставка дедуплицируется на сервере. Связь рвётся, ack теряется, агент шлёт результат заново — без этой механики ловил бы дубли, а на неидемпотентных командах ещё и двойное исполнение.

Скрипты, группы и вопрос «а на скольких машинах это сейчас так»

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

У скрипт-политик три триггера: расписание (cron), при подключении агента и по событию. Третий появился из практики — реакция на «поставили запрещённое» полезна в момент установки, а не в ближайшие плановые три часа ночи. Софт-политики — правила allowed/forbidden по устройству, группе или платформе; они же кормят алерты: увидел агент в инвентаре то, чего быть не должно — прилетело событие.

А поверх этого — то, чего мне больше всего не хватало в чужих инструментах: по каждой политике видно охват и Pass / Fail. На сколько устройств она распространяется и сколько из них ей соответствуют. Политика без счётчика соответствия — не политика, а благое пожелание, лежащее в базе.

Агенту не нужна постоянная связь

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

Сложнее всего с блокировкой экрана. В офлайне полноэкранный overlay держится, а разблокировка идёт по локально хранимому bcrypt-хешу пароля — ходить за ней к серверу не нужно. Это осознанный компромисс: если бы разблокировка требовала сервер, любой обрыв связи превращал бы блокировку в невозможность войти в систему — а это уже хуже самой угрозы. Результаты и события тем временем копятся локально и досылаются, когда связь вернётся.

Обход блокировки — это тоже событие

Оверлей держится офлайн, но живёт он на машине, у пользователя которой есть руки. Поэтому у службы агента есть tamper-protection: на Windows — SafeBoot плюс реестр, на macOS — флаг `schg`. На Linux её нет, и это записано в docs/tamper-protection.md прямым текстом, а не подразумевается. Штатное снятие защиты — отдельная процедура, а не «убил процесс и пошёл дальше».

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

Временные админ-права — без поездки к машине

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

Теперь пользователь запрашивает временные локальные админ-права прямо из трея агента, я одобряю заявку в панели — и он ставит нужное сам, а по истечении срока повышение снимается. Ни подходить к машине, ни поднимать удалённую сессию ради одной инсталляции не надо. Мелочь на фоне остальной механики, но именно из таких мелочей и складывалось то самое «здраво администрировать парк», ради которого всё и затевалось.

Конфигурация как код — потому что кликать второй раз я не хотел

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

Поэтому появился CLI `routineops` с YAML-экспортом и применением: выгрузил скрипты, политики и группы в файлы, положил в git, применил на другом сервере. Diff конфигурации теперь читается в ревью, а не реконструируется по журналу аудита задним числом.

Fail-closed self-update и миграции

Самообновление — самый опасный канал из всех. Тот, кто им рулит, кладёт свой бинарь на все устройства как root. Поэтому здесь всё fail-closed. Примерно раз в 6 часов агент тянет манифест и проверяет sha256 и ed25519-подпись по полному манифесту: версия, ОС, архитектура, хеш подписаны одним набором сразу. Так нельзя подсунуть валидный бинарь под чужую версию или платформу. Дальше агент атомарно заменяет себя и перезапускается. Даунгрейд невозможен — есть anti-rollback floor: битый релиз чинится только версией вперёд, назад дороги нет. Приватный ключ подписи уникален для конкретной инсталляции; потеря не катастрофа — новый раздаётся через переэнролл.

На сервере тот же принцип. Схему накатывает отдельный migrate-сервис — до старта сервера. Не прошла миграция — сервер просто не поднимется на несовместимой схеме. Down-миграций нет, и это намеренно: откат — только из бэкапа, причём бэкап БД update.sh снимает сам перед каждым обновлением. Пережить факап из снапшота я предпочту тому, чтобы полагаться на корректность down-скрипта, накатываемого поверх наполовину применённого состояния.

Модель доверия: god-mode by design

А вот тут льстить не буду — и это, пожалуй, самая важная часть текста. MDM по своей природе — это god-mode над парком. Скрипт-канал исполняет произвольный `bash -c` / `powershell -Command` как root/SYSTEM на каждом устройстве. Это не дыра, которую я забыл заткнуть. Это и есть продукт: весь смысл MDM в том, чтобы раскатать одну команду на сотню машин разом. А такой инструмент по определению — санкционированный RCE.

Скажу прямо.

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

- `JWT_SECRET` (симметричный HS256) — единственный корень доверия панели. Кто прочитал этот секрет, тот печатает себе сколько угодно валидных admin-токенов. Не «подобрать пароль», не «обойти MFA» — просто сгенерировать подписанный токен и зайти админом.

- Отсюда единственный вывод: реальный периметр безопасности — это хост, на котором крутится сервер. Не TLS, не RBAC, не аудит. Они важны, но вторичны. Увели сервер — увели весь парк.

Харденинг этого хоста — работа оператора, и в SECURITY.md под неё лежит чеклист: SSH только по ключам, наружу открыты только два порта, Postgres и Redis — на localhost, `JWT_SECRET` генерируется через `openssl rand -base64 48` и лежит в режиме `600`, панель — за VPN или IP-allowlist, аудит-лог — в append-only хранилище с алертом на появление новых админов.

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

Что закрыто по умолчанию

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

- Не стартует на слабом секрете. Требует `JWT_SECRET` от 32 байт и минимум 16 различных байт. Случайно уехать в прод на `changeme` не получится.

- Admin-JWT живёт 8 часов. Logout реально ревокирует токен через jti-блоклист. Смена или сброс пароля обнуляет все ранее выданные токены пользователя разом — через token-epoch.

- Lockout по IP и по аккаунту, bcrypt cost 12. Форма входа не выдаёт, какие аккаунты вообще существуют.

- Политика сложности пароля — для всех, включая seed-админа: от 8 символов, минимум 3 класса символов из 4. Даже первый администратор не заведётся с `admin/admin`.

- RBAC на две роли — `it_admin` (всё) и `viewer` (только чтение), с проверкой на сервере. Viewer, дёрнувший мутирующий эндпоинт прямо из DevTools, упрётся в 403 ещё на сервере.

- API-токены — отдельная сущность, а не админская сессия. Выпуск и отзыв из панели: интеграции ходят под своим токеном, и выключается такой доступ одним действием.

- Плюс одноразовые enroll-токены, журнал аудита на каждое привилегированное действие (retention по умолчанию 365 дней), security-заголовки (HSTS/CSP/X-Frame-Options/nosniff), rate-limit и cap на размер запроса.

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

Мелочи, из которых на самом деле состоит эксплуатация

Отдельного раздела каждая из них не заслуживает, но вместе они закрывают вопрос «а как я об этом узнаю»:

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

- «Пользователь за консолью» в карточке. Кто прямо сейчас сидит за машиной. Без этого половина алертов повисает в воздухе.

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

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

- `agent diag` на устройстве. Первый вопрос в поле всегда один — «почему агент не выходит на связь», и отвечать на него по логам сервера бессмысленно: сервер как раз ничего и не видит.

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

Честные ограничения

Раз обещал честность — вот граница, без прикрас.

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

- Нет SSO и MFA. Вход по паролю плюс RBAC. Пока разумно держать панель за VPN или allowlist.

- macOS .pkg не подписан Apple. По двойному клику встретит Gatekeeper — ставится через `installer` из терминала.

- Скрипт-канал — это RCE by design. Подробно — в разделе про модель доверия выше.

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

- Оверлея блокировки на Linux нет. Состояние блокировки хранится, экрана нет.

- Запрещённое ПО детектится, но не удаляется. Алерт есть, автоматического устранения — нет.

- Под Windows нет сборки arm64. Для Linux и macOS arm64 есть.

Про Fleet

Ближайший открытый аналог, который я смотрел, — Fleet, тоже open source, ядро под MIT. Инструмент серьёзный и зрелый, и во многом он сильнее моего: настоящий нативный MDM с профилями конфигурации и zero-touch-энроллментом, live-запросы osquery по всему парку, расчёт на масштаб в сотни тысяч машин. Построен вокруг osquery, инфраструктура — MySQL плюс Redis за балансировщиком, под горизонтальное масштабирование.

Под мой случай он просто не сошёлся по устройству. Чтобы реально управлять маками, Fleet опирается на нативный Apple MDM — а это APNs-сертификат от Apple с ежегодным продлением плюс Apple Business Manager для zero-touch. Мне не нужна была SQL-аналитика по всему парку; нужен был лёгкий агент, офлайн-лок без APNs, инвентарь и скрипты. А поверх этого архитектурного несовпадения легли те самые бытовые проблемы с развёртыванием из России и капризным macOS-агентом, о которых я писал в начале.

Чему это меня научило

Самое неожиданное в проекте — что львиная доля инженерных решений оказалась не про «как добавить», а про «как убрать». Идентичность через CN вырезала целый класс серверной авторизации; fail-closed на миграциях и обновлениях — ветки «а что если накатилось наполовину». Разведённые heartbeat и инвентарь сняли лишний трафик. А карта модели доверия избавила меня самого от иллюзии, будто TLS и RBAC — это и есть безопасность. Настоящий периметр оказался в одном месте — на хосте сервера.

Исходники я открыл под Apache-2.0; прямую ссылку на репозиторий оставлю тут :). Если вам будет интересно я бы с радостью пообщался по замечаниям именно по модели доверия — по местам, где приложение должно что-то enforce-ить, но не делает.

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

Также доп. фишка в том что основная конфигурация происходит именно в frpc, который, в свою очередь, передает часть настроек на frp на удаленном сервере.

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

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

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

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

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

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

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

Изначально для домашней страницы я написал кастомную минималистичную HTML-панель с Glassmorphism-дизайном. Выглядело это красиво, но добавлять новые сервисы вручную через постоянную правку исходного кода было крайне неудобно.

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

Заключение

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

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

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

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

С практической точки зрения проект на**й не нужен. Есть GitHub, GitLab и куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Почему не JSON

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

Подергал JSON туда-сюда пару дней и понял: не варик.

1. Конкурентный доступ. Два юзера одновременно коммитят — один перезаписывает файл другого.
2. Целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии.
3. Версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Вывод: JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор SQLite и схема БД

Выбрал SQLite, потому что:

• Не надо поднимать отдельный сервер
• Целостность данных на уровне движка (транзакции, foreign keys, rollback)
• Всё в одном файле — скопировал и унёс

Сущности:

• users — telegram_id, username, current_project_id
• projects — owner_id, name, thread_id (каждый проект живёт в своём треде канала)
• files — filename, current_version, флаг modified (файл изменился и готов к коммиту)
• file_versions — мясо. Каждая версия файла с полным содержимым. Привязана к file_id и опционально к commit_id
• commits — сообщение, время, ссылка на проект
• commit_files — связка коммитов с версиями файлов (many-to-many, чтобы поддержать ветки)

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

В коде вместо голых кортежей из SQL — датаклассы:

Маркдауновый ад

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

На практике Telegram использует свой диалект Markdown, где куча служебных символов: _ * [ ] ( ) ~ > # + - = | { } . !

Попытка 1: заэкранировать всё подряд. Результат: код превращается в кашу. Вместо def __init__- получается def |_|_init|_|_ — уже не запустишь, и в канале выглядит как говно.

Попытка 2: не экранировать вообще. Telegram шлёт на**й с ошибкой «can't parse entities».

Попытка 3: экранировать только то, что реально ломает разметку. Выяснилось, что порядок важен. Сначала экранируем точки и подчеркивания, потом обратную косую черту. Но и это не панацея — последовательности типа \*

после экранирования превращаются в \\*, и Telegram снова недоволен.

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

Попытка 5 (финал): забил на Markdown и перешёл на HTML. Telegram умеет его принимать. Да, он не такой красивый, но зато предсказуемый:

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

Security by design

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

Добавил в /commit. Потом решил с другого аккаунта потестировать команды на чужих файлах. И тут бот на каждую команду стал выдавать «файл не найден» или «проект не найден». И я понял: безопасность уже работает. С самого начала. Из коробки. Без единой строчки кода.

Как так вышло? В таблице projects с самого начала было поле owner_id. При создании проекта я писал туда telegram_id владельца. Все запросы к БД фильтруются по этому полю:

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

Команды: от семи до двух десятков

Изначально казалось, что команд будет немного. Но...

Жизнь рассудила иначе.

• База: /start, /init, /use, /list, /ls, /commit, /log, /status
• Удаление: /rm, /rmproject + подтверждение
• Игнор: /ignore, /ignored, /unignore
• Ветки: /branch, /branches, /checkout
• Диффы и просмотр: /diff, /cat

Итого — уже под два десятка. И это не предел.

Простота > абстракции

В моём коде нет абстрактных базовых классов. Совсем. Потому что они нужны только когда у тебя есть минимум две разные реализации одного и того же. В GitGram всё проще: один способ работать с БД, один способ шифровать, один способ парсить .gitignore.

Если завтра появится вторая реализация — тогда и буду делать интерфейс. А пока это просто оверхед.

В GitGram:

• Хочешь понять, как работает add_file — идёшь в database.py и читаешь 10 строк кода.
• Хочешь увидеть обработчик /commit — открываешь bot.py и смотришь.

Никаких AbstractMinerShieldEventProcessor, BaseGitGramManager, InterfaceProviderFactory.

Код должен быть тупым. Чем тупее — тем проще его читать и отлаживать.

Что дальше

В планах:

• Докрутить коллаборацию (несколько человек над одним проектом)
• Приватные репозитории
• Кодспейс прямо в боте (да да знаю я сошёл с ума и бла бла бла..)

Итог

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

На практике GitGram ни к чему. Но сама задумка — Git в Telegram — это же так прикольно. Просто посмотреть, можно ли такое вообще запилить.

Если хочешь поучаствовать

• GitGram
• Чат для хардкорных: @sandbox_hardcore — вся сырая разработка, факапы и обсуждения (без цензуры)

Подписывайся на мой TГ-канал — там я публикую все свои эксперименты, код и приглашаю к обсуждению. Только факты, мат и никакой политоты.

На первый взгляд кнопка «наверх» — задача на пять минут. Добавил position: fixed, обработчик window.scrollTo() — готово.

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

В итоге маленькая UI-деталь начинает обрастать условиями. Я решил собрать их в отдельный Django-пакет — django-scroll-to-top

Когда трёх строк JavaScript достаточно

Для небольшого сайта, где нет сложной верстки, админки, CSP и требований к повторному использованию, самый простой вариант действительно выглядит примерно так:

Это нормальное решение. Не всегда стоит тянуть пакет ради одной кнопки.

Но в реальном Django-проекте быстро появляются дополнительные вопросы:

• когда именно показывать кнопку: после 300 пикселей, одного экрана или только при прокрутке вверх;
• что делать на коротких страницах;
• как не перекрыть cookie-баннер, чат, toast-уведомления или нижнюю мобильную навигацию;
• как дать пользователю закрыть кнопку;
• как не сломать клавиатурную навигацию и режим reduced motion;
• как сделать отдельное оформление для сайта и Django Admin;
• как не заставлять проект добавлять unsafe-inline в Content Security Policy;
• как позволить редактору или администратору изменить цвет, положение и иконку без нового деплоя.

Именно в этот момент «три строки JavaScript» превращаются в отдельный компонент.

Что я хотел получить

Цель была не в том, чтобы сделать ещё одну стрелку в правом нижнем углу. Хотелось собрать переиспользуемый компонент со следующими свойствами:

1. Подключение сайта одной template-тегом.
2. Отдельная поддержка обычных страниц и стандартного Django Admin.
3. Настройка внешнего вида через админку, а не через постоянную правку CSS.
4. Без jQuery, CDN, фронтенд-фреймворка и обязательной сборки.
5. Безопасная работа при строгой CSP.
6. Прогрессивное улучшение: без JavaScript остаётся обычная ссылка в начало страницы.
7. Возможность жить рядом с другими фиксированными элементами интерфейса.

Пакет в итоге хранит обычные настройки установки в settings.py, а визуальное поведение — в базе данных. Это позволяет менять кнопку через Django Admin, публиковать новую версию настроек и при необходимости откатываться на предыдущую. В проекте есть отдельные профили для публичного сайта и Django Admin, а ревизии могут быть черновыми, опубликованными или архивными.

Быстрое подключение

Базовый сценарий начинается с установки:

В settings.py добавляем приложение. Если нужна поддержка стандартной админки, пакет должен идти раньше django.contrib.admin:

Включаем области, где должна работать кнопка:

Для публичной части добавляем URLConf пакета:

А в общий шаблон сайта — один тег:

На стандартном Django Admin ничего дополнительно вставлять не нужно: пакет использует обычный механизм разрешения шаблонов Django. Если же в проекте переопределён admin/base_site.html тег можно добавить вручную в блок footer

Настройка без превращения админки в редактор CSS

Мне не хотелось хранить в базе шаблоны, произвольный CSS или JavaScript. Это неудобно для сопровождения и создаёт лишнюю поверхность для ошибок.

Поэтому визуальная часть собрана из контролируемых вариантов:

• круг, квадрат, скруглённый квадрат или pill;
• заливка solid, outline, soft, ghost, glass или gradient;
• положение в любом углу экрана;
• отдельные размеры для desktop и mobile;
• светлая и тёмная тема;
• встроенные иконки, иконки от разработчика или загружаемые SVG;
• настройки тени, границы, opacity и focus ring.

Что происходит, когда рядом есть cookie-баннер или чат

Нижний правый угол страницы редко бывает свободен. Там часто живут:

• cookie-баннер;
• компактная кнопка после закрытия баннера;
• чат поддержки;
• кнопка обратного звонка;
• мобильная навигация;
• toast-уведомления.

Пакет умеет рассматривать такие элементы как препятствия. Для этого можно пометить элемент атрибутом:

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

Для сложных виджетов есть отдельный адаптер: он может отслеживать появление и исчезновение элементов, например компактного launcher после закрытия cookie-баннера. При этом ни cookie-пакет, ни чат не становятся зависимостями django-scroll-to-top

Доступность — не отдельная галочка в конце

У кнопки есть понятное имя для screen reader, поддержка клавиатуры, видимый focus-visible, минимальный размер области нажатия и режим prefers-reduced-motion.

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

Полный независимый аудит WCAG 2.2 AA и тестирование масштабирования 200% и 400% пока находятся в roadmap, поэтому называть компонент полностью сертифицированным по WCAG было бы неправильно. Но структурные требования — клавиатурная доступность, фокус, reduced motion, forced-colors и безопасная работа без JavaScript — уже заложены в компонент и покрываются тестами.

CSP и загружаемые SVG

В корпоративных проектах часто нельзя просто добавить inline-скрипт и включить unsafe-inline ради одной кнопки.

По умолчанию компонент использует same-origin CSS и JavaScript. Для него подходит политика такого вида:

Настраиваемые цвета и размеры отдаются не через inline-стили, а через версионированный stylesheet endpoint. Это позволяет сохранить простой контракт с одним template-тегом и не ослаблять CSP.

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

Ревизии, публикация и откат

Одна из самых полезных вещей в пакете — не сама кнопка, а жизненный цикл её настроек.

Можно создать черновик, посмотреть результат в live preview, опубликовать изменения или вернуться к предыдущей версии. Это особенно удобно, когда кнопку настраивает не разработчик, а контент-менеджер или дизайнер.

У ревизий есть три состояния:

• draft — редактируемый черновик;
• published — текущая активная конфигурация;
• archived — сохранённая версия для отката.

Где пакет уместен, а где нет

django-scroll-to-top имеет смысл, когда кнопка нужна в нескольких проектах, должна работать в Django Admin, настраиваться без деплоя или жить в окружении со строгими требованиями к CSP и интерфейсу.

Для лендинга на одну страницу проще и правильнее написать несколько строк самостоятельно. Это будет быстрее, понятнее и дешевле в сопровождении.

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

Сейчас пакет выпущен как beta-версия 0.2.0, требует Python 3.10+ и поддерживает Django 4.2 LTS, 5.x и 6.0. Лицензия — MIT.

Исходный код, документация и примеры использования доступны в GitHub-репозитории проекта.

Пакет опубликован в PyPI под именем django-scroll-to-top.

Обратная связь, баг-репорты и предложения по интеграции с кастомными Django Admin-темами приветствуются в Issues.

SafeLine WAF — это бесплатный инструмент, который я лично тестировал.

Это полностью open-source решения, продукт с действительно бесплатной Community Edition, где ключевые функции не урезаны.

SafeLine WAF — веб-приложенийный межсетевой экран, который действительно поставляется с разумными настройками по умолчанию

Что он делает:

Защищает веб-приложения от SQL-инъекций, XSS-атак, командных инъекций, CSRF, SSRF, атак включения файлов и других угроз из списка OWASP Top 10. Также поддерживает защиту от CC/DDoS-атак, управление ботами и может работать как шлюз аутентификации.

Почему он:

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

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

Некоторые показатели, которые стоит учитыват

1. Уровень обнаружения - SafeLine (Balanced) (71.65%), ModSecurity (Level 1) (69.74%), Cloudflare (Free) (10.7%)
2. Уровень ложных срабатываний - SafeLine (Balanced) (0.07%), ModSecurity (Level 1) (17.58%), Cloudflare (Free) (0.07%)
3. Точность - SafeLine (Balanced) (99.45%), ModSecurity (Level 1) (82.20%), Cloudflare (Free) (98.40%)

Сбалансированный профиль SafeLine обнаруживает более 70% атак, при этом блокируя легитимный трафик ошибочно всего в 0.07% случаев. Это именно тот уровень настроек по умолчанию, который можно использовать в промышленной среде без постоянного ручного контроля.

Установка выполняется одной командой

После запуска он разворачивается как набор Docker-контейнеров: Tengine (форк Nginx) используется в качестве reverse proxy, отдельный сервис отвечает за семантический анализ, PostgreSQL хранит конфигурации и логи, а удобная веб-панель администратора работает на порту 9443.Community Edition поддерживает до 10 сайтов, чего достаточно для большинства личных проектов и небольших бизнес-сценариев.

Сайт: https://cyberserval.tech/landing/safeline

GitHub: github.com/chaitin/SafeLine (более 21 тыс. звёзд)

Лицензия: GPL-3.0 / MIT (Community Edition)

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

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

Допустим, команда решила переписать модуль заказов в e-commerce-продукте. В старой версии есть корзина, промокоды, доставка и оплата. Команда планирует за полгода сделать новый сервис заказов. Но за эти полгода бизнес добавляет подписки, подарочные сертификаты, частичную оплату бонусами и новую логику возвратов. В итоге новая система, которую проектировали под старые требования, к моменту релиза уже нуждается в доработке.

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

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

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

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

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

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

Например, в системе расчета налогов может быть правило: для контрактов, заключенных до 2018 года, НДС округляется в меньшую сторону до целого рубля, а для всех остальных — по математическим правилам. Новый разработчик может решить, что это ошибка, и «исправить» округление. Но потом выяснится, что часть крупных клиентов держит это поведение в своих сверках, а смена правила приведет к расхождениям в актах и претензиям.

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

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

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

Последний пункт особенно важен. Если флаги не удалять, система быстро превращается в набор ветвлений, где никто уже не понимает, какая логика актуальна.

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

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

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

Для критичной доменной логики — платежей, биллинга, расчета тарифов — допустимый уровень расхождения должен быть около нуля: цель в shadow-режиме не «как можно меньше различий», а «понимаем каждое расхождение». Для менее чувствительных доменов (рекомендации, ранжирование результатов поиска) можно жить с расхождением в долях процента, но и там расхождения нужно классифицировать, а не игнорировать. Возможно, это баги новой реализации. А возможно, старая система содержит устаревшую логику, которую нужно отдельно обсудить с бизнесом.

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

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

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

Технических метрик недостаточно. Если команда переносит оформление заказа, важно смотреть не только на 500 ошибки и время ответа, но и на конверсию в оплату, количество брошенных корзин, повторы запросов, обращения в поддержку.

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

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

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

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

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

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

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

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

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

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

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

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

Компромиссы, к которым нужно быть готовыми

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

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

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

Когда Strangler Fig особенно оправдан

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

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

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

Когда модернизацию лучше не делать

Постепенная миграция — мощный инструмент, но у неё тоже есть стоимость, и иногда правильный ответ — оставить систему как есть. Несколько сценариев, в которых модернизация плохо окупается.

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

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

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

Что получает команда

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

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

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

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

Git worktrees позволяют держать несколько рабочих копий одного репозитория на разных ветках — и сейчас эта возможность в тренде. Забавно, что в Git она появилась ещё в 2015 году. Но worktrees действительно удобны, и в этой статье разберёмся, зачем они нужны, чем отличаются от обычных веток и почему внезапно стали популярны.

worktree — это дополнительная рабочая копия репозитория на другой ветке, привязанная к тому же .git.

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

Они особенно полезны при параллельной работе с ИИ-агентами и в приложении GitHub Copilot.

У worktrees есть ограничения: раздувание зависимостей, необходимость убирать папки, правила .gitignore и запрет на одновременный checkout одной ветки в нескольких worktrees.

Переключение контекста через ветки и stash

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

Сначала, скорее всего, спрячете текущие изменения в stash:

Потом перейдёте на main и обновите её:

Затем создадите ветку с хотфиксом:

Пофиксите, закоммитите и запушите ветку:

После слияния pull request вы вернётесь к компьютеру, подтянете main и удалите ветку с багфиксом:

А потом сможете вернуться к задаче, над которой работали:

Фух. На чём мы остановились?

Переключение туда-сюда, перезагрузка файлов, переустановка node_modules в зависимости от того, что изменилось, — всё это отнимает много сил. Нагрузка от смены контекста серьёзная.

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

А потом появились… worktrees!

Переключение контекста через worktrees

С worktrees вы никогда не покидаете свою ветку и не используете stash, а редактор с вашей текущей фичей остаётся нетронутым.

Эта команда мгновенно создаёт соседнюю папку hotfix-workspace, базирует её на main и создаёт новую ветку hotfix-bug.

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

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

Гораздо плавнее! Нет риска конфликтов stash, редактор не перезагружается, и вы действительно можете работать параллельно.

Так почему же сейчас?

Долгое время worktrees были относительно неизвестны. Большинство разработчиков никогда о них не слышали, потому что либо Git GUI не поддерживали их (или относились как к второсортной функции), либо все привыкли к знакомой схеме: feature-ветка, работа, PR, merge и повтор.

Сейчас наша работа изменилась. ИИ заставляет нас работать параллельно больше, чем когда-либо в истории разработки ПО. Разработчики запускают множество сессий одновременно, а «культура код-ревью» растёт быстрее, чем «культура написания кода».

Агенты и люди могут делать больше параллельно с помощью worktrees. Это режим по умолчанию в приложении GitHub Copilot и во многих других современных инструментах.

Агенты и люди могут делать больше параллельно с помощью worktrees.

В чём подвох?

Worktrees решают кучу проблем, но есть нюансы, на которые стоит обращать внимание.

• Раздувание зависимостей: каждая папка worktree требует собственную копию зависимостей проекта. Если запускать npm install или pip install в нескольких worktrees, диск может быстро закончиться.
• Управление папками: нужно удалять папки worktree, чтобы со временем не засорять родительский каталог. Приложение GitHub Copilot часто делает это за вас, но если вы работаете в терминале, придётся следить самостоятельно.
• Требования к глобальному .gitignore: если создавать worktree внутри основного репозитория, их нужно вручную добавить в .gitignore, чтобы случайно не закоммитить. Можно создавать worktree за пределами основного репозитория (GitHub Copilot делает это по умолчанию), но это стоит учитывать.
• Ограничение «одна ветка»: Git не позволяет одновременно checkout’ить одну и ту же ветку в двух разных worktrees, чтобы избежать повреждения данных.

Как использовать git worktrees в приложении GitHub Copilot?

Отличный вопрос! Здорово, что там всё работает «из коробки». Когда вы открываете приложение, на главном экране есть выпадающий список, который спрашивает, где запускать новую сессию. По умолчанию выбран новый worktree.

Когда вы запускаете новую сессию, можно нажать на имя сессии вверху приложения и увидеть (забавное!) сгенерированное имя вашего worktree, а также путь, где он находится, проект, для которого он создан, и сведения о внесённых изменениях.

Проще простого!

Стоит ли использовать worktrees?

Я дам вам самый senior-ответ, который только можно: зависит от ситуации! Вам может быть удобнее работать по-другому. Возможно, вы не так много работаете параллельно и привыкли к ментальной модели веток и stash. Возможно, теперь вы будете использовать только worktrees. А может, захотите и то, и другое!

Мир у ваших ног, и попробовать всё это можно уже сегодня в приложении GitHub Copilot.

Об авторе. Cassidy Williams — старший директор по адвокации разработчиков в GitHub. Она создаёт ПО, консультирует стартапы и учит разработчиков строить лучше. Подписаться на её еженедельную рассылку можно на cassidoo.co/newsletter.

Выводы

Git worktrees — способ работать с несколькими ветками одновременно, не прерывая текущую задачу и не рискуя запутаться в stash. Они особенно удобны при параллельной работе с ИИ-агентами и встроены в приложение GitHub Copilot по умолчанию. Попробуйте — возможно, именно они упростят ваш рабочий процесс.

Business Insider со ссылкой на двух знакомых с планами людей сообщает: Microsoft, владелец GitHub, вынуждена арендовать дополнительные вычислительные мощности у Amazon Web Services. Официальный представитель Microsoft подтвердил лишь использование нескольких облачных провайдеров, но отказался комментировать участие Amazon. AWS — главный конкурент Microsoft Azure на рынке облаков, поэтому конкуренты вынуждены сотрудничать.

• Microsoft планирует разместить часть нагрузки GitHub на Amazon Web Services из-за нехватки собственных мощностей.
• При сохранении текущего темпа число коммитов на платформе может вырасти с 1 млрд в 2025 году до 14 млрд в 2026 году.
• В 2026 году GitHub пережил десятки крупных сбоев.
• Microsoft намеревалась полностью перевести GitHub на Azure к 2027 году, но ИИ-бум ускорил потребность в дополнительных мощностях.

Что произошло

GitHub — популярная платформа для хранения и совместной работы над кодом. До поглощения Microsoft в 2018 году она в основном использовала собственные дата-центры. Корпорация планировала полностью перевести GitHub на Azure к 2027 году, но всплеск активности, связанный с разработкой на базе ИИ-агентов и ассистентов, заставил пересмотреть сроки и искать мультиоблачную схему.

Рост коммитов в 14 раз

По данным директора по операциям GitHub Кайла Дейгла, при сохранении текущего темпа число коммитов — записей об изменениях в коде — в 2026 году может достичь 14 млрд против 1 млрд в 2025. Microsoft, со своей стороны, прогнозирует общие капитальные затраты корпорации в $190 млрд в 2026 году, в основном на расширение дата-центров, но часть проектов откладывается.

Почему Microsoft идёт на сделку с AWS

Конкуренция между Azure и AWS не отменяет главную задачу — не допустить сбоев в работе сервиса. В 2026 году GitHub пережил десятки крупных сбоев. Кроме того, на рынке появляются альтернативы вроде Cursor и Claude Code, которые конкурируют с экосистемой GitHub и Copilot, и Microsoft приходится ускорять модернизацию инфраструктуры.

Конкуренция за разработчиков

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

Часто задаваемые вопросы

Выводы

Сделка Microsoft и Amazon — признак того, что спрос на ИИ-инфраструктуру превышает возможности даже крупнейших игроков. Для разработчиков главное — чтобы GitHub оставался стабильным: следите за статус-страницей сервиса и не используйте GitHub как единственное хранилище критичных данных. Первоисточник: Business Insider.

Историю обнародовал журналист Брайан Кребс в материале от 18 мая по наводке исследователя из GitGuardian. Репозиторий назывался без лишней скромности — Private-CISA — и был виден любому, кто откроет GitHub.

• Подрядчик CISA с 13 ноября 2025 года вёл публичный репозиторий Private-CISA размером 844 МБ с паролями, ключами AWS GovCloud, сертификатами Entra ID SAML и Kubernetes-манифестами.
• Пароли лежали в открытом виде в CSV-файле, а среди файлов был importantAWStokens с админ-доступом к трём серверам AWS GovCloud.
• Чтобы такое стало возможным, в аккаунте было выключено стандартное правило GitHub, блокирующее коммиты с секретами.
• GitGuardian называет утечку «худшей в карьере» исследователя, но CISA утверждает, что «нет признаков компрометации чувствительных данных».
• Репозиторий закрыли вечером 15 мая 2026 года, спустя около 26 часов после уведомления исследователей — но он был публичным около полугода.

Что лежало в Private-CISA

GitGuardian, компания, у которой сканер постоянно обходит публичные репозитории GitHub в поисках утёкших секретов, наткнулась на репозиторий 14 мая 2026 года. По объёму это 844 МБ — 498 МБ в рабочем дереве, остальное в истории Git. Среди папок и файлов исследователи нашли:

• importantAWStokens — административные токены к трём серверам AWS GovCloud (изолированный облачный регион Amazon для госструктур США).
• AWS-Workspace-Firefox-Passwords.csv — экспорт сохранённых паролей Firefox с десятками логинов и паролей от внутренних систем CISA в открытом виде.
• CAWS GitHub Token.txt — отдельный токен GitHub-организации.
• Kube-Config.txt — конфигурации Kubernetes для доступа к кластерам.
• Папку ENTRA ID — SAML Certificates с сертификатами для единого входа через Microsoft Entra ID.
• Папки All Backups, Backup-April-2026, LZ-Artifactory, Kubernetes-Important-Yaml-Files — внутренние бэкапы, манифесты ArgoCD и YAML-файлы с секретами.
• Terraform-код инфраструктуры и GitHub Actions, описывающие, как CISA собирает, тестирует и выкатывает свой софт.
• Резервные копии внутренней документации в форматах OneNote и DOCX, плюс скрипты для GitHub, Kubernetes, ArgoCD.

Один из попавших в репозиторий хостов назывался LZ-DSO — по словам исследователей это сокращение от Landing Zone DevSecOps, то есть от среды, в которой CISA «безопасно» собирает свой код. Иронично: ключи от пайплайна, который должен защищать всё остальное, лежали публично.

Это худшая утечка, которую я видел за свою карьеру.

Сначала команда GitGuardian приняла находку за розыгрыш: слишком уж красноречивые названия папок и файлов. Но личные документы, имена хостов и аккуратная структура повторных бэкапов убедили — это рабочая копия чьего-то ноутбука, которую регулярно «синхронизировали» через git push в открытый репозиторий.

Как нашли и сообщили

Согласно подробному разбору GitGuardian, программа Good Samaritan компании первой обнаружила утечку и автоматически отправила девять писем владельцу коммитов. К утру 15 мая в ответ пришли только автоответчики.

Тогда исследователи связались с Брайаном Кребсом, чтобы он передал утечку напрямую своим контактам в CISA. Параллельно подключились партнёры с прямой линией в агентство. Около 16:00 по центральноевропейскому времени удалось дозвониться, а в районе 18:00 по восточному времени США репозиторий стал недоступен. От первого выявленного слива до закрытия прошло чуть больше суток — но создан репозиторий был 13 ноября 2025 года, так что окно для злоумышленника составляло около полугода.

Хронология

• 13 ноября 2025 — создан публичный репозиторий Private-CISA, первые секреты залиты.
• 13 мая 2026 — автоматический сканер GitGuardian Good Samaritan уже успел отправить владельцу репозитория девять писем-предупреждений.
• 14 мая 2026, 16:14 CET — GitGuardian фиксирует инцидент и подаёт его в CERT/CC (координационный центр по реагированию на киберинциденты), параллельно ища личные контакты в CISA.
• 15 мая 2026 — GitGuardian параллельно выходит на Кребса для эскалации через его контакты и на собственных партнёров с прямой линией в агентство; около 16:00 CET до CISA дозваниваются.
• 15 мая, около 18:00 EST — репозиторий удалён.

Почему secret scanning не сработал

GitHub давно предлагает push protection — функцию, которая не даёт залить в публичный репозиторий распознанные секреты вроде токенов AWS, ключей SSH или ключей API. Для бесплатных публичных репозиториев она включена по умолчанию с 2024 года. Но защита от дурака легко выключается одним кликом, и в случае с Private-CISA её действительно отключили — Кребс цитирует исследователей, которые нашли в истории коммитов следы того, что владелец аккаунта вручную убрал блокировку секретов.

Это распространённый паттерн: разработчик сталкивается с блокировкой пуша, не разбирается, почему сработала защита, и снимает её через настройки. Иногда — в личном репозитории «для удобства», иногда — потому что коммит уже содержит что-то более чувствительное, чем тестовый ключ. Результат предсказуем: репозитории, в которых годами лежат «временные» .env-файлы с продакшен-доступами, и автоматические сканеры вроде GitGuardian, TruffleHog или GitHub Secret Scanning, которые рано или поздно их находят.

По версии Gizmodo, сотрудник подрядчика Nightwing использовал GitHub как личную папку «Загрузки»: коммитил файлы с рабочего ноутбука, чтобы открыть их на домашнем компьютере. То же самое многие делают через личную почту, только публичный репозиторий ещё хуже — он проиндексирован поисковиками и сканируется ботами в режиме реального времени.

Кто такая CISA и почему это важно

Особый цинизм истории — в том, кто оказался виновником. CISA (Cybersecurity and Infrastructure Security Agency) — молодое подразделение Министерства внутренней безопасности США, отвечающее за кибербезопасность всех федеральных гражданских сетей. Это именно та организация, которая публикует руководства про «никогда не храните пароли в спредшитах». При этом, по данным TechCrunch, у CISA с 20 января 2025 года нет постоянного директора, агентство потеряло около трети штата после сокращений и отпусков, а ни один временно исполняющий обязанности не был утверждён Сенатом. В таких условиях процессы по контролю подрядчиков и аудиту репозиториев предсказуемо проседают — и тот факт, что утечку у регулятора по кибербезу нашёл частный сканер, а не внутренние инструменты, красноречивее любого внутреннего отчёта.

Что делать в своей команде, чтобы не повторить историю CISA

История CISA читается как готовый чеклист «как не надо». Перевернём его в «как надо» — для команд от стартапа до крупного бизнеса.

1. Включите GitHub push protection на уровне организации и запретите её отключать. Owner organization → Security → Secret protection → Push protection: Enabled.
2. Запретите коммитеры-индивидуумам быть owner репозиториев в проде. Любой публичный репозиторий компании должен принадлежать организации с настроенными правилами.
3. Сканируйте свою историю, а не только новые коммиты. Один раз пропущенный .env остаётся в Git forever — поможет TruffleHog, GitGuardian, GitHub Advanced Security или встроенный git-secrets.
4. Не используйте Git как файлообменник между домашним и рабочим компьютером. Для этого есть VPN, корпоративный OneDrive, S3-бакет с IAM, в конце концов — scp.
5. Включите автоматическую ротацию ключей AWS и сервис-токенов. Даже если они утекут, окно использования закроется через сутки-двое.
6. Настройте мониторинг подозрительных вызовов API в облаке. Для AWS — CloudTrail + GuardDuty с алертами на новые регионы, необычные IAM-действия и обращения к AWS API из неизвестных IP. Если ключ всё-таки утёк — вы узнаете об этом по логам, а не из новостей.
7. Раз в квартал проводите аудит публичных репозиториев: gh repo list ORG --visibility public и быстрая проверка, что там должно лежать публично.

GitHub в своём блоге называет push protection первой линией защиты и приводит цифру: с момента включения по умолчанию на бесплатных публичных репозиториях функция предотвратила сотни тысяч случайных утечек. Эту настройку выключают именно те, кто потом попадает в новости.

Что говорят сами CISA и эксперты

Сводный ответ агентства для Кребса и TechCrunch звучит как стандартная PR-формула. TechCrunch уточняет, что комментарий дал пресс-секретарь CISA Марко ДиСандро:

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

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

Что в итоге

Сюжет «подрядчик слил ключи в публичный git» повторяется в индустрии раз в пару месяцев, но обычно героем оказывается стартап или подрядчик банка. Случай с CISA выделяется тем, что виновником стало именно то агентство, которое выпускает рекомендации по защите от подобных утечек.

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

Для разработчиков вывод предельно практичный: включите push protection, проверьте свои публичные репозитории, не подсовывайте секреты в Git ни на минуту. История CISA — это просто очень громкая иллюстрация того, как один человек, перетаскивающий файлы с ноутбука на ноутбук через git, способен поставить под угрозу целое ведомство.

Источники: Krebs on Security — CISA Admin Leaked AWS GovCloud Keys on Github; GitGuardian Blog — How We Got a CISA GitHub Leak Taken Down in Under a Day; TechCrunch — US cyber agency CISA exposed reams of passwords and cloud keys to the open web; Gizmodo — «The Worst Leak That I've Witnessed».

Проект написан на Go — языке, с которым автор раньше почти не работал. Весь процесс разработки прошёл через GitHub Copilot CLI: вместо того чтобы разбираться в деталях синтаксиса незнакомого языка, можно было описать нужное поведение и получить работающий код.

GitHub Dungeons — расширение gh extension, которое генерирует рогалик из вашего репозитория прямо в терминале.

Процедурная генерация работает через Binary Space Partitioning (BSP), засеянный SHA последнего коммита — один и тот же код всегда даёт одно и то же подземелье.

Команда /delegate в Copilot CLI передаёт задачу облачному агенту, который работает асинхронно и открывает готовый PR.

«Опасный режим»: можно настроить pre-commit хук, который удалит все несохранённые изменения, если проиграть.

Установка одной командой: gh extension install leereilly/gh-dungeons.

Что такое GitHub Dungeons

GitHub Dungeons — это терминальная игра в жанре рогалик, где каждый уровень генерируется на основе вашей кодовой базы. Комнаты, коридоры и враги строятся из структуры репозитория и отрисовываются прямо в консоли. Навигация — стрелками, WASD или Vim-клавишами. Цель — найти скрытый выход, преодолев пять уровней с нарастающей сложностью.

Рогалики (roguelikes) ведут историю с игры Rogue 1980-х — терминальных приключений, где каждое прохождение генерировало новые подземелья, а смерть означала начало сначала (permadeath). GitHub Dungeons обращается к этой традиции, добавляя инженерный твист: ваш последний коммит задаёт seed генерации — один и тот же код всегда даёт одно и то же подземелье, но каждое изменение перестраивает его.

Как репозиторий превращается в подземелье

Генерация уровней построена на алгоритме Binary Space Partitioning (BSP) — классическом методе процедурной генерации карт в играх. В качестве seed используется SHA последнего коммита репозитория, что обеспечивает детерминированность: один коммит — одно подземелье. Изменился код — изменилась карта.

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

Как работает Binary Space Partitioning

BSP — это рекурсивное разбиение пространства на прямоугольные регионы. Алгоритм прост в объяснении, но даёт именно тот баланс между структурой и хаосом, который нужен рогаликам:

1. Начало. Весь уровень — один большой прямоугольник.
2. Разбиение. Пространство делится на два региона (горизонтально или вертикально). Каждый регион снова делится. И снова.
3. Остановка. Разбиение прекращается, когда регион становится слишком маленьким для комнаты.
4. Комнаты. Каждый конечный регион становится комнатой. Позиция и размер слегка рандомизируются — чтобы карта не выглядела как сетка.
5. Коридоры. Алгоритм обходит дерево разбиений в обратном порядке и соединяет соседние комнаты L-образными коридорами.
6. Результат. Карта выглядит спроектированной, хотя создана алгоритмически. Все комнаты достижимы, нет тупиков.

BSP решает две главные проблемы процедурной генерации: чистый рандом даёт хаотичные карты, регулярные сетки — предсказуемые. BSP находит баланс: структурированный хаос, где каждый забег выглядит по-разному, но остаётся проходимым.

Разработка с GitHub Copilot CLI

Ли Рейли написал GitHub Dungeons на Go — языке, которым он не пользовался регулярно. Copilot CLI позволил сосредоточиться на поведении игры, а не на синтаксисе: вместо того чтобы вспоминать, как работают горутины, можно было описать нужное поведение и получить работающий код.

Команда /delegate: асинхронный агент

Ключевым инструментом в разработке стала команда /delegate. В отличие от обычного автодополнения, /delegate передаёт задачу облачному агенту Copilot, который работает асинхронно. Разработчик описывает задачу на естественном языке, запускает делегирование и может заниматься чем-то другим. Когда агент завершает работу, он открывает pull request с результатами.

Например, команда /delegate с описанием задачи на естественном языке вернула готовую реализацию прогрессии сложности в виде PR. Автор просмотрел результат, подправил баланс и влил изменения. Тот же подход использовался для читкодов, системы туман войны и документации.

Работа с Copilot (особенно через /delegate) — это как иметь армию NPC, готовых делать всё, что я скажу.

Команда /yolo: живёшь только раз

Для проекта о рогалике команда /yolo оказалась особенно уместной: это алиас для /allow-all, который разрешает Copilot CLI выполнять все действия без дополнительных подтверждений. «You only live once» — именно это слоган permadeath-механики рогаликов. В разработке /yolo ускоряет итерации: не нужно подтверждать каждое действие агента.

Copilot также сгенерировал «dungeon scribe» — вспомогательного агента, который добавил документацию и ASCII-диаграммы, объясняющие генерацию подземелий. Это органично вписалось в стиль терминального рогалика.

Установка и игра

Для запуска нужен установленный GitHub Copilot CLI. Расширение устанавливается одной командой:

После установки запустите игру в директории любого репозитория:

Управление: стрелки, WASD или Vim-клавиши (hjkl). Цель — найти скрытую дверь и сбежать через пять уровней, сражаясь с врагами и собирая зелья здоровья. Автоатака, туман войны, счётчик убийств и уровней входят в комплект. Остальные возможности придётся обнаружить самостоятельно.

Опасная зона: pre-commit хук с ставками

Для тех, кто хочет испытать настоящий permadeath в духе рогаликов, автор предлагает привязать игру к git-коммитам. Pre-commit хук запускает GitHub Dungeons перед каждым коммитом: если проигрываете — все несохранённые изменения удаляются.

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

Выводы

GitHub Dungeons — эксперимент, который демонстрирует несколько интересных вещей одновременно. Во-первых, Copilot CLI меняет паттерн разработки: когда агент берёт на себя незнакомый синтаксис и рутину, разработчик остаётся в режиме дизайнера механик, а не кодировщика. Для этого рогалика это означало итерации по балансу, тайным кодам и пасхалкам вместо бесконечной отладки Go-специфики. Во-вторых, классические алгоритмы вроде BSP решают современные задачи: детерминированный seed из SHA коммита — это не случайность, а осмысленная связь между состоянием кода и состоянием игры. Каждый мердж меняет карту.

Попробовать GitHub Dungeons можно в любом репозитории: github.com/leereilly/gh-dungeons. Оригинальный разбор от автора — на GitHub Blog. Установите, запустите gh dungeons в своём репозитории — и посмотрите, каким подземельем стал ваш последний коммит.

1. Как я утонул в генерациях
2. Экзамен вместо «прыжков» по сервисам
3. Небольшой технический конвейер
4. Зачем цифры важнее впечатлений
5. Простой тест на форматы
6. Как ведут себя Riverflow, Flux и Seedream
7. Отчёты, артефакты и спокойная аналитика
8. Сценарий «восемь формулировок»
9. Зрелый подход к выбору AI

В прошлой статье я рассказывал, как собрал тестовый стенд для AI‑генерации. Теперь — про то, как превратил его в живой процесс с разными сценариями и метриками.

1. Как я утонул в генерациях

Я осознал что в очередной раз листал чат и не мог найти тот самый удачный вариант обложки.

Ситуация повторялась по одному и тому же шаблону. Запускаю один сервис — получаю результат, морщу лицо и сразу иду в другой. Там промпт приходится переформулировать: движок по-другому читает слова. В третьем генераторе наконец складывается приятная композиция, но детализация рушит весь смысл. Через пару дней на диске лежит россыпь PNG, а я уже не понимаю, где оказался осознанный успех, а где просто повезло. В какой-то момент я сказал себе: стоп. Случайные «попробую тут, попробую там» не ведут никуда.

2. Экзамен вместо «прыжков» по сервисам

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

3. Небольшой технический конвейер

Реализация получилась до обидного простой. Node.js, TypeScript, запуск через tsx. Список моделей вынесен в отдельный конфиг, API-ключ лежит в .env, а команды запуска выглядят вроде npm run test:niche или npm run test:collage-2x2-eight-prompts. Я взял творческий хаос и сложил его в аккуратный pipeline.

Дальше всё происходит автоматически: запускаешь тест — и один и тот же набор задач последовательно проходит через всех кандидатов. Мой вклад заканчивается на нажатии Enter.

4. Зачем цифры важнее впечатлений

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

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

5. Простой тест на форматы

Возьмём самый базовый пример — проверка соотношения сторон. Формулировка элементарная: закат над горами, три варианта — 3:4, 1:1 и 16:9. Казалось бы, минимальный уровень адекватности. Но нет.

Достаточно пробежать глазами столбец со статусом. Три запроса — три быстрых проверки «на глаз». Там, где на 3:4 и 16:9 горит FAIL, модель откровенно игнорирует задачу и рисует квадрат или удобный для себя формат. И это при том, что промпт простейший: не сложная сцена, не коллаж — всего лишь «закат, горы и нужная рамка».

6. Как ведут себя Riverflow, Flux и Seedream

Если посмотреть на результаты, riverflow-v2-pro аккуратно соблюдает все три формата. Но за эту аккуратность приходится платить временем: портретная картинка генерируется около 360 секунд. Шесть минут — роскошь, если у вас в руках горящий дедлайн. Упрощённая версия, riverflow-v2-fast, выдаёт правильные форматы за секунды и остаётся в адекватных рамках по времени — это уже инструмент для реальных задач.runware+2

С моделями Flux история другая. Почти вся линейка black-forest-labs стабильно промахивается по нестандартным форматам: колонка «Соотношение» упорно показывает 4/3 или 1/1, хотя в запросе чётко указано «16:9, wide landscape». Относительно ровно ведёт себя только flux.2-max, который хотя бы честно выдаёт квадрат, но проблемы с другими соотношениями никуда не деваются.github+1

Seedream-4.5 от Bytedance, напротив, поражает скоростью: ответы прилетают за 7–8 секунд, но модель регулярно игнорирует заданный формат и возвращает квадрат 2048×2048. Для макета, привязанного к конкретным пропорциям — сторис, постера или баннера — такая «быстрота» только ломает всю вёрстку.eachlabs+1

7. Отчёты, артефакты и спокойная аналитика

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

Особенно сильно это помогает в задачах, где критична композиция: нужна ровная сетка 2×2 или 3×3 без самодеятельности в духе «я тут чуть подвину, так красивее». Это как раз те случаи, когда от сервиса нужна дисциплина, а не внезапные художественные «инициативы».

8. Сценарий «восемь формулировок»

Отдельный пласт наблюдений даёт сценарий «восемь формулировок» (collage-2x2-eight-prompts). Суть задачи не меняется, контент остаётся одним и тем же. Я варьирую только подачу: где-то пишу запрос грубо и коротко, где-то — щадяще и структурно, местами добавляю лишний контекст.

На этом месте становится видно, как модель реагирует не на саму тему, а на стиль запроса. Одна и та же нейросеть спокойно выдерживает строгое техническое ТЗ и проваливается при формулировке «сделай красиво, сам понимаешь». После таких тестов по-другому относишься к промптам: начинаешь формулировать точнее, понимая, какая модель как «слушает» текст. И внезапно исчезают загадки в духе «почему здесь получилось, а там всё развалилось».

9. Зрелый подход к выбору AI

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

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

Это не рутинное объявление об увеличении кластера. Если самый закалённый разработческой инфраструктуры игрок планеты говорит «в 10 раз — уже мало», значит фундаментальные предположения о том, как производится софт, сместились быстрее, чем GitHub успел заложить в собственные планы. Все, кто строит ниже по течению — на тех же предположениях, — попадают под тот же сдвиг.

Сигнал. CTO GitHub Влад Фёдоров: октябрьский план мощностей в 10 раз к 2026 году устарел уже к февралю — нужен план в 30 раз из-за роста AI-агентного кода.

Bottleneck не в железе. CI справится с любым потоком; не справляется валидация — очередь ревью, стенды staging, интеграционные тесты.

Стоимость поиска бага растёт по стадиям. Внутри цикла разработки — почти ноль; в CI — полный цикл сборки; в staging — деплой и очередь к стенду; в production — инцидент, откат и отдельный revert-PR.

Структурный ответ. Сдвиг валидации в inner-loop, где агент сам прогоняет изменение против реальной системы до создания PR.

Что делать командам. Отделить «compile-clean» от «correct», встроить эфемерные окружения в inner-loop агента, не наращивать слепо мощности CI.

Почему GitHub переписал план мощностей

В апреле 2026 года у GitHub было два крупных инцидента — внутренний апдейт об их разборе содержал ключевой абзац:

Мы начали в октябре 2025 года план по 10-кратному наращиванию мощностей GitHub с целью существенно улучшить надёжность и failover. К февралю 2026 стало ясно, что нужно проектировать под будущее, требующее 30-кратного объёма от текущего.

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

Объём становится проблемой, когда не конвертируется в throughput

30-кратный рост производства кода в идеальном мире давал бы 30-кратный рост поставленных фич. На практике SDLC никогда не превращал объём кода в релизную функциональность 1:1. Конверсия теряется на одном и том же этапе — валидация.

До прихода агентов это уже было больно: тест-сьюты по часу, постоянно перегруженные стенды staging, интеграционные баги, всплывающие на release candidate, очереди review, в которых сидят единственные люди, способные определить, безопасно ли изменение. Валидация — самая медленная, самая зависящая от человека и самая ошибкоёмкая часть цикла, и она встроена между «код написан» и «код задеплоен».

В cloud-native архитектурах эта проблема обостряется. Современное приложение — это граф сервисов, каждый со своим состоянием, зависимостями, темпом релизов. Изменение одного сервиса прокатывается по половине соседних, а ломается обычно то, что не видно в исходниках: contract drift (несовпадение договорённостей между сервисами), race conditions, edge-кейсы мульти-тенантности, поведение под нагрузкой.

Где ловить баг — там и платить

Стоимость найденного бага компаундится в зависимости от стадии:

• Inner loop (агент или разработчик ещё итерирует) — почти ноль.
• CI — полный цикл сборки.
• Staging — деплой + слот в очереди + время валидаторов.
• Production — инцидент, rollback, revert PR, который сам идёт через тот же pipeline.

При человеческой скорости разработки SDLC поглощал часть этой неэффективности — объём ограничивался числом инженеров. На скорости и масштабе агентов поглощать перестаёт: задержка превращается в постоянно растущий backlog. Поэтому ответ — не «больше мощностей CI, больше стендов staging, больше ревьюеров». Это тактический отклик на структурный сдвиг.

Замкнуть петлю — там, где код пишется

Структурный ответ — сдвинуть валидацию максимально влево, прямо в inner loop, где агент порождает код. Сегодня агенты для кодинга — это половина рабочей системы: они пишут код на беспрецедентной скорости, но не могут самостоятельно проверить, правильно ли он ведёт себя в распределённой системе. Compile-clean ≠ correct. Unit-тесты проверяют ровно то, что они скоупят.

Поэтому агент делает единственное, что может — объявляет изменение готовым и пушит вниз по pipeline, где работа по «а оно вообще пашет?» падает на ревьюера, интеграционные тесты, деплой на staging или инцидент в production. И вся компаундящаяся стоимость валидации включается на полную.

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

Почему не справляются текущие подходы

• Mocks — подделывают поведение зависимостей и проходят мимо реальных.
• Unit-тесты — покрывают индивидуальные функции, не интеграционную поверхность.
• Зелёный CI — говорит, что протестированное прошло. Это не равно «изменение корректно».

Чтобы петля действительно замкнулась, агенту нужно прогнать кандидата против настоящего состояния системы, а не модельного. И это требует инфраструктуры, которой массово в командах ещё нет: эпемерные окружения, изолированные на уровне one-PR-one-environment, с реальными зависимостями.

Чек-лист для тимлидов

1. Замерить текущую валидационную «вилку»: время от commit до зелёного staging для среднего PR. Если оно растёт — bottleneck уже здесь.
2. Посчитать долю PR-ов с rollback или revert. Если rollback-rate растёт месяц к месяцу — петля у агентов открытая.
3. Запустить пилот с ephemeral environments на одном из сервисов с самым большим интеграционные накладные расходы. Сравнить за 4 недели: процент PR-ов, прошедших валидацию с первого раза.
4. Не наращивать мощности CI «в ширину» как первый ответ. Это лечит симптом, не причину.
5. Дать агенту сигналы во время выполнения (не только compile + unit). Без них следующий шаг качества кода невозможен.

Выводы

Объём кода, генерируемого AI-агентами, растёт быстрее, чем планировали даже в GitHub. Стратегический вопрос для каждой инженерной организации сейчас простой: ваши агенты работают в замкнутой петле или открытой? Замкнутая — мультипликатор на throughput команды. Открытая — мультипликатор на те самые валидационные bottleneck-и, которые и так были самым узким местом.

Похожий тренд мы недавно разбирали в материале про tokenmaxxing: AI-ассистенты дают двукратную выработку кода ценой десятикратных затрат токенов и роста code churn на 861%. Природа проблемы одна: код производится массой, а инфраструктура к этому не готова.

Источник: The agent code explosion is here. We need to rethink our pipelines, fast — The New Stack.

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

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

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

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

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

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

, чтобы приватный ключ жил внутри браузерного crypto runtime и его нельзя было экспортировать в байты. Но у этого подхода есть практическая сложность: ключи нужно переживать между перезагрузками страницы, синхронизировать с IndexedDB, аккуратно восстанавливать состояние устройства и не сломать UX.

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

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

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

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

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Мы остановились на открытом симуляторе InferSim от Alibaba. Он умеет считать TTFT, TPOT и пропускную способность без запуска реального инференса. Но из коробки поддерживает только несколько топовых GPU и фиксированный набор моделей — для наших сценариев этого было недостаточно. Пришлось дорабатывать.

Как устроен InferSim

В основе симулятора — двухфазная схема. Сначала на целевом железе запускаются микро-бенчмарки: измеряется реальная производительность на типовых операциях внимания и матричных умножениях. Получается таблица коэффициентов Model FLOPs Utilization (MFU) — сколько процентов от теоретического максимума выдаёт конкретная карта на конкретной операции. Затем, уже без доступа к GPU, симулятор на основе этих MFU и аналитической модели вычисляет задержки. Именно такой подход даёт более точные предсказания, чем оценка по паспортной пропускной способности памяти.

Добавляем своё железо

Первым делом мы внесли в hardware/gpu.py поддержку MetaX C500 64GB. Характеристики добавляются через dataclass-экземпляры:

После этого c500 попадает в словарь gpu_map, и симулятор запускается с ключом --device-type C500 --world-size 2. Значения FLOPS и пропускной способности пришлось оценивать по косвенным источникам — производитель не публикует точных цифр. Позже планируем уточнить их через бенчмаркинг на реальном оборудовании. Таким же способом добавили Nvidia 1xH100 и A100.

Конфигурация моделей и одна болезненная ошибка

Симулятор ожидает стандартный config.json в формате Hugging Face. Для Qwen3-32B подготовили файл qwen3_32b_config.json:

Ключевой момент — правильное значение head_dim. У Qwen3-32B оно равно hidden_size / num_attention_heads = 5120 / 64 = 80. У нас ушло некоторое время, чтобы понять, почему симулятор выдаёт невалидные результаты: изначально в конфиге стояло значение 128. Пока не исправили — KV-кеш переоценивался, и метрики улетали в неадекватные цифры. После исправления всё встало на свои места.

Позже добавили поддержку Qwen3.5‑9B с её гибридной архитектурой, построенной на чередовании Gated DeltaNet и Gated Attention. Главная особенность модели в том, что около трёх четвертей слоёв не создают привычного KV‑кеша, а используют линейное внимание – компактное скрытое состояние, которое лишь обновляется с каждым новым токеном, не увеличиваясь в объёме. Это кардинально снижает расход памяти на длинных контекстах, но привносит и свою цену: на коротких дистанциях такая модель проигрывает в скорости Prefill, потому что Gated DeltaNet работает последовательно и хуже утилизирует матричные вычисления GPU.

Симулятор изначально не умел различать слои двух типов и считал весь KV‑кеш одинаково. Чтобы поддержать Qwen3.5, пришлось доработать расчёт задержек в классе HybridModel: теперь он отдельно обсчитывает full‑attention‑слои с полным кешем и linear‑attention‑слои без кеша, используя параметры num_full_attn_layers и num_linear_attn_layers из конфигурации. В директорию проекта models добавили hybrid_model.py, в котором сделали дополнительные расчёты:

Без такой дифференциации симулятор для Qwen3.5‑9B показывал E2E порядка 2 500 секунд вместо реальных нескольких секунд – та ошибка, которую мы долго отлавливали.

Визуализация и эксплуатация

Чтобы не разбирать каждый раз текстовый вывод InferSim, сделали веб-интерфейс на Streamlit. Симулятор дёргается через subprocess, результаты парсятся из stdout и визуализируются:

• тепловые карты задержек (Prefill, Decode, E2E Total) для разных длин входных и выходных токенов;
• анализ RPS с расчётом требуемой параллельности и сравнением с доступной памятью;
• информация о занятой памяти в формате «X ГБ из Y ГБ».

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

Приложение упаковано в Docker и лежит в репозитории на GitHub. Сервисы — сам Streamlit и Nginx в качестве обратного прокси с SSL-терминацией и базовой HTTP-аутентификацией. Деплой на VDS автоматизирован через GitHub Actions: собрали образ, отправили на сервер, перезапустили контейнеры. SSL-сертификаты Let's Encrypt обновляются по cron.

Что в итоге

Адаптированный InferSim не претендует на абсолютную точность — она ограничена качеством бенчмарков и коэффициентов MFU. Но инструмент позволяет избежать грубых ошибок при планировании, что в условиях ограниченного доступа к GPU и их высокой стоимости само по себе немало. Мы продолжаем калибровку симулятора и готовим обновлённые конфигурации для следующих моделей.

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

CVE-2026-3854 — RCE-уязвимость в обработке push-опций git, CVSS 8.7. Нашли её исследователи Wiz, отправили в bug bounty программу 4 марта 2026 года. GitHub воспроизвёл уязвимость за 40 минут, выкатил фикс на github.com ещё через 35 — итого «менее чем за два часа», как сами они округлили. Bounty payout — один из крупнейших в истории GitHub Bug Bounty; публично программа платит от $30 000 за критические RCE-находки.

Под удар попали все варианты GitHub: github.com, GitHub Enterprise Cloud (включая Data Residency — изолированные облачные инстансы для регулируемых отраслей — и Enterprise Managed Users — корпоративный SSO-tenant), и GitHub Enterprise Server (GHES, самохостинг). Клиентам Cloud делать ничего не нужно — там пропатчили в день репорта. Админам GHES — обновиться до последнего патча в вашей мажорной ветке и пройтись по аудит-логам.

CVE-2026-3854 (CVSS 8.7) — RCE через push-опции git. Любой пользователь с push-доступом к репозиторию мог выполнить команды на сервере, обрабатывающем его пуш. Один git push --push-option=... и сервер выполнял чужой код.

Нашёл Wiz, репорт через bug bounty 4 марта 2026 года. github.com закрыли в тот же день, через 1 час 15 минут после получения. Форензика следов эксплуатации не нашла — все срабатывания уязвимого кодового пути в логах сошлись на тестах самих Wiz.

Затронуты: github.com, GitHub Enterprise Cloud (плюс Data Residency и Enterprise Managed Users), GitHub Enterprise Server. Cloud-варианты пропатчены 4 марта, GHES — теперь публично.

Для GHES — обновляться сейчас. Патчи: 3.14.25 / 3.15.20 / 3.16.16 / 3.17.13 / 3.18.7 / 3.19.4 / 3.20.0 и новее. Эксплуатация требует пользователя с push-доступом, но на корпоративном инстансе это часто весь штат разработчиков.

Bounty payout — один из самых больших в истории GitHub Bug Bounty, по словам самих GitHub. Точную сумму не назвали, но программа публично платит от $30 000 за критические RCE-находки и допускает доплаты сверху за исключительные репорты.

Что такое push-опции и зачем они нужны

git push --push-option=foo=bar — это легитимная фича git: при пуше клиент передаёт серверу произвольные пары ключ-значение. На сервере хуки видят их через переменные окружения GIT_PUSH_OPTION_* и могут использовать для сигналов вроде «обойти проверку pre-receive в этот раз», «уведомить вот такой пайплайн в CI», «явно пометить пуш как hotfix». Сама фича в git с сентября 2016 года (релиз 2.10), включить можно флагом, конфигом push.pushOption или git-алиасом.

Внутри GitHub push-опции едут через служебный межсервисный протокол: метаданные о пуше — тип репозитория, кто пушит, в какое окружение его обработать — складываются в служебную строку и передаются между микросервисами. Именно в этой строке и обнаружилась дыра.

Что было в инъекции

Разделителем полей во внутреннем протоколе была точка с запятой ;. GitHub в техническом разделе своего блога её прямо не называет, но в рекомендациях для админов GHES просит искать ; в /var/log/github-audit.log — оттуда видно, какой именно символ был делимитером. Та же точка с запятой могла оказаться в значении push-опции, переданной пользователем, из-за чего и появлялась инъекция.

Дальше — классическая инъекция, как SQL-injection, только не в базу, а в служебный протокол между микросервисами GitHub. Пользователь подсовывает push-опцию вида foo=bar;trustedField=..., сервер бережно складывает её в строку метаданных, downstream-сервис парсит строку, видит «лишнее» поле и интерпретирует его как доверенное внутреннее значение. Сцепив несколько таких полей подряд, исследователи добились трёх вещей: переопределили окружение, в котором обрабатывался пуш; обошли sandbox, который обычно ограничивает выполнение хуков; и выполнили произвольные команды на сервере.

Самое неприятное — для атаки не нужен был никакой доступ к чужим репозиториям. Достаточно собственного приватного репозитория, который можно создать за 5 секунд и закрыть от всех остальных. С push-доступом к этому репозиторию атакующий получал shell на инфраструктуре, обрабатывающей пуш — на github.com это shared-инфраструктура, через которую идут пуши всех пользователей.

Хронология: 55 дней приватного фикса

• 4 марта 2026, 17:45 UTC — Wiz отправляют репорт в bug bounty.
• 4 марта 2026, 18:25 UTC — GitHub воспроизводит уязвимость внутри (через 40 минут).
• 4 марта 2026, 19:00 UTC — фикс выкачен на github.com (через 1 час 15 минут после репорта).
• 4 марта — параллельно закрыто на GitHub Enterprise Cloud (все варианты).
• Март-апрель — приватная работа над GHES патчами + форензика по логам.
• 28 апреля 2026 — публичный пост, релизы GHES, выдан CVE-2026-3854.

Полтора месяца молчания — потому что у GHES медленный цикл релизов и нужно было параллельно подготовить патчи для всех поддерживаемых мажорных веток. Параллельно GitHub перерыл логи: уязвимый кодовый путь в нормальной работе не дёргается совсем, поэтому любое его срабатывание в телеметрии — кандидат на exploit. Все обнаруженные срабатывания сошлись на тестовой активности самих Wiz, других следов не нашли.

Сама архитектура атаки им в этом помогла. Эксплойт заставляет сервер пройти по кодовому пути, который никогда не используется в нормальной работе github.com — это прямое следствие того, как именно работает инъекция. Атакующий не может «спрятаться» в обычном трафике: каждое его срабатывание остаётся в телеметрии как явная аномалия.

Кого затронуло

Под уязвимость попали все площадки GitHub:

• github.com (публичная площадка) — пропатчена 4 марта 2026.
• GitHub Enterprise Cloud — пропатчен 4 марта.
• GitHub Enterprise Cloud with Data Residency — пропатчен 4 марта.
• GitHub Enterprise Cloud with Enterprise Managed Users — пропатчен 4 марта.
• GitHub Enterprise Server (GHES, self-hosted) — патчи 28 апреля 2026.

Эксплуатация на GHES требует аутентифицированного пользователя с push-доступом на конкретный инстанс. На корпоративных серверах это, как правило, весь штат разработчиков и любой внешний контрактник, которого пустили в проект. То есть для большинства компаний это эквивалент «локальный пользователь → root на сервере GitHub».

Что делать админам GHES

Обновитесь до одного из следующих релизов в вашей мажорной ветке (или новее):

• GitHub Enterprise Server 3.14.25
• GitHub Enterprise Server 3.15.20
• GitHub Enterprise Server 3.16.16
• GitHub Enterprise Server 3.17.13
• GitHub Enterprise Server 3.18.7
• GitHub Enterprise Server 3.19.4
• GitHub Enterprise Server 3.20.0 или позже

После обновления — пройдитесь по /var/log/github-audit.log и поищите push-операции, в push-опциях которых встречается символ ;. GitHub рекомендует это сделать «из соображений предосторожности» — exploitation на github.com они не нашли, но GHES — это ваш инстанс, и логи только у вас. Команда на коленке:

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

Defense in depth: как туда попал лишний код-путь

GitHub в том же посте признаются в дополнительной находке. Уязвимый кодовый путь не должен был быть доступен в той среде, в которой он отрабатывал. Раньше деплой явно его исключал — путь нужен был только для другой конфигурации продукта. Когда модель деплоя поменяли, исключение не перенесли, и код-путь начал лежать на диске рядом с продакшен-обработчиком пушей.

Это не первичный баг — без injection до этого кода всё равно было не дотянуться. Но это второй слой обороны, которого здесь не оказалось. GitHub отдельно зачистил окружения от лишнего, и теперь даже при гипотетической второй injection через push-опции там просто нечего эксплуатировать.

Урок: при смене модели деплоя пересматривайте список того, что в этой модели не должно быть доступно. Каждый кодовый путь — отдельный кусок атак-поверхности, и держать его «на всякий случай» обходится дороже, чем удалить.

Выводы

CVE-2026-3854 — учебный пример инъекции через делимитер во внутреннем протоколе. Ничего экзотического: пользовательский ввод попал в служебную строку, разделитель совпал, downstream-парсер посчитал «лишнее» доверенным. То, что такая дыра прожила какое-то время в одном из самых внимательных к безопасности продуктов индустрии, — отдельная иллюстрация, насколько живучи такие классы багов даже у зрелых команд.

40 минут на репродукцию и 1 час 15 минут на патч в продакшен — впечатляющие цифры incident response. GitHub отрабатывает такие кейсы постоянно, но всё равно показательно: расследование, фикс, прогон через CI и выкат на github.com уместились в один кофе-брейк команды.

Источники: официальный пост в GitHub Blog, advisory CVE-2026-3854, технический разбор Wiz. Если у вас GHES — обновитесь, проверьте логи, идите дальше. Если только аккаунт на github.com — благодарите security-команду GitHub: вы узнали об этой истории, когда её уже не было.

• Скомпрометирована одна npm-версия @bitwarden/cli@2026.4.0. Окно атаки — 1 час 33 минуты 22 апреля 2026 года.
• Vault-данные пользователей Bitwarden не затронуты. Пострадал только npm-канал доставки CLI и те, кто успел поставить эту сборку.
• Вектор — скомпрометированный action checkmarx/ast-github-action, который Bitwarden подтягивал в свой CI. По словам исследователей, это первый зафиксированный взлом пакета через npm trusted publishing.
• Малварь таргетит ИИ-ассистенты Claude, Cursor, Codex CLI, Aider и AWS-based Kiro — отдельный модуль собирает их конфиги и API-ключи.
• Если ставили — ротируйте npm/GitHub-токены, SSH-ключи и облачные креденшлы AWS/Azure/GCP; проверьте CI/CD-пайплайны и публичные репозитории со строкой «Shai-Hulud» в имени.

Что случилось с пакетом

По данным The Hacker News, в ночь с 22 на 23 апреля 2026 года в npm-реестре появилась версия @bitwarden/cli@2026.4.0 с дополнительным файлом bw1.js внутри. Сборка была доступна 1 час 33 минуты — с 17:57 до 19:30 по времени Нью-Йорка, — после чего её сняли с публикации. Первыми на неё обратили внимание исследователи Socket, JFrog и OX Security. JFrog описал поведение как «кражу GitHub/npm-токенов, содержимого .ssh, .env, истории shell, секретов GitHub Actions и облачных провайдеров с выгрузкой на внешние домены и в виде коммитов в GitHub».

Bitwarden подтвердил инцидент и уточнил, что «расследование не обнаружило признаков доступа к данным пользовательских хранилищ и компрометации продакшн-систем». По словам компании, доступ нарушителя был отозван, вредоносный релиз помечен как deprecated, по версии 2026.4.0 заводится отдельный CVE. Пострадавшие — только те, кто успел скачать пакет в полуторачасовом окне и выполнил его установку.

Как устроен троян

Механика по отчёту Socket проста, но многоступенчата. В package.json зловредной версии добавлен preinstall-хук, который запускает скрипт bw_setup.js. Тот проверяет наличие Bun — альтернативного JS-рантайма — и, если его нет, скачивает. Затем Bun-ом запускается обфусцированный загрузчик bw1.js. Bun тащат с собой не случайно: на машине жертвы его, скорее всего, нет, а корпоративный EDR (антивирус нового поколения для рабочих станций и серверов) реагирует на неожиданный бинарник хуже, чем на стандартный npm-скрипт. Preinstall-хук при этом срабатывает ещё до того, как код пакета формально «установлен».

• npm- и GitHub-токены из локальных конфигов и переменных окружения;
• приватные SSH-ключи из ~/.ssh;
• содержимое .env-файлов и историю shell (.bash_history, .zsh_history);
• секреты GitHub Actions из переменных окружения CI;
• креденшлы облачных провайдеров — AWS, Azure, Google Cloud;
• конфиги и API-ключи ИИ-ассистентов Claude, Cursor, Codex CLI, Aider и AWS-based Kiro.

Собранные данные шифруются AES-256-GCM и выгружаются двумя каналами. Основной — POST на домен audit.checkmarx[.]cx (конкретно путь /v1/telemetry), который притворяется инфраструктурой Checkmarx. Резервный — малварь создаёт публичные GitHub-репозитории в аккаунте жертвы и кладёт туда зашифрованный payload. В названиях репозиториев встречается строка «Shai-Hulud: The Third Coming» — отсылка к прошлогодней одноимённой кампании в npm. OX Security подчёркивает, что такой тайник (по терминологии безопасников — dead-drop) через GitHub опасен отдельно: утёкшие секреты становятся доступны любому, кто ищет по публичным репозиториям, — а системы защиты почти не следят за исходящим трафиком в GitHub.

Поверх этого в бинарнике есть модуль-червь: с украденным npm-токеном малварь находит все пакеты, которые жертва имеет право публиковать, и вбрасывает в них тот же payload. Endor Labs называет его «CanisterSprawl» и считает один из самых полных npm supply chain-пейлоадов на сегодняшний день: шесть разных поверхностей для сбора секретов, OIDC- и cloud-кража, самораспространение через npm-публикации и отдельный модуль для ИИ-ассистентов.

Отдельный удар по ИИ-ассистентам

Отдельный модуль малвари специально ищет артефакты ИИ-кодеров — API-ключи OpenAI и Anthropic из конфигов Claude, Cursor и Codex CLI, токены Aider, настройки AWS-based Kiro. Endor Labs считает, что это один из первых публично задокументированных случаев, когда supply chain-атака отдельной веткой целится на «кошельки разработчиков у ИИ». Ключ к Anthropic или OpenAI — это не только деньги на балансе аккаунта жертвы, но и возможность с его помощью заставить ИИ-ассистента писать закладки в код при следующих авто-запросах.

Почему малварь пропускает русскую локаль

Малварь завершается без выполнения, если в системе выставлена русская локаль. Socket отмечает три возможных причины: отдельный оператор, использующий общую инфраструктуру, отколовшаяся группа с идеологическими мотивами или эволюция самой кампании. На практике для российских разработчиков это не даёт защиты: большинство dev-машин, серверов и CI-раннеров работают с англоязычной локалью по умолчанию (обычно en_US.UTF-8), поэтому пропуск по локали чаще всего не срабатывает.

Что делать, если могли установить 2026.4.0

• Сначала убедитесь, что пакет действительно попал в ваши машины и раннеры: прогрепайте package-lock.json, pnpm-lock.yaml и yarn.lock на @bitwarden/cli версии 2026.4.0, посмотрите логи npm-установок в ночь на 23 апреля МСК.
• Ротируйте все токены с этих машин: npm-токены, GitHub PAT (включая fine-grained), SSH-ключи, AWS access/secret keys и STS-сессии, Azure SP, GCP service accounts.
• Замените секреты в GitHub Actions и других CI-системах, где пакет мог запускаться, — включая secrets, variables и OIDC-конфигурации.
• Пройдитесь по API-ключам ИИ-ассистентов (Anthropic, OpenAI, Cursor, Aider) и отзовите их в кабинетах провайдеров; сверьте биллинг на предмет аномальных трат.
• Проверьте публичные репозитории в своём GitHub-аккаунте: ищите имена в формате <слово>-<слово>-<3 цифры> (например, fremen-muaddib-042) со строкой «Shai-Hulud» в README и удалите.
• Откатитесь на безопасную версию CLI — 2026.3.x или актуальную стабильную, которую Bitwarden опубликовал после инцидента. Ставьте её через npm i @bitwarden/cli@<версия>, а не через latest или диапазон.

Связь с Checkmarx и первый взлом через npm trusted publishing

Накануне, 21 апреля, Checkmarx раскрыла собственный инцидент — компрометацию KICS Docker-образов, GitHub-расширений и пакета checkmarx/ast-github-action, который используется во многих CI-пайплайнах. По данным Endor Labs, репозиторий Bitwarden подтягивал именно этот action, и через него злоумышленники получили доступ к npm-каналу. Socket приводит прямые пересечения: тот же домен audit.checkmarx[.]cx, тот же паттерн обфускации __decodeScrambled с seed-значением 0x3039 — технический отпечаток, указывающий на одних и тех же авторов, — плюс тот же приём «украсть → выгрузить в GitHub → распространиться дальше».

Исследователь Аднан Хан утверждает, что это первый зафиксированный случай компрометации пакета, использующего npm trusted publishing — механизм OIDC-публикации, при котором GitHub Actions обменивается на короткоживущий npm-токен без долгоживущих секретов в CI. Его как раз продвигали в ответ на регулярные утечки npm-токенов у мейнтейнеров. На деле trusted publishing оказался не панацеей: если нарушитель получает доступ к GitHub Actions-воркфлоу с правом публиковать пакет, OIDC-токен ему выдаёт сам npm. Атрибуция у исследователей — группа TeamPCP, уже засветившаяся на взломах LiteLLM и Trivy. Аккаунт TeamPCP в X на момент выхода материала заблокирован.

Выводы для npm-экосистемы и supply chain

Случай укладывается в серию ударов по цепочке доставки последних двух недель: Trivy и LiteLLM на PyPI, Axios и PyPI, теперь Checkmarx и Bitwarden. Характерная деталь — защитный слой не спасает: trusted publishing, OIDC и короткоживущие токены не помогают, если злоумышленник уже получил доступ к CI-воркфлоу. Практический вывод: pin-версии в лок-файлах, отдельный CI-аккаунт с минимальными правами, еженедельная ревизия CI-секретов и мониторинг собственного GitHub на появление незнакомых публичных репозиториев. Инвентаризация секретов, которые ходят через CI/CD, перестала быть теоретическим упражнением.

Формально это не повышение цен ($10 Pro / $39 Pro+ / $0 Free остаются). Фактически у Pro-подписчика снизились возможности при прежней цене, а у Pro+ — выросли относительно других тарифов. GitHub объясняет это взрывным ростом агентных рабочих процессов.

— Новые регистрации. На Pro, Pro+ и Student регистрации приостановлены до особого уведомления. Enterprise и Business — работают.

— Opus. С Pro убраны все версии Claude Opus. В Pro+ остаётся Opus 4.7; Opus 4.5 и 4.6 по changelog скоро уйдут и оттуда.

— Лимиты. Две оси — session (пиковая защита) и weekly (7-дневный потолок токенов с учётом мультипликатора модели). Premium requests остались: 300/мес Pro, 1500/мес Pro+, $0,04 за каждый сверх.

— Refund. До 20 мая можно отменить Pro/Pro+ и вернуть деньги за неиспользованную часть.

— Прозрачность. VS Code и Copilot CLI теперь показывают оставшееся usage прямо в UI — когда лимит близко, это видно.

Что именно изменилось

Pro — урезан

Claude Opus с Pro удалён. Пользователь, подписанный на $10 в месяц, теряет доступ к флагманской модели Anthropic. Остаются Haiku 4.5, GPT-5 mini и остальной уровень менее мощных моделей. Weekly-лимит стал жёстче, а session-лимит защищает от всплесков, которые случаются при длинных агентных циклах.

Формально цена $10/мес не изменилась — но по функциональности тариф сократился. Те, кому критичен Opus, фактически вынуждены переходить на Pro+ за $39/мес — это +$29, то есть почти 4-кратный рост.

Pro+ — расширен

Pro+ сохраняет весь каталог моделей, получает лимиты «более чем в 5 раз выше Pro» и 1500 premium-запросов в месяц (у Pro — 300). Плюс остаётся доступ к GitHub Spark. По changelog, Opus 4.5 и 4.6 скоро уйдут и отсюда — останется только Opus 4.7 как единственный Opus-вариант на платформе. С плана Pro весь Opus уже убрали.

Free — без изменений

На Free-тарифе по-прежнему 50 запросов в режиме чата/агента и 2000 автодополнений в месяц. Модели — Haiku 4.5 и GPT-5 mini. Регистрация на Free открыта. Это базовая точка входа для разработчиков, которые только знакомятся с Copilot.

Почему GitHub закручивает гайки

Главная причина — агентные сценарии. Copilot Agent Mode и параллельные подпроцессы — например, через команду /fleet, которая запускает сразу несколько агентов на одну задачу — разворачивают один «запрос» в десятки вызовов модели. GitHub прямо пишет:

Agentic workflows have fundamentally changed Copilot's compute demands… it's now common for a handful of requests to incur costs that exceed the plan price.

Перевод: несколько агентных задач у одного пользователя могут стоить GitHub больше, чем месячная подписка. Weekly-лимит — попытка ограничить активных пользователей на уровне плана, а не выставлять им счёт за перерасход. Overage-ставка $0,04 за premium-запрос остаётся, но теперь есть дополнительный недельный потолок.

Как устроены новые лимиты

Лимиты теперь работают в двух плоскостях:

• Session-лимит — защита от пиков. Поглощает всплеск токенов в одной активной сессии; точную длительность окна GitHub не публикует, сбрасывается относительно быстро
• Weekly-лимит — 7-дневный потолок усреднённых токенов с учётом мультипликатора модели. Дорогие модели (Opus) съедают квоту в несколько раз быстрее, дешёвые (Haiku 4.5) — медленнее
• Premium-запросы — отдельная квота: 300/мес Pro, 1500/мес Pro+ (арифметика 5×300), $0,04 за каждый сверх

Важный момент: premium-квота и weekly-квота независимы. Можно иметь 295 неиспользованных premium-запросов и всё равно упереться в weekly cap, если весь месяц пользоваться Opus на длинных контекстах.

Что делать Pro-подписчику

Три варианта, в порядке возрастания затрат:

1. Перейти на дешёвые модели на Pro ($10 сохраняется). Haiku 4.5 и GPT-5 mini хорошо справляются с типовыми задачами — автодополнение кода, рефакторинг, комментарии. Opus нужен не всегда
2. Апгрейд на Pro+ ($39/мес). Подходит, если часто пользуетесь Claude Opus или запускаете агентные задачи с длинным контекстом. В 5 раз выше лимиты
3. Отменить подписку и получить refund до 20 мая. GitHub возвращает пропорциональную часть оплаты. Полезно, если после изменений Copilot больше не отвечает вашим потребностям

Что с этим делать из России

Copilot официально не оплачивается с российских карт с 2022 года. Обычный путь — иностранная карта + VPN при оформлении. С апрельской паузой на регистрации подписаться на Pro/Pro+/Student сейчас нельзя вообще, даже с иностранной картой. Остаётся только Free tier (50 чат-запросов и 2000 автодополнений в месяц).

Дополнительный нюанс: с 24 апреля 2026 года входные и выходные данные, а также фрагменты кода пользователей Free, Pro и Pro+ по умолчанию используются для обучения моделей. Opt-out есть, но включать его надо вручную — разбирали отдельно. Это отдельное изменение, не связанное с тарифами, но вступает в силу одновременно.

Альтернативы: Cursor, Zed (оба также требуют иностранной карты для pro-тарифов), Copilot CLI с BYOK — «bring your own key»-режим, где вы подключаете собственный API-ключ Anthropic или OpenAI через свой биллинг у провайдера модели. Anthropic принимает оплату через ряд неамериканских методов, так что для ряда российских разработчиков это самый реалистичный путь. Остаётся также Yandex Code Assistant — без санкций, но с менее продвинутыми моделями.

Что это значит

Формально цены не изменились, но это скрытое сужение Pro-тарифа и защита Pro+ от активных пользователей с агентными нагрузками. GitHub откровенно говорит, что длинные агентные задачи обходятся компании дороже, чем подписка, — и перекладывает часть стоимости на пользователей через weekly-лимит и апгрейд-путь к Pro+.

Для частного разработчика, использующего Copilot для рутинных задач, ничего не изменилось — Haiku и GPT-5 mini работают как раньше, premium-квоты те же. Для тех, кто гоняет длинные агентные цепочки через Opus — либо переход на Pro+, либо пересмотр рабочего процесса: использовать plan-mode (агент формирует план без немедленного запуска кода, экономит токены) вместо /fleet, дешёвые модели на простых шагах, точечные premium-запросы на сложных.

Шире — экономика ИИ-моделей всё меньше укладывается в фиксированную месячную подписку. В ближайший год можно ожидать аналогичные шаги у Cursor, Zed и других — либо через изменения лимитов, либо через чистый usage-based-биллинг. Официальный анонс GitHub, актуальные тарифы.

Работа «Six Million (Suspected) Fake Stars on GitHub» принята на ICSE 2026 — ведущую конференцию по программной инженерии. Команда выложила StarScout — открытый инструмент, которым любой разработчик может проверить подозрительный репозиторий.

≈ 6 миллионов фейковых звёзд на 18 617 репозиториях за июль 2019 — декабрь 2024. Раздавали их ≈ 301 000 аккаунтов.

Пик — июль 2024: 16,66% всех репозиториев с 50+ звёздами засветились в фейк-кампаниях. До 2022 года таких было около нуля.

GitHub валидировал находки: 90,42% помеченных репозиториев и 57,07% аккаунтов сам платформа удалила к январю 2025.

Большинство фейк-кампаний — не маркетинг, а malware: фишинг под видом читов, крипто-ботов и пиратского софта. Остальные — ИИ/LLM-проекты, блокчейн, утилиты, демо.

Растёт только короткое время. Эффект фейковых звёзд держится менее двух месяцев — потом trending смещается к свежим проектам, а репозиторий оседает в публичных списках подозрительных.

Почему звёзды стали валютой

Звёзды на GitHub — это аналог лайков. Главный публичный сигнал «этому проекту доверяют». На них смотрят разработчики, выбирающие зависимость; рекрутеры, оценивающие пет-проекты; инвесторы, оценивающие стартапы вокруг open source. Сам GitHub использует звёзды для ранжирования в trending, в поиске и в рекомендациях.

В 2024 году рынок фейковых звёзд выглядит так: «boost-сервисы» открыто продают пакеты в Google по запросу buy github stars. Цена — от $0,10 до $2 за звезду, доставка — за часы. Есть и обменники: «я звёздочку тебе, ты — мне». Чем больше боты в группе, тем больше «органических» звёзд они могут раздать одному репозиторию.

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

Как ловят: две сигнатуры StarScout

Команда написала StarScout — сканер, который пробежался по 20 терабайтам публичных метаданных GitHub за 2019–2024 годы из GHArchive. Аномалия определяется по двум независимым сигнатурам.

Сигнатура 1 — пустые аккаунты

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

Сигнатура 2 — аккаунты, действующие синхронно

Метод CopyCatch от Facebook: ищем кластеры аккаунтов, которые ставят звёзды одним и тем же репозиториям в близкие промежутки времени. Если 200 аккаунтов накидали звёзд тому же набору из пяти проектов в течение двух часов — это не совпадение, это автоматизация.

Совпадение по обеим сигнатурам — высокая уверенность в фейке. GitHub косвенно подтвердил методологию: к январю 2025 года платформа сама удалила 90,42% репозиториев и 57,07% аккаунтов из списка StarScout. Без участия исследователей.

Что прячется за фейковой популярностью

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

Похожая, но отдельная история — «Stargazers Ghost Network» от Check Point Research: сеть из более чем 3000 фейковых аккаунтов, которая распространяет Atlantida Stealer, Rhadamanthys, RisePro, Lumma Stealer и RedLine. Атрибутируется группе Stargazer Goblin. Эта сеть анализировалась отдельной командой и, вероятно, частично пересекается с 301 000 аккаунтов из списка StarScout. Общий паттерн один: звёзды как главный инструмент маскировки.

Меньшая часть фейк-кампаний — без явного malware: проекты вокруг ИИ/LLM, блокчейна, тулов, туториалов и демо. Авторы таких проектов покупают звёзды ради growth hacking или венчурной видимости. По исследованию, выгода всё равно недолгая: эффект исчезает через два месяца. Причина прозаичная — trending у GitHub смещается к свежим проектам, а без органического роста популярность проседает. Вдобавок репозиторий попадает в публичные списки подозрительных, и метка «были фейки» остаётся надолго.

Фейковые звёзды — это новый слой атак на supply chain, то есть на цепочку зависимостей, из которых собирается любой современный софт. В отличие от точечных инцидентов вроде XZ Utils backdoor или GlassWorm в OpenVSX, это массовый инструмент: дешёвый, автоматизированный, работает пока жертва доверяет звёздам как метрике.

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

Простое правило: звёзды — не доказательство доверия, а только сигнал к проверке. Если выбираете зависимость или клонируете утилиту с GitHub, стоит за минуту пробежаться по чек-листу.

1. Посмотреть на возраст репозитория и историю коммитов. Проект с 2 тыс звёзд и 3 коммитами от одного автора за неделю — почти всегда buy-кампания.
2. Ткнуть на вкладку Stargazers и открыть 5–10 случайных аккаунтов. Если у большинства пустой профиль, дефолтный аватар и ноль собственных репозиториев — это бот-сеть.
3. Посмотреть на даты звёзд. 500 звёзд за один день, а потом тишина — признак накрутки. У здорового проекта звёзды копятся плавно.
4. Сверить зависимость перед установкой с Socket или Snyk Advisor — они уже проверяют репозитории на supply-chain-риски.
5. Для дотошных: запустить StarScout локально (нужен доступ к GHArchive) или посмотреть в релизах репозитория готовые датасеты с помеченными кампаниями.

Выводы

Главное практическое следствие: звёздами больше нельзя пользоваться как самостоятельной метрикой доверия. Они полезны как первичный фильтр — обрезать заведомо мёртвые проекты — но сами по себе ничего не доказывают. С июля 2024 года ≈ 16% всех «популярных» репозиториев на GitHub имели хотя бы одну фейк-кампанию. Это не маргинальное явление, а фоновый шум.

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

Источники: paper «Six Million (Suspected) Fake Stars on GitHub», ICSE 2026 · пресс-релиз CMU · репозиторий StarScout · первая версия исследования (Socket, 3,7 млн) · Check Point про Stargazers Ghost Network

Если используете GitHub-зависимости в проде — добавьте проверку через StarScout или supply-chain-сканер в свой CI. Звёзды — больше не сигнал.

Раньше стэки делали сторонними инструментами: облачный сервис Graphite, консольные клиенты ghstack (от Meta) или spr. Все они симулировали стэки поверх обычного GitHub и ломались на ребейзах, merge queue и branch protection. Нативная реализация решает именно эти проблемы — о том, что с ней не так на старте и кому есть смысл пробовать прямо сейчас, разбираемся ниже.

• Статус: Private Preview, нужен waitlist для репозитория
• Что внутри платформы: stack map в UI, cascading rebase, корректная работа branch protection и merge queue
• CLI: расширение gh stack открыто в гитхабе, алиас gs — команды init, add, push, submit
• ИИ-агенты: npx skills add github/gh-stack учит Claude Code и Codex разбивать задачи на слои
• Кому идти сразу: командам с регулярными PR 1500+ строк или большими диффами от ИИ-ассистентов
• Кому подождать: тем, кто уже на Graphite или делает в основном PR на 200 строк

Что такое stacked PRs

Stacked PR (стек пулл-реквестов) — это цепочка PR, где каждый таргетит не main, а ветку PR ниже. Вместо одного огромного пулл-реквеста с пятью разными по смыслу изменениями вы делаете пять маленьких PR, которые читаются независимо и строятся один на другом.

Пример. Вы делаете фичу, которая требует нового API, роутов и фронтенда. Обычно это превращается в PR на 2000 строк, где ревьюер сначала вникает в API, потом забывает про него, когда смотрит роуты, путается в фронтенде и в итоге пишет «LGTM, не читал». Со стэком:

• PR #1 — auth-layer: новый API-слой (200 строк, одна тема)
• PR #2 — api-routes: роуты на базе auth-layer, таргетит ветку PR #1
• PR #3 — frontend: UI на базе роутов, таргетит ветку PR #2

Ревьюеры читают по одному PR, дают фидбек по конкретной теме, и вы мержите всё разом, когда каждый слой одобрен. Подход называется «small PR culture» — мы уже разбирали, почему команды переосмысляют формат пулл-реквестов.

Что GitHub сделал на уровне платформы

Сторонние тулы уже давно давали стек на Git-уровне, но работали поверх обычного GitHub и ломались на ребейзах, merge queue и branch protection. Нативная поддержка закрывает эти углы:

• Stack map в UI — навигация между PR прямо в интерфейсе, видно статус каждого слоя сразу
• Cascading rebase — ребейзнули PR внизу стэка, один клик — и все PR выше автоматически ребейзятся
• Branch protection — правила (ревью-апрув, passing checks) применяются против финальной целевой ветки (обычно main), а не против промежуточной
• CI — прогоняется для каждого PR в стэке так, будто он уже таргетит финальную ветку (не промежуточную)
• Merge queue — очередь GitHub, которая последовательно ребейзит и мерджит PR. Теперь понимает стэки: можно ставить в очередь как весь стэк, так и его часть
• Частичный мердж стэка — если одобрены только нижние два PR, можно слить их, а верхние оставить на доработку
• API — управление стэками через GraphQL и REST, интеграция с вашими CI-тулами

CLI gh stack: что внутри

CLI — опциональное расширение к стандартному gh. Сокращает рутину: не надо вручную создавать ветки, проставлять base, делать серию rebase. Базовые команды следуют той же логике, что и современные workflow поверх Git — работать мелкими слоями и синхронизироваться автоматически.

Базовый сценарий от GitHub:

Дальше — работа как с обычными PR, только с визуальной картой стэка. Хотите ребейзнуть auth-layer на свежий main — gs rebase, и вышележащие слои автоматически подтягивают новую базу.

Интеграция с ИИ-агентами

GitHub явно заточил stacked PRs под сценарий совместной работы с ИИ-агентами. Skills — это документированный формат инструкций для кодовых ассистентов: одна папка с markdown-файлами и примерами, которую агент читает и использует как расширение своего поведения. Команда npx skills add github/gh-stack добавляет такой скилл для Claude Code, OpenAI Codex и других агентов, которые поддерживают формат.

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

Как попасть в Private Preview

1. Зайти на github.github.com/gh-stack и записаться в waitlist (кнопка «Sign up for the waitlist»)
2. Дождаться, пока GitHub включит фичу для вашей организации или репозитория — точных сроков они не называют
3. Включить в настройках репо: появится новая секция Stacked PRs в Settings → Pull Requests
4. Поставить расширение CLI: gh extension install github/gh-stack

CLI-расширение распространяется свободно — его можно поставить уже сейчас из открытого репозитория github/gh-stack. Но README расширения предупреждает: без включённого Private Preview на стороне сервера команды gs push и gs submit упрутся в API, который отвечает 404 или ошибкой доступа. Поставить CLI и посмотреть gh stack --help можно, реально прогонять стэки — только после активации preview в репозитории.

Зачем это, если есть Graphite, ghstack и spr

Существующие решения делятся на две группы. Graphite — коммерческий сервис: у него свой веб-интерфейс, бэкенд и платные тарифы, он синхронизирует стэк через GitHub API. Ghstack (Meta) и spr (Cord) — консольные клиенты: держат локальный граф стэка и пушат PR напрямую. Общее у них одно — стэк живёт где-то вне GitHub, а синхронизируется с ним через API.

Из-за этого все они ломаются в одном классе сценариев: когда кто-то из команды мержит через веб-интерфейс, делает force-push из терминала или запускает merge queue, локальный граф CLI или состояние сервиса Graphite разъезжаются с реальностью — и стэк приходится чинить руками.

Нативная реализация снимает этот класс проблем: стэк живёт на стороне сервера GitHub, UI и CLI синхронизируются с ним автоматически. Branch protection, merge queue, CI — всё работает без костылей. Для базового сценария «разбить большую диффу на стэк и слить её» стороннее звено становится необязательным.

У сторонних тулов остаётся ниша: автогенерация описаний PR через ИИ у Graphite, интеграция с Jira и Linear, аналитика по времени ревью — всё это GitHub не закрывает. Если вы уже платите Graphite за эту часть — ничего не сломается, тулы совместимы со Stacked PRs на уровне API.

Для российских разработчиков: GitHub работает с ограничениями для аккаунтов, подключённых из РФ с 2022 года — возможны блокировки при создании организаций и проблемы с оплатой приватных репозиториев. Нативные Stacked PRs становятся особенно полезны, если переходить на GitFlic, GitVerse или self-hosted GitLab, где аналогов стэков на платформенном уровне пока нет — но CLI-клиенты ghstack и spr работают и на них.

Что делать прямо сейчас

Если ваша команда регулярно сталкивается с ревью на 1500+ строк, PR, которые висят неделями, или большими диффами от ИИ-ассистентов — встаньте в waitlist, поставьте CLI gh extension install github/gh-stack и подготовьтесь к следующей крупной задаче. Пока ждёте активации — попробуйте разбить текущую большую задачу руками через последовательные PR с правильными base-ветками: это работает и в обычном GitHub, а CLI потом сделает то же самое автоматически.

Если вы уже на Graphite и довольны — переезд имеет смысл после выхода фичи из Private Preview и появления миграционного сценария. Небольшим командам с PR на 200 строк фича пока не нужна: инвестиции в стэки окупаются там, где большие задачи — частая история.

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

Источники: официальный анонс GitHub Stacked PRs, репозиторий CLI-расширения, обсуждение на Hacker News.

Источник — официальная страница Trending. Сортировка по количеству звёзд за неделю. Для каждого проекта — что это, кому полезно и стоит ли тратить время.

• Hermes Agent (NousResearch) — +19,7 тыс. звёзд за неделю, фреймворк для LLM-агентов с долговременной памятью
• OpenScreen — +12,2 тыс., опенсорсная альтернатива Screen Studio без водяных знаков и подписок
• TimesFM (Google Research) — +3,1 тыс., foundation-модель для временных рядов, zero-shot forecasting
• Multica — +3,2 тыс., платформа управления командами кодинг-агентов
• Gallery (Google AI Edge) — +4,3 тыс., демо-приложение on-device ML и GenAI на Android
• DeepTutor, LiteRT-LM, PersonaPlex, Onyx — остальные заметные проекты недели

NousResearch / hermes-agent — агент с долговременной памятью

⭐ 49 247, +19 765 за неделю · Python · github.com/NousResearch/hermes-agent

NousResearch — команда, известная по серии открытых моделей Hermes на базе Mistral и Llama, — выпустила собственный фреймворк для LLM-агентов с акцентом на долговременную память и персонализацию. Слоган проекта — «The agent that grows with you»: агент накапливает контекст о пользователе между сессиями, учится на взаимодействиях и адаптирует поведение.

Зачем смотреть: если вы строите ассистента, который должен помнить историю работы с конкретным пользователем, — Hermes Agent предлагает готовую механику memory layer без привязки к облачной модели. Работает с open-weights моделями серии Hermes, но архитектура позволяет подключать и другие LLM.

siddharthvaddem / openscreen — опенсорсный Screen Studio

⭐ 27 315, +12 278 за неделю · TypeScript · github.com/siddharthvaddem/openscreen

Единственный не-ИИ проект в топе недели. OpenScreen — опенсорсная альтернатива Screen Studio, инструмента для записи красивых демо (плавные переходы, zoom-эффекты, курсор-акценты, автоматические скругления). Без подписок, без водяных знаков, лицензия позволяет использовать коммерчески.

Зачем смотреть: если вы делаете видео-туториалы, демо для лендингов продукта или онбординги, хороший скринкаст сильно повышает воспринимаемое качество. Screen Studio стоит $29 в месяц по подписке — OpenScreen закрывает базовые сценарии бесплатно. Это нативное десктоп-приложение на Electron (Mac, Windows, Linux).

onyx-dot-app / onyx — открытая ИИ-платформа для чата

⭐ 26 299, +5 556 за неделю · Python · github.com/onyx-dot-app/onyx

Ещё один open-source конкурент платным ChatGPT-подобным интерфейсам. Onyx — ИИ-чат с поддержкой любой LLM через провайдер-абстракцию, RAG по загруженным документам, поддержкой плагинов и корпоративными фичами (SSO, аудит, разделение доступа). Позиционируется как замена OpenAI-подобным сервисам для команд, которым важно контролировать данные.

Зачем смотреть: если у вас стоит задача развернуть корпоративный чат-интерфейс с подключением к собственным документам и запретом утечки данных наружу — Onyx закрывает большую часть требований без покупки Enterprise-лицензии у вендора.

google-ai-edge / gallery — демо on-device ML для Android

⭐ 20 072, +4 326 за неделю · Kotlin · github.com/google-ai-edge/gallery

Официальное приложение-галерея от команды Google AI Edge. Показывает живые примеры on-device ML и GenAI-кейсов: генерация текста, классификация изображений, перевод речи, всё локально на устройстве без отправки данных в облако. В последней версии приложение работает на открытых моделях Gemma, используя LiteRT (бывший TensorFlow Lite) и MediaPipe как runtime. Доступно и на Android, и на iOS.

Зачем смотреть: если вы Android-разработчик и хотите добавить в приложение GenAI-фичу, которая не требует интернета — это проще всего запустить и изучить код. В подборке — готовые примеры того, что уже работает на флагманских Pixel и Samsung устройствах.

multica-ai / multica — платформа для команд кодинг-агентов

⭐ 5 140, +3 201 за неделю · TypeScript · github.com/multica-ai/multica

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

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

HKUDS / DeepTutor — агент-преподаватель

⭐ 15 552, +3 233 за неделю · Python · github.com/HKUDS/DeepTutor

Проект от Data Intelligence Lab Университета Гонконга (HKU). «Agent-Native Personalized Learning Assistant» — ИИ-репетитор, который подстраивает объяснения под конкретного ученика: учитывает уровень знаний, стиль обучения и прошлые заблуждения. Открытый исходный код, документированный, с примерами использования в разных образовательных сценариях.

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

google-research / timesfm — foundation-модель для временных рядов

⭐ 16 158, +3 095 за неделю · Python · github.com/google-research/timesfm

TimesFM (Time Series Foundation Model) — предобученная модель от Google Research для прогнозирования временных рядов, аналог GPT/LLaMA, но для числовых последовательностей. Zero-shot: можно передать свою серию данных без дообучения и получить прогноз на N шагов вперёд.

Зачем смотреть: если вы работаете с прогнозированием метрик (посещаемость, продажи, нагрузка на сервис) — обычно приходится обучать отдельную модель под каждую задачу. TimesFM позволяет попробовать foundation-подход: одна модель, любой ряд, никакого fine-tuning. Для продакшена может быть рано, для R&D — удобно.

NVIDIA / personaplex — speech-to-speech модель с контролем персоны

⭐ 8 853, +2 745 за неделю · Python · github.com/NVIDIA/personaplex

На самом деле это не про аватары, как можно подумать по названию. PersonaPlex — full-duplex speech-to-speech conversational модель от NVIDIA на базе архитектуры Moshi (разработка Kyutai). Главная фича — управление персоной ассистента через текстовые промпты ролей и audio-кондишенинг голоса. Репозиторий даёт рабочий инференс-сервер, веса лежат на Hugging Face.

Зачем смотреть: если вы строите голосового ассистента и хотите, чтобы он разговаривал не дежурным TTS-голосом, а с узнаваемой персоной — PersonaPlex показывает, как это делается на уровне модели, а не на уровне промптов. Low-latency интерактив в стиле Moshi уже из коробки.

google-ai-edge / LiteRT-LM — runtime для локальных LLM на edge

⭐ 3 260, +2 157 за неделю · C++ · github.com/google-ai-edge/LiteRT-LM

Второй проект Google AI Edge в подборке. LiteRT-LM — это runtime (время выполнения) для запуска LLM на edge-устройствах: мобильные телефоны, embedded-железо, IoT. Продолжение линии LiteRT (бывший TensorFlow Lite), но с акцентом именно на большие языковые модели.

Зачем смотреть: если вы хотите запускать 3–7B модель локально на телефоне или Raspberry Pi и вам надоело разбираться с llama.cpp под каждую архитектуру — LiteRT-LM предлагает единый runtime с поддержкой Google-оптимизаций под мобильные чипсеты.

Что можно брать в работу прямо сегодня

Из девяти проектов подборки три — от Google (Gallery, LiteRT-LM, TimesFM). Компания явно толкает on-device ML и foundation-модели для едж-устройств. Четыре проекта — про ИИ-агентов (Hermes, Multica, DeepTutor, Onyx): агентский слой окончательно перекочевал из ресёрча в рабочий инструментарий.

Если нужно выбрать что-то одно на этот уикенд — возьмите OpenScreen: он работает прямо сейчас, решает конкретную задачу и не требует погружения в теорию агентов. А если вы строите что-то с памятью и персонализацией — Hermes Agent заслуживает как минимум получаса внимания.

Источник: GitHub Trending на 10 апреля 2026 года. Числа звёзд актуальны на момент публикации.

Мне стало интересно: а можно ли на бесплатных мощностях, буквально "на коленке", собрать русскоязычного ИИ-рентгенолога? Спойлер: можно. В этой статье расскажу, как я скрестил Vision Transformer от Google с ruGPT-3 от Сбера, как боролся с датасетами на Kaggle и что из этого вышло. В конце — ссылки на GitHub и рабочее демо.

Архитектура: как пришить глаза к мозгу

Чтобы нейросеть могла посмотреть на снимок и написать текст, нужна архитектура Vision-Language Model. Обучать такого монстра с нуля у меня не было ни ресурсов, ни желания. Поэтому я пошел по пути Hugging Face VisionEncoderDecoderModel.

Идея проста как кирпич:

1. Энкодер (Глаза): Берем предобученный google/vit-base-patch16-224-in21k. Он отлично дробит картинку на патчи и извлекает визуальные фичи (понимает, где ребра, а где легкие).
2. Декодер (Язык): Берем ai-forever/rugpt3small_based_on_gpt2. У нее нет глаз, она умеет только генерировать текст.

Чтобы их сшить, пришлось немного "взломать" конфиг ruGPT-3, принудительно сказав ей: «Теперь ты декодер, и у тебя есть слои кросс-внимания» (is_decoder=True, add_cross_attention=True). Hugging Face заботливо создал новые пустые веса между двумя моделями. Именно эти связи мне и предстояло обучить.

Data Engineering: боль, страдания и Kaggle

Найти 7-10 тысяч рентгеновских снимков с подробными заключениями на русском языке в открытом доступе — задача нереальная.

Поэтому я взял открытый американский датасет Indiana University Chest X-Ray (IU X-Ray). Там есть картинки и тексты от американских врачей.

Прямо на Kaggle я поднял пайплайн машинного перевода на базе Helsinki-NLP/opus-mt-en-ru. Закинул тексты в GPU батчами по 32 штуки и за 10 минут перевел более 7000 медицинских заключений на вполне сносный русский медицинский язык.

Но тут платформа подкинула сюрприз: Kaggle прячет часть файлов в виртуальной файловой системе (снимков 7000, а стандартный скрипт видел только 4). Пришлось писать суровый маппинг с глубоким сканированием (os.walk), отрезать расширения и жестко связывать ID в CSV с реальными путями на диске.

Обучение: выжимаем все соки из бесплатных T4

Обучение проходило на Kaggle (2x NVIDIA T4). Чтобы модель не умерла от нехватки памяти (OOM), а сессия не отвалилась по тайм-ауту, пришлось шаманить:

• Включил Mixed Precision (fp16) — ускорило обучение в 2 раза.
• Настроил Gradient Accumulation — размер батча на видеокарту был всего 4, но виртуально мы накапливали до 16.
• Столкнулся с тем, что Seq2SeqTrainer крашится при попытке сохранить промежуточный чекпоинт мультимодального "франкенштейна". Решение? Выключить промежуточные сохранения (save_strategy="epoch") и молиться, чтобы Kaggle не завис. (Кстати, спасает JS-скрипт в консоли браузера, делающий клик раз в 60 секунд).

На 15 эпох ушло около 2.5 часов.

Что получилось в итоге? (Потрогать руками)

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

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

👉 Потыкать лайв-демо тут: Hugging Face Space

👉 Весь код, пайплайны и веса тут: GitHub Репозиторий

Буду рад, если кому-то этот код сэкономит время при создании своих мультимодальных сеток. Залетайте в репу, ставьте звездочки, форкайте. Если есть идеи, как улучшить датасет (может, прогнать переводы через LLM для чистки медицинского сленга) — пишите в комменты!

(Дисклеймер: модель обучена в исследовательских целях за вечер. Не суйте ей свои снимки вместо похода к реальному врачу)

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

• LinkedIn тайно сканирует установленное ПО на компьютерах пользователей при каждом визите на сайт
• Сканирование выявляет религиозные убеждения, политические взгляды, инвалидность и поиск работы — через расширения браузера
• LinkedIn определяет более 6000 продуктов, включая 200+ конкурирующих инструментов продаж
• Данные передаются третьим сторонам без уведомления и согласия
• По мнению исследователей, это нарушает GDPR и может быть уголовным преступлением в ЕС

Что именно сканирует LinkedIn

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

• Религиозные убеждения — расширения для практикующих мусульман
• Политическая ориентация — расширения, связанные с политическими предпочтениями
• Нейроотличность — расширения для пользователей с СДВГ, аутизмом и другими особенностями
• Поиск работы — 509 инструментов для поиска вакансий, которые выдают тех, кто тайно ищет новое место

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

Корпоративный шпионаж: сканирование конкурентов

LinkedIn сканирует более 200 продуктов, напрямую конкурирующих с его собственными инструментами продаж — Apollo, Lusha, ZoomInfo и другие. Зная работодателя каждого пользователя, платформа может составить карту: какие компании используют какие конкурирующие продукты.

По утверждению исследователей, LinkedIn уже использует эти данные — отправляет угрозы пользователям сторонних инструментов, идентифицируя их через скрытое сканирование. Список сканируемых продуктов вырос с около 461 в 2024 году до более чем 6000 к февралю 2026 года.

Обман европейских регуляторов

В 2023 году ЕС признал LinkedIn регулируемым гейткипером по Digital Markets Act и обязал открыть платформу для сторонних инструментов. LinkedIn опубликовал два ограниченных API, обрабатывающих около 0,07 запросов в секунду. При этом внутренний API Voyager, на котором работают все продукты LinkedIn, обрабатывает 163 000 запросов в секунду.

В 249-страничном отчёте Microsoft для Еврокомиссии слово «API» встречается 533 раза. Слово «Voyager» — ноль раз.

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

Передача данных третьим сторонам

LinkedIn загружает невидимый трекинговый элемент от HUMAN Security — нулевой ширины, скрытый за пределами экрана — который устанавливает куки без ведома пользователя. Отдельный скрипт фингерпринтинга работает с серверов LinkedIn. Третий скрипт от Google выполняется молча при каждой загрузке страницы. Всё зашифровано. Ничего не раскрыто в политике конфиденциальности.

Важный контекст: сканирование расширений браузера — известная техника борьбы с ботами и мошенничеством. HUMAN Security (PerimeterX) — именно anti-bot компания. LinkedIn может аргументировать, что сканирование нужно для защиты платформы. Расследование Fairlinked e.V. представляет одну сторону — независимая верификация их утверждений пока не проводилась.

Правовые последствия

Исследователи утверждают, что действия LinkedIn нарушают GDPR, поскольку сканирование выявляет данные особых категорий (религия, политика, здоровье) без согласия и без правовой основы. По законодательству ЕС такие данные не просто регулируются — их обработка запрещена без явного согласия.

Fairlinked e.V. собирает доказательную базу и средства для судебного разбирательства. На момент публикации Microsoft и LinkedIn не прокомментировали расследование.

Выводы

Расследование BrowserGate — одно из крупнейших обвинений в корпоративном шпионаже в истории веба. Если данные подтвердятся, LinkedIn и Microsoft могут столкнуться с серьёзными штрафами по GDPR и Digital Markets Act.

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

BGP (Border Gateway Protocol) — протокол, по которому автономные системы (AS) обмениваются информацией о маршрутах. Автономная система — это сеть под управлением одного оператора: провайдера, облачной платформы, крупной компании. Когда вы открываете сайт, трафик проходит через цепочку таких AS. Но иногда он уходит не туда — из-за ошибок конфигурации или злонамеренных действий. Такие инциденты называются утечками маршрутов (route leaks). Новый криптографический стандарт ASPA (Autonomous System Provider Authorization) призван решить эту проблему — он проверяет не только пункт назначения, но и весь путь трафика.

• ASPA — новый стандарт криптографической проверки маршрутов BGP, дополняющий существующий RPKI/ROA
• ROA проверяет пункт назначения трафика, ASPA проверяет путь — цепочку сетей, через которые он проходит
• ASPA обнаруживает утечки маршрутов, проверяя, что трафик движется по «горной» модели: вверх к провайдеру, через пиринг, вниз к получателю
• Создать ASPA-запись можно за пару кликов в RIPE или ARIN
• Cloudflare Radar теперь отслеживает глобальное внедрение ASPA в реальном времени

Как сейчас защищён BGP: RPKI и ROA

Сегодня сети используют инфраструктуру RPKI (Resource Public Key Infrastructure), внедрение которой значительно выросло за последние годы. В рамках RPKI сети публикуют криптографические записи — ROA (Route Origin Authorizations). ROA — это верифицируемое цифровое удостоверение, подтверждающее, что конкретная автономная система (AS) авторизована анонсировать определённые IP-адреса. Это решает проблему origin hijacks — когда одна сеть выдаёт себя за другую.

Но ROA проверяет только пункт назначения. А что насчёт пути?

Что такое ASPA и как он работает

ASPA (Autonomous System Provider Authorization) надстраивается над RPKI. Если ROA проверяет куда идёт трафик, то ASPA проверяет как он туда добирается.

Когда данные путешествуют по интернету, каждая сеть на пути записывается в лог — AS_PATH. ASPA позволяет сетям официально публиковать список авторизованных апстрим-провайдеров в системе RPKI. Любая принимающая сеть может посмотреть на AS_PATH, проверить ASPA-записи и убедиться, что трафик прошёл только через одобренную цепочку сетей.

Модель «горы»: как устроена здоровая маршрутизация

В нормальной топологии (valley-free routing) трафик движется по «горной» модели:

1. Подъём (Up-Ramp) — трафик идёт от клиента вверх через всё более крупных провайдеров (ISP)
2. Вершина (Apex) — на уровне магистрали трафик может пересечь один пиринговый линк
3. Спуск (Down-Ramp) — трафик спускается через провайдеров к получателю

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

Как ASPA валидирует маршруты

ASPA проверяет цепочку отношений с обоих концов маршрута:

1. Проверка подъёма — начинаем от источника и двигаемся вперёд. На каждом хопе спрашиваем: «Авторизовала ли эта сеть следующую как своего провайдера?»
2. Проверка спуска — то же самое, но в обратном направлении от получателя BGP-обновления

Если «подъём» и «спуск» встречаются или пересекаются на вершине — маршрут валидный. Форма горы сохранена.

Если пути не сходятся и в середине есть разрыв — ASPA отмечает маршрут как проблемный. Этот разрыв и есть «долина», то есть утечка.

Пример: обнаружение утечки маршрута

Допустим, сеть AS65539 получает подозрительный маршрут от клиента AS65538. Клиент пытается отправить трафик, полученный от одного провайдера (AS65537), «вверх» к другому провайдеру (AS65539) — действуя как мост между провайдерами. Это классическая утечка маршрута.

Процесс валидации ASPA:

1. Проверяем подъём: источник (AS65536) авторизует своего провайдера — проверка пройдена
2. Проверяем спуск: начинаем от получателя и смотрим назад — видим клиента (AS65538)
3. Несовпадение: подъём заканчивается на AS65537, спуск — на AS65538. Пути не соединяются

Результат: маршрут отмечен как ASPA Invalid. Без подписанных ASPA-объектов в RPKI невозможно определить, какие сети авторизованы анонсировать префиксы горизонтально (пирам) или вверх (провайдерам).

ASPA против forged-origin hijacks

ASPA эффективно защищает от forged-origin hijacks — атак, при которых злоумышленник обходит проверку ROV: он анонсирует реальный IP-префикс с правильным origin AS, но вставляет себя в AS_PATH как промежуточный хоп. ROV это не замечает, так как проверяет только origin. Источник формально правильный, но связь между атакующим и жертвой — сфабрикована.

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

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

Как создать ASPA-запись: пара кликов

Создание ASPA-объекта для вашей сети стало простым в реестрах RIPE и ARIN. Всё, что нужно — ваш номер AS и номера AS ваших провайдеров, у которых вы покупаете транзит. В обратном направлении это сети, которым вы разрешаете присылать полную таблицу маршрутизации — карту достижимости остального интернета.

Пример Cloudflare: для AS203898 (офис в Лондоне) с тремя интернет-провайдерами (AS8220, AS2860, AS1273) процесс занимает три шага:

1. Войти в RPKI-дашборд RIPE и перейти в раздел ASPA
2. Нажать «Create ASPA» для нужного AS
3. Указать список провайдеров

Через короткое время ASPA-запись появляется в глобальной RPKI-экосистеме.

Отдельный случай — запись с AS0 в качестве провайдера. Это означает, что у сети нет апстрим-провайдеров. По определению, каждая транзитно-свободная сеть Tier-1 в будущем должна будет подписать ASPA только с «AS0» — если у неё действительно только пиринговые и клиентские отношения.

Мониторинг ASPA в Cloudflare Radar

Cloudflare Radar добавил новые возможности мониторинга внедрения ASPA:

• Графики роста внедрения ASPA по пяти региональным реестрам (RIR)
• Интеграция ASPA-данных в страницы маршрутизации по странам и ASN
• Для каждой AS — список провайдеров из ASPA-объекта, проверка BGP-апстримов и история изменений

Что нужно для полного внедрения ASPA

ASPA — это криптографический фундамент для валидации путей. Но, как показал опыт RPKI/ROA, внедрение займёт время. Необходимы обновления:

• RPKI Relying Party (RP) — программы проверки криптографических записей
• RTR (RPKI-to-Router protocol) — протокол передачи данных маршрутизаторам
• BGP-реализации на маршрутизаторах — для валидации путей с использованием ASPA

Помимо создания ASPA-записей, операторам рекомендуется настроить BGP roles (RFC 9234). BGP roles привязывают предполагаемые отношения между AS к конкретным BGP-сессиям, помогая ASPA определить, какой алгоритм валидации применять — для апстрима или даунстрима. Уточните у своих вендоров оборудования, поддерживают ли они BGP roles и атрибут OTC (Only-to-Customer).

Управление ASPA-записями не отличается от управления ROA. В будущем, когда сети начнут активно блокировать невалидные пути, пропуск легитимного провайдера может привести к потере трафика. Но это тот же риск, который операторы уже научились контролировать.

Выводы

ASPA — следующий логичный шаг в безопасности интернет-маршрутизации после RPKI/ROA. Если ROA закрепил за каждой AS право анонсировать свои IP-адреса, то ASPA закрепляет право на транзит — описывает авторизованный путь трафика.

Для операторов сетей: проверьте в Cloudflare Radar, есть ли у вашей AS ASPA-запись, и создайте её в RIPE или ARIN. Чем больше сетей подпишут ASPA, тем быстрее стандарт начнёт реально блокировать утечки маршрутов.

Пулл-реквесты задумывались как инструмент для совместной работы над кодом. На практике они превратились в бюрократическую процедуру: гигантские диффы, комментарии в разных вкладках, коллапсированные «outdated»-ветки обсуждений. Bernard Kolobara считает, что проблема не в самой идее code review, а в инструментах — и предлагает конкретные решения.

• Comprehension debt (долг понимания) — главная проблема, которую должен решать code review, а не только ловля багов
• Стековые пулл-реквесты: разбиение изменений на мелкие самодостаточные коммиты, которые ревьюятся независимо
• Приоритет файлов: тесты и зависимости показываются первыми в диффе через .gitattributes
• Всё на одной странице: код и обсуждение вместе, без вкладок
• ИИ не убил code review — он обнажил хрупкость инструментов, которые не справляются с растущим объёмом кода

Comprehension debt: долг понимания кода

Addy Osmani описал comprehension debt как разрыв между объёмом кода в проекте и тем, сколько из этого кода команда реально понимает. Чем больше разрыв — тем медленнее работа. Проектировать систему, которую полностью понимаешь, проще, чем ту, которую «примерно знаешь». С появлением ИИ-агентов в рабочих процессах этот разрыв значительно вырос.

Paul Graham в эссе о великой работе пишет, что лучшие идеи приходят вне клавиатуры — на прогулке, в душе, перед сном. Но для этого «фонового процессинга» нужно, чтобы контекст проекта уже был в голове. Сначала нужна осознанная работа с кодом.

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

Как сократить разрыв: конкретные решения

Стековые пулл-реквесты

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

Git заточен под append-only workflow. Вернуться в старый коммит и отредактировать его — мучительно. Даже если вы аккуратно структурировали историю, рано или поздно появляется серия коммитов «fix», «actual fix», «ok now really fix». Когда смотришь на отдельный коммит, не видишь полной картины — правки могут быть размазаны по нескольким коммитам дальше по истории.

Bernard и его коллега Luísa решают эту проблему с помощью Jujutsu — VCS, которая позволяет прыгнуть в любой коммит и отредактировать его на месте, а затем автоматически пропагирует изменения через всю историю. Это позволяет «вылепить» идеальную историю коммитов.

В Lubeno стековые PR детектятся автоматически. Каждый PR показывается как дифф относительно родительского PR — ревью и одобрение идут независимо. Автор не ждёт, пока предыдущий PR смёржат, и может продолжать работу.

Приоритет файлов в диффе

При ревью автор первым делом смотрит тесты: были ли изменены существующие, тестируют ли новые что-то полезное. Затем — зависимости: добавляется ли новая и зачем. Но все платформы для code review показывают файлы в алфавитном порядке — важные изменения легко пропустить в большом диффе.

Lubeno использует кастомный атрибут priority в .gitattributes (это не стандартный атрибут Git, а расширение Lubeno):

Файлы с высоким приоритетом показываются первыми на странице PR. Простое решение, но оно гарантирует, что самые важные изменения вы увидите сразу.

Всё на одной странице

Почти все платформы для code review разносят комментарии, коммиты и код по разным вкладкам. Автор признаётся: «Я нажимал на вкладку Commits только по ошибке — ни разу намеренно». Обсуждение тесно связано с кодом, но чтобы следить за ним, приходится постоянно скроллить наверх, переключать вкладки и искать нужный фрагмент.

В Lubeno нет вкладок на странице PR. Код и обсуждение живут в одном месте.

Эволюция кода в рамках PR

PR — не статичная сущность. Это место для обсуждения и итераций. Знакомая ситуация: вы оставили комментарий, вернулись — и обнаружили несколько новых коммитов, а все ваши комментарии свёрнуты как «outdated». Непонятно, учтены ли ваши замечания, что изменилось с момента вашего последнего просмотра.

Lubeno отслеживает комментарии к коду и наложение interdiff (разницу между версиями файла в рамках PR): если код был изменён более поздним коммитом (или force push), разница видна прямо в контексте комментария. Не нужно переключаться между вкладками, чтобы понять, что произошло.

Будущее пулл-реквестов

Некоторые называют PR «реликтом прошлого» и призывают от них отказаться. Автор не согласен: процесс ревью кода сегодня ценнее, чем когда-либо. ИИ не убил code review — он обнажил хрупкость инструментов. Больше строк кода просто сделали их непригодными.

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

Выводы

Статья Bernard Kolobara — не абстрактные размышления, а описание конкретных решений, реализованных в Lubeno. Даже если вы не планируете переходить с GitHub — идеи стековых PR, приоритета файлов и unified-страницы ревью стоит примерить к своему workflow.

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

TechSpot сообщает: 30 марта австралийский разработчик Зак Мэнсон заметил, что Copilot добавил промо-текст приложения Raycast в pull-реквест коллеги. Поиск по GitHub показал, что аналогичные «подсказки» оказались в тысячах PR. В течение суток руководство GitHub признало проблему и отключило функцию.

• Copilot вставлял промо-подсказки (Raycast и другие инструменты) в PR, которые он не создавал — без согласия авторов
• Более 11 400 pull-реквестов затронуты
• GitHub VP Martin Woodward: «GitHub не размещает и не планирует размещать рекламу»
• Copilot PM Tim Rogers признал: «Это было неправильное решение»
• Функция отключена — промо-подсказки больше не появятся в PR

Как обнаружили проблему

Зак Мэнсон рассказал The Register, что коллега использовал Copilot для исправления опечатки в PR. При ревью Мэнсон обнаружил, что ИИ добавил строку:

Quickly spin up Copilot coding agents from anywhere on your macOS or Windows machine with Raycast.

Первая реакция — подозрение на компрометацию: повреждённые обучающие данные, prompt injection или маркетинговый эксперимент от Raycast. Дальнейший поиск по GitHub показал масштаб: более 11 400 PR содержали почти идентичные промо-сообщения. Нашлись и подсказки, продвигающие другие инструменты — все вставлены автоматически.

Больше всего Мэнсона удивило не содержание подсказок, а сам факт: Copilot редактировал чужой контент без согласия. «Я даже не знал, что интеграция GitHub Copilot Review может редактировать описания и комментарии других пользователей», — написал он.

Реакция GitHub: отключение за сутки

Microsoft-овский GitHub отреагировал в тот же день. Вице-президент по DevRel Мартин Вудвард объяснил в X, что Copilot вставлял «подсказки» в свои собственные PR и раньше — это была задуманная функция. Проблема возникла, когда добавили возможность вызывать Copilot через @-упоминание в чужих PR:

Когда мы добавили возможность вызывать Copilot в любом PR через @-упоминание, поведение стало неприятным.

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

Оглядываясь назад, позволить Copilot вносить изменения в pull-реквесты, написанные людьми, было неправильным решением.

GitHub отключил промо-подсказки в PR, созданных или затронутых Copilot. Вудвард добавил: «GitHub не размещает и не планирует размещать рекламу».

Почему это важно для разработчиков

Инцидент выявил три проблемы:

1. ИИ-агент добавлял контент в чужие PR без согласия — Copilot мог изменять описания и комментарии в PR других пользователей. Многие разработчики не знали об этой возможности
2. Граница между функцией и рекламой размыта — GitHub позиционировал подсказки как «обучение», но содержимое продвигало конкретные сторонние продукты (Raycast) со ссылками на установку
3. Доверие к ИИ-инструментам хрупко — достаточно одного инцидента, чтобы разработчики начали отключать Copilot Review. По данным TechSpot, множество пользователей уже деактивировали функцию

Положительный момент: GitHub отреагировал быстро — менее чем за сутки — и два топ-менеджера публично признали ошибку. Для сравнения: многие компании в аналогичных ситуациях замалчивают проблему или списывают её на «баг».

Что в итоге

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

Проблему обнаружил мельбурнский разработчик Зак Мэнсон: коллега вызвал Copilot для исправления опечатки в PR, но ИИ заодно дописал в описание рекламу расширения Raycast. Тот же рекламный текст нашли более чем в 11 000 pull-реквестов на GitHub и в merge-реквестах на GitLab.

— GitHub Copilot вставляет рекламные «советы» в описания PR как обычный текст после скрытого HTML-маркера.

— Затронуты более 1,5 млн pull-реквестов на GitHub и merge-реквесты на GitLab.

— Продвигаются расширения из экосистемы Microsoft: Raycast, Slack, Teams, VS Code, JetBrains.

— Способа отключить вставки пока нет — Microsoft не комментирует.

Коллега вызвал Copilot, чтобы исправить опечатку в моём PR. Copilot исправил опечатку — и заодно отредактировал описание PR, вставив рекламу самого себя и Raycast.

Как работает инъекция рекламы

Когда Copilot выполняет задачу в pull-реквесте, он добавляет в описание PR скрытый HTML-маркер <!-- START COPILOT CODING AGENT TIPS -->. Сам маркер не виден при просмотре — это обычный HTML-комментарий. А вот рекламный текст, который идёт сразу после него, отображается как часть описания PR и виден всем участникам.

Среди обнаруженных рекламных вставок — предложения запускать задачи агента Copilot из Slack, Teams, VS Code, Visual Studio, JetBrains IDE и Eclipse. Все продвигаемые продукты — часть экосистемы Microsoft или её партнёров.

Кто стоит за рекламой

На первый взгляд могло показаться, что рекламу вставляет Raycast — приложение для macOS и Windows с набором ИИ-инструментов, включая расширение для Copilot. Однако перечень продвигаемых сервисов (Slack, Teams, VS Code) и структура HTML-маркеров указывают на то, что «советы» встраиваются через сам механизм агента Copilot — то есть, судя по всему, за вставками стоит Microsoft.

Ни Raycast, ни Microsoft пока не прокомментировали ситуацию.

Как обнаружить и убрать рекламу из PR

Рекламные вставки можно найти по маркеру в описании PR. Откройте любой PR, отредактированный Copilot, и переключитесь в режим редактирования — вы увидите HTML-комментарий и следующий за ним промо-текст.

Для автоматического удаления можно настроить CI-проверку или pre-commit hook, который ищет строку COPILOT CODING AGENT TIPS в описаниях PR и удаляет блок от маркера до следующего раздела. На момент публикации Microsoft не предоставила штатного способа отключить «советы».

Выводы

Разработчики платят за Copilot подпиской ($19/мес за Individual, $39/мес за Business), но Microsoft дополнительно монетизирует их рабочий процесс, встраивая промо-тексты прямо в код-ревью. Пока компания не дала объяснений и не предложила способа отключить вставки — остаётся проверять описания PR вручную или автоматизировать удаление через CI.

ATLAS (Adaptive Test-time Learning and Autonomous Specialization) — open-source система, которая оборачивает замороженную квантизированную модель Qwen3-14B в трёхфазный пайплайн генерации, верификации и починки кода. На бенчмарке LiveCodeBench v5 (599 из 880 задач) система набрала 74,6% — против 71,4% у Claude Sonnet 4.5.

— ATLAS набирает 74,6% на LiveCodeBench v5, используя замороженную Qwen3-14B на одной RTX 5060 Ti за ~$430

— Базовая модель набирает лишь ~55% — пайплайн добавляет почти 20 п.п. за счёт генерации нескольких решений, тестирования и починки

— Стоимость — ~$0,004 за задачу (электричество) против ~$0,066 за вызов API Claude Sonnet

— Сравнение не прямое: ATLAS использует best-of-3 + итеративную починку, а Claude тестировали в режиме single-shot на другом наборе задач

— На других бенчмарках (GPQA Diamond — 47%, SciCode — 14,7%) ATLAS значительно уступает фронтирным моделям

Автор проекта, студент Исаак Тиггес, собрал всё это на одной потребительской видеокарте RTX 5060 Ti 16 ГБ. Весь инференс локальный — данные не покидают машину, API-ключи не нужны.

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

ATLAS — это не новая модель, а инженерная обвязка вокруг существующей. В основе — замороженная квантизированная Qwen3-14B-Q4_K_M от Alibaba, запущенная через патченный llama-server на K3s. Система работает в три фазы:

Фаза 1: генерация

PlanSearch извлекает ограничения из задачи и генерирует несколько различных планов решения. BudgetForcing контролирует количество thinking-токенов. DivSampling обеспечивает разнообразие кандидатов. На выходе — три варианта решения (k=3).

Одна эта фаза поднимает результат с 54,9% до 67,3% — прирост 12,4 процентных пункта.

Фаза 2: отбор лучшего кандидата

Geometric Lens — компонент, который оценивает качество каждого кандидата по внутренним представлениям модели и отправляет лучшего на исполнение в песочницу.

Важный нюанс: в текущей версии эта фаза не дала прироста (+0,0 п.п.), потому что C(x) обучалась всего на ~60 примерах — слишком мало для осмысленного энергетического ландшафта. Автор планирует исправить это в V3.1.

Фаза 3: починка провалов

Если все кандидаты провалились, модель генерирует собственные тест-кейсы и запускает PR-CoT (multi-perspective chain-of-thought repair) — итеративную починку через рассуждение с нескольких точек зрения. Модель никогда не видит правильные ответы — только свои собственные тесты.

PR-CoT спасает 36 из 42 задач, попавших в фазу починки — 85,7% успеха. Суммарный прирост фазы 3 — ещё 7,3 п.п.

Бенчмарки: что показывают цифры

Результаты ATLAS V3 на трёх бенчмарках:

Метрика pass@1-v(k=3) означает, что для каждой задачи генерируются три кандидата, из которых выбирается лучший. Это значительно легче, чем классический pass@1, где модель даёт ровно один ответ без права на повторную попытку.

Для контекста — сравнение стоимости и результата на LiveCodeBench:

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

Автор ATLAS сам признаёт ключевое ограничение: сравнение — не контролируемый head-to-head.

• ATLAS тестировали на 599 задачах LiveCodeBench v5, а Claude — на 315 задачах из данных Artificial Analysis. Это разные наборы задач
• ATLAS генерирует три кандидата, отбирает лучшего и итеративно чинит провалы. Claude тестировали в режиме single-shot (один запрос, один ответ, без повторов)
• ATLAS оптимизировался именно под LiveCodeBench — на GPQA Diamond (47%) и SciCode (14,7%) результаты значительно скромнее
• Метрика ATLAS — pass@1-v(k=3), а не классический pass@1. Это принципиально разные вещи

Как отмечает Fordel Studios, бенчмарки измеряют способность решать изолированные задачи с чёткими условиями — это около 5% того, что важно в продакшене. Остальные 95% — длинный контекст, неоднозначные требования, мультишаговое планирование.

Что действительно впечатляет

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

1. Инженерия побеждает масштаб. Базовая Qwen3-14B набирает ~55% — пайплайн ATLAS добавляет почти 20 п.п. без единой строчки файнтюнинга. Это чистая системная инженерия
2. Порог входа падает. Два года назад для локального инференса нужна была видеокарта за $2000+. Сегодня — RTX 5060 Ti за ~$430. Через два года это может быть карточка за $200
3. Полная автономность. Данные не покидают машину. Нет API-ключей, нет счетов, нет зависимости от провайдера. Для сценариев с чувствительными данными — это принципиально
4. Стоимость. ~$0,004 за задачу (электричество при $0,12/кВт·ч) — в 16 раз дешевле одного вызова Claude Sonnet API

Ограничения и планы

Автор честно документирует проблемы текущей версии:

• Geometric Lens (фаза 2) не работает — обучалась на 60 примерах, что слишком мало
• Метрический тензор G(x) неактивен — будет переработан или удалён в V3.1
• Задачи обрабатываются последовательно — нет параллелизма
• Баг SandboxAdapter со stdin — не работает tiebreaking через distinguishing input
• Система оптимизирована только под LiveCodeBench — кросс-доменная генерализация на повестке V3.1

В версии V3.1 планируется переход на Qwen3.5-9B с архитектурой DeltaNet (ускорение в 3–4 раза), переобучение Geometric Lens, параллелизация задач и расширение набора бенчмарков. Целевой результат — 80–90% на LiveCodeBench.

Требования к железу

Проект пока не plug-and-play — V3.1 обещает улучшить портативность. На текущий момент настройка под конкретное железо может потребовать ручной работы с параметрами: количество параллельных слотов, квантизация KV-кеша, размер контекста на слот.

Выводы

ATLAS — впечатляющая демонстрация того, как системная инженерия может компенсировать разрыв в масштабе моделей. Студент, одна видеокарта за $430, замороженная open-source модель — и результат, который на конкретном бенчмарке обходит коммерческую фронтирную модель.

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

Бенчмарки измеряют, может ли модель решить игрушечную задачу. Продакшен измеряет, может ли она думать.

Настоящий сигнал здесь — не в том, что локальный инференс «победил» облачный ИИ. А в том, что порог доступа к мощному ИИ-инференсу продолжает стремительно падать. Если у вас есть NVIDIA GPU с 16+ ГБ VRAM — попробуйте ATLAS на своих задачах и оцените результат.

Источники: ATLAS на GitHub (1,2K звёзд) · LiveCodeBench Leaderboard · обсуждение на Hacker News · анализ Fordel Studios

Атака затрагивает пользователей множества репозиториев на GitHub — уведомления о «критических уязвимостях» приходят прямо на почту всем подписчикам и участникам проектов.

- Тысячи фейковых security-алертов публикуются в GitHub Discussions по множеству репозиториев - Злоумышленники выдают себя за мейнтейнеров и используют поддельные CVE ID - Ссылки ведут на вредоносные расширения VS Code, размещённые на Google Drive - За фасадом — Traffic Distribution System с JS-разведкой и фильтрацией исследователей - GitHub Discussions автоматически рассылает email-уведомления всем подписчикам репозиториев

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

Кампания построена на злоупотреблении функцией GitHub Discussions — раздела для обсуждений внутри репозиториев. Атакующие создают новые аккаунты или используют малоактивные учётные записи и за считаные минуты публикуют тысячи постов с одинаковым шаблоном.

Каждый пост оформлен как срочное предупреждение о безопасности с заголовком вида Severe Vulnerability — Immediate Update Required. В тексте указаны поддельные CVE-идентификаторы (CVE — Common Vulnerabilities and Exposures, стандартная система нумерации известных уязвимостей) и ссылка на «пропатченную» версию расширения. Злоумышленники тщательно имитируют стиль настоящих security advisories и подписываются именами реальных мейнтейнеров или исследователей безопасности.

Ключевой рычаг атаки — механизм уведомлений GitHub. Все пользователи, которые подписаны на репозиторий (watchers) или участвовали в обсуждениях (participants), автоматически получают email с содержимым фейкового алерта. Таким образом, одна публикация в Discussions может охватить сотни и тысячи разработчиков.

Цепочка заражения

Ссылка из фейкового алерта ведёт на Google Drive, где размещён файл, замаскированный под обновлённое расширение VS Code. Далее запускается многоступенчатая цепочка:

1. Жертва переходит по ссылке на Google Drive и скачивает файл
2. Файл инициирует цепочку cookie-driven редиректов, которая приводит на домен drnatashachinn[.]com
3. На этом домене выполняется JavaScript-скрипт разведки — он собирает данные о системе: часовой пояс, локаль, user agent, операционную систему и индикаторы автоматизации
4. Собранные данные отправляются на C2-сервер (Command and Control — управляющий сервер атакующих) через POST-запрос
5. Сервер работает как Traffic Distribution System (TDS) — фильтрует ботов и ИБ-исследователей, пропуская к следующему этапу только реальных пользователей

Исследователям из Socket не удалось перехватить финальную полезную нагрузку (payload — вредоносный код второго этапа) — TDS-система определяла их как аналитиков и блокировала доставку. Важно: сам JS-скрипт разведки не крадёт пароли и не перехватывает учётные данные — он только собирает информацию о системе для фильтрации. Что именно получают прошедшие фильтрацию жертвы — пока неизвестно.

Как распознать фейковый алерт

Разработчикам стоит проявлять бдительность при получении уведомлений о безопасности из GitHub Discussions. Вот чеклист для проверки:

1. Проверьте автора поста — кликните на профиль. Новый аккаунт без активности или с минимальной историей — красный флаг
2. Настоящие security advisories публикуются во вкладке Security репозитория, а не в Discussions
3. Проверьте CVE ID через официальную базу cve.mitre.org или nvd.nist.gov — фейковые идентификаторы там не найдутся
4. Не скачивайте расширения VS Code из Google Drive или любых внешних источников — используйте только официальный VS Code Marketplace
5. Обращайте внимание на язык поста: паникёрские формулировки вроде «Immediate Update Required» нехарактерны для реальных мейнтейнеров
6. Если получили email-уведомление — перейдите в репозиторий и проверьте обсуждение в контексте, а не переходите по ссылкам из письма

Прецеденты: атаки через GitHub в 2024–2025

Это не первый случай использования инфраструктуры GitHub для распространения вредоносного ПО:

• Март 2025 — масштабная кампания затронула более 12 000 репозиториев. Злоумышленники публиковали фейковые security alerts и через них направляли разработчиков на авторизацию вредоносного OAuth-приложения, получая доступ к их аккаунтам
• Июнь 2024 — атакующие использовали спам-комментарии и pull requests для запуска email-уведомлений GitHub, перенаправляя разработчиков на фишинговые страницы

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

Как защититься прямо сейчас

Вот конкретные шаги, которые стоит предпринять уже сегодня:

1. Отключите email-уведомления для Discussions: Settings → Notifications → Watching → Custom → снимите галочку с Discussions
2. Включите двухфакторную аутентификацию на GitHub: Settings → Password and authentication → Enable two-factor authentication
3. Проверьте список установленных расширений VS Code: откройте Extensions (Ctrl+Shift+X) → убедитесь, что все расширения установлены из официального VS Code Marketplace
4. Не переходите по ссылкам из email-уведомлений GitHub — открывайте репозиторий напрямую в браузере
5. Сообщайте о подозрительных постах через кнопку Report в GitHub Discussions — это помогает платформе быстрее блокировать вредоносный контент

Выводы

Атака через GitHub Discussions показывает, что даже доверенные платформы могут стать каналом доставки вредоносного ПО. Злоумышленники комбинируют социальную инженерию (срочность, имитация авторитетных фигур), легитимную инфраструктуру (Google Drive, email-уведомления GitHub) и техническую изощрённость (TDS-фильтрация, JS-разведка). Подробности — в отчёте BleepingComputer.

Главное правило остаётся прежним: не устанавливайте ПО из непроверенных источников, даже если предупреждение выглядит правдоподобно. Настоящие обновления безопасности для расширений VS Code всегда доступны через официальный VS Code Marketplace.

Что такое Git

Git — это распределённая система контроля версий (Version Control System, VCS), которая отслеживает изменения в файлах и позволяет нескольким разработчикам работать над одним проектом одновременно. Git был создан Линусом Торвальдсом в 2005 году для разработки ядра Linux и сегодня является стандартом индустрии: по данным Stack Overflow Developer Survey, его используют около 93–95% профессиональных разработчиков. С помощью Git можно в любой момент вернуться к предыдущей версии кода, сравнить изменения и объединить работу нескольких людей с минимумом конфликтов — хотя конфликты при слиянии (merge conflicts) иногда возникают, Git помогает их разрешить.

- Git — бесплатная и открытая система контроля версий, созданная в 2005 году - Используется в более чем 93% профессиональных проектов по всему миру - GitHub — это облачный хостинг для Git-репозиториев, а не сам Git - Три состояния файла в Git: рабочая директория, staging area, репозиторий - Основные команды: git init, git add, git commit, git push, git pull - GitLab и Bitbucket — альтернативы GitHub с похожим функционалом - Первый коммит можно сделать за 5 минут после установки

Зачем нужна система контроля версий

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

Вот основные задачи, которые решает Git:

• История изменений — вы видите, кто, когда и что изменил в коде
• Откат к предыдущей версии — если новый код сломал проект, достаточно одной команды
• Параллельная работа — несколько человек могут работать над разными частями проекта одновременно
• Эксперименты без риска — создайте отдельную ветку, попробуйте идею, и если не понравится — просто удалите ветку
• Резервное копирование — код хранится не только локально, но и в удалённом репозитории

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

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

Рабочая директория (Working Directory)

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

Staging Area (индекс)

Промежуточная зона, куда вы добавляете файлы перед сохранением. Думайте о ней как о корзине для покупок: вы выбираете нужные товары (изменения) и кладёте их туда, прежде чем оформить заказ (сделать коммит). Команда git add перемещает файлы в staging area.

Репозиторий и коммиты

Когда вы выполняете команду git commit, Git делает снимок всех файлов из staging area и сохраняет его в историю репозитория. Каждый коммит — это точка в истории проекта с уникальным идентификатором (SHA-хешем), автором, датой и сообщением. В любой момент можно вернуться к любому коммиту.

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

Основные команды Git

Большинство повседневных задач решается с помощью 7–10 команд. Разберём их по порядку.

git init — создать репозиторий

Инициализирует новый Git-репозиторий в текущей папке. После выполнения команды появится скрытая папка .git, в которой Git хранит всю историю. Папку .git удалять нельзя — в ней хранится вся история проекта.

git add и git status — добавить файлы в staging area

Команда git status показывает текущее состояние репозитория — какие файлы изменены, какие добавлены в staging area. Команда git add добавляет файлы в staging area.

git commit — сохранить изменения

Создаёт коммит из файлов, добавленных в staging area. Сообщение коммита должно кратко описывать, что именно изменилось. Хороший формат: глагол в повелительном наклонении + что сделано.

git push и git pull — синхронизация с удалённым репозиторием

Команда git push отправляет локальные коммиты на удалённый сервер (например, GitHub). Команда git pull загружает изменения с сервера и объединяет их с локальной версией.

git branch и git merge — ветки

Ветки — одна из самых мощных функций Git. Ветка — это независимая линия разработки. Вы можете создать ветку для новой функциональности, работать в ней, не затрагивая основной код, а потом объединить (merge) с главной веткой.

Что такое GitHub

GitHub — это облачная платформа для хостинга Git-репозиториев. Если Git — это инструмент на вашем компьютере, то GitHub — это место в интернете, где вы храните свой код и делитесь им с другими. Главная страница GitHub — github.com — основана в 2008 году и сегодня насчитывает более 100 миллионов разработчиков и свыше 420 миллионов репозиториев.

GitHub добавляет поверх Git множество удобных возможностей:

• Pull Request (PR) — предложение изменений с обсуждением кода перед слиянием
• Issues — система задач и багов прямо внутри репозитория
• Actions — автоматизация: тесты, деплой, сборка при каждом коммите
• GitHub Pages — бесплатный хостинг статических сайтов прямо из репозитория
• Discussions — форум для обсуждений внутри проекта
• Code Review — удобный интерфейс для ревью кода с комментариями к строкам

Git — это технология, а GitHub — это сервис поверх этой технологии. Можно использовать Git без GitHub (например, хранить репозиторий на собственном сервере), но нельзя использовать GitHub без Git.

Git vs GitHub vs GitLab vs Bitbucket

Разработчики часто путают эти понятия. Вот краткое сравнение четырёх основных инструментов экосистемы.

• Git — локальная система контроля версий, работает без интернета, устанавливается на компьютер
• GitHub — крупнейший хостинг для Git-репозиториев, принадлежит Microsoft с 2018 года, идеален для open-source
• GitLab — альтернатива GitHub с упором на DevOps, есть self-hosted версия, популярен в корпоративной среде
• Bitbucket — продукт Atlassian (Jira, Confluence), хорошо интегрируется с их экосистемой, популярен в командах

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

Как начать работать с Git: пошаговая инструкция

Следуйте этой инструкции, и через 10–15 минут у вас будет первый репозиторий на GitHub.

Шаг 1. Установка Git

• Windows: скачайте установщик с git-scm.com/download/win и запустите его
• macOS: откройте терминал и выполните brew install git (или xcode-select --install)
• Linux (Ubuntu/Debian): sudo apt install git

Шаг 2. Настройка имени и почты

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

Шаг 3. Создать аккаунт на GitHub

Перейдите на github.com, нажмите «Sign up» и заполните форму регистрации. Выберите бесплатный тарифный план — для начинающих он полностью достаточен.

Шаг 4. Создать первый репозиторий и сделать коммит

Выводы

Git — это не просто инструмент для разработчиков, это основа профессиональной работы с кодом. Без него невозможно представить ни командную разработку, ни open-source проекты, ни современный DevOps. Хорошая новость: базовые команды можно освоить за один вечер, а дальше — практика и опыт.

Что делать дальше:

1. Установите Git и создайте аккаунт на GitHub прямо сейчас
2. Сделайте первый репозиторий по инструкции из этой статьи
3. Попрактикуйтесь с ветками: создайте ветку, внесите изменения, слейте в main
4. Попробуйте сделать Pull Request в любой open-source проект — даже исправление опечатки в README считается
5. Изучите команды git stash, git cherry-pick и git bisect — они пригодятся на следующем уровне

Знание Git сегодня — обязательное требование для любого разработчика. Если вы только начинаете — это один из первых инструментов, который нужно освоить. Если уже работаете — углубляйтесь в продвинутые возможности: rebase, stash, cherry-pick, подмодули. Подробнее о всех возможностях можно прочитать в официальной документации Git.

Git лежит в основе всей современной DevOps-экосистемы. Следующий шаг — освоить Docker для контейнеризации приложений: именно связка Git + Docker образует фундамент любого CI/CD-пайплайна. А если хотите автоматизировать тестирование и доставку кода — читайте нашу статью о том, что такое CI/CD.

Если хотите собрать из Git, Docker, CI/CD, Kubernetes и Helm единый маршрут, посмотрите план обучения DevOps-инженера. Там видно, почему Git идёт первым и как из него вырастает вся следующая цепочка инструментов.

Если вы используете Nix, присмотритесь к Garnix — он анализирует ваш flake, определяет, что нужно собрать, и делает это. Никакого YAML. Лучший CI-конфиг — это отсутствие CI-конфига. Но эта статья не для вас. Эта статья — для всех остальных.

Часть I: Нисхождение

Просмотрщик логов, или Куда уходит ваш день

Билд упал. Красный крестик. Вы нажимаете на него и попадаете... нет, не в логи. Вы попадаете на страницу Checks Summary. Оттуда — в Workflow Runs. Оттуда — в Jobs. Каждый шаг свёрнут. Каждая страница — это новый спиннер. Три-четыре клика, чтобы добраться до собственно ошибки. Это не отладка — это квест.

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

На длинных логах скроллбар становится декоративным. Он есть, он выглядит как скроллбар, но прокрутить до конца вы не сможете. Приходится скачивать raw-логи и открывать в текстовом редакторе, как будто на дворе 2003 год и вы только что поставили Gentoo.

Кнопка «Назад» — это рулетка. Вы ожидаете вернуться на PR, но попадаете на случайную страницу GitHub Actions, которую видите впервые в жизни.

А теперь — отладка. Вы пушите коммит, ждёте, смотрите логи. Что-то падает. Добавляете run: env. Пушите снова. Ждёте. Двадцатиминутный цикл обратной связи ради однострочного изменения. Повторяете четырнадцать раз. Ваш вечер закончился.

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

Ловушка YAML

Любая CI-система рано или поздно сводится к «куче YAML-файлов». Но YAML в GitHub Actions — это нечто особенное. Свой язык выражений, своя объектная модель контекста, свои правила интерполяции строк. Это уже не конфигурация — это программирование. Только без отладчика, без типов и без чувства собственного достоинства.

Синтаксис ${{ }} — это танец. Неправильно поставили кавычку? Ждите четыре минуты, пока раннер запустится, чтобы узнать, что ваша строка была молча проглочена. Этот язык выражений «рос в темноте, без присмотра» — слишком сложный для конфига, слишком ограниченный для настоящего языка программирования.

«А как же маркетплейс!»

GitHub Actions Marketplace — это npm для CI. Комьюнити-экшены разного качества: shell-скрипты с Dockerfile и мечтой.

uses: some-stranger/cool-action@v2 — вы только что дали незнакомцу доступ к вашему репозиторию, секретам и среде сборки. Можно, конечно, пригвоздить версию к SHA. Никто этого не делает.

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

Вы не владеете своими вычислениями

Вы арендуете раннеры у Microsoft — медленные, ограниченные в ресурсах, не поддающиеся настройке. Это породило целую индустрию стартапов: Namespace, Blacksmith, Actuated, Runs-on, BuildJet — компании, которые существуют исключительно потому, что штатные раннеры GitHub Actions непригодны для продакшена.

Self-hosted раннеры решают проблему вычислений, но вы по-прежнему пишете YAML для GitHub Actions — это как поставить новый двигатель в машину, которая загорается каждый раз, когда вы включаете радио.

Microsoft — это место, куда амбициозные инструменты для разработчиков приходят, чтобы стать корпоративными SKU.

Мелочи, которые накапливаются

• actions/cache — ключи кеша непонятные, промахи молчаливые, вытеснение непрозрачное.
• Reusable workflows нельзя вкладывать друг в друга, и у них нет чистого доступа к контексту вызывающего воркфлоу.
• GITHUB_TOKEN permissions — лабиринт. permissions: write-all — это кувалда, а fine-grained permissions — это пазл на 500 деталей без картинки на коробке.
• Concurrency controls — топорные. Отменить текущий запуск? Одна строка. Что-нибудь более тонкое? Нет.
• Секреты нельзя использовать в условиях if: — обоснованное ограничение безопасности, но с точки зрения DX — катастрофа.

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

«Просто напиши баш-скрипты»

Искушение велико: просто засунуть всё в run: и написать большой shell-скрипт.

И это работает! А потом скрипт растёт. Условия, функции, парсинг аргументов, второй скрипт, обработка ошибок, логирование, «ну и чуть-чуть параллелизма».

Проходит три месяца — и вот у вас 800 строк баша, которые переизобретают параллельное выполнение задач при помощи wait и PID-файлов.

Race condition в cleanup-trap только на ядре Linux 6.x, вы в отпуске, телефон звонит.

Вы не избежали CI. Вы построили CI-систему. Просто она хуже.

Bash хорош как клей. Но он не система сборки. Не тестовый фреймворк. Не оркестратор. Каждый раз, когда кто-то говорит «просто напиши баш-скрипт», где-то в мире рождается ещё один 800-строчный ci.sh.

Часть II: Выход

Просмотрщик логов, который не убивает браузер

У Buildkite просмотрщик логов — это веб-страница, которая показывает логи и не падает. Звучит как минимальное требование к продукту, но после GitHub Actions это ощущается как роскошь.

• ANSI-цвета работают — вывод тестового фреймворка приходит в первозданном виде, а не в виде кашицы из escape-последовательностей.
• Аннотации — богатый Markdown-вывод прямо на странице билда.
• Отладка: агент крутится на вашем железе, вы можете зайти на машину по SSH. Как нормальный человек, а не как археолог, расшифровывающий логи по слоям.

YAML, который знает своё место

YAML в Buildkite описывает пайплайн: шаги, команды, плагины. Это структура данных, а не язык программирования. Когда нужна логика — пишите скрипт на нормальном языке. Запускайте локально. Как человек, у которого есть достоинство.

Оркестрацию — в конфиг, логику — в код. Buildkite уважает эту границу.

Вы владеете своими вычислениями

Агент Buildkite — это один бинарник на ваших машинах. Ваш облачный провайдер, ваш дата-центр, ваше странное кастомное железо.

Никакой побочной индустрии «Buildkite, только быстрее» — просто поставьте машины помощнее.

GitHub Actions выдаст вам стандартную Ubuntu-виртуалку с эмоциональной теплотой зала ожидания в районной поликлинике.

Динамические пайплайны

Шаги пайплайна — это данные. Вы можете генерировать их динамически в рантайме.

Скрипт смотрит на монорепо, определяет, что изменилось, и загружает именно те шаги, которые нужны. Никаких захардкоженных матриц, никаких спагетти из if: contains(...).

По поводу плагинов

Честно говоря, структурно плагины Buildkite похожи на маркетплейс GitHub Actions.

Но: тонкие shell-хуки вместо целых Docker-образов, меньше поверхности атаки. И главное — всё запускается на вашем железе, так что радиус поражения — под вашим контролем.

Маленькие радости

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

Объективно — бесполезная мелочь. Но она рассказывает вам о людях, которые создали этот продукт.

GitHub Actions — это продукт, спроектированный комитетом, который ни разу не задал вопрос: «А пользователю от этого радостно?»

Заключение

GitHub Actions победил не потому, что он хорош, а потому что он стоит по умолчанию. Internet Explorer от мира CI.

Если у вас маленькая команда и простое приложение — он сойдёт. Серьёзно, не переезжайте ради принципа.

Но если у вас продакшен-системы, монорепо, билды дольше пяти минут — присмотритесь к Buildkite.

GitHub Actions — это самая простая CI-система для старта. Buildkite — это лучшая CI-система для жизни.

Если ваш CI воюет с вами больше, чем помогает — проблема не в вас. Проблема в инструменте.

Это литературный перевод и адаптация статьи Иэна Данкана (Ian K. Duncan) GitHub Actions is Killing Your Team. Мнение автора оригинала может не совпадать с мнением редакции.

Distance-Engagement Oscillation (DEO) — это метод промптинга, основанный на теории перцептивного рефрейминга (Perceptual Reframing Theory, PRT). Рефрейминг — это способность посмотреть на проблему под другим углом, сменив «рамку» восприятия. DEO заставляет языковую модель чередовать два когнитивных режима: аналитическую дистанцию (анализ проблемы со стороны) и эмоциональное вовлечение (проживание проблемы изнутри). Автор метода — Гёкхан Гёкмен из Технического университета Бурсы.

Результаты эксперимента на трёх open-source LLM показали: DEO-промптинг повышает качество креативного мышления модели на 40–55% по сравнению с обычными промптами. Эффект подтверждён тремя независимыми оценщиками с размером эффекта Cohen's d от 1.29 до 1.63 («очень большой»).

Главное:
— DEO-промптинг улучшает креативное мышление LLM на 40–55% (Cohen's d = 1.29–1.63)
— Предсказанный порядок DEO > Distance > Engagement ≥ Vanilla подтвердился во всех 9 комбинациях модель×оценщик (p < .001)
— Метод работает без дообучения — только через структуру промпта
— Тестировалось на Llama 3.3 70B, Qwen3 32B и Llama 4 Scout
— Код и данные открыты на GitHub под лицензией CC BY 4.0

Как работает DEO-промптинг

В основе метода лежит Perceptual Reframing Theory (PRT) — теория, объединяющая исследования из области инсайтов, самодистанцирования, теории уровней конструирования и психотерапии. PRT описывает девять когнитивных путей, которыми люди переключают восприятие при решении творческих задач.

DEO использует четыре шага, чередуя аналитическую дистанцию и эмоциональное вовлечение:

1. ANALYSE (дистанция) — модель анализирует проблему со стороны, выявляя скрытые допущения и рамки мышления
2. FEEL (вовлечение) — модель «проживает» проблему, подключая эмпатию и эмоциональный контекст
3. REFRAME (дистанция) — модель формулирует альтернативные интерпретации на основе обоих режимов
4. ENVISION (вовлечение) — модель представляет конкретную реализацию нового решения

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

Дизайн эксперимента

Исследование включало два анализа с общим объёмом в 13 500 вызовов генерации:

Анализ 1: промпты с рефреймингом vs обычные промпты

• 50 оригинальных задач из 8 категорий когнитивных ловушек: якорение, ложная бинарность, функциональная фиксированность, фрейминговая ловушка, нарративный замок, нулевая сумма, эффект Эйнштеллунга, многоходовые задачи
• 3 open-source LLM: Llama 3.3 70B, Qwen3 32B, Llama 4 Scout 17B-16E
• 5 запусков на каждое условие (temperature 0.7) с усреднением
• 3 независимых оценщика: самооценка модели + Claude Sonnet 4 + GPT-4.1 (все слепые к условию)
• 5 критериев оценки: разнообразие фреймов, выявление допущений, новизна решения, ревизия предпосылок, корректность

Анализ 2: четыре условия DEO

Для 20 задач с чистыми путями дистанции сравнивались четыре условия:

• Vanilla — обычный промпт без дополнительной структуры
• Distance-only — только аналитическая дистанция
• Engagement-only — только эмоциональное вовлечение
• DEO — полная осцилляция между дистанцией и вовлечением

Результаты

Предсказанный теорией порядок DEO > Distance > Engagement ≥ Vanilla подтвердился во всех 9 комбинациях модель × оценщик (все Friedman p < .001).

Анализ 1: рефрейминг значимо лучше обычных промптов

Средние баллы по 5-балльной шкале рефрейминга:

• Llama 3.3 70B — vanilla: 2.84, рефрейминг: 3.99 (Δ = +1.15, d = 1.29)
• Qwen3 32B — vanilla: 2.86, рефрейминг: 4.00 (Δ = +1.14, d = 1.56)
• Llama 4 Scout — vanilla: 2.82, рефрейминг: 3.98 (Δ = +1.16, d = 1.42)

Все 9 пар модель × оценщик показали статистическую значимость на уровне p < .001. При этом корректность ответов не снизилась — напротив, также значимо выросла.

Анализ 2: осцилляция эффективнее любого режима по отдельности

Средние баллы по четырём условиям (оценщик OpenAI, Llama 3.3 70B):

• Vanilla: 2.37
• Engagement-only: 2.92
• Distance-only: 3.61
• DEO: 4.06

Дистанция значительно превосходит вовлечение во всех 9 случаях — это подтверждает гипотезу PRT о том, что увидеть фрейм мышления сложнее, чем прочувствовать проблему. DEO добавляет значимое улучшение поверх дистанции в 4 из 9 случаев (d = 0.40–1.06).

Какие задачи выигрывают больше всего

Максимальный эффект DEO наблюдается на задачах с нарративным замком (narrative lock-in) — когда модель застревает в одной истории или интерпретации. Здесь прирост достигает Δ = +2.14, d = 3.23. На втором месте — задачи с фрейминговой ловушкой и эффектом Эйнштеллунга (фиксация на привычном методе решения).

Девять путей рефрейминга PRT

Теория PRT выделяет девять когнитивных путей, которые используются как промпт-стратегии:

1. Name the Frame — назвать скрытую рамку мышления (Δ до +1.60)
2. Decompose to Generic — разложить задачу на абстрактные компоненты
3. Distant Analogy — применить аналогию из другой области (Δ до +1.64)
4. Incubate & Reset — сделать паузу и вернуться к задаче заново
5. Invert — перевернуть задачу наоборот (Δ до +1.38)
6. Premise Reflection — поставить под сомнение исходные предпосылки (Δ до +1.56)
7. Surprise as Signal — использовать удивление как сигнал для рефрейминга (Δ до +1.87)
8. Confidence Calibration — калибровать уверенность в ответе
9. Step Outside — посмотреть на задачу глазами другого человека (Δ до +1.34)

Самые эффективные пути: Name the Frame, Distant Analogy и Surprise as Signal. Все три связаны с дистанцией — способностью модели "увидеть" рамку, в которой она мыслит.

Как попробовать DEO самому

Репозиторий включает slash-команду /reframe для Claude Code. Она применяет четырёхшаговую осцилляцию DEO к любой задаче:

Claude пройдёт четыре этапа — ANALYSE, FEEL, REFRAME, ENVISION — и выдаст рефреймированный ответ с альтернативными интерпретациями проблемы.

Для воспроизведения полного эксперимента:

Полный эксперимент (3 модели, 4 условия, 5 запусков, 3 оценщика) обходится примерно в $15–20.

FAQ

Что такое DEO-промптинг?

DEO (Distance-Engagement Oscillation) — это метод промптинга, в котором языковая модель чередует аналитический режим (дистанция) и эмоциональный режим (вовлечение). Такое чередование помогает модели выйти за рамки привычного мышления и находить более креативные решения. Метод основан на теории перцептивного рефрейминга (PRT) из когнитивной психологии.

На каких моделях работает DEO?

В исследовании метод тестировался на трёх open-source моделях: Llama 3.3 70B, Qwen3 32B и Llama 4 Scout 17B-16E. Эффект был стабильно значимым на всех трёх. Поскольку DEO работает на уровне промпта (zero-shot, без дообучения), он применим к любой LLM, способной следовать структурированным инструкциям.

Чем DEO отличается от Chain-of-Thought?

Chain-of-Thought заставляет модель рассуждать пошагово в одном когнитивном режиме. DEO добавляет переключение между режимами — от анализа к эмпатии и обратно. Это помогает модели не просто "думать дольше", а "думать иначе", выявляя скрытые предпосылки и рамки мышления, которые блокируют креативные решения.

Снижается ли корректность ответов при использовании DEO?

Нет. В эксперименте корректность ответов значимо выросла во всех 9 комбинациях модель × оценщик (p < .001). DEO не жертвует точностью ради креативности — оба показателя улучшаются одновременно.

Можно ли использовать DEO в продакшене?

Код и данные открыты под лицензией CC BY 4.0. Метод не требует дообучения или специальной инфраструктуры — достаточно модифицировать системный промпт. Четырёхшаговая структура ANALYSE–FEEL–REFRAME–ENVISION легко интегрируется в любой пайплайн.

Выводы

Аналитическая дистанция показывает модели, что рамка мышления существует. Эмоциональное вовлечение делает сдвиг восприятия устойчивым. Именно осцилляция между ними даёт максимальный эффект.

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

Полный код эксперимента, 307 JSON-файлов с ответами моделей и статистический анализ доступны в репозитории на GitHub. Препринт статьи опубликован на Zenodo (DOI: 10.5281/zenodo.19252225).

Попробуйте DEO-промптинг на своих задачах — возможно, ваша LLM способна на большее, чем вы думаете.

LiteLLM — это open-source прокси для работы с API различных LLM-провайдеров: OpenAI, Anthropic, Azure, Bedrock и ещё сотней других. Библиотека позволяет переключаться между моделями через единый интерфейс с автоматическими фоллбэками, ретраями и трекингом расходов. При 97 миллионах загрузок в месяц (около 3,4 млн в день) это один из самых популярных инструментов в AI-инфраструктуре.

В скомпрометированных версиях 1.82.7 и 1.82.8, опубликованных на PyPI, обнаружили встроенный стилер учётных данных. Он крал SSH-ключи, токены облачных сервисов, API-ключи и пароли, а затем расползался по Kubernetes-кластерам.

Ключевое: Версии LiteLLM 1.82.7 и 1.82.8 на PyPI содержали стилер, крадущий SSH-ключи, облачные токены и API-ключи. Версия 1.82.8 запускала вредоносный код при каждом старте Python — даже без импорта библиотеки. Если вы устанавливали LiteLLM 24 марта 2026 года — проверьте свои системы. Последняя чистая версия — 1.82.6.

Но эта атака — не изолированный инцидент. Это финал пятидневной supply chain атаки (атаки через цепочку поставок — внедрение вредоносного кода в легитимный пакет через компрометацию его инфраструктуры). За ней стоит группировка TeamPCP — ранее неизвестная группа, которая за последнюю неделю марта целенаправленно атаковала инструменты безопасности и разработки. Кампания началась с компрометации сканера уязвимостей Trivy и через цепочку украденных CI/CD-креденшалов дотянулась до LiteLLM.

Разбираем всю цепочку атаки от начала до конца — подробнее, чем где-либо ещё.

Хронология: пять дней, три вендора, пять экосистем

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

19 марта: Trivy — точка входа

Всё началось с Trivy — open-source сканера уязвимостей от Aqua Security, которым пользуются тысячи компаний для проверки контейнеров и кода.

Атакующие использовали скомпрометированные учётные данные мейнтейнера, чтобы:

• Опубликовать вредоносный релиз Trivy v0.69.4, который прошёл через стандартную release-машинерию и попал в GHCR, ECR Public, Docker Hub, deb/rpm-пакеты
• Подменить 76 из 77 тегов aquasecurity/trivy-action на вредоносные коммиты
• Заменить все 7 тегов aquasecurity/setup-trivy

Вредоносный код в GitHub Actions сканировал память процесса Runner.Worker, собирал креденшалы, шифровал данные AES+RSA и отправлял на подставной домен scan.aquasecurtiy[.]org — обратите внимание на опечатку в слове «security». Если прямая эксфильтрация не удавалась, малварь создавала публичный репозиторий tpcp-docs через GitHub-токен жертвы и сливала данные туда.

20–22 марта: npm-червь и дефейс

Уже на следующий день украденные токены пошли в дело. Атакующие запустили самораспространяющегося npm-червя: 28 пакетов в @EmilGroup, 16 в @opengov, плюс отдельные пакеты в других скоупах. Червь крал npm-токены из скомпрометированных окружений, проверял, к каким пакетам они дают доступ, поднимал patch-версию, подставлял оригинальный README для маскировки и переиздавал пакет с вредоносной начинкой.

К 22 марта та же инфраструктура начала обслуживать Kubernetes-скрипт с разделением жертв по геолокации. На иранских системах деплоился DaemonSet с контейнером kamikaze, который удалял файловую систему хоста и перезагружал ноду. На остальных — устанавливал персистентный бэкдор.

В тот же день атакующие дефейснули 44 репозитория внутренней GitHub-организации Aqua Security (aquasec-com), переименовав их с префиксом tpcp-docs- и описанием «TeamPCP Owns Aqua Security».

23 марта: Checkmarx

Кампания добралась до Checkmarx — ещё одного крупного вендора в сфере безопасности приложений. Были скомпрометированы:

• Checkmarx/kics-github-action — сканер инфраструктурного кода
• Checkmarx/ast-github-action — GitHub Action для платформы Checkmarx
• Расширения VS Code в реестре Open VSX: ast-results v2.53.0 (около 36 000 загрузок) и cx-dev-assist v1.7.0 (около 500 загрузок)

Паттерн тот же: стилер креденшалов, привязанный к домену checkmarx[.]zone, с фоллбэком на публичный репозиторий docs-tpcp для эксфильтрации.

24 марта: LiteLLM

В 10:52 UTC на PyPI появилась версия LiteLLM 1.82.8. Соответствующий тег или релиз на GitHub отсутствовал — пакет был загружен напрямую, в обход стандартного процесса. По данным ReversingLabs, был скомпрометирован GitHub-аккаунт сооснователя и CEO LiteLLM Криша Дхолакии — предположительно, через CI/CD-пайплайн, где Trivy использовался без пиннинга версии.

Через три часа команда безопасности PyPI поставила проект на карантин. Скомпрометированные версии были удалены. Последняя чистая версия — 1.82.6. Но при 3,4 миллионах загрузок в день даже три часа — это огромное окно.

Мейнтейнеры LiteLLM опубликовали security-апдейт, подтвердив компрометацию и рекомендовав всем пользователям обновиться до версии 1.82.6 или выше (после снятия карантина). Issue #24512 на GitHub, описывающий уязвимость, был закрыт — предположительно, самим атакующим через скомпрометированный аккаунт.

Как работает вредоносный код

Теперь разберём, что именно попадало на машины жертв. LiteLLM оказался скомпрометирован в двух версиях, и они существенно различаются по механизму запуска.

Версия 1.82.7: инъекция в proxy_server.py

В версии 1.82.7 вредоносный код был внедрён в файл litellm/proxy/proxy_server.py. Малварь запускалась только при реальном использовании LiteLLM Proxy в приложении. Если пакет был установлен, но прокси-сервер не запускался, код мог не сработать.

Версия 1.82.8: .pth-файл — запуск без импорта

Версия 1.82.8 принципиально опаснее. В wheel-пакет был добавлен файл litellm_init.pth размером 34 628 байт, содержащий дважды закодированный в base64 вредоносный код.

.pth-файлы — малоизвестная особенность Python. Согласно документации модуля site, исполняемые строки в .pth-файлах выполняются автоматически при каждом запуске интерпретатора. Не при импорте библиотеки, а при запуске любого Python-процесса в окружении, где установлен пакет.

Это означает: достаточно было выполнить pip install litellm==1.82.8, и каждый последующий запуск Python на этой машине активировал стилер. Не нужно писать import litellm — даже python -c "print('hello')" запускал вредоносный код.

Три стадии: сбор, шифрование, эксфильтрация

Стадия 1 — сбор. Скрипт прочёсывает машину и собирает:

• SSH-ключи и конфигурации (~/.ssh/)
• .env-файлы с секретами
• Креденшалы AWS (Access Key, Secret Key), GCP (ADC), Azure
• Конфигурации Kubernetes (~/.kube/config)
• Docker-конфиги (~/.docker/config.json)
• Пароли баз данных
• Историю шелла (bash_history, zsh_history)
• Файлы криптокошельков
• Все переменные окружения
• Данные с облачных metadata-эндпоинтов (IMDS)

Стадия 2 — шифрование. Собранные данные упаковываются в tar-архив и шифруются гибридной схемой: случайный сессионный ключ AES-256-CBC для данных, зашифрованный захардкоженным 4096-битным RSA-публичным ключом.

Стадия 3 — эксфильтрация. Зашифрованный архив отправляется POST-запросом на models.litellm[.]cloud (домен не имеет отношения к настоящему litellm.ai) с заголовком X-Filename: tpcp.tar.gz.

Горизонтальное распространение в Kubernetes

Если на машине обнаружен токен сервисного аккаунта Kubernetes, малварь переходит в режим горизонтального распространения (lateral movement):

1. Читает все секреты кластера во всех неймспейсах
2. Создаёт привилегированный pod на каждой ноде в kube-system на основе образа alpine:latest
3. Каждый pod монтирует корневую файловую систему хоста
4. Устанавливает персистентный бэкдор в /root/.config/sysmon/sysmon.py
5. Регистрирует systemd user service для автозапуска

Таким образом, компрометация одного pip-пакета превращается в полную компрометацию всего Kubernetes-кластера.

Персистентность и бэкдор

На локальной машине малварь создаёт:

• ~/.config/sysmon/sysmon.py — скрипт-бэкдор
• ~/.config/systemd/user/sysmon.service — systemd unit для автозапуска

После установки бэкдор периодически обращается к https://checkmarx[.]zone/raw, скачивает файл в /tmp/pglog и выполняет его содержимое. Это даёт атакующим возможность удалённо выполнять произвольный код на скомпрометированных машинах в любой момент.

Как обнаружили: баг в малвари устроил fork-бомбу

Ирония истории в том, что атаку обнаружили благодаря ошибке самих хакеров.

Команда FutureSearch столкнулась с проблемой случайно: MCP-плагин в IDE Cursor подтянул LiteLLM как транзитивную зависимость. Вредоносный .pth-файл запускал дочерний Python-процесс через subprocess.Popen. Но поскольку .pth-файлы срабатывают при каждом запуске интерпретатора, дочерний процесс тоже запускал малварь, та порождала ещё один процесс — и так далее.

Результат — экспоненциальная fork-бомба, которая мгновенно съедала всю оперативную память и вешала систему. Без этого бага стилер мог бы работать незамеченным значительно дольше.

Мы были взломаны… тысячи людей, вероятно, прямо сейчас под атакой

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

Если в ваших проектах, CI/CD-пайплайнах или на рабочих машинах устанавливался LiteLLM 24 марта или позже — проверьте версию:

Если обнаружена версия 1.82.7 или 1.82.8:

1. Удалите пакет и очистите кэши: pip cache purge, rm -rf ~/.cache/uv
2. Проверьте наличие бэкдора: файлы ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service
3. В Kubernetes: аудит kube-system на наличие подов node-setup-*, проверка секретов на несанкционированный доступ
4. Ротация всех креденшалов: SSH-ключи, облачные токены (AWS, GCP, Azure), API-ключи, пароли БД, .env-файлы
5. Сетевые логи: проверьте обращения к models.litellm[.]cloud, checkmarx[.]zone, scan.aquasecurtiy[.]org
6. Восстановление: не ограничивайтесь удалением пакета — пересобирайте системы из известных чистых образов с закреплёнными (pinned) зависимостями

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

Индикаторы компрометации (IoC)

Вредоносные домены:

• models.litellm[.]cloud — C2 для LiteLLM
• checkmarx[.]zone — C2, используемый для персистентности и Checkmarx-атаки
• scan.aquasecurtiy[.]org — C2 для Trivy-атаки

Файлы на диске:

• litellm_init.pth в site-packages/
• ~/.config/sysmon/sysmon.py
• ~/.config/systemd/user/sysmon.service
• /tmp/pglog
• /tmp/.pg_state

Kubernetes-артефакты:

• Поды с именами node-setup-* в kube-system
• Контейнеры с именами kamikaze или provisioner

Инциденту присвоен идентификатор CVE-2026-33634. Полный список IoC в формате CSV доступен в репозитории Datadog Security Labs.

Частые вопросы

Что такое LiteLLM и зачем его используют?

LiteLLM — это open-source Python-библиотека и прокси-сервер, который предоставляет единый интерфейс для работы с более чем 100 LLM-провайдерами (OpenAI, Anthropic, Azure, AWS Bedrock и другие). Библиотека позволяет переключаться между моделями без изменения кода, автоматически обрабатывает фоллбэки и ретраи, отслеживает расходы. По данным PyPI, пакет загружается около 3,4 миллионов раз в день.

Какие версии LiteLLM скомпрометированы?

Скомпрометированы версии 1.82.7 и 1.82.8, опубликованные на PyPI 24 марта 2026 года. Обе версии удалены. Последняя безопасная версия — 1.82.6. Версия 1.82.8 опаснее: она запускает вредоносный код при каждом старте Python через механизм .pth-файлов, тогда как 1.82.7 активируется только при использовании прокси-сервера.

Как проверить, затронут ли я?

Выполните pip show litellm для проверки версии и find ~/.cache/uv -name "litellm_init.pth" для поиска вредоносного файла в кэше. Также проверьте наличие бэкдора: файлы ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service. В Kubernetes ищите поды node-setup-* в namespace kube-system.

Кто стоит за атакой?

Атака приписывается группировке TeamPCP, которая за последнюю неделю марта 2026 года провела серию supply chain атак на инструменты разработки и безопасности: сканер уязвимостей Trivy (Aqua Security), GitHub Actions и расширения VS Code от Checkmarx, npm-пакеты, и в финале — LiteLLM. Инциденту присвоен идентификатор CVE-2026-33634.

Что такое .pth-файл и почему он опасен?

Файлы с расширением .pth, размещённые в директории site-packages, автоматически обрабатываются модулем site Python при каждом запуске интерпретатора. Исполняемые строки в таких файлах выполняются без явного импорта библиотеки. В случае LiteLLM 1.82.8 файл litellm_init.pth содержал дважды закодированный в base64 вредоносный скрипт, который запускался при каждом вызове python в скомпрометированном окружении.

Выводы

Ирония инцидента — в том, что LiteLLM по определению хранит API-ключи ко всем LLM-провайдерам организации. Атакующие выбрали пакет, который гарантированно имеет доступ к самым ценным секретам.

Одна зависимость. Одна цепная реакция. Пять экосистем supply chain скомпрометированы менее чем за месяц

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

Устанавливать пакеты из публичного реестра без проверки хешей и без lock-файлов — значит фактически отдать root-доступ любому, кто сможет скомпрометировать аккаунт мейнтейнера. Как ёмко выразилась Ноэлль Мурата, старший инженер по безопасности в Xcape: «Это цифровой эквивалент того, чтобы съесть бутерброд, найденный в метро, и удивиться пищевому отравлению».

Подробный технический анализ от Datadog Security Labs доступен здесь. Оригинальный отчёт FutureSearch — здесь. Официальный security-апдейт LiteLLM — здесь.

Проверьте свои зависимости сегодня. Команды для аудита — в разделе выше.

В марте 2026 Trivy — один из наиболее популярных open-source сканеров уязвимостей — был скомпрометирован дважды за три недели. Пострадали тысячи CI/CD-пайплайнов по всему миру. Если ваш проект использует Trivy или связанные с ним GitHub Actions, эта информация критически важна для защиты вашей инфраструктуры.

Хронология инцидентов: две атаки за три недели

Первая атака: CVE-2026-28353 и hackerbot-claw

Даты: 21–28 февраля 2026

Злоумышленники эксплуатировали критическую уязвимость в GitHub Actions-воркфлоу через механизм pull_request_target. Автономный бот hackerbot-claw автоматически создал Pull Request #10252, что позволило выполнить произвольный код в контексте с доступом к секретам репозитория. Через эту атаку было скомпрометировано VSCode-расширение Trivy, а вредоносная версия v1.8.12 попала в Open VSIX Registry.

Инцидент получил идентификатор CVE-2026-28353 с максимальной оценкой критичности CVSS 10.0. Это означает полную компрометацию конфиденциальности, целостности и доступности системы. Причём исходный disclosure discussion (#10265) был удалён во время второго инцидента, что вызвало критику сообщества за недостаточную прозрачность в обработке уязвимостей.

Вторая атака: TeamPCP и ретроактивное отравление тегов

Дата: 19 марта 2026

Группа TeamPCP использовала учётные данные, украденные в первом инциденте, и опубликовала вредоносный релиз v0.69.4. Однако главная особенность этой атаки — ретроактивное отравление тегов: атакующие переместили (force-push) 76 из 77 существующих тегов релизов так, чтобы они указывали на вредоносный код.

Это означает, что даже если вы использовали «старую стабильную версию», вы также могли получить малварь. Команды, которые зафиксировали версии через теги, оказались под ударом, поскольку теги были изменены задним числом. Полезная нагрузка обеих атак была направлена на кражу секретов CI/CD: GitHub-токенов, npm-токенов, API-ключей и других данных из GitHub Secrets.

Каскадный эффект: CanisterWorm

Ситуация усугубилась каскадным эффектом: украденные npm-токены запустили CanisterWorm — самораспространяющегося червя, который заразил от 28 до 47 пакетов в npm-реестре.

Как проверить свой проект на компрометацию: инструкция

Если вы использовали Trivy или связанные GitHub Actions в период с февраля по март 2026 года, по умолчанию считайте, что ваш пайплайн скомпрометирован. Выполните следующие проверки в указанном порядке.

1. Проверьте версии Trivy и GitHub Actions

Откройте ваши workflow-файлы (.github/workflows/*.yml) и найдите использования trivy-action и setup-trivy. Обратите особое внимание на версии.

Статус версий на момент публикации (22.03.2026, 14:30 GMT+3):

2. Проанализируйте логи CI/CD на подозрительную активность

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

• Необъяснимые HTTP-запросы к неизвестным доменам или IP-адресам.
• Запросы к canister-контейнерам на блокчейне Internet Computer (ICP), это характерный признак CanisterWorm.
• Странное поведение переменных окружения, особенно GITHUB_TOKEN и NPM_TOKEN.
• Подозрительные base64-кодированные строки в выводе, которые могут маскировать полезную нагрузку.

3. Проверьте npm-пакеты на заражение CanisterWorm

Если ваши npm-токены были скомпрометированы, злоумышленники могли опубликовать через них вредоносные версии ваших пакетов. CanisterWorm самораспространяется: каждый заражённый пакет пытается заразить другие пакеты, к которым имеет доступ.

Используйте инструменты для сканирования ваших npm-пакетов на наличие вредоносного кода, зарубежные кибербез-издания рекомендуют Socket.dev или Snyk.

Особое внимание стоит уделить пакетам, опубликованным или обновлённым в период с 19 по 22 марта 2026 года — именно в это время происходила первичная волна распространения CanisterWorm.

4. Проведите аудит учётных данных и токенов

Надо определить, какие секреты были доступны скомпрометированным workflow. Проверьте следующие категории токенов:

GITHUB_TOKEN — автоматически предоставляется workflow → доступ к репозиторию и коду
NPM_TOKEN — публикация npm-пакетов → публикация вредоносных версий
DOCKER_USERNAME/PASSWORD — публикация контейнеров → компрометация образов
AWS_ACCESS_KEY_ID/SECRET — доступ к облаку → несанкционированный доступ к инфраструктуре

Как защитить CI/CD пайплайн: практическое руководство

1. Немедленно ротируйте все секреты

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

Последовательность действий:

1. Сгенерируйте новые токены для всех сервисов (GitHub, npm, Docker Hub, AWS и других).
2. Обновите секреты в настройках репозитория
3. Проверьте, что новые токены работают корректно (запустите тестовый workflow).
4. Отзовите старые токены.

2. Закрепляйте версии GitHub Actions через SHA-хеши

Вместо тегов используйте неизменяемые ссылки по SHA-хешу. Это один из наиболее эффективных методов защиты от атак на зависимости.

Для получения SHA-хеша конкретной версии перейдите на страницу релиза или используйте команду git ls-remote для получения хеша конкретного тега.

3. Реализуйте принцип минимальных привилегий для GITHUB_TOKEN

По умолчанию GITHUB_TOKEN имеет достаточно широкие права доступа. Ограничьте их до минимально необходимых для каждого конкретного workflow:

• Отключите запись, если workflow только читает данные
• Используйте блок permissions в каждом workflow для явного указания требуемых прав
• Не передавайте токен в шаги, которым он не нужен

4. Защитите pull_request_target

Этот тип триггера особенно опасен: workflow выполняется в контексте базовой ветки с доступом к секретам. Если вам необходим pull_request_target, применяйте следующие меры защиты:

Никогда не выполняйте код из PR в контексте с секретами — сначала проверяйте источник.

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

Рассмотрите альтернативные паттерны запуска workflow, например pull_request вместо pull_request_target.

Изолируйте привилегированные операции в отдельные workflow с ограниченным доступом.

5. Настройте мониторинг и оповещения

Настройте мониторинг на все критичные точки входа в ваш CI/CD процесс:

• Уведомления о необычных workflow-запусках — особенно в нерабочее время или из незнакомых источников.
• Алерты на подозрительные исходящие запросы из CI/CD (особенно на неизвестные домены и IP).
• Контроль публикаций пакетов — отслеживайте, кто, когда и откуда публикует пакеты в ваши реестры.

А ещё чистите зубы, мойте руки с мылом и надевайте шапку.

Технические детали для юных детективов: как сработали атаки на Trivy

Бот hackerbot-claw

Инцидент начался 27 февраля 2026 года, когда автономный бот hackerbot-claw создал Pull Request #10252 в репозитории Trivy. Бот эксплуатировал workflow с использованием pull_request_target, который позволял выполнить произвольный код в контексте с доступом к секретам репозитория.

Результат атаки — скомпрометированное VSCode-расширение Trivy. Версия 1.8.12, попавшая в Open VSIX Registry, содержала вредоносный код, который выполнял следующие действия:

1. Собирал конфиденциальные данные из среды разработки пользователя.
2. Эксфильтрировал украденные данные на командный сервер злоумышленников.
3. Создавал персистентный бэкдор для повторного доступа.

NVD зарегистрировала инцидент как CVE-2026-28353 с оценкой CVSS 10.0 — максимально возможной оценкой, указывающей на полную компрометацию информационной безопасности.

Ретроактивное отравление тегов

Группа TeamPCP получила write-доступ к репозиторию Trivy через скомпрометированные учётные данные, украденные в первом инциденте.

Ключевая инновация атаки — ретроактивное отравление тегов. Атакующие не просто опубликовали новую вредоносную версию — они переместили 76 из 77 существующих тегов так, чтобы те указывали на вредоносный код. Это означает, что под удар попадает любой пользователь, который:

• Использовал trivy-action@latest
• Использовал конкретную версию через тег
• Фиксировал зависимости через теги

CanisterWorm: блокчейн как командный сервер

Отдельного внимания заслуживает CanisterWorm — малварь, распространившаяся через скомпрометированные npm-токены.

Ключевые особенности CanisterWorm:

1. Использование блокчейна Internet Computer (ICP) как C2-сервера — децентрализованная инфраструктура, устойчивая к традиционным методам блокировки доменов и IP-адресов.
2. Автоматическое распространение — каждый заражённый пакет пытается заразить другие пакеты в экосистеме.
3. Кража токенов из среды разработчиков и CI/CD окружения для расширения сферы влияния.
4. Персистентный бэкдор для повторного несанкционированного доступа.

FAQ / TLDR

Как проверить, использовал ли я скомпрометированную версию Trivy?

Проверьте ваши workflow-файлы в .github/workflows/*.yml на наличие версий v0.69.4 для Trivy или любых версий для trivy-action от 19 марта 2026 года. Также проверьте логи CI/CD на подозрительную активность: исходящие запросы к неизвестным доменам, особенно к canister-контейнерам на ICP.

Что делать, если я обнаружил компрометацию?

Немедленно ротируйте все секреты, которые передавались в workflow, отдельное внимание уделите GITHUB_TOKEN и NPM_TOKEN. Проверьте npm-пакеты на заражение CanisterWorm с помощью Socket.dev или Snyk. Проведите аудит всех публикаций в реестры за период с февраля по март 2026 года.

Почему атака на сканер уязвимостей особенно опасна?

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

Как защититься от атак на зависимости в будущем?

Используйте SHA-хеши вместо тегов для закрепления версий зависимостей.

Применяйте принцип минимальных привилегий для всех токенов в CI/CD.

Настройте регулярную ротацию секретов.

Мониторьте исходящий трафик из CI/CD на предмет аномалий.

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

Материал подготовлен по открытым данным.

Основные источники: CrowdStrike, StepSecurity, Socket.dev, Ars Technica, Apache Foundation, Aikido Security, The Hacker News, NVD (CVE-2026-28353), GitHub Discussion #10265, Chainguard.

Шведский разработчик Торе Нестениус решил сорвать занавес. Он выпустил Coding Agent Explorer — открытый прокси-сервер, который в реальном времени показывает все общение между агентом и API Anthropic.

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

Что именно он показывает

Explorer перехватывает HTTP-запросы и визуализирует:

• системные промпты (часто намного длиннее, чем кажется);
• последовательность вызовов инструментов (Read, Grep, Write, Bash);
• шаги «размышления» агента;
• распределение задач между моделями (например, Haiku для рутинных операций и Sonnet/Opus для сложной логики);
• статистику токенов, включая кэш (cache_creation_tokens и cache_read_tokens).

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

В интерфейсе два режима. HTTP Inspector — сухая таблица со всеми JSON-телами, временем ответа и расходом токенов. Conversation View — более «человеческий» режим, где процесс выглядит как диалог: шаги планирования, проверки гипотез, исправления ошибок.

Зачем это нужно

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

Когда агент «зависает», теперь можно увидеть, что он на самом деле делает: перебирает файлы, пересобирает контекст или тратит половину лимита токенов на анализ README.

А уже это помогает оптимизировать промпты и понимать реальную стоимость задач. В итоге ИИ перестает быть черным ящиком.

Безопасность и ограничения

Explorer работает только локально (localhost). API-ключи автоматически маскируются в интерфейсе.

Данные не сохраняются — все хранится в памяти и ограничено примерно тысячей запросов. Никаких внешних сервисов и баз данных.

Об этом сообщил пользователь GitHub под ником Angry-Orangutan, опубликовав подробный баг-репорт в публичном репозитории Microsoft.

Проблема затрагивает новый режим agent / subagent в Copilot и связана не с безопасностью в классическом смысле, а с биллингом. Тем не менее, эффект от нее вполне материальный: дорогие модели вроде Claude Opus можно использовать бесплатно и сколько угодно долго.

Как работает обход биллинга

Механизм уязвимости строится на нескольких допущениях в архитектуре Copilot.

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

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

Дальше все просто: бесплатная модель делегирует работу подагенту, а тот выполняет задачи с помощью Opus или другого дорогого ИИ — без списания лимитов. По словам автора отчета, таким способом он запускал сотни подагентов и часами обрабатывал файлы, потратив всего несколько платных кредитов.

Реакция Microsoft

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

В итоге issue действительно появилась в открытом репозитории VS Code, но довольно быстро была закрыта со статусом «not planned». Это означает, что компания не обещает что-либо исправить и уж тем более не комментирует сроки.

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

Почему это важно

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

Линус Торвальдс закоммитил файл Project continuity — формальный план действий на случай, если он больше не сможет выполнять роль главного мейнтейнера проекта.

Переживать не стоит — пока что речи о скором уходе или передаче власти «наследнику» не идет. Документ скорее фиксирует то, как сообщество должно действовать в кризисной ситуации — внезапной и без предварительной подготовки.

Ранее подобные вопросы в Linux решались негласно и на уровне доверия, но теперь процесс впервые описан письменно.

Почему это вообще понадобилось

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

Исторически эту роль выполняет сам Торвальдс. Именно он принимает изменения в mainline и определяет, что считается «официальным» Linux.

В коммите напрямую упоминается релиз 4.19 в 2018 году — момент, когда Торвальдс временно отошел от проекта.

Тогда стало очевидно, что даже при развитой системе мейнтейнеров отсутствие одного человека создает управленческую неопределенность. Новый документ — попытка эту неопределенность устранить.

Как выглядит план преемственности

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

Организатор последнего Linux Maintainers Summit обязан в течение 72 часов собрать обсуждение с участниками саммита и Technical Advisory Board (TAB) Linux Foundation.

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

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

Если саммит давно не проводился, состав участников определяет TAB. Через две недели после встречи, сообщество получает публичное разъяснение дальнейших шагов через официальную рассылку kernel.org.

Стартапы начали скупать Mac mini и использовать их не как персональные компьютеры, а как круглосуточных цифровых сотрудников. На этих машинах крутится Clawdbot — ИИ-ассистент, который берет на себя рутину и работает без выходных.

Mac mini как «железный сотрудник»

Компактный компьютер от Apple неожиданно оказался идеальным форматом для ИИ-работника.

Он тихий, энергоэффективный и может быть включен 24/7. В результате Mac mini стали использовать как отдельные рабочие узлы: один — для коммуникаций, другой — для автоматизации задач, третий — для интеграций с сервисами.

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

Во главе угла — Clawdbot

В сети Clawdbot частенько сравнивают с ассистентом Тони Старка — Джарвисом. Причин тому несколько. Так, это не просто чат с нейросетью, а полноценный помощник, который умеет работать с приложениями, файлами и сервисами так, как это делал бы человек.

Он пишет и отвечает на сообщения в мессенджерах, управляет файлами на компьютере, автоматизирует повторяющиеся действия и взаимодействует с популярными сервисами вроде Gmail, Notion или GitHub.

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

Ключевой момент — Clawdbot живет локально, на отдельной машине. Да, это не облачный ассистент, принадлежащий какой-то крупной компании.

Почему стартапы выбирают именно такой формат

Использование Mac mini вместо облачных серверов или виртуальных рабочих столов оказалось неожиданно практичным. Машины легко масштабировать, они не требуют сложной инфраструктуры и обходятся дешевле в долгосрочной перспективе. Один раз купил, настроил и получил «сотрудника», который всегда на месте.

Далее его использовали для распространения вредоносных PowerShell-скриптов. В результате на компьютеры с Windows устанавливался троян Cosmali Loader.

Инцидент стал заметен после того, как пользователи MAS начали массово жаловаться на Reddit — на их компьютерах появлялись всплывающие уведомления о заражении.

Одна буква и система скомпрометирована

Атакующие зарегистрировали домен get.activate[.]win, который визуально почти не отличается от легитимного get.activated.win. Разница — всего в одной букве «d».

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

После выполнения команды, в системе загружался Cosmali Loader — открытый вредоносный загрузчик, который затем устанавливал дополнительные компоненты.

По данным исследователей, среди полезной нагрузки были криптомайнеры и XWorm RAT — троян удаленного доступа, позволяющий полностью контролировать зараженный компьютер.

Странные предупреждения и «доброжелательный взлом»

Интересная деталь инцидента — сами предупреждения о заражении. Они выглядели как пугающие pop-up сообщения с советом переустановить Windows и проверить диспетчер задач на подозрительные PowerShell-процессы.

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

Что такое MAS и почему это риск

Microsoft Activation Scripts — это open-source набор PowerShell-скриптов, размещенный на GitHub. Он используется для активации Windows и Office с помощью HWID, эмуляции KMS и других обходных методов.

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

Но если в UNIX это скорее философия с оговорками, то в PatchworkOS идея доведена почти до абсолюта. Здесь файлами считаются не только данные, но и процессы, события, таймеры и даже взаимодействие с ядром.

Проект носит исследовательский характер и не претендует на роль универсальной ОС для повседневного использования.

Как работает «все — файл» в PatchworkOS

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

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

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

Сам автор проекта описывает PatchworkOS как систему, где файловая и процессная модели слиты воедино, а граница между «данными» и «поведением» намеренно размыта.

Минимум абстракций и максимум прозрачности

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

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

Норберг отдельно отмечает, что его операционка — это не Linux-дистрибутив и не попытка конкурировать с существующими ОС.

Ограничения и честные предупреждения

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

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