Почему .env файлы — это катастрофа для безопасности (и что мы делаем вместо этого)

Компания столкнулась с нарушением безопасности, когда новый сотрудник случайно отправил производственные ключи API в публичный репозиторий GitHub через файл .env. Это привело к лихорадочным усилиям по обеспечению безопасности системы, подчеркнув риски, связанные с файлами .env. Компания осознала, что неправильное обращение с переменными окружения, особенно обмен содержимым `.env`, является серьезной уязвимостью. Инженеры часто вручную распространяли секреты, создавая узкие места в разработке и риски безопасности через такие платформы, как Slack. Существующие инструменты управления секретами были сложными и громоздкими, что затрудняло настройку окружений для не разработчиков. Компания стремилась создать решение с нулевым трением UX и первоклассной безопасностью, даже если это казалось противоречивым. Они создали собственный инструмент управления секретами, который внедрял секреты непосредственно в процесс выполнения, избегая хранения на диске и реализуя аренду Just-In-Time. Это было достигнуто с помощью облегченной CLI и расширения VS Code, что сделало новую систему практически невидимой для пользователей. Решение кардинально улучшило адаптацию, устранило утечки и прекратило обмен секретами через личные сообщения командой. Этот акцент на удобстве использования привел к более безопасной системе, демонстрируя, что хороший опыт разработчика повышает безопасность. Затем компания выпустила свое решение, RunEnv, в качестве менеджера секретов для решения этой общеотраслевой проблемы.