AlexMorozov
New member
Когда я впервые услышал про DevSecOps, честно говоря, ожидал очередную корпоративную религию с мантрами про безопасность и стопкой регламентов на двести страниц. У нас тогда была небольшая команда, релизы каждую неделю, а безопасность жила где-то на задворках: пентест раз в год, письмо от безопасника после инцидента и вечное «давайте потом». Потом случился неприятный эпизод, когда в логи попали ключи от продакшена, и я понял, что дело не в бюрократии, а в привычках. За следующие пару лет мы перестроили процесс и выкинули из него почти всё, что пахло бумажной работой. Осталось три принципа, которые действительно работают.
Первый принцип простой: проверки должны идти вместе с кодом, а не отдельным этапом перед релизом. Мы вшили в конвейер быстрые сканеры зависимостей и секретов, добавили проверку конфигураций и линтер безопасности. Главное правило, которое я выстрадал: если проверка длится дольше пары минут, разработчик её отключит или обойдёт. Поэтому сначала только то, что даёт результат за секунды, а тяжёлый анализ уходит в ночную задачу. И да, падение сборки из-за критичной уязвимости дисциплинировало команду куда лучше любых совещаний.
Второй принцип: объяснять, а не наказывать. Раньше у нас любой разбор инцидента превращался в поиск виноватого, и люди начали молчать о своих ошибках, а это самое опасное, что может случиться с безопасностью. Мы переломили ситуацию просто: уязвимость теперь это баг с приоритетом, а не преступление. В каждой команде появился свой человек, которому эта тема искренне интересна и который может спокойно объяснить, почему так писать не стоит. Заодно мы перестали требовать идеального кода: если риск понятен и осознан, его можно принять и зафиксировать в паре строк. Доверие оказалось дешевле тотального контроля.
Третий принцип: двигаться мелкими шагами и мерить только то, что помогает. Мы не строили матрицу из сорока метрик, а следили за тремя вещами: сколько живёт критичная уязвимость, сколько секретов утекает в репозитории и сколько времени команда тратит на разбор инцидентов. Это давало честную картину без отчётности ради отчётности. Плюс дефолты в безопасную сторону: секреты только в хранилище, доступы по принципу необходимого, окружения изолированы друг от друга. Когда правильное поведение проще неправильного, никто не сопротивляется.
А вот что не сработало, и я до сих пор вспоминаю это с лёгкой дрожью. Мы пытались ввести общий чек-лист перед релизом на сорок пунктов. Через месяц его заполняли формально, копируя прошлые ответы. Отдельная команда безопасности в роли полиции вызывала только раздражение и обходные тропинки в обход процесса. Длинные внутренние стандарты никто не читал, включая их авторов. Вывод простой: любой процесс, который добавляет трения и не даёт быстрой пользы, умирает сам, причём тихо и незаметно.
Если хотите начать без большого бюджета и без новых регламентов, я бы советовал вот что. Начните с секретов в репозиториях, это самая частая и самая болезненная дыра. Затем подключите быстрый сканер зависимостей и заранее договоритесь, что команда делает с критичными находками. Найдите одного увлечённого человека и дайте ему немного времени и голос на общих встречах. Проводите разборы инцидентов без поиска виноватых, но с конкретными действиями и сроками. И хвалите команду вслух за пойманные проблемы, потому что хорошая безопасность почти незаметна, пока она работает.
Для меня DevSecOps в итоге оказался не про инструменты и не про сертификаты, а про привычки команды и уважение к чужому времени. Бюрократия появляется там, где перестают доверять людям, и почти никогда не решает реальных проблем, только создаёт видимость контроля. А у вас как? Расскажите, какие практики безопасности прижились в вашей команде, а какие вы торжественно выкинули на свалку?
Первый принцип простой: проверки должны идти вместе с кодом, а не отдельным этапом перед релизом. Мы вшили в конвейер быстрые сканеры зависимостей и секретов, добавили проверку конфигураций и линтер безопасности. Главное правило, которое я выстрадал: если проверка длится дольше пары минут, разработчик её отключит или обойдёт. Поэтому сначала только то, что даёт результат за секунды, а тяжёлый анализ уходит в ночную задачу. И да, падение сборки из-за критичной уязвимости дисциплинировало команду куда лучше любых совещаний.
Второй принцип: объяснять, а не наказывать. Раньше у нас любой разбор инцидента превращался в поиск виноватого, и люди начали молчать о своих ошибках, а это самое опасное, что может случиться с безопасностью. Мы переломили ситуацию просто: уязвимость теперь это баг с приоритетом, а не преступление. В каждой команде появился свой человек, которому эта тема искренне интересна и который может спокойно объяснить, почему так писать не стоит. Заодно мы перестали требовать идеального кода: если риск понятен и осознан, его можно принять и зафиксировать в паре строк. Доверие оказалось дешевле тотального контроля.
Третий принцип: двигаться мелкими шагами и мерить только то, что помогает. Мы не строили матрицу из сорока метрик, а следили за тремя вещами: сколько живёт критичная уязвимость, сколько секретов утекает в репозитории и сколько времени команда тратит на разбор инцидентов. Это давало честную картину без отчётности ради отчётности. Плюс дефолты в безопасную сторону: секреты только в хранилище, доступы по принципу необходимого, окружения изолированы друг от друга. Когда правильное поведение проще неправильного, никто не сопротивляется.
А вот что не сработало, и я до сих пор вспоминаю это с лёгкой дрожью. Мы пытались ввести общий чек-лист перед релизом на сорок пунктов. Через месяц его заполняли формально, копируя прошлые ответы. Отдельная команда безопасности в роли полиции вызывала только раздражение и обходные тропинки в обход процесса. Длинные внутренние стандарты никто не читал, включая их авторов. Вывод простой: любой процесс, который добавляет трения и не даёт быстрой пользы, умирает сам, причём тихо и незаметно.
Если хотите начать без большого бюджета и без новых регламентов, я бы советовал вот что. Начните с секретов в репозиториях, это самая частая и самая болезненная дыра. Затем подключите быстрый сканер зависимостей и заранее договоритесь, что команда делает с критичными находками. Найдите одного увлечённого человека и дайте ему немного времени и голос на общих встречах. Проводите разборы инцидентов без поиска виноватых, но с конкретными действиями и сроками. И хвалите команду вслух за пойманные проблемы, потому что хорошая безопасность почти незаметна, пока она работает.
Для меня DevSecOps в итоге оказался не про инструменты и не про сертификаты, а про привычки команды и уважение к чужому времени. Бюрократия появляется там, где перестают доверять людям, и почти никогда не решает реальных проблем, только создаёт видимость контроля. А у вас как? Расскажите, какие практики безопасности прижились в вашей команде, а какие вы торжественно выкинули на свалку?