Ваш кодинг-агент уже выбрал ваш стек. Вы просто еще не заметили.

Исследователи из Amplifying прогнали около 2,5 тыс. открытых запросов к Claude Code типа "добавь базу данных", "как задеплоить", "добавь аутентификацию" ни разу не назвав конкретный инструмент. Записали, что агент выбрал и сделал. Получилась карта того, как AI-агенты формируют стек за разработчиков.

Что нашли

- Монополии. GitHub Actions владеет CI/CD (94%), Stripe - платежами (91%), shadcn/ui - UI (90%), Vercel -деплоем JS (100%). Redux получил 0 рекомендаций (Zustand забрал все). Vitest вместо Jest. pnpm вместо yarn. Resend вместо SendGrid и тд
- Конкурентные категории. Auth, кеширование, ORM, background jobs, real-time - здесь нет явного победителя, а выбор полностью зависит от стека. NextAuth.js для Next.js (91%), но для Python - кастом (100%). Redis для Python-кеша (57%), но Next.js использует встроенный кеш (42%) и тд
- Контекст > формулировка. Один и тот же вопрос дает разные инструменты для разных репо (Drizzle для JS, SQLModel для Python), но стабилен при перефразировании (76% stability)
- Велосипеды - главная находка. В 12 из 20 категорий агент строит с нуля вместо рекомендации инструмента. Кастом предлагался чаще чем у любого отдельного инструмента. Например просишь auth для Python - пишет JWT реализацию с нуля.

А что изменилось-то

Проблема "на какую технологию ставить" была всегда, но сейчас размывается момент осознанного выбора. Гитхаб в своей статье назвал это "convenience loop".
И как вы поняли, проблема "Catch-22" намного шире технического стека, про это, например, пишет Nature.

И, вдобавок, есть проблема конфликта интересов, например авторы рисерча The Invisible Hand показали например как Gemini молча заменял open-source на платный Google Speech Recognition. Когда компания владеет и моделью, и облаком - модель может стать продавцом, притворяющимся советником.

И да, можно (и нужно) определить стек через документацию. Но знание из training data - это как гравитация. Исследования показывают: когда контекст противоречит тому, что модель "знает" из обучения, она часто игнорирует контекст и возвращается к дефолту.

Что с этим делать

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

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

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

- Спросите себя "если сломается - кто поможет починить?" Популярная библиотека - community. SaaS - вендор. Кастомная реализация агента - вы.

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

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

🔥 ➕ 🔁 @nobilix

В ingress-nginx обнаружена (очередная) критическая уязвимость CVE-2026-3288, связанная с обработкой аннотаций Ingress ресурсов. Некоторые значения аннотаций подставляются в шаблон конфигурации NGINX без достаточной фильтрации, что позволяет атакующему внедрить произвольные директивы в итоговый nginx.conf. Уязвимость затрагивает версии ingress-nginx до 1.13.7 / 1.14.3.

Атака возможна, например, через аннотацию nginx.ingress.kubernetes.io/rewrite-target. Специально сформированное значение может привести к конфигурационной инъекции: при генерации конфигурации контроллер вставляет его в NGINX шаблон, после чего в nginx.conf появляются дополнительные директивы (например include, lua и другие). Это позволяет выполнить код в контексте ingress-nginx controller.

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

Интересно это следствие того, что это по сути анализ ряда зарубежных источников или автор англоязычный? Заголовок "ТЕХНОЛОГИЧЕСКИЕ ТРЕНДЫ: ЭФФЕКТЫ ОТ АДАПТАЦИИ" на русском языке читается как эффект от того, что технология была изменена.
Странно, что ни исследования международные, ни эксперты опрошенные АФТ не верят, что проактивная Кибербезопасность может повлиять в принципе на улучшение клиентского опыта.
0 примеров из России для этого тренда тоже не в пользу исследования =(

https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/rekomendatsii-po-zashchite-setevogo-perimetra-informatsionnykh-avtomatizirovannykh-sistem
Вышли рекомендации ФСТЭК по ужесточению настроек сетевых политик на периметре.

Мне кажется рекомендации бы стали сильнее если бы их структурировали по сложности\приоритетности. С одинаковым приоритетом написать и про учения и сложность пароля, мне кажется, не самый мудрый поступок.

В целом рекомендации полезны, но где то явно можно было чуть подробнее написать, а не просто "Настроить доступ к сети по модели нулевого доверия (ZTNA)."

ФСТЭК разработала рекомендации по защите сетевого периметра информационных (автоматизированных) систем, разработанные по результатам анализа успешных фактов реализации угроз безопасности информации, связанных с удалённой эксплуатацией уязвимостей, а также осуществлением несанкционированного доступа к внутренней инфраструктуре из внешней сети.

Подписаться в MAX

https://cloud.google.com/blog/topics/threat-intelligence/preparation-hardening-destructive-attacks/

Отличный гайд от Гугл (Мандиант) как повысить свою устойчивость к деструктивным атакам.
Подходит и для борьбы с APT.
Когда читаешь, почти ощущаешь, что каждая рекомендация была выстрадана в ходе инцидента.

Например:
"Proactively identify domain controllers that hold flexible single master operation (FSMO) roles, as these domain controllers will need to be prioritized for recovery in the event that a full domain restoration is required. "

Даже кратко обозначили риски каждого способа MFA.

https://businessinsights.bitdefender.com/apt36-nightmare-vibeware

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

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

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

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

Медианная статистика когда CISO и Архитектор в среднем получают меньше пентестера требует вдумчивого анализа методики, почему так.

Самый вероятный ответ - небольшая выборка: у пентестеров 5 вакансий, у CISO - 53.

А вы отслеживаете переходы владения для согласованных расширений, продуктов, оборудования?

У кого то работает, если требование по уведомлению смены собственника включить в договор поставки?

https://monxresearch-sec.github.io/shotbird-extension-malware-report/

Новый инцидент, связанный с утечкой данных из AI-ассистента консалтинговой компании McKinsey. Исследователи из CodeWall во время red teaming-упражнений протестировали чат-бота для сотрудников и консультантов компании, который имел доступ к данным клиентов и другим конфиденциальным перепискам.

Агент-хакер CodeWall обнаружил незащищенные API-эндпоинты приложения и подобрал SQL-инъекцию, которая дала доступ к продакшен базе данных. Случай для безопасности веб-приложений довольно обычный, но есть и интересные особенности.

Далее исследователи обнаружили, что система хранит системные инструкции в той же самой базе данных. Поменяв промпты в БД, они тем самым убрали guardrails и смогли вытащить дополнительные данные из RAG-системы. Не стоит хранить системные инструкции в той же базе данных, которая подключена к вашим открытым API :)

Тестирование прошло в конце февраля, 1 марта команда McKinsey получила уведомление, и уже на следующий день уязвимости были закрыты. С момента атаки до публичного релиза статьи прошло меньше недели, что, конечно, поразительно. Молодцы и в McKinsey, и в CodeWall.

Pillar Security сообщает о двух критических уязвимостях в n8n, которые могуь быть использованы для RCE и выхода из песочницы, что потенциально приведет к раскрытию всех учетных данных, хранящихся в базе данных n8n.

Первая ошибка, CVE-2026-27493 (CVSS 9,5), описывается как проблема внедрения выражений второго порядка, затрагивающая узлы Form платформы автоматизации рабочих процессов с открытым исходным кодом.

Успешная эксплуатация уязвимости позволяет неавторизованному злоумышленнику внедрить произвольные команды в поле Name и получить результат выполнения команды.

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

По данным Pillar Security, эта уязвимость может быть связана со второй критической проблемой, которая отслеживается как CVE-2026-27577 (CVSS 9,4) и позволяет выйти за пределы песочницы n8n для выполнения команд на хосте.

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

Обе уязвимости были устранены в конце февраля в n8n 2.10.1, 2.9.3 и 1.123.22.

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

Обе проблемы затрагивали как локальные, так и облачные развертывания и могли быть использованы для извлечения всех учетных данных из баз данных n8n, включая ключи AWS, пароли, токены OAuth и ключи API.

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

Поскольку конечные точки форм предназначены для доступа из интернета, CVE-2026-27493 может быть использована любым пользователем, отправившим всего одну форму и выполнившим GET-запрос.

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

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