Инструменты ИИ ускоряют разработку, увеличивают объём выпускаемого кода и освобождают программистов от части рутинных операций. Узкое место возникает позже: сгенерированный код за считаные минуты добавляет в проект библиотеки и другие компоненты с открытым исходным кодом, а проверять их по-прежнему приходится людям. Скорость написания программы растёт, скорость проверки зависимостей почти не меняется.
Каждый новый пакет ставит перед службой безопасности и инженерами несколько вполне приземлённых вопросов. Есть ли в нём известные уязвимости? Допустима ли его лицензия для конкретного продукта? Поддерживается ли пакет, кто отвечает за обновления и нужен ли он в рабочей среде вообще? Добавить зависимость можно одной командой. Разобраться с её происхождением, версиями и условиями использования обычно куда дольше.
Так накапливается долг исправлений: очередь из уязвимостей и других проблем растёт быстрее, чем команда успевает их устранять. Сам по себе ИИ-код тут не главный виновник. Опасность создаёт разница между темпом появления новых зависимостей и пропускной способностью процессов проверки. Чем самостоятельнее становятся инструменты программирования, тем шире может оказаться этот разрыв.
ActiveState опросила 300 руководителей служб безопасности и инженерных подразделений из технологических компаний, финансового сектора, здравоохранения, промышленности и государственных организаций. Исследователи изучали, как предприятия управляют рисками открытого кода, появившимися из-за ИИ, и на каких участках буксуют программы исправления. Отдельно рассматривалась связь накопленного долга с проваленными аудитами, частотой взломов и потерями рабочего времени.
Сопоставление с 300 предприятиями позволяет проверить, действительно ли внутренние меры контроля поспевают за разработкой. Большой список найденных проблем ещё не говорит о зрелой защите: иногда сканеры лишь быстрее пополняют очередь, которую некому разбирать. В таком случае работа не исчезает, а переносится на поздние стадии, где обновление пакета уже способно затронуть архитектуру, тесты и сроки выпуска.
На вебинаре ActiveState «ИИ-программирование и риски открытого исходного кода» (AI Coding and Open Source Risk webinar) выступают Rebecca Banks и Moris Chen. Они разбирают, как ИИ меняет объём исправлений, и предлагают участникам сравнить собственную практику с результатами 300 корпоративных респондентов. Дата публикации исследования и проведения вебинара в представленных данных не указана.
Rebecca Banks и Moris Chen также рассматривают момент, когда техническая очередь начинает сказываться на бизнесе: аудит заканчивается замечаниями, инциденты происходят чаще, а разработчики тратят время на срочную замену зависимостей. Обсуждаются действующие модели управления пакетами и подходы, которые при внешней строгости могут породить ещё больше работы. Например, запрет без удобного механизма одобрения нередко толкает команды к обходным решениям.
Практическая задача состоит не в повторении общей формулы «ИИ создаёт риски», а в пересмотре пути зависимости через организацию. Пакету нужны понятные критерии допуска, назначенный владелец, проверка лицензии и состояния сопровождения, а найденной уязвимости — приоритет и срок устранения. Без такой цепочки автономный помощник получает возможность расширять программный стек быстрее, чем предприятие успевает понять, что именно оказалось внутри продукта.
Материалы вебинара дают данные для проверки программы управления открытым кодом: где контроль уже не справляется, как действуют другие предприятия и какие процедуры следует менять до дальнейшего роста ИИ-разработки. Смотреть стоит прежде всего на скорость закрытия проблем относительно скорости появления зависимостей. Если вторая стабильно выше первой, продуктивность разработки частично оплачивается будущими аудитами, инцидентами и часами аварийной инженерной работы.
Изображение носит иллюстративный характер
Каждый новый пакет ставит перед службой безопасности и инженерами несколько вполне приземлённых вопросов. Есть ли в нём известные уязвимости? Допустима ли его лицензия для конкретного продукта? Поддерживается ли пакет, кто отвечает за обновления и нужен ли он в рабочей среде вообще? Добавить зависимость можно одной командой. Разобраться с её происхождением, версиями и условиями использования обычно куда дольше.
Так накапливается долг исправлений: очередь из уязвимостей и других проблем растёт быстрее, чем команда успевает их устранять. Сам по себе ИИ-код тут не главный виновник. Опасность создаёт разница между темпом появления новых зависимостей и пропускной способностью процессов проверки. Чем самостоятельнее становятся инструменты программирования, тем шире может оказаться этот разрыв.
ActiveState опросила 300 руководителей служб безопасности и инженерных подразделений из технологических компаний, финансового сектора, здравоохранения, промышленности и государственных организаций. Исследователи изучали, как предприятия управляют рисками открытого кода, появившимися из-за ИИ, и на каких участках буксуют программы исправления. Отдельно рассматривалась связь накопленного долга с проваленными аудитами, частотой взломов и потерями рабочего времени.
Сопоставление с 300 предприятиями позволяет проверить, действительно ли внутренние меры контроля поспевают за разработкой. Большой список найденных проблем ещё не говорит о зрелой защите: иногда сканеры лишь быстрее пополняют очередь, которую некому разбирать. В таком случае работа не исчезает, а переносится на поздние стадии, где обновление пакета уже способно затронуть архитектуру, тесты и сроки выпуска.
На вебинаре ActiveState «ИИ-программирование и риски открытого исходного кода» (AI Coding and Open Source Risk webinar) выступают Rebecca Banks и Moris Chen. Они разбирают, как ИИ меняет объём исправлений, и предлагают участникам сравнить собственную практику с результатами 300 корпоративных респондентов. Дата публикации исследования и проведения вебинара в представленных данных не указана.
Rebecca Banks и Moris Chen также рассматривают момент, когда техническая очередь начинает сказываться на бизнесе: аудит заканчивается замечаниями, инциденты происходят чаще, а разработчики тратят время на срочную замену зависимостей. Обсуждаются действующие модели управления пакетами и подходы, которые при внешней строгости могут породить ещё больше работы. Например, запрет без удобного механизма одобрения нередко толкает команды к обходным решениям.
Практическая задача состоит не в повторении общей формулы «ИИ создаёт риски», а в пересмотре пути зависимости через организацию. Пакету нужны понятные критерии допуска, назначенный владелец, проверка лицензии и состояния сопровождения, а найденной уязвимости — приоритет и срок устранения. Без такой цепочки автономный помощник получает возможность расширять программный стек быстрее, чем предприятие успевает понять, что именно оказалось внутри продукта.
Материалы вебинара дают данные для проверки программы управления открытым кодом: где контроль уже не справляется, как действуют другие предприятия и какие процедуры следует менять до дальнейшего роста ИИ-разработки. Смотреть стоит прежде всего на скорость закрытия проблем относительно скорости появления зависимостей. Если вторая стабильно выше первой, продуктивность разработки частично оплачивается будущими аудитами, инцидентами и часами аварийной инженерной работы.
