À propos du projet

# Zentra CLI Zentra est un CLI de sécurité applicative open-source et alimenté par l'IA, conçu pour les développeurs. Il analyse les bases de code pour détecter les risques de sécurité à l'aide d'analyses de framework, de modélisation des menaces, d'analyse statique (SAST), de chaîne d'approvisionnement, d'API et d'infrastructure en tant que code (IaC). Il peut fonctionner localement avec une interface terminal interactive ou en mode headless dans les pipelines CI. Le binaire est nommé `zentra`. ## Fonctionnalités - **Mode CI headless** pour GitHub Actions et les pipelines de merge request GitLab. - **Orchestration de scanners basée sur LLM** avec les fournisseurs Anthropic, compatibles OpenAI, Claude CLI et Codex CLI expérimental. - **Mode pentest dynamique par navigateur** pour les cibles autorisées. - **Plusieurs formats de sortie** : Markdown, JSON, SARIF et HTML stylisé sous `.zentra/`. - **Stockage des identifiants chiffré au repos** (DPAPI sur Windows, fichiers `0600` sur Unix). ## Installation ### Installation rapide (recommandée) Aucune chaîne d'outils Rust, clone de dépôt ou étape de compilation requise. ```bash curl --proto '=https' --tlsv1.2 -LsSf https://github.com/johannus22/zentra/releases/latest/download/zentra-cli-installer.sh | sh ``` Pour Windows PowerShell : ```powershell powershell -ExecutionPolicy Bypass -c "irm https://github.com/johannus22/zentra/releases/latest/download/zentra-cli-installer.ps1 | iex" ``` Ouvrez une nouvelle fenêtre de terminal ensuite pour que `zentra` soit disponible. Pour une installation manuelle, téléchargez une compilation depuis la [page Releases](https://github.com/johannus22/zentra/releases). > **Note Linux :** Le binaire est lié à `libdbus` au moment de l'exécution pour l'accès au trousseau du système d'exploitation. Sur les images minimales ou headless, installez-le d'abord (`sudo apt-get install -y libdbus-1-3` ou équivalent). Sinon, définissez `ZENTRA_NO_OS_KEYCHAIN=1` pour utiliser le stockage d'identifiants chiffré basé sur des fichiers. ### Installation depuis la source Compilez et exécutez localement : ```bash cargo build ``` Installez le binaire depuis la copie du dépôt : ```bash cargo install --path . ``` ## Utilisation La TUI est la principale expérience locale pour configurer les fournisseurs, démarrer les analyses et examiner les résultats. Le menu principal regroupe les tests de sécurité d'applications statiques (SAST), les tests de sécurité d'applications dynamiques (DAST) et les actions diverses. ### Commandes d'analyse Exécutez une seule famille de scanners : ```bash zentra scan --only sast zentra scan --only supply-chain zentra scan --only api zentra scan --only iac ``` Utilisez `--pack` pour donner à chaque scanner un pack de dépôt vérifié par contexte. L'état de l'analyse est stocké dans `.zentra/checkpoint.json` pour les exécutions incrémentales. SAST peut utiliser jusqu'à 50 tours de fournisseur ReAct ; les autres scanners utilisent jusqu'à 30. Les exécutions locales de `zentra scan` incluent un panneau de discussion (Chat) permanent en lecture seule. Le Chat répond aux questions limitées et expurgées sur l'analyse et le dépôt avec un profil en lecture seule (`list_files`, `read_file`, `grep_code` et commandes Git limitées). Il peut proposer des actions typées de focus/réexécution ou de catégorie de vulnérabilité, mais ni la sortie du modèle ni un appel d'outil ne peuvent en appliquer une sans confirmation locale. Les actions confirmées sont stockées dans le point de contrôle et appliquées uniquement lors de la prochaine analyse. Le Chat n'est pas disponible dans `zentra ci` ou d'autres chemins d'analyse headless. ### Analyse de sécurité CI Zentra inclut une commande CI dédiée : ```bash zentra ci ``` `zentra ci` n'est pas un alias pour `zentra scan`. Il détecte GitHub Actions ou GitLab CI, confirme que le travail s'exécute dans un pipeline PR/MR, exécute des scanners de sécurité ciblés sans TUI, écrit des artefacts CI et échoue uniquement pour les constatations au niveau ou au-dessus du seuil d'échec ou pour les échecs de scanner/système. Par défaut, `zentra ci` bloque la PR/MR sur toute constatation **Critique ou Élevée**. Les constatations Moyennes, Faibles et Informatives sont signalées mais ne font pas échouer le travail. #### Seuil d'échec Définissez la variable d'environnement `ZENTRA_CI_FAIL_THRESHOLD` (une de `critical`, `high`, `medium`, `low`, `info`) ou utilisez le champ `fail_threshold` dans `.zentra/config.json` pour conserver la politique. Exemple de travail GitHub Actions : ```yaml - name: Run Zentra CI env: ZENTRA_API_KEY: ${{ secrets.ZENTRA_API_KEY }} ZENTRA_PROVIDER_MODEL: ${{ vars.ZENTRA_PROVIDER_MODEL }} ZENTRA_CI_FAIL_THRESHOLD: critical run: zentra ci ``` #### GitLab CI Le flux de travail GitLab CI fournit un deuxième travail pour les pipelines de push vers `staging`. Il exécute une analyse complète du dépôt, ne fait jamais échouer le pipeline et crée ou met à jour un problème GitLab avec les étiquettes `security` et `zentra-triage`. Utilisez un jeton d'accès personnel avec le champ d'application `api` comme variable CI/CD masquée. Les artefacts CI se trouvent dans `.zentra/ci-report.md`, `.zentra/ci-report.json` et `.zentra/ci-report.html`. #### Variables d'environnement CI | Variable | Requise | Notes | |----------|----------|-------| | `ZENTRA_API_KEY` | oui | Secret — la clé API du fournisseur LLM | | `ZENTRA_PROVIDER_BASE_URL` | oui | Secret ou variable — par exemple, `https://api.anthropic.com` | | `ZENTRA_PROVIDER_MODEL` | oui | Variable — par exemple, `claude-sonnet-5` | | `ZENTRA_PROVIDER_KIND` | non | Par défaut `openai_compat` | | `ZENTRA_PROVIDER_REASONING_EFFORT` | non | Transmis aux fournisseurs compatibles OpenAI | | `ZENTRA_PROVIDER_CONTEXT_WINDOW` | non | Remplace la fenêtre de contexte par défaut du fournisseur | | `ZENTRA_CI_FAIL_THRESHOLD` | non | Sévérité minimale qui bloque la PR | Si aucune de `ZENTRA_API_KEY`, `ZENTRA_PROVIDER_BASE_URL` ou `ZENTRA_PROVIDER_MODEL` n'est définie, `zentra ci` revient au profil configuré avec `zentra config setup` dans `~/.zentra/config.toml`. ### Générer des flux de travail CI ```bash zentra init --ci github # créer un flux de travail GitHub Actions zentra init --ci gitlab # créer un travail GitLab CI ``` ### Mode pentest Zentra inclut un mode pentest dynamique autorisé pour les cibles web en direct : ```bash zentra pentest --url https://target.example --authorized \ --allow-host target.example \ --allow-host api.target.example ``` Le drapeau `--authorized` est requis, donc une analyse accidentelle échoue en mode fermé. N'exécutez ce mode que sur des systèmes que vous possédez ou pour lesquels vous avez une autorisation explicite de tester. Utilisez `--exclude-path` pour exclure des chemins et `--scope-domain` pour autoriser un domaine et tous ses sous-domaines. Le mode pentest utilise l'image Docker `zentra/pentest-sandbox:0.1.0` pour sa boîte à outils isolée. Définissez `ZENTRA_SANDBOX_IMAGE` et `ZENTRA_SANDBOX_VERSION` pour des images personnalisées. Une exécution de pentest utilise trois agents sandbox (Recon, Exploit, Validator) et génère des rapports avec des vecteurs de base CVSS v3.1. Répertoires de sortie : - Dans un projet initialisé : `./.zentra/pentest/<host>/<run-id>/` - À l'extérieur : `<Documents>/Zentra/pentest/<host>/<run-id>/` (ou `output_dir` configuré) ### Autres commandes ```bash zentra init # créer .zentra/config.json zentra scan --only sast # exécuter une famille de scanners zentra ci # analyse CI PR/MR headless zentra ci --refresh-architecture zentra ci --full --report-only # analyse complète sans bloquer un pipeline staging zentra security verify-audit [session] ``` ## Notes de sécurité - Zentra stocke les identifiants des fournisseurs en dehors du répertoire du projet dans un coffre-fort de secrets chiffré. DPAPI protège la clé de chiffrement des données sur Windows ; Unix utilise des permissions de fichiers restrictives et le backend de trousseau disponible. - Les outils de fichiers bloquent le traversement de chemin et limitent les lectures de fichiers. - Le Chat interactif utilise un profil d'outils séparé, limité et en lecture seule. - L'enveloppe de sécurité par défaut enregistre une chaîne d'audit infalsifiable, contrôle les appels d'outils et marque la sortie d'outil non fiable. Définissez `ZENTRA_SECURITY=hardened` pour appliquer la liaison de réponse et l'abandon en cas d'injection ; utilisez `ZENTRA_SECURITY=off` uniquement pour le développement local de confiance. - Vérifiez une chaîne d'audit avec `zentra security verify-audit [session]`. - Les outils d'audit de l'historique Git et des dépendances se dégradent gracieusement lorsque les binaires ou l'historique requis ne sont pas disponibles. ## Structure du projet - `.zentra/config.json` — configuration du projet - `.zentra/checkpoint.json` — état de l'analyse pour les exécutions incrémentales - `.zentra/reports/findings.html` — rapports HTML - `.zentra/architecture.md` — sortie d'analyse de framework utilisée comme contexte CI Ne commettez pas de secrets ou d'état d'analyse dans le contrôle de version.