Vom Artefakt-Digest zum fortlaufenden Nachweis
Jedes Release durchläuft ein Nachweis-Rückgrat. Jede Stufe enthält mit dem Artefakt-Digest verknüpfte Nachweise und trägt genau einen Zustand: MISSING, RECORDED oder SIGNED. Nach der Bereitstellung prüft Watch fortlaufend, ob der Nachweis weiterhin gilt.
Nach der Ersteinrichtung verfügen Sie über:
- 1. Ihr erstes mit
SBOMSoftware Bill of Materials – eine vollständige Liste aller Pakete und Abhängigkeiten in Ihrer Softwaregescanntes Bild + Erreichbarkeitsanalyse - 2. Eine signierte Decision Capsule zum Nachweis der Scanergebnisse
- 3. Eine vollständige Hochstufung vom Entwickler zum Staging mit Beweisen
Wo Stella Ops hineinpasst
Stella sitzt zwischen Ihrer CI und Ihren Servern. CI baut Images. Stella entscheidet, ob sie promoted werden dürfen, deployt sie auf Nicht-Kubernetes-Ziele (Compose, SSH/WinRM) und exportiert Nachweise für Audits.
Gate aus jedem CI/CD-System
Was auch immer Ihre Deployments ausführt — Jenkins, Octopus-Schritte, GitLab CI, GitHub Actions, ein Shell-Skript auf einer Build-Maschine — gated über Stella auf dieselbe Weise: Fügen Sie eine Stufe hinzu, die die CLI ausführt.
Der Befehl endet mit einem Exit-Code ungleich null, wenn das Gate blockiert; die Stufe schlägt fehl und die Pipeline stoppt. Mehr ist nicht einzurichten: kein eingehender Webhook, keine Callback-URL, kein Netzwerkpfad von Stella in Ihr Build-System.
Die Signatur erfolgt beim Build, sodass der Beweis nicht davon abhängt, welches CI sie erstellt hat.
Vier Eingabekategorien speisen das Nachweis-Rückgrat. Nachweise werden dort signiert, wo sie erzeugt werden, und anschließend von der Control-Plane geprüft.
Container-Registries · Pipeline-Nachweise über das CLI · Advisory- und VEX-Quellen · Secrets — Every source named, and what each one feeds →
Das Nachweis-Rückgrat
Sieben Stufen, eine Artefaktübersicht. Dies ist die Seite, die Sie öffnen, wenn jemand fragt, was ausgeführt wird und warum es zugelassen wurde. Im Betrieb ansehen · 4 Min.
Jede Stufe befindet sich in genau einem von drei Zuständen:
MISSING
Für diese Stufe liegen keine Nachweise vor. Sie meldet MISSING, bis Nachweise eintreffen.
RECORDED
Beweise sind vorhanden und an den Artefakt-Digest gebunden, aber noch nicht signiert.
SIGNED
Der Beweis trägt eine DSSEDead Simple Signing Envelope – ein einfacher, flexibler Standard zum Signieren beliebiger Daten mit kryptographischen Signaturen-Signatur und kann offline überprüft werden.
- 1
Quelle
Commit und Repository, aus denen das Artefakt laut Pipeline stammt, werden aufgezeichnet – niemals abgeleitet.
- 2
- 3
Scan
SBOMSoftware Bill of Materials – eine vollständige Liste aller Pakete und Abhängigkeiten in Ihrer Softwareund Schwachstellenanalyse, exakt an diesen Digest gebunden. Ein neuer Digest bedeutet einen neuen Scan; Befunde werden niemals auf einen Build übertragen, aus dem sie nicht stammen. - 4
- 5
Entscheidung
Das Gate-Ergebnis und jede menschliche Genehmigung, aufgezeichnet mit der genauen Richtlinienversion, die dazu geführt hat.
- 6
Einsetzen
Rollout des genehmigten Digests in einer benannten Umgebung: Was wurde wo und wann ausgeführt?
- 7
Watch
Kontinuierlicher Vergleich laufender Digests mit genehmigten Digests. Drift wird erkannt, nicht vermutet.
Gate-Bewertung: erreichbares Risiko, keine Rohdaten
Das Gate bewertet signierte Befunde anhand einer versionierten Richtlinie. Die ReachabilityAnalyse, die beweist, ob verwundbarer Code tatsächlich von Ihrer Anwendung aufgerufen wird — und so Fehlalarme aus dem Scanner-Rauschen herausfiltert-Analyse beschränkt das Blockieren auf Befunde, die auf einem von Ihrem Code ausführbaren Pfad liegen. Unterstützt werden Go, Java, C#/.NET, JavaScript und TypeScript, Python, Rust, PHP und Ruby; Befunde außerhalb dieser Sprachen bleiben im Arbeitssatz – sie werden nicht standardmäßig als nicht erreichbar eingestuft.
In der Demo-Expositionsansicht: 7 Befunde → 1 blockierender Befund (erreichbar × nicht behoben). Das stoppt das Release. Die anderen sechs bleiben sichtbar und sind nur einen Filter entfernt.
Kontext: ~85 % der kritischen Container-Schwachstellen liegen in inaktivem Code (Sysdig 2024 Container Security Report).
$ stella gate evaluate --env staging --image sha256:8c1a4f…
Befehle wie in der Produktkonsole angezeigt (v1.0-RC1).
Eine Prüfung, die nicht durchgeführt werden konnte, wird als NICHT BEWERTET gemeldet und im Urteil erfasst. Es wird nie als bestanden gewertet.
Was die Freigabe blockiert – zuerst erreichbare, nicht behobene, richtlinienrelevante Expositionen. Der lange Rest ist nur einen Filter entfernt.
Jede fehlgeschlagene Prüfung nennt die ausgelöste Regel, die ausgewerteten Nachweise und den zugrunde liegenden Befund. Die Antwort steht im Urteil – Scanner müssen nicht erneut ausgeführt und das Sicherheitsteam muss nicht in einem Nachrichtenverlauf befragt werden. „Warum ist meine Release blockiert?“ →
Ist Stella Ops nicht erreichbar, blockiert das Gate.
Ein Timeout von Scanner oder Policy-Engine gilt bewusst als Fehler und wird nicht durchgewinkt; im CLI gibt es keinerlei Fail-Open-Schalter. Ein Artefakt, dessen Scan-Ergebnis nicht abrufbar ist, wird nicht deployt.
Ein Release während einer Störung ist ein bewusster, zurechenbarer Akt und kein Workaround: eine signierte, eingegrenzte, befristete Ausnahme, dem verantwortlichen Betreiber zugeordnet und vor der ersten Nutzung konfiguriert.
Nachweisanker
Pruefen Sie Aussagen mit Decision Capsules, Replay-Beispielen und End-to-End-Nachweisen.
Verwandte Evidenz: Evidenz und Audit | Decision Capsule-Spezifikation | Betrieb und Deployment
Bereitstellen: genehmigte Digests für Nicht-Kubernetes-Ziele
In der Bereitstellungsphase wird der genehmigte Digest ausgerollt und aufgezeichnet, was wohin gelangt ist. Die Ziele sind genau die Umgebungen, die von den meisten Release-Tools ignoriert werden.
- → Docker Compose-Projekte
- → SSH/WinRM Hosts – von Natur aus agentenlos
- → Rolling-, Canary- und Blue-Green-Strategien
- → Rollback verweist erneut auf einen bekanntermaßen guten Digest, dessen Beweise bereits gespeichert sind
- → Bei jeder Bereitstellung werden Digest, Umgebung und Zeit erfasst
Ein Rollback ist ein verifiziertes Deployment eines bereits freigegebenen Digests, keine Ausnahme vom Prozess.
Betrieb und Deployment · Bereitstellung auf Servern ohne Installation Agenten
Watch: Der Nachweis muss gültig bleiben
Eine Genehmigung ist eine Momentaufnahme. Nach der Bereitstellung vergleicht Watch jeden ausgeführten Digest mit dem für diesen Dienst und diese Umgebung genehmigten Digest. Die Bereitstellung bleibt agentenlos — auf Ihren Hosts wird nichts installiert. Das Beobachten übernimmt der Stella-Ops-Agentendienst, der die tatsächlich laufenden Image-Digests von den Docker-Daemons liest, die er erreichen kann. Der Agentendienst läuft in Ihrer eigenen Stella-Installation, nicht auf Ihren Hosts, und liest über die Docker-API.
Drift, wie das Produkt es definiert:
“Der laufende Digest ist kein genehmigter/deployed Digest (nicht genehmigtes oder verändertes Image)”
Umgebungen, die Stella nicht beobachten kann, werden als unbewiesen dargestellt und niemals als gesund angesehen.
Die von Watch beobachtete Einheit ist der Container, identifiziert per Image-Digest – die Drift-Erkennung deckt also containerisierte Lasten auf Ihren Hosts ab, ob sie über Docker per SSH, Compose oder einen Windows-Daemon laufen.
Die Grenze, klar benannt: Was außerhalb eines Containers läuft, liegt außerhalb des Watch-Beweises. Dateien, Dienste oder ausführbare Programme auf einem nackten Host tragen Deployment-Evidenz — wer was wann aus welchem digest-identifizierten Release ausgerollt hat —, werden aber nicht kontinuierlich per Image-Digest nachgeprüft.
Mehr erfahren
Womit Stella eine Verbindung herstellt Architekturüberblick Was Auditoren erhalten