Questions fréquemment posées

Non. Stella Ops est conçu pour les environnements non-Kubernetes comme cas d'utilisation principal.

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.

It is shown as Missing. Not passed, not assumed healthy, not quietly skipped.

Every stage of the custody spine carries one of three states — Missing, Recorded, or Signed. A gate that cannot find the evidence it needs does not fall back to a pass; NOT EVALUATED is never counted as a pass. Most tools treat absence as absence of a problem. This is the opposite of that, and it is the reason the rest of the evidence is worth anything.

Yes. The example capsule is a real signed archive you can check with stock tooling — cosign verify-blob plus sha256sum, no Stella Ops anywhere.

That download is a sanitized sample signed with a demo key, so it carries no trust beyond itself. stella evidence card verify and deterministic replay need an installation and a product-exported capsule — they will not succeed against the sample.

Yes, and offline. A verdict replays deterministically from the frozen inputs that produced it: the same SBOM, the same advisory snapshot, the same policy version.

This is the difference between a tool that tells you an answer and one that can be made to show its working months later, on a machine with no network, in front of someone who does not trust you.

Après le déploiement, Stella continue de surveiller. Watch est la dernière étape de la colonne vertébrale de la garde (Source → Build → Scan → Verdict → Decision → Deploy → Watch) : elle compare le résumé réellement exécuté dans chaque environnement avec le résumé qui a été approuvé pour celui-ci.

Lorsqu'ils diffèrent, le service est signalé : l'exécution d'un résumé n'est pas un résumé approuvé/déployé (image non approuvée ou modifiée). Vous voyez exactement quel service, dans quel environnement, a dérivé 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 du domaine →

Oui. Stella fonctionne à 100 % hors ligne sans dépendances externes.

Le 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 le Offline Kit →

Call graphs are built through the scan pipeline for nine languages: compiler-grade for Go, Java and .NET, and from source text for Python, JavaScript, TypeScript, Rust, PHP and Ruby. Every edge carries the tier that produced it.

The narrower case matters more: building a call graph from a source tree in the CLI supports Go and Rust only. Everything else arrives as a pre-extracted graph from the pipeline. Findings outside covered languages are not silently dropped — they stay in the working set as unknowns, scored rather than skipped.

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 — pas de toute la suite ; le scellement des preuves, les notifications et l'audit timeline sont hors du chemin de décision. Ce que la topologie livrée n'apporte pas, c'est la redondance : chaque magasin de données tourne en instance unique, prévoyez donc la disponibilité de PostgreSQL. Nous préférons le dire plutôt que vous le laisser découvrir.

Déployer sur une VM nue est de premier ordre : via SSH, WinRM ou Ansible, Stella Ops peut poser un fichier, redémarrer un service ou exécuter un exécutable fourni par l'opérateur sur l'hôte, et 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'accessibilité 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 ordinaires » 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 et non un défaut — la connexion par annuaire n'est pas encore validée pour la production, considérez-la donc comme à venir plutôt que comme évaluable aujourd'hui.

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 modifiantes sont consignées dans la piste d'audit propre au produit, avec sa propre permission de lecture — distincte de, et en plus de, la chaîne de preuve signée que porte une release. Rien de tout cela n'est réservé à un palier : chaque capacité est livrée dans tous les paliers, y compris Free.

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’accessibilité 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 du gate 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’accessibilité 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 il 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 un gate ne vaut que la politique qui le 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 accessible 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'accessibilité →

The verdict re-opens. Advisory freshness is not a report you read later — new advisory data re-evaluates decisions that were already made, and the affected release is flagged.

The decision that was correct on Tuesday can stop being correct on Thursday without anything in your estate changing. Systems that only evaluate at promotion time cannot see that.

Feed age is reported per source, on screen. Staleness is visible, never hidden.

An air-gapped install that quietly serves month-old advisory data while looking healthy is worse than one that refuses to start. Stella Ops shows you the age of what it is deciding with, and an offline kit import records the snapshot digest so a replay months later uses the same data you decided on.

Les auditeurs reçoivent des Decision Capsules — des paquets de preuves signés cryptographiquement qui prouvent :

• 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 c'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 tâche de build existante. stella ci init échafaude les étapes du pipeline; la CLI signe la preuve de build à l'intérieur du travail (stella attest sign).

Aucun connecteur n'est requis : tout CI capable d'exécuter un binaire fonctionne. Stella consomme des résumés et des preuves signés, pas l'accès au référentiel.

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

Les packs de conformité mappent les preuves de garde aux obligations NIS2, DORA et CRA. L'activation démarre la collecte de preuves en mode conservateur preuve uniquement; il ne revendique pas la conformité réglementaire.

L'opérateur reste toujours le décideur régulé. Stella vous aide à assembler et à signer les artefacts attendus par un régulateur : elle ne classe jamais et ne certifie jamais.

Certains chemins d'écriture sont toujours en cours - par exemple, le transport de soumission automatique ENISA est en attente du schéma officiel (abandon du système de fichiers de l'opérateur aujourd'hui). L'état actuel de chaque pack est indiqué sur la page de conformité.

Les packs de conformité en détail →

Plus que l'offre que vous payez — pour l'instant. Précommandez Plus et vous êtes provisionné en Pro : 100 environnements au lieu de 20, aucun plafond d'analyse au lieu de 50 000 par mois, des données de vulnérabilités en continu au lieu de quotidiennes, et le support Pro — 30 tickets par an avec un objectif de réponse de 1 jour ouvré, au lieu des 10 tickets et 3 jours ouvrés de Plus — au prix de Plus. Ce tarif early-adopter prend fin à la v1.0 ; commandez avant pour le conserver. Sinon, une précommande achète l'offre exactement telle que cette page la décrit, et la RC1 est publique aujourd'hui : vous pouvez faire tourner le logiciel avant de vous engager. La commande, le paiement et la facturation sont assurés par un vendeur officiel agréé ; confirmez la durée du surclassement avec le service commercial lors de la commande.

Détails complets des tarifs →

L'offre gratuite est à €0 : 3 environnements et 100 analyses de nouveaux digests par 24 heures glissantes, avec toutes les fonctionnalités incluses. Les offres payantes augmentent le nombre d'environnements et le volume d'analyse :

• Plus — €499 par mois : 20 environnements
• Pro — €1 199 par mois : 100 environnements
• Enterprise — sur mesure : environnements, volume d'analyse et SLA négociés

Module complémentaire pour Plus : +10,000 analyses approfondies de nouveaux digests pour €399

Toutes les fonctionnalités sont incluses dans chaque offre : les packs de conformité ne sont pas réservés à certaines offres. Facturation annuelle : payez 11 mois et bénéficiez de 12.

Prices are shown excluding VAT. Any applicable VAT or sales tax is determined and charged at checkout by the merchant of record handling your order, based on your location and tax status.

Détails complets des tarifs →

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

• Maintenant : v1.0.0-RC1 — 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, attendue le 1er janvier 2027 : le tarif de précommande pour premiers adoptants prend fin. Les précommandes sont ouvertes jusque-là
• Le code est source-available sous BUSL-1.1
• Inchangé dans tous les cas : formats de preuves rétrocompatibles et relecture déterministe

Demander un accès anticipé →

Directory sign-in is not on by default. The LDAP, OIDC and SAML plugins ship signed with v1.0.0-RC1 and the install bundle carries a configuration file for each, but Stella Ops does not offer zero-configuration directory sign-in: you point a plugin at your directory and enable it.

It is also not a Kubernetes tool — that is a deliberate position, not a gap. It does not scan for malware, and it does not ship US federal compliance packs. If any of those is your deciding requirement, something else fits better today.

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, de sorte que vos artefacts, SBOM et preuves restent sur votre propre infrastructure, isolés si vous en avez besoin. Exploitant européen · hébergement suisse · auto-hébergé · compatible air-gap.

Question légitime pour tout ce qui se trouve dans un chemin de release. La réponse par conception : l'exploitation quotidienne ne dépend jamais de notre disponibilité. Le produit est auto-hébergé et fonctionne en environnement isolé ; il n'y a ni serveur de licences ni dépendance cloud envers nous.

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 prend en charge 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 seul les correctifs non destructifs, et les destructifs uniquement derrière une validation, avec aperçu à blanc et enregistrement d'audit durable — sinon il vous remet les étapes manuelles. Le support humain est une option payante par-dessus, pas ce qui maintient votre installation en marche. Si vos achats exigent des clauses contractuelles de continuité, cadrez-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 vendeur officiel agréé — voir l'avis de paiement. Pour tout le reste, contactez sales@stella-ops.org pendant l'évaluation.

Le produit est conçu pour continuer à tourner sans ticket : Doctor contrôle la pile et applique lui-même les correctifs non destructifs dans une fenêtre de maintenance, en vous remettant les étapes exactes pour tout ce qu'il ne fera pas sans surveillance. En complément : Free et Plus sont en self-service — documentation, discussions communautaires et diagnostics Doctor, sans objectif de réponse contractuel. Pro ajoute un canal de support par e-mail avec un objectif de réponse de 1 jour ouvré. Le support Entreprise et ses conditions de réponse et d'onboarding sont convenus par contrat, cadrés avec sales@stella-ops.org pendant l'évaluation. Quelle que soit la personne qui répond, 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, créer 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 est à git.stella-ops.org.

BUSL-1.1 permet l’utilisation en production dans les limites gratuites (3 environnements, 100 analyses de nouveaux digests par 24 heures glissantes). Au-delà, une offre payante est nécessaire. Après la date de modification (quatre ans à compter de chaque version), le code est converti en Apache-2.0.

Ce modèle finance le développement durable tout en gardant la chaîne de preuves entièrement auditable.

A tenant is an isolated workspace with its own users, roles, policies, and evidence history. Suspending a tenant freezes all of its access.

Tenants share an installation; evidence and access are separated per tenant. The two words answer different questions:

• An 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 is a deployment target — where a release runs, and what policy gates its promotion.
• A tenant is an access and evidence boundary — who can see and act, and whose evidence history it lands in.

One tenant normally holds several environments. Tenants are not metered: tiers meter environments and new-digest scans.

A new-digest deep scan is consumed when Stella analyses a container digest for the first time and produces SBOM?Software Bill of Materials – une liste complète de tous les packages et dépendances de votre logiciel, vulnerability, and reachability evidence. Only unique digests count.

Consumes one deep scan:

• The first scan of a new artifact digest

Does not consume a deep scan:

• Re-deploying an already-scanned digest
• Promoting an already-scanned digest
• Re-evaluation when CVE?Common Vulnerabilities and Exposures – un identifiant unique pour une vulnérabilité de sécurité publiquement connue or advisory intelligence updates
• Querying existing Decision Capsules

Plus est mesurée par mois calendaire : le quota est réinitialisé le premier du mois, donc les pics au cours d'un même mois ne posent pas de problème. Pro n'a aucune limite d'analyse. L'offre gratuite n'a aucun moment de réinitialisation — la licence autorise 100 analyses approfondies de nouveaux digests sur toute fenêtre glissante de 24 heures, une analyse cesse donc d'être décomptée 24 heures après son exécution. Il n'y a pas de réserve mensuelle sur l'offre gratuite.

If a release spike, migration, or intake window exceeds the monthly quota, a capacity add-on of +10,000 new-digest deep scans is available on Plus for €399.

Tier limits and pricing →

L'offre gratuite autorise une utilisation limitée en production : toutes les fonctionnalités, jusqu'à 3 environnements et 100 analyses de nouveaux digests par 24 heures glissantes.

L'utilisation en production nécessite un forfait payant : Plus (environnements 20), Pro (100) ou Enterprise au-delà.

Détails des prix →

Oui. Stella est la couche de contrôle au-dessus du scanner que vous utilisez, et ses résultats ont où atterrir : 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 disponibilité nomme, 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 →