Интеграции
Свържете източниците, които правят възможни решенията за издания
Доказателствата от компилирането и сканирането изобщо не се нуждаят от конектор — CLI ги подписва в задачата за компилиране.
Четири категории източници захранват решенията за издания: регистри, доказателства от конвейера, данни от бюлетини и VEX и тайни. Всички попадат в една и съща верига за проследимост — Изходен код → Компилиране → Сканиране → Вердикт → Решение → Разгръщане → Наблюдение.
Конекторите не са защитимото предимство
Доказателства от конвейера (CLI): Тази категория умишлено не е конектор. Доказателствата от компилирането и сканирането не се нуждаят от конектор към SCM или CI, нито от входяща уеб кука: CLI работи в съществуващия ви конвейер и изпраща подписаните доказателства.
Конекторите умишлено са най-лесният за повторение слой — всеки доставчик може да възпроизведе решетка от лога. Това, което захранват, е по-трудно за копиране: доказателства, подписани при източника, проверени от платформата за управление и възпроизводими по-късно. Сравнете веригата, а не списъка с отметки.
Gate от всяка CI/CD система
Каквото и да изпълнява вашите внедрявания — Jenkins, стъпки в Octopus, GitLab CI, GitHub Actions, шел скрипт на билд машина — контролът минава през Stella по един и същи начин: добавете етап, който изпълнява CLI.
CLI се разпространява като фиксиран контейнерен образ, така че на runner-а няма какво да се инсталира. registry.stella-ops.org/stella-cli:v1.0 се изтегля анонимно — без идентификационни данни, без CI/CD променлива, само изходящ достъп до регистъра. Runner-ите без такъв достъп насочват 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:… пита дали този дайджест може да влезе в дадена среда.
Командата излиза с ненулев код, когато контролът блокира, така че етапът се проваля и конвейерът спира. Няма какво друго да се свързва: без входящ webhook, без callback URL, без мрежов път от Stella към вашата билд система.
Доказателствата пътуват навън. CLI подписва билд атестацията и я изпраща отвътре на задачата; контролният слой никога не посяга навътре, за да я вземе.
Автоматизация и агенти. CI задача, скрипт или ИИ агент, който пускате, управлява изданията през същите интерфейси като човек: удостоверява се като служебен клиент на OAuth (client credentials) и извиква API за издания (promote, deploy, rollback) или stella release approve|reject|promote|deploy|rollback. Одобренията и контролните точки по политики се оценяват от сървъра, така че към автоматизиран клиент се прилага същата политика като към човек.
stella ci init днес генерира готови файлове за конвейер за GitHub, GitLab и Gitea. Всяка друга CI система извиква същия CLI директно — командите са същите, различава се само YAML около тях.
Препоръчителен ред за настройване
- 1 Регистри — откъде идват образите и хешовете
- 2 Доказателства от конвейера (CLI) — подписват се в задачата за компилиране, не е необходим конектор
- 3 Източници на бюлетини и VEX — какво поддържа вердиктите актуални
- 4 Тайни — с какво се удостоверяват останалите интеграции
Редът, предложен от центъра Интеграции в продукта.
Четирите източника, на които се основава решение за release
Регистри
Източниците на контейнери, които Stella открива, сканира, версионира и придвижва. Хешът е идентичността, с която се обвързва всичко останало. Наблюдавайте нови хеши и изтегляйте образи за сканиране и придвижване. Digest-firstИдентификация на издание, базирана на неизменяеми хешове (SHA-256 хешове) вместо променливи тагове — байт-идентични внедрявания
Docker Hub · Harbor · AWS ECR · Google GCR / Регистър на артефакти · Azure ACR · Всеки OCIOpen Container Initiative — индустриалният стандарт за формати на контейнерни образи и регистри-съвместим регистър — Всичко, което говори OCIOpen Container Initiative — индустриалният стандарт за формати на контейнерни образи и регистри distribution спецификацията, работи.
Доказателства от конвейера чрез CLI
CLI сканира всяка компилация и подписва удостоверение за компилацията (DSSEDead Simple Signing Envelope – прост, гъвкав стандарт за подписване на произволни данни с криптографски подписи) в самата задача. Вашият конвейер изпраща доказателствата; платформата за управление не влиза в системата ви за компилиране, за да ги събира.
Източници на бюлетини и VEX
Източници на бюлетини: NVDNational Vulnerability Database – държавното хранилище на САЩ за стандартизирани данни за уязвимости + OSVOpen Source Vulnerabilities – разпределена база данни за уязвимости в проекти с отворен код + 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. Вградено хранилище за тайни: Данните за достъп до регистрите и разгръщането се съхраняват в хранилището за тайни и се подават при изпълнение. Стойностите на тайните не се появяват в доказателствата или Decision Capsules.
Източници на бюлетини и 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. TenantИзолирано работно пространство със собствени потребители, роли, политики и история на доказателствата. Тенантите споделят една инсталация; доказателствата и достъпът са разделени по тенанти, а спирането на тенант замразява целия му достъп
Ограничен обхват по замисъл: Достъпът ви е ограничен до четири неща. Широки права на оператор или одобряващ никога не са условие за изпращането на собствената ви услуга.
- Вашите услуги Виждате и актуализирате възложените ви услуги, а не цялата инфраструктура.
- Вашите хранилища Достъпът следва хранилищата, свързани с услугите ви. Хранилищата на други екипи са извън вашия обхват.
- Вашите пространства от имена за образи Кандидат-хешовете се приемат от пространствата от имена за образи, свързани с вашата услуга, а не от произволно място в регистъра.
- Вашите среди Действате само в разрешените от ролята ви среди — чрез директна актуализация или заявка за повишаване, определено за всяка среда.
Самообслужването изисква екипът по платформата да го активира за всяка среда. Когато е изключено, подавате заявка за повишаване към одобряващите. Stella показва в кои среди можете да действате; никога не разширява този набор самостоятелно.
Научете повече
Суверенитет и изолация Двигател за доказателства Цени Всички функции
Готови ли сте да свържете вашата инструментална верига?
Stella Ops работи с това, което вече имате. Започнете с един регистър и разширявайте от там.