Guide de la version préliminaire · 0.1.0
Comment CodeSecurity s’articule
Suivez les droits sur les sources, les jobs durables et les éléments d’analyse dans l’interface locale.
La référence de l’API est en anglais.
CodeSecurity est un environnement local de sécurité avec deux clients : tableau de bord navigateur et extension VS Code. FastAPI sert l’application React compilée et l’API de contrôle. PostgreSQL conserve l’état applicatif. Un worker distinct exécute les commandes durables auprès de l’analyseur, du service de mise à jour des données et du connecteur Advisor facultatif.
Suivez une analyse des sources enregistrées aux éléments conservés. Chaque service a un rôle précis et sa propre frontière d’autorité.
Suivre une analyse dans le système
Clients opérateur
- Navigateur
Session opérateur associée et interface web.
- VS Code
Un profil d’éditeur approuvé avec des capacités limitées.
Entrée locale et état durable
- Relais loopback
Publie l’endpoint TCP local sans secrets d’exécution ni montages persistants.
- FastAPI + React
Sert l’interface et vérifie les requêtes de contrôle. Aucun socket Docker.
- PostgreSQL
Conserve état d’installation, commandes, jobs, constats et politiques.
- Worker de jobs
Revendique le travail durable et coordonne son résultat.
Services d’exécution bornée
- Analyseur
Lit les sources autorisées et données validées sur un réseau interne.
- Mise à jour
Récupère les données examinées sans montage des sources de projet.
- Connecteur Advisor
Exécute les requêtes facultatives avec des autorisations exactes.
Données et fournisseur facultatif
- Cache d’analyse validé
Les lecteurs voient une génération choisie en lecture seule.
- Fournisseur Ollama autorisé
Destination locale ou distante explicitement autorisée.
Connexions
Navigateur vers Relais loopback
Les requêtes navigateur entrent par l’endpoint loopback.
VS Code vers Relais loopback
Les requêtes éditeur utilisent le même endpoint avec leurs propres droits.
Relais loopback vers FastAPI + React
Le relais transmet le trafic TCP au service de contrôle.
FastAPI + React vers PostgreSQL
L’état est lu et modifié par des opérations admises.
Worker de jobs vers PostgreSQL
Baux et résultats sont persistés indépendamment de la page client.
Worker de jobs vers Analyseur
Le worker soumet l’analyse bornée et collecte les résultats.
Worker de jobs vers Mise à jour
La préparation est distincte de l’analyse des sources.
Analyseur vers Cache d’analyse validé
L’analyseur lit les données validées sélectionnées.
Mise à jour vers Cache d’analyse validé
Le service de mise à jour valide et choisit une génération complète.
Worker de jobs vers Connecteur Advisor
Le travail Advisor reçoit une autorisation fournisseur exacte.
Connecteur Advisor vers Fournisseur Ollama autorisé
Seuls la destination et le périmètre autorisés sont utilisés.
- L’opérateur autorise une racine précise ou fournit un instantané borné pris en charge. Créer un projet enregistre son identité source ; cela ne donne pas accès à un autre répertoire hôte.
- L’API vérifie le périmètre demandé et les prérequis actuels des analyseurs. Elle enregistre ensemble analyse et job durable.
- Le worker revendique le job avec un bail. L’analyseur revalide l’accès puis exécute les outils activés sur sa vue capturée et sa génération de données validée.
- La sortie native devient des constats bornés, normalisés et expurgés. Le worker valide manifeste et pages, puis valide en transaction les éléments admis et leur point de récupération dans PostgreSQL.
- Après cette transaction seulement, il acquitte le résultat exact pour permettre la suppression des sorties temporaires. Les éléments complets peuvent ensuite être évalués selon la politique du projet.
- Les clients actualisent les ressources faisant autorité lorsque jobs et constats changent. Conseil facultatif et décisions humaines sont séparés ; aucun ne fournit la couverture manquante.
Le chapitre jobs et éléments décrit les échecs et récupérations autour de ces étapes.
Placer les droits à chaque frontière
La configuration Compose principale expose une adresse loopback via un relais TCP non privilégié. Celui-ci transmet à l’API sans montages persistants ni configuration de secrets d’exécution. L’API n’a pas de socket Docker. Sessions navigateur et capacités limitées d’éditeur passent par la même frontière, avec des règles d’authentification différentes.
| Composant | Lecture et écriture | Rôle |
|---|---|---|
| API de contrôle | PostgreSQL, instantanés bornés et artefacts admis | Autorise les commandes, sert les ressources et enregistre l’état durable. Aucun montage des sources de projet. |
| Worker de jobs | PostgreSQL et stockage d’artefacts ; instantanés en lecture seule | Gère exécution, baux, progression, annulation et persistance. |
| Analyseur | Sources autorisées, instantanés et cache validé en lecture seule ; espace temporaire privé et sortie d’artefacts | Exécute les outils figés sélectionnés et publie un protocole de résultat borné. |
| Mise à jour des données | Cache accessible en écriture ; sources de téléchargement examinées | Prépare et active des générations complètes sans montage des sources de projet. |
| Connecteur Advisor | Autorisation fournisseur dédiée et routes approuvées | Exécute le travail Ollama local ou distant précisément autorisé. Aucun montage de projet. |
L’analyseur utilise un réseau interne. Mise à jour et connecteur Advisor ont des réseaux sortants distincts. Le worker appelle le connecteur pour les modèles locaux comme distants ; il n’envoie pas de prompts directement à Ollama. Ces frontières sont définies dans les sources. Contenu des images, montages effectifs et trafic sortant réel restent à vérifier pour l’installation évaluée.
Consultez droits des sources et clients pour ces décisions et services internes pour les protocoles.
Séparer les types d’état
| Question | État faisant autorité | Ce qu’il n’implique pas |
|---|---|---|
| La commande a-t-elle été acceptée ? | Job durable et identité de commande | Début ou réussite de l’exécution. |
| L’analyse est-elle complète ? | Statut, résultats des outils et résumé de couverture | Vérification de toute vulnérabilité possible. |
| Comment un constat a-t-il été examiné ? | Décision, raison et révision | Vérification d’un fichier modifié ou héritage par une nouvelle analyse. |
| Les éléments satisfont-ils la politique ? | Décision sur les éléments complets | Installation de protection ou autorisation d’un push. |
| Ce push protégé peut-il passer ? | Droits actuels du dépôt, arbres sortants, éléments et politique | Impossibilité de contourner le hook local. |
Cette séparation garde visible une analyse incomplète même si tous ses constats sont supprimés des comptes. Elle empêche aussi une réussite sur l’arbre de travail de remplacer les vérifications de commits sortants antérieurs. Les guides constats, contrôles et protection Git décrivent les parcours opérateur.
Comprendre ce qui persiste
PostgreSQL conserve projets, analyses, constats normalisés, politiques et jobs. Des volumes nommés contiennent artefacts admis, données des analyseurs et instantanés. Rapports natifs bruts et spool de transport ont une durée temporaire bornée. Ouvrir ou fermer une page ne détermine pas la vie d’un job.
C’est une conception applicative durable, pas une garantie de reprise après sinistre. Les sources documentent un outil de sauvegarde expérimental, non atomique et désactivé par défaut. Une récupération testée nécessite ses propres éléments et entrées exactes.
Les profils facultatifs de supervision, proxy Git local et administration de base sont désactivés par défaut. Ils ne font pas partie des droits de l’API principale et ne transforment pas l’interface en service hébergé.
Lire l’implémentation par responsabilité
| Domaine source | Point de départ |
|---|---|
| Services, montages et réseaux | Configuration Compose |
| Application de contrôle et persistance | Application API, modèle de données |
| Exécution et préparation | Architecture d’analyse |
| Actualisations navigateur et éditeur | Événements et réconciliation |
| Contributions | Points d’extension |
La politique de sécurité définit les hypothèses de confiance. CodeSecurity n’est pas un bac à sable pour dépôts hostiles. Un contrôle réussi est une décision de politique sur les éléments admis, pas une garantie de sûreté du code.