CoRoid übernimmt die autonome Softwareentwicklung für Ihren Code. Diese Seite erläutert, wo diese Arbeit ausgeführt wird, welche Ziele sie erreichen kann, wie Zugangsdaten und Daten geschützt werden sowie welche Aufzeichnungen dabei entstehen. Sie beschreibt die derzeit vorhandenen Kontrollmechanismen. Geplante Kontrollen werden als „geplant“ gekennzeichnet.
Wo die Agentenarbeit ausgeführt wird
Jede Aufgabe läuft in ihrem eigenen isolierten Cloud-Arbeitsbereich. Der Arbeitsbereich wird für diese Aufgabe erstellt und nach Abschluss wieder gelöscht. Die Agenten lesen und schreiben nur in das darin eingecheckte Repository.
Es gibt drei Zonen:
| Zone | Inhaber | Was sie enthält |
|---|---|---|
| Agent-Arbeitsbereich | CoRoid | Das Checkout, die Build- und Test-Tools einer Aufgabe. Werden pro Aufgabe erstellt und nach Abschluss wieder gelöscht. |
| Steuerungsebene | CoRoid | Zeitplanung, Spezifikationen, Nachweise und Entscheidungshistorie. Enthält projektbezogene Zugangsdaten in verschlüsselter Konfiguration. |
| Ihr Netzwerk und die Produktionsumgebung | Sie | Ist vom Agent-Arbeitsbereich aus nicht erreichbar. |
- Agent-ArbeitsbereichBetrieben von CoRoidTools zum Auschecken, Erstellen und Testen einer einzelnen Aufgabe.
- SteuerungsebeneBetrieben von CoRoidZeitplanung, Spezifikationen, Nachweise und Entscheidungsnachverfolgung. Zugangsdaten bleiben verschlüsselt.
- Ihr Netzwerk und die ProduktionIhr eigener BereichKeine IDE-Erweiterung, kein lokaler Agent oder Netzwerkzugriff erforderlich.
Ein Agent-Arbeitsbereich kann nicht auf Ihr Netzwerk oder die Produktionsumgebung zugreifen.
Der einzige Ausweg ist ein pull request, über dessen Merge-Idee Ihr Team entscheidet.
Die Ergebnisse der Arbeit werden in einer einzigen Form aus dem Arbeitsbereich übergeben: einem pull request. Ihr Team entscheidet, ob dieser in den Hauptzweig übernommen wird, und anschließend erfolgt die eigene Bereitstellung über Ihren eigenen Weg. CoRoid benötigt weder eine IDE-Erweiterung, noch einen lokalen Agenten oder Zugriff auf Ihr privates Netzwerk.
Welche Internetadressen ein Arbeitsbereich erreichen kann
Ein Arbeitsbereich, der Ihren Code buildet und testet, greift direkt auf öffentliche Internetadressen zu, sodass Installationen und Downloads wie auf einem Entwicklerrechner funktionieren. Private Adressen – das interne Netzwerk des Clusters, der Cloud-Metadienst und private Bereiche – sind für ihn gesperrt.
Sandbox-Netzwerk, unter Sicherheit → Einstellungen, leitet die Arbeitsbereiche eines Bereichs stattdessen über das Egress-Proxy von CoRoid weiter. Dieser ist deaktiviert, bis Sie ihn für die Organisationseinstellungen oder für ein einzelnes Projekt auf jedem Plan aktivieren:
- Aktiviert (beobachten). Jede Verbindung läuft über den Proxy, der Host und Port der Aufgabe aufzeichnet – niemals einen Pfad oder Inhalt. Nichts wird abgelehnt.
- Nicht erlaubte Anfragen ablehnen (erzwingen), im Schutz-Panel ausgewählt. Der Proxy ermöglicht den Zugriff auf öffentliche Paketregistries (npm, PyPI, Go Modules, crates.io, RubyGems, Maven Central und Gradle, NuGet, Packagist, Hex, pub.dev, Conda), den Git-Host Ihres Projekts sowie die Hosts auf der Erlaubnisliste der Einstellung. Alles andere wird abgelehnt. Wenn nach einer Ablehnung ein Befehl fehlschlägt, wird dem Agenten mitgeteilt, welcher Host abgelehnt wurde und warum.
Das Panel zeigt wo die Sandboxes verbunden waren in den letzten 30 Tagen: jeder Host und Port, wie viele Aufgaben und Verbindungen es gab, die letzte Aufgabe, die darauf zugegriffen hat, sowie ob der Zugriff erlaubt, abgelehnt oder unter „Erzwingen“ mit der aktuellen Liste abgelehnt würde. Erlauben fügt einen Host zur Liste hinzu. Beginnen Sie mit der Beobachtungsfunktion: Die Liste zeigt an, was „Erzwingen“ ablehnen würde, bevor Sie es aktivieren.
Die Netzwerk Im Abschnitt „Factory-Ansicht“ werden die Ziele aufgelistet, die von den Arbeitsbereichen erreicht wurden – zuerst die abgelehnten Ziele. Ein von CoRoid selbst durchgeführter Scan (beispielsweise ein Sicherheitsscan) hält seinen Arbeitsbereich in einer eigenen Aufgabe fest; diese Aufgabe gibt an, um welchen Scan es sich handelt, und listet die Ziele auf dieselbe Weise auf.
In beiden Modi schlägt eine Verbindung, die das Proxy umgeht – etwa eine direkte TCP-Verbindung –, fehl, und das Proxy stellt niemals eine Verbindung zu einer privaten Adresse her. Tools finden das Proxy über die Standard-Proxy-Variablen, die von CoRoid festgelegt werden; Maven liest sein Proxy nur aus settings.xml, sodass ein Maven-Build bei aktiviertem Sandbox-Netzwerk kein Internet erreichen kann. Namensauflösungen erfolgen weiterhin über den Resolver des Clusters. Eine Änderung wirkt sich auf nach ihr erstellte Arbeitsbereiche aus.
Jeder Eintrag der Erlaubnisliste ist ein Host (api.example.com), seine Subdomänen (*.example.com), oder beides mit einem Port (example.com:8443; ohne Port werden 80 und 443 verwendet). Ein Projekt mit eigener Konfiguration hat sein eigenes Modus und seine eigene Liste; Verwenden Sie
die Standardeinstellung stellt sie auf die der Organisation zurück. Die Einstellung wird mit
Einstellungs-Portabilitätzusammen mit den übrigen Einstellungen von „Sicherheit“ übertragen.
Identität und Zugriff
Die Authentifizierung ist im Gateway zentralisiert. Folgende Funktionen werden unterstützt:
- JWT-basierte Benutzersitzungen für den Portal-Zugriff
- Service-zu-Service-Tokens mit verwalteter Rotation
- API-Schlüssel für externe Integrationen
- Schutzmechanismen für Benutzer-, Service- und gemischte Zugriffsendpunkte
Der Zugriff auf das Repository ist auf das Projekt beschränkt. Die Zugangsdaten eines Projekts können nicht von einem anderen Projekt verwendet werden, und CoRoid benötigt keine organisationsweiten Zugangsdaten, um mit einem Repository zu arbeiten. Siehe Ihren Code verbinden.
Organisationsbesitzer und Administratoren verwalten Mitglieder, Sitzungen und das Sicherheits-Ereignisprotokoll unter Einstellungen → Identität und Zugriff. SSO/SAML mit SCIM-Bereitstellung ist Teil von „Enterprise“, das in privater Vorschau.
Datenschutz
- Daten werden während der Übertragung und im Ruhezustand verschlüsselt.
- Die Zugangsdaten Ihrer Organisation – wie Provider-Schlüssel, Repository-Tokens und andere Integrationsgeheimnisse – werden mit einem Datenverschlüsselungs-Schlüssel Ihrer Organisation verschlüsselt. Ein Schlüsselmanagementservice verschlüsselt diesen Datenverschlüsselungs-Schlüssel wiederum. Nur der Credential-Broker von CoRoid kann sie entschlüsseln, und jede Nutzung wird protokolliert. Siehe Anbieter-Schlüssel.
- Die eigenen Konfigurationsgeheimnisse von CoRoid werden verschlüsselt gespeichert.
- Der öffentliche Cloud-Dienst bietet ein EU-Hosting-Profil für Teams mit GDPR- oder Datenspeicherungsanforderungen. Das Nur in der EU AI-Profil sorgt dafür, dass die Modellinferenz bei in der EU gehosteten Anbietern erfolgt. Siehe AI-Profile.
- Sie bestimmen, wie lange Ausführungsverläufe, Transkripte und Artefakte aufbewahrt werden. Siehe Datenaufbewahrung.
Die Entscheidungskette
Jede autonome Änderung wird in Begriffen erklärt, die Rezensenten und Sicherheitsteams bereits kennen:
- Die Spezifikation, die Aktivität der Agenten, die Rezension und die Genehmigungsentscheidung bleiben mit der Aufgabe verknüpft.
- Der Ausführungsverlauf protokolliert jeden Agentenlauf, einschließlich fehlgeschlagener Versuche und deren Gründen.
- Der Verlauf der Pull-Requests zeigt die endgültigen Nachweise vor dem Zusammenführen des Codes.
- Nachweise zu Sicherheit, Abhängigkeiten, Codeabdeckung, visuellen Tests, End-to-End-Tests und Browser-Tests können einer Rezension beigefügt werden. Siehe Rezensionsnachweise.
Merge-Gates halten Produktionsänderungen hinter expliziten Richtlinien zurück. Nichts wird zusammengeführt ohne die Genehmigung Ihrer Qualitätsgates erfordern.
Produktionsbetrieb
- Erstellung von SBOMs und Scannen von Container-Images in der CI
- Öffentliche Endpunkte nur über HTTPS mit TLS-Terminierung
- Automatisierte Datenbank-Snapshots und Restore-Runbooks
- Überwachung und Alarmierung zu Metriken, Protokollen und Fehlern
Deploy-Optionen
CoRoid arbeitet in drei Betriebsmodellen. Der Arbeitsablauf ist in jedem Modell gleich; was sich ändert, ist der Ort von Laufzeitumgebung, Speicher, Repository-Zugriff und Zugangsdaten.
| Modell | Verfügbarkeit | Ausführungsort |
|---|---|---|
| Cloud | Allgemein verfügbar | Von CoRoid betrieben, mit optionalem EU-Hosting-Profil |
| Enterprise-Cloud | Private Preview | Von CoRoid betrieben, mit vertraglich vereinbartem Kapazitätsumfang, SSO/SAML, SCIM und Audit-Export |
| On-Premises | Private Preview | In Ihrer Infrastruktur, mit Docker Compose oder Kubernetes |
On-Premises
On-Premises-Deployments ermöglichen es regulierten Teams, Repository-Zugriff, Speicher, Anmeldeinformationen und Netzwerkrichtlinien innerhalb der von ihnen gesteuerten Infrastruktur zu belassen.
- Docker Compose eignet sich für Ein-Server-Installationen und Pilotprojekte. Persistente Volumes speichern die Datenbank, Repositorys und Protokolle.
- Kubernetes eignet sich für Multi-Server- und automatisch skalierbare Installationen. Helm verwaltet die Anwendungs-, Worker-, Sync- und Runner-Dienste und arbeitet mit verwalteten oder selbstgehosteten PostgreSQL-Instanzen sowie Objektspeichern zusammen.
- Eingeschränkte Netzwerke kann Offline-Modelle und Abhängigkeitsstrategien, selbstgehostete Geheimnisverwaltung und interne TLS nutzen.
Der Git-Zugriff verwendet persönliche Zugriffstoken statt einer Installation von Drittanbieter-Apps und kann auf interne Repository-Hosts verweisen.
Zertifizierungen
CoRoid verfügt derzeit über keinen SOC 2-Bericht oder andere Zertifizierungen durch Dritte. SOC 2 ist ein angestrebtes Ziel. Wir werden eine Kontrolle erst als zertifiziert bezeichnen, wenn dies der Fall ist.
Verwandt
- Sicherheit: das Finden und Beheben von Schwachstellen in Ihrem eigenen Code und den Abhängigkeiten
- Datenaufbewahrung
- Anbieter-Schlüssel
- Pläne und Preise
- Rezensionsnachweise