Интеграции

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

Для сборки и сканирования доказательств вообще не требуется соединитель — CLI подписывает их внутри вашего задания сборки.

Четыре категории источников обеспечивают решения о выпуске: реестры, данные конвейера, рекомендации и данные VEX и секреты. Все они попадают в одну и ту же цепочку доказательств — Источник → Сборка → Сканирование → Вердикт → Решение → Развертывание → Watch.

Начать бесплатно Читать документацию

Разъемы – это не ров

Свидетельство конвейера (CLI): Эта категория не является разъемом — намеренно. Для создания и сканирования доказательств не требуется ни соединителя SCM, ни соединителя CI и входящего веб-перехватчика: CLI работает внутри существующего конвейера и отправляет подписанные доказательства.

Разъемы здесь являются наименее защищенным слоем по своей конструкции — любой поставщик может подобрать сетку логотипа. То, что они передают, труднее скопировать: доказательства подписаны в их источнике, проверены на уровне управления и могут быть воспроизведены позже. Сравнивайте цепочку, а не контрольный список.

Посмотрите, как доказательства перемещаются по цепочке доказательств →

Гейт из любой системы CI/CD

Что бы ни выполняло ваши развёртывания — Jenkins, шаги Octopus, GitLab CI, GitHub Actions, шелл-скрипт на сборочной машине — контроль через Stella устроен одинаково: добавьте этап, запускающий CLI.

CLI поставляется как зафиксированный образ контейнера, поэтому на раннере ничего устанавливать не нужно. registry.stella-ops.org/stella-cli:v1.0 скачивается анонимно — без учётных данных, без переменной CI/CD, достаточно исходящего доступа к реестру. Раннеры без такого доступа указывают STELLA_CLI_IMAGE на внутреннее зеркало.

Шаг во время сборки

Терминал

$ docker run --rm \
  -e STELLA_OCI_REGISTRY_USERNAME="$CI_REGISTRY_USER" \
  -e STELLA_OCI_REGISTRY_PASSWORD="$CI_JOB_TOKEN" \
  -v "$CI_PROJECT_DIR:/src:ro" \
  registry.stella-ops.org/stella-cli:v1.0 \
    sbom attach --generate --reachability --reachability-source /src \
    --image "$IMAGE_REF" --digest "$IMAGE_DIGEST" \
    --commit "$CI_COMMIT_SHA" --repo-url "$CI_PROJECT_URL" \
    --source-id "gitlab-cr/$CI_PROJECT_PATH"

Команды, как показано в консоли продукта (v1.0-RC1).

Дерево исходного кода монтируется только для чтения в /src, чтобы извлечение достижимости могло прочитать код, из которого собран образ; контейнер работает от имени пользователя без прав root. Учётные данные реестра читаются только из окружения — CLI не принимает их как аргументы, поэтому они не могут попасть в логи сборки или в список процессов.

Начните с рекомендательного режима. В конвейере, из которого взят этот пример, каждый шаг Stella заканчивается || echo … (non-fatal): сборка остаётся зелёной независимо от того, записаны ли доказательства, поэтому команда может внедрить шаг раньше, чем начнёт ему доверять. Блокировка — отдельное решение, принимаемое позже, а не условие для старта.

После того как доказательства прикреплены, более поздний этап может на них блокировать: stella gate evaluate --env staging --image sha256:… спрашивает, может ли этот дайджест попасть в среду.

Команда завершается с ненулевым кодом, когда контроль блокирует, поэтому этап падает и конвейер останавливается. Больше ничего настраивать не нужно: ни входящего вебхука, ни callback-URL, ни сетевого пути из Stella в вашу сборочную систему.

Доказательства идут только наружу. CLI подписывает аттестацию сборки и отправляет её изнутри задания; управляющий слой никогда не тянется внутрь, чтобы забрать её.

stella ci init уже сегодня создаёт готовые файлы конвейера для GitHub, GitLab и Gitea. Любая другая CI-система вызывает тот же CLI напрямую — команды те же, отличается только YAML вокруг них.

Предлагаемый порядок установки

1 Реестры — откуда берутся изображения и дайджесты
2 Свидетельство конвейера (CLI) — подписано внутри задания сборки, соединитель не требуется.
3 Консультации и источники VEX — что поддерживает актуальность вердиктов
4 Секреты — то, с помощью чего аутентифицируются другие интеграции

Порядок, предлагаемый Центром интеграции продукта.

Четыре источника, на которых основано решение о релизе

Реестры

Источники контейнера Stella обнаруживают, сканируют, создают версии и продвигают. Дайджест — это идентичность, с которой связано все остальное. Watch для новых дайджестов и изображений для сканирования и продвижения релизов. Digest-first?Идентификация релиза на основе неизменяемых хешей контента (дайджесты SHA-256) вместо изменяемых тегов — байт-идентичные развёртывания

Docker Концентратор · Гавань · АВС ЭКР · Google GCR/Реестр артефактов · Azure ACR · Любой реестр, соответствующий OCI?Open Container Initiative — отраслевой стандарт форматов образов контейнеров и реестров. — Все, что соответствует спецификации дистрибутива OCI?Open Container Initiative — отраслевой стандарт форматов образов контейнеров и реестров, работает.

Доказательство конвейера через CLI

CLI сканирует каждую сборку и подписывает аттестацию сборки (DSSE?Dead Simple Signing Envelope – простой гибкий стандарт для подписи произвольных данных криптографическими подписями) внутри задания. Ваш конвейер выталкивает доказательства; уровень управления не обращается к вашей системе сборки, чтобы собрать его.

Гейт из любой системы CI/CD ↑

Консультации и источники VEX

Информационные каналы: NVD?National Vulnerability Database – государственный репозиторий США стандартизированных данных об уязвимостях + OSV?Open Source Vulnerabilities – распределённая база данных уязвимостей для open-source-проектов + GHSA?GitHub Security Advisories – база данных уязвимостей безопасности для пакетов на GitHub · CISA?Cybersecurity and Infrastructure Security Agency – федеральное агентство США, ответственное за кибербезопасность и каталоги уязвимостей KEV?Known Exploited Vulnerabilities – каталог CISA активно эксплуатируемых уязвимостей · Национальные CERT · Фиды поставщиков. See the full source breakdown →

VEX прием: Принимайте и создайте операторы VEX?Vulnerability Exploitability eXchange – машиночитаемые утверждения о том, являются ли уязвимости реально эксплуатируемыми в вашем контексте для разрешения доверия нескольких эмитентов. OpenVEX?Открытый стандартный формат для VEX-утверждений об эксплуатируемости уязвимостей · CSAF 2.0 · Настраиваемые издатели. Настраиваемые издатели: Опубликованный поставщиком VEX?Vulnerability Exploitability eXchange – машиночитаемые утверждения о том, являются ли уязвимости реально эксплуатируемыми в вашем контексте с настраиваемыми весами доверия. SBOM и VEX →

CSAF 2.0: Common Security Advisory Framework для структурированных бюллетеней.

Секреты

Хранилища учетных данных, из которых считываются последующие интеграции. Соединители реестра и развертывания содержат секретную ссылку, а не сами учетные данные.

Встроенный магазин секретов · Хранилище ХашиКорп · Azure Key Vault · AWS Secrets Manager · HSM / PKCS#11. Встроенный магазин секретов: Учетные данные регистрации и развертывания хранятся в хранилище секретов и вводятся во время выполнения. Значения секретных данных не отображаются в доказательствах или капсулах.

Цели развертывания

Развертывание закрытых выпусков в инфраструктуре, отличной от Kubernetes.

Docker Compose · SSH (Linux/Unix) · WinRM (Windows) · AWS / Фаргейт · HashiCorp · Сценарий (.NET 10)

Цели развертывания не ограничены на каждом уровне. Уровни измеряют среду и сканирование новых дайджестов, а не целевые показатели.

The non-Kubernetes operating model Agentless SSH and WinRM deployment См. дрейф во всей инфраструктуре

Кто может входить в систему

The default setup uses local users held by Stella Ops. Passwords are hashed with Argon2id.

Коннекторы SAML, OIDC и LDAP/Active Directory поставляются подписанными вместе с платформой, а установочный бандл содержит файл конфигурации для каждого. Включение — это шаг настройки оператора, а не значение по умолчанию.

All access is tenant-scoped. A user acts inside one tenant, and roles are evaluated within that boundary. Tenant?An isolated workspace with its own users, roles, policies, and evidence history. Tenants share an installation; evidence and access are separated per tenant, and suspending a tenant freezes all of its access

Область действия определяется конструкцией: Ваш доступ ограничен четырьмя вещами. Широкие права оператора или утверждающего лица никогда не являются обязательным условием для предоставления вашей собственной услуги.

Ваши услуги Вы видите и обновляете назначенные вам службы, а не всю инфраструктуру.
Ваши репозитории Доступ следует за репозиториями, привязанными к вашим сервисам. Репозитории других команд находятся за пределами вашей компетенции.
Пространства имен ваших изображений Дайджесты-кандидаты принимаются из пространств имен изображений, привязанных к вашей службе, а не из любого места реестра.
Ваша среда Вы действуете только в тех средах, которые разрешены вашей ролью — прямой запрос на обновление или продвижение выпуска, определяемый для каждой среды.

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

Identity and roles in the technical docs →

Подробнее

Суверенность и Air-Gap Движок доказательств Цены Все возможности

Готовы подключить свою цепочку инструментов?

Stella Ops работает с тем, что у вас уже есть. Начните с одного реестра и расширяйте его.