Häufig gestellte Fragen

Nein. Stella Ops ist für Non-Kubernetes-Umgebungen als primären Anwendungsfall konzipiert.

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 der Umgebung gebaut — VMs, Compose-Projekte, klassische Server — und die meisten Teams betreiben beides.

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.

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/deployed-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.

Bestandsansicht öffnen →

Ja. Stella arbeitet 100% offline ohne externe Abhängigkeiten.

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

Siehe 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.

Der Zieldatensatz enthält das Geheimnis nie — nur einen Verweis darauf. Das Geheimnis selbst wird mit AES-256-GCM unter einem pro Mandant abgeleiteten Schlüssel versiegelt, 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 gegatetes 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 gibt es selbst frei. Sie stellen eine befristete Policy-Ausnahme, die durch einen von Ihnen konfigurierten Genehmigungs-Workflow läuft: benannte Genehmiger-Rollen, eine Mindestzahl an Genehmigern, ein Grund-Code, 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 Grenze bleibt bewusst nicht aushebelbar: jedes deployte Artefakt muss einen echten Scanner-Pass tragen. Eine Ausnahme klärt einen bestimmten Policy-Befund; sie klärt nie die Anforderung, dass das Artefakt überhaupt gescannt wurde.

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 — Verzeichnis-Anmeldung ist noch nicht für den Produktionseinsatz validiert, betrachten Sie sie also als kommend und nicht als heute bewertbar.

Zugriff ist mandantenbezogen und rechtebasiert, nicht grob rollenförmig. 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 ist an eine Stufe gebunden: jede Fähigkeit ist in jeder Stufe enthalten, auch in Free.

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 diesen Datensatz schwer blind vertrauenswürdig und leicht überführbar.

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 →

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.

Auditoren erhalten Decision Capsules — kryptographisch signierte Beweispakete, die belegen:

• 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 Connector erforderlich – jedes CI, das eine Binärdatei ausführen kann, funktioniert. Stella nutzt signierte Digests und Beweise, 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 begründet 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 →

Mehr als der Tarif, den Sie bezahlen — vorerst. Bestellen Sie Plus vor und werden als Pro provisioniert: 100 Umgebungen statt 20, keine Scan-Obergrenze statt 50.000 pro Monat, kontinuierliche Schwachstellendaten statt täglicher, und der Pro-Support — 30 Tickets pro Jahr mit Reaktionsziel 1 Werktag statt 10 Tickets und 3 Werktagen bei Plus — zum Plus-Preis. Dieser Frühbucherpreis endet mit v1.0; bestellen Sie vorher, um ihn zu behalten. Ansonsten kauft eine Vorbestellung den Tarif genau wie auf dieser Seite beschrieben, und RC1 ist heute öffentlich, Sie können die Software also vor der Entscheidung betreiben. Bestellung, Zahlung und Rechnungsstellung übernimmt ein autorisierter Verkäufer (Merchant of Record); die Laufzeit des Upgrades bestätigen Sie beim Kauf mit dem Vertrieb.

Vollständige Preisdetails →

Das kostenlose Kontingent kostet €0: 3 Umgebungen und 100 Scans neuer Digests pro gleitende 24 Stunden, alle Funktionen enthalten. Kostenpflichtige Tarife erhöhen die Anzahl der Umgebungen und das Scanvolumen:

• Plus – €499 pro Monat: 20 Umgebungen
• Pro – €1.199 pro Monat: 100 Umgebungen
• Enterprise – individuell: Umgebungen, Scanvolumen und SLA werden ausgehandelt

Add-on für Plus: +10,000 zusätzliche Tiefenscans neuer Digests für €399

Alle Funktionen sind in jeder Stufe verfügbar – Compliance-Pakete sind nicht stufenweise unterteilt. Jährliche Abrechnung: 11 Monate bezahlen, 12 erhalten.

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.

Vollständige Preisdetails →

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

• Jetzt: v1.0.0-RC1 – 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
• Mit v1.0, erwartet zum 1. Januar 2027: der Early-Adopter-Vorbestellpreis endet. Bis dahin sind Vorbestellungen offen
• Der Code ist unter BUSL-1.1 source-available
• In beiden Fällen unverändert: rückwärtskompatible Nachweisformate und deterministische Wiedergabe

Fordern Sie einen frühen Zugang an →

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 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 Beweise auf Ihrer eigenen Infrastruktur bleiben – bei Bedarf mit Air Gap. Europäischer Betreiber · Hosting in der Schweiz · selbstgehostet · Air-Gap-fähig.

Eine berechtigte Frage für alles, was im Release-Pfad sitzt. Die Design-Antwort: Der laufende Betrieb hängt nie davon ab, uns zu erreichen. Das Produkt ist selbst gehostet und läuft air-gapped; es gibt keinen Lizenzserver und keine Cloud-Abhängigkeit von uns.

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 Stack 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. Menschlicher Support ist ein kostenpflichtiger Zusatz darüber hinaus und nicht 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 Checkout-Hinweis. Alles darüber hinaus besprechen Sie mit sales@stella-ops.org während der Evaluierung.

Das Produkt ist darauf ausgelegt, ohne Ticket weiterzulaufen: Doctor prüft den Stack und wendet innerhalb eines Wartungsfensters nicht-destruktive Korrekturen selbst an und übergibt Ihnen für alles Übrige die exakten Schritte. Darüber hinaus: Free und Plus sind self-serve – Dokumentation, Community-Diskussionen und Doctor-Diagnostik, ohne vertragliches Reaktionsziel. Pro ergänzt einen E-Mail-Support-Kanal mit Reaktionsziel 1 Werktag. Enterprise-Support, Reaktions- und Onboarding-Bedingungen werden per Vertrag vereinbart, abgestimmt mit sales@stella-ops.org während der Evaluierung. Wer auch antwortet: Es ist das Engineering-Team, das das Produkt baut – der Support ist nicht ausgelagert.

Stella Ops Suite ist quellenverfügbar unter BUSL-1.1. Sie können den Code lesen, erstellen 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 Produktiveinsatz innerhalb der kostenlosen Grenzen (3 Umgebungen, 100 Scans neuer Digests pro gleitende 24 Stunden). Darüber hinaus ist ein kostenpflichtiger Tarif erforderlich. Nach dem Änderungsdatum – vier Jahre nach jeder Release – wird der Code in Apache-2.0 konvertiert.

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

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?Ein logisches Deployment-Ziel (z. B. dev, staging, prod), das eigene Release-Historie, Promotion-Regeln und Policy-Gates verfolgt 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 – eine vollständige Liste aller Pakete und Abhängigkeiten in Ihrer Software, 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 – eine eindeutige Kennung für eine öffentlich bekannte Sicherheitslücke or advisory intelligence updates
• Querying existing Decision Capsules

Plus wird pro Kalendermonat gemessen: Das Kontingent wird am Monatsersten zurückgesetzt, Lastspitzen innerhalb eines Monats sind also unproblematisch. Pro hat kein Scan-Limit. Das kostenlose Kontingent hat überhaupt keinen Rücksetzzeitpunkt — die Lizenz erlaubt 100 neue Digest-Tiefenscans in jedem gleitenden 24-Stunden-Fenster, ein Scan zählt also 24 Stunden nach seiner Ausführung nicht mehr mit. Einen monatlichen Pool gibt es im kostenlosen Kontingent nicht.

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 →

Das kostenlose Kontingent erlaubt begrenzten Produktiveinsatz: alle Funktionen, bis zu 3 Umgebungen und 100 Scans neuer Digests pro gleitende 24 Stunden.

Für die Produktionsnutzung ist ein kostenpflichtiger Plan erforderlich – Plus (20-Umgebungen), Pro (100) oder Enterprise darüber hinaus.

Preisdetails →

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 exportiert als acht signierte Aufsichtsprofile: 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 →