Du résumé d’artefacts à la preuve vivante
Chaque version se déplace le long d’une colonne vertébrale. Chaque étape contient des preuves liées au résumé de l'artefact, et chaque étape est dans exactement un état : Manquant, Enregistré ou Signé. Après le déploiement, Watch continue de vérifier que la preuve est toujours valable.
Après la configuration initiale, vous devrez :
- 1. Votre première image numérisée avec
SBOMSoftware Bill of Materials – une liste complète de tous les packages et dépendances de votre logiciel+ analyse d'atteignabilité - 2. Une
Decision CapsuleUn ensemble de preuves signé et exportable qui scelle chaque entrée et sortie d'une décision de release pour l'audit hors ligne et la relecture déterministesignée prouvant les résultats de l'analyse - 3. Une promotion complète du développement à la préparation avec preuves
Où s'intègre Stella Ops
Stella se place entre votre CI et vos serveurs. Le CI construit les images. Stella décide si elles peuvent être promues, les déploie sur des cibles non-Kubernetes (Compose, SSH/WinRM) et exporte les preuves pour l'audit.
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 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.
La signature a lieu lors de la construction, donc la preuve ne dépend pas du CI qui l'a produite.
Quatre catégories d'entrée alimentent la colonne vertébrale. Les preuves sont signées là où elles sont produites, puis vérifiées par le plan de contrôle.
Registres · Preuves en pipeline via CLI · Sources de conseil et VEX · Secrets — Every source named, and what each one feeds →
La colonne vertébrale de la garde
Sept étapes, un résumé d'artefact. C'est la page que vous ouvrez lorsque quelqu'un demande ce qui est en cours d'exécution et pourquoi cela a été autorisé. Voir en action · 4 min
Chaque étape se trouve exactement dans l’un des trois états suivants :
MISSING
Aucune preuve n’existe pour cette étape. Elle indique MISSING jusqu’à l’arrivée d’une preuve.
RECORDED
Les preuves existent et sont liées au résumé de l'artefact, mais ne sont pas encore signées.
SIGNED
Les preuves portent une signature DSSEDead Simple Signing Envelope – un standard simple et flexible pour signer des données arbitraires avec des signatures cryptographiques et peuvent être vérifiées hors ligne.
- 1
Source
Le commit et le référentiel dont l'artefact prétend provenir, enregistrés à partir de votre pipeline – jamais déduits.
- 2
Construire
- 3
Balayage
SBOMSoftware Bill of Materials – une liste complète de tous les packages et dépendances de votre logicielet analyse de vulnérabilité liées à ce résumé exact. Un nouveau résumé signifie une nouvelle analyse; les résultats ne sont jamais reportés sur une version à partir de laquelle ils n'ont pas été créés. - 4
- 5
Décision
Le résultat de la porte et toute approbation humaine, enregistrés avec la version exacte de la politique qui l'a produit.
- 6
Déployer
Le déploiement du résumé approuvé dans un environnement nommé : ce qui a été exécuté, où et quand.
- 7
Montre
Comparaison continue des résumés en cours d'exécution avec les résumés approuvés. La dérive est détectée, pas supposée supprimée.
Évaluation des portes : risque atteignable, pas de décomptes bruts
Gates évalue les résultats signés par rapport à une politique versionnée. L’analyse ReachabilityAnalyse qui prouve si le code vulnérable est réellement appelé par votre application — filtrant les faux positifs du bruit des scanners limite le blocage aux résultats situés sur un chemin que votre code peut exécuter. Elle couvre Go, Java, C#/.NET, JavaScript et TypeScript, Python, Rust, PHP et Ruby; les résultats en dehors de ces langages restent dans l’ensemble de travail – ils ne sont pas marqués comme inaccessibles par défaut.
Sur l'écran d'exposition de démonstration : résultats 7 → blocage 1 (accessible × non corrigé). Celui-là arrête la libération. Les six autres restent visibles, un filtre plus loin.
Contexte : ~85 % des vulnérabilités critiques des conteneurs sont dans du code inactif (rapport Sysdig 2024 sur la sécurité des conteneurs).
$ stella gate evaluate --env staging --image sha256:8c1a4f…
Commandes telles qu'affichées dans la console du produit (v1.0-RC1).
Un contrôle qui n'a pas pu être exécuté est signalé comme NON ÉVALUÉ et enregistré dans le verdict. Cela n’est jamais considéré comme une réussite.
Ce qui bloque l’expédition : une exposition accessible, non corrigée et pertinente en premier lieu. La longue queue est à un filtre.
Chaque vérification échouée indique la règle qui s'est déclenchée, les preuves qu'elle a lues et la conclusion qui se cache derrière. La réponse est dans le verdict, et non dans la réexécution des scanners ou dans un fil de discussion avec l'équipe de sécurité. « Pourquoi ma libération est-elle bloquée ? » →
Si Stella Ops est injoignable, la porte bloque.
Un délai dépassé du scanner ou du moteur de politiques est traité comme un échec par conception, pas laissé passer, et aucun drapeau fail-open n'existe dans la CLI. Un artefact dont le résultat de scan est introuvable n'est pas déployé.
Publier pendant une panne est un acte délibéré et imputable, pas un contournement : une exception signée, cadrée et limitée dans le temps, rattachée à l'exploitant qui l'a prise, et configurée avant première utilisation.
Ancrages de preuve
Validez les affirmations avec des Decision Capsules, des exemples de replay et des preuves de flux de bout en bout.
Preuves associees : Preuves et audit | Specification Decision Capsule | Operations et deploiement
Déployer : résumés approuvés vers des cibles non Kubernetes
L'étape de déploiement déploie le résumé approuvé et enregistre ce qui s'est passé où. Les cibles sont les domaines que la plupart des outils de version ignorent.
- → Projets Docker Compose
- → Hôtes SSH/WinRM — sans agent par conception
- → Stratégies roulantes, canaries et bleu-vert
- → Le retour en arrière renvoie à un résumé connu dont les preuves sont déjà au dossier
- → Chaque déploiement enregistre le résumé, l'environnement et l'heure
Un rollback est un déploiement vérifié d'un digest déjà approuvé, pas une exception au processus.
Operations et deploiement · Déployer sur des serveurs sans Installation des agents
Attention : la preuve doit continuer à tenir
L'approbation est un moment précis. Après le déploiement, Watch compare chaque digest en cours d'exécution avec le digest approuvé pour ce service et cet environnement. Le déploiement reste sans agent — rien n'est installé sur vos hôtes. La surveillance est assurée par le service d'agent Stella Ops, qui lit les digests d'images réellement en cours d'exécution sur les démons Docker qu'il peut atteindre. Le service d'agent s'exécute dans votre propre installation Stella, pas sur vos hôtes, et lit via l'API Docker.
Dérive, telle que la définit le produit :
“l'exécution du résumé n'est pas un résumé approuvé/déployé (image non approuvée ou modifiée)”
Les environnements que Stella ne peut pas observer sont présentés comme non prouvés et jamais considérés comme sains.
L’unité que Watch observe est le conteneur, identifié par digest d’image — la détection de dérive couvre donc les charges conteneurisées sur vos hôtes, qu’elles tournent sur Docker via SSH, Compose ou un démon Windows.
La limite, dite clairement : ce qui tourne hors d'un conteneur est hors de la preuve de Watch. Les fichiers, services ou exécutables déployés sur un hôte nu portent une preuve de déploiement — qui a déployé quoi, quand, depuis quelle release identifiée par empreinte —, mais ils ne sont pas revérifiés en continu par empreinte d'image.
Aller plus loin
Ce à quoi Stella se connecte Vue d’ensemble de l’architecture Ce que reçoivent les auditeurs
Prêt à le voir en action ?
Voir toutes les fonctionnalités | Preuves & Audit | Documentation