#Блокировать вредоносные компоненты через OSA Proxy

#Контекст

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

OSA Proxy — это прокси-сервис CodeScoring, который перехватывает запросы пакетных менеджеров к удалённым репозиториям, проверяет компоненты и при необходимости блокирует их. В этом сценарии он разворачивается перед JFrog Artifactory, чтобы внутренний PyPI-репозиторий получал только те пакеты, которые прошли проверку по политикам безопасности.

#Что получится

После прохождения сценария:

• OSA Proxy будет развернут и настроен для PyPI в режиме strict_wait;
• JFrog Artifactory начнет получать пакеты через OSA Proxy, а не напрямую из внешнего источника;
• блокирующая политика на этапе proxy будет останавливать вредоносные компоненты по условию Зависимость опасна;
• результат проверки можно будет увидеть в разделе OSA -> Запросы.

#Требования

Перед началом убедитесь, что есть:

• хост или стенд, на котором можно развернуть OSA Proxy;
• доступ к Docker или Kubernetes и образу OSA Proxy для выбранного способа установки;
• доступ к osa-proxy.yml OSA Proxy и возможность перезапустить сервис после изменения конфигурации;
• JFrog Artifactory с удалённым PyPI-репозиторием, который можно перенастроить;
• лицензия CodeScoring, в которой включен модуль OSA;
• доступ в CodeScoring с правами на создание политик и просмотр данных OSA;
• тестовый пакетный поток, на котором можно проверить работу схемы до её включения для всех команд.

#Шаги

#Шаг 1. Разверните OSA Proxy

Если сервис ещё не установлен, сначала нужно поднять его в отдельном окружении. Для первой проверки достаточно варианта с Docker.

docker run -d \
  --name osa-proxy \
  -p 8080:8080 \
  -e OSA_PROXY_CONFIG_PATH=/etc/osa-proxy/osa-proxy.yml \
  -v /path/to/osa-proxy.yml:/etc/osa-proxy/osa-proxy.yml:ro \
  <registry-url>/osa-proxy:<tag>

Если используется Kubernetes, удобнее сразу развернуть сервис через Helm Chart. Оба варианта установки описаны в документации по развертыванию OSA Proxy.

После установки сервис должен быть доступен по своему URL и готов к загрузке конфигурации.

#Шаг 2. Настройте OSA Proxy для PyPI и включите режим strict_wait

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

codescoring:
  url: https://codescoring.example.com
  token: "<token>"
  work-mode: strict_wait
  osa-proxy-url: https://osa-proxy.example.com
  enable-status-line: true
  block-on-codescoring-errors: true
  legacy-judge: false
  stage: proxy
  block-status-code: 403

pypi:
  enabled: true
  repository:
    - name: pypi
      registry: https://pypi.org
      packages-registry: https://files.pythonhosted.org
      scan-manifest: true
      remove-blocked-versions: true
      scan-package: true
      work-mode: strict_wait

Что важно в этой конфигурации:

• work-mode: strict_wait запрещает загрузку компонентов до завершения проверки и применения политик;
• osa-proxy-url задаёт внешний адрес OSA Proxy, который используется при формировании ссылок и ответов;
• scan-manifest: true позволяет убирать запрещённые версии из ответа Simple API;
• scan-package: true включает проверку архивов пакетов;
• enable-status-line: true помогает быстрее понимать причину блокировки при диагностике;

Если OSA Proxy подключается к CodeScoring версии ниже 2026.20.0, укажите legacy-judge: true. В версиях до 2026.20.0 используется legacy API Judge, а OSA Proxy по умолчанию работает с текущим API Judge.

После сохранения osa-proxy.yml перезапустите OSA Proxy.

#Шаг 3. Поставьте OSA Proxy перед JFrog Artifactory

Теперь нужно сделать так, чтобы удалённый PyPI-репозиторий в JFrog Artifactory больше не обращался напрямую во внешний источник и получал пакеты только через OSA Proxy.

1. Откройте в JFrog Artifactory раздел Administration -> Repositories -> Remote.

2. Найдите удалённый PyPI-репозиторий, через который команды получают внешние Python-пакеты.

3. В поле URL укажите адрес OSA Proxy вместо прямого адреса PyPI.

4. Если удалённый репозиторий в JFrog Artifactory обращается напрямую во внешний PyPI, передайте OSA Proxy контекст внутреннего репозитория через Base64-параметры и используйте URL такого вида:

   https://osa-proxy.example.com/pypi/eyJyZXBvTWFuYWdlckhvc3QiOiJodHRwczovL2pmcm9nLmV4YW1wbGUuY29tL2FydGlmYWN0b3J5L2FwaS9weXBpL3B5cGktcmVtb3RlIiwicmVwb05hbWUiOiJweXBpLXJlbW90ZSJ9

   В этом примере в строке Base64 закодирован такой JSON:

   {"repoManagerHost":"https://jfrog.example.com/artifactory/api/pypi/pypi-remote","repoName":"pypi-remote"}

   OSA Proxy использует эти параметры, чтобы понять, к какому внутреннему репозиторию относится запрос и какие политики к нему применять.

5. Если Artifactory требует URL именно до Simple API, используйте тот же Base64-префикс и добавьте /simple в конце:

   https://osa-proxy.example.com/pypi/eyJyZXBvTWFuYWdlckhvc3QiOiJodHRwczovL2pmcm9nLmV4YW1wbGUuY29tL2FydGlmYWN0b3J5L2FwaS9weXBpL3B5cGktcmVtb3RlIiwicmVwb05hbWUiOiJweXBpLXJlbW90ZSJ9/simple

6. Сохраните изменения.

После этого новые запросы к внешнему PyPI начнут проходить через OSA Proxy.

#Шаг 4. Создайте блокирующую политику для вредоносных компонентов

Теперь нужно задать правило, которое будет срабатывать на этапе proxy и запрещать компонент, если он попадает под критерий Зависимость опасна.

1. Перейдите в Настройки -> Политики.
2. Нажмите Создать.
3. Заполните основные поля:
   • Название — например, Опасная зависимость на этапе proxy;
   • Этапы — proxy;
   • Компоненты OSA — Пакеты;
   • Активно — включите;
   • Блокер — включите.
4. Если правило должно действовать только для одного канала поставки, выберите нужный репозиторий. Если защита нужна для всех прокси-репозиториев, оставьте это поле пустым.
5. Добавьте условие:
   • Зависимость опасна.
6. Нажмите Создать.

После сохранения OSA Proxy сможет применять это правило к новым запросам на получение пакетов.

#Шаг 5. Проверьте, что клиент больше не видит запрещённые версии

В этой проверке удобнее смотреть не на установку конкретного пакета, а на то, какой ответ получает клиент от индекса пакетов после фильтрации версий.

В этом примере клиент запрашивает список доступных версий requests через OSA Proxy и получает уже отфильтрованный ответ Simple API. Если опасной версии нет в ответе, пакетный менеджер не сможет выбрать её для установки.

#Шаг 6. Проверьте результат в OSA -> Запросы

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

1. Перейдите в раздел OSA -> Запросы.
2. Откройте вкладку Пакеты.
3. Найдите запрос, выполненный через пилотный PyPI-репозиторий.
4. Проверьте, что в списке видны:
   • название пакета;
   • режим работы;
   • статус блокировки;
   • дата запроса;
   • инициатор запроса.

После этого уже можно проверить не только поведение клиента, но и то, что событие сохранилось в самой платформе.

#Результат

Сценарий можно считать завершённым, если:

• OSA Proxy развернут и работает в режиме strict_wait для PyPI-источника;
• JFrog Artifactory получает пакеты через OSA Proxy;
• в CodeScoring создана активная блокирующая политика на этапе proxy с условием Зависимость опасна;
• клиент получает отфильтрованный ответ индекса, а в OSA -> Запросы видно зафиксированный запрос и его статус.

После этого вредоносные и запрещённые компоненты можно останавливать ещё до того, как они окажутся во внутреннем репозитории и станут доступны командам разработки.

#Что дальше

• разобрать детали запросов и статусы блокировки в OSA;
• уточнить режимы работы и параметры блокировки OSA Proxy;
• масштабировать схему на другие пакетные менеджеры.