Connecter. Empaqueter. Contrôler. Déployer.

Stella Ops connecte votre chaîne d'outils, produit des preuves, contrôle les promotions et exporte la preuve de décision pour chaque version.

Demander l'acc?s Voir la documentation

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

Après la configuration initiale, vous devrez :

1. Votre première image numérisée avec SBOM?Software Bill of Materials – une liste complète de tous les packages et dépendances de votre logiciel + analyse d'atteignabilité
2. Une capsule de décision signé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, ECS, Nomad) et exporte les preuves pour l'audit.

Vue d’ensemble de l’architecture

Le plan de contrôle Stella Ops se situe entre vos entrées (CI/CD, registres, feeds) et vos sorties (cibles de déploiement, systèmes d’audit). Les preuves transitent et sont scellées à chaque étape.

Stella Ops Architecture Diagram — Architecture de Stella Ops Suite — auto-hébergée avec modules pour chaque couche, extensible via plugins

Cycle de vie d’un release en un coup d’œil

Connecter, bundler, gater, déployer et exporter une capsule de décision avec des preuves liées au digest de l’artefact.

Connecter registre, SCM, CI et infrastructure

Liez vos registres de conteneurs, pipelines CI et composants d'infrastructure pour construire un registre de versions basé sur les digests. Stella surveille les nouvelles images et se coordonne avec votre infrastructure existante.

Source & Registre

→ Docker Hub, Harbor, ECR, GCR, ACR
→ Webhooks GitHub, GitLab, Bitbucket
→ Jenkins, GitHub Actions, GitLab CI

Infrastructure

→ HashiCorp Vault pour les secrets
→ HashiCorp Consul pour le registre de services
→ SSH/WinRM pour les cibles distantes (sans agent par conception)

Construire le bundle de version

Capturez les digests d'artefacts, SBOMs et provenance comme une unité unique de promotion. Le bundle traverse les environnements, accumulant des preuves à chaque étape.

→ Génération SBOM?Software Bill of Materials – une liste complète de tous les packages et dépendances de votre logiciel CycloneDX?Un format standard ouvert pour les SBOM utilisé dans toute l'industrie / SPDX?Software Package Data Exchange – un autre format standard ouvert pour les SBOMs, largement utilisé en open source
→ Attestation de provenance SLSA?Supply-chain Levels for Software Artifacts — un cadre garantissant l'intégrité des artefacts logiciels tout au long de la chaîne d'approvisionnement
→ Identité d'artefact adressée par contenu (SHA-256)

Contrôler avec atteignabilité hybride + politique

Évaluez la politique par rapport aux preuves à chaque promotion. L'analyse d'atteignabilité hybride utilise trois couches pour déterminer quelles vulnérabilités votre code appelle réellement :

1. Analyse statique

Extraction de graphes d'appels depuis le bytecode/source

2. Analyse des manifestes

Instructions d'import/require, arbres de dépendances

3. Traces d'exécution

Données de profilage optionnelles pour une confiance accrue

Terminal

$ stella gate evaluate --env stage --artifact sha256:abc123...
✓ 487 CVE trouvées dans les dépendances
✓ 475 NON ATTEIGNABLES (analyse hybride)
! 12 ATTEIGNABLES (évaluées par la politique)
Verdict de politique : PASS — 12 CVE atteignables sous le seuil
Évaluation du gate enregistrée : evidence/gate-stage-2025-07-15.json

Résultat : nettement moins de faux positifs comparé au comptage traditionnel de CVE.

Déployer + exporter la Capsule de décision

Exécutez le déploiement vers vos cibles et exportez un bundle de preuves signé. Configurez les environnements via SSH/WinRM ou utilisez les fournisseurs intégrés — tous les déploiements sont sans agent par conception.

Cibles de déploiement

→ Déploiements Docker Compose
→ AWS ECS / Fargate
→ HashiCorp Nomad
→ Déploiements scriptés (.NET 10)

Configuration de l'environnement

→ SSH pour les cibles Linux/Unix
→ WinRM pour les cibles Windows
→ Vault pour l'injection de secrets
→ Consul pour la découverte de services

Les Capsules de décision sont signées DSSE et contiennent tout pour l'export d'audit et le rejeu déterministe.

La différence de l'atteignabilité

Sans atteignabilité

487 CVE?Common Vulnerabilities and Exposures – un identifiant unique pour une vulnérabilité de sécurité publiquement connue à trier
Des jours d'investigation
Pas de piste d'audit
Deviner l'exploitabilité
Exceptions ad-hoc

Avec Stella Ops

12 CVE?Common Vulnerabilities and Exposures – un identifiant unique pour une vulnérabilité de sécurité publiquement connue atteignables à corriger
Des heures jusqu'à la résolution
Export de Capsule de décision
Preuve des chemins d'appels
Portes contrôlées par politique

Ce que reçoivent les auditeurs

Chaque Capsule de décision contient :

Digest exact de l'artefact (SHA-256)
Snapshot SBOM?Software Bill of Materials – une liste complète de tous les packages et dépendances de votre logiciel (CycloneDX?Un format standard ouvert pour les SBOM utilisé dans toute l'industrie/SPDX?Software Package Data Exchange – un autre format standard ouvert pour les SBOMs, largement utilisé en open source)
Preuves d'atteignabilité (graphes signés)
Version de politique + verdict
État VEX?Vulnerability Exploitability eXchange – déclarations lisibles par machine indiquant si les vulnérabilités sont réellement exploitables dans votre contexte (résolu par treillis)
Enregistrements d'approbation signés

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

Prêt à le voir en action ?

Demander l'acc?s Voir la documentation

Voir toutes les fonctionnalités | Preuves & Audit | Documentation