Самоэволюционирующееся ПО и новые вызовы в оценке соответствия требованиям ИБ

Не знаю, есть ли у вас время следить за трендами, а я тут, совершенно случайно, столкнулся с двумя историями, которые показывают насколько быстро сейчас меняется все, включая и архитектуру ПО, что, несомненно, повлияет и на кибербезопасность. Мы еще не до конца осознаем объем этих перемен, но это, как по мне, прямо сейсмический сдвиг. Первое событие связано с анонсом новой версии Omarchy, проекта, который сейчас позиционирует себя как agentic OS. То есть агент получает инструменты и скиллы, позволяющие разбираться с системой, диагностировать сбои, создавать приложения, плагины, темы и фактически на лету перестраивать операционную систему.

То есть, если раньше (у многих и сейчас) схема работы была следующей: пользователь → настройки → ОС, то Omarchy продвигает иную концепцию: пользователь → намерение → агент → изменение ОС.

Вторым событием стал анонс новой IDE — bb, авторы которой прямо говорят, что это «IDE, которая строит сама себя». Большая часть возможностей bb сделана через тот же механизм плагинов, который доступен пользователю: можно попросить «добавь мне task manager», и агент создаст UI, CLI и skill для других агентов. Авторы отдельно подчеркивают, что: «Нет двух идентичных инсталляций, которые были бы похожи друг на друга”.

Чувствуете, куда я клоню?

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

Очень показательно, что такие идеи одновременно возникают в совершенно разных местах. Google сейчас продвигает Generative UI: интерфейс не является заранее нарисованным набором экранов – LLM может на лету генерировать компоненты, дашборды или фактически маленькое приложение под текущую задачу. Google Research идет еще дальше и рисует более интересную картину самоэволюционирующегося ПО. Авторы выделяют три механизма:

• Directed synthesis – «сделай мне вот такую функцию».
• Inferred synthesis – система сама понимает, что функции не хватает, и создает ее (шок-контент).
• Real-time adaptation – система перестраивается непосредственно во время работы (шок-контент дважды).

Есть уже и ОС, строящиеся вокруг этого принципа. Например, Alibaba в августе выпустила Alibaba Cloud Linux 4 Agentic Edition / ANOLISA. Там вместо обычной модели управления ОС появился agent-first слой, natural-language shell и система OS Skills, через которую агент может выполнять системные операции.

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

Есть и более экспериментальные проекты вроде HYVE Ether OS, где ИИ-агент вообще заявлен как shell ОС и предполагается его самоулучшение. И хотя это пока скорее исследовательско-экспериментальная история, чем доказанная массовая архитектура, движение вырисовывается вполне себе определенное.

С точки зрения кибербеза это все ночной кошмар, когда у вас сама ОС начинает придумывать, как решить задачу, в том числе и создавая новое ПО, которое может жить очень ограниченное время. Как это описывать в современных EDR? И как отличить самовоспроизводимое ПО в легальных целях от вредоносов?

Но я думаю, мы постепенно вообще размываем само понятие «приложение». Сегодня вы говорите: «Открыть MP SIEM». Потому что задача представлена объектом – приложением. В агентской модели вы говорите: «Посмотри события безопасности за последние 3 недели, найди аномалии и сделай прогноз». И системе вообще необязательно иметь MP SIEM (крамольную мысль высказал). Она может на лету собрать:

• PDQL-запрос
• Python-код
• график или дашборд
• интерактивную таблицу
• временный UI
• агента
• workflow.

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

• работать с моей базой материалов
• разбирать Downloads
• делать суммаризацию текстов
• готовить презентации
• следить за RSS
• взаимодействовать с моим сайтом
• знать структуру моих книг и исследовательских проектов
• создавать картинки
• готовить посты.

А у моего коллеги, занимающегося threat hunting’ом, та же исходная ОС через полгода:

• взаимодействует с PT Fusion
• анализирует заголовки разных типов файлов
• готовит разбор поведения файла и дерево запросов к ОС
• строит таймлайны
• пишет DFIR-скрипты
• интегрируется с VirusTotal или национальным «Мультисканером».

Через год это уже практически две разные операционные системы. Хотя первоначально они обе были, допустим, Omarchy 5.2. Но подстраиваясь под вас, операционная система переписала 12% себя; или 27%, или 43%. Это же кошмар практически для всех, кто занимается безопасностью, эксплуатацией и поддержкой.

И куда нас это заведет?

Я бы предположил, что мы пойдем в сторону продажи не ПО, решающего какую-то задачу, а в сторону продажи возможности решать какую-то задачу. Несмотря на кажущуюся схожесть, это две кардинально разных истории. Условно, чтобы сейчас написать статью, мне нужен MS Word (на самом деле не нужен и я пишу в VS Code, но сдаю финальный текст я обычно не в Markdown, а в .docx). А в будущем мне будут продавать способность создавать тексты и мне будет совершенно пофигу, что там под капотом, если я получаю конечный результат, который мне и нужен. Тоже самое касается ИБ. Вместо продажи NDR, EDR, SIEM, CDR и т.п., я буду получать набор примитивов, которые смогут мне просто генерить нужного агента под мой запрос или просто решать мой запрос, создавая временных агентов по анализу телеметрии и реагированию на инциденты с последующим удалением их по мере достижения результата. И каждый пользователь получит свою собственную ветку эволюции ПО; что-нибудь типа:

SIEM-base 32.2
+
Alexey branch
├── 184 generated capabilities
├── 37 workflows
├── 12 agents
└── 26 UI adaptations


И вот здесь начинается «праздник» для ИБ, потому что вся современная модель безопасности основана на предположении «мы знаем, что за ПО запущено». А здесь через полгода эксплуатации мы этого уже не знаем. Возникают очень неприятные вопросы:

• Что именно надо патчить?
• Как считать SBOM?
• Как делать подписать кода?
• Как проводить аудит?
• Что считать supply chain?
• Кто автор сгенерированного кода?
• Кто отвечает за уязвимость?
• Как воспроизвести баг?
• Как провести forensic analysis?
• Как отличить полезную адаптацию от присутствия злоумышленника?

И особенно красивый в своей глубине вопрос:

Если агент сам изменил механизм собственной безопасности, это обновление, изменение конфигурации или инцидент ИБ?

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

То есть условно не: «Вот контрольная сумма XYZ123. Все остальное запрещено», а «Система имеет право меняться, если каждое изменение прошло через разрешенный контур, сохранило заданные инварианты безопасности и оставило проверяемый след».

То есть привычная оценка соответствия станет многослойной. Да, останется фиксированное доверенное ядро. Цепочка загрузки, hypervisor/runtime, agent framework, policy engine, механизм обновления, ключи подписи и т. п. – это все еще можно хэшировать, подписывать и сертифицировать, используя традиционные механизмы. Здесь я бы посмотрел еще в сторону RFC 9334, который как раз описывает модель, где один доверенный слой измеряет следующий и формирует проверяемые доказательства об его состоянии.

Второй слой – сертифицированные правила изменения. Сертифицируется уже не каждая будущая программа, а то, что агенту разрешено делать – создавать UI, генерировать scripts в sandbox, устанавливать подписанные skills, менять пользовательские workflows. При этом агенту запрещено переписывать policy engine, менять собственные права доступа, отключать регистрацию событий, читать чужие домены/зоны безопасности и т.п.

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

Четвертый возможный слой оценки соответствия – инварианты вместо фиксированной реализации. Например, требования сегодня могут звучать: «ПО должно реализовывать функцию X способом Y». В самоэволюционирующейся системе гораздо логичнее будет: «независимо от того, как система себя изменила, должны всегда соблюдаться свойства A, B и C».

То есть мы начнем сертифицировать не код, а неизменные свойства системы.

А потом сертификат становится «живым» и статус «СООТВЕТСТВУЕТ ТРЕБОВАНИЯМ» может быть не бумажкой, полученной два года назад, а свойством системы в данный момент времени. Этакая непрерывная сертификация/оценка соответствия. Дальше больше. Придется сертифицировать саму способность к изменению. То есть оценщик будет проверять, что произойдет, если я попрошу систему сделать нечто, чего разработчики никогда не предусматривали? Например, сгенерировать 10000 случайных новых возможностей и попытаться:

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

То есть сертификационные испытания начнут очень сильно напоминать: тестирование свойств + фаззинг + red teaming + формальная верификация + мониторинг в процессе исполнения.

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

Очень интересная задачка из теории конечных автоматов…

И отсюда вылезает еще более неприятный вопрос для регуляторов. А что тогда вообще считать «объектом оценки»: бинарник, платформу, агент, модель, policy engine или всю систему правил эволюционирующегося по каким-то своим внутренним законам ПО?

В интересное время живем, однако…