Eclipse SW360

Роль в линейке лицензионных инструментов SW360 — это каталог компонентов и портфель обязательств на уровне всей Организации, а не сканер. ScanCode, ORT и FOSSology производят лицензионные находки и заключения по одному проекту; SW360 их собирает, хранит и связывает с проектами, чтобы один раз разобранный компонент переиспользовался во всех релизах.

Для чего

Веб-платформа управления каталогом open-source компонентов и их лицензионными обязательствами в масштабе портфеля. Хранит компоненты и их версии (releases), связывает их с проектами, прикрепляет к каждому release результаты clearing-а (вердикты, тексты лицензий, обязательства при распространении) и показывает, какой компонент в каких продуктах используется. Решает задачу «однократного разбора»: разобранный компонент не пересматривается заново в каждом проекте.

Как применяют

Собственного сканер-CLI у SW360 нет — это сервер плюс REST API (есть отдельная сторонняя командная обвязка для скриптинга, но не для сканирования). Развёртывается контейнерами, интеграции и автоматизация идут через /resource/api:

# создать компонент через REST (после OAuth2-аутентификации)
curl -s -X POST "https://sw360.local/resource/api/components" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"somelib","componentType":"OSS","categories":["library"]}'

Типичный поток данных: ORT/FOSSology выгружают результат clearing-а, а SW360 его принимает — есть штатные коннекторы (ORT-экспортёр в SW360, fossology-агент). Загрузка release обычно сопровождается SBOM в SPDX/CycloneDX, из которого платформа разворачивает компоненты и привязывает к ним лицензионные обязательства. На выходе SW360 отдаёт по проекту сводку лицензий и документ обязательств (license obligations / disclosure).

Сильные стороны

• Портфельный взгляд: видно, какой компонент и какая версия используются в каких проектах Организации — основа для оценки охвата при новой уязвимости или проблемной лицензии.
• Однократный clearing переиспользуется: вердикт по компоненту, внесённый один раз, применяется ко всем release, где он встречается.
• Трекинг обязательств: к каждой лицензии привязаны требования при распространении (attribution, disclosure), формируется итоговый документ обязательств для поставки.
• Интегрируется с остальной линейкой: принимает выгрузки ORT и FOSSology, импортирует SBOM в SPDX/CycloneDX — служит хранилищем поверх сканеров.

Ограничения

• Сам ничего не сканирует: SW360 не находит лицензии и не выносит машинных вердиктов — он зависит от ScanCode/ORT/FOSSology как источников данных.
• Тяжёлая платформа: несколько сервисов (бэкенд, хранилище, поиск, аутентификация), требует развёртывания и сопровождения — это инфраструктура, а не утилита.
• Ценность пропорциональна дисциплине наполнения: пустой или нерегулярно обновляемый каталог не даёт портфельного эффекта.
• Качество данных наследуется от источников: ошибки и NOASSERTION из импортированных SBOM попадают в каталог как есть.

Offline / on-premise

Предназначен для on-premise развёртывания в периметре Организации. Все сервисы (каталог, хранилище, REST API) работают в закрытом контуре; внешний доступ не требуется для основной работы — обмен данными идёт с внутренними источниками (выгрузки ORT/FOSSology, импорт SBOM). Это делает SW360 удобным центральным реестром компонентов для среды без выхода в интернет.

Связанные темы

• Модули: М07 Лицензионная чистота и юридический workflow · М10 Много исполнителей и корпоративная модель продукта
• Практики: П27. Юридическое заключение и реестр лицензий · П28. Поставка от нескольких исполнителей · П12. ORT и license policy
• Смежные карточки: OSS Review Toolkit · FOSSology · ScanCode Toolkit · OWASP Dependency-Track · SPDX · CycloneDX