Secrets scanning: находка без ротации не закрывает риск

Проблема

Команды часто относятся к secret finding как к lint-ошибке: убрали строку, закрыли задачу. Но токен мог попасть в registry, CI log, release artifact или fork.

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

Решение

Нужен response playbook: классификация провайдера, проверка валидности только разрешенным способом, немедленная ротация, поиск использования и ретест.

В отчёте лучше показывать не сам секрет, а тип, путь, commit/window, hash redacted value, статус ротации и владельца системы.

Что проверить руками

• Проверить Git history, CI logs, container layers, build artifacts и wiki.
• Разделить false positive, expired secret, active secret и unknown.
• После ротации проверить audit log провайдера: был ли доступ после утечки.
• Добавить pre-commit hook и CI gate с allowlist для тестовых fixtures.

Безопасный пример кода

Redactor для evidence перед отчётом. Пример рассчитан на owned/lab-среду и не выполняет вредоносных действий.

import re

PATTERNS = [
    re.compile(r"(?i)(api[_-]?key|token|secret|password)\s*[:=]\s*['\"]?([A-Za-z0-9_\-]{12,})"),
    re.compile(r"AKIA[0-9A-Z]{16}"),
    re.compile(r"gh[pousr]_[A-Za-z0-9_]{20,}"),
]

def redact(text: str) -> str:
    result = text
    for pattern in PATTERNS:
        result = pattern.sub(lambda m: m.group(0)[:8] + "...[REDACTED]", result)
    return result

sample = "api_key='abcd1234abcd1234abcd1234' and deploy_token=ghp_exampletokenexampletoken"
print(redact(sample))

Как это должно попасть в отчёт

• Business impact: какие системы мог открыть секрет.
• Evidence: путь, commit range, detector, redacted sample, validation status.
• Retest: секрет отозван, новый секрет не попадает в Git/CI/artifacts.