Обеспечение безопасности ПО со скоростью ИИ

14 мин чтения

20 авг. 2026 г.

Уроки создания стратегии безопасности ПО на базе автономных ИИ-агентов в Palantir

Нажмите Enter или кликните, чтобы посмотреть изображение в полном размере

Введение

Команда продуктовой безопасности Palantir начала экспериментировать с агентным ИИ в различных рабочих процессах безопасности более года назад. К тому моменту, когда Anthropic запустила Project Glasswing, мы уже использовали внутреннюю многоагентную систему проверки с ИИ-агентами по безопасности, специализирующимися в различных областях. Модель Mythos от Anthropic и киберпрограмма от OpenAI помогли ускорить эту работу.

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

Пять ключевых выводов легли в основу нашей стратегии безопасности ПО и продукта Security Forge:

• Сама по себе модель — это еще не программа проверки безопасности. Моделям требуется обвязка (harness) — программное обеспечение, инструкции, инструменты и средства контроля, которые распределяют работу между агентами, определяют права доступа каждого агента, сохраняют доказательства, ставят под сомнение результаты и направляют их инженерам. Мы используем нашу платформу искусственного интеллекта Palantir (AIP) в качестве оркестратора рабочих нагрузок, управляемых агентами.

• Качество обвязки во многом зависит от организационного контекста, который она может задействовать для конкретной задачи. Модель приносит больше пользы, когда она понимает взаимосвязь сервисов, расположение границ доверия, развернутые конфигурации, выводы предыдущих проверок и владельца затронутого ПО. Мы используем нашу платформу обработки данных Palantir Foundry для объединения этого контекста посредством онтологического происхождения (lineage) между исходными материалами, находками, решениями и устранением уязвимостей.

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

• Устранение уязвимостей — новое «узкое горлышко». Темпы обнаружения уязвимостей фундаментально ускорились. Это сместило «узкое горлышко» в киберзащите с обнаружения на устранение: как быстро можно развернуть исправления в огромных гетерогенных средах? Мы используем нашу платформу разработки ПО Palantir Apollo для онтологизации свойств нашей среды и создания проверенного пути доставки исправлений по всему нашему парку программного обеспечения.

• Модели и обвязки будут продолжаться совершенствоваться. Устойчивым активом является регламентированный процесс и инфраструктура вокруг них. По мере того как модели и обвязки будут улучшаться, именно окружающая их инфраструктура определит, действительно ли программа безопасности организации станет лучше в результате. Наш конвейер безопасности — Foundry, объединяющий контекст и память безопасности, AIP, оркестрирующая взаимозаменяемые агенты, и Apollo, применяющая исправления во всем нашем ПО, — обеспечивает надежную основу, позволяющую нам адаптироваться по мере изменения моделей и угроз.

Подробнее о выводах

В ходе наших ранних оценок агентного ИИ Palantir тестировал агентов в процессах подготовки запросов на комментарии (RFC) и инженерных проверок, анализа исходного кода, триажа уязвимостей (CVE), разработки патчей и тестирования на проникновение. Не все агенты оказались одинаково полезны. Проверка кода и анализ уязвимостей принесли наибольшую и наиболее воспроизводимую пользу. Они генерировали практические результаты, привязанные к конкретным путям кода, одновременно наращивая знания о продуктах, сервисах, границах доверия, архитектуре, предыдущих находках и причинах принятия решений по безопасности.

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

Ниже мы подробно описываем идеи, которые помогли нам эволюционировать и ускорить многие аспекты нашей внутренней стратегии безопасности ПО и продукта Security Forge.

Моделям нужна обвязка

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

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

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

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

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

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

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

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

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

Обвязки нуждаются в организационном контексте

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

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

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

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

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

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

Организационный контекст должен оставаться суверенным

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

Получайте истории Palantir на свою электронную почту

Присоединяйтесь к Medium бесплатно, чтобы получать обновления от этого автора.

Запомнить меня для более быстрого входа

Кроме того, уровень безопасности организации не может зависеть от учетной записи одной модели, облачного региона или дорожной карты какого-то одного вендора. Организация должна иметь возможность направлять обнаружение, триаж и реагирование через любую модель, любую вычислительную инфраструктуру и любую среду развертывания — локальную (on-premises), в суверенном облаке или на периферии (edge). Это особенно критично для рабочих нагрузок безопасности, где операционная скорость требует возможности действовать на основе выявленных проблем в режиме реального времени. Управляемый цикл, который связывает обнаружение с устранением и внедрением, должен оставаться под собственным контролем организации, чтобы двигаться с той скоростью, которую действительно диктуют угрозы.

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

В качестве примера суверенитета ИИ мы недавно завершили перевод всех сотрудников Palantir с клиентских приложений от передовых провайдеров на инструменты производительности собственной разработки. Это дало нам гибкость в использовании моделей и архитектуре, а также полный контроль над судьбой любых данных (альфа-факторов), присутствующих в конкретной рабочей нагрузке. Мы ожидаем, что подобная норма распространится по всей индустрии по мере того, как организации будут взвешивать риски, способные поставить под угрозу их собственные средства производства.

Устранение уязвимостей — новое узкое место

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

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

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

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

Процесс и инфраструктура — это долговечные возможности

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

В нашей программе безопасности:

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

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

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

В совокупности Foundry, AIP и Apollo обеспечивают программе стабильную основу по мере эволюции моделей и угроз. Foundry сохраняет контекст, AIP предоставляет заменяемый уровень интеллекта, а Apollo гарантирует, что одобренные изменения выполняются контролируемым и отслеживаемым образом. Модели могут изменяться в любое время, не заставляя нас перепроектировать всю программу безопасности вокруг них.

Security Forge — решение для клиентов

Для клиентов, которые хотят использовать возможности Palantir для собственной киберзащиты, мы разработали Security Forge — платформу для проверки с помощью ИИ, не зависящую от конкретных моделей. Она автоматизирует высокоинтенсивные, повторяющиеся элементы операций по безопасности, сохраняя при этом человеческое суждение для принятия наиболее важных решений. Security Forge включает в себя упомянутые выше платформы Foundry, AIP и Apollo в виде интегрированного решения, которое клиенты могут использовать в своих средах. Security Forge позволяет организациям:

• Использовать настроенные под кибербезопасность большие языковые модели (LLM) с доступом к коду и сети для активного поиска уязвимостей;

• Применять организационный контекст (состав команд, критичность активов, данные об использовании, реальные данные и разведданные) для интеллектуальной расстановки приоритетов в отношении обнаруженных проблем;

• Передавать результаты проверок агенту по устранению уязвимостей, который автоматически рекомендует и создает изменения в коде и архитектуре, а также средства минимизации рисков, способные разорвать цепочку атак (kill-chain);

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

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

Создание собственного конвейера агентской безопасности

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

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

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

• Установите контролируемую оболочку (harness) для моделей. Распределите работу между специализированными агентами, ограничьте инструменты и учетные данные по этапам, сохраняйте доказательства для каждого обнаружения, независимо проверяйте предполагаемые результаты и удаляйте дубликаты перед тем, как они попадут к инженерам.

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

• Сохраняйте решения в качестве организационного контекста. Храните результаты проверок, ложноположительные срабатывания, решения о достижимости, принятые риски, меры по минимизации и исправления в управляемой системе с отслеживанием происхождения (lineage). Каждая проверка должна делать последующие проверки кода, дизайна и динамические проверки более информированными.

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

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

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

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