Заид Аль Хамани, генеральный директор и основатель Boost Security – Интервью

Заид Аль Хамани, генеральный директор и основатель Boost Security, является лидером в области кибербезопасности и DevSecOps с более чем двумя десятилетиями опыта построения и масштабирования глобальных технологических операций. С момента основания Boost Security в 2020 году он сосредоточился на модернизации того, как организации обеспечивают безопасность разработки программного обеспечения, опираясь на предыдущие роли, включая вице-президента по безопасности приложений в Trend Micro и сооснователя/генерального директора IMMUNIO. Ранее он занимал руководящие должности в Canonical, где возглавлял разработку продукта, инженерию и глобальную поддержку, и в SITA, где управлял крупномасштабными, критически важными для миссии ИТ-операциями. Его карьера отражает сильный послужной список построения команд, оптимизации систем и продвижения современных практик безопасности.

Boost Security – это компания по кибербезопасности, которая фокусируется на защите современной цепочки поставок программного обеспечения через платформу DevSecOps, ориентированную на разработчиков. Ее технология интегрируется直接 в конвейеры CI/CD для автоматического обнаружения, определения приоритета и устранения уязвимостей, снижая ручную нагрузку при сохранении скорости разработки. Объединяя безопасность приложений и цепочки поставок в единую систему, платформа обеспечивает полную видимость кода, зависимостей и инфраструктуры, помогая организациям укреплять устойчивость в сложных, родных для облака средах.

Ранее вы возглавляли безопасность приложений в Trend Micro и были сооснователем IMMUNIO. Что привело вас к основанию Boost Security, и какую пробел на рынке вы были уникально позиционированы для выявления?

IMMUN.IO была одной из первых компаний RASP, и наш опыт до этого момента показал, что WAF в качестве технологии безопасности во время выполнения было невозможно поддерживать и не очень эффективно. Мы представили себе способ, при котором WAF будет заменен более точным и легким в обслуживании решением – путем инструментирования приложения.

Это было в 2012 году, DevOps еще только зарождался, большинство команд не были Agile, и Kubernetes еще не существовало.

Trend Micro приобрела IMMUN.IO в 2017 году. К тому времени DevOps-практики стали более распространенными: конвейеры CI/CD, практики Agile-разработки, более быстрые итерации и циклы выпуска, облако и т. д. Команды разработчиков стали лучше в построении программного обеспечения и его доставке. Однако безопасность все еще была сломана:

• Сканирования слишком медленные или результаты приходят слишком поздно
• Результаты слишком сложны для разработчиков, чтобы они могли их реализовать
• Существует общепринятый недопустимый уровень ложных положительных результатов
• Многие новые типы артефактов не сканируются: инфраструктура как код, контейнеры, API и т. д.

Производство программного обеспечения быстро стало проще. Производство безопасного программного обеспечения быстро все еще было сложно.

Это была исходная проблема, которую мы поставили перед собой. Сделать DevSecOps работоспособным в реальном мире; можно ли заставить команду разработчиков легко добавить безопасность в SDLC, со скоростью, соответствующей новым стандартам скорости? Можно ли сделать покрытие широким – где одна платформа является всем, что вам нужно? Можно ли сделать так, чтобы разработчики, а не только принимали технологию, но и видели ее преимущества? Можно ли сделать ее масштабируемой, чтобы вам не нужно было целые армии специалистов по безопасности, чтобы поддерживать количество написанного кода…

Мы помогли компаниям внедрить безопасность в SDLC во время эры DevOps. Это было переходом от 1 до 10. Теперь мы находимся в эпоху агентного кодирования – где агенты пишут огромное количество кода – но это по сути та же проблема – скорость и объем кода просто перешли от 10 до 100; и мы стремимся продолжить ту же траекторию.

Вы утверждали, что жизненный цикл разработки программного обеспечения (SDLC) фундаментально сместился вверх по течению. Какой был момент, когда вы поняли, что традиционные подходы DevSecOps больше не являются достаточными?

Это было наблюдение за тем, как атакующие фактически проникали. Мы постоянно видели одну и ту же закономерность: открытый рабочий процесс GitHub Actions, который никто не проверял с момента fork-репозитория, токен с доступом к производственной облачной среде, встроенный в конфигурацию runner, легитимная задача CI, захваченная для развертывания полезной нагрузки атакующего. Эти стали известны как атаки “living off the pipeline”, потому что противник использует вашу собственную автоматизацию против вас, с учетными данными, которые ваша команда безопасности уже одобрила.

Стек DevSecOps, который мы построили за десятилетие, не имел ответа на это. SAST сканирует исходный код приложения. SCA сканирует зависимости приложения. Оба предполагают, что конвейер, запускающий их, является доверенным. Тем временем сам конвейер является файлом YAML с командами shell, сетевым доступом и конфиденциальными учетными данными, и почти никто его не проверяет.

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

Как должны организации пересмотреть SDLC в мире, где агенты ИИ генерируют код непрерывно, а не разработчики, пишущие его шаг за шагом?

Мы все должны перестать думать о SDLC как о последовательности контрольных точек. Агенты ИИ сжали время между “кто-то написал это” и “это в производстве” с недель до минут. Старая модель предполагала человеческий темп между код-ревью, SAST, SCA и развертыванием, но мы вышли за эти рамки.

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

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

Рассматривать инструмент кодирования ИИ как слой производительности – это как рассматривать младшего разработчика с доступом root как слой производительности. Метка технически точна, но она не дает вам никакого полезного框а для思考а о том, что может пойти не так.

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

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

Boost представляет ноутбук разработчика как новую плоскость управления. Какие риски существуют на конечной точке, которые команды безопасности в настоящее время упускают из виду?

Самый большой риск – это инвентаризация. Большинство команд безопасности не могут сказать вам, какие агенты ИИ запускаются на каких ноутбуках, какие серверы MCP и модели эти агенты подключены, или какие расширения IDE соскабливают контент репозитория прямо сейчас. EDR не имеет видимости в слое агента; SIEM также не может увидеть, что эти агенты делают локально.

Под этим лежит беспорядок с учетными данными. Мы построили открытый инструмент под названием Bagel частично для того, чтобы сделать это конкретным. Типичный ноутбук разработчика содержит токены GitHub с доступом для записи в производственные репозитории, облачные учетные данные, которые могут запустить инфраструктуру, токены npm или PyPI, которые могут опубликовать контент для миллионов пользователей, и ключи сервисов ИИ, которые атакующие перепродают. Ни один из этих элементов не защищен так же, как защищен запускатель CI. Та же машина, которая содержит эти учетные данные, также просматривает веб и устанавливает случайные расширения VS Code.

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

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

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

Проблема обнаружения начинается с того, что трафик утечки выглядит идентично нормальному использованию продукта. Это TLS для api.openai.com или api.anthropic.com. Это исходит от одобренного бизнес-приложения. Стандартный DLP видит разработчика, использующего инструмент ИИ, который компания только что купила лицензию. Он не видит, что одна из строк в этой подсказке является ключом AWS, который агент получил из забытого файла .env в родительском каталоге.

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

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

Вот один из сценариев, который мы видели вариации повторно. Разработчик просит агента добавить функцию, которая требует библиотеки повторных HTTP-запросов. Агент предлагает имя пакета. Пакет звучит правдоподобно, но на самом деле не существует на npm. В течение часа атакующий регистрирует его, заполняет рабочей логикой повторных запросов плюс небольшой пост-инсталляционный скрипт, который читает ~/.aws/credentials и отправляет содержимое на веб-хук. Агент запускает npm install без проверки, потому что агенты не проверяют репутацию. Учетные данные утеряны, прежде чем разработчик даже запускает код.

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

Окно от публикации до компрометации теперь измеряется минутами. Любая проверка после этого происходит слишком поздно.

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

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

Практические защиты выглядят иначе, чем то, что большинство команд имеет сейчас. Начните с ингестии. Блокируйте опечатанные и недавно зарегистрированные пакеты на момент запуска npm install или pip install, на машине разработчика, до того, как что-либо попадет на диск. Обнаружение после факта в CI не помогает, когда пост-инсталляционный скрипт уже эксфилировал учетные данные. Затем дайте агенту ограничители, чтобы он работал внутри. Вставьте список одобренных зависимостей непосредственно в контекст агента, чтобы модель видела, что разрешено, прежде чем она сгенерирует предложение. Просьба к разработчикам написать “безопасные подсказки” не является стратегией. Если вы стратегически мыслите, это означает, что безопасность устанавливает границу, а агент наследует ее. И начните отслеживать Билль материалов ИИ. Большинство команд не могут сказать вам, какие агенты, модели и пакеты касаются каких репозиториев. Вы не можете защитить то, что не можете инвентаризировать.

Вы сказали, что безопасность больше не может начинаться в CI/CD. Что выглядит современный конвейер безопасности, когда защита должна начинаться раньше в процессе разработки?

Если безопасность начинается в CI/CD, вы уступили всю фазу до коммита среде, которую вы не контролируете. Агент уже получил контекст, ваши учетные данные могут уже быть в чьих-то журналах. Вы сканируете труп.

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

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

Когда организации продолжают采用 агенты кодирования ИИ, какие являются наиболее критическими изменениями, которые они должны сделать сегодня, чтобы обеспечить, что их среды разработки остаются безопасными в течение следующих нескольких лет?

Самая большая ошибка – это обеспечение безопасности только того, что коммитится. Интересный риск теперь живет в течение восьми часов до коммита. Невидимая драма может разыграться на ноутбуке, в подсказке или при установке пакета. Если ваши инструменты начинаются с PR, вы защищаете неправильную половину рабочего процесса.

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

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

Спасибо за отличное интервью, читатели, которые хотят узнать больше, должны посетить Boost Security.