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

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

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

Проблема зависимостей теперь является проблемой ИИ

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

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

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

Сканирование после факта не является стратегией

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

Сканеры обнаруживают проблемы после того, как они уже есть в вашем коде. Окно между введением и обнаружением – это место, где живет ваша уязвимость. Когда ИИ генерирует код в большом масштабе, это окно становится шире, и объем результатов растет быстрее, чем любая команда может вручную исправить. Результатом является список уязвимостей, который расширяется бесконечно, приоритизация становится猜work, и разработчики тратят 4-8 часов на каждую уязвимость на работу, которая не приносит никакой бизнес-ценности.

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

Сдвиг, который действительно работает: контроль того, что попадает внутрь

Организации, которые обгоняют это, перестали пытаться сканировать свой путь к безопасности и начали контролировать, что их разработчики и инструменты ИИ могут потреблять в первую очередь. Механизм – это отобранный, управляемый политикой каталог компонентов с открытым исходным кодом, построенный из источника, непрерывно контролируемый и представленный как частный внутренний реестр, который заменяет прямые запросы к публичным экосистемам, таким как PyPI, npm или Maven.

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

Как это выглядит на практике

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

1. Определите набор одобренных компонентов, прежде чем масштабировать принятие ИИ. Если ваши инструменты кодирования ИИ разрешают зависимости из публичных реестров, ваш процесс одобрения существует только на бумаге. Установите управляемый внутренний реестр, направьте все через него и требуйте, чтобы компоненты были построены из источника с верифицированной происхождением.
2. Относитесь к исправлению как к управляемому процессу, а не к очереди тикетов. Организации, которые остаются впереди долга уязвимостей, не двигаются быстрее на ручном исправлении. Они удалили ручное исправление из уравнения. Когда доступен патч, одобренный сообществом, он автоматически перестраивается в каталог. Разработчики получают обновление в следующий раз, когда они запрашивают. Никто не назначает тикет. Никто не ждет 60 дней.
3. Сопоставьте свою цепочку инструментов ИИ с вашими обязательствами по соблюдению требований до того, как вы будете вынуждены это сделать. Я наблюдал, как команды строят на инструментах ИИ в течение месяцев, только чтобы столкнуться со стеной, когда клиент требует соответствия FedRAMP или доказательств SOC 2. Ваш отобранный каталог также является вашим следом аудита соблюдения требований. SBOM и записи происхождения должны поставляться с каждым компонентом, а не собираться ретроспективно под давлением сроков.
4. Назначьте четкую собственность на уровне управления, а не на уровне тикета. Команды, которые двигаются быстрее на исправлении, не являются теми, у которых больше всего разработчиков. Это те, где команда безопасности владеет политикой, команда платформы владеет доставкой, и ни одна из них не ждет, пока другая команда действует.

Безопасность, которая позволяет, а не блокирует

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

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