44% задач, выполненных с помощью генеративных помощников для программирования, привнесли известную уязвимость. На этом фоне разговор о защите ПО перестаёт быть спором о том, какой сканер поставить в CI, и становится вопросом инженерной дисциплины. Американское издание Dark Reading собрало десять принципов, которые должны пережить смену языков, облаков и нынешнего ИИ-ажиотажа — и для российских команд в них нет ничего экзотического, кроме горизонта в 250 лет.
Материал написал Кристофер Уолкатт, директор по безопасности компании DirectDefense. Он напоминает, что ещё в 1998 году, выступая в Конгрессе США вместе с коллегами из хакерского сообщества L0pht, предупреждал о рисках небезопасного ПО для критической инфраструктуры. За почти три десятилетия стек изменился радикально, но базовые вопросы остались прежними: откуда в систему приходит недоверенный ввод, какими полномочиями обладает компонент, кто отвечает за риск и как проверить, что контроль действительно работает.
Безопасность начинается не на этапе аудита
Первый тезис Уолкатта звучит почти банально, но на практике его регулярно откладывают до первого инцидента: безопасность должна быть частью архитектуры. Речь не о чек-листе перед релизом, а о безопасных настройках по умолчанию, утверждённых паттернах, явных границах доверия и механизмах, при которых небезопасный вариант сложно выбрать случайно. Если контроль появляется в конце разработки, он вынужден спорить с уже принятыми архитектурными решениями. Встроенный контроль, напротив, становится свойством самого продукта.
Вторая опора — актуальная карта того, чем организация вообще владеет и что использует. В неё должны входить приложения, open-source-зависимости, инструменты разработки, внешние сервисы и модели ИИ, а у критичных систем — назначенный владелец. Когда появляется серьёзная уязвимость, команде нужны не недели на поиск репозиториев и согласования, а ответ на три вопроса: где работает уязвимый компонент, до чего он может дотянуться и кто обязан устранить проблему. Инвентаризация без ответственности превращается в аккуратно оформленный список тревог.
Отдельное место автор отводит проверке кода независимо от происхождения: написан ли он штатным разработчиком, сгенерирован ассистентом или взят у третьей стороны. Приведённая в статье оценка — 44% задач с ИИ-кодом содержали известную уязвимость — не означает, что автодополнение надо запретить приказом. Она означает, что защита ПО не может полагаться на происхождение патча. Нужны независимое тестирование, автоматические проверки и скорость работы, сопоставимая со скоростью генерации изменений.
Для разработчиков вывод особенно прикладной: защищённый путь должен быть самым коротким. Если SAST заваливает ложными срабатываниями, секретный пакет проще скачать из случайного реестра, а исправление требует трёх тикетов, контроль будут обходить. Автор предлагает переносить точную обратную связь, разрешённые компоненты и проверенные исправления в привычные места работы — репозиторий, IDE и конвейер сборки. Автоматике достаётся повторяемая рутина, инженерам — решения, где без знания продукта и последствий не обойтись.
Зависимости, долги и агенты
Современное приложение собирается из значительно большего объёма чужого кода, чем собственного. Поэтому одного SBOM или перечня библиотек недостаточно: компоненты надо оценивать при попадании в сборку, фиксировать их происхождение, выявлять вредоносные и заброшенные пакеты, заранее готовить безопасное обновление. Список зависимостей отвечает на вопрос «что у нас есть», но не гарантирует, что рискованная зависимость не попадёт в следующий релиз.
Не менее неприятная тема — накопленный долг. По данным исследования Veracode, на которое ссылается автор, он затрагивает 82% организаций: уязвимости остаются неустранёнными более года. Уолкатт связывает это с ИИ: инструменты могут ускорить поиск слабых мест настолько, что многолетняя исследовательская работа сожмётся до месяцев. Для бизнеса это аргумент финансировать исправления как постоянную инженерную функцию, а не как авральный проект после публичного CVE. Полезнее считать не число закрытых тикетов, а время, в течение которого критичная эксплуатируемая ошибка доступна атакующему, и соотношение новой и погашенной экспозиции.
Самый свежий участок списка — моделирование угроз для ИИ-систем целиком. Агент — это не только модель: его возможности определяют идентичность, права доступа, инструменты, память, данные, среда исполнения и сеть. Чувствительные действия нужно авторизовать в точке выполнения, доступ скомпрометированного компонента — ограничивать, а следов работы оставлять достаточно для последующего разбора. Иначе расследование инцидента сведётся к бесполезному вопросу: «Почему модель так решила?»
Последний принцип звучит менее технологично, но именно он удерживает остальные: у каждого важного приложения и принятого риска должен быть ответственный человек, а у решений — следы тестов, применённых контролей и обоснований. Чем больше кода создают и меняют машины, тем важнее способность команды проверить их результат и оспорить сомнительное решение. Через 250 лет названия фреймворков исчезнут; входные данные, привилегии, зависимости и ответственность никуда не денутся. Вопрос для компаний уже не в том, появится ли следующий ускоритель разработки, а в том, успеет ли их защита ПО стать частью процесса до его внедрения.
