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

Você deve então configurar um arquivo de configuração:```
npx secretlint --init

:memo: Secretlint suporta [glob pattern](https://github.com/mrmlnc/fast-glob#basic-syntax) e o glob pattern deve ser envolvido por aspas duplas.

Também é possível instalar o Secretlint globalmente usando `npm install --global`. No entanto, não recomendamos, pois algumas regras podem quebrar globalmente.

### Usando Binário Executável Único

**Pré-requisitos:** Nenhum

Você pode usar o comando `secretlint` sem Node.js utilizando um binário executável único.

1. Baixe o binário mais recente da [página de Releases](https://github.com/secretlint/secretlint/releases)
2. Altere a permissão do arquivo para executável: `chmod +x ./secretlint`
3. Execute `./secretlint --init` para criar um arquivo de configuração
4. Execute `./secretlint "**/*"` para verificar seu projeto

Para mais detalhes, consulte o README em [publish/binary-compiler](https://github.com/secretlint/secretlint/blob/HEAD/publish/binary-compiler).

## Uso

`secretlint --help` mostra o uso.

    CLI Secretlint que escaneia dados de segredos/credenciais.
    
    Uso
    $ secretlint [file|glob*]
    
    Nota
    a sintaxe glob suportada é baseada no picomatch (o motor usado pelo micromatch)
    https://github.com/micromatch/picomatch#globbing-features
    https://github.com/micromatch/micromatch#matching-features
    
    Opções
    --init             configura o arquivo de configuração. Cria o arquivo .secretlintrc.json a partir do seu package.json
    --format           [String] nome do formatador. Padrão: "stylish". Formatadores disponíveis: checkstyle, compact, github, jslint-xml, junit, pretty-error, stylish, tap, unix, json, mask-result, table
    --output           [path:String] caminho do arquivo de saída para o resultado reportado.
    --secretlintrc     [path:String] caminho para o arquivo de configuração .secretlintrc. Padrão: .secretlintrc.*
    --secretlintignore [path:String] caminho para o arquivo .secretlintignore. Padrão: .secretlintignore
    --stdinFileName    [String] nome do arquivo para processar conteúdo do STDIN. Algumas regras dependem do nome do arquivo para verificar o conteúdo.
    --no-color         desabilita cores ANSI na saída.
    --no-terminalLink  desabilita terminalLink na saída.
    --no-maskSecrets   desabilita a máscara de valores secretos; segredos são mascarados por padrão.
    --no-glob          desabilita a interpretação de glob pattern; trata todas as entradas como caminhos de arquivo literais.
    --no-gitignore     desabilita o respeito à cascata do .gitignore; arquivos .gitignore são respeitados por padrão (desde v13).
    
    Opções para Desenvolvedor
    --profile          Ativa o perfil de desempenho.
    --secretlintrcJSON [String] uma string JSON do .secretlintrc. use string JSON em vez do arquivo rc.
    
    Opções Experimentais
    --locale            [String] tag de localidade para traduzir a mensagem. Padrão: en
    
    Exemplos
    # Escaneia um único arquivo
    $ secretlint ./README.md

    # Escaneia todos os arquivos (envolva o glob em aspas duplas para evitar expansão do shell)
    $ secretlint "**/*"
    $ secretlint "source/**/*.ini"

    # Trata entradas como caminhos literais (para SvelteKit (group) / Next.js [param] etc.)
    $ secretlint --no-glob "src/(auth)/login.ts"

    # Verifica conteúdo do STDIN (a dica do nome do arquivo afeta quais regras se aplicam)
    $ echo "SECRET" | secretlint --stdinFileName=secret.txt

    # Usa um arquivo de configuração personalizado
    $ secretlint "**/*" --secretlintrc=.secretlintrc.custom.json

    # Escaneia arquivos ignorados pelo .gitignore (por exemplo, para verificar artefatos de build)
    $ secretlint --no-gitignore "dist/**/*"

    # Mascara segredos em um arquivo in-place
    $ secretlint .zsh_history --format=mask-result --output=.zsh_history

    # Produz JSON para análise programática
    $ secretlint "**/*" --format=json --output=secretlint-report.json

    # Produz anotações do GitHub Actions em CI
    $ secretlint "**/*" --format=github
    
    Status de Saída
    O Secretlint sai com os seguintes valores:
    
        - 0:
          - A verificação foi bem-sucedida, nenhum erro encontrado.
          - Erro de lint encontrado mas --output foi especificado.
        - 1:
          - A verificação falhou, erros encontrados.
        - 2:
          - Ocorreu um erro inesperado, erro fatal.


## Configuração

Secretlint possui um arquivo de configuração `.secretlintrc.{json,yml,js}`.

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

Após executar `secretlint --init`, você terá um arquivo `.secretlintrc.json` em seu diretório.

Nele, você verá algumas regras configuradas assim:```json
{
  "rules": [
    {
      "id": "@secretlint/secretlint-rule-preset-recommend"
    }
  ]
}

Quando você usa um preset como `@secretlint/secretlint-rule-preset-recommend`, você precisa colocar a opção em `rules`.

Por exemplo, uma opção para `@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"
              ]
            }
        }
      ]
    }
  ]
}

O id da mensagem deste erro é `EXAMPLE_MESSAGE` em `@secretlint/secretlint-rule-example`.

Se você quiser ignorar este erro, por favor use `allowMessageIds`.```json
{
  "rules": [
    {
      "id": "@secretlint/secretlint-rule-example",
      "allowMessageIds": ["EXAMPLE_MESSAGE"]
    }
  ]
}

### Ignorando arquivos via `.gitignore` e `.secretlintignore`

O Secretlint percorre o sistema de arquivos da mesma forma que o Git, respeitando arquivos `.gitignore` aninhados. Um arquivo ou diretório correspondido por qualquer `.gitignore` ao longo do caminho do diretório de trabalho até o arquivo é ignorado.

`.secretlintignore` funciona da mesma forma que `.gitignore` e é consultado adicionalmente. A ordem de resolução é:

1. Ignorados internamente: `.git`, `node_modules` e a família `.secretlintrc*`.
2. O arquivo apontado por `--secretlintignore` (padrão: `.secretlintignore`).
3. O `.gitignore` de cada diretório (em cascata).

Para escanear arquivos que estão no gitignore — por exemplo, um arquivo `.env` em um projeto onde `.env` está no gitignore — utilize `--no-gitignore`:```
secretlint --no-gitignore "**/*"

Para mais detalhes, consulte [Configuring Secretlint](https://github.com/secretlint/secretlint/blob/HEAD/docs/configuration.md).

## Casos de Uso

### Mascarar segredos na mensagem de erro do lint (Comportamento padrão)

Por padrão, o Secretlint mascara segredos nas mensagens de erro do lint. Isso é útil para evitar a exposição acidental de segredos em logs de CI, saída de terminal ou ao usar ferramentas de agente de IA.```bash
# Secrets are masked by default
$ secretlint "**/*"

### Corrigir segredos

O Secretlint não pode corrigir os segredos automaticamente.
No entanto, é útil que `--format=mask-result` mascare os segredos do arquivo de entrada.

Por exemplo, você pode mascarar os segredos do arquivo `.zsh_history` e sobrescrevê-lo.```bash
$ secretlint .zsh_history --format=mask-result --output=.zsh_history

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

> **Nota:** A flag `--no-glob` é necessária porque lint-staged passa caminhos de arquivo literais que podem conter caracteres especiais de glob (ex.: padrões de roteamento `(group)` ou `[param]` usados por Next.js, SvelteKit, etc.).

Isso significa que verifica cada arquivo staged pelo Secretlint antes do commit.

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

**Caso de uso:** Você tem um projeto que está sendo desenvolvido com Docker. Fácil de integrar ao secretlint.

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

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

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

### Hook de Pré-commit Globalmente

**Caso de Uso:** Se você quiser verificar qualquer projeto com secretlint, pode usar hooks git globais.

[Git 2.9+](https://github.blog/2016-06-13-git-2-9-has-been-released/) suporta [`core.hooksPath`](https://git-scm.com/docs/githooks).
Ele permite integrar secretlint globalmente.

Criamos um projeto de exemplo de hooks git usando secretlint + Docker.

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

Você pode configurar seguindo os passos abaixo:```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` para anotações de Pull Request

Você pode usar `--format github` para mostrar erros de lint como anotações nos arquivos do Pull Request.
Este formatador gera [comandos de fluxo de trabalho do GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions) que exibem anotações de erro diretamente nos arquivos alterados no seu Pull Request.```yaml
      - name: Lint with Secretlint
        run: npx secretlint --format github "**/*"

#### Mega-Linter

[Mega-Linter](https://nvuillam.github.io/mega-linter/) é um agregador de linters nativamente compatível com qualquer ferramenta de CI, incorporando [80+ aplicativos de linting](https://nvuillam.github.io/mega-linter/supported-linters/), incluindo [**secretlint**](https://nvuillam.github.io/mega-linter/descriptors/credentials_secretlint/) por padrão.

Você pode [instalar](https://nvuillam.github.io/mega-linter/installation/) em qualquer projeto de repositório usando o seguinte comando (Node.js deve estar instalado previamente)```shell
npx mega-linter-runner --install

## Política de Versionamento Semântico

O projeto Secretlint segue [Versionamento Semântico](https://semver.org/ "Semantic Versioning")([secretlint-rule-preset-canary](https://github.com/secretlint/secretlint/blob/HEAD/packages/@secretlint/secretlint-rule-preset-canary) é uma exceção).

- Lançamento de patch (pretendido para não quebrar sua compilação de lint)
    - Correção de bug na CLI ou núcleo (incluindo formatadores).
    - Melhorias na documentação.
    - Mudanças não voltadas ao usuário, como refatoração.
    - Republicação após uma falha na publicação (ou seja, publicar uma versão que não funciona para ninguém).
- Lançamento menor (pode quebrar sua compilação de lint)
    - Uma nova opção.
    - Uma regra existente é descontinuada.
    - Uma nova capacidade da CLI é criada.
    - Novas APIs públicas são adicionadas (novas classes, novos métodos, novos argumentos para métodos existentes, etc.).
        - Pode quebrar definições TypeScript
    - Um novo formatador é criado.
- Lançamento maior (quebra sua compilação de lint)
    - Uma nova opção para uma regra existente que resulta em secretlint relatando mais erros por padrão.
    - Um formatador existente é removido.
    - Adicionar nova regra padrão ao preset de regras.
    - Parte da API pública é removida ou alterada de forma incompatível.

## Motivação

- [git-secrets](https://github.com/awslabs/git-secrets) é útil, mas é difícil configurar por projeto.
	- Seu principal caso de uso é instalação global
	- Secretlint quer instalar para um projeto e personalizar configuração por projeto.
- [repo-security-scanner](https://github.com/UKHomeOffice/repo-security-scanner), [Gitleaks](https://github.com/zricethezav/gitleaks) e [truffleHog](https://github.com/dxa4481/truffleHog) são boas ferramentas de varredura
	- Secretlint precisa de personalização flexível que inclua definições de ignorar, regras personalizadas.
- [detect-secrets](https://github.com/Yelp/detect-secrets) é uma ferramenta similar, mas adota abordagem opt-out
    - Secretlint adota abordagem opt-in  
    - Também precisamos de regras personalizadas pelo usuário
		- Veja [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 suporta [secret scanning](https://docs.github.com/en/code-security/secret-security/about-secret-scanning), mas funciona apenas após o commit [~~push~~](https://docs.github.com/en/code-security/secret-scanning/push-protection-for-users)
    - Secretlint funciona na sua máquina local, Secretlint pode prevenir o commit

## Filosofia

- Reduzir falsos-positivos de linting
- Integração ao fluxo de trabalho de desenvolvimento
- Capacitar Usuários a Contribuir

### Opt-in em vez de Opt-out

Secretlint adota a abordagem opt-in.

Na nossa experiência, ferramentas de linting que relatam vários erros por padrão são difíceis de usar.
A abordagem opt-in ajuda a introduzir Secretlint incrementalmente.

Isso ajudará a reduzir falsos-positivos através da configuração.

### Regra como Documentação

Consideramos uma regra como documentação.
Assim, cada regra deve ter documentação razoável.

Precisamos descrever por que este arquivo é um erro.
Uma regra sem documentação é apenas opinativa.

Descreva o motivo do erro e isso levará a reduzir falsos-positivos.

Além disso, a CLI do Secretlint suporta hyperlink no Terminal.
Isso significa que você pode pular para a documentação da regra diretamente da mensagem de erro de lint.

![link clicável na saída](https://assets.kitploit.com/production/public/readmes/6649/890de2bdbaaae05b3b40c5bbe32b8389a7672beb231308453e585e308afca2be.png)

> Exemplo no iTerm 2: Cmd + Clique na messageId do erro e abra [AWSSecretAccessKey](https://github.com/secretlint/secretlint/blob/master/packages/%40secretlint/secretlint-rule-aws/README.md#awssecretaccesskey) no seu navegador.

Se você quiser saber sobre suporte a terminal, veja [Hyperlinks em Emuladores de Terminal](https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda).

Além disso, contribuições para a documentação do Secretlint são bem-vindas!

### Por que Node.js?

- Gerenciador de Pacotes
	- Requer gerenciador de pacotes para realizar sistema flexível de plugins
	- Node.js tem npm e pnpm como gerenciadores de pacotes
	- Gerenciador de pacotes ajuda a instalar plugin/regra personalizado pelo usuário
- Existe Implementação de Referência
	- Node.js já tem ferramentas de linting com plugins como ESLint, textlint, stylelint etc
	- Então usuários de Node.js estão familiarizados com ferramentas de linting com plugins
	- Anteriormente, criei textlint com a mesma abordagem, então estou familiarizado com Node.js
- Usuários
    - JavaScript é uma linguagem popular
    - Isso capacita os usuários a contribuir
    - Usuários podem criar sua própria regra com as próprias mãos

Claro, secretlint também suporta [Docker](https://hub.docker.com/r/secretlint/secretlint).

## Changelog

Veja a [página de Releases](https://github.com/secretlint/secretlint/releases).

## Contribuindo

Pull requests e estrelas são sempre bem-vindos.

Para bugs e solicitações de funcionalidades, [crie uma issue](https://github.com/secretlint/secretlint/issues).

Veja também, [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)

### Adicionar Nova Regra

Você pode usar o comando `pnpm run gen:rule` para criar uma nova regra.```shell script
pnpm run gen:rule