Современная защита цепочки поставок, и при чём здесь хранилище артефактов разработки?

Современная защита цепочки поставок, и при чём здесь хранилище артефактов разработки?

Когда команда, которая занимается безопасностью кода, начинает строить собственное хранилище артефактов, предсказуем вопрос: а зачем еще одно? Ведь на рынке уже есть Sonatype Nexus, JFrog Artifactory, Harbor, встроенные хранилища платформ разработки, а может быть и еще кто-то.

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

Современная разработка — это не только код. Это контейнерные образы, пакеты библиотек, Helm-чарты, ML и AI-модели, скомпилированные бинарные файлы. Все, что возникает в результате сборки, тестирования и подготовки к развертыванию, принято называть артефактами. И у каждого из них должно быть место, где он хранится, версионируется, раздается потребителям и, к сожалению, пока только в идеале, проверяется на безопасность. Это место — хранилище артефактов, или менеджер репозиториев.

Долгое время выбор хранилища был вопросом сугубо инженерным: скорость работы, поддерживаемые форматы, удобство API, настройка проксирования внешних репозиториев. Но чем глубже артефакты проникают в цепочки поставки ПО, тем острее становится другой вопрос — вопрос безопасности. Масштаб хорошо иллюстрируют цифры: в 2025 году нашей командой было зарегистрировано 457 тыс. вредоносных библиотек, в 11 раз больше, чем годом ранее. Зафиксировано также 14 тыс. новых уязвимостей в открытых компонентах. При этом старые проблемы никуда не уходят, 15 тыс. пакетов экосистемы Java продолжают зависеть от уязвимой версии пресловутого log4j (уязвимость — Log4Shell). Логичным выглядит исследование Cloudsmith Artifact Management Survey 2025, которое показывает, что 56% инженерных команд уже считает главной задачей хранилища артефактов именно защиту цепочки поставки, а не удобство хранения.

Можно ли быть уверенным в том, что артефакт, который прямо сейчас разворачивается в продуктивной среде, не несет в себе уязвимость, вредоносный код или нелицензионный компонент? На этот вопрос помогает ответить SBOM (Software Bill of Materials) — перечень компонентов программного обеспечения, который позволяет понять, из чего именно собран конкретный артефакт и отследить его цепочку зависимостей и «происхождение». Практики формирования SBOM закрепляются по всему миру, от зарубежных стандартов до ГОСТ Р 56939-2024 «Защита информации. Безопасная разработка. Общие требования». И именно этот сдвиг от вопроса «что хранить» к вопросу «чему доверять» сделал тему хранения артефактов по-настоящему актуальной для всех, кто занимается безопасностью разработки.

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

 
Классика хранения артефактов

Sonatype Nexus и JFrog Artifactory — ветераны и де-факто стандарты. Именно они сформировали само понятие «универсального менеджера репозиториев»: поддержка десятков экосистем, многозадачные комбинации хранения данных, развитые механизмы репликации и масштабирования. Заслуженная зрелость и большая инсталляционная база. Для организаций, которым важна максимальная широта поддержки форматов и годами выстроенная экосистема интеграций и плагинов, эти решения по-прежнему остаются обоснованным выбором.

Но зрелость имеет обратную сторону. Обе системы — тяжелые монолиты с высокими требованиями к ресурсам. Критичные для промышленной эксплуатации возможности — HA (высокая доступность), расширенное хранение, security-функционал — закрыты за дорогими лицензиями. Кластеризация превращается в отдельный инфраструктурный проект. Обновления болезненны: меняется схема БД, формат метаданных, модель плагинов. А вот уязвимости находятся часто, что создает неприятную вилку: обновляться — больно, не обновляться — страшно. Архитектурные решения, принятые пятнадцать лет назад, становятся не только устаревшими (легаси), но и ограничением для тех, кто хочет строить современные процессы.

 
Простые хранилища артефактов

Следующая волна решений взяла на флаг идею «чем проще — тем лучше». Harbor, проект CNCF, ограничился OCI-совместимыми артефактами и предложил разумный баланс между простотой и функциональностью: kube-native архитектура, интегрированные open source сканеры образов контейнеров, механизм проверки подписей. Для cloud-native команды, живущей контейнерами — то, что нужно. Harbor — отличный пример того, как фокус на конкретном формате позволяет довести пользовательский опыт до уровня, недоступного универсальным решениям.

Но если в стеке есть Maven, npm, PyPI или что-то еще — нужно или второе хранилище, или набор упражнений для перестройки в формат OCI всех поступающих артефактов. На больших объемах неизбежно приходится бороться со сборкой мусора (garbage collection), а мажорные обновления требуют почти ручной миграции без волшебной кнопки «перенести». Это был справедливый компромисс для своего времени, но все же компромисс.

Хранилища артефактов на платформах разработки

Параллельно развивался другой подход: артефакты как бонус к платформе разработки. Встроенные хранилища GitLab, GitHub, Azure DevOps и ряда других платформ предложили единый пользовательский интерфейс (UI), общие права доступа, нативную (по умолчанию) интеграцию с CI — все в одном месте. Главная сила подобных решений — околонулевая стоимость входа, ведь команда уже живет в этой экосистеме. На российском рынке, где потребность в быстром импортозамещении в какой-то момент стала критической, хостовые экосистемные решения упали в благодатную почву: они закрывали сразу множество задач одним инструментом. Хорошим примером можно назвать решения от GitFlic или Сфера.

Но платформенная привязка — палка о двух концах. Интеграция с внешними инструментами ограничена. Поддержка пакетных менеджеров часто реализована на уровне «минимально достаточного», с огрублениями протоколов. Data layer (уровень данных) привязан к самой платформе, масштабирование — только вместе со всем сервером, обновление реджистри отдельно невозможно. По сути, вы не выбираете хранилище — вы принимаете то, что дает платформа.

Неканоничные реализации

Наконец, есть категория решений, предлагающих принципиально иную логику. Проекты вроде Dragonfly (CNCF) переосмысляют саму модель распространения артефактов: P2P-дистрибуция образов поверх основного хранилища по аналогии с торрент-сетями. Ценностное предложение для бизнеса убедительно: радикальное снижение трафика, разгрузка центрального хранилища, эффективная раздача больших образов на сотни нод. Но это меняет всю экономику и модель доверия: образ приходит не из реджистри, а от «соседа» по кластеру, отладка запросов, гуляющих по пирам, нетривиальна, а порог входа для команды высок. Существуют и другие нишевые решения — Pulp для сценариев зеркалирования в изолированных средах, Zot Registry как минималистичное OCI-хранилище с фокусом на безопасность. Каждое точно решает свою задачу, но ни одно не претендует на универсальность.

 
Назревшая потребность в эволюции хранилищ артефактов

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

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

И вот мы подходим к тому, что стало для нас в CodeScoring отправной точкой. Главный вопрос к хранилищу артефактов сегодня — это давно не «можешь ли ты хранить контейнер или ML-модель?».

Главный вопрос звучит иначе: «можешь ли ты доказать, что этот артефакт безопасен?». Существующие решения отвечают на него по-разному. Nexus подключает отдельный IQ Server, JFrog — платформу XRay, Harbor — встроенные OSS-сканеры. Платформенные решения делегируют это внешним инструментам. Кто-то закрывает вопрос широко, кто-то точечно, но почти никто — оптимально. Безопасность в них «сбоку»: отдельный сервис, отдельная интеграция, отдельная лицензия. Хранилище и безопасность существуют параллельно, а не как единое целое. Говоря о современных реалиях, нельзя не упомянуть вектор угроз, напрямую связанный с хранением артефактов. Исследование Техасского университета в Сан-Антонио (и нескольких участников из других американских университетов), в котором проводился анализ 576 000 фрагментов кода от 16 популярных LLM, показало, что в среднем около 20% рекомендуемых моделями пакетов не существует в реальных репозиториях. При этом 58% таких «выдуманных» пакетов стабильно воспроизводятся при повторных запросах. То есть это не случайный сбой, а устойчивый паттерн. Именно эта устойчивость открывает дорогу для slopsquatting-атак: злоумышленник заранее регистрирует пакет с именем, которое LLM будет рекомендовать снова и снова, превращая галлюцинацию в точку входа.

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

Современный технологический стек и инженерные практики диктуют вполне конкретные ожидания к, в первую очередь, инфраструктурному ПО: контейнерная среда, горизонтальное масштабирование, разделение compute и storage, API-first подход к управлению. В современных хранилищах артефактов есть вещи, которые нужнына этапе проектирования, например: разработка на Go, kube-native архитектура с HA доступна сразу, модульная SOA-структура, отделяемые компоненты хранения, с реляционной базой данных и S3-хранилищем. Это не уникальные фичи, это отражение того, как строится инфраструктурное ПО сегодня, когда ему не нужно тащить на себе пятнадцатилетнее легаси. Поддержка популярных пакетных менеджеров, улучшенные возможности контроля и аудита — следствие того, что продукт пишется командой, для которой безопасная разработка — не надстройка, а исходная точка.

Отдельно стоит сказать о локальной специфике. Ни одно из существующих зарубежных решений не учитывает требования российских стандартов безопасной разработки — в частности, ГОСТ Р 56939-2024 и связанных с ним практик РБПО. Для команд, которым важно соответствие этим требованиям, возможности зарубежных хранилищ заканчиваются там, где начинается отечественная нормативная база.

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