---
read_when:
    - Написание документации, содержащей токены, ключи API или фрагменты учётных данных
    - Обновление примеров, которые могут сканироваться средствами обнаружения секретов
summary: Соглашения об использовании безопасных для сканера секретов заполнителей в документации и примерах
title: Соглашения об обозначениях-заполнителях для секретов
x-i18n:
    generated_at: "2026-07-13T18:45:32Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 24
    provider: openai
    source_hash: 0864f0fcc6fb1e4a3147b4b2ce0aac475437a19d694f3d059374782428c7f248
    source_path: reference/secret-placeholder-conventions.md
    workflow: 16
---

# Соглашения об обозначениях секретов-заполнителей

Используйте понятные человеку заполнители, которые не похожи на настоящие секреты.

## Рекомендуемый стиль

- Отдавайте предпочтение описательным значениям, таким как `example-openai-key-not-real` или `example-discord-bot-token`.
- В примерах команд оболочки используйте `${OPENAI_API_KEY}` вместо встроенных строк, похожих на токены.
- Примеры должны быть заведомо вымышленными и соответствовать назначению (провайдер, канал, тип аутентификации).

## Избегайте этих шаблонов в документации

- Буквальный текст заголовка или окончания закрытого ключа PEM.
- Префиксы, похожие на действующие учётные данные, например `sk-...`, `xoxb-...`, `AKIA...`.
- Реалистично выглядящие bearer-токены, скопированные из журналов среды выполнения.

## Пример

```bash
# Хорошо
export OPENAI_API_KEY="example-openai-key-not-real"

# Лучше (когда документация посвящена настройке переменных окружения)
export OPENAI_API_KEY="${OPENAI_API_KEY}"
```