Инструменты программирования на базе ИТ ускоряют распространение зависимостей и увеличивают связанные с ними риски вредоносного ПО

При поддержке Chainguard

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

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

«Скорость опережает управление и контроль, — говорит директор по информационной безопасности (CISO) компании Chainguard Куинси Кастро (Quincy Castro). — Когда вы можете генерировать код мгновенно, традиционный цикл запроса, проверки и утверждения создает узкие места для людей. Никто не смирится с миром, где они выполняют свою работу очень быстро, а все это простаивает из-за устаревшего, ручного, управляемого человеком процесса».

Это означает, что изменились две вещи. Агенты выбирают зависимости на основе их соответствия промпту, что может иметь мало общего с тем, насколько хорошо эта зависимость поддерживается. В то же время программы для разработчиков без профильной подготовки (citizen developer programs) передают сборку ПО в руки людей без традиционного образования в области софтверного инжиниринга, что усложняет техническую валидацию.

Почему команды безопасности никогда полностью не проверяли зависимости с открытым исходным кодом

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

«Идея о том, что небольшая команда безопасности может быть специалистом по каждому стеку технологий в компании из списка Fortune 500 и может сказать «да» или «нет», безопасно ли выпускать эту штуку в свет, звучит смехотворно, — объясняет он. — Я сомневаюсь, что большинство команд безопасности когда-либо эффективно проверяли и валидировали программные компоненты, используемые разработчиками. Именно поэтому цепочка поставок программного обеспечения стала такой лакомой целью. Если мы плохо справлялись с этим раньше, то наложение скорости и масштаба агентской разработки делает ситуацию только хуже».

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

Злоумышленники нацеливаются на малоизвестные пакеты с открытым исходным кодом

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

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

Кастро указывает на недавнюю атаку, в рамках которой массово создавались форки легитимных проектов, в них внедрялось вредоносное ПО, и они распространялись настолько широко, что разработчики принимали форк за официальный репозиторий и подтягивали вредоносные возможности в свой CI/CD-пайплайн. Но это не значит, что популярные проекты не являются мишенями: в марте злоумышленники, захватившие GitHub Actions сканера Trivy, принудительно отправили (force-push) 75 из 76 тегов версий для коммитов, содержащих стикер информации (infostealer). Затем они использовали похищенные секретные данные для публикации вредоносных npm-пакетов ниже по цепочке».

Злоумышленники также все чаще используют тайпсквоттинг (typosquatting), захват учетных записей мейнтейнеров, отравленные точки дистрибуции и «подъезд на чужих зависимостях» (dependency riding). Кастро говорит, что доверие, которым пользуются эти методы, никогда не было оправданным, учитывая, что любой человек может написать и опубликовать код с открытым исходным кодом.

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

96% CVE находятся вне топ-20 образов контейнеров

В мартовском отчете Chainguard за 2026 год «Состояние доверенного открытого исходного кода» (State of Trusted Open Source) отмечается, что 96,2% распространенных уязвимостей и рисков (CVE) находятся за пределами топ-20 образов контейнеров, а в июньском выпуске эта цифра выросла до 97%. Корпоративные программы усиления безопасности (hardening) концентрируются на небольшом наборе образов, на которые приходится оставшаяся доля.

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

Транзитивные зависимости создают слепые зоны в цепочке поставок

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

«У нас срабатывали детекты на зависимость с вредоносным ПО внутри, и выяснялось, что она не является частью образа контейнера или отсутствует в спецификации материалов (BOM), — говорит Кастро. — Затем мы отматываем пленку назад и видим, что это была зависимость транзитивной зависимости, которая кратковременно запускалась во время сборки. Было ли это реально? Да. Были ли у обычного человека, создающего это, какие-либо признаки того, что он находится в зоне риска? Абсолютно нет».

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

Сканирование уязвимостей не успевает за кодом, сгенерированным ИИ

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

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

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

Безопасный по умолчанию открытый исходный код и проверенное происхождение

Если сканирование и патчинг терпят крах при масштабировании, альтернатива заключается в том, чтобы не допустить попадания уязвимостей в сканер в первую очередь, за счет использования компонентов с открытым исходным кодом, которые поставляются уже пересобранными, с подтверждением происхождения (provenance attestations), минимальной поверхностью атаки и непрерывным обслуживанием за спиной. Преобладающая модель похожа на автомобиль, единственной системой безопасности которого являются подушки безопасности: полезно в худшем случае, но не заменяет фары, антиблокировочную систему тормозов и контроль тяги. Проверенные, безопасные по умолчанию компоненты призваны стать теми превентивными уровнями, которые снижают нагрузку уязвимостей до того, как их перехватит какой-либо шлюз. Но ни одна модель предотвращения не может полагаться на то, что удастся направить каждую команду к наиболее поддерживаемым пакетам. А финансовый аналитик, создающий внутренний инструмент «по наитию» в среде разработки с поддержкой ИИ, не имеет команды SRE или персонала по безопасности приложений, проверяющих его результат.

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

Спонсорские статьи — это контент, подготовленный компанией, которая либо платит за публикацию, либо имеет деловые отношения с VentureBeat, и они всегда четко промаркированы. Для получения дополнительной информации обращайтесь по адресу sales@venturebeat.com.