Sécurité et déploiement

CoRoid effectue des travaux d'ingénierie autonomes sur votre code. Cette page décrit l'endroit où ces travaux s'exécutent, leur portée, la manière dont les identifiants et les données sont protégés, ainsi que les traces qu'ils laissent. Elle présente également les contrôles actuellement en place. Les contrôles prévus sont indiqués comme tels.

Lieu d'exécution des travaux des agents#

Chaque tâche s'exécute dans son propre espace de travail cloud isolé. Cet espace est créé pour cette tâche puis supprimé après son achèvement. Les agents ne lisent et n'écrivent que dans le dépôt qui y est extrait.

Il existe trois zones :

Le résultat du travail prend une forme unique : un pull request. Votre équipe décide de son intégration dans le code, puis votre propre processus de déploiement s'en charge ensuite. CoRoid n'a besoin ni d'extension IDE, ni d'agent local, ni d'accès à votre réseau privé.

Portées d'accès d'un espace de travail à Internet#

Un espace de travail qui compile et teste votre code accède directement aux adresses Internet publiques, afin que les installations et téléchargements fonctionnent comme sur une machine de développeur. Il n'atteint jamais les adresses privées : le réseau interne du cluster, le service de métadonnées du cloud et les plages d'adresses privées lui sont interdits.

Réseau de sandbox, sous Sécurité → Paramètres, et fait passer les espaces de travail d'une portée par le proxy d'egress de CoRoid à la place. Ce dernier est désactivé jusqu'à ce que vous l'activiez, que ce soit pour l'organisation entière ou pour un projet, sur tous les abonnements :

• Activé (observation). Toute connexion passe par le proxy, qui enregistre l'hôte et le port de la tâche, mais jamais le chemin ni le contenu. Rien n'est refusé.
• Refuser ce qui n'est pas autorisé (application stricte), sélectionné dans le panneau de configuration de la protection. Le proxy autorise les registres de paquets publics (npm, PyPI, modules Go, crates.io, RubyGems, Maven Central et Gradle, NuGet, Packagist, Hex, pub.dev, conda), l'hébergeur Git de votre projet ainsi que les hôtes figurant sur la liste d'autorisation définie dans les paramètres. Tout autre accès est refusé. Si une commande échoue après un refus, l'agent reçoit l'information concernant l'hôte qui a été refusé et la raison du refus.

Le panneau affiche les connexions des sandbox au cours des 30 derniers jours : chaque hôte et port, le nombre de tâches et de connexions, la dernière tâche ayant accédé à cet hôte, ainsi que si l'accès était autorisé, refusé ou le serait sous le mode application stricte avec la liste actuelle. Autoriser ajoute un hôte à la liste. Commencez en mode observation : la liste montre ce que le mode application stricte refuserait avant que vous l'activiez.

La section Réseau Dans la vue Usine, cette section liste les destinations atteintes par ses espaces de travail, en plaçant les refus en premier. Une analyse effectuée par CoRoid lui-même (par exemple une analyse de sécurité) conserve son espace de travail dans une tâche distincte ; cette tâche indique quel type d'analyse a été réalisé et liste ses destinations de la même manière.

Dans les deux modes, toute connexion contournant le proxy, comme une connexion TCP brute, échoue, et le proxy ne se connecte jamais à une adresse privée. Les outils détectent le proxy grâce aux variables de proxy standard définies par CoRoid ; Maven ne lit son proxy qu'à partir de settings.xml, donc une compilation Maven ne peut pas accéder à Internet lorsque le réseau de sandbox est activé. Les requêtes de résolution de noms passent toujours par le résolveur du cluster. Un changement s'applique aux espaces de travail créés après celui-ci.

Chaque entrée de la liste d'autorisation correspond à un hôte (api.example.com), ses sous-domaines (*.example.com), ou l'un ou l'autre avec un port (example.com:8443; sans port, les ports 80 et 443). Un projet disposant de sa propre configuration possède son propre mode et sa propre liste ; Utiliser le paramètre par défaut le ramène au paramètre de l'organisation. Ce réglage suit la portabilité des paramètres, tout comme les autres paramètres de la section Sécurité.

Identité et accès#

L'authentification est centralisée dans le portail. Il prend en charge :

• Des sessions utilisateur basées sur JWT pour l'accès au portail
• Des jetons service à service avec rotation gérée
• Les clés API pour les intégrations externes
• Des gardes pour les points de terminaison utilisateur, service et à accès mixte

L'accès au dépôt est limité au projet concerné. Les identifiants d'un projet ne peuvent pas être utilisés par un autre projet, et CoRoid n'a pas besoin d'identifiants à l'échelle de l'organisation pour travailler sur un dépôt. Consultez Connecter votre code.

Les propriétaires et administrateurs d'organisation gèrent les membres, les sessions et le flux d'événements de sécurité sous l'onglet Paramètres → Identité et accès. SSO/SAML avec approvisionnement SCIM fait partie de l'offre Entreprise, disponible dans aperçu privé.

Protection des données#

• Les données sont chiffrées en transit et au repos.
• Les identifiants de votre organisation, tels que les clés de fournisseur, les jetons de dépôt et autres secrets d'intégration, sont chiffrés à l'aide d'une clé de données appartenant à votre organisation. Un service de gestion des clés chiffre ensuite cette clé de données. Seul le broker d'identifiants de CoRoid peut les déchiffrer, et il enregistre chaque utilisation. Consultez Clés de fournisseur.
• Les secrets de configuration propres à CoRoid sont stockés sous forme chiffrée.
• Le service cloud public propose un Profil d'hébergement UE pour les équipes ayant des exigences liées à GDPR ou à la résidence des données. Le UE uniquement Le profil AI conserve l'inférence du modèle chez des fournisseurs hébergés en UE. Voir Profils AI.
• Vous contrôlez la durée de conservation de l'historique d'exécution, des transcriptions et des artefacts. Voir Conservation des données.

L'historique des décisions#

Chaque modification autonome est expliquée en termes que les réviseurs et les équipes de sécurité utilisent déjà :

• la spécification, l'activité de l'agent, la révision et la décision d'approbation restent liées à la tâche
• l'historique d'exécution enregistre chaque exécution d'agent, y compris les tentatives échouées et les raisons de leur échec
• l'historique des demandes de fusion montre les preuves finales avant la fusion du code
• Les preuves de sécurité, de dépendances, de couverture, visuelles, end-to-end et de tests navigateur peuvent être jointes à une révision. Voir Preuves de révision.

Les portes de fusion maintiennent les modifications en production derrière une politique explicite. Rien ne se fusionne sans l'approbation de votre portes de qualité l'exige.

Opérations de production#

• Génération de SBOM et analyse d'images conteneurisées dans l'CI
• Points de terminaison publics en HTTPS uniquement avec terminaison TLS
• Snapshots automatisés de base de données et procédures de restauration
• Surveillance et alertes sur les métriques, journaux et erreurs

Options de déploiement#

CoRoid fonctionne selon trois modèles opérationnels. Le flux de travail reste identique dans chaque cas ; ce qui change, c'est l'emplacement du runtime, du stockage, de l'accès au dépôt et des identifiants.

En local#

Les déploiements en local permettent aux équipes réglementées de conserver l'accès au dépôt, le stockage, les identifiants et la politique réseau au sein de l'infrastructure qu'elles gèrent.

• Docker Compose convient aux installations sur un seul serveur et aux pilotes. Des volumes persistants stockent la base de données, les dépôts et les journaux.
• Kubernetes convient aux installations sur plusieurs serveurs et à l'échelle automatique. Helm gère les services d'application, de travailleur, de synchronisation et d'exécution, et fonctionne avec PostgreSQL géré ou auto-hébergé ainsi qu'avec le stockage d'objets.
• Réseaux restreints peut utiliser des stratégies de modèle et de dépendances hors ligne, une gestion des secrets auto-hébergée et un TLS interne.

L'accès Git utilise des jetons d'accès personnels plutôt qu'une installation d'application tierce, et peut pointer vers des hébergeurs de dépôts internes.

Certifications#

CoRoid ne dispose pas actuellement d'un rapport SOC 2 ou d'une autre certification de sécurité tierce. La norme SOC 2 constitue une cible à atteindre. Nous ne qualifierons un contrôle de certifié qu'après l'avoir obtenu.

Articles associés#

• Sécurité: détecter et corriger les vulnérabilités dans votre propre code et vos dépendances
• Conservation des données
• Clés de fournisseur
• Plans et tarifs
• Preuves de révision