Использование крючков с Copilot CLI для предсказуемого, соответствующего политикам выполнению

Используйте крючки для ведения пользовательских запросов и контроля, какие инструменты Интерфейс командной строки Copilot могут запускаться в репозитории, чтобы команды могли безопасно автоматизировать работу в рамках требований безопасности и соответствия вашей организации.

В этой статье

Этот туториал предназначен для инженеров DevOps, команд платформ и инженерных лидеров, которые поддерживают разработчиков с помощью Интерфейс командной строки Copilot.

Хуки — это пользовательские скрипты, которые выполняются в определённых точках во время сессии Интерфейс командной строки Copilot. Они могут проверять запросы и вызовы инструментов, вести лог для аудита и даже блокировать выполнение определённых команд.

Вы настроите крючки с репозиторием, которые:

  • Обеспечивайте видимость в подсказках и использовании инструментов.
  • Блокируйте опасные паттерны команд перед выполнением.
  • Помогите разработчикам понять организационные политики с помощью чётких сообщений.

Предпосылки

  • Знакомство с скриптингом оболочек (Bash или PowerShell)
  • Базовое понимание конфигурационных файлов JSON
  • Доступ к репозиторию, где используется Интерфейс командной строки Copilot
  •         `jq` установлен (для примеров Bash)

1. Определить организационную политику

Прежде чем писать скрипты с крючками, решите, какие действия должны быть разрешены автоматически, а какие требуют человеческого рассмотрения.

Чёткая политика помогает избежать чрезмерной блокировки, одновременно снижая риски.

Определите команды, которые всегда требуют повторения

Начните с выявления шаблонов, которые никогда не должны автоматически выполняться Интерфейс командной строки Copilot. Распространенные примеры:

  •         **Повышение привилегий**: `sudo`, `su`, `runas`

  •         **Деструктивные операции системы**: `rm -rf /`, `mkfs`, `dd`, `format`

  •         **Шаблоны загрузки и выполнения**: `curl ... | bash`, `wget ... | sh`, PowerShell `iex (irm ...)`

Эти команды могут иметь необратимые последствия, если выполняться непреднамеренно.

Решите, что именно записывать

При использовании крючков вы можете собирать информацию о том, как Интерфейс командной строки Copilot используется в репозитории, включая запросы, присланные пользователями, и инструменты, которые Интерфейс командной строки Copilot пытается запустить.

Минимум, большинство организаций ведут регистрацию:

  • Временная метка и путь репозитория
  • Текст запроса (или отредактированная форма)
  • Название инструмента и аргументы инструмента
  • Любое политическое решение (например, отклонённая команда и её причина)

Избегайте регистрации секретов или учетных данных. Если подсказки или команды могут содержать конфиденциальные данные, примените редактирование перед записыванием журналов.

В этом учебном пособии используется локальный .github/hooks/logs каталог в качестве простого и наглядного примера. Эти лог-файлы не предназначены для фиксации в репозитории и обычно находятся только на машине разработчика.

В производственных условиях многие организации пересылают события hook в централизованную систему логирования или наблюдаемости вместо локальной записи журналов. Это позволяет командам применять последовательные редактирование, контроль доступа, политики сохранения и мониторинг между репозиториями и пользователями.

Согласование с заинтересованными сторонами

Перед применением политики изучите их следующими:

  • Команды безопасности или комплаенса, чтобы подтвердить границы рисков
  • Команды платформы или инфраструктуры, которым могут понадобиться более широкие разрешения
  • Команды разработки, чтобы они понимали, что будет заблокировано и почему

Чёткие ожидания облегчают принятие и поддержание исполнения политики.

2. Настройте файлы с крючками репозитория

На протяжении всего этого учебника вы будете использовать крючки с репозиторийным диапазоном , хранящиеся в репозитории под .github/hooks/. Эти крючки применяются, когда Интерфейс командной строки Copilot запускается из этого репозитория.

Примечание.

Copilot агенты загружают конфигурационные файлы .github/hooks/*.json из репозитория. Крючки работают синхронно и могут блокировать выполнение.

Создать структуру каталога

Из корня репозитория создайте каталоги для конфигурации хуков, скриптов и логов:

Bash
mkdir -p .github/hooks/scripts
mkdir -p .github/hooks/logs

Добавьте .github/hooks/logs/ в .gitignore для того, чтобы локальные журналы аудита не фиксировались:

Bash
echo ".github/hooks/logs/" >> .gitignore

Этот учебник использует следующую структуру:

.github/
└── hooks/
    ├── copilot-cli-policy.json
    ├── logs/
    │   └── audit.jsonl
    └── scripts/
        ├── session-banner.sh
        ├── session-banner.ps1
        ├── log-prompt.sh
        ├── log-prompt.ps1
        ├── pre-tool-policy.sh
        └── pre-tool-policy.ps1

Создайте конфигурационный файл крючка

Создайте конфигурационный файл крючка по адресу .github/hooks/copilot-cli-policy.json.

Этот файл определяет, какие хуки запускаются, когда они запускаются и какие скрипты они выполняют.

JSON
{
  "version": 1,
  "hooks": {
    "sessionStart": [
      {
        "type": "command",
        "bash": "./scripts/session-banner.sh",
        "powershell": "./scripts/session-banner.ps1",
        "cwd": ".github/hooks",
        "timeoutSec": 10
      }
    ],
    "userPromptSubmitted": [
      {
        "type": "command",
        "bash": "./scripts/log-prompt.sh",
        "powershell": "./scripts/log-prompt.ps1",
        "cwd": ".github/hooks",
        "timeoutSec": 10
      }
    ],
    "preToolUse": [
      {
        "type": "command",
        "bash": "./scripts/pre-tool-policy.sh",
        "powershell": "./scripts/pre-tool-policy.ps1",
        "cwd": ".github/hooks",
        "timeoutSec": 15
      }
    ]
  }
}

Поймите, что делает эта конфигурация

Эта конфигурация задаёт три крючка:

  •         `sessionStart`: Показывает информационное сообщение при начале или возобновлении сессии нового агента.

  •         `userPromptSubmitted`: Запускается всякий раз, когда пользователь отправляет запрос.

  •         `preToolUse`: Запускается до запуска инструмента и может явно разрешать или отклонять выполнение.

Зафиксируйте и поделитесь конфигурацией хука

Когда будете готовы поделиться конфигурацией крючка с соавторами (например, через pull-запрос или в тестовом репозитории), зафиксируйте конфигурацию хука и скрипты. Не фиксируйте локальные журналы аудита.

Bash
git add .github/hooks/copilot-cli-policy.json .github/hooks/scripts
git commit -m "Add Copilot CLI hook configuration"
git push

На этом этапе Интерфейс командной строки Copilot может обнаружить конфигурацию крюка, даже если скрипты хуков ещё не создали.

3. Добавить баннер политики при начале сессии

Используйте sessionStart крючок, чтобы показать баннер всякий раз, когда начинается или возобновляется новая сессия Интерфейс командной строки Copilot. Это ясно даёт разработчикам понять, что организационные политики активны.

          `sessionStart` Крючок получает контекстную информацию, такую как текущий рабочий каталог и начальный запрос. Любой выход этого крючка игнорируется Интерфейс командной строки Copilot, что делает его подходящим для информационных сообщений.

Создать скрипт сессионного баннера (Bash)

Создание .github/hooks/scripts/session-banner.sh:

Bash
#!/bin/bash
set -euo pipefail

cat << 'EOF'
COPILOT CLI POLICY ACTIVE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• Prompts and tool use may be logged for auditing
• High-risk commands may be blocked automatically
• If something is blocked, follow the guidance shown
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
EOF
exit 0

Создать скрипт сессионного баннера (PowerShell)

Создание .github/hooks/scripts/session-banner.ps1:

PowerShell
$ErrorActionPreference = "Stop"

Write-Host @"
COPILOT CLI POLICY ACTIVE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• Prompts and tool use may be logged for auditing
• High-risk commands may be blocked automatically
• If something is blocked, follow the guidance shown
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
"@
exit 0

Протестируйте баннер сессии

Вы можете протестировать баннерные скрипты напрямую:

.github/hooks/scripts/session-banner.sh
# or, for PowerShell
.github/hooks/scripts/session-banner.ps1

Когда вы запускаете любой из этих скриптов, вы должны увидеть баннер политики в терминале.

4. Журнал запросов для аудита

Используйте userPromptSubmitted крючок для записи, когда пользователи отправляют запросы в Интерфейс командной строки Copilot. Этот крюк запускается всякий раз, когда отправляется запрос, до запуска любых инструментов.

Крючок получает структурированный JSON-ввод, включающий временную метку, текущий рабочий каталог и полный текст запроса. Вывод этого хука игнорируется.

Внимание

Подсказки могут содержать конфиденциальную информацию. Применяйте редактирование и следуйте политике обработки и хранения данных вашей организации при регистрации этих данных.

Создать скрипт логирования запросов (Bash)

Создание .github/hooks/scripts/log-prompt.sh:

Bash
#!/bin/bash
set -euo pipefail

INPUT="$(cat)"

TIMESTAMP_MS="$(echo "$INPUT" | jq -r '.timestamp // empty')"
CWD="$(echo "$INPUT" | jq -r '.cwd // empty')"

# This example logs only metadata, not the full prompt, to avoid storing
# potentially sensitive data. Adjust to match your organization’s needs.
LOG_DIR=".github/hooks/logs"
mkdir -p "$LOG_DIR"
chmod 700 "$LOG_DIR"

jq -n \
  --arg ts "$TIMESTAMP_MS" \
  --arg cwd "$CWD" \
  '{event:"userPromptSubmitted", timestampMs:$ts, cwd:$cwd}' \
  >> "$LOG_DIR/audit.jsonl"

exit 0

Создайте скрипт логирования запросов (PowerShell)

Создание .github/hooks/scripts/log-prompt.ps1:

PowerShell
$ErrorActionPreference = "Stop"

$inputObj = [Console]::In.ReadToEnd() | ConvertFrom-Json

$timestampMs = $inputObj.timestamp
$cwd = $inputObj.cwd
$prompt = $inputObj.prompt

# Optional example redaction. Adjust to match your organization’s needs.
$redactedPrompt = $prompt -replace 'ghp_[A-Za-z0-9]{20,}', '[REDACTED_TOKEN]'

$logDir = ".github/hooks/logs"
if (-not (Test-Path $logDir)) {
  New-Item -ItemType Directory -Path $logDir -Force | Out-Null
}

$logEntry = @{
  event       = "userPromptSubmitted"
  timestampMs = $timestampMs
  cwd         = $cwd
  prompt      = $redactedPrompt
} | ConvertTo-Json -Compress

Add-Content -Path "$logDir/audit.jsonl" -Value $logEntry
exit 0

Протестируйте скрипт логирования запросов

Вы можете тестировать скрипты напрямую, передавая пример ввода.

echo '{"timestamp":1704614500000,"cwd":"/repo","prompt":"List all branches"}' \
  | .github/hooks/scripts/log-prompt.sh
# or, for PowerShell
echo '{"timestamp":1704614500000,"cwd":"/repo","prompt":"List all branches"}' |
  .github/hooks/scripts/log-prompt.ps1

После запуска скрипта проверьте .github/hooks/logs/audit.jsonl наличие новой записи в журнале.

Bash
cat .github/hooks/logs/audit.jsonl

На этом этапе запросы, отправленные в Интерфейс командной строки Copilot в этом репозитории, записываются для аудита.

5. Применять политики с помощью preToolUse

Используйте крючок preToolUse , чтобы оценить вызов инструмента перед его запуском. Этот крючок может позволить выполнить (ничего не делая) или запретить выполнение (возвращая структурированный ответ).

Поймите вводные preToolUse данные

Ввод preToolUse с крюком включает:

  •         `toolName`: Инструмент, который Интерфейс командной строки Copilot вот-вот запустит (например, `bash`)

  •         `toolArgs`: **JSON-строка** , содержащая аргументы этого инструмента

Поскольку toolArgs это JSON-строка, ваш скрипт должен анализировать её перед чтением полей, таких как command.

Внимание

Аргументы и команды инструментов могут содержать конфиденциальную информацию, такую как токены API, пароли или другие учетные данные. Примените редактирование перед регистрацией этих данных и следуйте политикам безопасности вашей организации. Рассмотрите возможность записи только нечувствительных метаданных (имя инструмента, временная метка, решение по политике) и направлять аудитские события в защищённую централизованную систему логирования с соответствующими контролями доступа и политиками сохранения.

Создайте скрипт политики

Далее создайте скрипт политики. В этом примере:

  • Записывает все попытки использования инструмента.
  • Применяет правила отказа только к командам удара.
  • Блокирует опасные паттерны, такие как повышение привилегий, разрушительные операции и команды на загрузку и выполнение.

Чтобы безопасно проверить поток deny, скрипт также включает временное правило демонстрации, блокирующее безвредную команду тестирования. Убедившись, что крючки работают как следует, уберите правило демонстрации и замените его шаблонами, отражающими политику вашей организации.

Пример сценария (Bash)

Создание .github/hooks/scripts/pre-tool-policy.sh:

Bash
#!/bin/bash
set -euo pipefail

INPUT="$(cat)"

TOOL_NAME="$(echo "$INPUT" | jq -r '.toolName // empty')"
TOOL_ARGS_RAW="$(echo "$INPUT" | jq -r '.toolArgs // empty')"  # JSON string

LOG_DIR=".github/hooks/logs"
mkdir -p "$LOG_DIR"

# Example redaction logic.
# GitHub does not currently provide built-in secret redaction for hooks.
# This example shows one possible approach; many organizations prefer to
# forward events to a centralized logging system that handles redaction.
# Redact sensitive patterns before logging.
# Adjust these patterns to match your organization's needs.
REDACTED_TOOL_ARGS="$(echo "$TOOL_ARGS_RAW" | \
  sed -E 's/ghp_[A-Za-z0-9]{20,}/[REDACTED_TOKEN]/g' | \
  sed -E 's/gho_[A-Za-z0-9]{20,}/[REDACTED_TOKEN]/g' | \
  sed -E 's/ghu_[A-Za-z0-9]{20,}/[REDACTED_TOKEN]/g' | \
  sed -E 's/ghs_[A-Za-z0-9]{20,}/[REDACTED_TOKEN]/g' | \
  sed -E 's/Bearer [A-Za-z0-9_\-\.]+/Bearer [REDACTED]/g' | \
  sed -E 's/--password[= ][^ ]+/--password=[REDACTED]/g' | \
  sed -E 's/--token[= ][^ ]+/--token=[REDACTED]/g')"

# Log attempted tool use with redacted toolArgs.
jq -n \
  --arg tool "$TOOL_NAME" \
  --arg toolArgs "$REDACTED_TOOL_ARGS" \
  '{event:"preToolUse", toolName:$tool, toolArgs:$toolArgs}' \
  >> "$LOG_DIR/audit.jsonl"

# Only enforce command rules for bash.
if [ "$TOOL_NAME" != "bash" ]; then
  exit 0
fi

# Parse toolArgs JSON string.
# If toolArgs isn't valid JSON for some reason, allow (and rely on logs).
if ! echo "$TOOL_ARGS_RAW" | jq -e . >/dev/null 2>&1; then
  exit 0
fi

COMMAND="$(echo "$TOOL_ARGS_RAW" | jq -r '.command // empty')"

# ---------------------------------------------------------------------------
# Demo-only deny rule for safe testing.
# This blocks a harmless test command so you can validate the deny flow.
# Remove this rule after confirming your hooks work as expected.
# ---------------------------------------------------------------------------
if echo "$COMMAND" | grep -q "COPILOT_HOOKS_DENY_DEMO"; then
  deny "Blocked demo command (test rule). Remove this rule after validating hooks."
fi

deny() {
  local reason="$1"

  # Redact sensitive patterns from command before logging.
  local redacted_cmd="$(echo "$COMMAND" | \
    sed -E 's/ghp_[A-Za-z0-9]{20,}/[REDACTED_TOKEN]/g' | \
    sed -E 's/gho_[A-Za-z0-9]{20,}/[REDACTED_TOKEN]/g' | \
    sed -E 's/ghu_[A-Za-z0-9]{20,}/[REDACTED_TOKEN]/g' | \
    sed -E 's/ghs_[A-Za-z0-9]{20,}/[REDACTED_TOKEN]/g' | \
    sed -E 's/Bearer [A-Za-z0-9_\-\.]+/Bearer [REDACTED]/g' | \
    sed -E 's/--password[= ][^ ]+/--password=[REDACTED]/g' | \
    sed -E 's/--token[= ][^ ]+/--token=[REDACTED]/g')"

  # Log the denial decision with redacted command.
  jq -n \
    --arg cmd "$redacted_cmd" \
    --arg r "$reason" \
    '{event:"policyDeny", toolName:"bash", command:$cmd, reason:$r}' \
    >> "$LOG_DIR/audit.jsonl"

  # Return a denial response.
  jq -n \
    --arg r "$reason" \
    '{permissionDecision:"deny", permissionDecisionReason:$r}'

  exit 0
}

# Privilege escalation
if echo "$COMMAND" | grep -qE '\b(sudo|su|runas)\b'; then
  deny "Privilege escalation requires manual approval."
fi

# Destructive filesystem operations targeting root
if echo "$COMMAND" | grep -qE 'rm\s+-rf\s*/($|\s)|rm\s+.*-rf\s*/($|\s)'; then
  deny "Destructive operations targeting the filesystem root require manual approval."
fi

# System-level destructive operations
if echo "$COMMAND" | grep -qE '\b(mkfs|dd|format)\b'; then
  deny "System-level destructive operations are not allowed via automated execution."
fi

# Download-and-execute patterns
if echo "$COMMAND" | grep -qE 'curl.*\|\s*(bash|sh)|wget.*\|\s*(bash|sh)'; then
  deny "Download-and-execute patterns require manual approval."
fi

# Allow by default
exit 0

Создайте скрипт политики (PowerShell)

Создание .github/hooks/scripts/pre-tool-policy.ps1:

PowerShell
$ErrorActionPreference = "Stop"

$inputObj = [Console]::In.ReadToEnd() | ConvertFrom-Json
$toolName = $inputObj.toolName
$toolArgsRaw = $inputObj.toolArgs  # JSON string

$logDir = ".github/hooks/logs"
if (-not (Test-Path $logDir)) { New-Item -ItemType Directory -Path $logDir -Force | Out-Null }

# Example redaction logic.
# GitHub does not currently provide built-in secret redaction for hooks.
# This example shows one possible approach; many organizations prefer to
# forward events to a centralized logging system that handles redaction.
# Redact sensitive patterns before logging.
# Adjust these patterns to match your organization's needs.
$redactedToolArgs = $toolArgsRaw `
  -replace 'ghp_[A-Za-z0-9]{20,}', '[REDACTED_TOKEN]' `
  -replace 'gho_[A-Za-z0-9]{20,}', '[REDACTED_TOKEN]' `
  -replace 'ghu_[A-Za-z0-9]{20,}', '[REDACTED_TOKEN]' `
  -replace 'ghs_[A-Za-z0-9]{20,}', '[REDACTED_TOKEN]' `
  -replace 'Bearer [A-Za-z0-9_\-\.]+', 'Bearer [REDACTED]' `
  -replace '--password[= ][^ ]+', '--password=[REDACTED]' `
  -replace '--token[= ][^ ]+', '--token=[REDACTED]'

# Log attempted tool use with redacted toolArgs.
(@{
  event    = "preToolUse"
  toolName = $toolName
  toolArgs = $redactedToolArgs
} | ConvertTo-Json -Compress) | Add-Content -Path "$logDir/audit.jsonl"

if ($toolName -ne "bash") { exit 0 }

# Parse toolArgs JSON string.
$toolArgs = $null
try { $toolArgs = $toolArgsRaw | ConvertFrom-Json } catch { exit 0 }

$command = $toolArgs.command

# ---------------------------------------------------------------------------
# Demo-only deny rule for safe testing.
# This blocks a harmless test command so you can validate the deny flow.
# Remove this rule after confirming your hooks work as expected.
# ---------------------------------------------------------------------------
if ($command -match 'COPILOT_HOOKS_DENY_DEMO') {
  Deny "Blocked demo command (test rule). Remove this rule after validating hooks."
}

function Deny([string]$reason) {
  # Redact sensitive patterns from command before logging.
  $redactedCommand = $command `
    -replace 'ghp_[A-Za-z0-9]{20,}', '[REDACTED_TOKEN]' `
    -replace 'gho_[A-Za-z0-9]{20,}', '[REDACTED_TOKEN]' `
    -replace 'ghu_[A-Za-z0-9]{20,}', '[REDACTED_TOKEN]' `
    -replace 'ghs_[A-Za-z0-9]{20,}', '[REDACTED_TOKEN]' `
    -replace 'Bearer [A-Za-z0-9_\-\.]+', 'Bearer [REDACTED]' `
    -replace '--password[= ][^ ]+', '--password=[REDACTED]' `
    -replace '--token[= ][^ ]+', '--token=[REDACTED]'

  # Log the denial decision with redacted command.
  (@{
    event    = "policyDeny"
    toolName = "bash"
    command  = $redactedCommand
    reason   = $reason
  } | ConvertTo-Json -Compress) | Add-Content -Path "$logDir/audit.jsonl"

  (@{
    permissionDecision = "deny"
    permissionDecisionReason = $reason
  } | ConvertTo-Json -Compress)

  exit 0
}

if ($command -match '\b(sudo|su|runas)\b') { Deny "Privilege escalation requires manual approval." }
if ($command -match 'rm\s+-rf\s*/(\s|$)|rm\s+.*-rf\s*/(\s|$)') { Deny "Destructive operations targeting the filesystem root require manual approval." }
if ($command -match '\b(mkfs|dd|format)\b') { Deny "System-level destructive operations are not allowed via automated execution." }
if ($command -match 'curl.*\|\s*(bash|sh)|wget.*\|\s*(bash|sh)') { Deny "Download-and-execute patterns require manual approval." }

exit 0

Протестируйте скрипт политики

Вы можете протестировать скрипты, передавая примерные preToolUse входы.

Допустим пример:

echo '{"toolName":"bash","toolArgs":"{\"command\":\"git status\"}"}' \
  | .github/hooks/scripts/pre-tool-policy.sh
# or, for PowerShell
echo '{"toolName":"bash","toolArgs":"{\"command\":\"git status\"}"}' |
  .github/hooks/scripts/pre-tool-policy.ps1

Пример отклонения:

echo '{"toolName":"bash","toolArgs":"{\"command\":\"sudo rm -rf /\"}"}' \
  | .github/hooks/scripts/pre-tool-policy.sh
# or, for PowerShell
echo '{"toolName":"bash","toolArgs":"{\"command\":\"sudo rm -rf /\"}"}' |
  .github/hooks/scripts/pre-tool-policy.ps1

После запуска примера отказа проверьте .github/hooks/logs/audit.jsonl наличие новой записи в журнале отказа.

{"permissionDecision":"deny","permissionDecisionReason":"Privilege escalation requires manual approval."}

На этом этапе команды высокого риска bash блокируются от автоматического выполнения в этом репозитории.

6. Тестирование сквозь конец в репозитории

После создания конфигурационного файла и скриптов убедитесь, что крючки работают как ожидается, когда вы используете Интерфейс командной строки Copilot в этом репозитории.

Проверьте конфигурационный файл крючка

Проверьте, что ваш файл конфигурации крюка является действительным JSON:

Bash
jq '.' < .github/hooks/copilot-cli-policy.json

Проверка разрешений скриптов (системы на базе Unix)

На macOS и Linux убедитесь, что ваши Bash-скрипты исполняемы:

Bash
chmod +x .github/hooks/scripts/*.sh

Проведите базовую сессию

Запустите новую сессию Интерфейс командной строки Copilot в репозитории:

Bash
copilot -p "Show me the status of this repository"

Ожидаемые результаты:

  • Вы видите баннер политики (от sessionStart).
  • Добавляется новая запись в .github/hooks/logs/audit.jsonl (из userPromptSubmitted).

Использование инструмента и проверка логирования

Запустите запрос, который заставляет Интерфейс командной строки Copilot использовать инструмент (например, bash):

Bash
copilot -p "Show me the last 5 git commits"

Ожидаемые результаты:

  • В . .github/hooks/logs/audit.jsonlдобавляется запись.preToolUse
  • Если вызов инструмента разрешен, выполнение происходит нормально.

Проверьте отклонённую команду

Примерный скрипт политики включает временное правило демонстрации, блокирующее команды, содержащие строку COPILOT_HOOKS_DENY_DEMO. Это позволяет безопасно проверить поток запрета без выполнения разрушительных команд.

Запустите подсказку, которая вызовет отклонённую команду:

Bash
copilot -p "Run a test command: echo COPILOT_HOOKS_DENY_DEMO"

Ожидаемые результаты:

  • Интерфейс командной строки Copilot не выполняет команду.
  • Ваш крючок отвечает отказом с чёткой причиной.
  • Запись policyDeny записывается на .github/hooks/logs/audit.jsonl.

Убедившись, что поток отказов работает корректно, удалите правило демонстрации из скрипта и замените его шаблонами отказа, отражающими политику вашей организации.

Проверьте свои журналы аудита

Чтобы посмотреть последние записи:

Bash
tail -n 50 .github/hooks/logs/audit.jsonl

Фильтровать только отклонённые решения:

Bash
jq 'select(.event=="policyDeny")' .github/hooks/logs/audit.jsonl

7. Безопасно распределяйтесь между командами

После проверки ваших крючков в одном репозитории внедряйте их постепенно, чтобы не мешать рабочим процессам разработки.

Выберите стратегию внедрения

Распространённые подходы к внедрению включают:

  •         **Внедрение с первым входом (рекомендуется**): начните с регистрации запросов и использования инструмента, не запрещая выполнение. Просмотрите журналы в течение определённого времени, а затем введите правила отказа, когда поймёте распространённые шаблоны использования.

  •         **Развертывание по командам**: развертывайте крючки для одной команды или репозитория за раз, собирайте отзывы, а затем расширяйте на дополнительные команды.

  •         **Внедрение, основанное на рисках**: Начните с репозиториев, работающих с чувствительными системами или производственной инфраструктурой, затем расширяйтесь на репозитории с низким риском.

Сообщайте о ожиданиях

Прежде чем применять правила отказа, убедитесь, что разработчики понимают:

  • Что крючки активны в репозитории
  • Какие типы команд могут быть заблокированы
  • Как действовать, если приказ отклонён

Чёткая коммуникация снижает путаницу и запросы в поддержку.

Поддерживайте политики

По мере развития использования:

  • Храните конфигурацию крючка и скрипты в контроле версий.
  • Периодически проверяйте журналы аудита для выявления новых закономерностей риска.
  • Обновляйте правила запрета постепенно, а не добавляйте широкие совпадения.
  • Задокументируйте, почему существует каждое правило отказа, особенно для ограничений с высоким воздействием.

Аккуратно обращайтесь с исключениями

Некоторые команды (например, инфраструктурные или платформенные команды) могут требовать более широких разрешений. Чтобы справиться с этим безопасно:

  • Поддерживайте отдельные конфигурации крючков для разных репозиториев.
  • Держите исключения узкими и хорошо задокументированными.
  • Избегайте случайных локальных обходов, которые подрывают аудитируемость.

Дополнительные материалы

Для устранения неисправностей см. АВТОЗАГОЛОВОК.