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 "**/*"

Dovresti quindi impostare un file di configurazione:```
npx secretlint --init

:memo: Secretlint supporta i [glob pattern](https://github.com/mrmlnc/fast-glob#basic-syntax) e il glob pattern deve essere racchiuso tra doppi apici.

È anche possibile installare Secretlint globalmente usando `npm install --global`. Tuttavia, non lo raccomandiamo, alcune regole potrebbero essere danneggiate globalmente.

### Utilizzo dell'eseguibile singolo

**Prerequisiti:** Nessuno

1. Scarica l'ultimo binario dalla [pagina delle release](https://github.com/secretlint/secretlint/releases) 
2. Modifica i permessi del file a eseguibile: `chmod +x ./secretlint`
3. Esegui `./secretlint --init` per creare un file di configurazione
4. Esegui `./secretlint "**/*"` per analizzare il tuo progetto

Per maggiori dettagli, consulta il README di [publish/binary-compiler](https://github.com/secretlint/secretlint/blob/HEAD/publish/binary-compiler).

## Utilizzo

`secretlint --help` mostra l'utilizzo.

    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.

## Configurazione

Secretlint ha un file di configurazione `.secretlintrc.{json,yml,js}`.

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

Dopo aver eseguito `secretlint --init`, avrai un file `.secretlintrc.json` nella tua directory.

Al suo interno, vedrai alcune regole configurate come segue:```json
{
  "rules": [
    {
      "id": "@secretlint/secretlint-rule-preset-recommend"
    }
  ]
}

Quando usi un preset come `@secretlint/secretlint-rule-preset-recommend`, devi inserire l'opzione in `rules`.

Per esempio, un'opzione per `@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'ID del messaggio di questo errore è `EXAMPLE_MESSAGE` in `@secretlint/secretlint-rule-example`. Se vuoi ignorare questo errore, per favore utilizza `allowMessageIds`.```json
{
  "rules": [
    {
      "id": "@secretlint/secretlint-rule-example",
      "allowMessageIds": ["EXAMPLE_MESSAGE"]
    }
  ]
}

### Ignorare file tramite `.gitignore` e `.secretlintignore`

Secretlint percorre il file system allo stesso modo di Git, rispettando i file `.gitignore` annidati. Un file o una directory corrispondente a qualsiasi `.gitignore` lungo il percorso dalla directory di lavoro al file viene saltato.

`.secretlintignore` funziona allo stesso modo di `.gitignore` e viene consultato in aggiunta. L'ordine di risoluzione è:

1. Ignora incorporati: `.git`, `node_modules` e la famiglia `.secretlintrc*`.
2. Il file indicato da `--secretlintignore` (predefinito: `.secretlintignore`).
3. Il `.gitignore` di ogni directory (a cascata).

Per scansionare file che sono gitignored — ad esempio, un file `.env` in un progetto dove `.env` è gitignored — passa `--no-gitignore`:```
secretlint --no-gitignore "**/*"

Per maggiori dettagli, consultare [Configurazione di Secretlint](https://github.com/secretlint/secretlint/blob/HEAD/docs/configuration.md).

## Casi d'uso

### Mascherare i segreti nei messaggi di errore di lint (Comportamento predefinito)

Secretlint maschera i segreti nei messaggi di errore di lint per impostazione predefinita. Ciò è utile per prevenire l'esposizione accidentale di segreti nei log CI, nell'output del terminale o quando si utilizzano strumenti di agenti AI.```bash
# Secrets are masked by default
$ secretlint "**/*"

### Correggere i segreti

Secretlint non può correggere automaticamente i segreti.
Tuttavia, è utile che `--format=mask-result` mascheri i segreti del file di input.

Ad esempio, è possibile mascherare i segreti del file `.zsh_history` e sovrascriverlo.```bash
$ secretlint .zsh_history --format=mask-result --output=.zsh_history

Aggiungi hook a `.husky/pre-commit`:```
npx husky add .husky/pre-commit "npx --no-install lint-staged"

> **Nota:** Il flag `--no-glob` è richiesto perché lint-staged passa percorsi file letterali che possono contenere caratteri speciali di glob (ad es., pattern di routing `(group)` o `[param]` utilizzati da Next.js, SvelteKit, ecc.).

Ciò significa che ogni file in staging viene controllato da Secretlint prima del commit.

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

**Caso d'uso:** Hai un progetto che stai sviluppando con Docker. Facile da integrare con secretlint.

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

    # macOS. see also https://pre-commit.com/#install
    brew install pre-commit

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

### Hook pre-commit globale

**Caso d'uso:** Se vuoi controllare qualsiasi progetto con secretlint, puoi usare i git hook globali.

[Git 2.9+](https://github.blog/2016-06-13-git-2-9-has-been-released/) supporta [`core.hooksPath`](https://git-scm.com/docs/githooks).
Consente di integrare secretlint a livello globale.

Abbiamo creato un progetto di esempio di git hook usando secretlint + Docker.

- [secretlint/git-hooks](https://github.com/secretlint/git-hooks)
    - Requisito: Docker

Puoi configurarlo seguendo questi passaggi:```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` per annotazioni nelle Pull Request

Puoi usare `--format github` per mostrare gli errori di lint come annotazioni sui file delle Pull Request.
Questo formattatore produce [comandi dei workflow di GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions) che visualizzano le annotazioni degli errori direttamente sui file modificati nella tua Pull Request.```yaml
      - name: Lint with Secretlint
        run: npx secretlint --format github "**/*"

#### Mega-Linter

[Mega-Linter](https://nvuillam.github.io/mega-linter/) è un aggregatore di linter nativamente compatibile con qualsiasi strumento CI, che include [80+ applicazioni di linting](https://nvuillam.github.io/mega-linter/supported-linters/), incluso [**secretlint**](https://nvuillam.github.io/mega-linter/descriptors/credentials_secretlint/) per impostazione predefinita.

Puoi [installarlo](https://nvuillam.github.io/mega-linter/installation/) su qualsiasi progetto di repository usando il seguente comando (Node.js deve essere precedentemente installato)```shell
npx mega-linter-runner --install

## Politica di versionamento semantico

Il progetto Secretlint segue il [Versionamento Semantico](https://semver.org/ "Semantic Versioning") ([secretlint-rule-preset-canary](https://github.com/secretlint/secretlint/blob/HEAD/packages/@secretlint/secretlint-rule-preset-canary) è un'eccezione).

- Rilascio patch (non dovrebbe rompere la tua build di lint)
    - Un bug fix per la CLI o il core (inclusi i formattatori).
    - Miglioramenti alla documentazione.
    - Modifiche non visibili all'utente come refactoring.
    - Ripubblicazione dopo un rilascio fallito (ad esempio, pubblicare una versione che non funziona per nessuno).
- Rilascio minore (potrebbe rompere la tua build di lint)
    - Una nuova opzione.
    - Una regola esistente è deprecata.
    - Viene creata una nuova funzionalità della CLI.
    - Vengono aggiunte nuove API pubbliche (nuove classi, nuovi metodi, nuovi argomenti per metodi esistenti, ecc.).
        - Potrebbe rompere le definizioni TypeScript
    - Viene creato un nuovo formattatore.
- Rilascio maggiore (rompe la tua build di lint)
    - Una nuova opzione per una regola esistente che fa sì che Secretlint segnali più errori in modo predefinito.
    - Un formattatore esistente viene rimosso.
    - Aggiunta di una nuova regola predefinita al preset di regole.
    - Parte dell'API pubblica viene rimossa o modificata in modo incompatibile.

## Motivazione

- [git-secrets](https://github.com/awslabs/git-secrets) è utile, ma è difficile da configurare per progetto.
	- Il suo uso principale è l'installazione globale
	- Secretlint vuole essere installato per un progetto e personalizzare le impostazioni per progetto.
- [repo-security-scanner](https://github.com/UKHomeOffice/repo-security-scanner), [Gitleaks](https://github.com/zricethezav/gitleaks) e [truffleHog](https://github.com/dxa4481/truffleHog) sono buoni strumenti di scansione
	- Secretlint necessita di una personalizzazione flessibile che includa definizioni di esclusione e regole personalizzate.
- [detect-secrets](https://github.com/Yelp/detect-secrets) è uno strumento simile, ma adotta un approccio opt-out
    - Secretlint adotta un approccio opt-in  
    - Abbiamo anche bisogno di regole personalizzate da parte dell'utente
		- Vedi [Bring-your own-plugins (BYOP), via --custom-plugins option by KevinHock · Pull Request #255 · Yelp/detect-secrets](https://github.com/Yelp/detect-secrets/pull/255)
- GitHub supporta la [scansione dei segreti](https://docs.github.com/en/code-security/secret-security/about-secret-scanning), ma funziona solo dopo il commit [~~push~~](https://docs.github.com/en/code-security/secret-scanning/push-protection-for-users)
    - Secretlint funziona sulla tua macchina locale, Secretlint può prevenire il commit

## Filosofia

- Ridurre i falsi positivi del linting
- Integrazione nel flusso di lavoro di sviluppo
- Dare potere agli utenti di contribuire

### Opt-in invece di Opt-out

Secretlint adotta un approccio opt-in.

Per nostra esperienza, gli strumenti di linting che segnalano vari errori in modo predefinito sono difficili da usare.
L'approccio opt-in aiuta a introdurre Secretlint in modo incrementale.

Aiuterà a ridurre i falsi positivi tramite la configurazione.

### Regola come documentazione

Consideriamo una regola come una documentazione.
Quindi, ogni regola dovrebbe avere una documentazione ragionevole.

Dobbiamo descrivere perché questo file è un errore.
Una regola senza documentazione è solo una opinione.

Descrivere la ragione dell'errore e questo porterà a ridurre i falsi positivi.

Inoltre, la CLI di Secretlint supporta i collegamenti ipertestuali nel Terminale.
Ciò significa che puoi saltare direttamente alla documentazione della regola dal messaggio di errore di lint.

![collegamento cliccabile nell'output](https://assets.kitploit.com/production/public/readmes/6649/890de2bdbaaae05b3b40c5bbe32b8389a7672beb231308453e585e308afca2be.png)

> Esempio su iTerm 2: Cmd + Clic sul messageId dell'errore e apri [AWSSecretAccessKey](https://github.com/secretlint/secretlint/blob/master/packages/%40secretlint/secretlint-rule-aws/README.md#awssecretaccesskey) nel tuo browser. 

Se vuoi sapere quali terminali supportano questa funzionalità, vedi [Hyperlinks in Terminal Emulators](https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda). 

Inoltre, Benvenuti ai contributi sulla documentazione di Secretlint!

### Perché Node.js?

- Gestione dei pacchetti
	- Richiede un gestore di pacchetti per realizzare un sistema flessibile basato su plugin
	- Node.js ha npm e pnpm come gestori di pacchetti
	- Il gestore di pacchetti aiuta a installare plugin/regole personalizzate da parte dell'utente
- Implementazione di riferimento esistente
	- Node.js ha già strumenti di linting basati su plugin come ESLint, textlint, stylelint, ecc.
	- Quindi gli utenti Node.js hanno familiarità con gli strumenti di linting basati su plugin
	- In precedenza, ho creato textlint con lo stesso approccio, quindi ho familiarità con Node.js
- Utenti
    - JavaScript è un linguaggio popolare
    - Dà potere agli utenti di contribuire
    - Gli utenti possono creare le proprie regole con le proprie mani

Naturalmente, Secretlint supporta anche [Docker](https://hub.docker.com/r/secretlint/secretlint).

## Changelog

Vedi [Pagina delle release](https://github.com/secretlint/secretlint/releases).

## Contribuire

Le pull request e le stelle sono sempre benvenute.

Per bug e richieste di funzionalità, [per favore crea un issue](https://github.com/secretlint/secretlint/issues).

Vedi anche, [CONTRIBUTING.md](https://github.com/secretlint/secretlint/blob/HEAD/CONTRIBUTING.md) e [CODE_OF_CONDUCT.md](https://github.com/secretlint/secretlint/blob/HEAD/CODE_OF_CONDUCT.md)

### Aggiungere una nuova regola

Puoi usare il comando `pnpm run gen:rule` per creare una nuova regola.```shell script
pnpm run gen:rule