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

Затем вам следует настроить файл конфигурации:```
npx secretlint --init

:memo: Secretlint поддерживает [шаблоны glob](https://github.com/mrmlnc/fast-glob#basic-syntax), и шаблоны glob должны быть заключены в двойные кавычки.

Также возможно установить Secretlint глобально с помощью `npm install --global`. Однако мы не рекомендуем это делать, так как некоторые правила могут быть нарушены при глобальной установке.

### Использование единого исполняемого бинарного файла

**Предварительные требования:** Нет

Вы можете использовать команду `secretlint` без Node.js с помощью единого исполняемого бинарного файла.

1. Загрузите последний бинарный файл со [страницы релизов](https://github.com/secretlint/secretlint/releases) 
2. Измените права доступа к файлу на исполняемый: `chmod +x ./secretlint`
3. Выполните `./secretlint --init` для создания файла конфигурации
4. Выполните `./secretlint "**/*"` для проверки вашего проекта

Для получения дополнительной информации обратитесь к README в [publish/binary-compiler](https://github.com/secretlint/secretlint/blob/HEAD/publish/binary-compiler).

## Использование

`secretlint --help` показывает справку по использованию.

    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.

## Конфигурация

Secretlint имеет файл конфигурации `.secretlintrc.{json,yml,js}`.

- Документация: [Настройка Secretlint](https://github.com/secretlint/secretlint/blob/HEAD/docs/configuration.md)

После выполнения `secretlint --init` в вашем каталоге появится файл `.secretlintrc.json`.

В нём вы увидите некоторые правила, настроенные следующим образом:```json
{
  "rules": [
    {
      "id": "@secretlint/secretlint-rule-preset-recommend"
    }
  ]
}

Когда вы используете пресет, например `@secretlint/secretlint-rule-preset-recommend`, вам нужно поместить опцию в `rules`.

Например, опция для `@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"
              ]
            }
        }
      ]
    }
  ]
}

Идентификатор сообщения этой ошибки — `EXAMPLE_MESSAGE` в `@secretlint/secretlint-rule-example`.

Если вы хотите игнорировать эту ошибку, используйте `allowMessageIds`.```json
{
  "rules": [
    {
      "id": "@secretlint/secretlint-rule-example",
      "allowMessageIds": ["EXAMPLE_MESSAGE"]
    }
  ]
}

### Игнорирование файлов с помощью `.gitignore` и `.secretlintignore`

Secretlint обходит файловую систему так же, как и Git, учитывая вложенные файлы `.gitignore`. Файл или каталог, соответствующий любому `.gitignore` на пути от рабочей директории до файла, пропускается.

`.secretlintignore` работает так же, как `.gitignore`, и учитывается дополнительно. Порядок разрешения:

1. Встроенные исключения: `.git`, `node_modules` и семейство `.secretlintrc*`.
2. Файл, указанный через `--secretlintignore` (по умолчанию: `.secretlintignore`).
3. `.gitignore` каждого каталога (каскадно).

Чтобы сканировать файлы, которые игнорируются git — например, файл `.env` в проекте, где `.env` добавлен в `.gitignore` — используйте `--no-gitignore`:```
secretlint --no-gitignore "**/*"

Для получения дополнительных сведений, пожалуйста, обратитесь к [Настройке Secretlint](https://github.com/secretlint/secretlint/blob/HEAD/docs/configuration.md).

## Варианты использования

### Маскировка секретов в сообщениях об ошибках линтинга (поведение по умолчанию)

Secretlint по умолчанию маскирует секреты в сообщениях об ошибках линтинга. Это полезно для предотвращения случайного раскрытия секретов в журналах CI, выводе терминала или при использовании инструментов AI-агентов.```bash
# Secrets are masked by default
$ secretlint "**/*"

### Исправление секретов

Secretlint не может автоматически исправлять секреты.
Однако полезно то, что `--format=mask-result` маскирует секреты входного файла.

Например, вы можете замаскировать секреты в файле `.zsh_history` и перезаписать его.```bash
$ secretlint .zsh_history --format=mask-result --output=.zsh_history

Добавьте хуки в `.husky/pre-commit`:```
npx husky add .husky/pre-commit "npx --no-install lint-staged"

> **Примечание:** Флаг `--no-glob` обязателен, поскольку lint-staged передаёт буквальные пути файлов, которые могут содержать специальные символы глобов (например, шаблоны маршрутизации `(group)` или `[param]`, используемые в Next.js, SvelteKit и т.д.).

Это означает, что каждый проиндексированный файл проверяется Secretlint перед коммитом.

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

**Сценарий использования:** У вас есть проект, который разрабатывается с помощью Docker. Легко интегрируется с Secretlint.

Установите [pre-commit](https://pre-commit.com/#install)

    # macOS. см. также https://pre-commit.com/#install
    brew install pre-commit

Создайте `.pre-commit-config.yaml`:```
-   repo: local
    hooks:
    -   id: secretlint
        name: secretlint
        language: docker_image
        entry: secretlint/secretlint:latest secretlint

### Pre-commit Hook глобально

**Сценарий использования:** Если вы хотите проверить любой проект с помощью secretlint, вы можете использовать глобальные хуки git.

[Git 2.9+](https://github.blog/2016-06-13-git-2-9-has-been-released/) поддерживает [`core.hooksPath`](https://git-scm.com/docs/githooks). Это позволяет интегрировать secretlint глобально.

Мы создали пример проекта git хуков, использующего secretlint + Docker.

- [secretlint/git-hooks](https://github.com/secretlint/git-hooks)
    - Требование: Docker

Вы можете настроить, выполнив следующие шаги:```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` для аннотаций Pull Request

Вы можете использовать `--format github` для отображения ошибок линтинга в виде аннотаций на файлах Pull Request.
Этот форматировщик выводит [команды рабочего процесса GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions), которые отображают аннотации ошибок непосредственно на измененных файлах в вашем Pull Request.```yaml
      - name: Lint with Secretlint
        run: npx secretlint --format github "**/*"

#### Mega-Linter

[Mega-Linter](https://nvuillam.github.io/mega-linter/) — это агрегатор линтеров, нативно совместимый с любым CI-инструментом, включающий [более 80 приложений для линтинга](https://nvuillam.github.io/mega-linter/supported-linters/), в том числе [**secretlint**](https://nvuillam.github.io/mega-linter/descriptors/credentials_secretlint/) по умолчанию.

Вы можете [установить](https://nvuillam.github.io/mega-linter/installation/) его в любом репозитории проекта, используя следующую команду (Node.js должен быть предварительно установлен)```shell
npx mega-linter-runner --install

## Политика семантического версионирования

Проект Secretlint следует [семантическому версионированию](https://semver.org/ "Семантическое версионирование") ([secretlint-rule-preset-canary](https://github.com/secretlint/secretlint/blob/HEAD/packages/@secretlint/secretlint-rule-preset-canary) является исключением).

- Патч-релиз (предполагается, что не нарушает вашу сборку линтинга)
    - Исправление ошибки в CLI или ядре (включая форматтеры).
    - Улучшения документации.
    - Изменения, невидимые для пользователя, такие как рефакторинг.
    - Перевыпуск после неудачного релиза (т.е. публикация версии, которая ни у кого не работает).
- Минорный релиз (может нарушить вашу сборку линтинга)
    - Новая опция.
    - Существующее правило объявлено устаревшим.
    - Создана новая возможность CLI.
    - Добавлены новые публичные API (новые классы, новые методы, новые аргументы для существующих методов и т.д.).
        - Это может нарушить определения TypeScript.
    - Создан новый форматтер.
- Мажорный релиз (нарушает вашу сборку линтинга)
    - Новая опция для существующего правила, которая приводит к тому, что secretlint по умолчанию сообщает о большем количестве ошибок.
    - Удаление существующего форматтера.
    - Добавление нового правила по умолчанию в пресет правил.
    - Часть публичного API удалена или изменена несовместимым образом.

## Мотивация

- [git-secrets](https://github.com/awslabs/git-secrets) полезен, но его сложно настраивать для каждого проекта.
	- Его основной сценарий использования — глобальная установка.
	- Secretlint предназначен для установки в проект и настройки под каждый проект.
- [repo-security-scanner](https://github.com/UKHomeOffice/repo-security-scanner), [Gitleaks](https://github.com/zricethezav/gitleaks) и [truffleHog](https://github.com/dxa4481/truffleHog) — хорошие инструменты сканирования.
	- Secretlint требует гибкой настройки, включая правила игнорирования и пользовательские правила.
- [detect-secrets](https://github.com/Yelp/detect-secrets) — похожий инструмент, но он использует подход opt-out (отказ от участия).
    - Secretlint использует подход opt-in (согласие на участие).
    - Нам также нужны пользовательские правила.
		- См. [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 поддерживает [сканирование секретов](https://docs.github.com/en/code-security/secret-security/about-secret-scanning), но оно работает только после коммита [~~push~~](https://docs.github.com/en/code-security/secret-scanning/push-protection-for-users).
    - Secretlint работает на вашем локальном компьютере и может предотвратить коммит.

## Философия

- Уменьшение количества ложных срабатываний при линтинге.
- Интеграция в рабочий процесс разработки.
- Предоставление пользователям возможности вносить свой вклад.

### Opt-in вместо Opt-out

Secretlint использует подход opt-in (согласие на участие).

Наш опыт показывает, что инструменты линтинга, которые по умолчанию сообщают о различных ошибках, сложны в использовании.
Подход opt-in помогает внедрять Secretlint постепенно.

Это поможет уменьшить количество ложных срабатываний с помощью конфигурации.

### Правило как документация

Мы рассматриваем правило как документацию.
Поэтому каждое правило должно иметь разумную документацию.

Нам нужно объяснять, почему этот файл является ошибкой.
Правило без документации — всего лишь субъективное мнение.

Объяснение причины ошибки поможет уменьшить количество ложных срабатываний.

Кроме того, CLI Secretlint поддерживает гиперссылки в терминале.
Это означает, что вы можете перейти непосредственно к документации правила из сообщения об ошибке линтинга.

![кликабельная ссылка в выводе](https://assets.kitploit.com/production/public/readmes/6649/890de2bdbaaae05b3b40c5bbe32b8389a7672beb231308453e585e308afca2be.png)

> Пример на iTerm 2: Cmd + щелчок по messageId ошибки, чтобы открыть [AWSSecretAccessKey](https://github.com/secretlint/secretlint/blob/master/packages/%40secretlint/secretlint-rule-aws/README.md#awssecretaccesskey) в браузере.

Если вы хотите узнать о поддерживаемых терминалах, см. [Гиперссылки в эмуляторах терминала](https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda).

Также приветствуются любые contributions к документации secretlint!

### Почему Node.js?

- Менеджер пакетов
	- Для реализации гибкой плагинной системы требуется менеджер пакетов.
	- В Node.js есть npm и pnpm в качестве менеджеров пакетов.
	- Менеджер пакетов помогает устанавливать пользовательские плагины/правила.
- Существующая эталонная реализация
	- В Node.js уже есть плагинные инструменты линтинга, такие как ESLint, textlint, stylelint и т.д.
	- Поэтому пользователи Node.js знакомы с плагинными инструментами линтинга.
	- Ранее я создал textlint с тем же подходом, поэтому я знаком с Node.js.
- Пользователи
    - JavaScript — популярный язык.
    - Это даёт пользователям возможность вносить свой вклад.
    - Пользователи могут создавать собственные правила самостоятельно.

Конечно, secretlint также поддерживает [Docker](https://hub.docker.com/r/secretlint/secretlint).

## Список изменений

См. [страницу релизов](https://github.com/secretlint/secretlint/releases).

## Участие

Pull request'ы и звёзды всегда приветствуются.

Для сообщений об ошибках и запросов функций [пожалуйста, создайте issue](https://github.com/secretlint/secretlint/issues).

Также см. [CONTRIBUTING.md](https://github.com/secretlint/secretlint/blob/HEAD/CONTRIBUTING.md) и [CODE_OF_CONDUCT.md](https://github.com/secretlint/secretlint/blob/HEAD/CODE_OF_CONDUCT.md)

### Добавление нового правила

Вы можете использовать команду `pnpm run gen:rule` для создания нового правила.```shell script
pnpm run gen:rule