Intégrations
Connectez les sources qui rendent les décisions de publication possibles
La création et l'analyse des preuves ne nécessitent aucun connecteur : la CLI les signe dans votre tâche de génération.
Quatre catégories de sources alimentent les décisions de publication : les registres, les preuves du pipeline, les données consultatives et VEX, et les secrets. Tous atterrissent sur la même colonne vertébrale de garde - Source → Construire → Analyse → Verdict → Décision → Déployer → Regarder.
Les connecteurs ne sont pas le fossé
Preuves en cours (CLI): Cette catégorie n’est pas un connecteur – délibérément. La création et l'analyse de preuves ne nécessitent aucun connecteur SCM, aucun connecteur CI et aucun webhook entrant : la CLI s'exécute à l'intérieur de votre pipeline existant et extrait les preuves signées.
De par leur conception, les connecteurs constituent ici la couche la moins défendable : n'importe quel fournisseur peut faire correspondre une grille de logos. Ce qu’ils nourrissent est plus difficile à copier : des preuves signées à la source, vérifiées par le plan de contrôle et rejouables ultérieurement. Comparez la chaîne, pas la liste de contrôle.
Découvrez comment les preuves se déplacent dans la colonne vertébrale →
Contrôlez depuis n'importe quel système CI/CD
Quel que soit l'outil qui exécute vos déploiements — Jenkins, étapes Octopus, GitLab CI, GitHub Actions, un script shell sur une machine de build — le contrôle passe par Stella de la même façon : ajoutez une étape qui exécute la CLI.
La CLI est livrée sous forme d'image conteneur épinglée : rien à installer sur le runner. registry.stella-ops.org/stella-cli:v1.0 se récupère anonymement — pas d'identifiants, pas de variable CI/CD, seulement un accès sortant vers le registre. Les runners privés de cet accès pointent STELLA_CLI_IMAGE vers un miroir interne.
$ 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"
Commandes telles qu'affichées dans la console du produit (v1.0-RC1).
L'arborescence source est montée en lecture seule sur /src afin que l'extracteur d'atteignabilité puisse lire le code à l'origine de l'image ; le conteneur s'exécute sous un utilisateur non root. Les identifiants du registre sont lus uniquement depuis l'environnement — la CLI les refuse en argument, ils ne peuvent donc pas fuiter dans les journaux de build ni dans la liste des processus.
Commencez en mode consultatif. Dans le pipeline dont provient cet exemple, chaque étape Stella se termine par || echo … (non-fatal) : le build reste vert que les preuves aboutissent ou non, si bien qu'une équipe peut adopter l'étape avant de lui faire confiance. Le blocage est une décision distincte, prise plus tard — pas un préalable au démarrage.
Une fois les preuves rattachées, une étape ultérieure peut bloquer dessus : stella gate evaluate --env staging --image sha256:… demande si ce digest peut entrer dans un environnement.
La commande se termine avec un code de sortie non nul lorsque le contrôle bloque : l'étape échoue et le pipeline s'arrête. Il n'y a rien d'autre à câbler — aucun webhook entrant, aucune URL de rappel, aucun chemin réseau de Stella vers votre système de build.
Les preuves circulent vers l'extérieur. La CLI signe l'attestation de build et la pousse depuis l'intérieur du job ; le plan de contrôle ne vient jamais les chercher.
stella ci init génère aujourd'hui des fichiers de pipeline prêts à l'emploi pour GitHub, GitLab et Gitea. Tout autre système de CI appelle directement la même CLI : les commandes sont identiques, seul le YAML autour change.
Ordre d'installation suggéré
- 1 Registres – d'où proviennent les images et les résumés
- 2 Preuve de pipeline (CLI) : signée dans la tâche de build, aucun connecteur n'est nécessaire
- 3 Sources consultatives et VEX : ce qui maintient les verdicts à jour
- 4 Secrets – ce avec quoi les autres intégrations s'authentifient
L’ordre suggéré par le hub d’intégrations du produit.
Les quatre sources sur lesquelles repose une décision de release
Registres
Les sources du conteneur que Stella découvre, analyse, versionne et promeut. Le résumé est l’identité à laquelle tout le reste est lié. Surveillez les nouveaux digests et extrayez des images pour les numériser et promotion. Digest-firstIdentité de release basée sur des hashes de contenu immuables (digests SHA-256) plutôt que des tags modifiables — garantissant des déploiements identiques octet par octet
Docker Hub · Port · AWS ECR · Google GCR/Artifact Registry · Azure ACR · Tout registre conforme à OCIOpen Container Initiative — le standard industriel pour les formats d'images de conteneurs et les registres — Tout ce qui parle de la spécification de distribution OCIOpen Container Initiative — le standard industriel pour les formats d'images de conteneurs et les registres fonctionne.
Preuves en pipeline via CLI
La CLI analyse chaque build et signe une attestation de build (DSSEDead Simple Signing Envelope – un standard simple et flexible pour signer des données arbitraires avec des signatures cryptographiques) à l'intérieur du travail. Votre pipeline fait sortir les preuves; le plan de contrôle n'atteint pas votre système de construction pour le collecter.
Sources de conseil et VEX
Flux de conseils: NVDNational Vulnerability Database – le référentiel du gouvernement américain de données de vulnérabilités + OSVOpen Source Vulnerabilities – une base de données distribuée de vulnérabilités pour les projets open source + GHSAGitHub Security Advisories – base de données de vulnérabilités de sécurité pour les packages sur GitHub · CISACybersecurity and Infrastructure Security Agency – agence fédérale américaine responsable de la cybersécurité et des catalogues de vulnérabilités KEVKnown Exploited Vulnerabilities – catalogue de CISA des vulnérabilités activement exploitées · CERTsComputer Emergency Response Teams – organisations régionales de cybersécurité publiant des avis de vulnérabilités nationaux · Flux des fournisseurs. See the full source breakdown →
Ingestion de VEX: Ingérer et produire des instructions VEXVulnerability Exploitability eXchange – déclarations lisibles par machine indiquant si les vulnérabilités sont réellement exploitables dans votre contexte pour la confiance multi-émetteurs résolution. OpenVEXUn format standard ouvert pour les déclarations VEX sur l'exploitabilité des vulnérabilités · CSAF 2.0 · Émetteurs personnalisés. Émetteurs personnalisés: VEXVulnerability Exploitability eXchange – déclarations lisibles par machine indiquant si les vulnérabilités sont réellement exploitables dans votre contexte publié par le fournisseur avec des poids de confiance configurables. SBOM et VEX →
CSAF 2.0: Cadre consultatif de sécurité commun pour les avis structurés.
Secrets
Magasins d’informations d’identification à partir desquels les intégrations en aval lisent. Les connecteurs de registre et de déploiement contiennent une référence secrète, jamais les informations d'identification elles-mêmes.
Magasin de secrets intégré · HashiCorp Vault · Azure Key Vault · AWS Secrets Manager · HSM / PKCS#11. Magasin de secrets intégré: Les informations d'identification du registre et du déploiement se trouvent dans le magasin de secrets et sont injectées au moment de l'exécution. Les valeurs secrètes n’apparaissent ni dans les preuves ni dans les capsules.
Sources de conseil et VEX
Les sources consultatives actives 38 nourrissent l'évaluation des vulnérabilités : le décompte est en direct sur l'écran d'état du flux du produit. La fraîcheur du flux entraîne une réévaluation : lorsqu'une source est mise à jour, les verdicts concernés sont réévalués au lieu de s'appuyer sur des données obsolètes.
Les déclarations VEX contradictoires sont résolues via un réseau documenté à sept états, et la résolution elle-même est enregistrée comme preuve.
Cibles de déploiement
Déployez des versions fermées sur une infrastructure non-Kubernetes.
Docker Compose · SSH (Linux/Unix) · WinRM (Windows) · AWS / Fargate · HashiCorp · Scripté (.NET 10)
Les cibles de déploiement sont illimitées à chaque niveau. Environnements de mesure par niveaux et analyses de nouveaux résumés : jamais de cibles.
The non-Kubernetes operating model Agentless SSH and WinRM deployment Voir la dérive sur tout le domaine
Qui peut se connecter
The default setup uses local users held by Stella Ops. Passwords are hashed with Argon2id.
Les connecteurs SAML, OIDC et LDAP/Active Directory sont livrés signés avec la plateforme, et le bundle d'installation contient un fichier de configuration pour chacun. L'activation est une étape de configuration de l'exploitant, pas un défaut.
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
Portée par construction: Votre accès est limité à quatre éléments. Des droits étendus d’opérateur ou d’approbateur ne sont jamais une condition préalable à l’expédition de votre propre service.
- Vos prestations Vous voyez et mettez à jour les services qui vous sont attribués, et non l'ensemble du patrimoine.
- Vos référentiels L'accès suit les référentiels liés à vos services. Les référentiels d'autres équipes sont hors de votre portée.
- Vos espaces de noms d'images Les résumés de candidats sont acceptés à partir des espaces de noms d’images liés à votre service, et non à partir de n’importe où dans le registre.
- Vos environnements Vous agissez uniquement dans les environnements que votre rôle permet – mise à jour directe ou demande de promotion, décidée par environnement.
Le libre-service nécessite que votre équipe de plateforme l'active pour chaque environnement. Là où il est erroné, votre chemin est une demande de promotion adressée aux approbateurs. Stella montre quels environnements vous pouvez toucher; il n’élargit jamais cet ensemble de lui-même.
Aller plus loin
Souveraineté et air-gap Moteur de preuves Tarifs Toutes les fonctionnalités
Prêt à connecter votre chaîne d'outils ?
Stella Ops fonctionne avec ce que vous avez déjà. Commencez avec un seul registre et développez-le à partir de là.