Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
JFrog Artifactory
Контекст Универсальный менеджер артефактов и пакетов: один сервер хранит и проксирует репозитории десятков экосистем (Maven, npm, PyPI, NuGet, Go, Debian/APT, RPM/YUM, Alpine, Docker/OCI, Conan, Generic). В курсе это опорный узел двух контуров: controlled repository для OSA-входа и артефакт-репозиторий в конвейере Организации между «генератором фактов» и «сервисом аудита/вердиктов».
Для чего
Хранит, версионирует и раздаёт сборочные артефакты и зависимости через единую точку. Три типа репозиториев — local (свои артефакты), remote (прокси-кэш публичного реестра) и virtual (агрегат local+remote под одним URL) — позволяют завести весь трафик пакетных менеджеров через подконтрольный индекс, что и делает его носителем OSA-политики допуска.
Как применяют
Менеджер пакетов настраивают ходить не в публичный реестр, а в virtual-репозиторий Artifactory. Пример для npm:
# .npmrc — весь install идёт через подконтрольный индекс
registry=https://artifactory.internal/artifactory/api/npm/npm-virtual/
//artifactory.internal/artifactory/api/npm/npm-virtual/:_authToken=${ART_TOKEN}
Публикация артефакта и чтение метаданных — через REST API:
# заливка собранного бинаря в local-репозиторий
curl -H "Authorization: Bearer $ART_TOKEN" -T app-1.4.2.tar.gz \
"https://artifactory.internal/artifactory/builds-local/app/1.4.2/app-1.4.2.tar.gz"
# поиск по координатам (для расследования происхождения артефакта)
curl -H "Authorization: Bearer $ART_TOKEN" \
"https://artifactory.internal/artifactory/api/search/gavc?g=org.apache&a=commons-text"
Сам по себе Artifactory не строит SBOM и не вычисляет уязвимости — за это отвечает дополнительный модуль (Xray) или внешний сканер по содержимому репозитория.
Сильные стороны
- Один контролируемый индекс на множество экосистем — естественная точка для блокирующего OSA-режима (запрошенный пакет физически не отдаётся, если попал под block-правило).
- Богатый REST API и checksum-based storage: воспроизводимое разрешение зависимостей, дедупликация, прослеживаемость происхождения артефакта.
build-infoфиксирует, какая сборка какие зависимости и в каких версиях втянула — материал для последующего аудита состава.
Ограничения
- Базовый репозиторий «видит» проблему состава и уязвимости только с дополнительным компонентом или внешним сканером; без него это хранилище, а не SCA.
- Блокирующий OSA-режим работает, лишь когда менеджер действительно настроен ходить через virtual-репозиторий; прямой доступ в публичный реестр обходит контур.
- Не закрывает dependency confusion сам по себе — нужны резервирование внутренних имён и приоритет local над remote в virtual-репозитории.
install-скрипты пакета выполняются уже после выдачи: проксирование не отменяет--ignore-scriptsкак отдельный контроль.
Offline / on-premise
Да. Self-hosted редакция разворачивается полностью в закрытом контуре; remote-репозитории работают как офлайн-кэш единожды скачанных артефактов, дальнейшие сборки идут без выхода во внешнюю сеть. Обновление метаданных требует управляемого «окна» наружу либо ручной заливки.
Связанные темы
- Модули: М08. Защита цепочки поставки и OSA · М11. Генератор фактов и сервис вердиктов
- Практики: П17. OSA controlled repository policy · П18. OSA Proxy режимы и ограничения
- Смежные карточки: Nexus Repository · GitLab CI · Docker BuildKit