Häufig gestellte Fragen

Nein — und das ist Absicht, keine Einschränkung. Docker Compose, Swarm, SSH/WinRM-Hosts und skriptgesteuerte Ziele werden vollwertig unterstützt und sind keine Notlösung für alle, die Kubernetes noch nicht eingeführt haben.

Unterstützte Ziele: Docker-Compose-Projekte, SSH/WinRM-Hosts. SSH/WinRM-Bereitstellungen sind agentenlos – das Docker-Image erledigt die Arbeit.

Der Umkehrschluss gilt auch: Wenn alles bei Ihnen auf Kubernetes läuft, ist Stella Ops nicht Ihr Werkzeug. Es ist für die andere Hälfte Ihrer Systemlandschaft gebaut — VMs, Compose-Projekte, klassische Server — und die meisten Teams betreiben beides.

Sie werden als Missing angezeigt. Nicht als bestanden gewertet, nicht als unbedenklich angenommen, nicht stillschweigend übersprungen.

Jede Stufe des Nachweis-Rückgrats trägt einen von drei Zuständen — Missing, Recorded oder Signed. Ein Gate, das die benötigten Nachweise nicht findet, fällt nicht auf „bestanden“ zurück; NOT EVALUATED zählt nie als bestanden. Die meisten Werkzeuge behandeln das Fehlen von Daten wie das Fehlen eines Problems. Hier ist es genau umgekehrt, und genau deshalb ist der Rest der Nachweise etwas wert.

Ja. Die Beispielkapsel ist ein echtes signiertes Archiv, das Sie mit Standardwerkzeugen prüfen können — cosign verify-blob plus sha256sum, ganz ohne Stella Ops.

Dieser Download ist ein bereinigtes Beispiel, das mit einem Demo-Schlüssel signiert ist; über sich selbst hinaus begründet er also kein Vertrauen. stella evidence card verify und das deterministische Replay benötigen eine Installation und eine vom Produkt exportierte Kapsel — mit dem Beispiel schlagen sie fehl.

Ja, und zwar offline. Ein Urteil lässt sich deterministisch aus den eingefrorenen Eingaben wiederholen, die es erzeugt haben: dasselbe SBOM, derselbe Advisory-Snapshot, dieselbe Policy-Version.

Das ist der Unterschied zwischen einem Werkzeug, das Ihnen eine Antwort nennt, und einem, das noch Monate später seinen Rechenweg offenlegen kann — auf einem Rechner ohne Netzwerk, vor jemandem, der Ihnen nicht vertraut.

Nach der Bereitstellung überwacht Stella weiter. Watch ist die letzte Stufe des Nachweis-Rückgrats (Source → Build → Scan → Verdict → Decision → Deploy → Watch): Watch vergleicht den tatsächlich in jeder Umgebung ausgeführten Digest mit dem dafür genehmigten Digest.

Wenn sie sich unterscheiden, wird der Dienst mit folgender Meldung gekennzeichnet: Der ausgeführte Digest ist kein genehmigter bzw. deployter Digest (nicht genehmigtes oder geändertes Image). Sie sehen genau, welcher Dienst in welcher Umgebung von seinem genehmigten Zustand abgewichen ist.

Ein Dienst, für den Watch keine Nachweise hat, meldet Missing — er wird nie als übereinstimmend angezeigt, nur weil sich vermutlich nichts geändert hat.

Estate-Ansicht öffnen →

Ja — und das erzwingt das Produkt selbst, statt es Ihrem Netzwerk zu überlassen. Der Sealed-Modus (EgressPolicyMode.Sealed) blockiert ausgehenden Datenverkehr; stella offline import --bundle importiert ein signiertes Kit; stella evidence verify-offline prüft Prüfsummen, das Manifest, die DSSE-Bindung und die Abdeckung durch Rekor-Tiles ganz ohne Netzwerk und schlägt bei jeder Manipulation fehl (fail-closed).

Das Offline Kit bündelt Schwachstellen-Feeds, Container-Images und Herkunftsdaten. Sie erhalten identische Scan-Ergebnisse, ob online oder in einem souveränen Netzwerk.

Zum Offline Kit →

Aufrufgraphen werden über die Scan-Pipeline für neun Sprachen erstellt: in Compiler-Qualität für Go, Java und .NET, aus dem Quelltext für Python, JavaScript, TypeScript, Rust, PHP und Ruby. Jede Kante trägt die Stufe, die sie erzeugt hat.

Wichtiger ist der engere Fall: Das Erstellen eines Aufrufgraphen aus einem Quellbaum in der CLI unterstützt nur Go und Rust. Alles andere kommt als vorab extrahierter Graph aus der Pipeline. Befunde in nicht abgedeckten Sprachen werden nicht stillschweigend verworfen — sie bleiben als Unbekannte in der Arbeitsmenge, bewertet statt übersprungen.

Der Zieldatensatz enthält das Geheimnis nie — nur einen Verweis darauf. Das Geheimnis selbst wird mit AES-256-GCM unter einem mandantenspezifischen Schlüssel versiegelt, der aus einem Hauptschlüssel abgeleitet wird, und die Verschlüsselung ist an Mandant, Eigentümer und Credential-Identität gebunden, sodass der Chiffretext einer Zeile nicht als der einer anderen wiederverwendet werden kann. Der gesamte Zielverbindungsdatensatz wird anschließend erneut in seiner eigenen Krypto-Domäne versiegelt, bevor er die Datenbank erreicht.

Den Hauptschlüssel liefern Sie, wir erzeugen niemals einen. Er kommt aus einer Umgebungsvariablen, einer Datei mit geprüften Berechtigungen, HashiCorp Vault oder OpenBao, oder einem HSM. Ist kein dauerhafter Speicher konfiguriert, schlagen alle Versiegelungs- und Auflösungsvorgänge fehl, statt still auf Speicher zurückzufallen.

Eingrenzung und Rotation werden erzwungen, nicht empfohlen: jede Abfrage ist nach Mandant gefiltert, sodass ein mandantenübergreifender Lesezugriff nichts zurückgibt und nicht einmal die Existenz eines Credentials verrät. Die Rotation hält das vorherige Geheimnis für ein Kulanzfenster auflösbar und schlägt danach fehl, und ein Widerruf löscht den gespeicherten Chiffretext, sodass eine spätere Schlüsselkompromittierung ihn nicht wiederherstellen kann.

Ein durch ein Gate abgesichertes Release wird blockiert, nicht durchgewinkt. Ist der Scanner oder die Policy-Engine nicht erreichbar, behandelt das Gate den Timeout bewusst als Fehler — die Code-Kommentare sagen genau das, und es gibt in der CLI nirgends einen Fail-open-Schalter. Dasselbe gilt beim Deploy: ein Artefakt, dessen Scan-Ergebnis nicht abrufbar ist, wird nicht deployt.

Ein Release während eines Ausfalls ist ein bewusster, zurechenbarer Akt und kein Workaround. Eine Gate-Ausnahme verlangt ein Recht, das standardmäßig niemand hat, eine schriftliche Begründung, eine ausdrückliche Risikobestätigung, eine Gültigkeit zwischen einem und 365 Tagen — unbefristete Ausnahmen werden abgelehnt —, eine Signatur des verantwortlichen Betreibers und eine erneute Anmeldung innerhalb der letzten fünf Minuten. Sie wird zum Release protokolliert. Beachten Sie: sie muss vorher konfiguriert werden — in einer unveränderten Installation ist der Signaturpfad nicht verdrahtet, die Anfrage wird also abgewiesen, bis Sie einen Betreiberschlüssel hinterlegen.

Das Gate braucht nicht die ganze Plattform. Eine Deploy-Entscheidung hängt von etwa zehn Diensten ab — Datenbank, Release-Orchestrator, Scanner, Policy-Engine, Identität und Gateway — nicht von der ganzen Suite; Nachweisversiegelung, Benachrichtigungen und Timeline-Audit liegen abseits des Entscheidungspfads.

Das Deployment auf eine reine VM ist vollwertig: über SSH, WinRM oder Ansible kann Stella Ops eine Datei ablegen, einen Dienst neu starten oder eine vom Betreiber bereitgestellte ausführbare Datei auf dem Host ausführen – und erfasst Befehl, Ausgabe und Exit-Code als Nachweis, ohne Container.

Continuous Watch ist enger, und das sollte man genau benennen. Watch und Erreichbarkeit beobachten laufende Container per Image-Digest – so weiß die Drift-Erkennung, dass das laufende Artefakt noch dem freigegebenen entspricht. Ein Host, von dem kein Container gelesen werden kann, wird als unbeobachtet angezeigt, nie als gesund angenommen. Ein reiner Prozess auf einem Docker-losen Host wird also deployt und sein Lauf erfasst, aber nicht wie eine containerisierte Last kontinuierlich auf Drift überwacht. „Einfache Server“ meint Server, die Container außerhalb von Kubernetes betreiben – nicht beliebige nicht-containerisierte Prozesse.

Nein. Ein berechtigter Betreiber hebt die Blockade selbst auf. Sie beantragen eine befristete Policy-Ausnahme, die einen von Ihnen konfigurierten Genehmigungs-Workflow durchläuft: benannte Genehmiger-Rollen, eine Mindestzahl an Genehmigern, ein Begründungscode, Belege und etwaige kompensierende Kontrollen, mit maximaler Laufzeit. Selbstgenehmigung ist ein Schalter, den Sie setzen, kein von uns vorgegebener Standard.

Die erteilte Ausnahme kippt genau diesen Befund – unterdrücken, aufschieben, herabstufen oder eine Kontrolle verlangen – und wird mit Genehmiger und Zeitpunkt in den Audit-Trail der Entscheidung geschrieben. Sie ist DSSE-signierbar, sodass eine Freigabe nachvollziehbar und wiederspielbar ist, kein stiller Override, der aus dem Protokoll verschwindet.

Eine Untergrenze bleibt bewusst nicht aufhebbar: Jedes deployte Artefakt muss einen echten Scanner-Durchlauf vorweisen. Eine Ausnahme hebt einen bestimmten Policy-Befund auf; die Anforderung, dass das Artefakt überhaupt gescannt wurde, hebt sie nie auf.

Standardmäßig verwaltet Stella Ops eigene lokale Benutzer und hasht Passwörter mit Argon2id. SAML-, OIDC- und LDAP/Active-Directory-Konnektoren werden signiert mit der Plattform ausgeliefert; einen davon zu aktivieren ist ein Konfigurationsschritt des Betreibers und kein Standard. Das Installations-Bundle enthält für jeden Konnektor eine Konfigurationsdatei.

Zugriff ist mandantenbezogen und rechtebasiert, nicht grob aus Rollen abgeleitet. Die Plattform liefert über 200 benannte Rechte, sodass die entscheidenden Dinge getrennte Vergaben sind: eine Policy-Ausnahme genehmigen, ein Release-Gate umgehen und einen Schlüsselverschlüsselungsschlüssel rotieren sind je ein eigenes Recht. Sie können jemandem erlauben, Befunde zu lesen, ohne eine Blockade freigeben zu dürfen.

Verändernde Aktionen werden im eigenen Audit-Protokoll des Produkts festgehalten, mit eigenem Leserecht — getrennt von und zusätzlich zu der signierten Nachweiskette, die ein Release trägt. Nichts davon hängt vom Plan ab: Die Pläne Kostenlos und Lizenziert enthalten jede Funktion.

Es ist die richtige Frage, und wir reden sie nicht weg: eine Signatur belegt, dass Ihre Installation das Urteil erzeugt hat, eine kompromittierte Kontrollebene kann also einen gültig aussehenden Datensatz signieren. Das Design macht es schwer, einem solchen Datensatz blind zu vertrauen, und leicht, ihn zu entlarven.

Die Verifikation läuft gegen einen Vertrauensanker, den Sie konfigurieren, und schlägt ohne einen fehl – sie ruft nie einen Stella-Ops-Dienst an, um zu entscheiden, was zu vertrauen ist. Jedes Urteil wird gegen eine von Ihnen benannte Zeitstempel-Instanz zeitgestempelt, und Transparenz-Log-Aufnahme ist gegen ein von Ihnen betriebenes Log verfügbar – „wann“ und „wurde das je festgehalten“ sind so außerhalb der geprüften Box verankert.

Die stärkste Prüfung ist Replay: jedes Urteil wird aus seinen versiegelten Eingaben neu berechnet, und ein Datensatz, der nicht auf dasselbe Ergebnis kommt, schlägt fehl. Führen Sie Replay auf Infrastruktur aus, die die verdächtige Kontrollebene nicht kontrolliert, und ein gefälschtes Urteil übersteht die Neuberechnung nicht. Nichts davon macht eine kompromittierte Ebene harmlos – es verlagert den Vertrauensanker von dieser Ebene weg und gibt Ihnen einen unabhängigen Weg, eine Lüge zu erkennen.

Nichts wurde entfernt. Erreichbarkeit ändert, ob ein Befund eine Freigabe blockiert, nicht ob er existiert: Der Befund bleibt mit dem ihm zugewiesenen Zustand im Datensatz, und der Nachweis des Gates hält die vollständige Befundzahl neben der Teilmenge fest, die tatsächlich blockiert hat. Es gibt keinen Unterdrückungsschritt, der später zu rekonstruieren wäre.

Die Kapsel sagt, warum und wann. Sie bindet jede Eingabe, die das Urteil erzeugt hat, per Digest: das SBOM, die Advisory-Snapshots, den Erreichbarkeitsnachweis, aus dem der Zustand stammt, sowie Kennung und Version der Policy, die darauf gewirkt hat. Die Genehmigung, mit der das Release freigegeben wurde, wird am Release selbst festgehalten, auf der Decision-Stufe der Nachweiskette.

Und es wird neu berechnet. Die Wiedergabe führt das Urteil aus diesen versiegelten Eingaben in einem Offline-Kontext erneut aus und vergleicht das Ergebnis mit dem aufgezeichneten; weichen sie ab, wird eine Divergenz gemeldet. Eine Wiedergabe, die nicht wirklich neu berechnen kann, schlägt fehl, statt das gespeicherte Urteil zurückzugeben. Nach einem Vorfall ist aktenkundig, was zum Entscheidungszeitpunkt bekannt war, statt Gegenstand einer Diskussion zu sein.

Das Restrisiko liegt bei Ihnen. Ihre Policy hat entschieden, welche Zustände blockieren und welche nicht, und ein Gate ist nur so gut wie die Policy dahinter. Stella Ops behauptet, dass die Entscheidung nachgewiesen und wiedergebbar war; nie, dass sie richtig war. Bevor Sie diese Policy schreiben, sollten Sie wissen: Nur ein bewiesener erreichbarer Pfad kann ein Release blockieren, denn „kein Pfad beobachtet“ ist kein Beweis dafür, dass kein Pfad existiert, und wird auch nicht als solcher festgehalten.

Nachweise & Audit → So funktioniert Erreichbarkeit →

Das Urteil wird wieder geöffnet. Die Aktualität der Advisories ist kein Bericht, den Sie später lesen — neue Advisory-Daten bewerten bereits getroffene Entscheidungen neu, und das betroffene Release wird markiert.

Eine Entscheidung, die am Dienstag richtig war, kann am Donnerstag nicht mehr richtig sein, ohne dass sich in Ihrer Infrastruktur irgendetwas geändert hat. Systeme, die nur zum Zeitpunkt der Promotion bewerten, können das nicht erkennen.

Das Alter der Feeds wird pro Quelle auf dem Bildschirm angezeigt. Veraltete Daten sind sichtbar, nie versteckt.

Eine Air-Gap-Installation, die stillschweigend einen Monat alte Advisory-Daten ausliefert und dabei gesund wirkt, ist schlimmer als eine, die den Start verweigert. Stella Ops zeigt Ihnen das Alter der Daten, auf deren Grundlage es entscheidet, und der Import eines Offline Kit erfasst den Snapshot-Digest, sodass ein Replay Monate später genau die Daten verwendet, auf deren Grundlage Sie entschieden haben.

Etwas, das sie selbst prüfen können, ohne uns zu vertrauen oder etwas zu installieren. Die veröffentlichte Beispielkapsel lässt sich mit cosign verify-blob und sha256sum in etwa dreißig Sekunden verifizieren.

• Was gescannt wurde (exakter Artefakt-Digest)
• Was gefunden wurde (SBOM?Software Bill of Materials – eine vollständige Liste aller Pakete und Abhängigkeiten in Ihrer Software + Erreichbarkeit)
• Warum es genehmigt wurde (Policy-Urteil)
• Wer es genehmigt hat (signierte Genehmigungen)

Auditoren können Signaturen unabhängig verifizieren und die Entscheidung offline mit stella replay nachspielen.

Befehle wie in der Produktkonsole angezeigt (v1.0-RC1).

Nein. Die Nachweise stammen aus dem CLI innerhalb Ihres vorhandenen Build-Jobs. stella ci init erzeugt das Gerüst der Pipeline-Schritte; das CLI signiert die Build-Nachweise im Job (stella attest sign).

Es ist kein Konnektor erforderlich – jedes CI, das eine Binärdatei ausführen kann, funktioniert. Stella nutzt signierte Digests und Nachweise, keinen Repository-Zugriff.

Befehle wie in der Produktkonsole angezeigt (v1.0-RC1).

Compliance-Pakete ordnen Nachweise aus der Beweiskette den Verpflichtungen aus NIS2, DORA und CRA zu. Die Aktivierung startet die Nachweiserhebung im konservativen Nur-Nachweis-Modus; sie erhebt keinen Anspruch auf regulatorische Konformität.

Der Betreiber bleibt stets der regulierte Entscheidungsträger. Stella hilft, die von einer Aufsichtsbehörde erwarteten Artefakte zusammenzustellen und zu signieren – Stella Ops reicht sie weder ein noch zertifiziert es sie.

Einige Schreibpfade sind noch in Arbeit. Beispielsweise wartet der ENISA-Transport zur automatischen Übermittlung auf das offizielle Schema; der Export in ein betreiberseitiges Dateisystem ist heute verfügbar. Der aktuelle Status jedes Pakets steht auf der Compliance-Seite.

Compliance-Pakete im Detail →

Eine verwaltete Workload in einer Umgebung Ihrer Installation: ein Container-Dienst oder ein per Digest adressiertes Artefakt, das per SSH oder WinRM auf einen Host deployt wird; beide zählen gleich. Eine Beziehung zwischen Workload und Umgebung kann zählen, wenn Stella Ops ihre Releases deployt, mit einem Gate absichert oder promotet, ihr installiertes Image oder Artefakt scannt oder ein früheres Scan-Ergebnis auf diese installierte Workload anwendet. Das Anwenden eines früheren Ergebnisses setzt keinen neuen Scan voraus. Jede zählende Beziehung wird einmal gezählt, auch wenn mehrere dieser Tätigkeiten zutreffen.

Platzierungen werden pro Installation gezählt — eine logische Bereitstellung der Control Plane von Stella Ops: Cluster-Knoten, Datenbankreplikate und Failover-Komponenten derselben Bereitstellung werden gemeinsam gezählt, und unabhängig voneinander betriebene Installationen zählen jeweils gesondert. Die eigene Infrastruktur von Stella Ops wird nie mitgezählt. Eine Platzierung endet, wenn jede Verwaltung dieser Workload in dieser Umgebung tatsächlich endet oder wenn die Workload entfernt wird und keine andere Verwaltungstätigkeit sie aktiv hält; der Abschluss eines Scans beendet sie nicht, und das Aufbewahren historischer Nachweise oder Berichte allein erzeugt keine Platzierung, reaktiviert keine und hält keine aktiv.

Das aktuelle Release zeigt keine Gesamtzahl der Platzierungen an. Zählen Sie jede Workload in jeder Umgebung einmal, wenn Stella Ops ihre Releases deployt, mit einem Gate absichert oder promotet, ihr installiertes Image oder Artefakt scannt oder ein früheres Scan-Ergebnis auf sie anwendet. Die Estate-Ansicht listet die Deployments auf, die Stella Ops ausgeführt hat; Sie müssen auch jede andere zählende Workload mitzählen, einschließlich derer, die andere Werkzeuge deployen, und derer, die das automatische Inventar nicht zeigt.

Was als verwaltete Platzierung zählt →

Nein. Fünf Replikate einer Workload in einer Umgebung sind eine Platzierung. Ein Neustart, ein erneutes Deployment oder das Ausrollen einer neuen Image-Version oder eines neuen Digests derselben Workload in derselben Umgebung fügt nichts hinzu.

Drei. Eine Platzierung ist eine Workload in einer Umgebung; eine Workload, die in Dev, Staging und Produktion läuft, ergibt also 3 Platzierungen, und zehn Workloads in drei Umgebungen ergeben 30. Umgebungen selbst werden nie begrenzt oder bepreist.

Nein. Es gibt keine Gebühr pro Scan, erneutem Scan, Schwachstellenbericht, Promotion oder Deployment. Das Scannen des Images oder Artefakts einer installierten Workload oder das Anwenden eines früheren Scan-Ergebnisses auf sie kann diese Workload für jede betroffene Umgebung in die Zählung der Platzierungen bringen. Jede Beziehung zwischen Workload und Umgebung zählt nur einmal, unabhängig von der Anzahl der Scans oder Berichte.

Das bloße Aufbewahren oder Ansehen eines Berichts ausschließlich als historischer Nachweis erzeugt keine Platzierung. Ein früheres Ergebnis als zutreffende Scan-Information für eine installierte Workload darzustellen, gilt als Anwenden dieses Ergebnisses. Das Scannen eines Images oder Artefakts, das in keiner Ihrer Umgebungen installiert ist, erzeugt keine Platzierung.

Der Produktiveinsatz mit mehr als 20 Platzierungen pro Installation erfordert den Plan Lizenziert: eine Lizenz für eine Platzierungskapazität, die mindestens der Zahl der von Ihnen verwalteten Platzierungen entspricht. Er kostet €100 pro Monat für eine Kapazität von bis zu 100 Platzierungen und darüber €1 pro Platzierung der Kapazität und Monat; oberhalb von 20 zählt jede Platzierung — die kostenlosen 20 werden nicht abgezogen —, eine Kapazität von 30 Platzierungen kostet daher €100 pro Monat, eine von 200 Platzierungen €200.

Kapazitätserhöhungen werden mit Ihrer Bestellung wirksam und ab diesem Datum anteilig berechnet; Verringerungen werden zur Verlängerung wirksam.

Wenn Sie bemerken, dass Sie Ihre Kapazität oder die kostenlosen 20 versehentlich überschritten haben, dürfen Sie ab diesem Zeitpunkt 14 Tage lang weiterarbeiten, während Sie die Nutzung reduzieren oder Kapazität bestellen. Diese Toleranz gilt für Versehen, nicht für vorsätzliche oder wiederholte Überschreitungen.

Sie können schon heute abonnieren: Schreiben Sie an sales@stella-ops.org; die Bestellung wird über einen autorisierten Verkäufer (Merchant of Record) abgewickelt. Der Online-Checkout ist in Kürze verfügbar.

Was wird es kosten? →

Der Plan Lizenziert hat ein monatliches Minimum von €100, und dieses Minimum deckt bis zu 100 Platzierungen ab: 21 Platzierungen und 100 Platzierungen kosten beide €100 pro Monat. Ab 101 Platzierungen beträgt der Preis €1 pro Platzierung — 101 kosten €101, 150 kosten €150.

Es wird nichts abgeschaltet. Das aktuelle Release setzt das Platzierungslimit nicht durch und prüft keine Lizenz; Ihre Software, Workloads, Scans und Deployments laufen also weiter, und jeder Nachweisdatensatz bleibt mit Ihrem eigenen Vertrauensanker verifizierbar.

Bezahlte Kapazität ist jedoch für die Laufzeit des Abonnements lizenziert. Nach Ende der Laufzeit erfordert der Produktiveinsatz mit mehr als 20 Platzierungen eine Verlängerung oder eine Reduzierung auf 20 oder weniger Platzierungen.

Nein. Es gibt keinen Lizenzserver, keine Aktivierung und keine Rückmeldung an uns (Phone-Home): Das aktuelle Release prüft keine Lizenz, daher ist eine Air-Gap-Installation genauso lizenziert wie eine verbundene. Ihre kostenlose Nutzung legen die Lizenzbedingungen fest, bezahlte Kapazität Ihre Bestellung — nicht eine Verbindung zu uns.

Updates der Schwachstelleninformationen erreichen eine Offline-Installation über das Offline Kit, und das Alter der Feeds wird pro Quelle auf dem Bildschirm angezeigt.

Durch Ihre Bestellung. Der Plan Lizenziert wird über einen autorisierten Verkäufer (Merchant of Record) für eine Platzierungskapazität gekauft, die mindestens der Zahl der von Ihnen verwalteten Platzierungen entspricht, und die angenommene Bestellung nennt diese Kapazität und die Laufzeit im Rahmen des Stella Ops Customer Agreement.

Das aktuelle Release importiert oder prüft diese Angaben nicht; die Installation innerhalb dieses Rahmens zu halten, liegt daher in Ihrer Verantwortung. Endet die Laufzeit, wird in der Software nichts abgeschaltet, der Produktiveinsatz mit mehr als 20 Platzierungen erfordert dann aber eine Verlängerung oder eine Reduzierung auf 20.

Kundenvertrag (Customer Agreement) →

Nachweise, die Ihre Installation erzeugt, werden mit den eigenen Schlüsseln Ihrer Installation signiert, nicht mit unseren. Verifizieren Sie ein portables Nachweis-Bundle vollständig offline gegen den von Ihnen festgelegten Vertrauensanker: stella evidence verify-offline <bundle.tgz> --trust-root <keys.jwks.json|key.pem>. Geprüft werden die Prüfsummen, die Manifest-Bindungen und die Signatur; bei jedem Fehler schlägt die Prüfung fehl (fail-closed).

Stella-Ops-Releases werden separat signiert: Das Release-Bundle und die Images sind mit Cosign signiert, und der öffentliche Schlüssel steht auf der Seite mit den Verifikationsschlüsseln. Eine Release-Signatur zeigt, dass ein Bundle von uns stammt; eine Nachweissignatur zeigt, dass ein Datensatz aus Ihrer Installation stammt.

Verifikationsschlüssel →

Ja, über dieselben Schnittstellen, die auch eine Person nutzt. Ein CI-Job, ein Skript oder ein von Ihnen betriebener KI-Agent authentifiziert sich als OAuth-Service-Client mit Client Credentials und steuert Releases über die Release-API oder stella release approve|reject|promote|deploy|rollback. Genehmigungen und Policy-Gates wertet der Server aus, sodass für einen automatisierten Aufrufer dieselbe Policy gilt wie für eine Person.

Auch andere Scanner lassen sich einbinden: stella sbom upload importiert ein externes CycloneDX?Ein offenes Standardformat für Software Bill of Materials (SBOM), das branchenweit eingesetzt wird- oder SPDX?Software Package Data Exchange – ein weiteres offenes Standardformat für SBOMs, weit verbreitet in Open Source-SBOM und hält fest, welches Werkzeug es erzeugt hat, und stella gate score batch --sarif führt die SARIF-Befunde eines anderen Werkzeugs durch dasselbe Release-Gate.

Ein Review umfasst ein definiertes Problem. Eine Fachperson aus unserem Engineering analysiert die Informationen, die Sie senden, und antwortet mit einer schriftlichen technischen Stellungnahme: der wahrscheinlichen Ursache und den Korrektur- oder Diagnoseschritten, die wir empfehlen.

Nicht enthalten sind unbegrenzte Engineering-Stunden, individuelle Entwicklung, garantierte Behebung oder laufende Beratung, und es gibt keine fortlaufende Service-Level-Zusage. Vor dem Kauf nennen wir Ihnen ein geschätztes Zeitfenster für die Lieferung; sobald uns die nötigen Informationen vorliegen, antworten wir schriftlich innerhalb einer angemessenen Frist. Bevor wir Logs anfordern, erklären wir Ihnen, wie Sie Diagnosedaten sicher übermitteln. Um ein Review zu kaufen, schreiben Sie an support@stella-ops.org und beschreiben Sie das Problem kurz.

Zeigt das Review, dass das Hauptproblem ein reproduzierbarer Fehler in einem unterstützten, korrekt konfigurierten Release ist, wird die Gebühr erstattet — oder, wenn Sie das vorziehen, gutgeschrieben.

Dokumentation, Doctor-Diagnosen und Selbsthilfe bei der Fehlersuche sind für alle kostenlos, und für die Meldung eines Produktfehlers oder einer Sicherheitslücke ist nie ein kostenpflichtiges Review nötig.

Stella Ops befindet sich im Release Candidate (v1.0-RC1).

• Jetzt: v1.0.0-RC1-20261029 – das signierte Bundle und die Images sind öffentlich und werden anonym von get.stella-ops.org und registry.stella-ops.org bezogen
• Vor dem Release von v1.0: mindestens zwei Kunden im Produktionsbetrieb und eine eingefrorene öffentliche API-Oberfläche
• v1.0 wird am 1. Januar 2027 erwartet
• Der Code ist unter BUSL-1.1 source-available
• In beiden Fällen unverändert: rückwärtskompatible Nachweisformate und deterministische Wiedergabe

So starten Sie →

Die Verzeichnisanmeldung ist nicht standardmäßig aktiviert. Die LDAP-, OIDC- und SAML-Plugins werden mit v1.0.0-RC1-20261029 signiert ausgeliefert, und das Installationspaket enthält für jedes eine Konfigurationsdatei; eine Verzeichnisanmeldung ganz ohne Konfiguration bietet Stella Ops jedoch nicht: Sie richten ein Plugin auf Ihr Verzeichnis aus und aktivieren es.

Es ist auch kein Kubernetes-Werkzeug — das ist eine bewusste Positionierung, keine Lücke. Es scannt nicht nach Malware und liefert keine Compliance-Pakete für US-Bundesvorgaben. Ist einer dieser Punkte für Sie ausschlaggebend, passt heute etwas anderes besser.

Stella modelliert Releases als Freigabegraph (Dev → Stage → Prod). An jedem Gate:

• Die Policy wird gegen die Beweise des Artefakts ausgewertet
• Genehmigungen werden mit kryptographischen Signaturen aufgezeichnet
• Eine Decision Capsule wird für das Audit generiert

Freigaben sind an Artefakt-Digests gebunden, nicht an Tags. Gleicher Digest = gleiche Beweise wiederverwendet.

Stella Ops wird in Europa entwickelt und von einem in Bulgarien eingetragenen Unternehmen betrieben. Unsere eigene Infrastruktur — diese Website, die Registry und die Update-Kanäle — wird in der Schweiz gehostet, für die ein EU-Angemessenheitsbeschluss zum Datenschutz vorliegt. Kein Anbieter mit US-Hauptsitz sitzt in Ihrer Lieferkette. Vollständige Betreiberangaben finden Sie im Impressum.

Die Plattform wird selbst gehostet, sodass Ihre Artefakte, SBOMs und Nachweise auf Ihrer eigenen Infrastruktur bleiben – bei Bedarf air-gapped. Europäische Rechtsordnung plus Self-Hosting bedeutet: Ihre Release-Nachweise liegen ausschließlich bei Ihnen.

Eine berechtigte Frage für alles, was im Release-Pfad sitzt. Die Antwort liegt im Design: Der laufende Betrieb hängt nie davon ab, dass Sie uns erreichen. Das Produkt ist selbst gehostet und läuft air-gapped; es gibt keinen Lizenzserver und keine Cloud-Abhängigkeit von uns, und nichts im aktuellen Release prüft eine Lizenz. Endet ein Abonnement, wird daher nichts abgeschaltet — der Produktiveinsatz mit mehr als 20 Platzierungen erfordert dann jedoch eine Verlängerung oder eine Reduzierung auf 20.

Auch Ihre Nachweise brauchen uns nicht. Verdicts und Kapseln verifizieren offline — stella replay berechnet eine Entscheidung aus ihren versiegelten Eingaben neu, ohne dass ein Stella-Ops-Dienst oder -Konto beteiligt ist.

Der Code ist unter BUSL-1.1 source-available: Sie können die Version, die Sie betreiben, lesen, bauen und patchen. Die Lizenz hat zudem ein eingebautes Ablaufdatum — jede Version wechselt an ihrem Change Date zu einer offenen Lizenz, für die aktuelle Version spätestens am 20. Januar 2030. Für den täglichen Betrieb sind Sie ebenfalls nicht auf uns angewiesen: stella doctor führt die Diagnoseprüfungen der Installation aus, stella doctor export packt ein Bundle für den Support, und stella doctor fix wendet nicht destruktive Reparaturen an. Der Quellcode liegt unter git.stella-ops.org.

Im Alltag trägt sich das Produkt selbst. Doctor prüft den Zustand des Stacks und liefert zu jedem Befund die Behebungsschritte; innerhalb eines Wartungsfensters wendet es nicht-destruktive Korrekturen selbst an, destruktive nur hinter einem Freigabe-Gate mit Trockenlauf-Vorschau und dauerhaftem Audit-Eintrag — andernfalls erhalten Sie die manuellen Schritte. Menschliche Hilfe gibt es zusätzlich als kostenpflichtiges Review eines definierten Problems, nicht als das, was Ihre Installation am Laufen hält. Wenn Ihr Einkauf vertragliche Kontinuitätszusagen braucht, klären Sie diese während der Evaluierung mit sales@stella-ops.org.

Verifizierungsschlüssel, ein signiertes Nachweisbeispiel sowie Architektur- und Härtungsdokumentation sind öffentlich und auf der Seite zur Lieferanten-Sicherheitsprüfung gesammelt, die auch unseren Zertifizierungsstatus nennt. Kundenreferenzen folgen in Kürze – Ergebnisse aus unserer internen Beta. Due-Diligence-Gespräche können während der Evaluierung abgestimmt werden.

Lieferanten-Sicherheitsprüfung →

Bestellung, Zahlung, Steuern und Rechnungsstellung übernimmt ein autorisierter Verkäufer (Merchant of Record) — siehe den Checkout-Hinweis. Sie können schon heute per E-Mail bestellen: den Plan Lizenziert über sales@stella-ops.org, ein Support-Review über support@stella-ops.org. Der Online-Checkout ist in Kürze verfügbar.

Das Produkt ist darauf ausgelegt, ohne Ticket weiterzulaufen: Doctor prüft den Zustand des Stacks und wendet innerhalb eines Wartungsfensters nicht-destruktive Korrekturen selbst an; für alles, was es nicht unbeaufsichtigt erledigt, übergibt es Ihnen die exakten Schritte. Dokumentation, Doctor und Selbsthilfe bei der Fehlersuche sind in jedem Plan kostenlos. Wenn Sie eine Fachperson aus dem Engineering brauchen, kostet ein Support-Review €75 für ein definiertes Problem: Vor dem Kauf erhalten Sie ein geschätztes Zeitfenster für die Lieferung, danach eine schriftliche technische Antwort, und die Gebühr wird erstattet, wenn sich das Hauptproblem als reproduzierbarer Fehler in einem unterstützten, korrekt konfigurierten Release herausstellt. Kein Plan enthält eine fortlaufende Service-Level-Zusage. Wer auch antwortet: Es ist das Engineering-Team, das das Produkt baut — der Support ist nicht ausgelagert.

Stella Ops Suite ist source-available unter BUSL-1.1. Sie können den Code lesen, bauen und prüfen. Die Verifizierungsschicht (Kapselvalidierung, Signaturprüfungen) ist unter Apache-2.0 lizenziert. Der Quellcode liegt unter git.stella-ops.org.

BUSL-1.1 erlaubt den kostenlosen Produktiveinsatz für bis zu 20 verwaltete Platzierungen pro Installation. Darüber hinaus erfordert der Produktiveinsatz den Plan Lizenziert, eine Lizenz für die Zahl Ihrer Platzierungen. Nach dem Change Date — vier Jahre nach jedem Release — wechselt der Code zu Apache-2.0.

Dieses Modell finanziert nachhaltige Entwicklung und hält gleichzeitig die Beweiskette vollständig überprüfbar.

Ein Mandant ist ein isolierter Arbeitsbereich mit eigenen Benutzern, Rollen, Policies und eigener Nachweishistorie. Wird ein Mandant gesperrt, werden alle seine Zugänge eingefroren.

Mandanten teilen sich eine Installation; Nachweise und Zugriffe sind pro Mandant getrennt. Die beiden Begriffe beantworten unterschiedliche Fragen:

• Eine Umgebung (Environment?Ein logisches Deployment-Ziel (z. B. dev, staging, prod), das eigene Release-Historie, Promotion-Regeln und Policy-Gates verfolgt) ist ein Deployment-Ziel — wo ein Release läuft und welche Policy über seine Promotion entscheidet.
• Ein Mandant ist eine Zugriffs- und Nachweisgrenze — wer sehen und handeln darf und in wessen Nachweishistorie die Einträge landen.

Ein Mandant umfasst normalerweise mehrere Umgebungen. Weder Mandanten noch Umgebungen werden bepreist: Gezählt werden die verwalteten Platzierungen in der gesamten Installation.

Ja. Stella ist die Kontrollschicht über jedem Scanner, den Sie betreiben, und dessen Ergebnis hat einen Platz: stella sbom upload nimmt ein externes CycloneDX?Ein offenes Standardformat für Software Bill of Materials (SBOM), das branchenweit eingesetzt wird- oder SPDX?Software Package Data Exchange – ein weiteres offenes Standardformat für SBOMs, weit verbreitet in Open Source-Dokument entgegen und hält fest, welches Werkzeug es erzeugt hat, und stella gate score batch --sarif führt die SARIF-Ausgabe jedes beliebigen Erzeugers durch dasselbe Release-Gate wie Stellas eigene Scans.

Auf diese Befundliste setzt Stella Erreichbarkeitsanalyse, VEX?Vulnerability Exploitability eXchange – maschinenlesbare Aussagen darüber, ob Schwachstellen in Ihrem Kontext tatsächlich ausnutzbar sind mehrerer Aussteller, umgebungsabhängige Policy-Gates und signierten Nachweisexport. Ihr Scanner findet CVEs; Stella entscheidet, welche davon zählen, und belegt die Entscheidung.

Erreichbarkeit berechnet Stella aus dem eigenen Scan des Digests. Ein importiertes SARIF trägt die Erreichbarkeit, die sein Erzeuger eingetragen hat — Stella liest dieses Feld, es leitet es nicht neu her.

Befehle wie in der Produktkonsole angezeigt (v1.0-RC1).

Vergleich mit Trivy · Vergleich mit Snyk · Vollständiger Vergleich →

Stella ist keine Schicht über Ihrem Deployment-Werkzeug — Stella ist ein Release-Orchestrator. Docker, Compose, SSH, WinRM, ECS, Nomad und Ansible sind als integrierte Ausführungs-Plugins enthalten. Auf den Zielen, die diese abdecken, führt Stella das Deployment selbst aus; es umhüllt kein Werkzeug, das dies bereits tut.

Ihre CI bleibt genau dort, wo sie ist, denn das Gate ist nur eine Binärdatei. Jede CI, die eine ausführen kann, ruft stella gate evaluate auf und reagiert auf den Exit-Code. stella ci init schreibt fertige Abläufe für GitHub Actions, GitLab CI und Gitea Actions; jede andere CI wird mit wenigen Zeilen von Hand angebunden.

Konnektoren gibt es für Gitea, GitHub App, GitLab, Jenkins, Harbor, Nexus, OCI?Open Container Initiative — der Industriestandard für Container-Image-Formate und Registries-Registries, Vault und Consul. Die praktische Aufteilung: Behalten Sie Ihre CI und entscheiden Sie je Umgebung, ob Stella das Deployment ausführt oder eines absichert, das Ihr vorhandenes Werkzeug ausführt.

Befehle wie in der Produktkonsole angezeigt (v1.0-RC1).

Vergleich mit Octopus Deploy · Was angebunden wird — und was keinen Konnektor braucht →

Ja. Stella liefert den Nachweis auf Artefaktebene, auf den sich ein Compliance-Programm beruft, den es aber selbst nicht erzeugen kann: für jedes Release was ausgeliefert ist, unter welchem Digest, durch welche Richtlinie freigegeben, von wem genehmigt und an welchem Tag. Dieser Datensatz stammt aus der Auslieferung selbst und läuft aus demselben Nachweis deterministisch erneut ab — was eine Prüfung nächstes Jahr sieht, ist genau das, was heute dort steht.

Dieser Datensatz lässt sich als acht signierte Aufsichtsprofile exportieren: NIS2-Erklärung zur Anwendbarkeit und Wirksamkeitsbericht; DORA-Informationsregister, Meldung schwerwiegender IKT-Vorfälle, Informationsaustausch nach Artikel 45 und TLPT-Nachweispaket; CRA-technische Dokumentation und Konformitätsdossier. Jedes Bündel ist versiegelt, signiert und offline gegen veröffentlichte Vertrauensanker prüfbar — die Signatur lässt sich ohne jeden Zugriff auf Ihre Stella-Instanz verifizieren.

An dem Programm, das Sie bereits betreiben, muss sich nichts ändern. Jeder Export ist eine übertragbare signierte Datei: Hängen Sie sie an die Kontrolle, die sie belegt, geben Sie sie einer Prüfstelle, oder holen Sie sie über die Assurance-Export-Schnittstelle ab. Und vor dem Export benennt eine Bereitschaftsprüfung je Profil genau, was noch fehlt — so zeigt sich eine Lücke, solange Sie sie noch schließen können, und nicht erst in der Prüfung.

Das Compliance-Feld, mit Quellen · Compliance-Pakete im Detail →