Integrationen
Verbinden Sie die Quellen, die Freigabeentscheidungen ermöglichen
Für Build- und Scan-Nachweise ist überhaupt kein Connector erforderlich – das CLI signiert sie im Build-Job.
Vier Kategorien von Quellen speisen Release-Entscheidungen: Registries, Pipeline-Nachweise, Advisory- und VEX-Daten sowie Secrets. Alle landen im selben Nachweis-Rückgrat – Source → Build → Scan → Verdict → Decision → Deploy → Watch.
Connectoren sind nicht der Burggraben
Pipeline-Beweise (CLI): Diese Kategorie ist bewusst kein Connector. Build- und Scan-Nachweise benötigen weder SCM- noch CI-Connector und keinen eingehenden Webhook: Das CLI läuft in Ihrer vorhandenen Pipeline und übermittelt signierte Nachweise.
Connectoren sind konstruktionsbedingt die am leichtesten kopierbare Ebene – jeder Anbieter kann ein Logo-Raster nachbilden. Schwerer zu kopieren ist, was sie speisen: an der Quelle signierte, von der Control-Plane geprüfte und später wiederholbare Nachweise. Vergleichen Sie die Kette, nicht die Checkliste.
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.
Die CLI wird als fixiertes Container-Image ausgeliefert; auf dem Runner muss nichts installiert werden. registry.stella-ops.org/stella-cli:v1.0 lässt sich anonym abrufen — keine Zugangsdaten, keine CI/CD-Variable, nur ausgehender Zugriff auf die Registry. Runner ohne diesen Zugang verweisen STELLA_CLI_IMAGE stattdessen auf einen internen Spiegel.
$ docker run --rm \
-e STELLA_OCI_REGISTRY_USERNAME="$CI_REGISTRY_USER" \
-e STELLA_OCI_REGISTRY_PASSWORD="$CI_JOB_TOKEN" \
-v "$CI_PROJECT_DIR:/src:ro" \
registry.stella-ops.org/stella-cli:v1.0 \
sbom attach --generate --reachability --reachability-source /src \
--image "$IMAGE_REF" --digest "$IMAGE_DIGEST" \
--commit "$CI_COMMIT_SHA" --repo-url "$CI_PROJECT_URL" \
--source-id "gitlab-cr/$CI_PROJECT_PATH"
Befehle wie in der Produktkonsole angezeigt (v1.0-RC1).
Der Quellbaum wird schreibgeschützt unter /src eingehängt, damit der Reachability-Extraktor den Code lesen kann, aus dem das Image entstanden ist; der Container läuft als Nicht-Root-Benutzer. Registry-Zugangsdaten werden ausschließlich aus der Umgebung gelesen — die CLI nimmt sie nicht als Argumente an, sodass sie weder in Build-Logs noch in Prozesslisten gelangen können.
Beginnen Sie im Hinweismodus. In der Pipeline, aus der dieses Beispiel stammt, endet jeder Stella-Schritt mit || echo … (non-fatal): Der Build bleibt grün, unabhängig davon, ob die Nachweise ankommen — ein Team kann den Schritt also übernehmen, bevor es ihm vertraut. Das Erzwingen ist eine spätere, eigene Entscheidung und keine Voraussetzung für den Einstieg.
Sobald die Nachweise angehängt sind, kann eine spätere Stufe darauf blockieren: stella gate evaluate --env staging --image sha256:… fragt, ob dieser Digest in eine Umgebung darf.
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.
Nachweise fließen ausschließlich nach außen. Die CLI signiert die Build-Attestierung und pusht sie aus dem Job heraus; die Control Plane greift niemals herein, um sie abzuholen.
stella ci init erzeugt heute fertige Pipeline-Dateien für GitHub, GitLab und Gitea. Jedes andere CI-System ruft dieselbe CLI direkt auf — die Befehle sind identisch, nur das YAML drumherum unterscheidet sich.
Vorgeschlagene Setup-Reihenfolge
- 1 Registries – Quellen für Images und Digests
- 2 Pipeline-Nachweise (CLI) – im Build-Job signiert, kein Connector erforderlich
- 3 Advisory- und VEX-Quellen – halten Urteile aktuell
- 4 Secrets – authentifizieren die anderen Integrationen
Die Reihenfolge, die der Integrations-Hub des Produkts vorschlägt.
Die vier Quellen, auf denen eine Release-Entscheidung beruht
Container-Registries
Containerquellen, die Stella erkennt, scannt, versioniert und promotet. Der Digest ist die Identität, an die alles Weitere gebunden wird. Achten Sie auf neue Zusammenfassungen und ziehen Sie Bilder zum Scannen und Abrufen Promotion. Digest-firstRelease-Identität basierend auf unveränderlichen Inhalts-Hashes (SHA-256 Digests) statt veränderbarer Tags — für byte-identische Deployments
Docker Hub · Harbor · AWS ECR · Google GCR/Artifact Registry · Azure ACR · Jede OCIOpen Container Initiative — der Industriestandard für Container-Image-Formate und Registries-kompatible Registrierung — Alles, was der Distributionsspezifikation OCIOpen Container Initiative — der Industriestandard für Container-Image-Formate und Registries entspricht, funktioniert.
Pipeline-Nachweise über das CLI
Das CLI scannt jeden Build und signiert im Job eine Build-Attestierung (DSSEDead Simple Signing Envelope – ein einfacher, flexibler Standard zum Signieren beliebiger Daten mit kryptographischen Signaturen). Ihre Pipeline übermittelt die Nachweise; die Control-Plane greift nicht in Ihr Build-System ein, um sie abzurufen.
Advisory- und VEX-Quellen
Advisory-Feeds: NVDNational Vulnerability Database – das US-Regierungsverzeichnis standardbasierter Schwachstellendaten + OSVOpen Source Vulnerabilities – eine verteilte Schwachstellendatenbank für Open-Source-Projekte + GHSAGitHub Security Advisories – Sicherheits-Schwachstellendatenbank für Pakete auf GitHub · CISACybersecurity and Infrastructure Security Agency – US-Bundesbehörde für Cybersicherheitsrichtlinien und Schwachstellenkataloge KEVKnown Exploited Vulnerabilities – CISAs Katalog aktiv ausgenutzter Schwachstellen · Nationale CERTsComputer Emergency Response Teams – regionale Cybersicherheitsorganisationen, die Schwachstellenhinweise veröffentlichen · Anbieter-Feeds. See the full source breakdown →
VEX-Aufnahme: VEXVulnerability Exploitability eXchange – maschinenlesbare Aussagen darüber, ob Schwachstellen in Ihrem Kontext tatsächlich ausnutzbar sind-Anweisungen für Multi-Issuer-Vertrauen erfassen und erstellen Auflösung. OpenVEXEin offenes Standardformat für VEX-Aussagen über die Ausnutzbarkeit von Schwachstellen · CSAF 2.0 · Benutzerdefinierte Emittenten. Benutzerdefinierte Emittenten: Vom Anbieter veröffentlichter VEXVulnerability Exploitability eXchange – maschinenlesbare Aussagen darüber, ob Schwachstellen in Ihrem Kontext tatsächlich ausnutzbar sind mit konfigurierbaren Vertrauensgewichtungen. SBOM & VEX →
CSAF 2.0: Common Security Advisory Framework für strukturierte Empfehlungen.
Secrets
Anmeldedatenspeicher, aus denen nachgelagerte Integrationen lesen. Registry- und Bereitstellungs-Connectoren enthalten eine Secret-Referenz – niemals die Anmeldedaten selbst.
Integrierter Secret-Speicher · HashiCorp Vault · Azure Key Vault · AWS Secrets Manager · HSM / PKCS#11. Integrierter Secret-Speicher: Registrierungs- und Bereitstellungsanmeldeinformationen befinden sich im Secrets Store und werden zum Zeitpunkt der Ausführung eingefügt. Secret-Werte erscheinen weder in Nachweisartefakten noch in Kapseln.
Advisory- und VEX-Quellen
38 aktive Advisory-Quellen speisen die Schwachstellenbewertung – die aktuelle Anzahl wird in der Feed-Statusansicht des Produkts angezeigt. Die Feed-Aktualität löst Neubewertungen aus: Wird eine Quelle aktualisiert, werden betroffene Urteile erneut bewertet, statt auf veralteten Daten zu beruhen.
Widersprüchliche VEX-Aussagen werden durch ein dokumentiertes Sieben-Zustands-Gitter gelöst, und die Lösung selbst wird als Beweis aufgezeichnet.
Bereitstellungsziele
Gated Releases in Nicht-Kubernetes-Infrastruktur bereitstellen.
Docker Compose · SSH (Linux/Unix) · WinRM (Windows) · AWS / Fargate · HashiCorp · Skriptgesteuert (.NET 10)
Bereitstellungsziele sind in jedem Tarif unbegrenzt. Tarife messen Umgebungen und Scans neuer Digests – niemals Ziele.
The non-Kubernetes operating model Agentless SSH and WinRM deployment Bewegungen in der gesamten Systemlandschaft ansehen
Wer sich anmelden kann
The default setup uses local users held by Stella Ops. Passwords are hashed with Argon2id.
SAML-, OIDC- und LDAP/Active-Directory-Konnektoren werden signiert mit der Plattform ausgeliefert, und das Installationsbundle enthält für jeden eine Konfigurationsdatei. Das Aktivieren ist ein Konfigurationsschritt des Betreibers, kein Standard.
All access is tenant-scoped. A user acts inside one tenant, and roles are evaluated within that boundary. TenantAn isolated workspace with its own users, roles, policies, and evidence history. Tenants share an installation; evidence and access are separated per tenant, and suspending a tenant freezes all of its access
Konstruktiv begrenzter Umfang: Ihr Zugriff ist auf vier Dinge beschränkt. Umfassende Betreiber- oder Genehmigungsrechte sind niemals Voraussetzung für die Bereitstellung Ihres eigenen Dienstes.
- Ihre Dienste Sie sehen und aktualisieren die Ihnen zugewiesenen Dienste, nicht den gesamten Bestand.
- Ihre Repositories Der Zugriff folgt den an Ihre Dienste gebundenen Repositorys. Die Repositorys anderer Teams liegen außerhalb Ihres Zuständigkeitsbereichs.
- Ihre Image-Namespaces Kandidaten-Digests werden nur aus den an Ihren Dienst gebundenen Image-Namespaces akzeptiert, nicht aus beliebigen Registry-Bereichen.
- Ihre Umgebungen Sie agieren nur in den Umgebungen, die Ihre Rolle zulässt – direkte Aktualisierung oder Promotionsanfrage, je nach Umgebung.
Ihr Plattformteam muss Self-Service pro Umgebung aktivieren. Andernfalls führt Ihr Weg über eine Promotionsanfrage an die Genehmiger. Stella zeigt, welche Umgebungen Sie ändern dürfen, und erweitert diesen Umfang niemals eigenständig.
Mehr erfahren
Bereit, Ihre Toolchain zu verbinden?
Stella Ops funktioniert mit dem, was Sie bereits haben. Beginnen Sie mit einer einzigen Registrierung und erweitern Sie von dort aus.