Інтеграції
З'єднайте джерела, які роблять можливими рішення про випуск
Для створення та сканування доказів взагалі не потрібен зв'язок — CLI підписує це всередині вашої будівельної роботи.
Чотири категорії джерел формують рішення щодо релізу: реєстри, докази з конвеєрів, дані рекомендацій і VEX, а також секрети. Усі вони потрапляють на одну магістраль збереження доказів — Source → Build → Scan → Verdict → Decision → Deploy → 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 Ops відкриває, сканує, розкриває версії та просуває. Дайджест — це ідентичність, до якої пов'язано все інше. Слідкуйте за новими хешами та фіксуйте образи для сканування і просування. Digest-firstІдентифікація релізу на основі незмінних хешів контенту (дайджести SHA-256) замість змінних тегів — байт-ідентичні розгортання
Docker Hub · Гавань · AWS ECR · Google GCR / Реєстр артефактів · Azure ACR · Будь-який реєстр, сумісний із OCIOpen Container Initiative — галузевий стандарт форматів образів контейнерів та реєстрів — Працює все, що відповідає специфікації розповсюдження OCIOpen Container Initiative — галузевий стандарт форматів образів контейнерів та реєстрів.
Докази з конвеєра через CLI
CLI сканує кожну збірку і підписує підтвердження збірки (DSSEDead Simple Signing Envelope – простий гнучкий стандарт для підпису довільних даних криптографічними підписами) всередині роботи. Ваш конвеєр витісняє докази; Площина керування не заходить у вашу систему побудови, щоб зібрати його.
Рекомендації та VEX джерела
Інформаційні потоки: NVDNational Vulnerability Database – державний репозиторій США стандартизованих даних про вразливості + OSVOpen Source Vulnerabilities – розподілена база даних вразливостей для open-source-проєктів + GHSAGitHub Security Advisories – база даних вразливостей безпеки для пакетів на GitHub · CISACybersecurity and Infrastructure Security Agency – федеральне агентство США, відповідальне за кібербезпеку та каталоги вразливостей KEVKnown Exploited Vulnerabilities – каталог CISA активно експлуатованих вразливостей · Національні CERT · Постачальник корми. See the full source breakdown →
VEX прийом: Приймайте та створюйте оператори VEXVulnerability Exploitability eXchange – машинозчитувані твердження про те, чи є вразливості реально експлуатованими у вашому контексті для визначення довіри кількох емітентів. OpenVEXВідкритий стандартний формат для VEX-тверджень щодо експлуатованості вразливостей · CSAF 2.0 · Власні емітенти. Власні емітенти: Опублікований постачальником VEXVulnerability Exploitability eXchange – машинозчитувані твердження про те, чи є вразливості реально експлуатованими у вашому контексті з настроюваними вагами довіри. SBOM і VEX →
CSAF 2.0: Common Security Advisory Framework для структурованих рекомендацій.
Таємниці
Облікові дані зберігаються, з яких інтеграції читаються далі. Конектори реєстру та розгортання мають секретне посилання — ніколи саму облікову інформацію.
Вбудований магазин секретів · HashiCorp Vault · Azure Key Vault · AWS Secrets Manager · HSM / PKCS#11. Вбудований магазин секретів: Облікові дані реєстру та розгортання знаходяться у сховищі секретів і вводяться під час виконання. Секретні значення не з'являються у доказах чи капсулах.
Консультації та VEX джерела
38 активних джерел рекомендації оцінюють вразливість каналів — підрахунок відображається на екрані статусу стрічки продукту. Свіжість потоку стимулює переоцінку: коли джерело оновлюється, змінені вердикти переоцінюються, а не залишаються на застарілих даних.
Суперечливі VEX твердження вирішуються через задокументовану решітку із сімома станами, а сама резолюція фіксується як доказ.
Цілі розгортання
Розгортайте закриті випуски в інфраструктурі, яка не відповідає Kubernetes.
Docker Compose · SSH (Linux/Unix) · WinRM (Windows) · AWS / Fargate · 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. TenantAn 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 Ops показує, до яких середовищ можна торкатися; вона сама по собі ніколи не розширює цей сет.
Детальніше
Готові підключити свій інструментарій?
Stella Ops працює з тим, що у вас уже є. Почніть з єдиного реєстру та розширюйте його звідти.