Готовы ли мы к коду, сгенерированному ИИ?

В последние месяцы мы поражались качеству компьютерных лиц, фотографий кошек, видео, эссе и даже произведений искусства. Искусственный интеллект (ИИ) и машинное обучение (МО) также незаметно проникли в разработку программного обеспечения с помощью таких инструментов, как GitHub Copilot, Tabnine, Polycode, и другие сделать следующий логический шаг, поместив существующую функциональность автозаполнения кода на ИИ-стероиды. Однако, в отличие от кошачьих картинок, происхождение, качество и безопасность кода приложения могут иметь далеко идущие последствия — и, по крайней мере, для безопасности, исследования показывают, что риск реален.

Предварительный научные исследования уже показал, что GitHub Copilot часто генерирует код с уязвимостями безопасности. Совсем недавно практический анализ, проведенный инженером по безопасности Invicti Кадиром Арсланом, показал, что предложения по небезопасному коду для второго пилота по-прежнему являются правилом, а не исключением. Арслан обнаружил, что предложения для многих распространенных задач включают в себя только абсолютно голые кости, часто выбирая самый простой и наименее безопасный маршрут, и что принятие их без изменений может привести к функциональным, но уязвимым приложениям.

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

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

Сатнав синдром

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

Особенно для менее опытных разработчиков удобство получения бесплатного блока кода способствует смене мышления с «Достаточно ли этот код похож на то, что я бы написал» на «Как я могу настроить этот код, чтобы он работал на меня».

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

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

Ассоциация Кризис безопасности Log4j выдвинул безопасность цепочки поставок программного обеспечения и, в частности, безопасность с открытым исходным кодом в центр внимания, с недавним Памятка Белого дома по безопасной разработке программного обеспечения и новой законопроект об улучшении безопасности с открытым исходным кодом. Благодаря этим и другим инициативам наличие любого открытого исходного кода в ваших приложениях может вскоре потребовать включения в спецификацию программного обеспечения (SBOM), что возможно только в том случае, если вы сознательно включаете конкретную зависимость. Инструменты анализа состава программного обеспечения (SCA) также полагаются на эти знания для обнаружения и пометки устаревших или уязвимых компонентов с открытым исходным кодом.

Но что, если ваше приложение включает в себя код, сгенерированный ИИ, который, в конечном итоге, получен из обучающего набора с открытым исходным кодом? Теоретически, если хотя бы одно существенное предложение идентично существующему коду и принято как есть, вы можете иметь открытый исходный код в своем программном обеспечении, но не в своем SBOM. Это может привести к проблемам с соблюдением требований, не говоря уже о возможности ответственности, если код окажется небезопасным и приведет к взлому — и SCA вам не поможет, поскольку он может найти только уязвимые зависимости, а не уязвимости в вашем собственном коде. .

Подводные камни лицензирования и атрибуции

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

Опять же, что, если в вашем приложении есть код, сгенерированный ИИ, который идентичен существующему коду с открытым исходным кодом? Если бы у вас был аудит, обнаружилось ли бы, что вы используете код без требуемого указания авторства? Или, может быть, вам нужно открыть исходный код части вашего коммерческого кода, чтобы обеспечить соответствие требованиям? Возможно, при нынешних инструментах это еще нереалистичный риск, но именно такие вопросы нам всем следует задавать сегодня, а не через 10 лет. (И чтобы внести ясность, у GitHub Copilot есть дополнительный фильтр, позволяющий блокировать предложения, соответствующие существующему коду, чтобы минимизировать риски в цепочке поставок.)

Более глубокие последствия для безопасности

Возвращаясь к безопасности, модель AI/ML настолько хороша (и плоха), насколько хороша ее обучающая выборка. Мы видели это в прошлом - например, в случаях алгоритмы распознавания лиц, показывающие расовые предубеждения из-за данных, на которых они обучались. Итак, если у нас есть исследование, показывающее, что генератор кода часто выдает предложения, не принимая во внимание безопасность, мы можем сделать вывод, что именно таким был его обучающий набор (т. е. общедоступный код). А что, если небезопасный код, сгенерированный ИИ, затем вернется в эту кодовую базу? Могут ли предложения когда-либо быть безопасными?

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

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

Следите за ИИ

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

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

Даже относительно прозрачные решения ML, такие как Copilot, уже вызывают некоторые юридические и этические вопросы, не говоря уже о проблемах безопасности. Но только представьте, что однажды какой-то новый инструмент начнет генерировать код, который работает идеально и проходит тесты безопасности, за исключением одной крошечной детали: никто не знает, как он работает. Вот тогда пришло время паниковать.