Интеграции
Свържете източниците, които правят възможни решенията за издания
Доказателствата от компилирането и сканирането изобщо не се нуждаят от конектор — 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 подписва билд атестацията и я изпраща отвътре на задачата; контролният слой никога не посяга навътре, за да я вземе.
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. 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 показва в кои среди можете да действате; никога не разширява този набор самостоятелно.
Научете повече
Суверенитет и изолация Двигател за доказателства Цени Всички функции
Готови ли сте да свържете вашата инструментална верига?
Stella Ops работи с това, което вече имате. Започнете с един регистър и разширявайте от там.