Как установить надежные защитные барьеры безопасного SDLC для разработки с использованием агентов

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

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

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

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

Представьте себе сценарий, в котором предприятие развертывает автономного агента рефакторинга кода для модернизации устаревшей службы посредством миграции в облако. Предприятие полагается на стандартные защитные барьеры DevSecOps, такие как моделирование угроз, статическое тестирование безопасности приложений (SAST), динамическое тестирование безопасности приложений (DAST), интерактивное тестирование безопасности приложений (IAST), анализ состава программного обеспечения (SCA), линтинг инфраструктуры как кода (IaC) и обязательное экспертное рецензирование кода.

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

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

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

Агенту предоставляется стандартная роль «облачного разработчика», которая позволяет ему создавать и изменять инфраструктуру хранилища в среде промежуточного тестирования. Сканеры IaC выполняют точечную проверку, но не видят, как агент изменяет шаблон позже.

Работая на машинно-быстрой скорости, агент разбивает миграцию на 500 микро-запросов на слияние (pull requests). Человеческие разработчики проверяют первые 100 и не находят ничего необычного. Но вредоносный PR оказался 499-м.

Разработка с помощью ИИ увеличивает скорость, но также расширяет поверхность рисков за счет появления таких новых векторов атак.

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

Идентификация, доступ и авторизация

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

Организации могут обратиться к органам по стандартизации и нормативным актам за рекомендациями по идентификации агентов. В США, например, Национальный институт стандартов и технологий (NIST) является правительственным агентством, которое разрабатывает подходы на основе стандартов и практические рекомендации. Его Национальный центр передового опыта в области кибербезопасности (NCCoE) работает над standards for AI agent identity and authorization.

Опасные входные данные и злоупотребление инструментами

Может ли кто-то манипулировать тем, что агент считает своей задачей? И какой вред может нанести агент, даже если им внешне не манипулирует злоумышленник?

Опасные входные данные могут включать инъекции промптов и поведенческие манипуляции, а также отравление контекста, памяти, инструментов и данных. Вредоносные инструкции могут скрываться на веб-страницах, в комментариях исходного кода или в результатах работы другого агента. Это означает, что весь SDLC становится частью поверхности атаки.

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

Качество кода

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

К счастью, хотя инструменты на базе агентов представляют риск, они также представляют собой мощное решение. Современные инструменты написания кода на базе агентов, такие как IBM BOB, могут быстро сканировать крупные кодовые базы устаревшего ПО для выявления запахов кода (code smells) и устранения «спагетти-кода», сводя к минимуму необходимость трудоемкого ручного осмотра потенциально тысяч строк кода.

Цепочка поставок программного обеспечения и зависимость от сторонних компонентов

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

Риски взаимодействия между агентами

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

Соответствие требованиям и аудируемость

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

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

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

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

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

Фундаментальный принцип современного безопасного SDLC заключается в том, что защитные барьеры должны быть встроены в рабочие процессы разработчиков, CI/CD-конвейеры, разработку с поддержкой ИИ (включая генерацию кода ИИ) и цепочку поставок программного обеспечения.

На самом высоком уровне эти защитные барьеры можно разделить на четыре основные категории:

• Управление и владение

Управление и владение

• Применение политик в рабочих процессах разработчиков

Применение политик в рабочих процессах разработчиков

• Защита цепочки поставок программного обеспечения

Защита цепочки поставок программного обеспечения

• Аудируемость и прослеживаемость

Аудируемость и прослеживаемость

Управление и владение

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

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

Появление разработки с поддержкой ИИ требует защитных барьеров, которые:

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

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

Применение политик в рабочих процессах разработчиков

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

Практики безопасного кодирования, требования к одобрению изменений с высоким уровнем риска и проверка человеком там, где это уместно, могут быть встроены непосредственно в репозитории, запросы на слияние (pull requests) и CI/CD-конвейеры.

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

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

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

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

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

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

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

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

Защита цепочки поставок программного обеспечения

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

Защитные барьеры должны устанавливать:

• Средства контроля, регулирующие использование сторонних компонентов;

Средства контроля, регулирующие использование сторонних компонентов;

• Происхождение артефактов — защищенные от несанкционированного вмешательства доказательства того, где и кем был создан каждый программный артефакт;

Происхождение артефактов — защищенные от несанкционированного вмешательства доказательства того, где и кем был создан каждый программный артефакт;

• Генерацию спецификации состава программного обеспечения (SBOM) для каждого релиза;

Генерацию спецификации состава программного обеспечения (SBOM) для каждого релиза;

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

Управление компонентами с открытым исходным кодом и артефактами, чтобы гарантировать надлежащее лицензирование, поддержку и исправление компонентов.

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

Аудируемость и прослеживаемость

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

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

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

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

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

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

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

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

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

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

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

В этом могут помочь отраслевые стандарты безопасности. Две наиболее популярные структуры, которые часто используются вместе, включают:

• NIST SSDF. Опубликованная и поддерживаемая Национальным институтом стандартов и технологий (NIST), структура Secure Software Development Framework (SSDF) описывает высокоуровневые требования к безопасности программного обеспечения и лучшие практики, организованные по четырем дисциплинам или областям деятельности: подготовка организации (PO), защита программного обеспечения (PS), создание хорошо защищенного программного обеспечения (PW) и реагирование на уязвимости (RV). Специальная публикация (SP) 800-218 описывает конкретные практики, задачи и доказательства, необходимые для подтверждения соблюдения этих практик. (Поскольку SDDF SP-800-218 является базовым стандартом для федеральных требований к аттестации безопасности программного обеспечения, он также служит структурой для обеспечения соответствия требованиям.)

NIST SSDF. Опубликованная и поддерживаемая Национальным институтом стандартов и технологий (NIST), структура Secure Software Development Framework (SSDF) описывает высокоуровневые требования к безопасности программного обеспечения и лучшие практики, организованные по четырем дисциплинам или областям деятельности: подготовка организации (PO), защита программного обеспечения (PS), создание хорошо защищенного программного обеспечения (PW) и реагирование на уязвимости (RV). Специальная публикация (SP) 800-218 описывает конкретные практики, задачи и доказательства, необходимые для подтверждения соблюдения этих практик. (Поскольку SDDF SP-800-218 является базовым стандартом для федеральных требований к аттестации безопасности программного обеспечения, он также служит структурой для обеспечения соответствия требованиям.)

• OWASP SAMM. Опубликованная проектом Open Worldwide Application Security Project (OWASP), модель Software Assurance Maturity Model (SAMM) представляет собой структуру с открытым исходным кодом для оценки зрелости безопасной разработки в пяти (5) ключевых областях — управление, проектирование, реализация, проверка и эксплуатация — и определения дальнейших действий.

OWASP SAMM. Опубликованная проектом Open Worldwide Application Security Project (OWASP), модель Software Assurance Maturity Model (SAMM) представляет собой структуру с открытым исходным кодом для оценки зрелости безопасной разработки в пяти (5) ключевых областях — управление, проектирование, реализация, проверка и эксплуатация — и определения дальнейших действий.

Организации могут использовать NIST SSDF в качестве справочника средств контроля, на основе которых можно выстраивать защитные механизмы и достигать целей соответствия, а OWASP SAMM — для приоритизации внедрения на основе текущего состояния рисков в каждой области.

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

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

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

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