Cycode

officiel

Améliorez la sécurité de votre cycle de développement grâce à l'analyse SAST, SCA, des secrets et IaC avec Cycode.

Que pouvez-vous faire avec Cycode MCP ?

Rechercher des secrets — Demandez à l’assistant d’analyser des fichiers ou des répertoires à la recherche de secrets codés en dur à l’aide de cycode_secret_scan.
Rechercher des problèmes SCA — Demandez une analyse Software Composition Analysis pour détecter les vulnérabilités et les problèmes de licence via cycode_sca_scan.
Rechercher des erreurs de configuration IaC — Demandez à l’assistant de vérifier le code d’infrastructure à la recherche d’erreurs de configuration avec cycode_iac_scan.
Rechercher des problèmes SAST — Lancez une analyse Static Application Security Testing pour détecter les problèmes de qualité du code et les failles de sécurité à l’aide de cycode_sast_scan.
Vérifier l’état de la CLI — Demandez la version de Cycode CLI, l’état de l’authentification et les détails de configuration via cycode_status.

Documentation

Guide d’utilisation de Cycode CLI

Cycode Command Line Interface (CLI) est une application que vous pouvez installer localement pour analyser vos dépôts à la recherche de secrets, de mauvaises configurations d’infrastructure en tant que code, de vulnérabilités liées à l’analyse de la composition logicielle et de problèmes de tests de sécurité des applications statiques.

Ce guide vous accompagne dans l’installation et l’utilisation de l’application.

Table des matières

Prérequis
Installation
1. Installer Cycode CLI
2. Installer le hook Pre-Commit
Commandes Cycode CLI
Certificats et proxys
Commande MCP
Commande Platform
Garde-fous de l’IA
1. Données collectées par les garde-fous de l’IA
Commande Scan
Commande Report
1. Générer un rapport SBOM
Commande Import
Journaux d’analyse
Aide sur la syntaxe

Prérequis

L’application Cycode CLI nécessite Python version 3.10 ou ultérieure.
Utilisez la commande cycode auth pour vous authentifier auprès de Cycode avec la CLI
- Vous pouvez également obtenir un Cycode Client ID et un Client Secret Key en suivant les étapes détaillées dans les pages Service Account Token et Personal Access Token, qui expliquent comment obtenir ces valeurs.

Installation

Les étapes d’installation suivantes s’appliquent aux systèmes d’exploitation Windows et UNIX / Linux.

[!NOTE] Les étapes suivantes supposent l’utilisation de python3 et pip3 pour les commandes liées à Python ; toutefois, certains systèmes peuvent utiliser les commandes python et pip à la place, selon la configuration de votre environnement Python.

Installer Cycode CLI

Pour installer l’application Cycode CLI sur votre machine locale, procédez comme suit :

Ouvrez votre application de ligne de commande ou de terminal.
Exécutez l’une des commandes suivantes :
- Pour installer depuis PyPI :
```
pip3 install cycode
```
- Pour installer depuis Homebrew :
```
brew install cycode
```
- Pour installer depuis GitHub Releases, accédez à la page et téléchargez l’exécutable correspondant à votre système d’exploitation et à votre architecture, puis exécutez la commande suivante :
```
cd /path/to/downloaded/cycode-cli
chmod +x cycode
./cycode
```
Enfin, authentifiez la CLI. Il existe trois méthodes pour définir le client ID et les identifiants Cycode (client secret ou jeton d’ID OIDC) :
- cycode auth (Recommandé)
- cycode configure
- Ajoutez-les à vos variables d’environnement

Utiliser la commande Auth

[!NOTE] Il s’agit de la méthode recommandée pour configurer votre machine locale afin de vous authentifier auprès de Cycode CLI.

Saisissez la commande suivante dans votre fenêtre de terminal/ligne de commande :

cycode auth
Une fenêtre de navigateur s’ouvrira et vous demandera de vous connecter à Cycode (comme illustré ci-dessous) :
Saisissez vos identifiants de connexion sur cette page et connectez-vous.
Vous serez ensuite redirigé vers la page ci-dessous, où vous devrez choisir le groupe professionnel avec lequel vous souhaitez autoriser Cycode (le cas échéant) :

[!NOTE] Il s’agira de la méthode d’authentification par défaut pour Cycode CLI.
Cliquez sur le bouton Allow pour autoriser Cycode CLI dans le groupe professionnel sélectionné.
Une fois l’opération terminée, l’écran suivant s’affichera si la sélection a réussi :
Dans la fenêtre du terminal/de la ligne de commande, le message suivant s’affichera lorsque vous fermerez la fenêtre du navigateur :

Successfully logged into cycode

Utiliser la commande Configure

[!NOTE] Si vous avez déjà configuré votre Cycode Client ID et votre Client Secret dans les variables d’environnement Linux ou Windows, ces identifiants auront priorité sur cette méthode.

Saisissez la commande suivante dans votre fenêtre de terminal/ligne de commande :
```
cycode configure
```
Saisissez la valeur de votre Cycode API URL (vous pouvez laisser le champ vide pour utiliser la valeur par défaut).

Cycode API URL [https://api.cycode.com]: https://api.onpremise.com
Saisissez la valeur de votre Cycode APP URL (vous pouvez laisser le champ vide pour utiliser la valeur par défaut).

Cycode APP URL [https://app.cycode.com]: https://app.onpremise.com
Saisissez la valeur de votre Cycode Client ID.

Cycode Client ID []: 7fe5346b-xxxx-xxxx-xxxx-55157625c72d
Saisissez la valeur de votre Cycode Client Secret (ignorez cette étape si vous prévoyez d’utiliser un jeton d’ID OIDC).

Cycode Client Secret []: c1e24929-xxxx-xxxx-xxxx-8b08c1839a2e
Saisissez la valeur de votre jeton d’ID OIDC Cycode (facultatif).

Cycode ID Token []: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Si les valeurs ont été saisies correctement, le message suivant s’affichera :

Successfully configured CLI credentials!

ou/et

Successfully configured Cycode URLs!

Si vous accédez au dossier .cycode dans votre dossier utilisateur, vous trouverez ces identifiants dans le fichier credentials.yaml créé à cet emplacement. Les URL sont enregistrées dans le fichier config.yaml de ce dossier.

Ajouter aux variables d’environnement

Sur Unix/Linux :

export CYCODE_CLIENT_ID={your Cycode ID}

export CYCODE_CLIENT_SECRET={your Cycode Secret Key}

Si votre organisation utilise l’authentification OIDC, vous pouvez fournir le jeton d’ID à la place (ou en complément) :

export CYCODE_ID_TOKEN={your Cycode OIDC ID token}

Sur Windows

Dans le Panneau de configuration, accédez au menu Système :
Cliquez ensuite sur Paramètres système avancés :
Dans la fenêtre Propriétés système qui s’ouvre, cliquez sur le bouton Variables d’environnement :
Créez les variables CYCODE_CLIENT_ID et CYCODE_CLIENT_SECRET avec les valeurs correspondant respectivement à votre ID et à votre clé secrète. Si vous vous authentifiez via OIDC, ajoutez également CYCODE_ID_TOKEN avec la valeur de votre jeton d’ID OIDC :
Ajoutez le cycode.exe au chemin pour terminer l’installation.

Installer le hook Pre-Commit

Les hooks pre-commit et pre-push de Cycode peuvent être configurés dans votre dépôt local afin que l’application Cycode CLI détecte automatiquement les problèmes dans votre code avant que vous ne le validiez ou ne l’envoyiez vers votre base de code.

[!NOTE] Les hooks pre-commit et pre-push ne sont pas disponibles pour les analyses IaC.

Procédez comme suit pour installer le hook pre-commit :

Installer le hook Pre-Commit

Installez le framework pre-commit (Python 3.10 ou version ultérieure doit être installé) :
```
pip3 install pre-commit
```
Accédez au répertoire racine du dépôt Git local que vous souhaitez configurer.
Créez un fichier YAML nommé .pre-commit-config.yaml (en incluant le début .) dans le répertoire racine du dépôt, avec le contenu suivant :
```
repos:
  - repo: https://github.com/cycodehq/cycode-cli
    rev: v3.25.0
    hooks:
      - id: cycode
        stages: [pre-commit]
```
Modifiez le fichier créé selon vos besoins. Utilisez l’ID de hook cycode pour activer l’analyse des secrets. Utilisez l’ID de hook cycode-sca pour activer l’analyse SCA. Utilisez l’ID de hook cycode-sast pour activer l’analyse SAST. Pour activer tous les types d’analyse, utilisez cette configuration :
```
repos:
  - repo: https://github.com/cycodehq/cycode-cli
    rev: v3.25.0
    hooks:
      - id: cycode
        stages: [pre-commit]
      - id: cycode-sca
        stages: [pre-commit]
      - id: cycode-sast
        stages: [pre-commit]
```
Installez le hook Cycode :
```
pre-commit install
```
Si l’installation du hook réussit, le message suivant s’affichera : Pre-commit installed at .git/hooks/pre-commit.
Maintenez le hook pre-commit à jour :
```
pre-commit autoupdate
```
Cette commande mettra automatiquement à jour rev dans .pre-commit-config.yaml vers la dernière version disponible de Cycode CLI.

[!NOTE] Le déclenchement a lieu lors de la commande git commit. Le hook ne s’exécute que sur les fichiers indexés pour le commit.

Installer le hook Pre-Push

Pour installer le hook pre-push en plus du hook pre-commit ou à sa place :

Ajoutez les hooks pre-push à votre fichier .pre-commit-config.yaml :

repos:
  - repo: https://github.com/cycodehq/cycode-cli
    rev: v3.25.0
    hooks:
      - id: cycode-pre-push
        stages: [pre-push]

Installez le hook pre-push :

pre-commit install --hook-type pre-push

Pour les hooks pre-commit et pre-push, utilisez :

pre-commit install
pre-commit install --hook-type pre-push

[!NOTE] Les hooks pre-push se déclenchent lors de la commande git push et analysent uniquement les commits sur le point d’être envoyés.

Commandes Cycode CLI

Voici les options et commandes disponibles dans l’application Cycode CLI :

Option	Description
`-v`, `--verbose`	Afficher des journaux détaillés.
`--no-progress-meter`	Ne pas afficher l’indicateur de progression.
`--no-update-notifier`	Ne pas rechercher de mises à jour de la CLI.
`-o`, `--output [rich\|text\|json\|table]`	Spécifier le type de sortie. La valeur par défaut est `rich`.
`--client-id TEXT`	Spécifier un client ID Cycode pour cette exécution d’analyse.
`--client-secret TEXT`	Spécifier un client secret Cycode pour cette exécution d’analyse.
`--id-token TEXT`	Spécifier un jeton d’ID OIDC Cycode pour cette exécution d’analyse.
`--install-completion`	Installer la complétion pour le shell actuel..
`--show-completion [bash\|zsh\|fish\|powershell\|pwsh]`	Afficher la complétion pour le shell spécifié, afin de la copier ou de personnaliser l’installation.
`-h`, `--help`	Afficher les options de la commande indiquée.
Commande	Description
-------------------------------------------	----------------------------------------------------------------------------------------------------------------------------------------------
auth	Authentifiez votre machine pour associer la CLI à votre compte Cycode.
configure	Commande initiale pour configurer l’authentification de votre client CLI.
ignore	Ignorer une valeur, un chemin ou un ID de règle spécifique.
mcp	Démarrer le serveur Model Context Protocol (MCP) pour permettre l’intégration de l’IA aux capacités d’analyse de Cycode.
scan	Analyser le contenu pour détecter les violations Secrets/IaC/SCA/SAST. Vous`ll devrez préciser le type d’analyse à effectuer : historique des commits/chemin/dépôt/etc.
report	Générer un rapport. Vous devrez préciser le type de rapport à générer, par exemple SBOM.
status	Afficher l’état de la CLI et quitter.

Certificats et proxys

Par défaut, la CLI Cycode vérifie les connexions HTTPS à l’aide du bundle d’autorités de certification fourni avec la CLI.

Si votre organisation utilise un proxy qui inspecte le trafic HTTPS, ou une installation sur site avec sa propre autorité de certification, vous avez deux options.

Option 1 — utiliser les certificats déjà installés sur la machine. Si votre autorité de certification se trouve dans le magasin de certificats de la machine (comme c’est généralement le cas sur un appareil géré), activez cette option :

export CYCODE_CLI_ENABLE_TRUSTSTORE=1

La CLI vérifie alors les certificats à l’aide du magasin de certificats Windows, du trousseau d’accès macOS ou du répertoire des autorités de certification système sous Linux. Aucun chemin de certificat n’a besoin d’être configuré.

[!IMPORTANT] Cette option est désactivée par défaut, à dessein. Faire confiance au magasin de la machine revient à faire confiance à tous les certificats racines qui s’y trouvent, y compris ceux installés par un administrateur ou un logiciel malveillant. Activez cette option uniquement si vous savez que le magasin de certificats de votre machine est digne de confiance.

Option 2 — indiquer à la CLI le chemin d’un fichier de bundle d’autorités de certification. Fonctionne sans activation :

Variable d’environnement	Description
`REQUESTS_CA_BUNDLE`	Chemin vers un fichier de bundle d’autorités de certification (`.pem` ou `.crt`) auquel faire confiance.
`CURL_CA_BUNDLE`	Alias de `REQUESTS_CA_BUNDLE`, pris en compte si cette dernière n’est pas définie.

Les deux options peuvent être combinées : avec CYCODE_CLI_ENABLE_TRUSTSTORE=1, les certificats de REQUESTS_CA_BUNDLE sont approuvés en plus de ceux du magasin de la machine, et non à leur place.

[!TIP] Exécutez n’importe quelle commande avec -v pour voir quelle source de confiance est utilisée, par exemple cycode -v status.

Remarques :

Sous Windows, la CLI a toujours utilisé le magasin de certificats système comme solution de repli lorsque ni REQUESTS_CA_BUNDLE ni CURL_CA_BUNDLE n’est défini. Ce comportement ne change pas.
Les proxys eux-mêmes sont configurés à l’aide des variables d’environnement standard HTTP_PROXY, HTTPS_PROXY et NO_PROXY.

Commande MCP [EXPERIMENT]

La commande Model Context Protocol (MCP) permet de démarrer un serveur MCP qui expose les capacités d’analyse de Cycode aux systèmes et applications d’IA. Les modèles d’IA peuvent ainsi interagir avec les outils de la CLI Cycode via un protocole standardisé.

[!TIP] Pour une expérience optimale, installez la CLI Cycode globalement sur votre système à l’aide de pip install cycode ou brew install cycode, puis authentifiez-vous une seule fois avec cycode auth. Après l’installation globale et l’authentification, vous n’aurez pas besoin de configurer les variables d’environnement CYCODE_CLIENT_ID et CYCODE_CLIENT_SECRET dans vos fichiers de configuration MCP.

Démarrer le serveur MCP

Pour démarrer le serveur MCP, utilisez la commande suivante :

cycode mcp

Par défaut, le serveur démarre avec le transport stdio, adapté aux intégrations locales et aux applications d’IA capables de lancer des sous-processus.

Options disponibles

Option	Description
`-t, --transport`	Type de transport du serveur MCP : `stdio`, `sse` ou `streamable-http` (par défaut : `stdio`)
`-H, --host`	Adresse hôte à laquelle lier le serveur (utilisée uniquement pour les transports autres que stdio) (par défaut : `127.0.0.1`)
`-p, --port`	Numéro de port auquel lier le serveur (utilisé uniquement pour les transports autres que stdio) (par défaut : `8000`)
`--help`	Afficher le message d’aide et les options disponibles

Outils MCP

Le serveur MCP fournit les outils suivants, utilisables par les systèmes d’IA :

Nom de l’outil	Description
`cycode_secret_scan`	Rechercher des secrets codés en dur
`cycode_sca_scan`	Analyser la composition logicielle (SCA) pour détecter les vulnérabilités et les problèmes de licence
`cycode_iac_scan`	Analyser les erreurs de configuration de l’infrastructure en tant que code (IaC)
`cycode_sast_scan`	Effectuer des tests de sécurité statiques des applications (SAST) pour détecter les problèmes de qualité et les failles de sécurité
`cycode_status`	Obtenir la version de la CLI Cycode, l’état de l’authentification et les informations de configuration

Chaque outil d’analyse accepte deux modes d’entrée mutuellement exclusifs :

paths (recommandé) — un ou plusieurs chemins de fichiers ou de répertoires existant sur le disque. Les répertoires sont analysés de manière récursive. Le moteur Cycode gère la découverte et le filtrage des fichiers, comme le fait cycode scan -t <type> path ./src depuis la CLI.
files (solution de repli) — un dictionnaire associant des chemins de fichiers à leur contenu intégral sous forme de chaînes. Utilisez cette option uniquement lorsque les fichiers ne sont pas disponibles sur le disque (par exemple, pour des modifications en mémoire qui n’ont pas encore été enregistrées).

[!TIP] Utilisez paths dans la mesure du possible. Transmettre de gros fichiers (comme package-lock.json) en contenu intégré peut dépasser les limites de jetons et ralentir le client d’IA. Avec paths, le moteur Cycode lit directement les fichiers sur le disque.

Tous les outils d’analyse renvoient un objet JSON qui comprend un champ "summary" indiquant le nombre de violations dans un format lisible (par exemple "Cycode found 3 violations: 1 CRITICAL, 2 HIGH."), en plus du tableau complet "detections".

Exemples d’utilisation

Exemples de commandes de base

Démarrer le serveur MCP avec les paramètres par défaut (transport stdio) :

cycode mcp

Démarrer le serveur MCP avec le transport stdio explicite :

cycode mcp -t stdio

Démarrer le serveur MCP avec le transport Server-Sent Events (SSE) :

cycode mcp -t sse -p 8080

Démarrer le serveur MCP avec le transport HTTP diffusible sur un hôte et un port personnalisés :

cycode mcp -t streamable-http -H 0.0.0.0 -p 9000

Pour en savoir plus sur les types de transport MCP, consultez la spécification du protocole MCP – Transports.

Exemples de configuration

Utiliser MCP avec Cursor/VS Code/Claude Desktop/etc. (mcp.json)

[!NOTE] Pour les environnements Cycode de l’UE, veillez à définir les valeurs appropriées de CYCODE_API_URL et CYCODE_APP_URL dans les variables d’environnement (par exemple, https://api.eu.cycode.com et https://app.eu.cycode.com).

Suivez ce guide pour configurer le serveur MCP dans VS Code/GitHub Copilot. Notez que dans settings.json, il existe un objet mcp contenant un sous-objet imbriqué servers, plutôt qu’un objet mcpServers autonome.

Pour le transport stdio (exécution directe) :

{
  "mcpServers": {
    "cycode": {
      "command": "cycode",
      "args": ["mcp"],
      "env": {
        "CYCODE_CLIENT_ID": "your-cycode-id",
        "CYCODE_CLIENT_SECRET": "your-cycode-secret-key",
        "CYCODE_API_URL": "https://api.cycode.com",
        "CYCODE_APP_URL": "https://app.cycode.com"
      }
    }
  }
}

Pour le transport stdio avec une installation pipx :

{
  "mcpServers": {
    "cycode": {
      "command": "pipx",
      "args": ["run", "cycode", "mcp"],
      "env": {
        "CYCODE_CLIENT_ID": "your-cycode-id",
        "CYCODE_CLIENT_SECRET": "your-cycode-secret-key",
        "CYCODE_API_URL": "https://api.cycode.com",
        "CYCODE_APP_URL": "https://app.cycode.com"
      }
    }
  }
}

Pour le transport stdio avec une installation uvx :

{
  "mcpServers": {
    "cycode": {
      "command": "uvx",
      "args": ["cycode", "mcp"],
      "env": {
        "CYCODE_CLIENT_ID": "your-cycode-id",
        "CYCODE_CLIENT_SECRET": "your-cycode-secret-key",
        "CYCODE_API_URL": "https://api.cycode.com",
        "CYCODE_APP_URL": "https://app.cycode.com"
      }
    }
  }
}

Pour le transport SSE (Server-Sent Events) :

{
  "mcpServers": {
    "cycode": {
      "url": "http://127.0.0.1:8000/sse"
    }
  }
}

Pour le transport SSE sur un port personnalisé :

{
  "mcpServers": {
    "cycode": {
      "url": "http://127.0.0.1:8080/sse"
    }
  }
}

Pour le transport HTTP diffusible :

{
  "mcpServers": {
    "cycode": {
      "url": "http://127.0.0.1:8000/mcp"
    }
  }
}

Exécuter le serveur MCP en arrière-plan

Pour le transport SSE (démarrer d’abord le serveur, puis configurer le client) :

# Start the MCP server in the background
cycode mcp -t sse -p 8000 &

# Configure in mcp.json
{
  "mcpServers": {
    "cycode": {
      "url": "http://127.0.0.1:8000/sse"
    }
  }
}

Pour le transport HTTP diffusible :

# Start the MCP server in the background
cycode mcp -t streamable-http -H 127.0.0.2 -p 9000 &

# Configure in mcp.json
{
  "mcpServers": {
    "cycode": {
      "url": "http://127.0.0.2:9000/mcp"
    }
  }
}

Configuration avancée

Délais d’expiration et certificats personnalisés (environnements proxy)

Si votre client MCP interrompt les analyses de longue durée, augmentez le délai d’expiration des appels d’outils.

Variable d’environnement	Description
`MCP_TOOL_TIMEOUT`	Délai d’expiration (en secondes) pendant lequel les clients MCP tels que Claude et GitHub Copilot attendent la fin d’un appel d’outil. Augmentez cette valeur si les analyses de longue durée sont interrompues avant leur achèvement.

Derrière un proxy d’entreprise, définissez les variables de certificat dans le bloc env du serveur MCP. Consultez Certificats et proxys pour connaître les options : soit CYCODE_CLI_ENABLE_TRUSTSTORE=1 pour utiliser les certificats déjà présents sur la machine, soit REQUESTS_CA_BUNDLE pour indiquer le chemin d’un fichier de bundle d’autorités de certification.

Exemple de configuration mcp.json avec un bundle d’autorités de certification personnalisé et un délai d’expiration plus long :

{
  "mcpServers": {
    "cycode": {
      "command": "cycode",
      "args": ["mcp"],
      "env": {
        "REQUESTS_CA_BUNDLE": "/path/to/your/corporate-ca-bundle.pem",
        "MCP_TOOL_TIMEOUT": "1800"
      }
    }
  }
}

[!NOTE] Le serveur MCP nécessite une authentification valide à la CLI Cycode pour fonctionner. Veillez à vous être authentifié avec cycode auth ou à avoir configuré vos identifiants avant de démarrer le serveur MCP.

Préautoriser les outils pour les sous-agents (Claude Code)

Lorsque Claude Code délègue des tâches à des sous-agents en arrière-plan (par exemple, pour exécuter des analyses en parallèle), ces sous-agents ne peuvent pas afficher de demandes d’autorisation interactives. Si les outils Cycode n’ont pas été préapprouvés, les analyses échoueront silencieusement dans le contexte des sous-agents.

Pour préautoriser les outils MCP Cycode afin qu’ils fonctionnent dans tous les contextes, y compris ceux des sous-agents, ajoutez-les à la liste allowedTools dans les paramètres de Claude Code (~/.claude/settings.json) :

{
  "allowedTools": [
    "mcp__cycode__cycode_secret_scan",
    "mcp__cycode__cycode_sca_scan",
    "mcp__cycode__cycode_iac_scan",
    "mcp__cycode__cycode_sast_scan",
    "mcp__cycode__cycode_status"
  ]
}

Une fois les outils ajoutés, Claude Code ne demandera pas d’approbation lors de leur appel et ils fonctionneront correctement dans les sous-agents.

Dépannage de MCP

Si vous rencontrez des problèmes avec le serveur MCP, vous pouvez activer la journalisation de débogage pour obtenir des informations plus détaillées sur ce qui se passe. Il existe deux façons de l’activer :

À l’aide de l’option -v ou --verbose :

cycode -v mcp

À l’aide de la variable d’environnement CYCODE_CLI_VERBOSE :

CYCODE_CLI_VERBOSE=1 cycode mcp

Les journaux de débogage fournissent des informations détaillées sur :

Le démarrage et la configuration du serveur
Les tentatives de connexion et leur état
L’exécution des outils et leurs résultats
Les erreurs ou avertissements éventuels

Ces informations peuvent être utiles pour :

Diagnostiquer les problèmes de connexion
Comprendre pourquoi certains outils ne fonctionnent pas
Identifier les problèmes d’authentification
Déboguer les problèmes propres à un transport

Configuration MCP

Commande Platform [BETA]

[!WARNING] La commande platform est en bêta. Les commandes, arguments et formats de sortie sont générés dynamiquement à partir de la spécification de l’API Cycode et peuvent changer entre les versions sans préavis. Ne vous y fiez pas encore pour l’automatisation en production.

La commande cycode platform expose les API de lecture de la plateforme Cycode sous forme de commandes CLI. Elle regroupe les points de terminaison par ressource (par exemple, projects, violations, workflows) et convertit les paramètres de chaque point de terminaison en arguments CLI typés et en options --option.

cycode platform projects list --page-size 50
cycode platform violations count
cycode platform workflows view <workflow-id>

La spécification OpenAPI est récupérée depuis l’API Cycode lors de la première utilisation et mise en cache dans ~/.cycode/openapi-spec.json pendant 24 heures. Les commandes sans rapport (cycode scan, cycode status, etc.) ne déclenchent pas de récupération.

[!NOTE] Vous devez être authentifié (cycode auth ou variables d’environnement CYCODE_CLIENT_ID / CYCODE_CLIENT_SECRET) pour que cycode platform puisse découvrir et exécuter des commandes. Les autres commandes de Cycode CLI fonctionnent sans authentification.

Découvrir les commandes

Comme les commandes sont générées à partir de la spécification, la source de référence pour connaître les commandes disponibles est --help :

cycode platform --help                  # list all resource groups
cycode platform projects --help         # list actions on a resource
cycode platform projects list --help    # list options/arguments for an action

Exemples de plateforme

# List projects with pagination
cycode platform projects list --page-size 25

# View a single project by ID
cycode platform projects view <project-id>

# Count violations across the tenant
cycode platform violations count

# Filter using query parameters (see `--help` for what each endpoint supports)
cycode platform violations list --severity CRITICAL

Par défaut, toutes les sorties sont au format JSON — utilisez jq pour les filtrer à la volée :

cycode platform projects list --page-size 100 | jq '.items[].name'

Remarques et limites de la plateforme

Lecture seule pour le moment. Seuls les points de terminaison GET sont exposés dans cette version bêta.
Piloté par la spécification. L’ajout d’un nouveau point de terminaison à l’API le rend automatiquement disponible lors de la prochaine actualisation du cache.
Aucune spécification intégrée. La première invocation de cycode platform après l’installation (ou après l’expiration du cache de 24 h) effectue une requête réseau. Sur les connexions lentes, ce premier appel peut prendre quelques secondes ; les appels suivants sont presque instantanés jusqu’à l’expiration du cache.
Remplacez la durée de vie du cache avec CYCODE_SPEC_CACHE_TTL=<seconds>.

Garde-fous IA [BETA]

AI Guardrails installe des hooks dans les agents de codage IA pris en charge (Claude Code, Cursor, Copilot, Codex) afin que les prompts, les fichiers lus par l’agent et les arguments des outils MCP soient analysés à la recherche de secrets avant d’être transmis au modèle.

Données collectées par AI Guardrails

L’analyse s’effectue côté serveur ; le contenu analysé quitte donc la machine : le texte des prompts, le contenu des fichiers lus par l’agent et les arguments des outils MCP sont envoyés à votre tenant Cycode pour y détecter les secrets.

Chaque événement est également signalé avec des informations contextuelles sur le développeur et la machine, afin qu’une détection puisse être attribuée à l’appareil et à l’utilisateur concernés. Certaines de ces informations sont des données personnelles :

Identifiants de l’appareil — le nom d’hôte de la machine et son numéro de série matériel.
Identifiants de l’utilisateur — l’adresse e-mail de l’utilisateur connecté à l’agent de codage IA et le nom d’utilisateur du système d’exploitation local.
Détails de l’environnement — le système d’exploitation et sa version, l’agent IA, sa version et le modèle utilisé, le contenu des fichiers de configuration MCP de l’agent et ses extensions activées.

Le numéro de série matériel est mis en cache dans un fichier temporaire local, lisible uniquement par l’utilisateur ayant exécuté la commande, afin que les invocations répétées du hook ne relancent pas la recherche des informations matérielles.

Si la collecte de ces données n’est pas acceptable dans votre environnement, n’installez pas les hooks de garde-fous (cycode ai-guardrails uninstall supprime les hooks déjà installés).

Commande de scan

Exécuter un scan

L’application Cycode CLI propose plusieurs types de scans afin que vous puissiez choisir l’option la mieux adaptée à votre situation. Voici les options et commandes actuellement disponibles :

Option	Description
`-t, --scan-type [secret\|iac\|sca\|sast]`	Indiquez le scan à exécuter (`secret`/`iac`/`sca`/`sast`), la valeur par défaut est `secret`.
`--show-secret BOOLEAN`	Affiche les secrets en texte brut. Consultez la section Afficher/masquer les secrets pour plus de détails.
`--soft-fail BOOLEAN`	Exécute le scan sans échec et renvoie toujours un code de sortie sans erreur. Consultez la section Échec non bloquant pour plus de détails.
`--severity-threshold [INFO\|LOW\|MEDIUM\|HIGH\|CRITICAL]`	Affiche uniquement les violations du niveau indiqué ou d’un niveau supérieur.
`--sca-scan`	Indiquez le scan SCA à exécuter (`package-vulnerabilities`/`license-compliance`/`unmaintained-packages`/`malicious-packages`). La valeur par défaut est « all ».
`--monitor`	Si cette option est spécifiée, les résultats du scan sont enregistrés dans Cycode.
`--cycode-report`	Affiche un lien vers le rapport de scan sur la plateforme Cycode dans la sortie de la console.
`--no-restore`	Si cette option est spécifiée, Cycode n’exécute pas la commande de restauration. Seules les dépendances directes seront analysées !
`--stop-on-error`	Interrompt le scan en cas d’échec de collecte de fichiers ou de restauration de dépendances, au lieu d’ignorer le fichier concerné et de poursuivre.
`--gradle-all-sub-projects`	Exécute la commande de restauration gradle pour tous les sous-projets. Cette commande doit être exécutée depuis
`--maven-settings-file`	Pour Maven uniquement, permet d’utiliser un fichier settings.xml personnalisé lors de l’analyse des dépendances
`--help`	Affiche les options de la commande indiquée.

Commande	Description
commit-history	Analyse l’historique des commits ou effectue une analyse des différences entre des commits spécifiques
path	Analyse les fichiers du chemin fourni dans la commande
pre-commit	Analyse le contenu qui n’a pas encore été validé ; prend également en charge l’analyse locale des différences via des options (adaptée aux IDE)
repository	Analyse le dépôt git, y compris son historique

Options

Option de gravité

Pour limiter les résultats du scan à un seuil de gravité spécifique, vous pouvez ajouter l’argument --severity-threshold à la commande de scan.

Par exemple, la commande suivante analyse le dépôt à la recherche de violations de règles de gravité moyenne ou supérieure :

cycode scan --severity-threshold MEDIUM repository ~/home/git/codebase

Option de surveillance

[!NOTE] Cette option est disponible uniquement pour les scans SCA.

Pour envoyer à Cycode les résultats d’un scan de type SCA associés aux règles SCA, ajoutez l’argument --monitor à la commande de scan.

Par exemple, la commande suivante analyse le dépôt à la recherche de violations des règles SCA et les envoie à la plateforme Cycode :

cycode scan -t sca --monitor repository ~/home/git/codebase

Option de rapport Cycode

Pour chaque scan effectué avec Cycode CLI, un rapport est automatiquement généré et ses résultats sont envoyés à Cycode. Ces résultats sont associés aux règles pertinentes (par exemple, les règles SCA pour les scans de dépôt) sur la plateforme Cycode.

Pour afficher l’URL directe de ce rapport Cycode dans la sortie de votre CLI une fois le scan terminé, ajoutez l’argument --cycode-report à votre commande de scan.

cycode scan --cycode-report repository ~/home/git/codebase

Tous les résultats des scans effectués avec la CLI apparaissent dans la section des journaux de la CLI de Cycode. Si vous avez inclus l’option --cycode-report dans votre commande, un lien direct vers le rapport correspondant s’affiche dans votre terminal après les résultats du scan.

[!WARNING] Vous devez avoir le rôle owner ou admin dans Cycode pour consulter cette page.

cli-report

La page du rapport ressemblera à ceci :

Option de vulnérabilités des packages

[!NOTE] Cette option est disponible uniquement pour les scans SCA.

Pour analyser une vulnérabilité spécifique d’un package dans votre dépôt local, ajoutez l’argument --sca-scan package-vulnerabilities après l’option -t sca ou --scan-type sca.

Dans l’exemple précédent, pour exécuter un scan SCA portant uniquement sur les vulnérabilités des packages, vous pouvez lancer la commande suivante :

cycode scan -t sca --sca-scan package-vulnerabilities repository ~/home/git/codebase

Option de conformité des licences

[!NOTE] Cette option est disponible uniquement pour les scans SCA.

Pour analyser une branche spécifique de votre dépôt local, ajoutez l’argument --sca-scan license-compliance, suivi du nom de la branche à analyser.

Dans l’exemple précédent, pour analyser uniquement une branche nommée dev, vous pouvez lancer la commande suivante :

cycode scan -t sca --sca-scan license-compliance repository ~/home/git/codebase -b dev

Option des packages non maintenus

[!NOTE] Cette option est disponible uniquement pour les scans SCA.

Pour rechercher uniquement les packages non maintenus (packages dont le contrôle OpenSSF Scorecard Maintained est faible, ce qui signifie qu’ils ont peu ou pas d’activité récente en matière de commits et de problèmes), ajoutez l’argument --sca-scan unmaintained-packages après l’option -t sca ou --scan-type sca.

[!NOTE] La politique de votre organisation détermine si les packages non maintenus sont signalés. Cette option restreint les résultats du scan ; elle ne peut pas activer une règle désactivée pour votre tenant.

Dans l’exemple précédent, pour exécuter un scan SCA portant uniquement sur les packages non maintenus, vous pouvez lancer la commande suivante :

cycode scan -t sca --sca-scan unmaintained-packages repository ~/home/git/codebase

Option des packages malveillants

[!NOTE] Cette option est disponible uniquement pour les scans SCA.

Pour rechercher uniquement les packages malveillants (dépendances qu’un avis de sécurité a identifiées comme des logiciels malveillants, et non comme de simples dépendances vulnérables), ajoutez l’argument --sca-scan malicious-packages après l’option -t sca ou --scan-type sca.

Les violations liées aux packages malveillants sont toujours signalées comme Critical et ne comportent ni score CVSS ni version corrective : la seule mesure corrective consiste à supprimer la dépendance.

[!NOTE] La politique de votre organisation détermine si les packages malveillants sont signalés. Cette option restreint les résultats du scan ; elle ne peut pas activer une règle désactivée pour votre tenant.

Dans l’exemple précédent, pour exécuter un scan SCA portant uniquement sur les packages malveillants, vous pouvez lancer la commande suivante :

cycode scan -t sca --sca-scan malicious-packages repository ~/home/git/codebase

Option de restauration des fichiers de verrouillage

[!NOTE] Cette option est disponible uniquement pour les scans SCA.

Lors d’un scan SCA, Cycode CLI tente automatiquement de restaurer (générer) un fichier de verrouillage des dépendances pour chaque fichier manifeste pris en charge qu’il trouve. Cela permet d’analyser les dépendances transitives, et pas seulement celles répertoriées directement dans le manifeste. Pour ignorer cette étape et analyser uniquement les dépendances directes, utilisez l’option --no-restore.

Les écosystèmes suivants prennent en charge la restauration automatique des fichiers de verrouillage :

Écosystème	Fichier manifeste	Fichier de verrouillage généré	Outil invoqué (si le fichier de verrouillage est absent)
npm	`package.json`	`package-lock.json`	`npm install --package-lock-only --ignore-scripts --no-audit`
Yarn	`package.json`	`yarn.lock`	`yarn install --ignore-scripts`
pnpm	`package.json`	`pnpm-lock.yaml`	`pnpm install --ignore-scripts`
Deno	`deno.json` / `deno.jsonc`	`deno.lock`	(lecture du fichier de verrouillage existant uniquement)
Go	`go.mod`	`go.mod.graph`	`go list -m -json all` + `go mod graph`
Maven	`pom.xml`	`bcde.mvndeps`	`mvn dependency:tree`
Gradle	`build.gradle` / `build.gradle.kts`	`gradle-dependencies-generated.txt`	`gradle dependencies -q --console plain`
SBT	`build.sbt`	`build.sbt.lock`	`sbt dependencyLockWrite`
NuGet	`*.csproj`	`packages.lock.json`	`dotnet restore --use-lock-file`
Ruby	`Gemfile`	`Gemfile.lock`	`bundle --quiet`
Poetry	`pyproject.toml`	`poetry.lock`	`poetry lock`
pip	`pyproject.toml` / `requirements.txt`	`pylock.toml`	`pip lock .` / `pip lock -r requirements.txt -o pylock.toml`
Pipenv	`Pipfile`	`Pipfile.lock`	`pipenv lock`
PHP Composer	`composer.json`	`composer.lock`	`composer update --no-cache --no-install --no-scripts --ignore-platform-reqs`

Si un fichier de verrouillage existe déjà à côté du manifeste, Cycode le lit directement sans exécuter de commande d’installation. Prérequis SBT : Le plugin sbt-dependency-lock doit être installé. Ajoutez la ligne suivante à project/plugins.sbt :

addSbtPlugin("software.purpledragon" % "sbt-dependency-lock" % "1.5.1")

Option d’arrêt en cas d’erreur

Par défaut, Cycode poursuit l’analyse même si un fichier ne peut pas être lu (par exemple, en raison d’une erreur d’autorisation) ou si un fichier de verrouillage des dépendances ne peut pas être généré lors d’une analyse SCA. L’élément en échec est ignoré avec un avertissement, et l’analyse se poursuit avec les fichiers restants.

Utilisez --stop-on-error pour modifier ce comportement : l’analyse s’interrompt immédiatement à la première erreur de ce type et signale l’erreur.

cycode scan -t sca --stop-on-error path ~/home/git/codebase

Cette option est utile dans les pipelines CI, où un échec silencieux produirait un résultat d’analyse incomplet. Lorsque --stop-on-error est déclenché, vous pouvez soit corriger le problème sous-jacent, soit, uniquement pour les échecs de restauration SCA, ajouter --no-restore afin d’ignorer la génération du fichier de verrouillage et d’analyser uniquement les dépendances directes.

Lorsque --stop-on-error est utilisé, la CLI distingue les erreurs d’analyse des violations de stratégie au moyen de codes de sortie :

Code de sortie	Signification
`0`	Analyse terminée sans violation
`1`	Analyse terminée et violations détectées
`2`	Analyse interrompue en raison d’une erreur (uniquement lorsque `--stop-on-error` est défini)

Analyse du dépôt

Une analyse du dépôt examine l’ensemble d’un dépôt local à la recherche de secrets exposés ou de configurations non sécurisées. Ce type d’analyse plus global examine tout : l’état actuel de votre dépôt et son historique de commits. Il recherche non seulement les secrets actuellement exposés dans le dépôt, mais aussi ceux qui ont été supprimés auparavant.

Pour effectuer une analyse complète du dépôt, exécutez la commande suivante :

cycode scan repository {{path}}

Par exemple, pour analyser un dépôt stocké dans ~/home/git/codebase, vous pouvez exécuter la commande suivante :

cycode scan repository ~/home/git/codebase

L’option suivante est disponible pour cette commande :

Option	Description
`-b, --branch TEXT`	Branche à analyser ; si elle n’est pas définie, la branche par défaut est analysée

Option de branche

Pour analyser une branche spécifique de votre dépôt local, ajoutez l’argument -b (ou --branch), suivi du nom de la branche à analyser.

Dans l’exemple précédent, pour analyser uniquement une branche nommée dev, vous pouvez exécuter la commande suivante :

cycode scan repository ~/home/git/codebase -b dev

Analyse de chemin

Une analyse de chemin examine un répertoire local spécifique et tout son contenu, au lieu de se limiter à un dépôt GIT.

Pour effectuer une analyse de répertoire, exécutez la commande suivante :

cycode scan path {{path}}

Par exemple, si vous souhaitez analyser le répertoire situé à ~/home/git/codebase, vous pouvez exécuter la commande suivante :

cycode scan path ~/home/git/codebase

Analyse d’un plan Terraform

La CLI Cycode prend en charge l’analyse des plans Terraform (Terraform 0.12 et versions ultérieures).

Le fichier de plan Terraform doit être au format JSON (avec l’extension .json).

Si vous disposez uniquement d’un fichier de configuration, vous pouvez générer un plan comme suit :

Initialisez un répertoire de travail contenant un fichier de configuration Terraform :

terraform init
Créez un plan d’exécution Terraform et enregistrez la sortie binaire :

terraform plan -out={tfplan_output}
Convertissez le fichier de sortie binaire en JSON lisible :

terraform show -json {tfplan_output} > {tfplan}.json
Analysez votre {tfplan}.json avec la CLI Cycode :

cycode scan -t iac path ~/PATH/TO/YOUR/{tfplan}.json

Analyse de l’historique des commits

[!NOTE] L’analyse de l’historique des commits n’est pas disponible pour les analyses IaC.

La commande d’analyse de l’historique des commits offre deux fonctionnalités principales :

Analyse complète de l’historique : analyse tous les commits de l’historique du dépôt
Analyse des différences : analyse uniquement les modifications entre des commits spécifiques

L’analyse des secrets peut examiner tous les commits de l’historique du dépôt, car les secrets introduits puis supprimés peuvent tout de même avoir été divulgués ou exposés. Pour les analyses SCA et SAST, la commande d’historique des commits se concentre sur l’analyse des différences/modifications entre les commits, ce qui la rend idéale pour les revues de demandes de fusion et les analyses incrémentielles.

Une analyse de l’historique des commits examine l’historique des commits de votre dépôt Git et peut servir aussi bien à une analyse historique complète qu’à l’analyse ciblée des différences de modifications spécifiques.

Pour effectuer une analyse de l’historique des commits, exécutez la commande suivante :

cycode scan commit-history {{path}}

Par exemple, si vous souhaitez analyser l’historique des commits d’un dépôt stocké dans ~/home/git/codebase, vous pouvez exécuter la commande suivante :

cycode scan commit-history ~/home/git/codebase

Les options suivantes sont disponibles pour cette commande :

Option	Description
`-r, --commit-range TEXT`	Analyse une plage de commits dans ce dépôt git. Par défaut, cycode analyse tout l’historique des commits (exemple : HEAD~1)

Option de plage de commits (analyse des différences)

L’option de plage de commits permet d’effectuer une analyse des différences : elle analyse uniquement les modifications entre des commits spécifiques, plutôt que l’intégralité de l’historique du dépôt. Cette option est particulièrement utile pour :

La validation des demandes de fusion : analyser uniquement les modifications introduites dans une demande de fusion
L’analyse incrémentielle CI/CD : se concentrer sur les modifications récentes plutôt que sur l’ensemble du code
La revue des branches de fonctionnalités : comparer les modifications à la branche main/master
L’optimisation des performances : accélérer les analyses en limitant leur portée aux modifications pertinentes

Syntaxe des plages de commits

L’option --commit-range (-r) prend en charge la syntaxe standard des révisions Git :

Syntaxe	Description	Exemple
`commit1..commit2`	Modifications de commit1 à commit2	`abc123..def456`
`commit1...commit2`	Modifications présentes dans commit2, mais pas dans commit1	`main...feature-branch`
`commit`	Modifications du commit jusqu’à HEAD	`HEAD~1`
`branch1..branch2`	Modifications de branch1 à branch2	`main..feature-branch`

Exemples d’analyse des différences

Analyser les modifications du dernier commit :

cycode scan commit-history -r HEAD~1 ~/home/git/codebase

Analyser les modifications entre deux commits spécifiques :

cycode scan commit-history -r abc123..def456 ~/home/git/codebase

Analyser les modifications de votre branche de fonctionnalités par rapport à main :

cycode scan commit-history -r main..HEAD ~/home/git/codebase

Analyser les modifications entre main et une branche de fonctionnalités :

cycode scan commit-history -r main..feature-branch ~/home/git/codebase

Analyser toutes les modifications des 3 derniers commits :

cycode scan commit-history -r HEAD~3..HEAD ~/home/git/codebase

[!TIP] Dans les pipelines CI/CD, vous pouvez utiliser des variables d’environnement telles que ${{ github.event.pull_request.base.sha }}..${{ github.sha }} (GitHub Actions) ou $CI_MERGE_REQUEST_TARGET_BRANCH_SHA..$CI_COMMIT_SHA (GitLab CI) pour analyser uniquement les modifications d’une demande de fusion.

Analyse pré-commit

Une analyse pré-commit détecte automatiquement les problèmes avant que vous ne validiez des modifications dans votre dépôt. Il n’est pas nécessaire de lancer cette analyse manuellement ; configurez le hook pré-commit comme indiqué dans la section Installation de ce guide.

Après avoir installé le hook pré-commit, vous pouvez parfois souhaiter ignorer l’analyse lors d’un commit spécifique. Pour ce faire, ajoutez ce qui suit à votre commande git afin d’ignorer l’analyse pour un seul commit :

SKIP=cycode git commit -m <your commit message>`

Les options suivantes sont disponibles pour cette commande :

Option	Description
`-b, --base-ref TEXT`	Référence Git (commit, branche ou tag) à utiliser pour la comparaison ; par défaut, `HEAD`, conformément au comportement du hook pré-commit
`--include-unstaged`	Analyse également les modifications non indexées des fichiers suivis, et pas seulement celles indexées ; désactivé par défaut
`--path PATH`	Chemin(s) facultatif(s) pour limiter l’analyse des différences ; répétable ; par défaut, tout le répertoire de travail

Analyse locale des différences (intégrations IDE)

--base-ref et --include-unstaged transforment pre-commit en une analyse locale des différences polyvalente : elle compare n’importe quel commit (par défaut HEAD) à votre répertoire de travail actuel, y compris les modifications qui ne sont pas encore indexées. Cette fonctionnalité est destinée aux plugins IDE et autres outils qui nécessitent un retour continu et en temps réel pendant le travail, plutôt que le flux de travail du hook Git. Associé à --include-unstaged, --path permet à un IDE de limiter l’analyse au seul fichier actuellement ouvert dans l’éditeur.

[!NOTE] L’analyse locale des différences (à l’aide de ces options) n’est pas disponible pour les analyses IaC.

Analyser toutes les modifications actuelles (indexées et non indexées) par rapport au dernier commit :

cycode scan pre-commit --include-unstaged

Analyser les modifications par rapport à un commit ou une branche spécifique :

cycode scan pre-commit --include-unstaged --base-ref main

Analyser uniquement un fichier spécifique (par exemple, le fichier actuellement ouvert dans votre IDE) :

cycode scan pre-commit --include-unstaged --path src/app.py

Analyse pré-push

Une analyse pré-push détecte automatiquement les problèmes avant que vous ne poussiez des modifications vers le dépôt distant. Ce hook s’exécute côté client et analyse uniquement les commits sur le point d’être poussés, ce qui permet de détecter efficacement les problèmes avant qu’ils n’atteignent le dépôt distant.

[!NOTE] Le hook pré-push n’est pas disponible pour les analyses IaC.

Le hook pré-push s’intègre au framework pre-commit et peut être configuré pour s’exécuter avant toute opération git push.

Installation du hook pré-push

Pour configurer le hook pré-push à l’aide du framework pre-commit :

Installez le framework pre-commit (s’il n’est pas déjà installé) :
```
pip3 install pre-commit
```

Créez ou mettez à jour votre fichier .pre-commit-config.yaml pour y inclure les hooks pré-push :

repos:
  - repo: https://github.com/cycodehq/cycode-cli
    rev: v3.25.0
    hooks:
      - id: cycode-pre-push
        stages: [pre-push]

Pour plusieurs types d’analyse, utilisez cette configuration :

repos:
  - repo: https://github.com/cycodehq/cycode-cli
    rev: v3.25.0
    hooks:
      - id: cycode-pre-push          # Secrets scan
        stages: [pre-push]
      - id: cycode-sca-pre-push      # SCA scan
        stages: [pre-push]
      - id: cycode-sast-pre-push     # SAST scan
        stages: [pre-push]

Installez le hook pré-push :
```
pre-commit install --hook-type pre-push
```
Une installation réussie affiche le message : Pre-push installed at .git/hooks/pre-push.
Maintenez le hook pré-push à jour :
```
pre-commit autoupdate
```

Fonctionnement de l’analyse pré-push

Le hook analyse chaque commit poussé, un à la fois, afin qu’un secret ajouté dans un commit puis supprimé dans un commit ultérieur soit tout de même détecté. Lorsqu’il est installé via le framework pre-commit, la plage de commits est déterminée par le framework : les nouveaux commits depuis la branche distante pour les branches existantes, et les commits qui ne sont pas encore sur le dépôt distant pour les nouvelles branches (tous les commits lors d’un push vers un dépôt distant vide). Lorsqu’il est exécuté depuis un fichier .git/hooks/pre-push écrit manuellement, la plage est lue à partir des données d’entrée du hook Git, et les nouvelles branches sont analysées à partir de leur base de fusion avec la branche par défaut (voir ci-dessous).

Les pushes ne contenant rien à analyser, comme les tags, les suppressions de branches et les pushes déjà à jour, sont acceptés sans analyse. Si le hook ne peut pas déterminer ce qui est poussé, il échoue et bloque le push au lieu de le laisser passer silencieusement.

Les hooks pré-push de Cycode définissent always_run: true et pass_filenames: false, car l’analyse porte sur les commits poussés plutôt que sur une liste de fichiers. Sans always_run, le framework pre-commit ignore le hook lorsque les commits poussés n’entraînent aucune modification de fichier, par exemple lorsqu’un secret est ajouté dans un commit puis supprimé dans le suivant. Sans pass_filenames: false, le framework transmet des noms de fichiers modifiés que l’analyse n’utilise pas et, lors de pushes volumineux, les répartit en lots et exécute l’analyse complète une fois par lot. Si vous définissez vous-même le hook (par exemple, comme hook repo: local), définissez les deux options.

Détection intelligente de la branche par défaut

Lorsqu’elle est exécutée depuis un hook écrit manuellement, l’analyse pré-push détecte la branche par défaut à utiliser pour le calcul de la base de fusion selon l’ordre de priorité suivant :

Variable d’environnement : CYCODE_DEFAULT_BRANCH — permet une substitution manuelle
HEAD du dépôt distant Git : utilise git symbolic-ref refs/remotes/origin/HEAD pour détecter la véritable branche par défaut du dépôt distant
Informations du dépôt distant Git : utilise git remote show origin en solution de repli si symbolic-ref échoue
Valeurs de repli codées en dur : utilise les noms courants de branches par défaut (origin/main, origin/master, main, master)

Définir une branche par défaut personnalisée :

export CYCODE_DEFAULT_BRANCH=origin/develop

Cette détection intelligente garantit le bon fonctionnement du hook pre-push, que votre dépôt utilise main, master, develop ou tout autre nom de branche par défaut.

Ignorer les analyses pre-push

Pour ignorer l’analyse pre-push lors d’une opération de push spécifique, utilisez :

SKIP=cycode-pre-push git push

Ou pour ignorer tous les hooks pre-push :

git push --no-verify

[!TIP] Le hook pre-push est déclenché lors de la commande git push et analyse uniquement les commits sur le point d’être poussés, ce qui le rend plus efficace que l’analyse de l’ensemble du dépôt.

Exclure des chemins des analyses

Vous pouvez utiliser un fichier .cycodeignore pour indiquer à la CLI Cycode les fichiers et répertoires à exclure des analyses. Il fonctionne comme un fichier .gitignore. Cela vous permet de concentrer les analyses sur le code pertinent et d’éviter que certains chemins ne déclenchent des violations localement.

Fonctionnement

Créez un fichier nommé .cycodeignore dans votre dossier de travail.
Répertoriez les fichiers et répertoires à exclure en utilisant les mêmes motifs que .gitignore.
Placez ce fichier dans le répertoire depuis lequel vous prévoyez d’exécuter la commande cycode scan.

[!WARNING]

Fichiers non valides : si le fichier .cycodeignore contient une erreur de syntaxe, l’analyse de la CLI échouera et renverra une erreur.

Ignorer des chemins ou des violations : ce fichier sert à exclure des chemins. Il est différent de la fonctionnalité de la CLI permettant d’ignorer des violations spécifiques (par exemple, à l’aide de l’option --ignore-violation).

Scanners pris en charge

SAST
IaC (bientôt disponible)
SCA (bientôt disponible)

Résultats de l’analyse

Chaque analyse se termine par un message indiquant si des problèmes ont été détectés.

Si aucun problème n’est détecté, l’analyse se termine par le message de réussite suivant :

Good job! No issues were found!!! 👏👏👏

Si un problème est détecté, une carte de violation s’affiche à la place à la fin de l’analyse. Dans ce cas, examinez le fichier concerné à la ligne indiquée dans le message de résultat. Apportez les modifications nécessaires pour résoudre le problème, puis relancez l’analyse.

Afficher/Masquer les secrets

Dans les exemples ci-dessous, un secret a été détecté dans le fichier secret_test, situé dans le sous-dossier cli. La deuxième partie du message indique la ligne précise où apparaît le secret, qui correspond ici à une valeur attribuée à googleApiKey.

Notez que l’exemple masque la valeur réelle du secret en remplaçant la majeure partie de celle-ci par des astérisques. Par défaut, les analyses masquent les secrets, mais vous pouvez désactiver cette fonctionnalité pour afficher le secret en entier (à condition que la machine sur laquelle vous consultez le résultat de l’analyse soit suffisamment sécurisée contre les regards indiscrets).

Pour désactiver le masquage des secrets, ajoutez l’argument --show-secret à tout type d’analyse.

Dans l’exemple suivant, une analyse de chemin est exécutée sur le sous-répertoire cli, avec l’option d’affichage intégral des secrets détectés activée :

cycode scan --show-secret path ./cli

Le résultat ne serait alors pas masqué.

Échec non bloquant

En fonctionnement normal, la CLI renvoie le code de sortie 1 lorsque des problèmes sont détectés dans les résultats de l’analyse. Selon votre configuration CI/CD, cela entraîne généralement un échec global. Si vous souhaitez éviter cela, vous pouvez utiliser la fonctionnalité d’échec non bloquant.

En ajoutant l’option --soft-fail à tout type d’analyse, le code de sortie sera forcé à 0, que des résultats soient détectés ou non.

Exemples de résultats d’analyse

Exemple de résultat Secrets

╭─────────────────────────────────────────────────────────────── Hardcoded generic-password is used ───────────────────────────────────────────────────────────────╮
│                                                                                                                                               Violation 12 of 12 │
│ ╭─ 🔍 Details ───────────────────────────────────────╮ ╭─ 💻 Code Snippet ─────────────────────────────────────────────────────────────────────────────────────╮ │
│ │  Severity    🟠 MEDIUM                             │ │   34 };                                                                                               │ │
│ │  In file     /Users/cycodemacuser/NodeGoat/test/s  │ │   35                                                                                                  │ │
│ │              ecurity/profile-test.js               │ │   36 var sutUserName = "user1";                                                                       │ │
│ │  Secret SHA  b4ea3116d868b7c982ee6812cce61727856b  │ │ ❱ 37 var sutUserPassword = "Us*****23";                                                               │ │
│ │              802b3063cd5aebe7d796988552e0          │ │   38                                                                                                  │ │
│ │  Rule ID     68b6a876-4890-4e62-9531-0e687223579f  │ │   39 chrome.setDefaultService(service);                                                               │ │
│ ╰────────────────────────────────────────────────────╯ │   40                                                                                                  │ │
│                                                        ╰───────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
│ ╭─ 📝 Summary ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │
│ │ A generic secret or password is an authentication token used to access a computer or application and is assigned to a password variable.                     │ │
│ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Exemple de résultat IaC

╭──────────── Enable Content Encoding through the attribute 'MinimumCompressionSize'. This value should be greater than -1 and smaller than 10485760. ─────────────╮
│                                                                                                                                              Violation 45 of 110 │
│ ╭─ 🔍 Details ───────────────────────────────────────╮ ╭─ 💻 Code Snippet ─────────────────────────────────────────────────────────────────────────────────────╮ │
│ │  Severity      🟠 MEDIUM                           │ │   20 BinaryMediaTypes:                                                                                │ │
│ │  In file       ...ads-copy/iac/cft/api-gateway/ap  │ │   21   - !Ref binaryMediaType1                                                                        │ │
│ │                i-gateway-rest-api/deploy.yml       │ │   22   - !Ref binaryMediaType2                                                                        │ │
│ │  IaC Provider  CloudFormation                      │ │ ❱ 23 MinimumCompressionSize: -1                                                                       │ │
│ │  Rule ID       33c4b90c-3270-4337-a075-d3109c141b  │ │   24 EndpointConfiguration:                                                                           │ │
│ │                53                                  │ │   25   Types:                                                                                         │ │
│ ╰────────────────────────────────────────────────────╯ │   26     - EDGE                                                                                       │ │
│                                                        ╰───────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
│ ╭─ 📝 Summary ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │
│ │ This policy validates the proper configuration of content encoding in AWS API Gateway. Specifically, the policy checks for the attribute                     │ │
│ │ 'minimum_compression_size' in API Gateway REST APIs. Correct configuration of this attribute is important for enabling content encoding of API responses for │ │
│ │ improved API performance and reduced payload sizes.                                                                                                          │ │
│ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Exemple de résultat SCA

╭─────────────────────────────────────────────────────── [CVE-2019-10795] Prototype Pollution in undefsafe ────────────────────────────────────────────────────────╮
│                                                                                                                                             Violation 172 of 195 │
│ ╭─ 🔍 Details ───────────────────────────────────────╮ ╭─ 💻 Code Snippet ─────────────────────────────────────────────────────────────────────────────────────╮ │
│ │  Severity               🟠 MEDIUM                  │ │   26758   "integrity": "sha1-5z3T17DXxe2G+6xrCufYxqadUPo=",                                           │ │
│ │  In file                /Users/cycodemacuser/Node  │ │   26759   "dev": true                                                                                 │ │
│ │                         Goat/package-lock.json     │ │   26760 },                                                                                            │ │
│ │  CVEs                   CVE-2019-10795             │ │ ❱ 26761 "undefsafe": {                                                                                │ │
│ │  Package                undefsafe                  │ │   26762   "version": "2.0.2",                                                                         │ │
│ │  Version                2.0.2                      │ │   26763   "resolved": "https://registry.npmjs.org/undefsafe/-/undefsafe-2.0.2.tgz",                   │ │
│ │  First patched version  Not fixed                  │ │   26764   "integrity": "sha1-Il9rngM3Zj4Njnz9aG/Cg2zKznY=",                                           │ │
│ │  Dependency path        nodemon 1.19.1 ->          │ ╰───────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
│ │                         undefsafe 2.0.2            │                                                                                                           │
│ │  Rule ID                9c6a8911-e071-4616-86db-4  │                                                                                                           │
│ │                         943f2e1df81                │                                                                                                           │
│ ╰────────────────────────────────────────────────────╯                                                                                                           │
│ ╭─ 📝 Summary ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │
│ │ undefsafe before 2.0.3 is vulnerable to Prototype Pollution. The 'a' function could be tricked into adding or modifying properties of Object.prototype using │ │
│ │ a __proto__ payload.                                                                                                                                         │ │
│ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Exemple de résultat SAST

╭───────────────────────────────────────────── [CWE-208: Observable Timing Discrepancy] Observable Timing Discrepancy ─────────────────────────────────────────────╮
│                                                                                                                                               Violation 24 of 49 │
│ ╭─ 🔍 Details ───────────────────────────────────────╮ ╭─ 💻 Code Snippet ─────────────────────────────────────────────────────────────────────────────────────╮ │
│ │  Severity       🟠 MEDIUM                          │ │   173         " including numbers, lowercase and uppercase letters.";                                 │ │
│ │  In file        /Users/cycodemacuser/NodeGoat/app  │ │   174     return false;                                                                               │ │
│ │                 /routes/session.js                 │ │   175 }                                                                                               │ │
│ │  CWE            CWE-208                            │ │ ❱ 176 if (password !== verify) {                                                                      │ │
│ │  Subcategory    Security                           │ │   177     errors.verifyError = "Password must match";                                                 │ │
│ │  Language       js                                 │ │   178     return false;                                                                               │ │
│ │  Security Tool  Bearer (Powered by Cycode)         │ │   179 }                                                                                               │ │
│ │  Rule ID        19fbca07-a8e7-4fa6-92ac-a36d15509  │ ╰───────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
│ │                 fa9                                │                                                                                                           │
│ ╰────────────────────────────────────────────────────╯                                                                                                           │
│ ╭─ 📝 Summary ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │
│ │ Observable Timing Discrepancy occurs when the time it takes for certain operations to complete can be measured and observed by attackers. This vulnerability │ │
│ │ is particularly concerning when operations involve sensitive information, such as password checks or secret comparisons. If attackers can analyze how long   │ │
│ │ these operations take, they might be able to deduce confidential details, putting your data at risk.                                                         │ │
│ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Consignes de correction personnalisées de l’entreprise

Si votre entreprise a défini des consignes de correction personnalisées dans la stratégie correspondante via le portail Cycode, un champ « Consignes de l’entreprise » s’affichera et contiendra les consignes de correction que vous avez ajoutées. Notez que si vous n’avez ajouté aucune consigne d’entreprise, ce champ n’apparaîtra pas dans l’outil CLI.

Ignorer les résultats d’analyse

Des règles d’exclusion peuvent être ajoutées pour ignorer des valeurs de secrets spécifiques, des valeurs SHA512 spécifiques, des chemins spécifiques ainsi que des ID de règles Cycode spécifiques pour les secrets et IaC. L’analyse ne signalera alors pas ces valeurs. Les règles d’exclusion sont rédigées et enregistrées localement dans le fichier ./.cycode/config.yaml.

[!WARNING] L’ajout de valeurs à ignorer doit être effectué avec soin, en tenant compte des valeurs, des chemins et des stratégies, afin de garantir que les analyses détectent les vrais positifs.

Voici les options disponibles pour la commande cycode ignore :

Option	Description
`--by-value TEXT`	Ignorer une valeur spécifique lors de l’analyse des secrets. Consultez Ignorer une valeur de secret pour plus de détails.
`--by-sha TEXT`	Ignorer une représentation SHA512 spécifique d’une chaîne lors de l’analyse des secrets. Consultez Ignorer une valeur SHA de secret pour plus de détails.
`--by-path TEXT`	Éviter l’analyse d’un chemin spécifique. Le type d’analyse doit être indiqué. Consultez Ignorer un chemin pour plus de détails.
`--by-rule TEXT`	Ignorer l’analyse d’un ID de règle spécifique pour les secrets, IaC ou SCA. Consultez Ignorer une règle Secret ou IaC pour plus de détails.
`--by-package TEXT`	Ignorer l’analyse d’une version de package spécifique lors d’une analyse SCA. Motif attendu : `name@version`. Consultez Ignorer un package pour plus de détails.
`--by-cve TEXT`	Ignorer l’analyse d’un CVE spécifique lors d’une analyse SCA. Motif attendu : CVE-YYYY-NNN.
`-t, --scan-type [secret\|iac\|sca\|sast]`	Indiquer l’analyse à exécuter (`secret`/`iac`/`sca`/`sast`). La valeur par défaut est `secret`.
`-g, --global`	Ajouter une règle d’exclusion et la mettre à jour dans le fichier de configuration global `.cycode`.

Ignorer une valeur de secret

Pour ignorer une valeur de secret spécifique, vous devez utiliser l’option --by-value. La valeur de secret indiquée sera alors ignorée lors de toutes les analyses ultérieures. Utilisez la commande suivante pour ajouter une valeur de secret à ignorer :

cycode ignore --by-value {{secret-value}}

Dans l’exemple au début de cette section, la commande permettant d’ignorer une valeur de secret spécifique est la suivante :

cycode ignore --by-value h3110w0r1d!@#$350

Dans l’exemple ci-dessus, remplacez la valeur h3110w0r1d!@#$350 par votre valeur de secret non masquée. Consultez les options d’analyse de Cycode pour savoir comment afficher les valeurs des secrets dans les résultats d’analyse.

Ignorer une valeur SHA de secret

Pour ignorer une valeur SHA de secret spécifique, vous devez utiliser l’option --by-sha. La valeur SHA de secret indiquée sera alors ignorée lors de toutes les analyses ultérieures. Utilisez la commande suivante pour ajouter une valeur SHA de secret à ignorer :

cycode ignore --by-sha {{secret-sha-value}}

Dans l’exemple au début de cette section, la commande permettant d’ignorer une valeur SHA de secret spécifique est la suivante :

cycode ignore --by-sha a44081db3296c84b82d12a35c446a3cba19411dddfa0380134c75f7b3973bff0

Dans l’exemple ci-dessus, remplacez la valeur a44081db3296c84b82d12a35c446a3cba19411dddfa0380134c75f7b3973bff0 par votre valeur SHA de secret.

Ignorer un chemin

Pour ignorer un chemin spécifique lors des analyses de secrets, IaC ou SCA, vous devez utiliser l’option --by-path avec l’option -t, --scan-type (vous devez indiquer le type d’analyse). Le chemin indiqué sera alors ignoré lors de toutes les analyses ultérieures du type spécifié. Utilisez la commande suivante pour ajouter un chemin à ignorer :

cycode ignore -t {{scan-type}} --by-path {{path}}

Dans l’exemple au début de cette section, la commande permettant d’ignorer un chemin spécifique lors d’une analyse de secrets est la suivante :

cycode ignore -t secret --by-path ~/home/my-repo/config

Dans l’exemple ci-dessus, remplacez la valeur ~/home/my-repo/config par votre chemin.

Dans l’exemple au début de cette section, la commande permettant d’ignorer un chemin spécifique lors des analyses IaC est la suivante :

cycode ignore -t iac --by-path ~/home/my-repo/config

Dans l’exemple ci-dessus, remplacez la valeur ~/home/my-repo/config par votre chemin.

Dans l’exemple au début de cette section, la commande permettant d’ignorer un chemin spécifique lors des analyses SCA est la suivante :

cycode ignore -t sca --by-path ~/home/my-repo/config

Dans l’exemple ci-dessus, remplacez la valeur ~/home/my-repo/config par votre chemin.

Ignorer une règle Secret, IaC, SCA ou SAST

Pour ignorer une règle spécifique pour les secrets, IaC, SCA ou SAST, vous devez utiliser l’option --by-rule avec l’option -t, --scan-type (vous devez indiquer le type d’analyse). L’ID de règle indiqué sera alors ignoré lors de toutes les analyses ultérieures. Utilisez la commande suivante pour ajouter un ID de règle à ignorer :

cycode ignore -t {{scan-type}} --by-rule {{rule-ID}}

Dans l’exemple au début de cette section, la commande permettant d’ignorer un ID de règle Secret spécifique est la suivante :

cycode ignore -t secret --by-rule ce3a4de0-9dfc-448b-a004-c538cf8b4710

Dans l’exemple ci-dessus, remplacez la valeur ce3a4de0-9dfc-448b-a004-c538cf8b4710 par l’ID de règle que vous souhaitez ignorer.

Dans l’exemple au début de cette section, la commande permettant d’ignorer un ID de règle IaC spécifique est la suivante :

cycode ignore -t iac --by-rule bdaa88e2-5e7c-46ff-ac2a-29721418c59c

Dans l’exemple ci-dessus, remplacez la valeur bdaa88e2-5e7c-46ff-ac2a-29721418c59c par l’ID de règle que vous souhaitez ignorer.

Dans l’exemple au début de cette section, la commande permettant d’ignorer un ID de règle SCA spécifique est la suivante :

cycode ignore -t sca --by-rule dc21bc6b-9f4f-46fb-9f92-e4327ea03f6b

Dans l’exemple ci-dessus, remplacez la valeur dc21bc6b-9f4f-46fb-9f92-e4327ea03f6b par l’ID de règle que vous souhaitez ignorer.

Ignorer un package

[!NOTE] Cette option est disponible uniquement pour les analyses SCA.

Pour ignorer un package spécifique lors des analyses SCA, vous devez utiliser l’option --by-package avec l’option -t, --scan-type (vous devez indiquer le type d’analyse sca). Le package indiqué, au format {{package_name}}@{{package_version}}, sera alors ignoré lors de toutes les analyses ultérieures. Utilisez la commande suivante pour ajouter un package et une version à ignorer :

cycode ignore --scan-type sca --by-package {{package_name}}@{{package_version}}

cycode ignore -t sca --by-package {{package_name}}@{{package_version}}

Dans l’exemple ci-dessous, la commande permettant d’ignorer un package SCA spécifique est la suivante :

cycode ignore --scan-type sca --by-package pyyaml@5.3.1

Dans l’exemple ci-dessus, remplacez pyyaml par le nom du package et 5.3.1 par la version du package que vous souhaitez ignorer.

Ignorer à l’aide d’un fichier de configuration

Les règles d’exclusion appliquées sont stockées dans le fichier de configuration nommé config.yaml. Ce fichier peut facilement être partagé entre développeurs ou même être validé dans un dépôt Git distant. Ces fichiers se trouvent toujours dans le dossier .cycode. Le nom du dossier commence par un point (.), et vous devez afficher les fichiers cachés pour le voir.

Emplacement des fichiers de configuration

Par défaut, toutes les commandes cycode ignore enregistrent la règle d’exclusion dans le répertoire courant depuis lequel la CLI a été exécutée.

Exemple : l’exécution d’une commande CLI d’exclusion depuis /Users/name/projects/backend créera config.yaml dans /Users/name/projects/backend/.cycode

➜  backend  pwd
/Users/name/projects/backend
➜  backend  cycode ignore --by-value test-value
➜  backend  tree -a
.
└── .cycode
    └── config.yaml

2 directories, 1 file

La deuxième option consiste à enregistrer les règles d’exclusion dans les fichiers de configuration globaux. Le chemin de la configuration globale est ~/.cycode/config.yaml, où ~ désigne users home directory, for example, /Users/name` sur macOS.

L’enregistrement dans l’espace global peut être effectué à l’aide de l’option -g de la commande cycode ignore. Par exemple : cycode ignore -g --by-value test-value.

Répertoire de travail approprié

Il est extrêmement important de placer le dossier .cycode et d’exécuter la CLI depuis le même emplacement. Vérifiez-le attentivement lorsque vous travaillez dans différents environnements, comme CI/CD (GitHub Actions, Jenkins, etc.).

Vous pouvez valider le dossier .cycode à la racine de votre dépôt. Dans ce cas, vous devez exécuter les analyses CLI depuis la racine du dépôt. Si cela ne répond pas à vos besoins, vous pouvez copier temporairement le dossier .cycode à l’emplacement de votre choix et lancer une analyse CLI depuis ce dossier.

Règles d’ignorance de la structure dans la configuration

Il est important de comprendre comment la CLI stocke les règles d’ignorance afin de pouvoir lire ces fichiers de configuration ou même les modifier sans la CLI.

Structure YAML abstraite :

exclusions:
  {scanTypeName}:
    {ignoringType}:
    - someIgnoringValue1
    - someIgnoringValue2

Valeurs possibles de scanTypeName : iac, sca, sast, secret.

Valeurs possibles de ignoringType : paths, values, rules, packages, shas, cves.

[!WARNING] Les valeurs utilisées pour « ignorer par valeur » ne sont pas stockées en texte brut ! La CLI stocke des hachages sha256 des valeurs. Lorsque vous modifiez le fichier de configuration manuellement, vous devez utiliser les hachages de la chaîne.

Exemple réel de config.yaml :

exclusions:
  iac:
    rules:
    - bdaa88e2-5e7c-46ff-ac2a-29721418c59c
  sca:
    packages:
    - pyyaml@5.3.1
  secret:
    paths:
    - /Users/name/projects/build
    rules:
    - ce3a4de0-9dfc-448b-a004-c538cf8b4710
    shas:
    - a44081db3296c84b82d12a35c446a3cba19411dddfa0380134c75f7b3973bff0
    values:
    - a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3
    - 60303ae22b998861bce3b28f33eec1be758a213c86c93c076dbe9f558c11c752

Commande Report

Génération d’un rapport SBOM

Une nomenclature logicielle (SBOM) est un inventaire de tous les composants et dépendances logicielles qui interviennent dans le développement et la livraison d’une application. Cette commande permet de créer un rapport SBOM pour votre projet local ou l’URI de votre dépôt.

Les options suivantes sont disponibles pour cette commande :

Option	Description	Obligatoire	Valeur par défaut
`-f, --format [spdx-2.2\|spdx-2.3\|cyclonedx-1.4]`	Format SBOM	Oui
`-o, --output-format [JSON]`	Spécifier le format du fichier de sortie	Non	json
`--output-file PATH`	Fichier de sortie	Non	nom de fichier généré automatiquement, enregistré dans le répertoire courant
`--include-vulnerabilities`	Inclure les vulnérabilités	Non	False
`--include-dev-dependencies`	Inclure les dépendances de développement	Non	False

Les commandes suivantes sont disponibles :

Commande	Description
`path`	Générer un rapport SBOM pour le chemin indiqué dans la commande
`repository-url`	Générer un rapport SBOM pour l’URI de dépôt indiquée dans la commande

Dépôt

Pour créer un rapport SBOM pour une URI de dépôt :
cycode report sbom --format <sbom format> --include-vulnerabilities --include-dev-dependencies --output-file </path/to/file> repository_url <repository url>

Par exemple :
cycode report sbom --format spdx-2.3 --include-vulnerabilities --include-dev-dependencies repository_url https://github.com/cycodehq/cycode-cli.git

Projet local

Pour créer un rapport SBOM pour un chemin :
cycode report sbom --format <sbom format> --include-vulnerabilities --include-dev-dependencies --output-file </path/to/file> path </path/to/project>

Par exemple :
cycode report sbom --format spdx-2.3 --include-vulnerabilities --include-dev-dependencies path /path/to/local/project

La sous-commande path prend en charge les options supplémentaires suivantes :

Option	Description
`--no-restore`	Ignorer la restauration du fichier de verrouillage et analyser uniquement les dépendances directes. Consultez Option de restauration du verrouillage pour plus de détails.
`--gradle-all-sub-projects`	Exécuter la commande de restauration Gradle pour tous les sous-projets (à utiliser depuis la racine d’une compilation Gradle multi-projets).
`--maven-settings-file`	Pour Maven uniquement, permet d’utiliser un fichier settings.xml personnalisé lors de la création de l’arborescence des dépendances.

Commande Import

Importation d’un SBOM

Une nomenclature logicielle (SBOM) est un inventaire de tous les composants et dépendances logicielles qui interviennent dans le développement et la livraison d’une application. Cette commande permet d’importer un fichier SBOM depuis votre système de fichiers dans Cycode.

Les options suivantes sont disponibles pour cette commande :

Option	Description	Obligatoire	Valeur par défaut
`-n, --name TEXT`	Nom d’affichage du SBOM	Oui
`-v, --vendor TEXT`	Nom de l’entité ayant fourni le SBOM	Oui
`-l, --label TEXT`	Ajouter une étiquette au SBOM	Non
`-o, --owner TEXT`	Adresse e-mail de l’utilisateur Cycode servant de personne à contacter pour ce SBOM	Non
`-b, --business-impact [High \| Medium \| Low]`	Impact métier	Non	Medium

Par exemple :
cycode import sbom --name example-sbom --vendor cycode -label tag1 -label tag2 --owner example@cycode.com /path/to/local/project

Journaux d’analyse

Toutes les analyses de la CLI sont consignées dans Cycode. Les journaux se trouvent sous Settings > CLI Logs.

Aide sur la syntaxe

Vous pouvez ajouter l’argument --help à n’importe quelle commande à tout moment pour afficher un message d’aide présentant les options disponibles et leur syntaxe.

Pour afficher l’aide générale, saisissez simplement la commande :

cycode --help

Pour afficher les options d’analyse, saisissez :

cycode scan --help

Pour afficher les options disponibles pour un type d’analyse spécifique, saisissez :

cycode scan {{option}} --help

Par exemple, pour afficher les options disponibles pour une analyse de chemin, saisissez :

cycode scan path --help

Pour afficher les options disponibles pour la fonction d’ignorance d’analyse, utilisez cette commande :

cycode ignore --help

Pour afficher les options disponibles pour un rapport, utilisez cette commande :

cycode report --help

Pour afficher les options disponibles pour un type de rapport spécifique, saisissez :

cycode scan {{option}} --help