Soft skills в DevSecOps

!!!Черновик!!!!

Soft skills в DevSecOps: как быть инфобезопасником, которого не хочется выгнать

Безопасников никто не любит. Это факт. Не потому что мы плохие люди, а потому что наша работа — говорить «нет». Разработчик хочет выпустить фичу, а мы говорим «подожди». Бизнес хочет быстрее, а мы говорим «нельзя». Конфликт встроен в роль.

Можно с этим жить и дальше — приходить в конце проекта с папкой замечаний, слышать за спиной «опять этот пришёл» и видеть, как на встрече кто-то демонстративно тянется к окну. А можно попробовать иначе.

Я не претендую на истину. Просто расскажу, что понял за годы работы — в банках, у крупных заказчиков, на проверках ФСТЭК. И где я сам был тем самым безопасником, от которого хотелось сбежать.

Почему нас не любят

Это не личное. Это структурное. Мы — те, кто тормозит. Даже если мы правы, даже если спасаем от катастрофы, в моменте мы — препятствие. Разработчик не думает: «О, безопасник предупредил меня о риске». Он думает: «Из-за него я не задеплою сегодня».

Понимание этого — первый шаг. Не «они меня не ценят», а «я стою на пути, и это нормально, но с этим можно работать».

Что именно бесит коллег

Говорите «нельзя» и не говорите «как можно». Проблему нашли, решение оставили на другого. Классика жанра.

Приходите в конце проекта. Когда всё готово, осталось нажать кнопку — и тут вы с папкой замечаний. Поздравляю, вы главный враг спринта.

Объясняете на своём языке. «У вас тут RBAC-мисконфигурация с эскалацией до cluster-admin через service account». Половина зала уже потерялась на слове RBAC.

Требуете, но не объясняете зачем. «Надо». «Так положено». «Есть требования». Требования у всех есть. А зачем — непонятно.

Что делать вместо этого

Приходите раньше. Не в конце, а в начале. Лучше на этапе идеи, чем на этапе релиза. Тогда ваши замечания — это не блокер, а помощь.

Предлагайте решение, а не проблему. Не «здесь дыра», а «здесь дыра, и вот три способа её закрыть, вот плюсы и минусы каждого». Даже если решение неидеальное — вы уже не враг, а партнёр.

Говорите на языке собеседника. С разработчиком — про код и пайплайн. С менеджером — про сроки и риски. С бизнесом — про деньги и репутацию. С юристом — про регуляторов и штрафы.

Объясняйте риск, а не требуйте. Вместо «небезопасно» — «если мы это выпустим, вот что может случиться». Конкретно. С примером. Желательно с суммой ущерба.

Признайте, что у бизнеса свои приоритеты. И это нормально. Ваша задача — не победить, а расставить приоритеты. Что критично, что можно отложить, а что — принять как риск осознанно.

Умейте сказать «это можно отложить». Если вы всё называете критичным, то критичного нет. Всё становится шумом, и вас перестают слышать.

Как разговаривать с разработчиками

Три фразы, которые я стараюсь не говорить.

«Это небезопасно». Бесполезно. Разработчик не знает, что с этим делать. Замените на «если это попадёт в прод, атакующий сможет сделать вот это».

«Так нельзя». Звучит как приказ. А приказы никто не любит. Замените на «есть три варианта, давай выберем».

«Ты должен». Я никому не должен, и разработчик тоже. Замените на «нам нужно вместе решить эту задачу».

И одна фраза, которую стоит говорить чаще: «Я понимаю, что ты хочешь выпустить фичу. Давай подумаем, как это сделать безопасно и не затормозить релиз». После неё разговор идёт совсем по-другому.

Как разговаривать с руководством

Безопасность сама по себе не продаётся. Никто не выделяет бюджет на «защиту от гипотетических угроз».

Переводите в понятное:

деньги — штрафы, потери, стоимость инцидента;

репутация — что скажут клиенты, если утечка;

сроки — что будет, если проверка ФСТЭК не пройдёт;

конкуренты — что делают другие, а мы почему отстаём.

И ещё: не пугайте. «Если мы не сделаем, всё рухнет» — работает один раз. Потом к вам привыкают и перестают верить. Лучше спокойно: «вот риск, вот вероятность, вот возможный ущерб, вот что предлагаю».

Как не выгореть

Тебя будут не любить. Это часть работы. Не принимай на свой счёт.

Найди союзников. Не все разработчики считают тебя врагом. Кто-то уже понимает, зачем безопасность. С ними проще, и они помогут.

Не будь один. Если ты единственный безопасник в компании — ты всегда будешь «тем, кто мешает». Команда меняет восприятие.

Отмечай победы. Не только инциденты, которые предотвратил, но и фичи, которые помог выпустить безопасно. Иначе кажется, что ты только запрещаешь.

И помни: ты не обязан нравиться. Ты обязан быть услышанным. Это разные вещи.

Чеклист: а вас не пора проветрить?

Проверьте себя. Если больше трёх «да» — пора открыть окно.

Вы говорили «нельзя» на этой неделе больше, чем «давай подумаем, как можно»?

Вы приходили в конце проекта с замечаниями, а не в начале с советами?

Вы использовали слова, которые ваша бабушка не поймёт?

Вы требовали что-то, не объяснив зачем?

Вы считаете, что разработчики просто не понимают, насколько всё серьёзно?

Вы хоть раз сказали «это можно отложить»?

Вы ждёте, когда собеседник закончит, чтобы вставить своё?

Вы в курсе, что за спиной вас называют «этот из ИБ»?

Вы открывали окно на встрече с коллегами?

Если серьёзно — этот чеклист не приговор. Это просто зеркало. Все мы иногда бываем невыносимыми. Главное — замечать это и что-то менять.

Главное

Быть нормальным безопасником — это не про то, чтобы нравиться всем. Это про то, чтобы тебя слушали. А слушают тех, кто помогает, а не мешает.

Безопасность может быть без пафоса и с юмором. Даже на работе.

Приходите в Telegram-канал «DevSecOps здорового человека» — там мы это всё обсуждаем.