Questions fréquemment posées

Non, et c'est voulu, pas une limite. Docker Compose, Swarm, les hôtes SSH/WinRM et les cibles scriptées sont pris en charge à part entière — ce ne sont pas des solutions de repli pour ceux qui n'ont pas encore adopté Kubernetes.

Cibles prises en charge : projets Docker Compose, hôtes SSH/WinRM. Les déploiements SSH/WinRM sont sans agent — l'image Docker fait le travail.

L'inverse vaut aussi : si tout ce que vous exploitez tourne sur Kubernetes, Stella Ops n'est pas votre outil. Il est conçu pour l'autre moitié du parc — VM, projets Compose, serveurs classiques — et la plupart des équipes exploitent les deux.

Elle est affichée comme Missing. Ni considérée comme réussie, ni présumée saine, ni ignorée en silence.

Chaque étape de la chaîne de traçabilité porte l'un des trois états — Missing, Recorded ou Signed. Une porte qui ne trouve pas la preuve dont elle a besoin ne se rabat pas sur un succès ; NOT EVALUATED n'est jamais compté comme un succès. La plupart des outils traitent l'absence de données comme l'absence de problème. C'est exactement l'inverse ici, et c'est ce qui donne de la valeur au reste des preuves.

Oui. La capsule d'exemple est une véritable archive signée que vous pouvez vérifier avec des outils standard — cosign verify-blob et sha256sum, sans Stella Ops nulle part.

Ce téléchargement est un échantillon expurgé, signé avec une clé de démonstration ; il n'apporte donc aucune confiance au-delà de lui-même. stella evidence card verify et le rejeu déterministe nécessitent une installation et une capsule exportée par le produit — ils échoueront sur l'échantillon.

Oui, et hors ligne. Un verdict se rejoue de manière déterministe à partir des entrées figées qui l'ont produit : le même SBOM, le même instantané d'avis, la même version de politique.

C'est la différence entre un outil qui vous donne une réponse et un outil qu'on peut amener à montrer son raisonnement des mois plus tard, sur une machine sans réseau, devant quelqu'un qui ne vous fait pas confiance.

Après le déploiement, Stella continue de surveiller. Watch est la dernière étape de la chaîne de traçabilité (Source → Build → Scan → Verdict → Decision → Deploy → Watch) : elle compare le digest réellement exécuté dans chaque environnement avec le digest approuvé pour celui-ci.

Lorsqu'ils diffèrent, le service est signalé : le digest en cours d'exécution n'est pas un digest approuvé/déployé (image non approuvée ou modifiée). Vous voyez exactement quel service, dans quel environnement, s'est écarté de son état approuvé.

Un service pour lequel Watch n’a aucune preuve indique Missing — il n’est jamais affiché comme conforme au seul motif que rien n’aurait changé.

Voir la vue Estate →

Oui, et c'est le produit qui l'impose, pas votre réseau. Le mode scellé (EgressPolicyMode.Sealed) bloque les flux sortants ; stella offline import --bundle importe un kit signé ; stella evidence verify-offline contrôle les sommes de contrôle, le manifeste, la liaison DSSE et la couverture des tuiles Rekor sans aucun accès réseau, et échoue en mode fermé à la moindre altération.

L'Offline Kit regroupe les flux de vulnérabilités, les images de conteneurs et les données de provenance. Vous obtenez des résultats de scan identiques en ligne ou dans un réseau souverain.

Voir l'Offline Kit →

Les graphes d'appels sont construits par le pipeline de scan pour neuf langages : avec une précision de compilateur pour Go, Java et .NET, et à partir du texte source pour Python, JavaScript, TypeScript, Rust, PHP et Ruby. Chaque arête porte le niveau qui l'a produite.

Le cas plus restreint compte davantage : construire un graphe d'appels à partir d'une arborescence de sources dans la CLI prend en charge uniquement Go et Rust. Tout le reste arrive sous forme de graphe pré-extrait depuis le pipeline. Les résultats dans des langages non couverts ne sont pas écartés en silence — ils restent dans l'ensemble de travail comme inconnues, notées plutôt qu'ignorées.

L'enregistrement de la cible ne contient jamais le secret — seulement une référence vers lui. Le secret lui-même est scellé en AES-256-GCM sous une clé dérivée par locataire, et le chiffrement est lié au locataire, au propriétaire et à l'identité de l'identifiant, de sorte que le chiffré d'une ligne ne peut pas être rejoué comme celui d'une autre. L'enregistrement complet de la connexion cible est ensuite scellé à nouveau dans son propre domaine cryptographique avant d'atteindre la base de données.

C'est vous qui fournissez la clé maîtresse ; nous n'en générons jamais. Elle provient d'une variable d'environnement, d'un fichier monté dont les permissions sont vérifiées, de HashiCorp Vault ou OpenBao, ou d'un HSM. Si aucun stockage durable n'est configuré, chaque scellement et chaque résolution échouent au lieu de retomber silencieusement en mémoire.

Le cloisonnement et le renouvellement sont imposés, pas conseillés : chaque recherche est filtrée par locataire, si bien qu'une lecture inter-locataires ne renvoie rien et ne révèle même pas l'existence d'un identifiant. Le renouvellement garde le secret précédent résoluble pendant une fenêtre de grâce puis échoue en fermeture, et une révocation efface le chiffré stocké afin qu'une compromission ultérieure de clé ne puisse pas le récupérer.

Une release soumise au contrôle est bloquée, pas laissée passer. Si le scanner ou le moteur de politique est injoignable, le contrôle traite le dépassement de délai comme un échec, par conception — les commentaires du code le disent mot pour mot, et aucun indicateur fail-open n'existe dans la CLI. Idem au déploiement : un artefact dont le résultat de scan est irrécupérable ne se déploie pas.

Livrer pendant une panne est un acte délibéré et imputable, pas un contournement. Une exception de contrôle exige une permission accordée à personne par défaut, une justification écrite, une reconnaissance explicite du risque, une échéance entre un et 365 jours — les exceptions sans terme sont refusées —, une signature de l'opérateur qui en assume la responsabilité, et une ré-authentification dans les cinq dernières minutes. Elle est consignée sur la release. À noter : elle doit être configurée au préalable — sur une installation non modifiée, le chemin de signature n'est pas câblé, la demande est donc refusée jusqu'à l'enrôlement d'une clé opérateur.

Le contrôle n'a pas besoin de toute la plateforme. Une décision de déploiement dépend d'une dizaine de services — base de données, orchestrateur de release, scanner, moteur de politique, identité et passerelle — et non de toute la suite ; le scellement des preuves, les notifications et l'audit de la chronologie sont hors du chemin de décision.

Le déploiement sur une VM nue est pris en charge à part entière : via SSH, WinRM ou Ansible, Stella Ops peut déposer un fichier, redémarrer un service ou exécuter sur l'hôte un exécutable fourni par l'opérateur, et il capture la commande, sa sortie et son code de retour comme preuve — sans conteneur.

Le Watch continu est plus étroit, et il faut le dire précisément. Watch et l'atteignabilité observent des conteneurs en cours d'exécution par digest d'image — c'est ainsi que la détection de dérive sait que l'artefact en cours correspond toujours à celui approuvé. Un hôte dont il ne peut lire aucun conteneur est indiqué comme non observé, jamais supposé sain. Un processus brut sur un hôte sans Docker est donc déployé et son exécution enregistrée, mais il n'est pas surveillé en continu pour la dérive comme l'est une charge conteneurisée. « Serveurs classiques » désigne des serveurs exécutant des conteneurs hors Kubernetes — pas des processus non conteneurisés quelconques.

Non. Un opérateur autorisé la débloque lui-même. Vous levez une exception de politique à durée limitée qui passe par un workflow d'approbation que vous configurez : rôles d'approbateurs nommés, nombre minimum d'approbateurs, un code de motif, des preuves et d'éventuels contrôles compensatoires, avec une durée de vie maximale. L'auto-approbation est un réglage que vous activez, pas un défaut que nous imposons.

L'exception accordée inverse ce résultat précis — supprimer, différer, rétrograder ou exiger un contrôle — et est inscrite dans la piste d'audit de la décision avec qui l'a approuvée et quand. Elle est signable en DSSE, si bien qu'une levée est traçable et rejouable, pas un contournement silencieux qui disparaît du registre.

Un plancher reste volontairement non contournable : tout artefact déployé doit porter un vrai passage du scanner. Une exception lève un résultat de politique précis ; elle ne lève jamais l'exigence que l'artefact ait été scanné.

Par défaut, Stella Ops gère ses propres utilisateurs locaux et hache les mots de passe avec Argon2id. Les connecteurs SAML, OIDC et LDAP/Active Directory sont livrés signés avec la plateforme ; en activer un est une étape de configuration de l'opérateur, pas un réglage par défaut. Le bundle d'installation contient un fichier de configuration pour chaque connecteur.

L'accès est cloisonné par locataire et fondé sur des permissions, pas sur des rôles approximatifs. La plateforme livre plus de 200 permissions nommées, si bien que ce qui compte fait l'objet d'attributions distinctes : approuver une exception de politique, contourner un contrôle de release et faire tourner une clé de chiffrement de clés sont chacune leur propre permission. Vous pouvez autoriser quelqu'un à lire des résultats sans l'autoriser à lever un blocage.

Les actions de modification sont consignées dans la propre piste d'audit du produit, avec sa propre permission de lecture — séparée de la chaîne de preuves signée que porte une release, et en complément de celle-ci. Rien de tout cela ne dépend de l'offre : les offres Gratuit et Licence incluent toutes les fonctionnalités.

C'est la bonne question, et nous ne l'éludons pas : une signature prouve que votre installation a produit le verdict, donc un plan de contrôle compromis peut signer un enregistrement d'apparence valide. Ce que fait la conception, c'est rendre cet enregistrement difficile à croire aveuglément et facile à prendre en défaut.

La vérification s'exécute contre une racine de confiance que vous configurez et échoue fermée sans elle — elle n'appelle jamais un service Stella Ops pour décider quoi croire. Chaque verdict est horodaté contre une autorité d'horodatage que vous désignez, et l'inclusion dans un journal de transparence est possible contre un journal que vous exploitez — le « quand » et le « a-t-il jamais été enregistré » sont ainsi ancrés hors de la boîte auditée.

Le contrôle le plus fort est la relecture : chaque verdict se recalcule à partir de ses entrées scellées, et un enregistrement qui ne se recalcule pas au même résultat échoue. Relancez la relecture sur une infrastructure que le plan de contrôle suspect ne contrôle pas, et un verdict falsifié ne survit pas au recalcul. Rien de cela ne rend un plan compromis inoffensif — cela déplace l'ancre de confiance hors de ce plan et vous donne un moyen indépendant de détecter un mensonge.

Rien n’a été supprimé. L’atteignabilité change le fait qu’un résultat bloque une promotion, pas le fait qu’il existe : le résultat reste au dossier avec l’état qui lui a été attribué, et la preuve de la porte conserve le nombre total de résultats à côté du sous-ensemble qui a réellement bloqué. Il n’y a aucune étape de suppression à reconstituer par la suite.

La capsule dit pourquoi, et quand. Elle lie par empreinte chaque entrée qui a produit le verdict : le SBOM, les instantanés d’avis, la preuve d’atteignabilité dont l’état provient, ainsi que l’identifiant et la version de la politique qui a agi dessus. L’approbation qui a promu la version est enregistrée sur la version elle-même, à l’étape Decision de la chaîne de traçabilité.

Et elle se recalcule. La relecture réexécute le verdict à partir de ces entrées scellées dans un contexte hors ligne et compare le résultat à celui enregistré, en signalant une divergence s’ils diffèrent ; une relecture qui ne peut pas réellement recalculer échoue au lieu de renvoyer le verdict stocké. Après un incident, ce qui était connu au moment de la décision relève du dossier et non de la discussion.

Le risque résiduel vous appartient. Votre politique a décidé quels états bloquent et lesquels ne bloquent pas, et une porte ne vaut que la politique qui la sous-tend. Stella Ops affirme que la décision était étayée par des preuves et rejouable ; jamais qu’elle était correcte. À savoir avant d’écrire cette politique : seul un chemin atteignable prouvé peut bloquer une version, car « aucun chemin observé » n’est pas une preuve qu’aucun chemin n’existe, et n’est pas consigné comme telle.

Preuves et audit → Comment fonctionne l'atteignabilité →

Le verdict est rouvert. La fraîcheur des avis n'est pas un rapport que vous lisez plus tard — de nouvelles données d'avis réévaluent les décisions déjà prises, et la release concernée est signalée.

Une décision correcte le mardi peut cesser de l'être le jeudi sans que rien n'ait changé dans votre parc. Les systèmes qui n'évaluent qu'au moment de la promotion ne peuvent pas le voir.

L'âge des flux est affiché à l'écran, source par source. L'obsolescence est visible, jamais masquée.

Une installation déconnectée qui sert en silence des données d'avis vieilles d'un mois tout en paraissant saine est pire qu'une installation qui refuse de démarrer. Stella Ops vous montre l'âge des données sur lesquelles il fonde ses décisions, et l'import d'un Offline Kit enregistre le digest de l'instantané, de sorte qu'un rejeu des mois plus tard utilise les mêmes données que celles sur lesquelles vous avez décidé.

Quelque chose qu'ils peuvent vérifier eux-mêmes, sans nous faire confiance ni rien installer. La capsule d'exemple publiée se vérifie avec cosign verify-blob et sha256sum en une trentaine de secondes.

• Ce qui a été scanné (digest exact de l'artefact)
• Ce qui a été trouvé (SBOM?Software Bill of Materials – une liste complète de tous les packages et dépendances de votre logiciel + atteignabilité)
• Pourquoi cela a été approuvé (verdict de politique)
• Qui l'a approuvé (approbations signées)

Les auditeurs peuvent vérifier indépendamment les signatures et rejouer la décision hors ligne avec stella replay.

Commandes telles qu'affichées dans la console du produit (v1.0-RC1).

Non. Les preuves proviennent de la CLI, dans votre job de build existant. stella ci init génère l'ossature des étapes du pipeline ; la CLI signe la preuve de build dans le job (stella attest sign).

Aucun connecteur n'est requis : toute CI capable d'exécuter un binaire convient. Stella consomme des digests et des preuves signés, pas un accès au dépôt.

Commandes telles qu'affichées dans la console du produit (v1.0-RC1).

Les packs de conformité mettent en correspondance les preuves de la chaîne de traçabilité et les obligations NIS2, DORA et CRA. Leur activation lance la collecte de preuves dans un mode prudent, preuves uniquement ; elle ne revendique aucune conformité réglementaire.

L'opérateur reste toujours le décideur soumis à la réglementation. Stella vous aide à assembler et à signer les artefacts qu'attend un régulateur — elle ne dépose jamais de déclaration et ne certifie jamais rien.

Certains chemins d'écriture sont encore en cours — par exemple, la transmission automatique à l'ENISA attend le schéma officiel (aujourd'hui, dépôt dans le système de fichiers de l'opérateur). L'état actuel de chaque pack est indiqué sur la page de conformité.

Les packs de conformité en détail →

Une charge de travail gérée dans un environnement de votre installation : un service conteneurisé, ou un artefact adressé par digest déployé sur un hôte via SSH ou WinRM ; les deux comptent de la même façon. Une relation charge de travail–environnement peut compter lorsque Stella Ops déploie, contrôle par ses portes ou promeut ses releases, scanne son image ou son artefact installé, ou applique un résultat de scan antérieur à cette charge de travail installée. Appliquer un résultat antérieur ne nécessite pas d'exécuter un nouveau scan. Chaque relation qui remplit ces conditions compte une seule fois, même lorsque plusieurs de ces activités s'appliquent.

Les placements sont comptés par installation — un déploiement logique du plan de contrôle de Stella Ops : les nœuds de cluster, les réplicas de base de données et les composants de basculement d'un même déploiement sont comptés ensemble, et les installations exploitées de manière indépendante sont des installations distinctes. L'infrastructure propre de Stella Ops n'est jamais comptée. Un placement prend fin lorsque toute gestion de cette charge de travail dans cet environnement cesse effectivement, ou lorsque la charge de travail est retirée et qu'aucune autre activité de gestion ne le maintient actif ; la fin d'un scan n'y met pas fin, et la conservation de preuves historiques ou de rapports ne suffit pas à créer, réactiver ou maintenir un placement.

La version actuelle n'affiche pas de total de placements. Comptez une seule fois chaque charge de travail dans chaque environnement si Stella Ops déploie, contrôle par ses portes ou promeut ses releases, scanne son image ou son artefact installé, ou lui applique un résultat de scan antérieur. La vue Estate liste les déploiements effectués par Stella Ops ; vous devez aussi compter toutes les autres charges de travail concernées, y compris celles que d'autres outils déploient et celles que l'inventaire automatique ne montre pas.

Ce qui compte comme placement géré →

Non. Cinq réplicas d'une charge de travail dans un environnement constituent un seul placement. La redémarrer, la redéployer ou déployer une nouvelle version d'image ou un nouveau digest de la même charge de travail dans le même environnement n'ajoute rien.

Trois. Un placement est une charge de travail dans un environnement : une charge de travail qui tourne en dev, en staging et en production représente donc 3 placements, et dix charges de travail réparties sur trois environnements en représentent 30. Les environnements eux-mêmes ne sont jamais limités ni facturés.

Non. Rien n'est facturé par scan, re-scan, rapport de vulnérabilités, promotion ou déploiement. Scanner l'image ou l'artefact d'une charge de travail installée, ou lui appliquer un résultat de scan antérieur, peut faire entrer cette charge de travail dans le décompte des placements pour chaque environnement concerné. Chaque relation charge de travail–environnement ne compte qu'une fois, quel que soit le nombre de scans ou de rapports.

Le simple fait de conserver ou de consulter un rapport uniquement comme preuve historique ne crée pas de placement. Présenter un résultat antérieur comme information de scan applicable à une charge de travail installée revient à appliquer ce résultat. Scanner une image ou un artefact qui n'est installé dans aucun de vos environnements ne crée pas de placement.

L'utilisation en production au-delà de 20 placements par installation nécessite l'offre Licence : une licence portant sur une capacité en placements au moins égale au nombre de placements que vous gérez. Elle coûte €100 par mois pour une capacité jusqu'à 100 placements, puis €1 par placement de capacité et par mois au-delà ; au-delà de 20, chaque placement compte — les 20 gratuits ne sont pas déduits —, si bien qu'une capacité de 30 coûte €100 par mois et une capacité de 200, €200.

Une augmentation de capacité prend effet dès sa commande et est facturée au prorata à partir de cette date ; une réduction prend effet au renouvellement.

Si vous constatez avoir dépassé par inadvertance votre capacité, ou les 20 placements gratuits, vous pouvez continuer pendant 14 jours à compter de ce constat, le temps de réduire l'utilisation ou de commander de la capacité. Cette tolérance vise les accidents, pas les dépassements délibérés ou répétés.

Vous pouvez vous abonner dès aujourd'hui : écrivez à sales@stella-ops.org ; la commande est passée par un marchand de référence (merchant of record) agréé. Le paiement en ligne sera bientôt disponible.

Combien cela coûtera-t-il ? →

L'offre Licence a un minimum mensuel de €100, et ce minimum couvre jusqu'à 100 placements : 21 placements et 100 placements coûtent tous deux €100 par mois. À partir de 101 placements, le prix est de €1 par placement — 101 coûtent €101, 150 coûtent €150.

Rien n'est désactivé. La version actuelle n'applique pas la limite de placements et ne vérifie pas de licence ; votre logiciel, vos charges de travail, vos scans et vos déploiements continuent donc de fonctionner, et chaque enregistrement de preuve reste vérifiable avec votre propre racine de confiance.

La capacité payante est toutefois concédée sous licence pour la durée de l'abonnement. Une fois cette durée écoulée, l'utilisation en production au-delà de 20 placements exige un renouvellement ou une réduction à 20 placements ou moins.

Non. Il n'y a ni serveur de licences, ni activation, ni appel vers nos serveurs : la version actuelle ne vérifie pas de licence, donc une installation air-gap est sous licence exactement comme une installation connectée. Votre utilisation gratuite est définie par les termes de la licence, et la capacité payante par votre commande — pas par une connexion à nos services.

Les mises à jour du renseignement sur les vulnérabilités parviennent à une installation hors ligne via l'Offline Kit, et l'âge des flux est affiché à l'écran, source par source.

Par votre commande. L'offre Licence s'achète auprès d'un marchand de référence (merchant of record) agréé, pour une capacité en placements au moins égale au nombre de placements que vous gérez, et la commande acceptée indique cette capacité et la durée, dans le cadre du Stella Ops Customer Agreement.

La version actuelle n'importe ni ne vérifie cet enregistrement ; maintenir l'installation dans ce cadre relève donc de votre responsabilité. À l'échéance, rien n'est désactivé dans le logiciel, mais l'utilisation en production au-delà de 20 placements exige alors un renouvellement ou une réduction à 20.

Contrat client (Customer Agreement) →

Les preuves générées par votre installation sont signées avec les propres clés de votre installation, pas avec les nôtres. Vérifiez un bundle de preuves portable entièrement hors ligne par rapport à la racine de confiance que vous déclarez : stella evidence verify-offline <bundle.tgz> --trust-root <keys.jwks.json|key.pem>. La commande contrôle les sommes de contrôle, les liaisons du manifeste et la signature, et échoue fermée.

Les releases Stella Ops sont signées séparément : le bundle de release et les images sont signés avec Cosign, et la clé publique figure sur la page des clés de vérification. Une signature de release montre qu'un bundle vient de nous ; une signature de preuve montre qu'un enregistrement vient de votre installation.

Clés de vérification →

Oui, par les mêmes interfaces qu'une personne. Un job CI, un script ou un agent d'IA que vous exploitez s'authentifie comme client de service OAuth (client credentials) et pilote les releases via l'API de release ou stella release approve|reject|promote|deploy|rollback. Les approbations et les portes de politique sont évaluées par le serveur, si bien qu'un appelant automatisé est soumis à la même politique qu'une personne.

D'autres scanners s'intègrent aussi : stella sbom upload importe un SBOM CycloneDX?Un format standard ouvert pour les SBOM utilisé dans toute l'industrie ou SPDX?Software Package Data Exchange – un autre format standard ouvert pour les SBOMs, largement utilisé en open source externe et enregistre l'outil qui l'a produit, et stella gate score batch --sarif fait passer les résultats SARIF d'un autre outil par la même porte de release.

Une revue couvre un problème défini. Un ingénieur analyse les informations que vous envoyez et vous adresse une réponse d'ingénierie écrite : la cause probable, et les étapes correctives ou de diagnostic que nous recommandons.

Elle n'inclut pas d'heures d'ingénierie illimitées, de développement sur mesure, de correction garantie ni de conseil continu, et elle ne comporte aucun engagement de niveau de service continu. Avant l'achat, nous vous communiquons un délai de réalisation estimé ; une fois en possession des informations nécessaires, nous répondons par écrit dans un délai raisonnable. Avant de vous demander des journaux, nous vous indiquons comment transmettre les données de diagnostic de manière sécurisée. Pour en acheter une, écrivez à support@stella-ops.org avec une brève description du problème.

Si la revue montre que le problème principal est un défaut reproductible dans une version prise en charge et correctement configurée, les frais sont remboursés — ou convertis en avoir, si vous le préférez.

La documentation, les diagnostics Doctor et le dépannage en libre-service sont gratuits pour tous, et signaler un défaut du produit ou une vulnérabilité de sécurité n'exige jamais de revue payante.

Stella Ops est en release candidate (v1.0-RC1).

• Maintenant : v1.0.0-RC1-20261029 — le bundle signé et les images sont publics et s'obtiennent anonymement depuis get.stella-ops.org et registry.stella-ops.org
• Avant la sortie de la v1.0 : au moins deux clients en production, et la surface d'API publique gelée
• La v1.0 est attendue le 1er janvier 2027
• Le code est source-available sous BUSL-1.1
• Inchangé dans tous les cas : formats de preuves rétrocompatibles et relecture déterministe

Comment démarrer →

La connexion par annuaire n'est pas activée par défaut. Les plugins LDAP, OIDC et SAML sont livrés signés avec la v1.0.0-RC1-20261029 et le bundle d'installation contient un fichier de configuration pour chacun, mais Stella Ops ne propose pas de connexion par annuaire sans configuration : vous pointez un plugin vers votre annuaire et vous l'activez.

Ce n'est pas non plus un outil Kubernetes — c'est une position délibérée, pas une lacune. Il ne recherche pas de logiciels malveillants et ne fournit pas de packs de conformité fédéraux américains. Si l'un de ces points est votre critère décisif, une autre solution vous conviendra mieux aujourd'hui.

Stella modélise les versions comme un graphe de promotion (Dev → Stage → Prod). À chaque porte :

• La politique est évaluée par rapport aux preuves de l'artefact
• Les approbations sont enregistrées avec des signatures cryptographiques
• Une Decision Capsule?Un 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éterministe est générée pour l'audit

Les promotions sont liées aux digests des artefacts, pas aux tags. Même digest = mêmes preuves réutilisées.

Stella Ops est développé en Europe et exploité par une société immatriculée en Bulgarie. Notre propre infrastructure — ce site, le registre et les canaux de mise à jour — est hébergée en Suisse, qui bénéficie d'une décision d'adéquation de l'UE en matière de protection des données. Aucun fournisseur dont le siège est aux États-Unis ne figure dans votre chaîne d'approvisionnement. Les mentions légales détaillent l'exploitant.

La plate-forme est auto-hébergée : vos artefacts, SBOM et preuves restent sur votre propre infrastructure, en environnement isolé si nécessaire. Juridiction européenne et auto-hébergement : la seule partie qui détient vos preuves de release, c'est vous.

Question légitime pour tout ce qui se trouve dans un chemin de release. La réponse tient à la conception : l'exploitation quotidienne ne dépend jamais de la possibilité de nous joindre. Le produit est auto-hébergé et fonctionne en environnement isolé, sans serveur de licences ni dépendance cloud envers nous, et rien dans la version actuelle ne vérifie de licence ; rien n'est donc désactivé à la fin d'un abonnement — l'utilisation en production au-delà de 20 placements exige alors un renouvellement ou une réduction à 20.

Vos preuves non plus n'ont pas besoin de nous. Les verdicts et capsules se vérifient hors ligne — stella replay recalcule une décision à partir de ses entrées scellées, sans aucun service ni compte Stella Ops.

Le code est source-available sous BUSL-1.1 : vous pouvez lire, compiler et corriger la version que vous exploitez. La licence a aussi une échéance intégrée — chaque version bascule vers une licence ouverte à sa Change Date, au plus tard le 20 janvier 2030 pour la version actuelle. Vous ne dépendez pas non plus de nous pour l'exploitation quotidienne : stella doctor exécute les contrôles de diagnostic de l'installation, stella doctor export prépare un bundle pour le support, et stella doctor fix applique des réparations non destructives. Le code source est à git.stella-ops.org.

Au quotidien, le produit se suffit à lui-même. Doctor contrôle l'état de la pile et renvoie les étapes de correction pour tout ce qu'il détecte ; dans une fenêtre de maintenance, il applique lui-même les corrections non destructives, et les corrections destructives uniquement derrière une porte d'approbation, avec un aperçu à blanc et une trace d'audit durable — sinon, il vous remet les étapes manuelles. Une aide humaine est disponible en plus, sous forme de revue payante d'un problème défini, et non comme ce qui fait tourner votre installation. Si vos achats exigent des engagements contractuels de continuité, définissez-les avec sales@stella-ops.org pendant l'évaluation.

Les clés de vérification, un exemple de preuve signée ainsi que la documentation d’architecture et de durcissement sont publiques et regroupées sur la page d’évaluation de sécurité fournisseur, qui indique aussi notre position en matière de certification. Des références clients arrivent bientôt — les résultats de notre bêta interne. Les discussions de due diligence peuvent être cadrées pendant l’évaluation.

Revue de sécurité fournisseur →

La commande, le paiement, les taxes et la facturation sont gérés par un marchand de référence (merchant of record) agréé — voir l'avis sur le paiement. Vous pouvez commander dès aujourd'hui par e-mail : l'offre Licence auprès de sales@stella-ops.org, une revue de support auprès de support@stella-ops.org. Le paiement en ligne sera bientôt disponible.

Le produit est conçu pour continuer à tourner sans ticket : Doctor contrôle l'état de la pile et applique lui-même les corrections non destructives dans une fenêtre de maintenance, en vous remettant les étapes exactes pour tout ce qu'il ne fera pas sans supervision. La documentation, Doctor et le dépannage en libre-service sont gratuits dans toutes les offres. Si vous voulez l'avis d'un ingénieur, une revue de support coûte €75 pour un problème défini : vous obtenez un délai de réalisation estimé avant l'achat, puis une réponse d'ingénierie écrite, et les frais sont remboursés si le problème principal s'avère être un défaut reproductible dans une version prise en charge et correctement configurée. Aucune offre ne comporte d'engagement de niveau de service continu. Quel que soit l'interlocuteur, c'est l'équipe d'ingénierie qui construit le produit — le support n'est pas externalisé.

Stella Ops Suite est disponible en source sous BUSL-1.1. Vous pouvez lire, compiler et auditer le code. La couche de vérification (validation des capsules, vérifications de signature) est sous licence Apache-2.0. Le code source se trouve sur git.stella-ops.org.

BUSL-1.1 autorise l'utilisation gratuite en production jusqu'à 20 placements gérés par installation. Au-delà, l'utilisation en production nécessite l'offre Licence, une licence pour votre nombre de placements. Après la Change Date — quatre ans après chaque version — le code passe sous Apache-2.0.

Ce modèle finance un développement pérenne du produit tout en gardant la chaîne de preuves entièrement auditable.

Un locataire est un espace de travail isolé, avec ses propres utilisateurs, rôles, politiques et historique de preuves. Suspendre un locataire gèle l'ensemble de ses accès.

Les locataires partagent une installation ; les preuves et les accès sont séparés par locataire. Les deux termes répondent à des questions différentes :

• Un environnement (Environment?Une cible de déploiement logique (p. ex. dev, staging, prod) qui suit son propre historique de releases, ses règles de promotion et ses portes de politiques) est une cible de déploiement — l'endroit où une release s'exécute, et la politique qui conditionne sa promotion.
• Un locataire est une frontière d'accès et de preuves — qui peut voir et agir, et à quel historique de preuves les enregistrements sont rattachés.

Un locataire contient généralement plusieurs environnements. Ni les locataires ni les environnements ne sont facturés : la tarification compte les placements gérés sur l'ensemble de l'installation.

Oui. Stella est la couche de contrôle au-dessus du scanner que vous utilisez, et les résultats de ce scanner ont un point d'arrivée : stella sbom upload accepte un document CycloneDX?Un format standard ouvert pour les SBOM utilisé dans toute l'industrie ou SPDX?Software Package Data Exchange – un autre format standard ouvert pour les SBOMs, largement utilisé en open source externe et consigne l'outil qui l'a produit, et stella gate score batch --sarif fait passer le SARIF de n'importe quel producteur par la même porte de publication que les analyses de Stella.

Par-dessus cette liste de résultats, Stella ajoute l'analyse d'atteignabilité, le VEX?Vulnerability Exploitability eXchange – déclarations lisibles par machine indiquant si les vulnérabilités sont réellement exploitables dans votre contexte multi-émetteurs, des portes de politique propres à chaque environnement et l'export de preuves signées. Votre scanner trouve des CVE ; Stella décide lesquelles comptent et prouve la décision.

L'atteignabilité est calculée par l'analyse que Stella fait elle-même du digest. Un SARIF importé porte l'atteignabilité que son producteur y a inscrite — Stella lit ce champ, elle ne le recalcule pas.

Commandes telles qu'affichées dans la console du produit (v1.0-RC1).

Comparaison avec Trivy · Comparaison avec Snyk · Comparaison complète →

Stella n'est pas une couche posée sur votre outil de déploiement : Stella est un orchestrateur de publications. Docker, Compose, SSH, WinRM, ECS, Nomad et Ansible sont fournis comme plugins d'exécution intégrés. Sur les cibles qu'ils couvrent, Stella effectue le déploiement elle-même ; elle n'enveloppe pas un outil qui le fait déjà.

Votre CI reste exactement où elle est, parce que la porte n'est qu'un binaire. Toute CI capable d'en exécuter un appelle stella gate evaluate et agit sur le code de sortie. stella ci init écrit des enchaînements prêts à l'emploi pour GitHub Actions, GitLab CI et Gitea Actions ; toute autre CI se branche à la main en quelques lignes.

Des connecteurs existent pour Gitea, GitHub App, GitLab, Jenkins, Harbor, Nexus, les registres OCI?Open Container Initiative — le standard industriel pour les formats d'images de conteneurs et les registres, Vault et Consul. Le partage concret : gardez votre CI, et décidez par environnement si Stella effectue le déploiement ou contrôle celui qu'effectue votre outil actuel.

Commandes telles qu'affichées dans la console du produit (v1.0-RC1).

Comparaison avec Octopus Deploy · Ce qui se branche, et ce qui n'a besoin d'aucun connecteur →

Oui. Stella fournit la preuve au niveau de l'artefact qu'un programme de conformité invoque sans pouvoir la produire lui-même : pour chaque publication, ce qui est déployé, sous quel digest, franchissant quelle politique, approuvé par qui et quel jour. Cet enregistrement est lu sur le déploiement lui-même et se rejoue à l'identique à partir des mêmes preuves — la réponse obtenue l'an prochain est celle d'aujourd'hui.

Cet enregistrement s'exporte en huit profils signés destinés aux régulateurs : déclaration d'applicabilité NIS2 et rapport d'efficacité ; registre d'informations DORA, rapport d'incident TIC majeur, partage d'informations au titre de l'article 45 et dossier de preuves TLPT ; dossier technique CRA et dossier de conformité. Chacun est scellé, signé et vérifiable hors ligne face à des ancres de confiance publiées — la signature se contrôle sans aucun accès à votre instance Stella.

Rien du programme que vous menez déjà n'a besoin de changer. Chaque export est un fichier signé et transportable : joignez-le au contrôle qu'il atteste, remettez-le à un auditeur, ou récupérez-le via l'API d'export d'assurance. Et avant l'export, un contrôle de préparation indique, profil par profil, ce qui manque encore — la lacune apparaît tant que vous pouvez encore la combler, pas pendant l'audit.

Le terrain de la conformité, sourcé · Les packs de conformité en détail →