Перспективы российского рынка ERP плюс про ответственность в гибридном предприятии

Перспективы российского облачного рынка: гибридные архитектуры и конкуренция за качество

Ключевые мысли статьи (https://kodeks.ru/news/read/perspektivy-rossiiskogo-oblacnogo-rynka-gibridnye-arxitektury-i-konkurenciia-za-kacestvo) относительно ERP:

1. ERP — в авангарде критически важных облачных нагрузок

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

«…предприятия активно переводят в облако критически важные системы — ERP, аналитические платформы, цифровые производственные сервисы. Такой подход требует от инфраструктуры высокой отказоустойчивости, зрелых механизмов информационной безопасности и управления».

2. Гибридная архитектура — безальтернативная модель для ERP

Ключевой вывод статьи о гибридных облаках имеет прямое отношение к ERP. Крупные компании не уходят в чистое публичное облако, а строят гибридные ландшафты, чтобы совместить требования безопасности, экономики и законодательства. Для ERP это означает, что наиболее критичные модули могут оставаться on-premise, а связанные с ними аналитические сервисы, песочницы или фронт-офисные блоки — выноситься в облако.

«Большинство крупных компаний не пойдут в чистый public cloud. Они строят и будут строить гибридные архитектуры — не из стратегических соображений, а из необходимости одновременно учитывать безопасность, экономику, производительность и соответствие законодательству».

3. Переход от «облака как хостинга» к готовым бизнес-сценариям

Для ERP-систем это означает, что заказчику всё чаще нужен не просто виртуальный сервер для 1С или SAP, а комплексное решение: среда для разработки доработок, резервная площадка для аварийного восстановления, аттестованный контур безопасности и т.д. Конкуренция за ERP-клиентов будет идти на уровне этих готовых сценариев, а не цены за vCPU.

«Выигрышную позицию займут поставщики, предлагающие готовый бизнес-сценарий: не просто виртуальные машины, а среду разработки, резервную площадку, защищённый контур, платформу для работы с данными…»

4. Приоритеты заказчика: контроль и возможность доработки (особенно важно для ERP)

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

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

5. Инфраструктурный фундамент для ERP-революции

Статья напоминает, что развитие облачных ERP и загрузка их ИИ-инструментами упирается в физическую ёмкость ЦОДов. Перенос тяжелых ERP-систем требует значительных вычислительных ресурсов и энергомощностей, рост спроса на которые пока опережает предложение. Это сдерживающий фактор, который напрямую затрагивает темпы миграции ERP в облако.

«Спрос на облака и ИИ растёт намного быстрее, чем ёмкость ЦОДов. … Именно в инфраструктуру упирается развитие облачного рынка в России».

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

https://kodeks.ru/news/read/perspektivy-rossiiskogo-oblacnogo-rynka-gibridnye-arxitektury-i-konkurenciia-za-kacestvo

* * *

Кому принадлежит результат? Ответственность в гибридном предприятии

https://www.techtarget.com/searcherp/feature/Who-owns-the-outcome-Accountability-in-the-hybrid-enterprise

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

1. ERP создаёт «галочную ответственность» (checkbox ownership)

ERP-системы отлично справляются с отслеживанием формальных состояний задач (начато, в работе, завершено). Но они жестко следуют предопределённым «счастливым путям» (happy paths). В реальности 70-80% процессов имеют отклонения, которые ERP не учитывает. В итоге сотрудник формально «поставил галочку» в ERP, но реальная логика решения осталась за бортом системы, не управляема и не видна.

2. ERP не фиксирует «соединительную ткань» работы

Главная проблема с точки зрения ERP: она является системой учёта (system of record), но фиксирует только то, что в неё явно внесли. Реальная работа, распределение ответственности и ключевые решения часто происходят вне ERP:

* Обсуждения в Slack / Teams
* Правки в Excel-файлах
* Электронные письма с уточнениями
* Заметки в блокнотах

В результате, когда происходит сбой, ERP покажет, кто закрыл наряд-заказ, но не покажет, кто принял ошибочное решение в чате. Человек становится «API» между несвязанными системами.

3. Связность ≠ подотчётность (Connectivity is not accountability)

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

4. Парадокс видимости в ERP

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

5. Слабое место ERP — точки передачи (handoff points)

Статья прямо указывает: когда инцидент в системе CRM (например, жалоба клиента) требует действия в SAP (отгрузка, пересчёт), а владельца процесса чётко не назначено, ответственность исчезает. ERP не умеет управлять такими межсистемными стыками. В офисе эти стыки сглаживались «быстрым разговором у кулера»; в гибридной среде с ERP этого нет.

6. ERP подменяет собой менеджмент, но не заменяет владельца решения

ERP всё чаще берёт на себя функции, которые раньше выполняли менеджеры: принуждение к workflow, назначение задач (автоматически), создание аудиторского следа. Это полезно, но риск в том, что ERP начинает диктовать структуру ответственности, и люди следуют системе, а не логике бизнеса. В результате появляется «владелец задачи в ERP», но нет владельца решения (decision owner) — человека с реальными полномочиями сказать «да» или «нет».

Главный вывод для ERP-специалистов:

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

Линус Торвальдс о использовании ИИ - перепечатка заметки

Перепечатка заметки

Линус Торвальдс высказался об использовании ИИ: «Форкайте ядро или уходите»

Мария Нефёдова 

 

5 дней назад

 

 1 комментарий

 

55860

 

https://xakep.ru/2026/07/17/torvalds-about-ai/

Создатель Linux Линус Торвальдс (Linus Torvalds) заявил, что разработчикам, которые выступают категорически против использования ИИ, придется смириться, уйти или создать собственный форк ядра. По его словам, Linux не станет очередным «анти-ИИ-проектом», а решения будут приниматься исходя из технических критериев, а не из страха перед новыми инструментами.

Поводом для заявления послужила дискуссия в списке рассылки для разработчиков ядра. Участники обсуждали Sashiko — агентную ИИ-систему для ревью кода Linux. Создатели Sashiko протестировали систему на старых версиях ядра, и она нашла 53,6% багов, которые разработчики позднее исправили. Однако Sashiko может генерировать и ложные отчеты об уязвимостях, доля которых составляет около 20%.

Противники подобных инструментов опасаются, что автоматизированные отчеты создадут огромную нагрузку на мейнтейнеров и могут спровоцировать их выгорание. В обсуждении даже процитировали недавнее заявление организации Software Freedom Conservancy, в котором опенсорсное сообщество призывали поддерживать разработчиков, полностью отвергающих генеративный ИИ.

Однако Торвальдс занял жесткую позицию. Создатель Linux написал:

«Это как раз тот случай, когда я готов совершенно однозначно настаивать на своем как главный мейнтейнер. Linux не относится к анти-ИИ-проектам. Если у кого-то с этим проблемы, он может поступить в духе open source и сделать форк. Или просто уйти».

Торвальдс подчеркнул, что никого не заставляют применять LLM, однако запрещать другим использовать такие инструменты тоже не получится:

«Мы не принуждаем никого использовать [LLM-инструменты]. Но я буду решительно игнорировать людей, которые пытаются запретить их использование остальным».

По мнению Торвальдса, ИИ следует воспринимать как обычный рабочий инструмент:

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

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

«Решение заключается не в том, чтобы засунуть голову в песок и во весь голос петь: "Ла-ла-ла, я ничего не слышу", как, похоже, делают некоторые. Нужно добиться того, чтобы LLM-инструменты помогали мейнтейнерам, а не вредили им».

Нынешняя позиция заметно отличается от слов Торвальдса, сказанных в октябре 2024 года. Тогда он называл 90% происходящего вокруг ИИ маркетинговым хайпом и заявлял, что намерен попросту игнорировать эту тему. Однако в январе 2026 года он уже экспериментировал с вайбкодингом и рассказывал, что написал на Python инс­тру­мен­т для генера­ции циф­ровых аудиооэф­фектов с помощью Google Antigravity.

Теперь Торвальдс подчеркивает, что не считает нынешние ИИ-системы идеальными, но напоминает, что люди тоже далеки от совершенства:

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

По словам Торвальдса, Linux остается в первую очередь технологическим проектом. Социальная сторона open source важна, но это побочный эффект, а не главная цель.

«В сообществе разработчиков ядра мы занимаемся open source, потому что это позволяет создавать лучшие технологии, а не по религиозным убеждениям. Поэтому мы принимаем решения прежде всего исходя из технических критериев, а не из страха перед новыми инструментами». 

Пример галлюцинаций ИИ для создания ботнетов - перепечатка статьи

Перепечатка статьи

Атака HalluSquatting использует галлюцинации ИИ для создания ботнетов

Мария Нефёдова 

 

неделю назад

 

 Комментарии

 

3148

 

https://xakep.ru/2026/07/15/hallusquatting/

Специалисты из Тель-Авивского университета, Израильского технологического института и компании Intuit продемонстрировали атаку HalluSquatting. Она строится на склонности ИИ-ассистентов «выдумывать» адреса репозиториев и других ресурсов. Эксперты показали, что атакующий может заранее зарегистрировать такой несуществующий адрес, дождаться подключения ИИ-агента и добиться выполнения вредоносного кода на машине пользователя.

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

Название HalluSquatting расшифровывается как adversarial hallucination squatting — сквоттинг, основанный на состязательных галлюцинациях. В целом атака напоминает тайпосквоттинг, но здесь атакующему нужно предугадать не человеческую опечатку, а адреса, которые LLM чаще всего «придумывают» в ходе обработки запросов на клонирование репозитория или установку навыка.

Затем злоумышленник регистрирует «выдуманное» имя на GitHub или в каталоге навыков и размещает там копию популярного проекта. В README или конфигурации атакующий может спрятать промпт-инжект с командой, вынуждающей ИИ установить бэкдор или ревер-шелл. В результате, когда ИИ-ассистент галлюцинирует и «придумывает» этот адрес, он попадает в ловушку, в итоге выполняя инструкции злоумышленника.

Исследователи протестировали атаку на Cursor, Cursor CLI, Gemini CLI, Windsurf, GitHub Copilot, Cline, OpenClaw, ZeroClaw и NanoClaw. Во всех случаях им удалось добиться выполнения кода (в экспериментах использовались безопасные тестовые пейлоады).

По данным специалистов, проблема затрагивает базовые модели Gemini 2.5 Flash, Gemini 2.5 Pro, GPT-5.1, GPT-5.2, Sonnet 4.5 и Opus 4.5. Их галлюцинации оказались предсказуемыми и часто повторялись. К примеру, обнаружилось, что LLM склонны генерировать адреса вида repo-name/repo-name, принимая название проекта за имя владельца аккаунта.

Исследователи отмечают, что чаще всего подобные ошибки возникают с новыми и трендовыми проектами, которые отсутствовали в обучающих данных LLM. Так, для проектов, опубликованных до 2019 года, средний показатель галлюцинирования составлял лишь 0,9%, тогда как для репозиториев, созданных в 2025 году — уже 92,4%. В итоге при клонировании репозиториев пиковая доля галлюцинаций достигала 85%, а при установке навыков — 100%.

Авторы HalluSquatting предупреждают, что атака может стать механизмом для доставки малвари на множество независимых систем. Зараженные машины в итоге можно объединить в ботнет для DDoS-атак или майнинга криптовалюты, а также использовать в массовых вымогательских кампаниях. В отличие от традиционных ботнетов, в этом случае хакерам не потребуется использовать уязвимости, слабые пароли и так далее. Малварь будет устанавливать сам ИИ-агент, имеющий доступ к командной строке.

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

Отметим, что недавно о похожей технике атак под названием phantom squatting писали специалисты компании Palo Alto Networks. Суть этой проблемы заключается в том, что злоумышленники могут регистрировать несуществующие домены, которые «придумывают» LLM, а затем размещать на них фишинговые страницы и малварь.

В свою очередь, атака phantom squatting похожа на описанные еще в 2025 году атаки типа slopsquatting, в ходе которых хакеры создают вредоносные пакеты в PyPI или npm, используя названия, которые «выдумывают» ИИ-модели. Причем эта схема уже применялась злоумышленниками на практике в кампании PhantomRaven, когда малварь разместили в 126 пакетах npm, которые в итоге установили более 86 000 раз.

* * *

Злоумышленники регистрируют домены, «придуманные» ИИ

Мария Нефёдова 

 

2 недели назад

 

 Комментарии

 

11664

 

https://xakep.ru/2026/07/06/phantom-squatting/

Эксперты компании Palo Alto Networks обнаружили новую технику атак, которой дали название phantom squatting. Злоумышленники регистрируют несуществующие домены, которые «придумывают» LLM, а затем размещают на них фишинговые страницы и малварь. В результате пользователь попадает на опасный сайт не через фишинговое письмо или вредоносную рекламу, а через ИИ-инструмент, которому доверяет.

Чтобы оценить масштаб проблемы, исследователи задали двум неназванным ИИ-моделям 685 339 вопросов о 913 известных брендах из технологического, финансового, медицинского, государственного и других секторов. В ответ модели предоставили специалистам 2,1 млн ссылок, причем системы анализа киберугроз уже считали 13 229 их этих адресов вредоносными. То есть ИИ напрямую рекомендовал пользователям заведомо опасные ресурсы. Еще около 250 000 доменов, порожденных галлюцинациями ИИ, были свободны, и зарегистрировать их мог любой желающий.

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

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

В одном случае система Palo Alto Networks предсказала, что модели «придумают» домен, похожий на адрес онлайн-маркетплейса национальной почтовой службы. Обе изученные модели действительно стабильно генерировали этот адрес при любых настройках температуры. Через 23 дня злоумышленник зарегистрировали этот домен и развернули там фишинг-кит Montana Empire.

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

В другом случае исследователи заметили «выдуманный» домен почтовой службы за 51 день до его регистрации. Позже на этом домене появился точный клон официального сайта с фальшивой оценкой 4,8 звезды и заявлением о более чем двух миллионах пользователей. Ресурс распространял вредоносное приложение для Android.

Прочие вредоносные домены имитировали банки в ОАЭ и странах Европы, а также сайты для спортивных ставок, которые были ориентированы на пользователей из Бангладеш.

Phantom squatting очень похож на описанные в 2025 году атаки типа slopsquatting, при которых преступники создают вредоносные пакеты в PyPI или npm, используя названия, которые «выдумывают» ИИ-модели. Именно эта схема применялась злоумышленниками в кампании PhantomRaven, когда малварь скрыли в 126 пакетах npm, которые в итоге установили более 86 000 раз.

* * *

Новые атаки типа слопсквоттинг строятся на «галлюцинациях» ИИ

Мария Нефёдова 

 

14.04.2025

 

 1 комментарий

 

8619

 

https://xakep.ru/2025/04/14/slopsquatting/

Эксперты предупреждают о новом типе атак на цепочку поставок, получившем название слопсквоттинг (slopsquatting). Такие атаки становятся возможны благодаря широкому применению генеративных ИИ-инструментов для кодинга, так как модели склонны к «галлюцинациям» и могут придумывать несуществующие пакеты.

Впервые термин слопсквоттинг был предложен ИБ-исследователем Сетом Ларсоном (Seth Larson) и родственен слову «тайпсквоттинг». В отличие от тайпсквоттинга, слопсквоттинг связан не с эксплуатацией опечаток, а с тем фактом, что злоумышленники могут создавать вредоносные пакеты в PyPI или npm, используя названия, которые часто «выдумывают» ИИ-модели.

Опубликованное в конце марта исследование, посвященное изучению «галлюцинаций» ИИ, показало, что примерно в 20% случаев (576 000 сгенерированных примеров кода на Python и JavaScript) рекомендуемые искусственным интеллектом пакеты не существовали.

Причем ситуация выглядит хуже для опенсорсных LLM (CodeLlama, DeepSeek, WizardCoder и Mistral), а коммерческие инструменты, такие как ChatGPT-4, галлюцинируют примерно в 5% случаев, что тоже совсем немало.

Исследователи отметили, что количество уникальных имен таких несуществующих пакетов превысило 200 000, причем 43% из них постоянно появлялись в ответах LLM при похожих промптах, а 58% повторялись хотя бы один раз из десяти.

Отмечается, что 38% названий несуществующих пакетов явно были вдохновлены настоящими пакетами, 13% были результатом опечаток, а остальные 51% являлись полностью вымышленными.

Схема атаки с использованием слопсквоттинга

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

«В целом 58% “галлюцинаций” повторялись более одного раза. Это свидетельствует о том, что большинство “галлюцинаций” — не просто случайный шум, а повторяющиеся артефакты того, как модели реагируют на определенные промпты, — объясняют исследователи Socket. — Такая повторяемость повышает их ценность для злоумышленников, облегчая выявление жизнеспособных целей для слопсквоттинга, просто наблюдая за результатами работы моделей даже на небольших выборках».

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

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

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

* * *

Кампания PhantomRaven: в npm загрузили более 100 пакетов с инфостилерами

Мария Нефёдова 

 

30.10.2025

 

 Комментарии

 

1919

 

https://xakep.ru/2025/10/30/phantomraven/

С августа 2024 года, в рамках кампании PhantomRaven в npm загрузили 126 вредоносных пакетов, которые суммарно скачали более 86 000 раз. Кампанию обнаружили специалисты Koi Security, которые пишут, что атаки осуществлялись благодаря малоизвестной особенности npm, которая позволяет обходить защиту и детектирование.

Подчеркивается, что на момент публикации отчета около 80 вредоносных пакетов все еще были активны.

Специалисты объясняют, что злоумышленники используют механизм удаленных динамических зависимостей (Remote Dynamic Dependencies, RDD). Обычно разработчик видит все зависимости устанавливаемого пакета — они загружаются из доверенной инфраструктуры npm. Однако RDD позволяет пакетам автоматически подтягивать код с внешних URL, причем даже по незашифрованному HTTP-каналу. При этом в манифесте пакета отображается ноль зависимостей.

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

«PhantomRaven показывает, насколько изощренными могут быть атакующие при эксплуатации слепых зон в традиционных средствах защиты. Удаленные динамические зависимости просто невидимы для статического анализа», — говорят исследователи.

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

После заражения малварь тщательно собирает информацию о системе жертвы:

• переменные окружения с конфигурациями внутренних систем разработчика;
• токены и учетные данные для npm, GitHub Actions, GitLab, Jenkins и CircleCI;
• всю среду CI/CD, через которую проходят изменения кода от разных разработчиков.

Украденные токены могут использоваться для атак на цепочки поставок и внедрения вредоносного кода в легитимные проекты. Кража данных организована с избыточностью, сразу тремя методами: HTTP GET с данными в URL, HTTP POST с JSON и через WebSocket-соединения.

Специалисты пишут, что многие вредоносные пакеты маскируются под инструменты GitLab и Apache.

Отдельную роль в этой кампании играет слопсквоттинг (slopsquatting), то есть эксплуатация галлюцинаций ИИ. Дело в том, что разработчики часто спрашивают у LLM-ассистентов, какие пакеты лучше использовать для того или иного проекта. ИИ-модели нередко выдумывают несуществующие, но правдоподобно выглядящие названия. Операторы PhantomRaven отслеживают такие галлюцинации и регистрируют пакеты с этими именами. В итоге жертвы сами устанавливают малварь, следуя рекомендациям LLM.

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

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

Угроза ИИ для вендоров ERP систем

Почему акции SAP упали более чем на 3%, хотя сама SAP не публиковала никаких плохих новостей? Причина кроется в «эффекте заразы» после финансового отчета главного конкурента — компании Oracle.

Главный триггер: Шок от капитальных затрат (Capex) Oracle

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

• Капитальные затраты (Capex) Oracle в 2026 финансовом году подскочили на 162% до $55,7 млрд.

• На 2027 финансовый год Oracle планирует потратить на ИИ-инфраструктуру до $95 млрд, что почти в полтора раза выше прогнозов аналитиков ($67,7 млрд).

• Из-за этих колоссальных вливаний в дата-центры Oracle зафиксировала отрицательный свободный денежный поток (Free Cash Flow) в размере -$23,7 млрд и предупредила о неизбежном снижении валовой маржи в ближайшем году.

Парадокс: Спрос на ИИ огромен, но пугает цена входа

Важно понимать, что у Oracle нет проблем со спросом. Их облачная выручка выросла на 47% до рекордных $9,9 млрд, а выручка от Oracle Cloud Infrastructure (OCI) подскочила на 93%. Бэклог контрактов (RPO) достиг $638 млрд. Однако инвесторов пугает именно цена этого роста. Рынок начал переоценивать устойчивость денежных потоков всего сектора корпоративного софта, опасаясь, что бесконечная «гонка вооружений» за ИИ съест всю прибыль.

Эффект домино для SAP: Почему падают «чужие» акции?

Почему акции SAP упали, если SAP не объявляла о таких тратах?

• Конкурентное давление: Oracle и SAP пересекаются в сегментах ERP, облачных сервисов, баз данных и бизнес-приложений. Инвесторы рассуждают так: если Oracle тратит $95 млрд на ИИ-инфраструктуру, то SAP и другим вендорам придется тратить несоразмерно много, просто чтобы удержать долю рынка и не отстать в технологической гонке.

• Сжатие маржи: Рынок закладывает в котировки SAP риск того, что ей тоже придется резко увеличить Capex, что неизбежно ударит по ее традиционно высокой рентабельности. SAP стала «чистым и ликвидным прокси» для шорта всего сектора корпоративного софта.

Две экзистенциальные угрозы для традиционного Enterprise-софта

Аналитики выделяют два главных страха, которые сейчас давят на акции SAP и ей подобных:

• Финансовая ловушка ИИ: Спрос на ИИ-мощности реален, но стоимость инфраструктуры растет быстрее, чем доходы от нее. Если Oracle преуспеет, конкурентам придется тратить больше. Если не преуспеет — инвесторы перестанут верить в окупаемость ИИ для всего софтверного сектора.

• Угроза бизнес-модели: ИИ-инструменты становятся настолько мощными, что начинают автоматизировать задачи, для управления которыми традиционные ERP-системы (включая SAP) и были созданы. Это заставляет рынок нервничать по поводу долгосрочной экономики традиционного корпоративного софта.

Падение SAP — это не реакция на внутренние проблемы компании, а стресс-тест всего рынка Enterprise-софта. Инвесторы осознали, что эпоха «легких денег» в облаках закончилась. Теперь, чтобы конкурировать в эпоху ИИ, вендорам придется тратить миллиарды на инфраструктуру.

Для клиентов и партнеров SAP это означает две важные вещи:

Давление на ценообразование: Чтобы окупить эти затраты и не разрушить свою маржинальность, SAP будет вынуждена очень агрессивно и тщательно монетизировать свои ИИ-инновации (о чем мы говорили в предыдущей статье про отказ от токенов в пользу «AI Units»).

Новые KPI для вендоров: Рынок теперь будет беспощадно оценивать любые ERP-компании не только по росту облачной выручки, но и по их способности генерировать свободный денежный поток на фоне гигантских ИИ-инвестиций. Любая ERP-система, которая не сможет доказать прямую финансовую отдачу от ИИ (как в случае с Joule), столкнется с оттоком клиентов и падением акций.

Из Телеграмм-канала "SAPLAND: Новости экосистемы"