В выпуске CrossCheck обсуждали безопасную разработку, DevSecOps и то, почему внезапно все заговорили про контейнеры, секреты и «свои базовые образы».
Почему компании вообще начинают думать про безопасную разработку? Что мотивирует?
Чаще всего речь идет не про осознанный шаг, а внешнее давление. Антон Конопак описал это метафорой, которую легко запомнить:
«Есть два типа мотивации: морковка спереди и морковка сзади. У нас чаще работает морковка сзади».
Как правило, толчком становятся требования регуляторов или стандарты, которые крупные компании транслируют своим дочерним структурам. Инициатива же со стороны самой разработки встречается значительно реже и обычно держится на отдельных специалистах, которые продвигают эту тему внутри команды. К сожалению, часто заинтересованными лицами выступают тимлиды/техлиды, а не те, кто реально принимает решения. Пока идеей не загорится CISO, реализовать процесс безопасной разработки будет невозможно.
Регуляторка: кому больно, кому проще?
Как компании реагируют на требования?
Молодым проще. Они строят процессы сразу с учётом требований: SSDLC, базовые проверки, open source инструменты, минимальная гигиена.
Старым — больно. Потому что легаси-код писался в эпоху, когда «такого вообще не спрашивали». Люди, которые его писали, давно покинули компанию, поэтому навести порядок в существующем коде трудозатратно и дорого.
И в воздухе висит дилемма: рефакторить дорого, переписать — ещё дороже, поэтому иногда проще «хлопнуть продукт» и оставить на поддержке, параллельно строя новый.
DevSecOps — это не про инструменты. Сначала нужен человек
Приоритет должен быть следующим: «люди → процессы → инструменты». И первым должен появиться человек, который реально углубляется в процесс и заряжает остальных. Он же обычно становится тем ответственным. Инструменты подтянутся. Гораздо важнее, чтобы было кому ими пользоваться и было понимание, что именно нужно контролировать.
Минимальный набор, «чтобы было не стыдно»
База для большинства сценариев:
- SCA (контроль зависимостей): закрывает огромный пласт рисков и быстро даёт эффект;
- SAST (статический анализ): полезно, но требует настройки, терпения и борьбы с false positives.
Почему рынок всё ещё любит пакеты (и почему это боль)
Александр Сорокатый упомянул, что часть заказчиков всё ещё хочет deb/rpm и не готова принимать контейнеры.
Вендору приходится держать «две (иногда три) линии производства»: пакеты, контейнеры, Helm/оркестрация. Такой подход оказывается:
- дороже в сборке и тестировании,
- больнее для внедренцев
- менее предсказуемым по окружениям.
И тут контейнеризация выглядит не как модный тренд, а как способ сделать поставку и обновления предсказуемыми.
Поведенческий runtime-анализ: звучит красиво, но жить с этим трудно
«Обучим модель поведению контейнеров и будем ловить отклонения» — идея классная.
Но в реальности:
— непонятно, сколько и как обучать,
— легитимные изменения начинают выглядеть как кибератака,
— новый релиз = часто надо переобучать.
И самое показательное — на рынке это пока не основной запрос. Заказчикам чаще нужны простые и ясные вещи: политики, контроль сетевых взаимодействий, исполняемые вызовы, логи.
Как продавать DevSecOps внутри компании?
Руслан Субхангулов начинает рассуждение с направления репутации и штрафов: «сейчас штрафы выросли, это уже не 50 тысяч».
Антон в ответ охлаждает: «у нас репутационные риски часто работают слабее, чем хотелось бы. Утекло — и многие спокойно живут дальше».
А вот идея, с которой они оба согласны: бизнес понимает только деньги.
Лучший принцип для объяснения DevSecOps руководству:
— любую техническую историю переводить в деньги;
— стоимость устранения уязвимости на ранних этапах разработки горадо ниже, чем в проде;
— зависимость может быть заражена — это тоже прямой финансовый риск;
— регуляторка и предписания — тоже деньги, даже если штраф формально небольшой (премии и карьеры иногда дороже штрафов).
Слушайте и смотрите полный выпуск подкаста «CrossCheck 2.0: DevSecOps — от кода до контейнера»:
- ВК Видео;
- Рутуб;
- Яндекс Музыка.
