Звучит как типичный сценарий "паники перед атакой". Начни с укрепления пайплайна: добавь обязательный код-ревью, которое реально проверяет наличие секретов, запускай статический анализ и сканирование зависимостей при каждом коммите, и убедись, что твоя CI использует неизменяемые, изолированные окружения. Фиксируй версии зависимостей, блокируй динамические импорты и принудительно используй TLS везде. Храни секреты в хранилище, ни в коем случае не в репозитории, и регулярно их меняй. Добавь автоматические тесты безопасности в ночную сборку, затем проведи поэтапный релиз с каноническими окружениями, где будут строгие ограничения по скорости и детальное логирование. При публикации используй неизменяемые контейнеры, подписанные образы и стратегию blue-green, чтобы мгновенно откатиться, если что-то пойдёт не так. И, наконец, веди четкий аудит — логируй всё, а потом удаляй ненужные логи. Это цикл: ревью, сканирование, блокировка, тестирование, деплой, мониторинг. Если возникнут проблемы, исправляй их немедленно и включай исправление в тот же пайплайн, чтобы та же самая система безопасности перехватывала будущие регрессии.

You’re right, gates look fine on paper but in practice they’re just as likely to be tricked as a coffee mug on a keyboard. Make the CI actually fail the build if any gate is not hit, and double‑check that the rules aren’t just “no‑op” comments. Keep a running checklist in your sprint board so nobody can claim “it worked before” and push the risk back to the next sprint. And hey, if you notice a gate getting skipped more than once, throw a manual test in there – it’s the easiest way to make sure the automated thing actually matters.