Разработчик закоммитил на GitHub, в конфиге пароль от базы. В публичном репо видно. Чё делать срочно?
Поменял пароль в базе, но в истории GitHub всё равно видно. Удалять историю коммитов?
Можно ли детектить секреты автоматическими инструментами? Чтобы ловить заранее?
Реагирование на утечку секретов (Secret Leak): Быстрое реагирование критично. Шаги: 1) НЕМЕДЛЕННО (1-5 мин): a) Сменить пароль БД, b) Отменить доступ к репо на GitHub (проверить collaborators), c) Включить GitHub secret scanning alert, если есть (Settings → Security → Secret scanning), 2) КРАТКОСРОЧНО (5-30 мин): a) Очистить историю Git (BFG Repo-Cleaner: bfg --delete-files 'config.yml' — переписать историю), b) Force push (git push --force-with-lease) — ВНИМАНИЕ: нужна координация команды, c) Проверить другие репо (grep -r password *.git), 3) АНАЛИЗ (30-60 мин): a) Проверка git log (кто пушил, когда), b) Логи доступа (БД): были ли попытки подозрительного входа?, c) Проверка AWS CloudTrail, GCP Cloud Audit Logs, 4) УВЕДОМЛЕНИЕ: a) Инфо для команды (предупреждение о rewrite git, нужен rebase), b) Команда БД (ротация паролей). Инструменты предотвращения: 1) .gitignore (исключить конфиги), 2) Переменные окружения (.env, в git-ignored), 3) GitHub secret scanning (встроенный + сторонние: TruffleHog, GitGuardian), 4) Хуки коммитов (pre-commit framework: детект секретов перед коммитом), 5) Автоматическое сканирование (CI/CD: проверка коммитов на паттерны). Снижение рисков: Логи доступа к БД (подозрительные IP, паттерны запросов), API rate limiting (защита от brute force), MFA для БД (если поддерживается).
сразу меняй пароль в базе. чтобы удалить историю на github, используй bfg-repo-cleaner или git-filter-branch. скажи команде, что нужен git rebase. включи secret scanning на github bfg сделает это автоматически в архиве.....
Очистка секретных данных: 1) BFG Repo-Cleaner (bfg --replace-text passwords.txt --no-blob-protection repo.git), 2) git-filter-branch (старый, медленный, но точный), 3) GitHub secret scanning + авто-отзыв (если токен, то отзывается автоматически), 4) Аудит: git log -S 'password' --all (поиск по коммитам), 5) Уведомление: проверь, получали ли злоумышленники доступ к базе (логи запросов, неудачные попытки входа, IP-адреса). Внедрение профилактики: pre-commit hook (pre-commit framework + плагины: detect-secrets, truffleHog), сканирование в CI/CD (GitHub Actions: Trivy, GitGuardian), шаблон .gitignore (.env, *.key, config.local.yml). Коммуникация с командой: переписывание истории git требует от всех пользователей force-pull + rebase (нагрузка на координацию).
Doki · Мобильное приложение · 2026
Сразу меняй пароль, для удаления истории используй BFG. Предупреди команду о необходимости git rebase. Включи Secret scanning на GitHub. Настрой pre-commit hook (truffleHog, detect-secrets), чтобы ловить такие вещи в будущем. Добавь сканирование в CI/CD...
Автоматизация обнаружения секретов: 1) Локальный pre-commit (pre-commit framework + плагин detect-secrets), 2) CI/CD pipeline (GitHub Actions, GitLab CI: TruffleHog, GitGuardian), 3) Сканирование репозитория (нативный GitHub secret scanning, GitLab security scanning) 4) Аудит истории Git (git-secrets, git-dumper). Автоматизация реагирования: GitHub secret scanning → автоматическая отмена (для токенов GitHub), уведомление команды, создание записи об инциденте. Лучшие практики: Шаблон .gitignore (исключить *.key, *.pem, .env, config/*local*), стратегия переменных окружения (все секреты в env vars CI/CD, никогда в коде), сервис управления секретами (HashiCorp Vault AWS Secrets Manager).
Я маленький бизнес, расскажу со своей стороны. Главное не цифра, а то на основе чего она получена.
Проверено опытом.
Спасибо, очень помогло. Забытые тестовые среды становятся входом в систему чаще, чем продакшн.
На этом всё, извините, если затянул.
Давайте разделим понятия их путают. Если ругать за ложные тревоги, никто больше не будет присылать уведомления.
Исправьте если я ошибаюсь.
Doki · Фирменный стиль · 2026
Расскажу, что было у меня, вдруг пригодится. Ошибка, сделанная на стороне забыл пароль в исходниках, обычно исправима, но дорого.
Начните с небольшого эксперимента, не привязывайте всё сразу. На этом всё, извините, если затянул.
Этот совет подойдет не всем, на мой взгляд. Большинство инцидентов начинается не с уязвимости, а с украденного пароля.
Здесь нужно провести различие. Если путь уведомления длинный, уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент.
Я бы пошел этим путем.
Я маленький бизнес, расскажу со своей стороны. Изменение платежных данных никогда не подтверждается через тот же канал.
Расскажу, что было у меня, вдруг пригодится. Любой пункт, не зафиксированный письменно, в будущем обе стороны будут помнить по-разному.
Люди защищают не процесс, а привычку. Сопротивление идет оттуда. Это мое мнение, не утверждаю, что оно единственно верное.
Если смотреть на процесс в целом, картина меняется. Безопасность не бывает абсолютной; цель — сделать атаку нецелесообразной.
Конечно, если ваша ситуация отличается, всё меняется.