docker run -v `pwd`:`pwd` -w `pwd` --rm -it secretlint/secretlint secretlint "**/*"

npx @secretlint/quick-start "**/*"

docker run -v `pwd`:`pwd` -w `pwd` --rm -it secretlint/secretlint secretlint "**/*"

Vous devriez ensuite configurer un fichier de configuration :```
npx secretlint --init

:memo: Secretlint prend en charge les [glob patterns](https://github.com/mrmlnc/fast-glob#basic-syntax) et les glob patterns doivent être entourés de guillemets.

Il est également possible d'installer Secretlint globalement avec `npm install --global`. Cependant, nous ne le recommandons pas, certaines règles peuvent être cassées globalement.

### Utilisation d'un binaire exécutable unique

**Prérequis :** Aucun

Vous pouvez utiliser la commande `secretlint` sans Node.js en utilisant un binaire exécutable unique.

1. Téléchargez le dernier binaire depuis la [page Releases](https://github.com/secretlint/secretlint/releases)
2. Modifiez les permissions du fichier pour le rendre exécutable : `chmod +x ./secretlint`
3. Exécutez `./secretlint --init` pour créer un fichier de configuration
4. Exécutez `./secretlint "**/*"` pour analyser votre projet

Pour plus de détails, veuillez consulter le README de [publish/binary-compiler](https://github.com/secretlint/secretlint/blob/HEAD/publish/binary-compiler).

## Utilisation

`secretlint --help` affiche l'utilisation.

    Secretlint CLI that scan secret/credential data.
    
    Usage
    $ secretlint [file|glob*]
    
    Note
    supported glob syntax is based on picomatch (the engine used by micromatch)
    https://github.com/micromatch/picomatch#globbing-features
    https://github.com/micromatch/micromatch#matching-features
    
    Options
    --init             setup config file. Create .secretlintrc.json file from your package.json
    --format           [String] formatter name. Default: "stylish". Available Formatter: checkstyle, compact, github, jslint-xml, junit, pretty-error, stylish, tap, unix, json, mask-result, table
    --output           [path:String] output file path that is written of reported result.
    --secretlintrc     [path:String] path to .secretlintrc config file. Default: .secretlintrc.*
    --secretlintignore [path:String] path to .secretlintignore file. Default: .secretlintignore
    --stdinFileName    [String] filename to process STDIN content. Some rules depend on filename to check content.
    --no-color         disable ANSI-color of output.
    --no-terminalLink  disable terminalLink of output.
    --no-maskSecrets   disable masking of secret values; secrets are masked by default.
    --no-glob          disable glob pattern interpretation; treat all inputs as literal file paths.
    --no-gitignore     disable .gitignore cascade respect; .gitignore files are
                       respected by default (since v13).
    
    Options for Developer
    --profile          Enable performance profile.
    --secretlintrcJSON [String] a JSON string of .secretlintrc. use JSON string instead of rc file.
    
    Experimental Options
    --locale            [String] locale tag for translating message. Default: en
    
    Examples
    # Scan a single file
    $ secretlint ./README.md

    # Scan all files (wrap glob in double quotes to avoid shell expansion)
    $ secretlint "**/*"
    $ secretlint "source/**/*.ini"

    # Treat inputs as literal paths (for SvelteKit (group) / Next.js [param] etc.)
    $ secretlint --no-glob "src/(auth)/login.ts"

    # Lint STDIN content (filename hint affects which rules apply)
    $ echo "SECRET" | secretlint --stdinFileName=secret.txt

    # Use a custom config file
    $ secretlint "**/*" --secretlintrc=.secretlintrc.custom.json

    # Scan files ignored by .gitignore (e.g. to verify build artifacts)
    $ secretlint --no-gitignore "dist/**/*"

    # Mask secrets in a file in-place
    $ secretlint .zsh_history --format=mask-result --output=.zsh_history

    # Output JSON for programmatic parsing
    $ secretlint "**/*" --format=json --output=secretlint-report.json

    # Output GitHub Actions annotations in CI
    $ secretlint "**/*" --format=github
    
    Exit Status
    Secretlint exits with the following values:
    
        - 0:
          - Linting succeeded, no errors found.
          - Found lint error but --output is specified.
        - 1:
          - Linting failed, errors found.
        - 2:
          - Unexpected error occurred, fatal error.


## Configuration

Secretlint a un fichier de configuration `.secretlintrc.{json,yml,js}`.

- Document : [Configurer Secretlint](https://github.com/secretlint/secretlint/blob/HEAD/docs/configuration.md)

Après avoir exécuté `secretlint --init`, vous aurez un fichier `.secretlintrc.json` dans votre répertoire.

Vous y trouverez quelques règles configurées comme ceci :```json
{
  "rules": [
    {
      "id": "@secretlint/secretlint-rule-preset-recommend"
    }
  ]
}

Lorsque vous utilisez une présélection comme `@secretlint/secretlint-rule-preset-recommend`, vous devez placer l'option dans `rules`.

Par exemple, une option pour `@secretlint/secretlint-rule-preset-recommend > @secretlint/secretlint-rule-aws````json5
{
  "rules": [
    {
      "id": "@secretlint/secretlint-rule-preset-recommend",
      "rules": [
        {
          "id": "@secretlint/secretlint-rule-aws",
            "options": {
              "allows": [
	            // it will be ignored
                "xxxx-xxxx-xxxx-xxxx-xxxx"
              ]
            }
        }
      ]
    }
  ]
}

L'identifiant du message de cette erreur est `EXAMPLE_MESSAGE` dans `@secretlint/secretlint-rule-example`.

Si vous voulez ignorer cette erreur, veuillez utiliser `allowMessageIds`.```json
{
  "rules": [
    {
      "id": "@secretlint/secretlint-rule-example",
      "allowMessageIds": ["EXAMPLE_MESSAGE"]
    }
  ]
}

### Ignorer les fichiers via `.gitignore` et `.secretlintignore`

Secretlint parcourt le système de fichiers de la même manière que Git, en respectant les fichiers `.gitignore` imbriqués. Un fichier ou un répertoire correspondant à un `.gitignore` sur le chemin entre le répertoire de travail et le fichier est ignoré.

`.secretlintignore` fonctionne de la même manière que `.gitignore` et est consulté en supplément. L'ordre de résolution est :

1. Ignorances intégrées : `.git`, `node_modules` et la famille `.secretlintrc*`.
2. Le fichier pointé par `--secretlintignore` (par défaut : `.secretlintignore`).
3. Le `.gitignore` de chaque répertoire (en cascade).

Pour analyser les fichiers qui sont gitignorés — par exemple, un fichier `.env` dans un projet où `.env` est gitignoré — passez `--no-gitignore` :```
secretlint --no-gitignore "**/*"

Pour plus de détails, veuillez consulter [Configuring Secretlint](https://github.com/secretlint/secretlint/blob/HEAD/docs/configuration.md).

## Cas d'utilisation

### Masquer les secrets dans les messages d'erreur de lint (Comportement par défaut)

Secretlint masque les secrets dans les messages d'erreur de lint par défaut. Cela est utile pour éviter l'exposition accidentelle de secrets dans les logs CI, la sortie terminal, ou lors de l'utilisation d'outils d'agent IA.```bash
# Secrets are masked by default
$ secretlint "**/*"

### Fix secrets

Secretlint ne peut pas corriger les secrets automatiquement.
Cependant, il est utile que `--format=mask-result` masque les secrets du fichier d'entrée.

Par exemple, vous pouvez masquer les secrets du fichier `.zsh_history` et l'écraser.```bash
$ secretlint .zsh_history --format=mask-result --output=.zsh_history

Ajoutez des hooks à `.husky/pre-commit`:```
npx husky add .husky/pre-commit "npx --no-install lint-staged"

> **Note :** L'option `--no-glob` est requise car lint-staged transmet des chemins de fichiers littéraux qui peuvent contenir des caractères spéciaux de glob (par exemple, les motifs de routage `(group)` ou `[param]` utilisés par Next.js, SvelteKit, etc.).

Cela signifie que chaque fichier placé en scène est vérifié par Secretlint avant le commit.

#### [pre-commit](https://github.com/pre-commit/pre-commit)

**Cas d'utilisation :** Vous avez un projet qui se développe avec Docker. Facile à intégrer à secretlint.

Installer [pre-commit](https://pre-commit.com/#install)

    # macOS. voir aussi https://pre-commit.com/#install
    brew install pre-commit

Créer `.pre-commit-config.yaml` :```
-   repo: local
    hooks:
    -   id: secretlint
        name: secretlint
        language: docker_image
        entry: secretlint/secretlint:latest secretlint

### Pre-commit Hook globalement

**Cas d'utilisation :** Si vous souhaitez vérifier n'importe quel projet avec secretlint, vous pouvez utiliser les hooks git globaux.

[Git 2.9+](https://github.blog/2016-06-13-git-2-9-has-been-released/) prend en charge [`core.hooksPath`](https://git-scm.com/docs/githooks).
Cela permet d'intégrer secretlint globalement.

Nous avons créé un exemple de projet de hooks git utilisant secretlint + Docker.

- [secretlint/git-hooks](https://github.com/secretlint/git-hooks)
    - Prérequis : Docker

Vous pouvez configurer en suivant les étapes suivantes :```shell script
# clone this repository
git clone https://github.com/secretlint/git-hooks git-hooks
cd git-hooks
# integrate secretlint to git hook globally
git config --global core.hooksPath $(pwd)/hooks

##### `--format github` pour les annotations de Pull Request

Vous pouvez utiliser `--format github` pour afficher les erreurs de lint comme annotations sur les fichiers de Pull Request. Ce formateur génère des [commandes de workflow GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions) qui affichent les annotations d'erreur directement sur les fichiers modifiés dans votre Pull Request.

- `--format github` pour les annotations sur les fichiers de Pull Request```yaml
      - name: Lint with Secretlint
        run: npx secretlint --format github "**/*"

#### Mega-Linter

[Mega-Linter](https://nvuillam.github.io/mega-linter/) est un agrégateur de linters nativement compatible avec tout outil CI, intégrant [80+ applications de linting](https://nvuillam.github.io/mega-linter/supported-linters/), dont [**secretlint**](https://nvuillam.github.io/mega-linter/descriptors/credentials_secretlint/) par défaut.

Vous pouvez l'[installer](https://nvuillam.github.io/mega-linter/installation/) sur n'importe quel projet de dépôt en utilisant la commande suivante (Node.js doit être installé au préalable)```shell
npx mega-linter-runner --install

## Politique de version sémantique

Secretlint project follows [Semantic Versioning](https://semver.org/ "Semantic Versioning")([secretlint-rule-preset-canary](https://github.com/secretlint/secretlint/blob/HEAD/packages/@secretlint/secretlint-rule-preset-canary) is an exception).

- Version corrective (destinée à ne pas casser votre lint)
    - Un correctif de bug pour le CLI ou le cœur (y compris les formateurs).
    - Améliorations de la documentation.
    - Modifications non visibles pour l'utilisateur comme le refactoring.
    - Réédition après une version ratée (c'est-à-dire publier une version qui ne fonctionne pour personne).
- Version mineure (pourrait casser votre lint)
    - Une nouvelle option.
    - Une règle existante est dépréciée.
    - Une nouvelle capacité CLI est créée.
    - De nouvelles API publiques sont ajoutées (nouvelles classes, nouvelles méthodes, nouveaux arguments pour des méthodes existantes, etc.).
        - Cela pourrait casser les définitions TypeScript
    - Un nouveau formateur est créé.
- Version majeure (casse votre lint)
    - Une nouvelle option pour une règle existante qui fait que Secretlint signale plus d'erreurs par défaut.
    - Un formateur existant est supprimé.
    - Ajout d'une nouvelle règle par défaut au preset de règles.
    - Une partie de l'API publique est supprimée ou modifiée de manière incompatible.

## Motivation

- [git-secrets](https://github.com/awslabs/git-secrets) est utile, mais il est difficile à configurer par projet.
	- Son cas d'utilisation principal est l'installation globale.
	- Secretlint veut s'installer pour un projet et personnaliser les paramètres par projet.
- [repo-security-scanner](https://github.com/UKHomeOffice/repo-security-scanner), [Gitleaks](https://github.com/zricethezav/gitleaks) et [truffleHog](https://github.com/dxa4481/truffleHog) sont de bons outils de scan.
	- Secretlint nécessite une personnalisation flexible qui inclut des définitions d'ignorance, des règles personnalisées.
- [detect-secrets](https://github.com/Yelp/detect-secrets) est un outil similaire, mais il adopte une approche d'opt-out.
    - Secretlint adopte une approche opt-in.  
    - Nous avons également besoin de règles personnalisées par l'utilisateur.
		- Voir [Bring-your-own-plugins (BYOP), via l'option --custom-plugins par KevinHock · Pull Request #255 · Yelp/detect-secrets](https://github.com/Yelp/detect-secrets/pull/255)
- GitHub prend en charge le [secret scanning](https://docs.github.com/en/code-security/secret-security/about-secret-scanning), mais cela ne fonctionne qu'après le commit [~~push~~](https://docs.github.com/en/code-security/secret-scanning/push-protection-for-users)
    - Secretlint fonctionne sur votre machine locale, Secretlint peut empêcher le commit.

## Philosophie

- Réduire les faux positifs du linting
- Intégration dans le workflow de développement
- Permettre aux utilisateurs de contribuer

### Opt-in plutôt qu'Opt-out

Secretlint adopte une approche opt-in.

Dans notre expérience, les outils de linting qui signalent diverses erreurs par défaut sont difficiles à utiliser.
L'approche opt-in aide à introduire Secretlint de manière incrémentale.

Cela aidera à réduire les faux positifs grâce à la configuration.

### Règle comme documentation

Nous considérons une règle comme une documentation.
Ainsi, chaque règle devrait avoir une documentation raisonnable.

Nous devons décrire pourquoi ce fichier est une erreur.
Une règle sans documentation n'est qu'arbitraire.

Décrire la raison de l'erreur mènera à réduire les faux positifs.

De plus, le CLI Secretlint prend en charge les hyperliens dans le terminal.
Cela signifie que vous pouvez accéder directement à la documentation de la règle depuis un message d'erreur de lint.

![clickable link in output](https://assets.kitploit.com/production/public/readmes/6649/890de2bdbaaae05b3b40c5bbe32b8389a7672beb231308453e585e308afca2be.png)

> Exemple sur iTerm 2 : Cmd + Clic sur messageId de l'erreur et ouvrir [AWSSecretAccessKey](https://github.com/secretlint/secretlint/blob/master/packages/%40secretlint/secretlint-rule-aws/README.md#awssecretaccesskey) dans votre navigateur.

Si vous voulez connaître les terminaux supportés, veuillez consulter [Hyperlinks in Terminal Emulators](https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda).

Aussi, bienvenue aux contributions concernant la documentation de Secretlint !

### Pourquoi Node.js ?

- Gestionnaire de paquets
	- Nécessite un gestionnaire de paquets pour concrétiser un système flexible et enfichable
	- Node.js dispose de npm et pnpm comme gestionnaires de paquets
	- Le gestionnaire de paquets aide à installer des plugins/règles personnalisées par l'utilisateur
- Existence d'une implémentation de référence
	- Node.js dispose déjà d'outils de linting enfichables comme ESLint, textlint, stylelint, etc.
	- Ainsi, les utilisateurs de Node.js sont familiers avec les outils de linting enfichables
	- Précédemment, j'ai créé textlint avec la même approche, donc je suis familier avec Node.js
- Utilisateurs
    - JavaScript est un langage populaire
    - Il permet aux utilisateurs de contribuer
    - Les utilisateurs peuvent créer leur propre règle de leurs propres mains

Bien sûr, Secretlint prend également en charge [Docker](https://hub.docker.com/r/secretlint/secretlint).

## Journal des modifications

Voir la [page des versions](https://github.com/secretlint/secretlint/releases).

## Contribuer

Les pull requests et les étoiles sont toujours les bienvenues.

Pour les bugs et les demandes de fonctionnalités, [veuillez créer une issue](https://github.com/secretlint/secretlint/issues).

Voir aussi, [CONTRIBUTING.md](https://github.com/secretlint/secretlint/blob/HEAD/CONTRIBUTING.md) et [CODE_OF_CONDUCT.md](https://github.com/secretlint/secretlint/blob/HEAD/CODE_OF_CONDUCT.md)

### Ajouter une nouvelle règle

Vous pouvez utiliser la commande `pnpm run gen:rule` pour créer une nouvelle règle.```shell script
pnpm run gen:rule