Chainguard проанализировала 52 тысячи open-source пакетов и напомнила рынку вещь, которую многие в эйфории от AI-кодинга предпочитают не замечать: безопасность open source ломается не только на известных CVE. Проблема шире: если агент или разработчик без разбора тянет зависимости из интернета, в прод попадает не обязательно вредоносный код, но вполне сомнительный софт, который трудно проверить, сопровождать и вообще объяснить службе безопасности.
Речь идет о том, что сама Chainguard называет greyware, а как пишет The New Stack, находка особенно важна на фоне моды на agentic development и vibe coding. Идея таких подходов проста: код может собирать не только инженер, но и аналитик, операционный менеджер или фаундер без глубокого технического бэкграунда, полагаясь на ИИ-агента. На демо это выглядит красиво. На практике агент столь же охотно подтянет удачную библиотеку, скрипт с полузабытым GitHub-репозиторием или пакет с неочевидным происхождением, если тот формально решает задачу.
Ключевой вывод Chainguard не в том, что open source внезапно опасен. Скорее наоборот: экосистема слишком велика, чтобы проверять ее по принципу «если ставится, значит нормально». Компания посмотрела на десятки тысяч пакетов и сфокусировалась на промежуточной зоне между откровенным malware и добросовестным, хорошо поддерживаемым проектом. Это и есть greyware: зависимости без явных признаков атаки, но с таким набором свойств, который для корпоративной среды выглядит токсично. У пакета может быть неясное происхождение, слабая поддержка, странные паттерны публикации, запутанная цепочка зависимостей или поведение, которое не тянет на инцидент, но уже требует отдельной проверки. Для платформенных команд это плохая новость: стандартный сканер уязвимостей такую историю часто не ловит, потому что у пакета может просто не быть CVE.
На этом месте история перестает быть разговором только для AppSec-команд. В последние два года рынок активно продает идею, что генерация кода ИИ снимает барьер входа в разработку. С точки зрения бизнеса в этом есть логика: быстрее прототипы, меньше рутины, шире круг людей, которые могут собирать внутренние инструменты и микросервисы. Но у этой модели есть неприятная развилка. Чем меньше человек понимает устройство экосистемы пакетов, тем выше шанс, что он оценивает зависимость по косвенным признакам: «нашлось в поиске», «агент предложил», «пример на форуме заработал». Для корпоративной разработки это почти идеальный рецепт для накопления технического долга под видом ускорения.
Chainguard, судя по акцентам материала, бьет ровно в этот разрыв между скоростью сборки и проверяемостью результата. Для cloud-native мира проблема особенно жесткая, потому что риск не заканчивается на этапе написания кода. Даже если приложение собирается и тесты зеленые, пакет остается частью исполняемой среды: живет в контейнере, тянет транзитивные зависимости, взаимодействует с рантаймом и инфраструктурой. Отсюда и неудобный, но здравый тезис: при агентной разработке верификация становится не nice to have, а обязательным слоем, причем не только на этапе коммита, но и во время выполнения. Иначе команда узнает о сомнительной зависимости тогда, когда она уже встроена в цепочку поставки.
Для русскоязычной IT-аудитории здесь несколько вполне прикладных выводов. Первый: SBOM, allowlist и внутренняя политика по зависимостям перестают быть бюрократией для крупных корпораций и становятся базовой гигиеной даже для средних команд. Второй: если компания разрешает разработку с ИИ-агентами, ей придется отдельно описывать, откуда агентам вообще можно брать код, пакеты и шаблоны. Третий: проверка известной уязвимости больше не равна проверке зависимости. Безопасность open source теперь упирается в репутацию пакета, прозрачность его сопровождения и способность команды быстро ответить на вопрос: почему именно эта библиотека попала в продукт. Для CTO и ИБ-руководителей это означает новую управленческую задачу: контролировать не только код, который пишет сотрудник, но и код, который сотруднику «посоветовал» агент.
Отдельно этот кейс неприятен для стартапов и внутренних продуктовых команд, где соблазн ускориться особенно велик. Когда дедлайн горит, а AI-ассистент уверенно предлагает готовую связку библиотек, очень хочется принять ее как есть. Но именно здесь и срабатывает ловушка greyware: проблема может не взорваться сразу, не попасть в баг-трекер и не светиться в отчете сканера. Она просто тихо въезжает в архитектуру. Потом выясняется, что пакет заброшен, лицензия спорная, происхождение мутное, а замена в проде стоит уже не пять минут, а целый спринт. В этом смысле исследование Chainguard бьет не по open source как таковому, а по ленивой модели потребления open source, которую генеративные инструменты только масштабируют.
Главный вопрос теперь не в том, будут ли команды использовать agentic development, а в том, кто в компании возьмет на себя право последнего слова перед импортом очередной зависимости. Пока рынок увлеченно снижает порог входа в разработку, безопасность open source внезапно становится не делом одного security-инженера, а общей дисциплиной продукта, платформы и разработки. И чем активнее ИИ начнет собирать код из готовых кусков, тем дороже окажется привычка брать из интернета «что-нибудь подходящее» без нормальной проверки.