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

20 августа 2026 г.

Уроки построения стратегии агентной безопасности программного обеспечения в Palantir

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

Введение

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

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

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

• Модель сама по себе — это еще не программа проверки безопасности. Моделям нужна обвязка — программное обеспечение, инструкции, инструменты и средства контроля, которые распределяют работу между агентами, определяют, к чему имеет доступ каждый агент, сохраняют доказательства, ставят под сомнение результаты и направляют их инженерам. Мы используем нашу Palantir Artificial Intelligence Platform (AIP) в качестве оркестратора рабочих нагрузок, управляемых агентами.
• Качество обвязки сильно зависит от организационного контекста, который она способна использовать для конкретной задачи. Модель более полезна, когда она понимает, как связаны службы, где проходят границы доверия, какие конфигурации развернуты, к каким выводам пришли предыдущие проверки и кто отвечает за затронутое программное обеспечение. Мы используем нашу платформу для работы с данными Palantir Foundry, чтобы связать этот контекст через онтологическую родословную между исходными материалами, результатами, решениями и устранением уязвимостей.
• Контекст организации — это ее альфа, и он должен оставаться в ее собственности и под ее контролем. Контекст, который позволяет агентам безопасности быть эффективными — данные, модели, решения, действия, среды развертывания и накопленные знания — является частью уникальной альфы организации и не должен раскрываться внешним сторонам. Суверенитет над конвейером ИИ-безопасности является ключом к тому, чтобы интеллект, генерируемый организацией, накапливался в ее собственных системах, а не приносил пользу третьим лицам, которые могли бы переупаковать его, перепродать или использовать для подрыва конкурентной позиции организации.
• Устранение уязвимостей — это новое «узкое место». Темпы выявления уязвимостей фундаментально ускорились. Это сместило «узкое место» в киберзащите с идентификации на устранение: как быстро можно развернуть исправления в обширных, гетерогенных средах? Мы используем нашу платформу производства программного обеспечения Palantir Apollo для онтологизации свойств нашей среды и обеспечения установленного пути для доставки проверенных исправлений по всему нашему парку программного обеспечения.
• Модели и обвязки будут продолжать совершенствоваться. Долговечной возможностью является регулируемый процесс и инфраструктура вокруг них. Поскольку модели и обвязки со временем улучшаются, инфраструктура вокруг них будет определять, действительно ли программа безопасности организации становится лучше в результате. Наш конвейер безопасности — Foundry, накапливающий контекст безопасности и память, AIP, оркестрирующий сменные агенты, и Apollo, применяющий исправления ко всему нашему программному обеспечению — обеспечивает долговечную структуру, которая позволяет нам адаптироваться по мере изменения моделей и угроз.

Развитие идей

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование организационного контекста

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

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

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

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

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

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

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

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

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

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

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

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

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

В качестве примера суверенитета в области ИИ мы недавно завершили миграцию всех сотрудников 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 создает непрерывно работающий цикл, основанный на обратной связи, который со временем повышает точность обнаружения, снижает нагрузку на аналитиков и ускоряет время локализации подтвержденных угроз.

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

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

• Создайте инвентаризацию программного обеспечения. Подключите репозитории, сервисы, зависимости, владельцев, развернутые версии и среды выполнения. Агенты должны знать, что существует и кто несет за это ответственность.
• Начните с ограниченных задач по проверке кода. Выбирайте цели, где результаты можно привязать к конкретным путям кода и проверить инженерами. Используйте эти проверки для установления стандартов доказательств и формирования первоначального контекста.
• Обеспечьте контролируемую среду для моделей. Распределяйте работу между специализированными агентами, ограничивайте инструменты и учетные данные по этапам, сохраняйте доказательства для каждого результата, независимо проверяйте предполагаемые находки и удаляйте дубликаты, прежде чем они попадут к инженерам.
• Оценивайте несколько моделей и повторяющиеся запуски. Сравнивайте модели и методы проверки на одних и тех же целях и известных случаях безопасности. Отслеживайте покрытие, уровень валидации, стоимость, время выполнения, поведение при отказах и частоту дублирования. Не предполагайте, что новейшая модель или одно успешное сканирование обеспечивают полное покрытие.
• Сохраняйте решения как организационный контекст. Храните результаты, ложноположительные срабатывания, решения о достижимости, принятые риски, меры по смягчению последствий и исправления в управляемой системе с отслеживанием происхождения. Каждая проверка должна делать последующие проверки кода, дизайна и динамические проверки более обоснованными.
• Сохраняйте суверенитет своего контекста. Поддерживайте владение и контроль над создаваемой вами ценностью. Мы выделяем 15 шагов, которые может предпринять каждая компания, чтобы обеспечить как свой суверенитет, так и преимущество here.
• Предоставьте инженерам по безопасности и продуктам общий рабочий процесс. Инженерам необходимо изучать доказательства, добавлять системный контекст, оценивать серьезность, назначать владельцев, а также разрабатывать и утверждать исправления, не создавая еще одну разрозненную очередь задач по безопасности.
• Подключите проверенные исправления к обычному процессу поставки программного обеспечения. Утвержденные патчи должны проходить через те же элементы контроля выпуска, развертывания, мониторинга работоспособности и отката, которые используются для других изменений в программном обеспечении.